Multi-Team Project Management at Enterprise Scale

This is uncomfortable, because restructuring is harder than adopting a framework. But a coordination mechanism applied to a structure that generates hundreds of dependencies manages the symptom while the cause continues producing more.

Quick answer: The defining problem at enterprise scale is not team performance — it is the volume of dependencies between teams, and dependency volume is largely determined by how teams are organised. The most effective intervention is almost always reducing dependencies through team design rather than adding coordination mechanisms to manage them.

The Real Problem at Scale

Individual teams usually work fine. What fails is the coordination between them, and the volume of that coordination is a consequence of structure.

Dependencies, not team performance

Ask any organisation of a thousand people where delivery slows, and the answer is between teams rather than within them. Work waits for another team, an assumption differs, an interface changes without warning.

Each team can be performing well and the aggregate still delivers slowly. That is a systems problem, and treating it as a team performance problem produces pressure without improvement.

Why adding coordination rarely helps

Coordination mechanisms — synchronised planning, dependency boards, programme roles — make dependencies visible and manageable. They do not remove them.

Adding coordination to a high-dependency structure raises the ceiling slightly and adds permanent overhead. The dependencies keep arriving because the thing generating them has not changed.

The uncomfortable first question

Before adopting any scaling framework, ask why so many dependencies exist.

If the answer is that teams are organised by technical layer — frontend, backend, database, QA — then every feature crosses several teams by construction. That is a structural choice producing a coordination problem, and no framework fixes it.

Coordination Mechanisms Compared

Mechanism Effort Removes dependencies?

Best for

Restructure around outcomes High, one-off Yes Any organisation generating avoidable dependencies Platform teams Medium, ongoing Partially Shared capabilities many teams need Scrum of scrums Very low No 3–6 teams, light coordination Dependency board Low No Making existing

Making Dependencies Visible and Owned

Synchronised quarterly planning Medium No Many teams, one product SAFe or similar framework High, ongoing No Large scale, one product, formal governance Portfolio management layer Medium No Cross-portfolio prioritisation

Reducing Dependencies Before Managing Them

Team boundaries determine how many dependencies exist, platform teams absorb shared needs, and where restructuring is impossible you manage what remains deliberately.

Team boundaries determine dependency count

A team organised around a customer journey or product area can deliver end to end. A team organised around a technical layer cannot deliver anything alone.

Restructuring around outcomes eliminates dependencies rather than scheduling them. It is politically harder than adopting a framework and considerably cheaper operationally, because every dependency you remove is permanent savings rather than a recurring coordination cost.

Platform teams and internal products

Where several teams need the same capability — authentication, deployment, data access — a platform team providing it as a self-service internal product removes the need for each team to request work.

The distinction that matters is self-service versus request. A platform team that takes tickets is a dependency; one that provides something teams can consume without asking is not.

When restructuring is not available

Sometimes it genuinely is not — regulatory separation, contractual structure, or organisational politics that will not move this year.

In that case, manage dependencies explicitly and thoroughly, and keep the structural argument alive. Many organisations adopt a scaling framework, spend two years on coordination overhead, and eventually restructure anyway.

Making Dependencies Visible and Owned Record cross-team dependencies as explicit commitments with owners on both sides, and track the ones that are late as the primary programme risk.

Record them as commitments, not notes

A dependency written as "waiting on platform team" is a note. Written as "Platform team to deliver v2 auth endpoint by 14 March, owner named, consumed by checkout team" it is a commitment.

The difference is that a commitment can be tracked, chased and escalated. Where the tool supports linking work across projects, dependencies exist as real relationships rather than as text someone has to remember to update.

Name an owner on both sides

Every dependency needs someone accountable for delivering it and someone accountable for consuming it.

Dependencies owned by a team rather than a person stall, because everyone assumes someone else is handling it. This is the single most common reason a dependency is discovered late.

Track the ones that are late

A weekly view of dependencies past their agreed date is the most useful programme-level artefact available.

It concentrates attention on the small number of things genuinely blocking progress, rather than on a status report describing everything. Most programme-level reporting fails by covering everything and surfacing nothing.

Planning and Reporting Across Teams

Synchronise planning periodically without necessarily adopting a full framework, derive the portfolio view from team data rather than maintaining it separately, and report in a form that survives aggregation.

Synchronised planning without a framework

Getting all teams planning the same quarter at the same time, in one place, surfaces dependencies while there is still time to act on them.

You can run this without adopting a framework: a planning day each quarter, a shared board of dependencies, and a commitment from each team. Many organisations that adopted SAFe would have been served by this alone.

One portfolio view, derived not maintained

The failure pattern is a portfolio view maintained separately from team data, updated by someone weekly, and permanently slightly wrong.

Derive it. If the portfolio view is a rollup of the same tasks teams are actually working on, it is current by construction. Where a platform supports portfolio-level dashboards over the same underlying work, this stops being a reporting job and becomes a view.

Reporting that survives aggregation

Detail does not aggregate well. Twelve teams' task-level status compiled into one document is unreadable and unactionable.

Report at the level executives can act on: milestone status, dependencies at risk, decisions required. The detail stays available for anyone who wants to drill in, but the summary must be short enough to be read.

Common Enterprise Scaling Mistakes

The three errors are adopting a framework to avoid restructuring, standardising process rather than interfaces, and producing reporting nobody can act on.

Adopting a scaling framework to avoid restructuring

The most expensive mistake in this space. A framework manages dependencies; it does not remove them, and the structure keeps generating more.

Frameworks are legitimate where dependencies are genuinely irreducible. Adopted as an alternative to fixing team design, they institutionalise the problem.

Standardising process instead of interfaces

Mandating one process across every team optimises for consistency and against fit.

Engineering, support and operations have genuinely different demand patterns.

Standardise the interfaces — how teams request work from each other, how dependencies are recorded, how status is reported — and let each team choose its internal process.

Reporting that nobody can act on

Programme reporting frequently becomes a monthly document describing everything, read by nobody, produced at considerable cost.

The test for any report is what decision it informs. Reports that inform no decision should be stopped, and the resulting objection reveals whether anyone was actually using them.