Coordination Surface: How interfaces and coordination effort grow with project architectures.

The coordination effort of a programme depends less on the number of tasks than on the number and diversity of its interfaces. Planning capacity only by delivery effort regularly underestimates coordination.

Observation

In programme planning, capacity is almost always planned from delivery effort. The question is how many person-days the migration, the customising or the testing will cost. How much capacity the coordination between those involved will cost is rarely asked with equal weight. In our own experience, however, a considerable part of the time in multi-supplier programmes goes into clarifications, handovers and status alignment.

The pattern becomes especially clear when a programme grows. An additional workstream does not only bring additional work. It also creates new relationships with every existing workstream, every affected system and every committee that steers it. The work grows linearly, the coordination grows faster. This observation comes from our own practice in setting up programmes and from PMO engagements.

Context

That large programmes regularly cost more and deliver less than planned is well documented. Bloch, Blumberg and Laartz (McKinsey and University of Oxford, 2012) analysed more than 5,400 IT projects. According to their results, large IT programmes exceeded their budget by 45 percent on average and delivered 56 percent less value than planned.

In the 2024 BCG study, more than 60 percent of the programmes surveyed name the absence of an end-to-end master plan with a critical path and clear dependencies as a central cause of failure.

Neither study measures the mechanism described here directly. The interpretation that a substantial part of the deviations arises from coordination at interfaces being planned too tightly is our own synthesis of these findings and of project experience. The studies themselves do not make this statement.

Research on software development does, however, document a related mechanism. Cataldo and colleagues developed the concept of coordination requirements. According to it, technical and task-related dependencies force certain people to work together. If a suitable communication structure is missing, the so-called socio-technical congruence decreases. This means the gap between the exchange that is technically necessary and the exchange that actually takes place.

MacCormack, Rusnak and Baldwin tested the mirroring hypothesis empirically. Their result is that the architecture of a product and the communication structure of the organisation developing it tend to take the same shape. Technical and organisational modularity are therefore not independent of each other.

Herbsleb and Mockus found that geographically distributed work items in the context studied took about two and a half times as long as comparable items handled at one location. The main reason was an additional need for communication and coordination. The study concerns distributed development teams. Transferring it to suppliers and workstreams is our own interpretation.

Finally, Shahin and colleagues show that coordination cannot simply be removed through architecture. Continuous delivery does not automatically require microservices. What matters are suitable architectural characteristics, small deployment units and early consideration of operational requirements.

The term: Coordination Surface

The coordination surface of a programme comprises all interfaces through which work, information or decisions are handed over between independent units. Such units are workstreams, suppliers, systems and committees. Two properties make the coordination surface relevant for planning.

• It grows with relationships. What matters is the number of connections between the units and less the number of units themselves. A programme with five closely intertwined workstreams has a larger coordination surface than a programme with eight cleanly decoupled ones.
• Diversity makes every interface more expensive. A handover between two teams with the same tool, the same cadence and the same contractual partner costs little. The same handover between two suppliers with different ticket systems, maturity levels and commercial interests costs many times as much, although the delivery effort is the same.

It follows that every decision about the project architecture is also a decision about coordination. The cut of the workstreams, the structure of the suppliers and the committee landscape determine the coordination effort long before the first task is planned.

Six components of the Coordination Surface

The coordination surface is made up of six drivers that can be steered independently of each other.

• Technical dependencies: Which systems, components, data and releases depend on each other?
• Organisational handovers: How often does a work result move between teams, departments or functions?
• Contractual boundaries: Which dependencies run between different suppliers or contracts?
• Ownership distance: How far is the person doing the work from the role that actually decides?
• Frequency of change: How often do requirements, interfaces or technical contracts change?
• Temporal distance: How strongly do time zones or different working rhythms make direct alignment harder?

Steering building blocks by coordination surface

The appropriate steering depends on the size of the coordination surface. More coordination is not always the right answer.

• Low: A cross-functional team aligns directly. Risks and dependencies are steered with little effort, and a dedicated coordination function is not needed.
• Medium: Each interface has a named owner. There is a shared release plan, documented dependencies and a regular alignment between the teams.
• High: A formal dependency board, an integration lead, a shared definition of done, a design authority and coordinated release governance are added. Suppliers and interfaces are steered deliberately.
• Very high: At this level, more coordination no longer helps. The programme has to be broken down differently, with different system boundaries, clearer domains, decoupled release units, fewer supplier interfaces and dedicated instead of shared resources. Coordination has limits. Beyond these limits, a programme does not need a larger meeting apparatus but a different cut.

Application in projects

• Dependency map before capacity planning: Before effort is estimated, workstreams, suppliers, systems and committees are recorded with their relationships. Interfaces with high diversity, for example in tools, contracts or cadence, are marked. That is where the most expensive coordination effort arises.
• Explicit coordination roles: High-volume interfaces receive a named responsibility, for example an integration lead or a vendor coordinator. The expectation that the teams will align themselves is not enough. Otherwise, the project management coordinates unstaffed interfaces on the side, without this effort being visible or budgeted.
• Pricing coordination into planning: Capacity planning shows coordination as a separate item. Its share rises with the number of interfaces recorded instead of being added as a flat surcharge or left out entirely. This also makes architectural decisions comparable, because an additional supplier is then assessed with the costs of its interfaces and not only with its daily rate.

Limits

Coordination surface is a working term from practice and not a validated metric. The coordination costs per interface can rarely be quantified precisely in real programmes. The approach complements effort estimation. It does not replace it. Nor can every interface be avoided through a different design. Some diversity is intended, for example with regulatorily separated systems or a deliberate multi-supplier strategy. In these cases, the point is to price the coordination surface in deliberately instead of reducing it.