When the Committee Turns Over and the Programme Pays the Price
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
There is a specific kind of professional humiliation that experienced programme directors describe in lowered voices.
It is not the humiliation of a public crisis, of being asked difficult questions in a steering meeting with the whole room watching. That is hard, but it is at least a shared experience. Everyone in the room knows what is happening. The difficulty is visible to all and owned by the group.
The humiliation being described is quieter and more personal. It is the experience of making a confident decision, on the basis of programme documentation that looked complete and a governance history that looked clean, and discovering two months later that the decision was wrong. Not because you failed to think carefully. Because the documentation was curated and the governance history was managed, and you had no way of knowing.
It is the experience of inheriting someone else’s fiction and presenting it to your own leadership as fact.
This is the personnel trap. And in large programmes, it is not an exceptional scenario. It is a structural feature of the environment.
The Gap Between Programme Lifespan and Governance Lifespan
Large programmes last a long time. A steel plant ERP implementation spanning finance, procurement, production planning, and maintenance typically runs twenty-four to thirty-six months. An integrated MES and APS implementation for a full production chain can run thirty to forty-eight months. A simultaneous ERP, MES, and APS transformation, which is not uncommon in large integrated steel plants undertaking a full digital modernisation, can run five to seven years.
Steering committees do not last this long with consistent membership. Executives move. Organisations restructure. The Chief Financial Officer who championed the ERP investment and personally attended every steering committee for the first eighteen months takes a group-level role and is replaced by a newly appointed CFO who has inherited the programme alongside a hundred other things she did not choose. The VP of Operations who understood the plant’s production constraints intimately and used that understanding to guide governance decisions retires and is replaced by a leader who comes from a different part of the business and has no prior exposure to the programme.
In a five-year programme, it is not unusual for the steering committee membership to turn over completely at least once and partially two or three times. The programme that began with one set of champions, one set of informal understandings, and one set of unwritten contextual knowledge will end with an entirely different set of people governing it.
This is not a governance failure. It is organisational life. Senior leaders change roles. Businesses restructure. People retire. None of this can be prevented, and none of it should be. The question is not whether the committee will turn over. The question is what the incoming committee member will find when she arrives.
If she finds a programme with a clean, complete, honest documentary record, she can govern it effectively from day one. She may not have the contextual knowledge of her predecessor, but she has the institutional record, and the institutional record tells her what decisions were made, why they were made, what they cost, what risks were identified, and what the programme currently looks like against the picture it was supposed to be.
If she finds a programme whose documentary record has been curated, she is in a different situation entirely. She is reading a history that has been edited. She is making decisions based on a representation of the programme that may not match its reality. And she will not know this until she makes a decision that exposes the gap.
What the Incoming Committee Member Actually Receives
When a new committee member joins a programme mid-delivery, she typically receives an onboarding package: the master programme schedule, the current RAID register, the last six to twelve months of steering committee minutes, the consolidated dashboard history, and a briefing from the programme director.
She reads these documents in good faith. She has no reason not to. They are the official record of the programme. They have been produced by professionals. They have been presented to, and in some cases approved by, her predecessor on the committee. They look authoritative.
What she cannot know, reading these documents, is what is not in them.
She cannot know about the scope addition that was agreed informally in a corridor conversation and absorbed into the baseline without a change request. The scope addition does not appear in the change log because there is no change request. It does not appear in the RAID register because it was not logged as a risk. It does not appear in the committee minutes because it was never raised in a committee meeting. It exists only in the memory of the people who agreed to it, and some of those people may no longer be in the programme.
She cannot know about the vendor risk that has been managed through a personal relationship between the programme director and the vendor’s account manager, without ever being formally logged or escalated. The vendor risk does not appear in the RAID register because the programme director preferred to handle it informally. It does not appear in the committee minutes because it was never brought to the committee. It exists only as a bilateral understanding between two individuals, one of whom may have changed roles.
She cannot know about the data migration issue that the workstream lead has been managing internally to avoid a third consecutive Amber on her workstream’s RAG status. The data migration issue does not appear in the programme-level RAID register because it was never escalated from the workstream register. It does not appear in the dashboard because the workstream is reporting Green. It exists only in the workstream lead’s own assessment, which may be more optimistic than the situation warrants.
The incoming committee member reads the documented programme. The documented programme is the curated programme. The real programme is different. She does not know how different. She will find out when she makes a decision that depends on an assumption that the real programme has already invalidated.
Three Steel Plant Scenarios Where the Personnel Trap Bites Hard
Scenario One: The Incoming CFO and the Budget That Was Already Spent
A large steel plant is twenty months into a thirty-month ERP implementation. The programme’s original budget was approved by the CFO who championed the investment. In month eighteen, that CFO moves to a group-level role. A new CFO joins the business in month twenty.
The new CFO’s programme onboarding includes a review of the budget status. The programme reports that it is tracking within budget, with a 6% contingency reserve remaining. The budget has been reforecast twice during the programme, with both reforecasts approved by the previous CFO. The documentation of the reforecasts describes the changes as “scope refinements” and “market rate adjustments for implementation resources.”
What the documentation does not describe is this: the first reforecast absorbed a significant scope addition, the additional customisation of the SAP PP module to handle the plant’s non-standard production order types, that was agreed informally between the programme director and the previous CFO without going through the programme’s change control process. The cost of this customisation was absorbed into the reforecast as a “scope refinement” without a separate change request that would have recorded the specific scope change, its cost, and the decision to proceed.
The second reforecast absorbed an extension of the implementation partner’s engagement by four months, driven by a delay in the data migration that had been managed internally without committee-level escalation. The extension was described as a “resource rate adjustment” in the reforecast documentation because the programme director did not want to surface the data migration delay that was its root cause.
The new CFO reviews the budget documentation, accepts the 6% contingency reserve as accurate, and approves a plan to use 3% of the remaining contingency to fund an additional training programme that the business is requesting.
In month twenty-three, the data migration delay surfaces when the go-live readiness assessment reveals that the legacy data cannot be loaded into the production environment within the planned cutover window. The cutover is postponed. An additional two months of implementation partner engagement is required.
The programme has no contingency remaining. The 6% contingency reserve was accurate as a percentage of the reforecast budget. It was not adequate as a buffer against the real programme risk profile, because the real programme risk profile had never been accurately represented to the committee.
The new CFO has to go to the board to request additional programme funding. The board asks why the contingency is exhausted when the programme was reported as tracking within budget at month twenty. She does not have a clean answer, because the documentation available to her does not tell the real story of how the budget was consumed.
Scenario Two: The New VP of Operations and the Go-Live That Was Already Wrong
An integrated steel plant is running an MES implementation for its hot rolling and finishing operations. The programme has been governed by a VP of Operations who has deep personal knowledge of the plant’s production constraints. She has been using that knowledge to guide the MES configuration informally, through direct conversations with the implementation team, rather than through the formal change control process.
Several of the MES configuration decisions that reflect this guidance are not documented in the formal design documents. They exist as working practices within the implementation team, understood by the team members who received the guidance but not captured in any document that a new team member or incoming committee member could read.
In month nineteen, the VP of Operations retires. A new VP joins from a different part of the organisation and takes over the governance role for the MES programme.
The new VP’s onboarding includes a review of the design documents. The design documents reflect the original configuration design, not the informally guided modifications. The new VP reads a programme that appears to be implementing a standard MES configuration. She approves the go-live plan on the basis of the design documents she has reviewed.
In month twenty-two, the MES goes live. Within the first week of operation, the rolling mill operators identify that the campaign scheduling logic is not behaving as expected in several specific scenarios involving grade transitions between high-carbon and low-carbon grades. The behaviour they are seeing does not match the design documents. It also does not match the informal guidance given by the previous VP, which was never documented.
The investigation reveals that the implementation team has been working from a combination of the formal design documents and the informal guidance, and that the informal guidance was not consistently applied because different team members received it at different times and interpreted it differently. The MES’s rolling campaign logic has three different versions of the grade transition rules embedded in different modules, none of which fully reflects either the formal specification or the informal guidance.
Resolving this requires a structured configuration review involving the rolling mill operators, the implementation team, and the MES vendor. It takes six weeks and requires a partial rollback of the live system to a stable baseline while the configuration is corrected.
The new VP of Operations is managing a go-live crisis that originated in governance decisions made before she joined the programme, executed through a process that produced no documentation she could have read, and manifested in a form that cannot be traced cleanly to any single decision or person.
Scenario Three: The Incoming Programme Sponsor and the Vendor That Was Already Failing
A steel plant is running an APS implementation programme. The programme sponsor, a director-level leader, has had a long personal relationship with the APS vendor’s regional account director. This relationship has been the primary channel through which vendor performance concerns have been managed throughout the programme. Issues have been raised and resolved through personal conversations between the two, without formal escalation, without formal vendor performance notices, and without any documentation in the programme’s governance record.
In month sixteen, the programme sponsor changes role. A new sponsor joins with no prior relationship with the APS vendor and no knowledge of the informal performance management history.
The new sponsor’s onboarding does not reveal the vendor performance history because it was never formally documented. The RAID register shows the vendor as delivering to plan. The dashboard shows the APS workstream as Green. The previous sponsor’s informal management of the relationship is invisible in the record.
In month seventeen, the APS vendor misses a significant milestone: the delivery of the heat-to-slab scheduling module’s configuration for the continuous caster. The miss is the fifth consecutive month in which the vendor has underdelivered against its commitments. The previous four misses were managed informally and absorbed through schedule adjustments that were not formally recorded as programme impacts.
The new sponsor has no context for this miss. She does not know it is the fifth in a sequence. She does not know the relationship history. She does not know what informal commitments the vendor’s regional account director made to her predecessor and whether those commitments were honoured.
She raises the miss formally, through the programme’s vendor management process. The vendor’s account team is surprised by the formal notice because they believed the relationship was still being managed informally. The relationship that the previous sponsor had built, which had been the primary tool for managing the vendor, is not available to the new sponsor because it was personal, not institutional.
The formal vendor management process, invoked without the context of the prior relationship history, takes three months to produce a resolution framework. During those three months, the vendor’s delivery continues to underperform because the informal management channel that had been providing at least some pressure is no longer active and the formal channel is still being established.
The go-live date moves by five months.
Why This Is a Governance Architecture Problem, Not a Personnel Problem
The personnel trap is frequently described as a consequence of inadequate knowledge transfer when committee members change. The solution, in this framing, is better onboarding: more comprehensive briefings, longer handover periods, more detailed documentation prepared at the point of transition.
Better onboarding helps. But it addresses the symptom rather than the cause.
The cause is that the programme’s governance record did not accurately reflect the programme’s real state in the first place. The incoming committee member’s problem is not that she was not briefed well enough. It is that the programme she was briefed on is not the programme that exists.
If the scope addition had been processed through a change request, the incoming committee member’s onboarding would have included it automatically. It would have been in the change log. She would have read it. She would have understood the scope, the cost, and the schedule impact before making any decisions.
If the vendor performance issue had been formally logged and escalated, it would have been in the RAID register. The incoming sponsor would have seen a vendor risk with a documented history. She would have understood the context before her first conversation with the vendor.
If the data migration risk had been escalated to the programme level, it would have been in the programme-level governance record. The incoming committee member would have known about it before approving the replan.
The incoming committee member’s vulnerability is not a function of her onboarding quality. It is a function of the governance record’s completeness. And the governance record’s completeness is determined not by what happens at the point of transition, but by what happened throughout the programme: in every steering meeting, in every RAID update, in every change request that was or was not raised.
The programme that is governed honestly throughout produces a record that any incoming committee member can read and trust. The programme that is governed through relationships and informal agreements produces a record that is incomplete at best and actively misleading at worst, and the incoming committee member has no way of knowing which she is reading.
The Specific Vulnerability of Long Steel Plant Programmes
Steel plant ERP and MES programmes have two characteristics that make the personnel trap particularly acute, and both are worth naming explicitly.
Steel plant programmes are long enough to outlast multiple committee generations.
A full digital transformation of an integrated steel plant, covering ERP, MES, APS, and the integration between them, is typically a five to seven year undertaking. In five to seven years, an organisation’s senior leadership can turn over completely. The CFO who approved the investment may not be the CFO who governs the go-live. The VP of Operations who understood the plant’s production constraints may retire before the MES goes live on the last production unit.
This is not unusual. It is the normal lifecycle of long programmes in industries where plant leadership tenures are measured in years rather than decades. The programme governance architecture must account for it by design, not hope that it will not happen.
Steel plant programmes involve domain knowledge that does not transfer easily.
The governance of a steel plant ERP or MES programme requires an understanding of the plant’s production constraints, metallurgical requirements, equipment characteristics, and operational rhythms that is not easy to acquire quickly. An incoming committee member from a financial or commercial background can read documents. She cannot, from documents alone, develop the intuition for whether a proposed MES configuration makes operational sense in a blast furnace context.
This domain knowledge gap creates a specific risk: the incoming committee member may approve decisions that a domain-knowledgeable predecessor would have questioned, not because she is less capable but because the documents she is reading do not contain the domain context that would enable her to ask the right questions.
The mitigation is not to keep the same committee member in place indefinitely. It is to ensure that domain knowledge is captured in the programme’s governance record in a form that is legible to a new committee member without prior domain exposure. This means design rationale documents that explain why specific configuration decisions were made in terms of operational requirements, not just technical specifications. It means vendor selection records that explain the commercial and operational reasoning behind vendor choices. It means risk register entries that connect technical risks to operational consequences in plain language.
I am not sure this is done well on most programmes. The honest answer is that most design rationale documents I have seen are written for the people who already understand the decision, not for the person who will need to understand it in eighteen months. That is a habit worth breaking.
The Institutional Record: What It Is and What It Is Not
The institutional record is not the programme’s archive. It is not the storage location for completed documents and closed meeting minutes. It is the living account of the programme’s governance, maintained continuously, with the specific purpose of enabling any new actor in the governance structure to understand what has happened, why it happened, and what the programme currently looks like against what it was supposed to be.
A complete institutional record includes:
A change log that records every change to scope, regardless of size, with the date, the originating request, the approver, the cost impact, and the schedule impact. Not “scope refinement” as a category. The specific scope that changed, and the specific decision that authorised it.
A RAID register that is updated at the workstream level and escalated to the programme level for any item with cross-workstream implications. Not managed locally and summarised globally. Escalated at the point of identification, with enough detail for the programme-level reader to understand the nature of the risk without needing to go back to the workstream lead for explanation.
Committee decision records that capture not just what was decided but why it was decided, what information was available at the time of the decision, and what assumptions the decision rested on. Not “the committee approved the go-live date” but “the committee approved the go-live date on the basis of the programme director’s confidence assessment that the MES steelmaking integration was on track. The confidence assessment was based on simulation testing results. Live data integration testing had not yet been performed.”
Vendor management records that capture the formal history of vendor performance, including commitments made and whether they were met, formal notices issued, and escalations to vendor account management. Not bilateral relationship management that exists only in the memories of the individuals involved.
This is not a large administrative burden if it is maintained continuously. It becomes a very large administrative burden when it is deferred and then attempted at the point of transition. That is the moment when everyone is busy, goodwill is stretched, and the departing committee member is already mentally halfway out of the door.
The programme that produces this record as a natural output of its governance process is the programme that survives personnel change with its governance integrity intact.
The programme that relies on briefings, knowledge transfer sessions, and retrospective documentation at the point of transition is the programme that sends each incoming committee member to govern a programme she does not fully understand, with a record that does not fully represent the programme she is governing.
Tips for Programme Teams: How to Build a Record That Survives
One: Write every governance decision as if the person reading it has no context.
The most common failure of programme documentation is that it assumes the reader knows the context in which the decision was made. “The committee approved the revised go-live date” is intelligible to someone who was in the room. It is not intelligible to someone who joins the programme six months later and wants to understand why the go-live date changed and what the programme’s confidence was at the time.
Write decisions with their context included: what information was available, what was not yet known, what assumptions were being made, and what the decision rested on. This takes slightly longer to write. It is worth significantly more as a governance record.
Two: When you have an informal conversation that produces a governance decision, document it the same day.
The informal conversation is not the problem. The absence of documentation is the problem. A corridor agreement about scope, a verbal approval of a budget adjustment, a personal understanding with a vendor account manager: all of these are legitimate governance events. They become liabilities only when they are not written down.
The practice of sending a same-day email that summarises what was agreed, who agreed it, and what the consequence is for the programme, is not bureaucracy. It is the minimum record required to ensure that the agreement exists beyond the memories of the people who made it.
Three: Treat vendor management as a formal governance activity, not a relationship activity.
Vendor relationships are valuable. They enable things that formal processes cannot enable: quick decisions, personal commitments, flexible problem solving. But they cannot substitute for a formal vendor management record, because the relationship exists between individuals and the record exists between organisations.
Every commitment a vendor makes should be documented. Every missed commitment should be recorded in the programme’s vendor management log. Every escalation to vendor account management should be confirmed in writing. This is not adversarial. It is the governance infrastructure that ensures the vendor management history is available to anyone who needs it, regardless of whether the individuals who built the relationship are still in their roles.
Four: Design the RAID register for the reader who does not know the programme.
The RAID register entry that says “MES-SAP interface alignment in progress, vendor coordination ongoing” is intelligible to the workstream lead who wrote it. It is not intelligible to a new programme director, an incoming committee member, or an external programme assurance reviewer who needs to understand the actual state of the risk.
Write RAID entries for the reader who has no context: what is the specific risk, what is its potential impact on the programme schedule and budget, what workstreams does it affect, what is being done to mitigate it, and what decision or action is needed from the committee. An entry that answers these five questions can be read and acted on by anyone. An entry that answers none of them is a reminder to the person who wrote it, not a governance record.
Five: Commission a governance health check at every significant committee transition.
When a senior committee member changes role, treat the transition as a trigger for a structured governance review. Not an onboarding briefing. A review: an independent assessment of the programme’s governance record against the programme’s real state, conducted before the incoming committee member makes her first significant governance decision.
The review does not need to be extensive. A two-day assessment by the programme’s assurance function or an independent reviewer, covering the change log, the RAID register, the budget history, and the vendor management record, will surface the gaps between the documented programme and the real programme before those gaps cause the incoming committee member to make a wrong decision.
This is not an expression of distrust in the programme team. It is a structural safeguard that protects the incoming committee member, the outgoing one, and the programme itself.
Tips for Incoming Committee Members: How to Govern a Programme You Did Not Start
One: Assume the document you are reading is incomplete. Not dishonest. Incomplete.
This is the right starting assumption for any incoming committee member joining a programme mid-delivery. The documentation is not necessarily wrong. But it is necessarily incomplete in ways that the person who produced it may not be aware of.
The incompleteness is not always the result of deliberate management. Some of it is the natural result of a programme team that has been focused on delivery rather than documentation. Some of it is the result of decisions made in formats that were not designed to produce a permanent record. Some of it is the result of context that was so obvious to the programme team that documenting it felt unnecessary.
Approach the documentation as a starting point, not a conclusion. It tells you what was written down. Your job in the first month is to understand what was not written down and why.
Two: Ask the programme director: “what is not in the documentation that I should know?”
This question, asked directly and early, signals to the programme team that the incoming committee member expects completeness, not curation. It gives the programme director an opportunity to surface informally managed items before they surface through a governance decision that exposes them.
Most programme directors will answer this question honestly if it is asked directly and without implication that honest disclosure will be penalised. Some will not. The answer itself is information: a programme director who answers this question with a rich, specific, contextually detailed response is a programme director who has been managing a real programme. A programme director who answers it with “I think the documentation is pretty comprehensive” is a programme director who may be managing a representation.
Three: Read the change log before approving any significant decision.
The change log is the single most revealing document in a programme governance pack. It tells you how the programme’s scope has evolved, through what process, with what costs and schedule impacts, and with what approvals.
Before making any significant governance decision, read the change log from the beginning. Look for gaps: periods where significant work was happening on the programme but few or no change requests were raised. Look for change request descriptions that are vague: “scope optimisation,” “resource rate adjustment,” “programme refinement.” Ask what specifically changed in each case.
A change log with a clean, continuous record of specific scope changes, each with a cost and schedule impact and a named approver, is a governance record that can be trusted. A change log with gaps, vague descriptions, or a pattern of cost absorbed into reforecasts without corresponding change requests is a governance record that requires further investigation before it can be relied on.
Four: Do not make a significant external commitment in your first month.
The incoming committee member who has been in her role for three weeks and is being asked to approve a client communication, a regulatory submission, or a board update is being asked to commit based on a programme picture she has not yet had time to verify.
The standard advice is to take time to understand the programme before making commitments. The specific advice here is more pointed: before making any commitment that would be difficult to unwind if the programme’s real state turns out to be different from the documented state, spend time actively looking for the gaps in the documentation, not just reading the documentation that is provided.
The gap that produces the worst outcome for an incoming committee member is always the gap she discovers after she has already committed to something that depended on the gap not existing.
The Final Point
Every large programme is, at some point, governed by people who did not start it. This is not a risk that can be mitigated by keeping the same committee members in place. It is a structural feature of long programmes in large organisations, and it needs to be designed for, not hoped against.
The design is straightforward. The execution is a discipline.
A programme that maintains a complete, honest, contextually rich governance record throughout its delivery, not at the point of transition but from the first day, is a programme that can be handed to a new committee member at any point in its lifecycle and governed effectively from the next meeting. The new committee member does not need to be briefed on informal agreements because there are no informal agreements. She does not need to be warned about undocumented scope because there is no undocumented scope. She does not need to inherit a vendor relationship because the vendor management is formal, documented, and transferable.
She can read the record. The record is the programme. And the programme is what it says it is.
This is not an aspiration. It is a choice that is made, or not made, by every PM, every workstream lead, every programme director, and every committee member, in every governance interaction, throughout the life of the programme.
The personnel trap is not sprung by the committee member who leaves. It is set by every governance interaction that produced a curated record rather than an honest one. By every change request that was not raised. Every risk that was not escalated. Every vendor commitment that was managed personally rather than documented formally.
The incoming committee member who falls into the trap is not the victim of bad luck. She is the victim of a governance culture that valued smooth relationships over honest records, and discovered too late that relationships do not outlast the people who hold them.
Records do.
Have you been the incoming committee member who discovered, in month three, that the programme you inherited was not the programme you were told it was? Or the programme director who had to explain to a new committee member why the change log had a six-month gap? The comments are open, and this one has stories in it that most people have never said out loud.
#ProgrammeGovernance #SteeringCommittee #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #ChangeManagement #RiskManagement #HonestLeadership #DeliveryExcellence #IndianManufacturing #ExecutiveLeadership #ProgrammeManagement #InstitutionalKnowledge
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.