The Green Dashboard Trap: Why ERP and MES Projects Fail Long Before Anyone Reports Red
There is a phrase that echoes through every project review room in India, from gleaming corporate towers to the air-conditioned cabins of integrated steel plants somewhere in this vast subcontinent. It is spoken with the quiet confidence of a man who has not yet opened the envelope.
“Sab theek hai, sir.”
Everything is fine.
It is said with such conviction, such practiced calm, such absolute serenity in the face of a schedule that has been quietly unravelling for six weeks, that it can make a steering committee member genuinely doubt their own instincts. Perhaps I am being unnecessarily anxious, they think. After all, the PM looks so relaxed.
The PM looks relaxed because she has had six weeks of practice.
This is the story of the Green dashboard… the single most expensive cosmetic product in the Indian project management ecosystem, and what happens when the foundation eventually runs out.
The Setup: What Actually Happens on Status Report Day
Picture the scene.
It is Thursday afternoon. The fortnightly steering review is tomorrow morning. The project manager has her laptop open, the status report template staring back at her like a disappointed parent.
The RAG field is blinking.
In the last two weeks, the following things have happened on her ERP implementation project… a large SAP S/4HANA rollout for an integrated steel plant spanning procurement, production planning, maintenance, and finance:
The legacy data extraction from the old system has thrown up 47,000 records with currency field mismatches that the migration team has been working on since Tuesday and has not yet resolved.
The basis team from the implementation partner - three people who flew in from another city - quietly mentioned in passing that the sandbox environment has been running at 94% memory utilisation since the load testing began and “it should be fine but we are monitoring.”
The FICO configuration lead has discovered that the plant’s chart of accounts has seventeen cost centres that do not exist in the new system and nobody knows who created them or what they were for.
And the business process owner for procurement… a senior manager who has been on this project since the beginning and knows where all the bodies are buried, has gone on two weeks of earned leave for a family wedding, taking his passwords and his institutional knowledge with him.
The PM looks at this situation. She looks at the RAG field. She thinks about tomorrow’s meeting, and the CFO who chairs it, and the way the CFO raises his left eyebrow when something displeases him.
She selects: Green.
Thoda manage ho jayega, she tells herself. It’ll get sorted somehow.
It will not get sorted. But that is a problem for next Thursday.
The Rationalisation: A Familiar Internal Monologue
The selection of Green over Amber is never without justification. The project manager’s internal monologue at this moment is a masterpiece of creative reasoning that deserves full documentation.
The currency issue is a data quality problem, not a project problem. We will fix it before go-live.
The sandbox memory thing is probably just the load testing. The basis team said it should be fine.
The cost centres - we’ll raise a configuration change request. It’s not blocking anything right now.
He will be back in two weeks. The wedding is only three days. The leave is mostly travel.
If I put Amber on this report, the CFO will spend forty-five minutes asking questions I don’t have answers to yet. What is the point of alarming him when I am already working on solutions?
Every one of these rationalisations contains a grain of truth. That is precisely what makes them dangerous.
The currency issue is a data quality problem… that is also a project problem, because the data quality problem is sitting on the critical path between extraction and migration sign-off. The sandbox memory is probably the load testing - but “probably” and “basis team said should be fine” is not the same as a confirmed, documented capacity assessment. The cost centres are not blocking anything right now, but “right now” is doing a lot of work in that sentence, because the FICO sign-off is in six weeks and unexplained cost centres have a way of becoming very blocking very quickly. The business process owner will be back in two weeks, but the interface specification review that was supposed to happen this week, which only he fully understands, has now moved two weeks to the right on a schedule that had no float.
Taken individually, each rationalisation is defensible. Taken together, they are the architecture of a project that is drifting and has chosen not to notice.
Andha vishwas, as they say. Blind faith in one’s own optimism.
The Green Dashboard in Steel Manufacturing: A Special Case
The project management community is full of cautionary tales about filtered reporting. What makes the steel manufacturing context - specifically ERP, MES, and APS implementations - particularly fertile ground for this kind of governance failure?
Three things. And they are beautifully specific.
First: the domain complexity is a perfect alibi.
An integrated steel plant is one of the most operationally complex environments on earth. The production chain runs from iron ore and coal handling through sintering, coking, blast furnace, steelmaking, continuous casting, hot rolling, cold rolling, finishing, and dispatch… each stage with its own process logic, equipment constraints, quality parameters, and data footprint.
When a PM in this environment says “it’s complex, we’re managing,” nobody in the steering committee is entirely sure she is wrong. Maybe it is supposed to be this hard. Maybe the MES integration with the Level 2 automation systems is always this temperamental. Maybe the APS system’s heat scheduling module always takes this long to configure against the caster constraints. The domain expertise required to challenge the PM’s narrative is precisely the domain expertise that the steering committee often does not fully possess.
The complexity becomes cover. Legitimate, plausible, technically impenetrable cover.
Second: the plant operations team has its own priorities, and they are not your go-live date.
In every steel plant ERP or MES implementation, there is a moment, usually around month ten of a twenty-four month project, when the reality of the plant’s operational calendar becomes visible in all its uncompromising glory.
The blast furnace cannot be touched during the campaign. The hot strip mill has a planned maintenance shutdown that the entire plant is organised around. The coke oven battery is due for a partial relining. The annual inventory count is approaching and no system changes are permitted within four weeks on either side.
These are real constraints. They are also, for a PM whose schedule is already under pressure, a magnificent source of justification for why certain milestones have slipped.
“We couldn’t complete the MES go-live for the casting shop because the furnace campaign constraint precluded any system changes in that period.”
Technically accurate. Also a fact that was known at the start of the project and should have been built into the plan. But in the status report, it appears as external constraint rather than planning failure… and external constraints are Green by temperament.
Third: the vendor ecosystem is a web of interdependencies that nobody has fully mapped.
A large steel plant ERP implementation typically involves SAP as the core system, a Level 1/Level 2 automation vendor whose systems need to interface with the MES, a specialist MES vendor whose platform needs to talk to both the ERP and the automation layer, an APS vendor whose planning engine needs real-time data from the MES and constraint data from the ERP, and, quite often, an integration middleware platform connecting all of these.
Each of these vendors has its own project manager, its own timeline, its own interpretation of the interface specification, and its own set of reasons why the delay is someone else’s fault.
In this ecosystem, a PM who wants to report Green has essentially unlimited material to work with. Something is always technically in progress. Something is always “being resolved bilaterally.” Something is always “in the vendor’s hands.”
“The APS scheduling module integration is currently being finalised with the MES vendor. Both teams are aligned on the approach and the resolution is expected by end of the current sprint.”
This sentence has been written, in some form, in every APS implementation status report in the history of APS implementations. It is the single most durable piece of programme fiction in the manufacturing software industry.
A Tale of Two Implementations
The One That Didn’t Escalate
An integrated steel plant somewhere in this country is implementing a full MES rollout - covering steelmaking, continuous casting, and hot rolling. The project has been running for fourteen months. The dashboard has shown Green for eleven of them.
In month twelve, the hot rolling mill team begins integration testing for the MES scheduling interface with the SAP PP module. The integration is supposed to receive rolling campaign data from SAP, pass it to the MES scheduling engine, and return confirmed production sequences to SAP for capacity confirmation.
The testing fails. Not in a small way. In the way that produces a silence in the testing lab that is different from all the normal silences.
The SAP PP module has been configured against a coil product hierarchy that uses a six-character material code. The MES scheduling engine, as configured by the MES vendor over the last eight months, has been built against a five-character code. This discrepancy has been visible in the interface specification document since month three. It was flagged in a bilateral technical meeting between the two vendors in month five. It was assigned to a joint working group in month six.
The joint working group had four meetings. The last one was in month eight. After month eight, both vendors assumed the other was handling the resolution.
Nobody told the PM. Or rather, somebody told the PM in month seven that “the code length alignment is being worked through,” and the PM logged this as an open item in the RAID register, marked it as “In Progress, Vendor,” and stopped asking about it.
Eleven months of Green dashboards. Fourteen months of project time. And the integration test that was supposed to be a formality is failing because of a discrepancy that has been sitting unresolved in the RAID register since month six.
The steering committee hears about this in month twelve. The chairman - a Vice President of Operations who has spent his career in steel - asks the question that every steering committee eventually asks:
“Why are we hearing this in month twelve? This was flagged in month six. What happened in the seven months in between?”
There is no good answer. The PM has a technically accurate explanation, the item was logged, it was assigned, the vendors were supposed to resolve it. But the steering committee is not asking for a technically accurate explanation. It is asking why nobody escalated a vendor interdependency that had been sitting unresolved for seven months.
The go-live, originally planned for month eighteen, moves to month twenty-four. The additional cost… extended vendor engagement, rework on the interface layer, extended project team deployment… runs to 35% of the original project budget.
Chota sa kaam tha, they said in month six. Just a small thing to align. Ho jayega.
The One That Did
A second steel plant, different ownership, similar scope - MES plus APS implementation for a flat products facility. The project manager runs her fortnightly reviews differently.
In month four, her integration architect flags the same kind of code length discrepancy… this time between the APS planning system and the ERP material master. It is a smaller issue, but the principle is identical: the two systems have been configured against slightly different versions of the material classification hierarchy.
She does not mark this Green. She marks it Amber and writes three lines in the escalation field: “Interface discrepancy identified between APS material codes and ERP material master classification. Bilateral vendor resolution has not progressed in two weeks. Requesting steering committee facilitation to bring both vendor PMs into a joint resolution session with authority to commit to a resolution approach.”
At the next steering committee meeting, the VP of Projects, who chairs the committee, contacts both vendor account managers directly and requests that each vendor’s delivery lead attend a joint session the following week with resolution authority.
The joint session happens. The resolution approach is agreed in three hours. The implementation is complete within the month.
Total delay to the programme: zero. Total cost of the escalation: one steering committee intervention and one joint vendor session.
Total cost of not escalating in the first case: six months and 35% of budget.
Same type of problem. Different reporting choice. Categorically different outcome.
Yahi toh farq hai. This is exactly the difference.
The Specific Pathology: Why This Happens in ERP Implementations
There is something particular about large ERP implementations, that amplifies the Green dashboard problem.
ERP projects are structured around phases: Blueprint, Realise, Deploy, Run. Each phase has a formal gate. Each gate has a checklist. Each checklist has a sign-off.
The psychological effect of this phase structure is that PMs tend to manage to the gate rather than to the outcome. The goal at any given moment is to clear the next gate. And gates, being checklist-based, can be cleared by completing checklist items, regardless of whether the completion is genuine.
Consider the Blueprint phase sign-off. The checklist includes: business process workshops completed, to-be process documentation approved, configuration design signed off by business process owners.
Workshop completed: yes, fourteen workshops were held.
To-be documentation approved: yes, sixty-two process documents have signatures on them.
Configuration design signed off: yes, the business process owners have signed the configuration design documents.
What the checklist does not capture: the workshops were attended by the wrong people in three critical areas because the right people were unavailable. The to-be documentation was signed by process owners who had not fully read it, because the signature was presented as an administrative step rather than a substantive approval. The configuration design sign-off happened in a session where the business process owner was shown a forty-slide deck in ninety minutes and signed at the end because the room expected her to.
The gate clears. The phase moves to Green. The Realise phase begins on a foundation that has not been properly laid.
Six months later, when the unit testing in Realise throws up configuration issues that trace directly back to unresolved decisions in Blueprint, the PM is surprised. She should not be surprised. The decisions were never actually resolved; they were gated through.
Khana khaya nahi, bas plate mein ghuma diya. The food wasn’t eaten, just moved around the plate.
The Comedy of the Amber That Fixed Itself
Every experienced project manager on a large implementation has encountered the Amber that fixed itself.
The Amber appears in the status report on a Thursday. By the following Thursday, when the next report is due, it has been upgraded to Green with a one-line note: “Issue resolved through vendor coordination.”
The steering committee sees the Amber for exactly one reporting cycle. They do not have time to ask about it. By the time the question forms, the Amber is already Green.
This is a sophisticated form of status report management that achieves two objectives simultaneously: it cannot be accused of hiding the Amber - it was reported! while ensuring the committee never actually engages with it.
The problem is that Ambers that genuinely resolve within a week are rare in complex manufacturing implementations. What is more common is that the Amber has been given an optimistic one-week resolution timeline that keeps it out of the committee’s direct line of sight, and then managed to a Green through a combination of deferred scope, workarounds, and quiet compromises that nobody has formally agreed to.
The testing scope was reduced by 15% to meet the timeline. Resolved.
The configuration gap was bridged with a manual workaround that will need to be automated later. Resolved.
The interface that was not working has been temporarily bypassed with a file-based data transfer that is not the intended architecture. Resolved.
Jugaad hai, sir. It’s a workaround. But on the dashboard, it looks like a solution.
The jugaad, of course, has a cost. It accumulates. By the time the project reaches User Acceptance Testing or go-live, the accumulated jugaad of twelve months of self-resolving Ambers has become the project’s biggest hidden risk - embedded in the system, undocumented, misunderstood, and quietly waiting to cause production incidents that the operations team will not be able to explain.
Tips for Project Managers: How to Break the Green Habit
One: Define your RAG criteria at the start, in writing, and get them signed off by the committee.
Do not leave RAG definitions to intuition or convention. Write them down explicitly. Green means: on schedule within agreed tolerance, no unresolved issues with cross-workstream impact, all risk mitigations progressing as planned. Amber means: schedule variance outside tolerance, or any unresolved vendor interdependency older than ten working days, or any risk without a documented mitigation owner and completion date. Red means: milestone cannot be achieved within the current plan without steering committee intervention.
Signed off. By the committee. At the very start.
Now you have something to point to. “I am reporting Amber because of the RAG criteria we agreed in week one.” This removes the subjectivity that enables managed optimism. It also removes the committee’s ability to retroactively claim the Amber was unnecessary; they defined the criteria themselves.
Two: The RAID log is not a parking lot.
A risk that sits in the RAID log for more than ten working days without a documented mitigation action and a named owner is not being managed. It is being stored. There is a meaningful difference between those two things.
Every item in the RAID log needs: a named individual owner, a specific mitigation action, a completion date, and a status update in every reporting cycle. If an item has carried the status “In Progress, Vendor” for three consecutive weeks, it has not been in progress. It has been parked. Park it in Amber instead, escalate it to the committee, and get a decision.
Three: Never carry a vendor interdependency past two missed deadlines without escalating.
Vendor interdependencies are the single biggest source of suppressed risk in ERP and MES implementations. The pattern is always the same: two vendors have an interface dispute, neither has authority to resolve it unilaterally, both prefer bilateral negotiation to escalation, and the PM lets them continue because escalating means an uncomfortable steering meeting.
The rule is simple: two missed deadlines on a vendor interdependency triggers automatic escalation. Not a discussion about whether to escalate. Automatic escalation. The PM’s job is to inform the committee that the interdependency exists, name the two missed deadlines, and state specifically what she needs from the committee to force resolution.
Four: Surface the single-point-of-knowledge problem immediately.
In every steel plant ERP implementation, there is at least one person who holds more institutional knowledge than any documentation can contain… whose availability is critical to specific project phases, and whose absence creates a knowledge gap that cannot be filled by anyone else on the team.
When that person goes on leave, falls sick, or changes role, that is a project risk. Log it. Report it. Do not assume it will be fine because their junior “knows most of it.” The junior knows most of it right up until the moment when the most important 15% is needed and the junior looks at you with the expression of someone who has just discovered what they do not know.
Five: Practise the structured escalation before you need it.
Most PMs avoid escalating because they are not confident doing it well in a committee context. They know how to describe a problem. They do not feel comfortable presenting it with options and a clear ask in front of senior leadership.
Practise this format until it is automatic: “We have identified [specific issue]. The current impact if not resolved is [schedule/cost/scope impact]. We have considered three options: [option one, option two, option three]. I am asking the committee to decide between options two and three today, because both require authority above my level.”
That is the whole format. Three minutes to deliver. Gives the committee everything they need. Positions the PM as a competent professional managing complexity, not a panicking individual with a crisis she cannot contain.
Seedhi baat, no bakwaas. Direct talk, no nonsense.
Tips for Steering Committee Members: How to See Through the Green
One: The dashboard that never goes Red is a broken instrument.
If a programme has been running for more than six months and the consolidated RAG has never shown a Red, one of two things is true: either the programme is the most flawlessly executed delivery in your organisation’s history… in which case, document it immediately and submit it for industry awards… or the RAG instrument has been captured and is no longer reflecting reality.
In steel plant ERP and MES implementations, the second explanation is almost always correct. There is no such thing as a complex manufacturing software implementation that runs for six months without encountering a genuine Red. If you are not seeing one, ask directly: “Show me the last three items that escalated to Red and how they were resolved.”
If nobody can show you three, something is being managed rather than reported.
Two: Ask about the interfaces, not just the workstreams.
The workstream-level dashboard is always more optimistic than the interface-level reality. A workstream lead asked “how is your workstream doing?” will give you her workstream’s perspective. The same lead asked “what are you dependent on from the adjacent workstream, and what is the current status of that dependency?” will tell you something considerably more revealing.
In your next steering review, pick three interface dependencies at random… the SAP-to-MES interface, the APS planning engine’s data feed from the ERP, the automation layer integration with the MES. Ask the programme manager to describe the current status of each. Not the workstream. The interface.
The answers will be instructive.
Three: “The vendor is handling it” is a question, not an answer.
When a PM tells the committee that an issue is “with the vendor” or “being resolved bilaterally between the vendors,” the appropriate response is not to nod and move on. The appropriate questions are:
“Since when has this been with the vendor?”
“What is the vendor’s committed resolution date?”
“What happens to our programme schedule if the vendor misses that date?”
“What have we done to formally escalate within the vendor’s own organisation?”
If the answer to any of these is “we’re monitoring” or “I’ll have to check,” the item is not being managed. It is being deferred. The committee needs to intervene.
Four: Create a safe room, not an inquisition chamber.
This one is uncomfortable, but it needs to be said without softening. If your steering reviews have developed a reputation for turning into interrogations when a workstream goes Amber, your PMs are reporting Green specifically to avoid the interrogation. You are not receiving honest information. You are receiving a performance calibrated to your known reaction.
The single most effective thing a steering committee chair can do is respond to the first well-structured Amber escalation with visible, public appreciation… in front of all the other workstream leads in the room. “Thank you for flagging this early. This is exactly the kind of information we need from this forum. Let’s make a decision.” And then make a decision, in that meeting, and follow up on it at the next review.
Do this once, visibly, and watch what happens to the quality of the status reports that follow.
Five: Ask for the RAID items that closed without escalation.
Every programme has a RAID log. Ask to see not just the open items but the recently closed ones… the risks and issues resolved in the last month without being escalated to committee level.
Read them. Not to second-guess the PM’s judgment about what needed escalation, but to understand the pattern of what the programme considers below the escalation threshold.
If you find items closed with the note “resolved through vendor coordination” and no further detail, ask what the resolution actually was. If you find items that involved interface decisions or scope trade-offs, ask what was decided and by whom. If you find items that affected the schedule by more than a week, ask why the impact was not reported upward.
This exercise, done once a quarter, does more for programme transparency than any governance framework document ever written.
The Moral of the Story
The PM from our opening scene is not a bad project manager. She is a good project manager operating in a governance environment that has trained her to believe that smooth reporting is a professional virtue.
It is not. It is a professional habit that defers cost rather than eliminating it… and in a complex manufacturing software implementation, deferred cost carries compound interest that the project eventually pays at the worst possible moment.
The currency field mismatches, the sandbox memory issue, the seventeen mystery cost centres, and the absent business process owner are not individually catastrophic. Together, logged honestly as Amber, escalated in a structured way, they give the steering committee exactly the information they need to intervene while intervention is still inexpensive.
Hidden behind a Green dashboard, they become the archaeology of a project that went wrong… the items that appear in the post-mortem as “early warning signs that were not surfaced.”
Doodh ka doodh, paani ka paani, as the saying goes. Milk is milk, water is water. Sooner or later, everything separates into what it actually is.
The dashboard that reads Green when the project reads Amber is not a performance. It is a loan, taken from the future of the project, at interest rates that only become visible when the bill arrives.
And in steel plant ERP and MES implementations, the bill always arrives.
Sab theek nahi hai, sir. Everything is not fine. And the sooner you say it out loud, in a steering meeting, with a structured escalation and a clear ask, the better it is for everyone in the room — including the PM who has been carrying it alone.
Have you sat on either side of this table… as the PM who knew more than the dashboard showed, or the committee member who found out too late? Tell me what changed the day someone decided to report honestly. The comments are open.
#ProjectManagement #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #ProgrammeGovernance #HonestLeadership #DigitalTransformation #SAPImplementation #IndianManufacturing #PMLeadership #SteeringCommittee #DeliveryExcellence
Disclaimer: The incidents, characters, projects, and organisations referenced in this article are fictionalised composites drawn from recurring patterns observed across complex transformation programmes. Their purpose is to illustrate leadership and governance lessons rather than describe any specific organisation, project, customer, or implementation. The lessons, however, are very real.