A Project is not a Platform
Why major infrastructure programmes need a different operating model from repeatable growth platforms.
Read Time : 7mins
A platform earns its return by doing a similar thing many times and getting better at it. A major infrastructure project earns its return once, at enormous scale, and is then brought into service.
That single difference changes the operating model.
A platform can learn across repetition. A major project has far less room to do so. It generally has one opportunity to define the scope, own the interfaces, prove the systems, integrate with the infrastructure around it and enter service safely. If the joins are not owned before the first irreversible commitments are made, the learning comes too late and usually at significant cost to the programme outturn.
Our standing view is that complex infrastructure fails at the joins. On a major project, that view is not softened. It is sharpened.
A major project brings many disciplines into play at once: civils and structures, mechanical and electrical, systems and controls, consents, land, stakeholders, commissioning and operational handover. The number of interfaces between them rises much faster than the number of disciplines. The joins are denser, more novel and more consequential because there is limited opportunity to recover through repetition.
It helps to be precise about what a major project actually is, because the word disguises its complexity. What we call a major project is rarely one project. It is a programme: an amalgamation of substantial, multi-disciplinary projects bound together because they have to become a single working asset.
The enabling works, main civils, mechanical and electrical build, control and protection systems, network connection, commissioning and integration are each significant projects in their own right. None of them is the asset alone.
The top-level discipline is therefore programme management, not project management at greater scale. Its defining task is not to deliver any single package, but to integrate all of them, and then to integrate the whole into the infrastructure it must join.
That puts the joins at two levels at once: inside each project between its disciplines, and across the programme between the projects themselves. The second level is usually the harder one, because no single package owner is positioned to see the whole.
That is the structural difference from a platform. On a platform, the operating system is part of what creates the asset value. The disciplines that convert capital and sites into commissioned assets are built once and amortised across every repetition. Each turn de-risks the next and tightens the economics.
A major project has no equivalent next turn. Whatever is not resolved at the front end is carried into execution, because there is no later unit across which to apply the lesson. A platform can afford to learn by doing because doing happens again and again. A programme of one cannot, so it has to define before it commits.
The practical consequence is that the operating model must be substantially right before the first irreversible commitment, not refined in flight.
Front-end definition is the highest-leverage activity on a major project, and the one most often starved of time under schedule pressure. It is the work of fixing scope, interfaces, sequence, responsibilities and assurance before mobilising at scale.
Because the work is delivered by a temporary coalition of contractors, designers, advisers and specialist suppliers rather than a standing business, the owner has to act as an intelligent client. It must hold the integrated view, own the interfaces between parties who each see only their own scope, and refuse to let the joins fall into the gaps between contracts.
This also changes how the joins are managed.
On a platform, the recurring handoffs can be systematised. Interface checkpoints can be built into stage gates and sharpened through each repetition. A major programme cannot lean on recurrence in the same way. It has to treat the work as a system, not as a stack of packages being delivered in parallel.
That means requirements that trace through to verification, interface registers that name an owner on both sides, a configuration baseline that does not drift silently as the design matures, and clear evidence of readiness before the programme crosses each threshold.
The absence of that systems approach is the most common and least visible way a major project loses control of its joins.
A systems approach also makes a demand on the schedule, and it is the demand most often refused. The programme has to hold genuine time, and defend it, for the full assurance chain: time to break the scope into coherent work packages; time to test and validate each subsystem before anything is called complete; time to run system and integration testing across the whole; and, most underestimated of all, time to integrate into the existing infrastructure systems the asset must join and must not disturb.
That time is often the first thing compressed when the front end slips. It is also the worst thing to lose, because it is exactly where the joins are proven or found wanting.
There is a cultural reason this happens, and it is worth saying plainly. Builders love to build. The visible and satisfying progress on a major project is the build: the steel, the concrete, the plant going in, the permanent works taking shape.
Commissioning, integration and tie-ins to live systems are harder to see and easier to defer. Under pressure, they are quietly borrowed against.
The projects that succeed invert that orientation. They treat commissioning and systems integration as the customer of the build, not as its afterthought. Everything upstream is packaged, sequenced and tested to give commissioning a clean, integrateable handover.
That is not a technical nicety. It is the route into service.
A major project is not finished when it is built. It is finished when it is in service.
When this goes wrong, and there have been too many examples to pretend otherwise, the cost is rarely a delay that can simply be absorbed. It is a recovery.
A reset capability has to be stood up, and what that reset does is telling. It refocuses the programme backwards from the end state it should have started from the plans forward. It realigns recovery, testing and commissioning around staged integration, completion criteria and handover-into-service requirements. It moves the programme away from the momentum of the build and back towards the end state it should always have served. Inevitably, the programme slips, the costs increase and the scope suffers.
The reset imposes, under duress and at considerable cost, the orientation the successful projects hold from the outset. That a recovery reaches for exactly this is the clearest proof that commissioning and integration were always the customer. The only question is whether the programme organises around that truth from the start, or is forced back to it through recovery.
The portfolio logic is different too.
A platform spreads risk across many small, similar and largely independent assets. A single interface failure may be painful, but it is usually survivable and instructive.
A major programme also decomposes into many sub-projects, but they are not independent. They are correlated by the need to integrate into one working whole. Failure in one area can propagate across the programme, which means interface risk has to be treated more conservatively, not less.
Governance follows the same logic. A platform gate commits capital in proportion to accumulating evidence that the unit repeats. A programme gate cannot rely on repetition as evidence, so it commits in proportion to the maturity of definition before each irreversible step: whether the work is defined well enough to commit, whether the next set of interfaces is understood, and whether every interface about to be crossed has an owner on both sides. The cost of committing before the programme is ready is borne in full.
A platform is built to compound. A major project is built to be delivered once, at scale, integrated into the infrastructure around it and brought into service.
The operating model that suits the first will quietly betray the second, and it will do it where complex infrastructure always fails.
At the joins.
MCMILLAN MACLEAN
Independent infrastructure and energy transition advisory.
McMillan Maclean | Perspectives