Orchestrating What You Don’t Control
The programme that outsources integration authority does not lose control visibly. It loses control structurally.
The Vanishing Programme Director
The programme board is running to time. Every partner’s RAG status is green. The slide deck is immaculate. And yet the programme director cannot answer a straightforward question from the sponsor: if we accelerate the platform migration by eight weeks, what breaks?
She cannot answer it because the sequencing model sits inside the systems integrator’s planning tool, the architecture decisions were delegated to the platform vendor three months ago, and the acceptance criteria are being defined by a testing partner whose contract incentivises throughput, not coverage. She holds the accountability. She does not hold the authority. And in that gap — between the accountability she was given and the authority she gave away — sits the mechanism by which large, multi-partner transformations quietly fail.
The Ecosystem Is the Delivery Model
Large-scale transformation programmes are no longer delivered by a single organisation with the client providing oversight. They are delivered by ecosystems — a strategy consultancy that framed the business case, a systems integrator building the platform, one or more product vendors whose technology is being implemented, specialist firms handling data migration or change management, infrastructure and cloud partners, and often a layer of staff augmentation filling capability gaps the client cannot recruit for at pace.
Each partner arrives with its own commercial physics. The SI’s margin model rewards scope expansion and change requests. The product vendor’s roadmap may not align with the programme’s timeline. The strategy firm’s departure after the design phase creates a handover gap that nobody owns. The testing partner’s fixed-price contract means it will optimise for the volume of defects found, not for the coherence of the testing strategy.
The programme director sits at the centre of this system, accountable for an outcome that depends on the coordinated behaviour of organisations whose incentives are, at best, imperfectly aligned with that outcome — and with each other. In many programmes today, the client employs a minority of the hands doing the work. Sometimes a significant minority. The director is leading a delivery effort in which most of the people, most of the capability, and most of the operational decisions sit outside her direct authority.
This is a structural fact, not a temporary problem. The complexity and pace of modern transformation mean that no single organisation — including the client — possesses all the capabilities required. Multi-partner delivery is not a failure of planning; it is the operating model. The question is whether the programme has been designed for it.
Orchestration Is Not Management
The instinct, when faced with a multi-partner delivery, is to manage harder — more governance forums, more status reports, more dashboards, more escalation paths. This is understandable and insufficient. Management assumes the work is happening inside your system and needs to be tracked. Orchestration recognises that the work is happening across multiple systems with different incentives, different planning horizons, and different definitions of success, and that these systems need to be designed to cohere.
The distinction shows up in practical terms. Incentive alignment, for instance, is an orchestration problem, not a management one. The time to align partner incentives is during procurement, not after mobilisation: writing contracts that create shared consequences — shared risk pools, milestone payments tied to programme outcomes rather than partner deliverables, penalty and reward mechanisms that make each partner’s commercial interest a function of the whole rather than just their own scope. Procurement functions are often not equipped for this work, and the legal frameworks are unfamiliar. But the alternative is to enter delivery with a set of contracts that, read together, describe a system optimised for each partner’s individual margin rather than the programme’s collective outcome.
Planning, likewise, fragments almost immediately in a multi-partner programme unless it is actively prevented. Each partner maintains its own plan, its own milestones, its own critical path. The programme plan becomes a reconciliation exercise — an attempt to stitch fragments together into something that resembles a coherent sequence. The discipline is a single integrated plan that the client owns and all partners plan within, where dependencies between partners are explicit, baselined, and tracked at the programme level. This sounds like basic planning discipline. It is. And it is absent from a remarkable number of large programmes, where the planning tool is owned by the SI and the programme director’s view of the schedule is whatever the SI chooses to surface.
Governance, too, must be redesigned for the reality of ecosystem delivery. Standard governance — the monthly steering committee, the fortnightly programme board — assumes the programme director has line-of-sight to the work. In a multi-partner ecosystem, the critical information sits not inside any one partner’s reporting but in the gaps between them. The data migration is running to its own plan, but nobody has tested whether the migrated data will be accepted by the platform the SI is building. The business processes the change team has been redesigning do not match the configuration decisions already locked in. Joint governance means creating mechanisms where partners expose their risks, dependencies, and assumptions to each other — laterally, not just upward — and where partner conflict is treated as a natural and expected feature of multi-party delivery rather than an escalation to be avoided. The programme that treats every partner disagreement as a crisis to be smoothed over will discover, at integration testing, that the disagreements it smoothed over were the warnings it should have heeded.
But of these orchestration disciplines — incentive alignment, integrated planning, joint governance — none matters as much as the fourth. What I will call retained integration authority is the spine of multi-partner delivery. It is also the thing that clients surrender most readily.
The Authority That Cannot Be Outsourced
Integration authority is the set of decisions that determine whether a programme’s component parts will come together into a working whole: the target architecture, the sequencing of delivery, the acceptance criteria at each stage, and the standards against which components are assessed for fitness. These are not administrative decisions. They are the decisions that, collectively, define what “done” means and in what order it is achieved.
In my experience, this is the authority that clients outsource earliest and miss latest. The reasoning is seductive: the SI has the technical capability, the platform vendor understands the product, the testing partner has the methodology. Why not let them make these decisions? They have more people, more experience, more capacity.
The answer is that each partner will make integration decisions that optimise for their own scope, their own risk, and their own commercial position. The SI will sequence work to maximise its team’s utilisation. The platform vendor will define the architecture to favour its own product capabilities. The testing partner will set acceptance criteria that are achievable within its contract parameters. None of this is malicious. It is rational commercial behaviour within the incentive structure each partner operates in. But the effect is cumulative: a set of locally rational decisions that produce a globally incoherent programme.
The programme that outsources integration authority does not lose control visibly. It loses control structurally. The director continues to chair governance meetings, review status reports, and make what appear to be decisions. But the decisions that matter — what gets built first, how components connect, what standard of completeness is sufficient — are being made elsewhere, by people whose accountability runs to their own contract, not to the programme’s outcome. The programme director is still on stage. She is no longer holding the script.
The moment a programme outsources architecture, sequencing, and acceptance, it has not delegated delivery. It has converted itself from the leader of its transformation into a spectator — accountable for an outcome it can no longer shape.
Some will argue that the client lacks the capability to hold integration authority — that the technical decisions are too complex, the architecture too specialised, the sequencing too dependent on deep product knowledge. This argument is not wrong in its premises but catastrophic in its conclusion. The answer is not to hand integration authority to a partner. It is to invest in the small, senior, technically credible team that can hold it. In a programme with four or five delivery partners, a retained integration team of eight to twelve people — provided they are the right people, with the right mandate — can hold the whole. They do not need to do the work. They need to own the decisions about how the work fits together.
The cost of this team is trivial relative to the cost of the programme. The resistance to funding it is enormous, because it looks like overhead in a world that has decided to outsource for efficiency. The irony deserves to be stated plainly: the decision to save two million on a retained integration team routinely produces twenty million in rework when the integration points fail. This is not a theoretical number. It is a pattern observed across enough programmes to be treated as a reliable consequence.
The Pattern and the Price
The pattern recurs with dispiriting regularity. A client procures a multi-partner ecosystem, often with genuine sophistication in selecting individual partners. The programme mobilises. Each partner stands up its team, its governance, its planning. The programme office produces an integrated view. For the first six months, sometimes twelve, the programme appears to be running well.
The fracture appears at the first major integration point. The platform does not accept the migrated data in the format the migration partner delivered it. The business processes the change team has been redesigning do not match the configuration the SI has built. The infrastructure is not ready for the load the platform team assumed it would carry. And the programme director discovers that the decisions which created these gaps were made months ago, inside partner teams, in meetings she was not in, against criteria she did not set.
What makes this pattern so persistent is that it does not feel, at any point along the way, like a failure of governance. Every partner reported on time. Every status was green. The dashboards worked. What failed was not the management of individual partners but the integration design of the whole — and that design was never anyone’s explicit job, because the authority to do it had been distributed across partners who each assumed someone else was holding the seams.
The Design Decision
The temptation in writing about multi-partner delivery is to offer a framework — a maturity model, a governance template, a set of principles to pin to a wall. The reality is simpler and harder than any framework. Orchestration is a discipline, practised daily in the decisions about what the client retains and what it delegates. It is not a layer of governance added on top of delivery. It is a design decision made before delivery begins — embedded in contracts, in the programme’s organisational design, and in the calibre and mandate of the people who hold the integration seams.
The programmes that get this right do not manage their partners harder. They design the conditions under which partnership produces coherence rather than fragmentation. They retain the authority that, once given away, converts them from leaders of their transformation into its audience. And they make that choice early — not because they distrust their partners, but because they understand, from hard experience, that trust without structural authority is hope dressed in a suit.