Why Scale Changes Everything and Why Your Dashboard Lies at a Different Altitude
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
There is a question that every programme director eventually gets asked by someone who has managed projects but not yet managed programmes.
“How different can it really be? More workstreams, bigger budget, longer timeline. Same principles, no?”
The answer is: no. Categorically, structurally, consequentially no.
A large project is complex. A programme is interdependent. These are not the same thing, and the difference between them is not a matter of degree. It is a matter of kind. And understanding the difference between them is the precondition for understanding why information management that is merely costly in a single project becomes catastrophic at programme scale.
Haathi aur ghoda dono bade hain. Lekin ek hi sawari nahi hai. An elephant and a horse are both large. But you cannot ride them the same way.
The Distinction That Changes Everything
A complex project has many moving parts. But those parts, however numerous, are ultimately answerable to a single project manager with a single plan, a single budget, and a single line of accountability to a single sponsor. When something goes wrong in one part, the PM knows about it immediately because it is her project. She feels the impact because she owns the whole. The information does not have to travel far before it reaches someone who can act on it.
A programme is a different organism entirely. It is not a big project. It is a system of projects that are structurally dependent on each other’s outputs, competing for each other’s resources, and making assumptions about each other’s delivery that are frequently not written down, not stress-tested, and not visible to anyone who is looking at only one workstream at a time.
The workstreams in a programme do not simply run in parallel like lanes on a highway, each progressing independently toward the same destination. They are more like the stages of a steel plant’s production chain. The blast furnace cannot run without the sinter plant feeding it. The continuous caster cannot run without the steelmaking shop feeding it. The hot rolling mill cannot run without the caster feeding it. Each stage is the downstream customer of the stage before it, and the upstream supplier of the stage after it.
Miss a commitment in one stage, and the whole chain adjusts. The adjustment is not optional. It is structural. The chain is the product.
A programme works the same way. When the data migration workstream misses its data quality commitment, the case management workstream, the testing workstream, the integration workstream, and the change management workstream all adjust involuntarily. They have no choice. They were dependent on that output. The output has changed. Their plans are now wrong.
This is the property that makes a programme fundamentally different from a large project. In a project, a problem is the PM’s problem. In a programme, a problem in one workstream is a programme-level problem, regardless of whether the programme director or the other workstream leads know about it yet.
The Engine That Is Also the Vulnerability
The interdependency of workstreams in a programme is not a design flaw. It is the design. It is precisely what makes programme-scale delivery powerful.
Without interdependency, parallel workstreams would simply be independent projects happening to share a sponsor. With interdependency, they become a coordinated system capable of delivering in two years what sequential execution would take eight years to achieve.
In a steel plant ERP and MES programme, this is not an abstraction. The finance workstream can be configuring the FICO module while the production planning workstream is designing the PP integration while the MES team is building the heat scheduling logic while the data migration team is cleansing the legacy production data while the infrastructure team is building the technical environment. All of this happens simultaneously because each workstream is confident that the outputs it depends on from other workstreams will arrive as planned.
That confidence is the engine. It is also the vulnerability.
Because the confidence is based on assumptions. The MES team assumes the material master data will be available in the agreed format by the agreed date. The production planning team assumes the MES interface specification will be finalised before the PP configuration requires it. The data migration team assumes the data model will be stable before the extraction logic needs to be built against it.
These assumptions are the connective tissue of the programme. They are also, almost always, the last thing that gets formally documented and the first thing that gets informally revised.
When a workstream lead discovers that her output will be late, or different from what was agreed, the immediate instinct is to manage it internally. This is the project manager’s instinct, and it is a good one in a project context. In a programme context, it is the equivalent of discovering a crack in the blast furnace lining and deciding not to mention it to the steelmaking shop because “we’re working on it.”
The steelmaking shop is planning its next campaign. It needs to know. Keeping your own counsel is fine. But you cannot forget what others need from you.
Three Steel Plant Programme Examples That Make This Concrete
Example One: The Material Master That Was Not Ready
A large integrated steel plant is running a simultaneous ERP and MES implementation. The programme has six workstreams: ERP core (FI, CO, MM, PP), MES for steelmaking and casting, MES for hot rolling, APS, data migration, and infrastructure and integration.
The data migration workstream is responsible for cleansing and loading the material master data from the legacy system into the new SAP environment. The material master is foundational: every other workstream depends on it being available, accurate, and stable before they can complete their own configuration and testing.
In month seven, the data migration lead discovers that the legacy material master contains approximately 4,200 materials with incomplete or inconsistent classification data. The materials are a mix of production grades, spare parts, and consumables that have been entered into the legacy system by multiple departments over fifteen years with no consistent taxonomy.
Cleansing this data properly will take six weeks. The data migration workstream’s plan had allocated two weeks for material master cleansing, based on a data quality assessment that was done eighteen months earlier and has not been updated since.
The data migration lead assesses the situation. She concludes that her team can work overtime and use an automated matching tool to close most of the gap. She does not escalate. She reports Green.
What she does not know is the following:
The ERP production planning team has been building its PP configuration for the last three months against the legacy material classification structure. Approximately 800 of the 4,200 problematic materials are production grades. When the correct classification is applied to these grades during the cleanse, seventeen of them change their material type in a way that affects the PP configuration. The production planning team’s configuration will need to be partially reworked.
The MES hot rolling workstream has been designing its campaign management logic around a material attribute called “rolling family” that groups grades by their rolling characteristics. The legacy data has inconsistent rolling family assignments on 340 of the problematic materials. The campaign management logic is being built against a grouping that is partially wrong.
The APS workstream has been building its constraint model for slab-to-order matching using material attributes from the legacy system. Several of the slab allocation rules are sensitive to the classification data that is inconsistent. The constraint model will produce incorrect allocation recommendations for a non-trivial percentage of orders when the corrected data is loaded.
The infrastructure and integration workstream has scheduled its first end-to-end data flow test for month ten, assuming the material master will be available in its final form by month nine.
None of these workstream leads know what the data migration lead knows. All of them are building on a material master representation that is going to change.
When the automated matching tool produces results that the data migration team cannot fully validate, the manual cleanse begins in earnest in month nine. The full cleanse completes in month eleven. The material master becomes available in its final form in month twelve, not month nine.
The end-to-end integration test moves from month ten to month thirteen. The PP configuration rework takes three weeks. The MES campaign management logic needs to be revised and retested. The APS constraint model needs to be recalibrated.
The programme’s go-live, originally planned for month twenty, moves to month twenty-five. The additional cost across all workstreams runs to 29% of the original budget.
A data quality issue known in month seven. A go-live impact of five months and 29% of budget. Because one workstream lead decided it was manageable internally.
Example Two: The Interface Specification That Kept Changing
In the same programme, the MES steelmaking and casting workstream is responsible for defining the interface specification between the MES heat scheduling module and the SAP PP production order management. This specification determines how production orders created in SAP are communicated to the MES, how the MES schedules heats against those orders, and how actual production data is returned from the MES to SAP for confirmation.
The interface specification was agreed in principle in month two. In month five, the MES workstream discovers that the SAP PP configuration has made several decisions about production order structure that affect the interface. The order type being used for steelmaking is different from what was assumed. The batch management approach has changed. The confirmation granularity is different.
The MES workstream lead raises this with the ERP workstream lead bilaterally. The ERP workstream lead acknowledges that changes have been made and says the interface specification will need to be updated. Both agree to meet the following week to align.
The meeting happens. Partial alignment is achieved. A follow-up meeting is scheduled for the week after.
The follow-up meeting is postponed because both workstream leads have other commitments.
Over the next six weeks, the interface specification exists in two versions: the original agreed version and a mentally held updated version that the two workstream leads have discussed but not formally documented. The MES team continues building against the original version because it is the one in the master document. The ERP team continues its PP configuration against the new decisions without flagging the impact on the interface.
This continues until month nine, when the integration testing team attempts to run its first MES-SAP interface test and discovers that the MES is expecting production order data in a structure that the SAP system is not sending.
The resolution requires a formal interface re-specification session involving both workstream leads, the integration team, and the programme architect. It takes three weeks. The integration testing window moves by four weeks. Two other workstreams whose testing plans depended on the MES-SAP interface being stable are affected.
The root cause: a bilateral technical conversation that was never escalated to the programme level, never documented formally, and never resolved through the programme’s change control process.
The steering committee, which has the authority to direct both workstream leads to resolve and document the interface specification within a defined window, never knew there was a dispute. Because both workstream leads were managing it themselves. Because it was a technical matter. Because it would be resolved soon.
Example Three: The Testing Window That Everyone Needed at the Same Time
The programme’s testing workstream has planned three testing windows: a system integration test in month fourteen, a performance test in month sixteen, and a user acceptance test in month eighteen. These windows have been planned around the assumption that all workstreams will have completed their unit testing and be ready to enter system integration test by month fourteen.
In month ten, three workstreams independently identify that they will not be ready for system integration testing by month fourteen. Each one assesses the situation internally. Each one concludes that a few additional weeks will be sufficient to close the gap. Each one continues to report Green or Amber-with-mitigation.
None of them know that the other two are in the same situation, because the programme’s cross-workstream dependency review meetings have been replaced by bilateral check-ins to “save time,” and the bilateral check-ins do not create a consolidated view of testing readiness.
In month thirteen, the testing workstream lead conducts a pre-test readiness check. She discovers that three workstreams are not ready for system integration testing. She escalates to the programme director.
The programme director convenes an emergency session. It becomes clear that the three workstreams are each approximately four to six weeks behind where they need to be for testing. The system integration test window moves from month fourteen to month seventeen. The performance test moves from month sixteen to month nineteen. The user acceptance test moves from month eighteen to month twenty-one.
The plant operations team, which has been planning for a go-live in month twenty-two, is informed that the go-live will now be month twenty-four at the earliest. They have already made operational commitments based on the month twenty-two date, including staff redeployments, training schedules, and production planning adjustments.
Three workstreams, each carrying a four-to-six week delay internally, each making independent assessments that their delay was “manageable,” have together produced a programme-level slip of three months. Not because their individual delays were large, but because they were invisible to each other and to the programme governance structure until it was too late to absorb them in the testing schedule.
Why the Incentives to Suppress Get Stronger as the Programme Gets Bigger
Here is the paradox that sits at the heart of programme governance: the larger the programme, the stronger the forces that push individual workstream leads toward suppressing bad news, and the more damaging that suppression becomes when it plays out across the programme.
This is not a coincidence. The same properties that make a large programme powerful, the interdependency, the parallel execution, the concentration of resources and authority, are precisely the properties that amplify the cost of information suppression.
Three forces operate in a large programme that do not operate, or operate far less powerfully, in a single project.
Visibility pressure is qualitatively different at scale.
In a small project team, everyone knows what everyone else is working on. A PM who is struggling with a problem does not need to manage perceptions actively because the problem is visible to the team anyway. The governance conversation is informal and continuous.
In a programme review with eight workstream leads around the table, the consolidated dashboard is the only shared picture. Being the red line on that dashboard is a qualitatively different experience from being the person with the problem in a small team. There are professional comparisons being made between workstreams. There are resource allocation decisions influenced by which workstreams appear to be performing. There are political relationships with the programme director that feel contingent on appearing in control.
The programme review room creates a competitive dynamic between workstream leads that a single project does not. And competitive dynamics produce impression management.
Distance from consequence removes the natural corrective.
In a single project, a PM who suppresses a risk feels the consequence of her suppression in her own workstream, often within weeks. The feedback is direct and personal. This directness is a natural corrective: the experience of being hurt by your own information management decisions is a powerful teacher.
In a programme, the consequence of one workstream lead’s suppression lands on other workstreams, in forms that may not be traceable to their origin. The data migration lead who suppresses the material master quality issue does not personally experience the PP configuration rework, the MES campaign logic revision, or the APS recalibration. She may not even know these consequences occurred. The pain is distributed across people she may not know well, in workstreams she may not interact with regularly.
This distance is not morally exculpatory. But it is psychologically significant. Human beings find it easier to defer costs that will land on others than costs that will land on themselves. The programme structure creates this condition by design, as a consequence of parallel execution, and governance must explicitly design against it.
Complexity provides cover that is both real and convenient.
Large programmes are genuinely complex. Interdependencies are genuinely hard to see in their entirety. Data quality issues genuinely do not always become visible until the pipeline is running. Interface misalignments genuinely do emerge during integration testing that were not apparent during design.
This genuine complexity provides plausible cover for suppression that would not exist in a simpler environment. “The issue only became visible when we ran the pipeline” is sometimes true. It is also sometimes a post-hoc rationalisation of a problem that was identifiable earlier but was not looked for because looking for it might have produced bad news.
The programme director who pushes back on this rationalisation in a post-mortem, asking “when did the data quality risk first appear in any form, even as a question?” will often find that the answer predates the official identification by weeks or months. The risk was present before it was “visible.” It became visible when someone chose to look, or when the downstream impact made it impossible to ignore.
These three forces do not make suppression right. They make it structurally predictable, which is the more useful insight. A programme that does not explicitly design its governance structures to counteract these forces will reliably produce suppression, not because the people in it are dishonest, but because the environment makes suppression the rational choice and escalation the costly one.
Changing the outcome requires changing the environment. Not just the people.
What Programme-Scale Governance Needs to Do Differently
The governance structures that work adequately for a single project are not sufficient for a programme. They need to be supplemented with mechanisms that are specifically designed to surface the cross-workstream information that individual workstream leads are structurally incentivised to manage locally.
The interface register needs to be a live governance instrument, not a design artefact.
Most programmes create an interface register during the design phase. It documents the data exchanges between workstreams, the formats, the frequencies, the owners. It is used as a reference document during configuration and largely forgotten during testing.
This is the wrong lifecycle for this document. The interface register should be reviewed in every programme-level governance session, not as an administrative exercise but as a substantive question: have any of these interfaces changed since the last review, and if so, what is the downstream impact?
Interface changes are the primary carrier of cross-workstream risk in ERP and MES programmes. They need to be tracked with the same rigour as the project plan.
Cross-workstream dependency reviews need to produce a consolidated picture, not bilateral acknowledgements.
The bilateral check-in, in which two workstream leads confirm that their shared dependency is on track, is not a programme-level governance mechanism. It is a local mechanism that produces local reassurance. It does not tell the programme director what she needs to know, which is whether the full network of dependencies is healthy as a system.
The programme-level dependency review needs to put all the critical dependencies on a single view, with each one assigned a status that has been validated, not self-reported, and with the implication of any Amber or Red dependency assessed across the full dependency network, not just for the two workstreams most directly involved.
Testing readiness needs to be assessed as a system, not as a workstream aggregate.
The testing window is a shared resource. All workstreams depend on it. It cannot absorb the sum of individual delays unless those delays have been planned for in advance.
A testing readiness assessment that asks each workstream “are you ready for SIT?” and aggregates the answers is not a system-level readiness assessment. It is a collection of self-assessments with no cross-validation. The programme director who wants to know whether the programme is genuinely ready for system integration testing needs to understand the dependency network between workstreams and validate readiness at the points where the workstreams touch each other, not just at the workstream level individually.
Tips for Project Managers and Workstream Leads: How to Think About Your Place in the System
One: Know your downstream addresses before you suppress anything.
Before deciding that a risk can be managed internally, a workstream lead should complete a simple exercise: list every workstream that depends on an output that the risk might affect. Not the workstreams that depend directly, but the ones that depend on the workstreams that depend on you, because in a tightly coupled system, second-order dependencies can be as significant as first-order ones.
If the list has more than one workstream on it, the risk is a programme-level risk, not a workstream-level one. It belongs in the programme RAID register and in the programme-level governance conversation, regardless of whether the workstream lead believes she can manage it.
Two: Change your mental model of what “managing it internally” means.
In a single project, managing a risk internally means keeping it within the project team while working toward resolution. In a programme, managing a risk internally means keeping it within a single workstream while other workstreams build their plans against assumptions that have already been invalidated.
The phrase does not mean the same thing in the two contexts. A workstream lead who has internalised this difference will escalate programme-level risks automatically, not because she has been instructed to, but because she understands that “managing it internally” in a programme context is not management. It is delay with consequences attached.
Three: The interface specification is your responsibility, not just the integration team’s.
In most programmes, the interface specification is owned by an integration architect or a technical lead. Workstream leads treat it as someone else’s document that they review and sign off on during the design phase.
This is the wrong ownership model. The workstream lead is the person who knows when her workstream’s design decisions are affecting the interface. She is the person who notices when the configuration has diverged from what the interface specification assumed. She is the person who needs to raise the flag when the bilateral conversation about an interface alignment has not produced a formal resolution.
If the interface specification changes and the workstream lead does not escalate it, the change will propagate through the programme silently, creating misalignments that will surface in integration testing at the worst possible moment.
Four: Build relationships across workstreams deliberately, not incidentally.
The workstream lead who knows the other workstream leads personally, who has informal conversations with them about their progress and their concerns, who is genuinely curious about how the other workstreams are doing, will learn things in those conversations that will never appear in a formal programme review.
These informal cross-workstream relationships are not a substitute for formal governance. But they are an early warning system that formal governance cannot replicate. The information that a fellow workstream lead shares over a cup of tea, because she trusts the person she is talking to, is often the earliest signal available of a problem that will take months to surface through the formal channel.
Build those relationships. Have those conversations. And when the conversations produce information that has programme-level implications, take it to the formal channel, with the consent of the person who shared it.
Tips for Steering Committee Members and Programme Directors: How to Govern a System, Not a Collection of Workstreams
One: Review the interface register at every programme governance session.
Not the full register. The active interfaces: the ones that have dependencies that are currently in play, where one workstream’s output is another’s input within the current planning horizon. Ask specifically whether any interface specification has changed since the last review, and what the downstream impact of that change is.
This question, asked consistently at every session, establishes the norm that interface changes are a programme-level governance matter, not a workstream-level technical matter. It also creates the expectation in workstream leads that interface changes will be asked about, which is a powerful incentive to surface them proactively.
Two: Do not accept workstream-level testing readiness as evidence of programme-level readiness.
When the programme approaches a testing window, the readiness assessment should be done at the dependency level, not the workstream level. The question is not “is each workstream ready?” The question is “are the interfaces between workstreams ready?” A workstream can be internally complete but unable to enter system integration testing because a dependency it relies on from another workstream is not available.
Direct the programme director to produce a dependency-level readiness view before each testing window. If the view shows any dependency that is not ready, understand the full impact on the testing window before making a decision about whether to proceed.
Three: When a workstream turns Amber, ask which other workstreams depend on its outputs.
The immediate response to an Amber workstream should not be limited to asking what is being done to recover. It should include a mandatory cross-workstream impact assessment: which other workstreams depend on outputs from this workstream, what is the nature of the dependency, and what is the impact on those workstreams if the Amber workstream does not recover to Green within the current planning window?
This question changes the nature of the governance conversation from a bilateral discussion between the committee and the Amber workstream to a systemic assessment of programme risk. It surfaces the cascade potential of the Amber before the cascade happens, not after.
Four: Create a programme-level risk that explicitly covers interface misalignments.
Most programme RAID registers have risks that correspond to individual workstreams or external dependencies. They rarely have a standing risk that covers the possibility of interface misalignment between workstreams.
Adding this risk explicitly, with a defined monitoring approach, sends a governance signal that interface alignment is a programme-level concern that the committee takes seriously. It also creates a formal channel through which workstream leads can escalate interface disputes without framing them as interpersonal conflicts between workstream leads, which is often how bilateral technical disagreements feel from the inside.
The Final Point
A programme is not a large project. It is a system. And a system has a property that a project does not: failures propagate.
In a project, a problem is contained within the project. In a programme, a problem in one workstream travels through the dependency network until it surfaces in a form that is unrecognisable as the original problem, in a workstream that had nothing to do with its origin, at a cost that no individual workstream lead would have believed possible when the original decision to suppress was made.
The data migration lead who did not escalate the material master quality issue in month seven did not believe she was causing a five-month programme delay. She believed she was managing a data quality issue. The two things are the same thing, from different altitudes. The programme director can see both. The workstream lead, looking at only her own workstream, can only see one.
This is why programme governance must operate at the system level, not the workstream level. Why the interface register must be live, not archived. Why cross-workstream dependencies must be reviewed as a network, not as a collection of bilateral agreements. Why testing readiness must be assessed at the point where workstreams touch each other, not at the point where each workstream is confident in itself.
And why the single most important thing a workstream lead in a large programme can do for the programme, for her fellow workstream leads, and for her own professional reputation, is to escalate the information that has programme-level implications at the moment she has it, not at the moment she has run out of other options.
Have you been the workstream lead who found out three months later that your plan was built on an assumption that had already changed? Or the programme director who discovered a cascade in a testing session that a single honest escalation in month seven would have prevented? The comments are open, and this one goes deep.
#ProgrammeManagement #ProjectGovernance #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #WorkstreamManagement #InterfaceManagement #RiskManagement #HonestLeadership #DigitalTransformation #DeliveryExcellence #IndianManufacturing
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.