Yeh Toh Safe Lag Raha Tha, Sir — The Trap That Feels Like Safety
If you have missed out the articles in this series, glance through these for a quick recap:
The Green Dashboard Trap: Why ERP and MES Projects Fail Long Before Anyone Reports Red
What a Steering Committee Actually Is, and Why You Are Using It Wrong
There is a particular comfort that settles over a project manager after a successful steering meeting.
The dashboard was Green. The committee seemed satisfied. The CFO did not raise his left eyebrow. The business sponsor smiled and said “good progress” on the way out. The invoices were approved without a single follow-up email.
She drives home thinking: this is what good project management looks like.
It is not. What it looks like is a loan that has been taken out at an interest rate she has not yet been shown. The principal is the problem she did not surface. The interest is the cost that will accumulate between now and the moment reality insists on being heard. And the moment reality insists on being heard is never the moment she would have chosen.
Udhar liya tha khushi se, bharna padega dukh se. Borrowed in happiness, repaid in grief.
The Logic That Makes It Feel Reasonable
The first thing to understand about managed optimism is that it does not feel like dishonesty. That is precisely what makes it dangerous.
It feels like professionalism. It feels like the exercise of judgment. It feels like the kind of mature, calibrated stakeholder management that distinguishes an experienced project manager from a junior one who panics at every minor deviation and floods the committee with noise.
The internal logic is airtight, at least in the short term.
The PM identifies a vendor risk. She assesses it. She concludes it is manageable with internal effort. She manages it. It resolves, approximately, before the next steering meeting. She reports Green. Nothing bad happens. The committee is satisfied. The relationship with the business sponsor remains warm and productive.
The feedback loop is immediate and unambiguous: smooth reporting produces smooth interactions. Smooth interactions produce goodwill. Goodwill produces approvals. Approvals produce continued project funding, continued vendor cooperation, and continued organisational support.
Everything about this loop rewards the behaviour. Nothing in this loop signals the cost.
What the loop does not show is what is accumulating underneath it. Because every problem that is managed internally rather than escalated produces several downstream consequences that are invisible at the moment of the decision.
The committee makes its next set of decisions without knowing about the vendor risk. Those decisions may depend on assumptions that the vendor risk has already invalidated. The committee does not know this.
The vendor risk, having been managed with a workaround rather than a structural fix, may resurface later in a different form. The workaround is undocumented. When it resurfaces, nobody will be able to trace it to its origin quickly.
Ek jhooth chhupaane ke liye sau jhooth bolne padte hain. To hide one lie, a hundred more are needed. Not because the PM is lying exactly, but because each managed problem requires the next status report to be consistent with the last one, and consistency with a managed picture requires continued management of the picture.
The PM, having successfully managed one problem alone, develops a slightly higher threshold for what constitutes an escalation-worthy issue. The next problem she manages alone is slightly larger. The threshold keeps moving.
And the gap between the project’s reported state and its real state grows, slowly, silently, in the space between steering meetings.
The Steel Plant Dimension: Why This Trap Has Extra Teeth Here
In a generic software project, managed optimism is costly. In a steel plant ERP, MES, or APS implementation, it has three specific characteristics that make it significantly more expensive.
The interdependencies are deeper and less visible.
A steel plant’s production system is not a collection of independent processes. It is a tightly coupled value chain where every stage is constrained by the stage before it and constrains the stage after it. The blast furnace feeds the steelmaking shop. The steelmaking shop feeds the caster. The caster feeds the rolling mill. The rolling mill feeds the finishing lines.
In this environment, a risk that is managed locally in one workstream is almost never truly local. The APS planning engine that is being configured with simplified caster constraints will eventually generate schedules that the steelmaking team cannot execute. The MES that is going live on the casting shop without resolving the interface with the SAP production order management will eventually create a data gap that neither system can explain. The ERP material master that has been set up with workaround cost centres will eventually produce financial reporting that the auditors cannot reconcile. Add more complexities to it by including site-specific plausibilities, and there you got the problem blown up exponentially.
Every locally managed problem in a steel plant implementation has a downstream address. The problem does not know it has been contained. It travels.
The plant operations team’s tolerance for system failure is zero.
When a steel plant’s MES goes live with an embedded workaround in the heat scheduling logic, and that workaround causes the system to recommend a heat sequence that the caster operators know is operationally wrong, the operators do one of two things: they override the system manually, or they stop using it.
Both outcomes are catastrophic for an MES implementation. Manual override means the system is not driving operations, which means the implementation has not delivered its value. System abandonment means the implementation has actively failed. Indeed, there is no middle path here, and for obvious reasons; Operations cannot be expected to ‘compromise’ on their work.
A software project that fails in a banking context or a retail context can be patched, rolled back, or replaced with relatively manageable disruption. A steel plant production system that loses operator confidence during go-live cannot be easily recovered, because steel plant operators develop their distrust slowly and surrender it even more slowly.
The cost of a managed problem that surfaces post-go-live in a steel plant context is not just financial. It is operational, relational, and often irreversible in its impact on the implementation’s long-term adoption.
The vendor ecosystem has long memories and short patience.
Steel plant automation and MES vendors are a relatively small community. The same vendors appear on multiple projects across multiple plants. The relationships between client organisations and vendor teams are long-standing and commercially significant.
When a project manager manages a vendor risk internally rather than escalating, she is not just deferring the problem. She is allowing the vendor to optimise their resource allocation for clients who are applying visible pressure, which means her project slides down the vendor’s internal priority list without either party explicitly acknowledging it.
And when the problem eventually surfaces and the escalation finally happens, the vendor has moved on. Resources have been committed elsewhere. The senior configuration lead who should have been on this project for the last three months has been deployed to another engagement. Getting them back requires breaking a commitment the vendor has made to another client, which the vendor will resist, which means the recovery takes longer and costs more than the original escalation would have.
In short, vendors know who is serious and who is managing their perception.
The Relationship That Ran Out: A Story Without Geography
There is a pattern that repeats itself in large programmes with enough regularity that anyone who has spent time in this industry will recognise it instantly, even if they have encountered it in different contexts.
A project manager builds an excellent working relationship with two or three key members of the steering committee. These are people who champion the project internally, who smooth the path for approvals, who absorb difficult conversations with their own leadership so those conversations do not reach the PM directly.
The PM, understandably and quite naturally, values these relationships. She protects them. She manages her reporting to avoid creating discomfort for people who have been good to her and to the project.
Over time, this protection becomes structural. Budget forecasts are presented with assumptions that make the numbers look better than they are. Schedule risks are described as “being managed” rather than being quantified. A significant scope addition, agreed in an informal conversation with one of the champions, is absorbed into the baseline without a formal change request, because raising a change request would mean an uncomfortable conversation about cost that the PM does not want to have with someone who has been supportive.
For a year, perhaps more, the arrangement works. The champions are happy. The programme looks healthy. Approvals come through without friction.
And then the champions leave.
It might be a reorganisation. It might be a promotion that takes them out of the programme’s governance structure. It might be a retirement. It might be a company acquisition that changes the leadership team overnight. In large organisations, personnel change is not an exceptional event. It is a feature of the environment.
The new committee members arrive. They have no relationship with the PM. They have a mandate to review programme performance against the original business case. They ask for the change request log, the risk register, the budget reforecast documentation, and the assumptions underpinning the current schedule.
What they find is a programme that has absorbed significant scope growth with no formal change record. A budget that has been reforecast with assumptions that are not documented anywhere. A risk register that is suspiciously clean for a programme of this complexity. And a PM who is very good at explaining things verbally but cannot point to documents that support her explanations.
The scope addition that was absorbed informally becomes the central question. The new committee asks whether it was formally approved. The PM says it was approved verbally by the previous director. The previous director, contacted for clarification, says he does not recall approving it in those terms. He may be right. He may be misremembering. He may be protecting himself. It does not matter which, because the outcome is the same: the approval cannot be substantiated, and a claim for additional funding based on an unsubstantiated verbal approval is not a strong commercial position.
Jo likha hai woh hai. Jo nahi likha, woh kabhi hua hi nahi. What is written exists. What is not written never happened.
The financial exposure from that single undocumented decision is significant. The time spent in dispute over it is significant. The damage to the PM’s professional reputation is significant. As a consequence, teams scramble overnight digging out their mailbox archives (rotten skeletons from graves, to honestly admit - ghade murde ukhaadna), to identify who-said-what-and-when-why-why-not. Huff! Nightmare literally!
And it was entirely preventable with a single change request form, submitted at the time, creating a paper trail that would have protected everyone including the champions who approved it. And all easily manageable with just being a little-more process-oriented, and using the ticketing systems like JIRA.
The Three Specific Traps in ERP, MES and APS Programmes
The general pattern above plays out in three specific and recognisable ways in steel plant software implementations. Each one deserves naming precisely, because naming them is the first step to avoiding them.
Trap One: The Informal Scope Conversation
In every large implementation, there are conversations that happen outside the formal project governance structure. A business process owner walks into the project room and says the system needs to do something it was not designed to do. A plant manager mentions in passing that he assumed the MES would handle a specific scheduling scenario that is not in scope. A finance director says she thought the ERP would produce a specific report format that the configuration does not support.
These conversations are real. The needs behind them are often legitimate. And the PM, wanting to be helpful and wanting to maintain a good relationship with the business, says: “Let me see what we can do.”
What she should say is: “That sounds like it may be outside the current scope. Let me raise a change request so we can assess the impact and get a formal decision from the committee.”
The difference between these two responses is the difference between a programme that accumulates undocumented scope and a programme that has a clean change record.
The informal scope conversation is the single most common source of undocumented scope growth in steel plant ERP implementations. Not because project managers are negligent, but because the impulse to be helpful and maintain relationships is natural, and the change request process feels like an obstacle to helpfulness rather than a protection of the project.
It is not an obstacle. It is a record. And a record, as the previous story demonstrates, is worth considerably more than a relationship when the relationship is no longer in the room.
Trap Two: The Optimistic Reforecast
Budget pressure in large implementations is a constant. At some point in almost every programme, the original budget estimate proves to have been optimistic, and the project manager faces a choice: surface the overrun and request a reforecast through the governance process, or find a way to make the numbers work within the existing budget by adjusting assumptions.
The adjustment of assumptions is not always dishonest. Assumptions do change. Scope does evolve. Legitimate efficiencies are sometimes found. But the pattern of reforecasting with progressively optimistic assumptions, without documenting why the assumptions have changed, is a pattern that eventually produces a budget that is disconnected from reality and a financial history that cannot be audited cleanly.
In a steel plant ERP context, this manifests in specific ways. The data migration effort is reforecast downward by reducing the historical data scope, without formally documenting the scope reduction or its implications for reporting. The training effort is reforecast downward by reducing the number of training sessions, without documenting the risk that a reduced training programme creates for system adoption. The cutover effort is reforecast downward by assuming a shorter parallel run period, without documenting the operational risk that a shorter parallel run creates for the plant.
Each of these adjustments is individually defensible. Together, they produce a budget picture that is technically within the approved number and operationally a fiction.
Trap Three: The Vendor Risk That Was “Being Monitored”
The third trap is the most common and the most dangerous in multi-vendor implementations like those typical of steel plant systems.
A vendor is behind on a deliverable. The PM is aware of this. She has had conversations with the vendor’s project manager. The vendor has committed to catching up. She has logged the item in the RAID register as “In Progress” with a note that it is “being monitored.”
For six weeks, the item sits in the RAID register with the same note. The status in each fortnight’s report is Green, because the vendor has committed to recovery and the PM is “monitoring” the situation.
What “monitoring” means in practice: the PM checks in with the vendor’s PM weekly. The vendor’s PM says progress is being made. The PM accepts this assessment.
What “monitoring” does not mean: any independent verification of the vendor’s claim, any escalation to the vendor’s account management, any formal notice of delay, any contractual mechanism being invoked, or any assessment of what happens to the programme schedule if the vendor does not recover.
The vendor does not recover. The item that was “In Progress” for six weeks surfaces as a failed milestone in week seven, at which point the schedule impact is visible, the escalation options are more limited, and the steering committee is asking why six weeks of “monitoring” did not result in a flag.
The answer, which the PM cannot say out loud, is that monitoring was chosen over escalating because escalating would have turned the item Amber on the dashboard, and Amber was uncomfortable.
Remember! Monitoring and managing are not the same thing.
The Only Strategy That Survives Personnel Change
The core insight buried in all of these examples is one that experienced programme directors articulate in different ways but always arrive at the same place.
Personal relationships are programme assets. But they are volatile assets. They are contingent on specific individuals remaining in specific roles, which in large organisations is never guaranteed beyond the short term.
Documented governance is a programme asset too. It is a significantly more stable one. A change request exists regardless of who approved it. An escalation note in the steering committee minutes exists regardless of whether the committee member who received the escalation is still in their role. A risk register entry with a named owner and a documented mitigation exists regardless of what happens to the project manager who wrote it.
Honest reporting builds an institutional record. That record is the programme’s most durable asset, because it is the only thing that remains fully intact when everything else changes around it.
A documented programme can be handed over to a new PM mid-delivery and the new PM can understand what has happened. A documented programme can be audited without requiring anyone to reconstruct decisions from memory (no need to look at skeletons). A documented programme can be defended when new committee members arrive with mandates to scrutinise it, because the scrutiny lands on a paper trail that shows a programme that was honestly managed, with problems surfaced and decisions made transparently.
An undocumented programme, in all these scenarios, requires the people who built it to be present to explain it. And the people who built it are not always present.
This is why the PM who raises every scope addition through a formal change request, even the ones where the sponsor pushes back, even the ones that create an uncomfortable meeting, is making the right professional decision, regardless of how it feels in the moment.
Rishte aate jaate hain. Record hamesha rehta hai. Relationships come and go. The record stays.
She is not being rigid or bureaucratic. She is building something that will exist after the sponsor leaves, after the committee turns over, after she herself moves on to the next engagement. She is building a programme that is governed by its record, not by its relationships.
A Special Note on the Steel Plant Context
There is a dynamic in steel plant implementations that makes the relationship trap particularly acute, and it deserves direct acknowledgment.
Steel plants are communities as much as they are industrial facilities. The same people have often worked together for years or decades. There are established hierarchies, long-standing personal relationships, and a deep cultural norm of solving problems through conversation and mutual accommodation rather than formal process.
This is, in many ways, a strength. The informal network of a steel plant is genuinely efficient. A phone call between the right two people can resolve in ten minutes what a formal process might take six weeks to address. The institutional knowledge held by long-serving plant personnel is irreplaceable and is often best accessed through relationships rather than documentation.
But this cultural strength becomes a project governance weakness when it bleeds into the implementation programme. A PM who has been on site for six months and has built strong relationships with plant department heads may find it natural to handle scope changes through conversations rather than change requests, to agree workarounds over tea rather than documenting them as formal decisions, and to treat the programme as an extension of the plant’s informal problem-solving culture.
The plant’s informal culture works because the same people who make informal decisions are also the people who implement them and live with the consequences. The programme’s governance structure is different: decisions made informally in year one of the programme may need to be explained to new committee members in year two, justified to auditors in year three, and defended in commercial disputes in year four.
The programme cannot afford to be governed the way the plant floor is managed. The plant floor culture is a stable system. The programme is a time-limited construct with a beginning, an end, and a succession of people who pass through it, each of whom needs to be able to understand what the ones before them decided and why.
Tips for Project Managers: How to Avoid the Trap
One: Treat every informal scope conversation as a change request trigger, without exception.
The rule needs to be absolute because the exceptions will eat the rule. If the PM allows herself to assess whether a scope change is “big enough” to warrant a change request, she will systematically underestimate size in the direction that favours her relationship with the person requesting the change.
The rule is simpler and more defensible: every change to scope, regardless of size, is documented. Small changes get a lightweight change record. Large changes get a full change request with impact assessment. But every change gets something written down, with an owner, a date, and a decision.
This is not bureaucracy. It is the minimum record required to defend the programme when the people who agreed to the change are no longer available to confirm it.
Two: Reforecasts require documented assumption changes.
Every time the budget forecast changes, the assumptions that drove the change must be written down. Not “scope optimisation” as a category. The specific scope that was reduced, why it was reduced, what risk the reduction creates, and who made the decision.
This discipline serves two purposes. It creates a record that protects the PM when the scope reduction later has consequences. And it forces the PM to articulate the risk of the reduction explicitly, which sometimes leads to the conclusion that the reduction should not be made and the honest escalation should happen instead.
Three: Change “being monitored” to “escalation pending” when a vendor misses two consecutive commitments.
The RAID register entry “In Progress” with a vendor update note is not a risk management action. It is a note. The transition from note to action is the transition from monitoring to escalating.
The rule: two consecutive missed vendor commitments on any item triggers an automatic change of status to Amber and an automatic escalation to the steering committee. The PM does not assess whether the situation is serious enough to warrant this. The rule makes that assessment for her, removing the bias that produced the comfortable Green in the first place.
Four: Write down every verbal agreement on the same day it is made.
In a steel plant environment where so much is handled conversationally, the practice of writing down verbal agreements immediately is a cultural adaptation that requires conscious effort.
The format does not need to be complex. An email to the person who made the verbal agreement, summarising what was agreed, sent the same day, and asking for a reply confirming the summary is accurate, is sufficient. If the agreement is significant, it should be documented as a formal decision in the next steering meeting minutes.
This practice protects both parties. The PM has a record. The committee member or sponsor has been given the opportunity to correct a misunderstanding before it becomes a dispute. Both are better off with the record than without it.
Let this sink in: What is written today is tomorrow’s armour.
Five: Build your professional reputation on the record, not the relationship.
This is a reframing that takes time to internalise, but it is the one that matters most over a career.
The PM who is known for her strong relationships with sponsors and committee members is well regarded. The PM who is known for running programmes that can be audited, handed over, or recovered under any personnel scenario is invaluable. The first reputation is contingent on the specific people who hold it. The second belongs to the PM regardless of who she works with.
Tips for Steering Committee Members: How to See the Trap Before It Closes
One: Ask for the change request log in the first month, and audit it quarterly.
A steering committee that never asks to see the change request log is a committee that has no visibility of scope evolution. The change request log is not just an administrative artefact. It is the record of every formal decision about what the programme is and is not trying to do.
An audit of the change log every quarter answers three questions: is scope growing, by how much, and through what process is it being approved? If scope is growing without change requests, the programme is being managed informally and the committee is not governing scope.
Two: Ask the PM to name the three risks she is most concerned about that are not currently Amber on the dashboard.
This question cannot be answered safely with a managed response. If the PM says “there are no significant risks below the Amber threshold,” the committee should probe further. In a complex steel plant implementation, there are always concerns that have not yet reached the formal escalation threshold.
The question invites the PM to speak candidly about the project’s sub-threshold concerns, which is where the early warning signals almost always live. A PM who gives a thoughtful, specific answer to this question is a PM who is genuinely managing. A PM who deflects it with reassurance is a PM who may be managing her reporting instead.
Three: When a long-serving committee member leaves, commission a programme health check.
Personnel change in the steering committee is a natural trigger for a structured review of programme status, not because the departing member was dishonest, but because any governance arrangement that has operated for an extended period needs to be validated when the people who operated it change.
A programme health check at the point of committee turnover is not an expression of distrust. It is a standard governance hygiene measure that protects the incoming committee member, the outgoing one, and the programme itself. It establishes a clean baseline for the new governance arrangement and surfaces any informal agreements or undocumented decisions that need to be brought into the formal record.
This practice, if normalised, also changes the PM’s behaviour prospectively. A PM who knows that committee turnovers trigger health checks has a strong incentive to maintain a clean formal record throughout, because she knows the informal record will be examined whenever the governance structure changes.
Four: Create a formal channel for scope requests from the business.
One of the most effective structural interventions a steering committee can make is to establish a clear, visible, low-friction process for the business to raise scope requests formally. If the formal channel is easier to use than the informal corridor conversation, the formal channel will be used.
This reduces the PM’s exposure to the informal scope conversation problem by changing the cultural norm around how changes are requested. When the business knows that scope requests go through a defined process, the expectation of informal absorption diminishes. The PM is no longer the first point of contact for scope changes. The governance process is.
The Final Point
The trap that feels like safety is not a character failing. It is a rational response to a feedback loop that rewards smooth performance and defers the cost of the underlying problems.
The way out of the trap is not willpower or ethics, though both help. It is architecture. A programme that has clear RAG definitions, a live change request process, an active RAID escalation discipline, and a documented assumption record has removed the structural conditions that make managed optimism the path of least resistance.
In that programme, the honest report is also the easy report. The change request is also the self-protective act. The escalation is also the professionally safe choice.
That is the governance environment worth building. Not because it is more comfortable, but because it is the only one that survives the thing that every large programme eventually encounters: the moment when the people who built the informal arrangements are no longer in the room to honour them.
Final Advise: Build the record, the relationships will still matter. Just don’t rely on either alone.
Have you been the PM who discovered too late that the champion who approved the informal scope change was no longer around to confirm it? Or the committee member who inherited a programme held together by conversations that nobody wrote down? The comments are open, and this one I suspect has more stories behind it than most.
#ProjectManagement #ProgrammeGovernance #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #SteeringCommittee #ChangeManagement #RiskManagement #HonestLeadership #DigitalTransformation #IndianManufacturing #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.