A programme's coordination effort grows not with the number of tasks, but with the number and heterogeneity of its interfaces. Whoever plans capacity by implementation effort alone systematically underestimates coordination.
Executive Summary
  • Two programmes with identical implementation effort can have entirely different steering requirements — depending on how many workstreams, suppliers, systems and committees are connected to one another.
  • This “coordination surface” is rarely priced explicitly in classic planning. It reappears later as delay, duplicated work and escalation.
  • What works is to treat interfaces as a planning variable in their own right: with a dependency map, explicit coordination roles and a coordination share in capacity planning.

Observation

In programme planning, capacity is almost always thought of from implementation effort: how many person-days does the migration, the customising, the testing cost? The question of how much capacity the alignment between those involved costs is rarely asked with equal weight — even though, in multi-vendor programmes, experience shows that a considerable part of programme time goes into clarifications, handovers and status reconciliation.

The pattern shows most clearly when a programme grows: an additional workstream does not add one unit of work, but a new relationship to every existing workstream, every affected system and every committee that steers it. The work grows linearly, the coordination does not. This observation stems from my own practice in programme set-ups and PMO mandates.

Context

That large programmes systematically become more expensive and deliver less than planned is well documented: the study by Bloch, Blumberg and Laartz (McKinsey & University of Oxford, 2012) of more than 5,400 IT projects puts the average budget overrun of large IT programmes at 45 per cent — with a value contribution that falls, on average, 56 per cent below plan.1 The 2024 BCG study names, as one of the central causes of failure, the absence of an end-to-end master plan with a critical path and clear dependencies — reported by more than 60 per cent of the programmes surveyed.2

Neither study measures the mechanics described here directly. The reading that a substantial part of the deviations arises from under-planned coordination at interfaces is my own synthesis from these findings and project experience — not a statement of the studies.

The software-engineering research, however, provides direct evidence for the mechanism. Cataldo and colleagues developed the concept of Coordination Requirements: technical and task-related dependencies force particular people to collaborate; if a matching communication structure is missing, “socio-technical congruence” declines — the gap between technically necessary and organisationally available exchange.3 MacCormack, Rusnak and Baldwin tested the Mirroring Hypothesis empirically: the product architecture and the communication structure of the developing organisation tend to take the same form — technical and organisational modularity are not independent of one another.4 Herbsleb and Mockus found, in the context studied, that geographically distributed work packages took around two and a half times as long as comparable, locally handled ones — chiefly through additional communication and coordination needs.5 And the study by Shahin and colleagues shows that coordination cannot simply be “architected away”: continuous delivery does not automatically require microservices; what is decisive are suitable architectural characteristics, small deployment units and the early consideration of operational requirements.6

The concept: Coordination Surface

A programme's Coordination Surface is the set of all interfaces across which work, information or decisions must be handed over between independent units: between workstreams, suppliers, systems and committees. Two properties make it relevant to planning:

  1. It grows combinatorially, not additively. What matters is not the number of units, but the number of relationships between them. A programme with five tightly interwoven workstreams has more coordination surface than one with eight cleanly decoupled ones.
  2. Heterogeneity makes every interface more expensive. A handover between two teams with the same tool, the same cadence and the same contract partner is cheap. The same handover between two suppliers with different ticketing systems, maturity levels and commercial interests is many times more expensive — at identical implementation effort.

The practical consequence: project architecture is coordination design. The way workstreams are cut, the choice of supplier structure and the committee landscape fix the coordination effort long before the first task is planned.

Six components of the Coordination Surface

The coordination surface is made up of several independently steerable drivers:

  1. Technical dependencies. Which systems, components, data and releases depend on one another?
  2. Organisational handovers. How often does a work product change hands between teams, departments or functions?
  3. Contractual boundaries. Which dependencies run between different suppliers or contracts?
  4. Ownership distance. How far is the person carrying out the work from the role that actually decides?
  5. Change frequency. How often do requirements, interfaces or technical contracts change?
  6. Temporal distance. How strongly do time zones or differing work rhythms impede direct alignment?

Steering building blocks by coordination surface

The appropriate steering scales with the surface — more coordination is not always the right answer:

  • Low. A cross-functional team, direct alignment, lightweight risk and dependency management, no separate coordination function.
  • Medium. Named interface owners, a shared release plan, documented dependencies, a regular cross-team sync.
  • High. A formal dependency board, an integration lead, a shared definition of done, a design authority, aligned release governance, plus dedicated vendor and interface steering.
  • Very high. Here the answer is no longer coordination, but the question of structural decomposition: different system boundaries, clearer domain cuts, decoupled release units, fewer vendor interfaces, dedicated rather than shared resources. Coordination has limits — beyond them a programme does not need a larger meeting apparatus, but a different cut.

Application in projects

  • Dependency map before capacity planning. Before effort estimation, workstreams, suppliers, systems and committees are mapped with their relationships. Interfaces of high heterogeneity — different tools, contracts, cadences — are flagged: that is where the most expensive coordination effort arises.
  • Explicit coordination roles. Interfaces with high volume are given a named responsibility (for example integration lead or vendor coordinator) instead of the implicit expectation that “the teams will sort out alignment themselves”. Unstaffed interfaces are otherwise, in effect, co-coordinated by the project lead — invisibly and unbudgeted.
  • Pricing coordination into the plan. Capacity planning reports coordination as a line item in its own right, whose share rises with the mapped number of interfaces — rather than carrying it as a blanket surcharge or not at all. That also makes architecture decisions comparable: an additional supplier is assessed by its interface costs, not just by its day rate.

Limitations

Coordination Surface is a working concept from practice, not a validated metric; an exact quantification (“coordination cost per interface”) is rarely cleanly possible in real programmes. The approach does not replace effort estimation but complements it. And not every interface can be designed away: some heterogeneity — for example regulatorily separated systems or deliberate multi-vendor strategies — is intended. The goal is then not less surface, but deliberately priced surface.