Otherside - The View Nobody Talks About
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
The Trap That Feels Like Safety
Why Scale Changes Everything and Why Your Dashboard Lies at a Different Altitude
Let me start with the person nobody talks about.
When a programme crisis finally surfaces in a steering committee meeting, there is a standard narrative about who suffers most. The PM who suppressed the problem, obviously. She is in the room, under scrutiny, trying to explain decisions that she cannot fully defend. The downstream workstream leads whose plans have been destroyed by a dependency they did not know had failed. The programme director who is holding the room together while simultaneously absorbing an impact assessment that seems to get worse with every slide.
These are the visible sufferers. Their pain is immediate, specific, and acknowledged. Everyone in the room knows where to look.
There is a fourth person whose specific disadvantage is almost never named.
She has been sitting in fortnightly steering reviews for the last six months. She has been reading Green status reports and accepting them at face value, because that is what you do when the programme is reporting Green and nothing is surfacing to contradict it. She has been making decisions, outside of this room, based on the picture of a programme that was performing.
She is the steering committee member. And she is, in a very specific and underappreciated way, the most disadvantaged person in the room.
Not because her position is the hardest personally. But because she has to do the hardest thing, under the worst conditions, with the least preparation.
The Four Things She Has to Do Simultaneously
Here is what I have never seen anyone try to articulate properly: when the crisis surfaces, the committee member has to process four distinct things at the same time. A normal human being cannot process four distinct things simultaneously without error. She has no choice.
The first thing: understand the content of the crisis.
What actually happened? What is the technical root cause? Which workstreams are affected? What is the current schedule impact? What options exist?
This is already a significant cognitive load. In a complex programme, the crisis is rarely simple. It has a root cause that requires explanation, a propagation path through the dependency network that requires mapping, and an impact assessment that is still being developed as the meeting progresses. The committee member is receiving all of this for the first time, in a room full of people who have been living with it for varying periods, and she is expected to absorb and act on it within the timeframe of a single meeting.
The second thing: recalibrate her entire mental model of the programme.
Every Green she accepted at face value in the last six months is now suspect. Not just the most recent one. Every one.
She told the board in last quarter’s update that the programme was on track. Was it? She told the client that the go-live date was confirmed. Should she have? She approved the decommissioning of a legacy system based on the assumption that the migration was proceeding as reported. Was that assumption valid?
The recalibration is not just about the immediate crisis. It is about every governance decision she has made since the suppression began. Each one needs to be assessed against the question: would I have decided differently if I had known what I know now?
Some of the answers will be uncomfortable. I am not sure there is any way to make this part less uncomfortable. It is the governance equivalent of discovering you have been given bad directions and have to figure out where that left you.
The third thing: make immediate decisions.
Resources need to be reallocated. Vendors need to be escalated. Clients need to be managed. The board may need to be briefed. External commitments may need to be renegotiated. Some of these decisions cannot wait for her to finish processing the first two things.
She is being asked to decide, under time pressure, on the basis of information she has just received, about a situation she has just discovered, with implications she has not yet fully understood.
This is not a description of good decision-making conditions. This is a description of what happens when the governance compact has been broken, and somebody else is paying the price.
The fourth thing: hold the question that does not go away.
After the immediate crisis is managed, after the decisions are made, after the room clears and the recovery plan is in motion, one question remains. It follows the committee member out of the room and into every subsequent interaction with the programme.
What else does she not know?
This question is the most damaging legacy of a suppressed escalation. It does not resolve when the crisis resolves. It recolours every subsequent status report. Every smooth meeting starts to feel like a performance she is not equipped to evaluate.
The committee member who has been burned once by a managed dashboard does not become paranoid. She becomes precise. She asks different questions. She probes where she previously accepted. She requests verification where she previously relied on assertion.
She does not become harder to work with because she has become unreasonable. She becomes harder to satisfy because she has learned, at cost, that the information environment she was operating in was not reliable. That is a lesson she is not going to unlearn.
The Specific Conditions That Make This Worse in Steel Plant Programmes
In a financial services or retail programme, a steering committee member who discovers the programme was not what it appeared faces a significant governance challenge.
In a steel plant ERP, MES, or APS programme, the same discovery carries additional dimensions that make it considerably more complicated. I say this not to be dramatic about steel, but because most governance writing treats the programme context as interchangeable. It is not.
The operational consequences are immediate and physical.
A steel plant does not have a pause button. When a programme crisis surfaces in a steering committee review for a steel plant MES implementation, the consequences are not abstract. The hot strip mill is rolling steel today. The blast furnace is tapping iron today. The continuous caster is casting slabs today.
If the MES that was supposed to go live in four months is now going live in ten, the plant operations team has been planning its entire production campaign around a go-live date that no longer exists. Crew rotation plans, training schedules, maintenance windows, production commitments to downstream customers: all of these have been structured around an assumption that is now wrong.
The steering committee member who chairs the crisis meeting is not just managing a programme schedule. She is managing the operational consequences of a changed timeline on a facility that is running continuously and cannot simply pause while the programme sorts itself out.
The vendor and partner ecosystem is small and interconnected.
Steel plant automation, MES, and ERP vendors operate in a community that is smaller than most people outside the industry realise. The same vendors appear on multiple projects across multiple plants. Relationships between client organisations and vendor teams are long-standing, commercially significant, and professionally visible.
When a steering committee member escalates a vendor failure in a steel plant programme, she is not just managing a single contract. She is potentially affecting a commercial relationship that spans multiple projects, multiple plants, and multiple years. The escalation needs to be calibrated carefully: forceful enough to produce the required response, measured enough not to damage a relationship the organisation will need for the next implementation and the one after that.
This calibration is hard to make under time pressure, in a crisis meeting, on information that has just been received. It is much easier to make three months earlier, when the vendor risk was first identified and the committee had time to engage thoughtfully before the situation became adversarial.
The plant’s leadership team has a different relationship with time.
Steel plant leaders operate on the timescale of production campaigns, furnace relining cycles, and annual maintenance shutdowns. A six-month programme delay does not feel to a plant leader the way it feels to a software programme director.
It feels like a missed blast furnace campaign. It feels like a production year with two different operating systems running in parallel. It feels like training cycles that clash with peak production periods.
The steering committee member who has to explain a programme delay to the plant’s leadership team is not explaining a schedule adjustment. She is explaining an operational disruption that will cascade through the plant’s production planning in ways that have real financial and operational consequences well beyond the programme’s own cost impact.
A Story Without Names: The Regulatory Programme That Made Three Wrong Decisions
There is a type of programme that concentrates the steering committee member’s specific disadvantage to its most extreme form: the regulatory compliance programme with a statutory deadline.
In a regulatory programme, the committee member is not just governing a delivery. She is governing a legal obligation. The deadline is not negotiable. The scope is not optional. The compliance standard is set by an external authority that does not have sympathy for implementation challenges.
I am going to describe a situation that is recognisable to anyone who has worked in financial services, manufacturing compliance, or any regulated industry. I have changed no names because I have used no names.
A large programme is implementing enhanced compliance requirements mandated by a new regulatory framework. Statutory deadline. Non-negotiable scope. The steering committee includes the Chief Risk Officer, the Chief Compliance Officer, the Chief Operating Officer, and an independent non-executive director with deep regulatory experience.
Fourteen months into the programme, the data workstream surfaces an issue. A significant population of existing accounts is missing the enhanced compliance fields required by the new regulation. The accounts were created before the regulation came into force. The legacy system does not have the fields. A retrospective data collection exercise is required.
The data workstream lead had known about this for six weeks. She had been assessing the scale of the population, working with the data team to understand the full extent of the gap, designing a remediation approach she could present alongside the problem when she finally escalated.
She surfaces it at week sixty-two of the programme.
The Chief Risk Officer’s response is immediate. She asks three questions, without pausing between them.
“When did you know this?”
“Why are we hearing it now rather than six weeks ago?”
“What decisions have we made in the last six weeks that this information should have informed?”
The third question is the one that defines the situation.
During those six weeks, the steering committee had made three significant governance decisions.
First, the committee had approved a communications plan for account holders describing the programme’s compliance approach and timeline. The plan had already been distributed to the organisation’s relationship managers. It described the retrospective population as a small and quickly addressed residual group.
Second, the committee had submitted a programme update to the regulatory supervisor describing the retrospective population as a small number of edge cases that would be addressed before the statutory deadline. This submission was now, in light of the actual population size, significantly inaccurate. The question of whether it constituted a material misrepresentation in a regulatory communication needed to be answered urgently and carefully.
Third, the committee had approved the decommissioning timeline for the legacy onboarding system, the system that held the original account onboarding data needed for the retrospective exercise. The decommissioning was already underway.
Three governance decisions, each made in good faith, each now requiring unwinding or renegotiation, because the committee did not have the information it needed when it made them.
The direct consequence for the data workstream lead was significant. The institutional consequences were worse. A statutory deadline that now carried genuine uncertainty. A regulatory relationship that required careful management to correct a potentially inaccurate submission. A committee that spent the remaining programme duration in a state of elevated scrutiny that consumed governance bandwidth and created an atmosphere of distrust that made every subsequent conversation harder than it needed to be.
And the Chief Risk Officer spent six months governing a programme in which every status update she received was filtered through the knowledge that the information environment had failed her once and might be failing her again.
That is the governance tax of a single suppressed escalation. It is paid not just in the crisis itself but in every governance interaction that follows it.
The Three Wrong Decisions: What This Looks Like in a Steel Plant Programme
The financial services example illustrates the pattern. The steel plant version is worth walking through separately, because the mechanism is the same but the texture is different.
Consider a steel plant running an MES go-live programme for its steelmaking and continuous casting operations. Month sixteen of a planned twenty-four month delivery. The steering committee includes the VP of Operations, the VP of Technology, the CFO, and the Chief Supply Chain Officer.
Two months earlier, in month fourteen, the MES steelmaking workstream lead had identified that the heat scheduling module’s integration with SAP production order management was producing sequencing recommendations that the steelmaking operators found impractical. The recommended heat sequences violated the plant’s established grade transition protocols in roughly one in five scheduling scenarios. The root cause was a gap between the grade transition matrix in the MES configuration and the actual metallurgical constraints as understood by the plant’s steelmaking team.
The workstream lead had been working with the MES vendor’s configuration team to address the gap. Progress was slow. The vendor’s configuration lead who understood the steelmaking constraints had been partially diverted to another client. The workstream lead kept reporting Green, because she believed the gap would be closed before the go-live window.
Looking back at situations like this one, what I find striking is how reasonable that belief probably felt. She was not lying. She was managing. The distinction matters, and so does the cost of it.
In months fourteen, fifteen, and sixteen, the steering committee made three decisions based on the assumption that the MES steelmaking integration was on track.
The VP of Operations approved a communication to the steelmaking crew about the MES go-live date, the new operating procedures, and the training schedule for the transition period. The communication went to three hundred people.
The Chief Supply Chain Officer confirmed the go-live date to three downstream customers who had been waiting for the improved delivery accuracy that the MES scheduling was expected to provide. One customer had restructured its own inventory planning around that date.
The CFO approved the reduction of the parallel run period from six weeks to three weeks, based on the programme director’s confidence assessment that the MES was performing well in testing. The parallel run reduction saved the programme significant cost.
In month seventeen, integration testing for the heat scheduling module produced results that the steelmaking operators immediately rejected as operationally implausible. The grade transition gap had not been resolved. The simplified matrix implemented as an interim measure was not adequate for the plant’s actual operating complexity.
The go-live date, communicated to three hundred employees, confirmed to three customers, used as the basis for the parallel run reduction, was now six months away at the earliest.
The VP of Operations had to recall a go-live communication that had been in the hands of three hundred people for three months. The Chief Supply Chain Officer had to call three customers and explain that a commitment made on the basis of programme information had turned out to be wrong. The CFO had to reverse a parallel run reduction decision and reinstate a cost that had already been removed from the programme budget.
What Experienced Committee Members Learn to Read
The steering committee member who has been through this experience once does not simply become more suspicious. She develops something more specific: a vocabulary of signal patterns that she reads in programme reviews with an attention she did not have before she needed it.
I want to be careful here. None of these signals is conclusive in isolation. Each one has an innocent explanation. But each one is worth naming, because naming them is how a committee member moves from pattern recognition to a question that actually produces useful information.
The workstream that is always on schedule but never ahead of it.
In any programme of genuine complexity, plans are imperfect. Some tasks take longer than expected. Some tasks complete faster. The natural variation of a real programme produces workstreams that occasionally have float and occasionally have pressure.
A workstream that is always precisely on schedule, never a day ahead and never a day behind, has not been executed to the plan. It has been reported to it. The precision is not evidence of excellent delivery. It is evidence of reporting calibrated to the plan.
A committee member who notices this should ask: show me the last three tasks that completed early and what we did with the float. If there are no tasks that completed early, the question becomes: is this programme executing with perfect precision, or is the reporting being calibrated?
The risk register that closes risks before the mitigation is visibly complete.
Risks close when the mitigation has been executed and the residual risk is at an acceptable level. They do not close when the mitigation plan has been written, when the vendor has committed to a resolution, or when the workstream lead believes the situation is improving.
A risk register that closes items at the plan stage rather than the completion stage is a register that has been curated for appearance.
In steel plant implementations, this pattern appears frequently around vendor commitments. The vendor commits to a resolution. The risk is closed. The resolution does not fully materialise. But the register shows it closed, which contributes to a Green dashboard that no longer accurately represents the programme’s risk profile.
Dependency descriptions that use process language rather than delivery language.
There is a specific linguistic difference between programme reviews that are being managed and programme reviews that are being reported honestly.
Process language: “Coordination is ongoing between the data migration workstream and the integration workstream on the material master extract.” “The MES and SAP interface alignment is being progressed through the joint technical working group.” “The vendor resolution is expected to be confirmed in the coming period.”
Delivery language: “The data migration workstream will deliver the material master extract to the integration workstream by the fourteenth. If that date is missed, the integration workstream’s unit testing window moves from month thirteen to month fourteen, which affects the system integration test start date.”
Process language describes activity. Delivery language describes commitment, dependency, and consequence.
A programme review that consistently uses process language and avoids delivery language is a review in which the real delivery commitments are not being surfaced. The committee member who notices this should ask: can you give me a specific date, a specific deliverable, and a specific consequence if that deliverable is not met on that date? If the answer is another process description, probe further.
The programme manager who has an answer for every question before it is fully asked.
This is the most counterintuitive signal, because preparation and fluency look like competence, and they often are competence. A good programme manager is well prepared. She has thought about the questions the committee is likely to ask and has answers ready.
But there is a texture difference between a programme manager who has thought deeply about her programme and a programme manager who has rehearsed her answers specifically to manage the committee’s impression. I am not sure I can fully articulate that texture. It is partly about the quality of uncertainty in the answers, which I will try to describe.
The programme manager who has thought deeply about her programme is occasionally uncertain. There are things she does not know yet. There are questions whose answers she has not worked through completely. She says so. She commits to finding out. She follows up.
The programme manager who is managing the committee’s impression has an answer for everything, including things that, in a programme of genuine complexity, should not yet have a clean answer.
The question that does not have a prepared answer: what is the thing you are most uncertain about in this programme right now? What is the risk you are watching most closely that has not yet reached the formal escalation threshold?
These questions require genuine reflection. The quality of the answer is itself information.
Tips for Steering Committee Members: How to Govern From the Disadvantaged Position
One: When a crisis surfaces, ask the third question first.
The Chief Risk Officer’s three questions are the right ones. But the sequence matters.
Most committee members instinctively ask the first question first: “when did you know this?” This is natural, but it creates an adversarial dynamic immediately, which closes down the room before the most important question can be answered well.
Consider inverting the sequence. Ask the third question first: “what decisions have we made in the last period that this information should have informed?” This question focuses the room on the governance consequence, not the personal accountability. It produces the most important information immediately. And it establishes that the committee’s primary concern is the programme’s integrity, not the workstream lead’s culpability.
The first and second questions can be asked afterward, in a separate session if necessary. The third question needs to be answered now.
Two: Commission a “decision audit” after any significant crisis.
A decision audit is a structured review of the governance decisions made during the suppression period, assessed against the information that was available versus the information that was not. It identifies which decisions would have been made differently, which decisions need to be unwound, and which external commitments need to be renegotiated.
The decision audit is not about assigning blame. It is about understanding the full cost of the information failure, including the costs embedded in decisions already made rather than in work still to be done.
In the regulatory programme example, the decision audit would have identified the three consequential decisions immediately and prioritised the regulatory submission correction above the others because of its statutory implications. Without the audit, these decisions might have been addressed in the order they surfaced, rather than in the order of their actual urgency.
Three: Create a standing agenda item called “what are we uncertain about?”
This is a simple structural change to the steering committee agenda that produces a disproportionate return in information quality.
At the end of every programme review, before the close, ask the programme director and the assembled workstream leads: what is the thing you are most uncertain about on this programme right now that has not appeared in today’s formal reporting?
This question creates a legitimate channel for the sub-threshold concerns that live in the space between formal escalation and confident management. It is not an invitation to dump every worry on the committee. It is an invitation to name the thing being watched most closely that has not yet resolved into a formal RAID item.
In steel plant implementations, this question frequently surfaces the vendor resource concerns, the instrument calibration issues, and the interface specification divergences that are the typical origins of cascades, before those origins have developed into triggers.
Four: Develop the habit of reading the dependency language, not just the status field.
Before each programme review, read not just the RAG statuses but the dependency descriptions. Look for process language where delivery language should be. Look for dependencies described as “ongoing” or “being progressed” without dates, owners, and consequences.
Mark the ones that use process language and ask for them to be translated into delivery language in the meeting. Not because process language is always dishonest, but because delivery language reveals the actual state of a dependency in a way that process language does not.
A committee that consistently asks for delivery language in its dependency reporting will, over time, receive delivery language as the default. And delivery language is the format in which programme risks are most clearly visible.
Five: When the programme is smooth, probe harder, not less.
The experienced committee member’s disposition is the reverse of the novice’s. The novice relaxes when the dashboard is Green. The experienced member looks more carefully.
Not because she is cynical about the programme or the delivery team. She does it because she has learned, at cost, that smooth periods in complex programmes are either the result of excellent delivery or the result of effective impression management, and that the dashboard alone does not tell her which.
The way to distinguish the two is to ask questions whose answers would be the same in both cases if delivery is genuinely on track, but different if it is not. The questions about uncertainty. The questions about what the simulation is not simulating. The questions about vendor resources and instrument calibration and interface specifications.
If the answers are consistently specific, honest, and occasionally uncertain, the smooth period is probably real. If the answers are consistently fluent, confident, and complete, probe further.
Tips for Project Managers: How Not to Put Your Committee Member in This Position
One: Before you decide to manage something internally, imagine the Chief Risk Officer asking the third question.
The question is: “what decisions have we made in the last period that this information should have informed?”
If the answer is “several important ones,” you are past the point where internal management is appropriate. The committee needs to know, not because the crisis has arrived, but because the governance decisions being made without your information are building an obligation that will need to be unwound later, at greater cost, with greater difficulty.
This is not about burdening the committee with your assessment process. It is about ensuring that governance decisions are made with the information they require.
Two: When you escalate, include the governance implications, not just the operational ones.
Most escalations describe the operational impact: schedule delay, cost increase, resource requirement. The governance implication is different. Which decisions that the committee has made or is about to make are affected by this information?
Including the governance implication in your escalation is the single most effective way to ensure the committee understands why the timing of the escalation matters. “I am surfacing this now because the committee is scheduled to approve the client communication plan next week, and this information is material to that decision” is more compelling than “I am surfacing this now because it has reached the formal escalation threshold.”
Three: Distinguish between the assessment period and the suppression period.
A brief, time-bounded assessment period before escalating is legitimate. The workstream lead who takes forty-eight hours to understand the shape of a risk before surfacing it is being professionally responsible.
The workstream lead who takes six weeks to assess a risk while the committee makes decisions that depend on it is not assessing. She is deferring.
Set yourself an assessment deadline. If you have not completed your assessment of a risk within two weeks, surface what you know, acknowledge what you do not yet know, and let the committee decide whether they want the programme to continue while the assessment completes.
The Final Point
The steering committee member on the other side of the table is not the most powerful person in the programme crisis. She is the most disadvantaged.
She has been given the hardest task: to make consequential decisions, under time pressure, on information she has just received, about a situation she did not know existed, with implications that are still unfolding. She has to do this while simultaneously recalibrating her understanding of a programme she thought she was governing effectively.
And she has to do it knowing that some of the decisions she made before this crisis, in good faith, with the information she was given, may now need to be unwound. That the board briefing she gave last quarter may have been inaccurate. That the client commitment her organisation made may need to be renegotiated. That the regulatory submission from two months ago may need to be corrected.
None of this was necessary. All of it was produced by a single decision, made by someone in a workstream, at the origin event, to manage the problem internally rather than surface it.
The committee member is paying the price of that decision in the hardest currency available: her credibility with the board, her organisation’s relationship with the client and the regulator, and six months of elevated scrutiny that follows every committee member who has been governed on bad information.
She is also, from this moment forward, a significantly better committee member. Because she knows something she did not know before: that the smooth meeting is the one to watch, that the fluent answer is the one to probe, and that the question worth asking is not “how is the programme performing?” but “what does the programme not yet know that it needs to know?”
From the other side of the table, you see what cannot be seen from this side. But only after you have sat there long enough to learn where to look.
Have you been the committee member who discovered, mid-meeting, that the programme you thought you were governing was not the programme that actually existed? Or the PM who finally understood what the third question cost the person asking it? The comments are where this conversation belongs.
#ProgrammeGovernance #SteeringCommittee #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #RiskManagement #HonestLeadership #DeliveryExcellence #DigitalTransformation #IndianManufacturing #ExecutiveLeadership #ProgrammeManagement
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.