Fear Factor — When the Committee Makes Fear the Rational Choice
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
The Cascade Nobody Saw Coming
Otherside - The View Nobody Talks About
When the Committee Turns Over and the Programme Pays the Price
This article series has spent seven parts being critical of project managers who filter information upward.
That criticism is warranted. The cost of suppression is real, the cascade mechanics are real, the personnel trap is real, and the view from the committee’s side of the table when the fiction finally surfaces is genuinely difficult. All of that belongs in the account.
But the account is incomplete without examining one more thing. The thing that most governance frameworks do not discuss, because it is uncomfortable for the people who design governance frameworks, and because those people are usually the same people who sit on steering committees.
The thing is this: the information environment a steering committee receives is not solely a function of the delivery team’s honesty. It is also, significantly and demonstrably, a function of what the committee does when it receives honest information.
Or more precisely: the answer you get depends on what happened the last time someone gave you a real answer.
The Environment Is Not Neutral
Governance environments produce behaviours. This is not a philosophical claim. It is an observable fact in every large programme that has been studied with any seriousness.
The behaviours a governance environment produces are shaped by the signals it sends. And the most powerful signal any governance environment can send is not its formal policy on escalation thresholds, not its RAG definitions, not its RAID register templates, and not its change control process.
The most powerful signal is what happens in the room when a project manager walks into a steering committee meeting and puts an Amber on the table.
Everything that follows from that moment is training. For every workstream lead who was in the room when it happened. For every PM who heard about it afterward. For the programme culture that is built, one steering meeting at a time, from the accumulated experience of what honest escalation produces.
If what it produces is intervention, the culture learns to escalate early.
If what it produces is interrogation, the culture learns to manage internally until management is no longer possible.
The Two Rooms
There are two recognisably different types of steering committee in large programmes. They do not advertise which type they are. They reveal it in the fifteen minutes after the first Amber escalation of the programme.
The first room receives an Amber escalation and responds with a question: “What do you need from us?”
The committee chair thanks the workstream lead for the early flag. Not perfunctorily, not as a formality, but visibly and specifically: “Thank you for bringing this to us while we still have options.” The committee works through the options that the PM has presented. A decision is made in the meeting. Action items are assigned to named committee members with completion dates. In the next fortnightly review, the committee chair opens with a follow-up on those action items, not to create accountability for the PM but to confirm that the committee’s own commitments have been met.
The PM who surfaced the risk is seen, by every workstream lead in the room, to have been helped rather than harmed by the act of escalating.
The second room receives an Amber escalation and responds with questions of a different kind. “How did this arise?” “Who is responsible for this?” “Why was this not prevented?” “Can you give us a written root cause analysis by next week?”
The meeting overruns. The committee does not make a decision about what to do next, because it is still establishing how this happened. The PM who raised the Amber leaves the room having answered more questions about the past than questions about the future, with a written root cause analysis assigned as homework, and with a clear sense that surfacing the risk was professionally costly.
In the next fortnightly review, the same risk is still open. The committee asks why it has not been resolved. The PM has been working on the root cause analysis. She has not been working on the resolution, because the committee did not give her a decision to work from.
Every workstream lead who was in the room for that meeting has received a signal that they will act on, rationally, in the next reporting cycle.
The Steel Plant Dimension: Why This Dynamic Has Extra Consequences Here
In a generic software programme, the governance environment’s effect on information flow is costly. In a steel plant ERP, MES, or APS programme, the same dynamic carries three additional dimensions. I want to name each of them explicitly, because they tend to get treated as background context when they are actually foreground causes.
The programme team is often embedded in the plant’s culture, which has its own norms about surfacing problems upward.
Steel plant operational culture varies, but in many integrated steel plants, there is a deeply embedded norm that problems are solved at the level where they arise. A furnace operator does not escalate every process deviation to the plant manager. A shift supervisor handles most issues within the shift. The culture of local resolution is an operational strength: it keeps the plant running efficiently without burdening senior leadership with every minor deviation.
This cultural norm is appropriate for plant operations. It is counterproductive when it is carried into programme governance. A programme team that has been embedded in the plant for six months absorbs this norm. When a risk arises, the instinct is to resolve it at the level where it arose. When the governance environment reinforces that instinct by punishing escalation, the effect is amplified: the PM’s cultural conditioning and the committee’s behavioural signal are pointing in the same direction, away from early escalation and toward local management.
The committee that wants honest information from a programme team embedded in a steel plant culture needs to work harder against this dynamic than a committee in a generic office environment. The pull toward local resolution is stronger. The explicit reward for early escalation needs to be correspondingly more visible.
The vendor and implementation partner community is small and reputationally sensitive.
Steel plant implementation vendors and implementation partners operate in a community where reputation travels quickly. A PM who escalates a vendor performance issue to the steering committee in a well-structured way, gets a committee-level intervention, and manages the resolution professionally has demonstrated capability. A PM who escalates the same issue and is publicly questioned about why she did not prevent the vendor failure has been professionally marked in a context where the same people will encounter each other again on the next programme.
The long-term reputational effect of governance environments that punish escalation is not limited to the current programme. It shapes how programme professionals in the steel industry think about escalation as a career risk across multiple programmes and multiple clients. A culture that consistently punishes escalation does not just harm the current programme. It contributes to an industry norm where managed optimism is the professionally safe default.
The technical complexity provides natural cover for the committee’s blame response.
When an Amber is raised in a steel plant MES programme, the technical context is complex enough that the committee can always find a line of questioning that implicitly attributes the risk to the PM’s failure to anticipate, prevent, or manage it adequately. “Shouldn’t this have been identified in the design phase?” “Why didn’t the interface specification prevent this?” “Was this not in the risk register from the start?”
These questions are not necessarily unfair. But they are not productive in the moment when the committee should be making a decision about what to do next. And when they are the consistent response to Amber escalations, they teach the programme team to anticipate them and to prepare for them, either by having complete answers ready before escalating, which delays the escalation, or by not escalating at all.
The technical complexity of a steel plant programme is an asset for the committee that wants to ask good questions in the spirit of understanding. It is a liability for the committee that uses questions as a substitute for decisions.
A Tale of Two Programmes in the Same Organisation
The clearest way to understand the governance environment’s effect on information quality is to look at two programmes running simultaneously in the same organisation, with the same governance framework, the same contractual structure, and a meaningfully different committee culture.
This is not a hypothetical. It is a pattern that anyone who has worked across multiple programmes in the same organisation will recognise.
Programme A: The Room Where Escalation Was Rewarded
A large industrial organisation is running two simultaneous ERP implementations. Programme A covers the plant’s manufacturing and supply chain operations. Programme B covers its corporate finance and procurement functions. Both report to the same executive governance body at the portfolio level, but each has its own programme-level steering committee with a different chair.
Programme A’s steering committee is chaired by a VP who has a specific way of running steering meetings. When a workstream lead presents an Amber, the first question is always the same: “What do you need from us to move this forward?” Not what happened, not who is responsible, but what does the committee need to do right now.
When a significant risk is surfaced early and resolved through committee intervention, she notes it explicitly in the next review: “Last month the data migration lead surfaced a data quality risk early enough for us to bring in additional cleansing resources. We absorbed a two-week schedule impact instead of what would have been a ten-week impact. That is the governance structure working as designed.”
This is not a minor statement. It is a public, visible, explicit signal to every workstream lead in the room: surfacing risks early produces better outcomes for the programme and is professionally recognised as good practice.
Over twenty-four months, Programme A’s risk register shows a consistent pattern of early identification. Risks appear at the Amber level and are resolved at the Amber level through committee intervention. The average time between a risk being identified at the workstream level and appearing in the programme-level governance is eleven days. The programme experiences two events that could have become significant cascades. Both are contained because they were surfaced early enough for the committee to intervene effectively.
Programme A completes within three weeks of its planned go-live date, with a final cost within 4% of the approved budget.
Programme B: The Room Where Escalation Was Costly
Programme B is chaired by a director who runs steering meetings differently. His instinct when an Amber is presented is to understand it thoroughly before committing to a response. He asks detailed questions about how the risk arose, what should have been done to prevent it, and who in the workstream was responsible for the gap that produced it. He requests written root cause analyses for significant risks. He is thorough, intelligent, and genuinely trying to govern well.
The effect on the programme’s information environment is not what he intends.
By month six, the workstream leads have learned that presenting an Amber in Programme B’s steering meeting means spending forty minutes answering questions about the past rather than thirty minutes making decisions about the future. The root cause analysis assigned as homework consumes two days of the PM’s time. The committee leaves the meeting without having made a decision about the forward path. The risk is still open at the next review, and the PM is asked to update the root cause analysis.
The workstream leads begin managing risks internally for longer before escalating. Not all of them. Not all risks. But the threshold for what constitutes an escalation-worthy issue moves upward in response to the experienced cost of escalating.
The RAID register in Programme B shows an unusual pattern: risks that appear as Amber and resolve to Green within a single reporting period, with a note that the resolution was achieved through internal management or vendor coordination, and no documented committee intervention. This pattern repeats across multiple workstreams and multiple reporting periods.
Looking at this pattern now, what strikes me is how invisible it would have been to the Programme B chair in the moment. He was seeing resolutions. He was not seeing the risks that never reached him.
In month twenty-one, an integration testing failure exposes a data workstream issue that has been managed internally for eleven weeks. The issue affects four workstreams. The schedule impact is five months. In the post-mortem, the data workstream lead is asked directly: why was this not surfaced earlier? Her answer is specific and documented: “The previous experience of surfacing risks to the committee had not been productive. I believed I could manage it internally.”
She is not wrong about her experience. She is wrong about her ability to manage it internally. But the governance environment shaped the calculation she made, and the calculation she made produced the outcome the programme suffered.
Programme B completes seven months late and 31% over budget.
Same organisation. Same governance framework. Same contractual structure. Same portfolio-level oversight. Different committee behaviour. Different programme outcomes.
The Accountability and Blame Distinction That Changes Everything
The committee that produces Programme B’s outcome is not a bad committee. The chair is not a bad leader. He is making a governance error that is understandable, common, and very costly: he is conflating accountability with blame.
These are different things. Understanding the difference is the key to building a governance environment that produces honest information.
Accountability is the expectation that a PM will surface risks early, escalate honestly, and manage with transparency. It is about the forward-looking behaviour that the governance structure requires. It is about what the PM does with information when she has it.
Blame is the attribution of fault when something goes wrong. It is about the backward-looking question of who is responsible for the gap that produced the problem. It is about what the PM did or did not do before the information became available.
A committee that conflates these two things responds to every Amber as if it were evidence of PM failure. Why did this risk arise? Who is responsible? Why was it not prevented? These are blame questions. They are appropriate in a post-mortem. They are actively harmful in a governance review where the committee’s job is to make a decision about the forward path.
The PM who brings an Amber to a committee and faces blame questions is receiving a signal that the committee does not distinguish between the risk and the PM who surfaced it. She will respond rationally: next time, she will surface the risk later, when the resolution is further developed, when the root cause is better understood, when she has more complete answers to the questions she knows will be asked.
Later is always worse. Later always costs more. And the committee, by conflating accountability with blame, has caused the delay that will produce the worse outcome it is trying to prevent.
I find this one of the most frustrating dynamics in programme governance to witness, because the chair who produces it is usually the chair who cares most about rigour. The rigour is not the problem. The sequencing is.
What the Governance Environment Looks Like When It Is Working
The Programme A steering committee is not a committee that accepts poor performance or does not hold the programme to account. It holds the programme to account more effectively than Programme B’s committee, precisely because it has separated accountability from blame.
The accountability is clear and consistent: workstream leads are expected to surface risks early, structure their escalations, and come to the committee with options. This expectation is not written in a governance document. It is demonstrated in every review by the committee’s response to escalations: decisive, action-oriented, and supportive.
The blame question, when it is relevant, is handled separately. If a risk arises from a genuine failure of process or judgment, that is addressed after the committee has made the decision about how to resolve the risk, not instead of it. The post-mortem is a separate session, conducted in a spirit of learning rather than attribution, and its findings are used to improve the programme’s risk management processes, not to mark the PM who raised the issue.
This separation produces an environment where the PM who surfaces a risk early is experienced as a professional who is managing well, not a professional who is in trouble. And that experience, repeated consistently across the programme community, produces a culture where early escalation is the rational choice.
The Specific Governance Signals That Build the Right Environment
Building the governance environment that produces honest information is not a single decision. It is a cumulative pattern of signals, sent consistently, over time, in the details of how the committee behaves in each steering meeting.
The thank-you that is specific and public. When a workstream lead surfaces a risk early, the committee chair’s response should include a specific, public acknowledgment of the early flag. Not “thank you for the update” but “thank you for surfacing this in month seven rather than month ten. That decision gives us three additional months of options.” This specificity matters because it names exactly what was right about the behaviour, which tells every other workstream lead in the room precisely what they should replicate.
The decision that is made in the meeting. When an escalation is brought to the committee, the committee’s job is to make a decision. Not to ask for more information, not to request a root cause analysis, not to schedule a follow-up session. To make a decision about the forward path, with the information available in the room. If the information is insufficient for a decision, the committee commits to a specific date and a specific information requirement, and the decision is made on that date. The pattern of making decisions in meetings, rather than deferring them, signals to the programme team that escalating produces action rather than process.
The follow-up on committee commitments. When a committee member commits to an action, that commitment appears on the next meeting’s agenda and is followed up with the same rigour as any programme milestone. This signal is particularly powerful because it demonstrates that the governance compact runs in both directions: the committee holds the programme team accountable for their commitments, and the programme team can hold the committee accountable for theirs. Accountability is not directional.
The root cause question that is asked after the decision, not instead of it. Understanding why a risk arose is valuable. It improves the programme’s risk management and prevents similar risks from arising in other workstreams. But this understanding is pursued after the committee has made its decision about the forward path, not before. The sequencing matters: decision first, understanding second. The committee that consistently inverts this sequence is the committee that consistently receives late escalations.
The explicit norm-setting at programme inception. The most effective committee chairs name their expectations explicitly at the first steering meeting of the programme. Not in a governance document, but in the room, in conversation: “In this programme, I want to hear about risks early, while we still have options. I will always respond to an early escalation with a decision, not a debrief. I will not ask you to explain why a risk arose before we have agreed what to do about it. Bring me problems early. That is what I am here for.”
This statement, made once, in the first meeting, establishes a norm that shapes the programme’s information culture from day one. It costs nothing. Its return, over a twenty-four month programme, is the difference between Programme A and Programme B.
The Uncomfortable Conclusion for Committee Members
The most uncomfortable implication of everything in this section is this: a steering committee that consistently receives poor information has probably earned it.
Not through malice. Not through negligence. Through the accumulated signal of how it responds when good information is brought to it. Through the experience it has created for the PMs who escalated honestly and were interrogated rather than supported. Through the culture it has built, one meeting at a time, without ever intending to build it.
This is uncomfortable because it implies that the committee is not just a victim of filtered information. It is a participant in the production of filtered information. The filtering happens downstream, in workstreams and RAID registers and status reports. But the decision to filter is shaped upstream, by the committee’s behaviour in the moments when filtering would have been avoided by an honest escalation.
The governance compact runs in both directions.
The programme team owes the committee honest, timely, structured information. This is the obligation this series has examined in detail: the PM’s responsibility to surface risks early, to structure escalations clearly, to maintain RAG integrity, and to bring the committee problems while there are still options on the table.
The committee owes the programme team something in return: a response to that information that makes honest escalation the rational choice. A decision rather than a debrief. An intervention rather than an interrogation. A thank-you rather than a root cause analysis request. The distinction between accountability and blame, maintained consistently, in every meeting, across the life of the programme.
When both sides of the compact are honoured, the governance structure works as it was designed to work. Information flows upward honestly, decisions flow downward clearly, and the programme benefits from the compound effect of both.
When one side of the compact is not honoured, the other side adjusts rationally. Programme teams that face interrogation rather than intervention learn to bring only the information they have already resolved. Committees that receive only resolved information wonder why they are always finding out late.
Tips for Steering Committee Members: How to Build the Room Where Honesty Is Rational
One: Make the thank-you specific and public in the next meeting that receives an early escalation.
The first early escalation your programme receives is the most important governance moment of the entire programme. How you respond to it determines the information culture you will live with for the next two years.
Respond with a specific, public acknowledgment of the early flag. Name exactly what the workstream lead did right. Make a decision in the meeting. Follow up on the decision at the next review. Every other workstream lead in the room is watching and will draw conclusions from what they see.
This costs nothing. It produces an environment where early escalation is the norm rather than the exception. It is the highest-return governance investment available to a steering committee chair.
Two: Separate the forward decision from the backward inquiry in every escalation session.
When an escalation arrives, structure the meeting in two explicit phases. Phase one: the committee makes a decision about the forward path. What resources are needed? What escalations are required? What decisions need to be made today? Who owns what by when? Phase one ends when every action item has a name and a date.
Phase two, if it is needed at all: the committee’s questions about how the risk arose, what should have been done differently, and what process improvements are needed. Phase two can be deferred to a separate session if the forward decision has consumed the meeting’s time. Phase one cannot be deferred.
The PM who experiences this sequence learns that escalating produces action first and accountability second. The PM who experiences the reverse sequence learns that escalating produces accountability first and action maybe. These two experiences produce different programme cultures.
Three: Track your own action items with the same rigour as the programme’s milestones.
When you commit to an action in a steering meeting, it belongs in the meeting’s action log with your name, a specific deliverable, and a completion date. It appears on the next meeting’s agenda as a standing item. It is followed up.
This is not just good governance practice. It is a signal to the programme team that accountability runs in both directions. The committee that holds the programme team to its commitments while quietly dropping its own is a committee that has demonstrated it does not take the governance compact seriously. The committee that tracks its own commitments with the same rigour it applies to the programme’s is a committee that has demonstrated it does.
Four: Establish the norm explicitly at the first steering meeting of the programme.
Do not leave the programme team to infer what kind of committee you are from the pattern of your responses over the first six months. Tell them directly, in the first meeting: what you expect from them in terms of early escalation, what they can expect from you in terms of response, and how you will distinguish between the accountability question and the blame question.
This explicit norm-setting is the single highest-leverage governance action available to a committee chair at programme inception. It costs thirty seconds. It shapes the programme’s information culture from day one.
Five: When the programme has been consistently smooth for three months, convene a specific session to look for what the smoothness might be hiding.
A programme that has reported Green for twelve consecutive fortnightly reviews is either executing perfectly or managing its reporting. A committee that has been receiving twelve consecutive Green reports and is feeling comfortable is a committee that may be in the second situation.
Convene a specific session, roughly quarterly, that is explicitly designed to surface what the formal reporting might not be capturing. Not a crisis session. A learning session: what are the things we are most uncertain about on this programme that have not yet reached the formal escalation threshold? What would we need to see to be confident that the current Green picture is accurate?
The answers to these questions are the most valuable governance intelligence available. They live in the space between what the workstream leads are confident enough to report formally and what they are genuinely uncertain about. Getting to that space requires a governance environment where the questions can be answered honestly.
That environment is built one meeting at a time, from the first Amber escalation of the programme, by the committee’s response to honest information.
Tips for Project Managers: How to Operate in Both Types of Room
One: In a Programme A room, escalate earlier than you think you need to.
If you are in a governance environment that visibly rewards early escalation, the temptation is to escalate when you are comfortable with the completeness of your analysis. Resist this temptation. Escalate when you have enough information to describe the risk clearly and name what you need from the committee. The committee does not need your complete analysis. It needs your honest current picture.
The governance environment that supports early escalation is an asset. Use it earlier than feels comfortable. The earlier you use it, the more options the committee has and the better the outcome.
Two: In a Programme B room, escalate anyway, but structure the escalation more carefully.
If you are in a governance environment that has historically responded to Amber escalations with interrogation rather than intervention, you face a harder choice. The rational response to that environment is to manage internally longer. But the rational response is also the wrong response for the programme.
In a Programme B room, the answer is not to stop escalating. It is to structure the escalation more carefully, to give the committee less room to ask about the past before it has dealt with the present. Arrive with the root cause already described briefly, the options clearly laid out, and the specific decision request explicitly named. Make it harder for the committee to defer the decision than to make it.
This does not always work. But a well-structured escalation in a Programme B room is significantly more likely to produce a decision than an unstructured one.
Three: If you have evidence that the governance environment is producing filtering, name it to the programme director.
If you are aware that workstream leads in the programme are managing risks internally because of the experienced cost of escalating, this is information the programme director needs. Not as a complaint. As a governance risk.
Frame it as such: “I am observing a pattern where workstream leads are choosing to manage risks internally rather than escalating, because the experience of escalating has not produced the support they needed. I believe this represents a governance risk for the programme because it means problems are being surfaced late. I wanted to flag this directly.”
This is a difficult conversation. It is also a critical one, because the alternative is to watch the programme build toward a cascade that was produced by a governance environment nobody named until after the crisis.
The Final Point
The governance compact is not a document. It is not a policy. It is not a framework or a methodology or a set of escalation thresholds.
It is a set of mutual obligations, demonstrated in the behaviour of both parties, in every governance interaction, across the life of the programme.
The programme team’s obligation: surface risks early, structure escalations clearly, maintain the integrity of the RAG reporting, and bring problems to the committee while there are still options on the table.
The committee’s obligation: respond to that information with decisions rather than debriefs, interventions rather than interrogations, and a consistent, visible distinction between the accountability they have every right to expect and the blame that belongs in a separate conversation at a separate time.
When both sides honour these obligations, something important happens. The information environment becomes honest not because the programme team is unusually courageous or the committee is unusually enlightened, but because honesty is the rational choice for both parties. The PM who escalates early gets support and gets outcomes. The committee that responds with decisions gets information and gets governance.
The programme that achieves this alignment is not the programme that avoids problems. Problems are a feature of complex programmes in industrial environments. They arise from the inherent uncertainty of implementing sophisticated software in operationally complex settings.
The programme that achieves this alignment is the programme that finds its problems early, when they are still manageable, and responds to them with the authority of a committee that has been honestly informed and the capability of a delivery team that has been genuinely supported.
That is the governance compact working as it was designed to work.
Have you been the workstream lead who escalated honestly and was interrogated rather than supported, and then never made that mistake again? Or the committee chair who realised too late that the smooth reviews had been smooth for the wrong reasons? The comments are open, and this is the conversation that most governance discussions never quite reach.
#ProgrammeGovernance #SteeringCommittee #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #HonestLeadership #RiskManagement #DeliveryExcellence #IndianManufacturing #ProjectManagement #GovernanceCulture #ProgrammeManagement #AccountabilityVsBlame