Der Koordinationsaufwand eines Programms hängt weniger von der Zahl der Aufgaben ab als von der Zahl und Verschiedenheit seiner Schnittstellen. Wer Kapazität nur nach dem Umsetzungsaufwand plant, unterschätzt die Koordination regelmäßig.
Kernaussagen
  • Zwei Programme mit gleichem Umsetzungsaufwand können sehr unterschiedlich viel Steuerung brauchen. Das hängt davon ab, wie viele Workstreams, Lieferanten, Systeme und Gremien miteinander verbunden sind.
  • Diese Koordinationsoberfläche wird in klassischen Planungen selten ausdrücklich eingepreist. Sie zeigt sich später als Verzögerung, Doppelarbeit und Eskalation.
  • Das Arbeitsmodell schlägt vor, Schnittstellen als eigene Planungsgröße zu behandeln. Dazu gehören eine Abhängigkeitslandkarte, ausdrückliche Koordinationsrollen und ein eigener Anteil für Koordination in der Kapazitätsplanung.

Beobachtung

In Programmplanungen wird Kapazität fast immer vom Umsetzungsaufwand her geplant. Gefragt wird, wie viele Personentage die Migration, das Customizing oder das Testing kosten. Wie viel Kapazität die Abstimmung zwischen den Beteiligten kostet, wird selten mit gleichem Gewicht gefragt. Nach eigener Erfahrung entfällt in Programmen mit mehreren Lieferanten jedoch ein erheblicher Teil der Zeit auf Klärungen, Übergaben und Statusabgleiche.

Besonders deutlich wird das Muster, wenn ein Programm wächst. Ein zusätzlicher Workstream bringt nicht nur zusätzliche Arbeit. Er schafft auch neue Beziehungen zu jedem bestehenden Workstream, zu jedem betroffenen System und zu jedem Gremium, das ihn steuert. Die Arbeit wächst linear, die Abstimmung wächst schneller. Diese Beobachtung stammt aus eigener Praxis beim Aufsetzen von Programmen und aus PMO-Mandaten.

Einordnung

Dass große Programme regelmäßig teurer werden und weniger liefern als geplant, ist gut belegt. Bloch, Blumberg und Laartz (McKinsey und University of Oxford, 2012) haben mehr als 5.400 IT-Projekte ausgewertet. Große IT-Programme überschritten ihr Budget danach im Durchschnitt um 45 Prozent und lieferten 56 Prozent weniger Wert als geplant.

In der BCG-Studie von 2024 nennen mehr als 60 Prozent der befragten Programme das Fehlen eines durchgängigen Master-Plans mit kritischem Pfad und klaren Abhängigkeiten als eine zentrale Ursache des Scheiterns.

Keine der beiden Studien misst die hier beschriebene Mechanik direkt. Die Deutung, dass ein wesentlicher Teil der Abweichungen aus zu knapp geplanter Koordination an Schnittstellen entsteht, ist eine eigene Synthese aus diesen Befunden und aus Projekterfahrung. Die Studien selbst treffen diese Aussage nicht.

Die Forschung zur Softwareentwicklung belegt allerdings einen verwandten Mechanismus. Cataldo und Kollegen haben das Konzept der Coordination Requirements entwickelt. Technische und aufgabenbezogene Abhängigkeiten zwingen danach bestimmte Personen zur Zusammenarbeit. Fehlt eine passende Kommunikationsstruktur, sinkt die sogenannte socio-technical congruence. Damit ist die Lücke zwischen dem technisch notwendigen und dem tatsächlich vorhandenen Austausch gemeint.

MacCormack, Rusnak und Baldwin haben die Mirroring Hypothesis empirisch geprüft. Ihr Ergebnis ist, dass die Architektur eines Produkts und die Kommunikationsstruktur der entwickelnden Organisation tendenziell dieselbe Form annehmen. Technische und organisatorische Modularität sind also nicht unabhängig voneinander.

Herbsleb und Mockus fanden, dass geografisch verteilte Arbeitspakete im untersuchten Kontext etwa zweieinhalbmal so lange dauerten wie vergleichbare Pakete, die an einem Ort bearbeitet wurden. Der Hauptgrund war zusätzlicher Bedarf an Kommunikation und Koordination. Die Studie betrifft verteilte Entwicklungsteams. Die Übertragung auf Lieferanten und Workstreams ist eine eigene Einordnung.

Shahin und Kollegen zeigen schließlich, dass sich Koordination nicht einfach durch Architektur beseitigen lässt. Continuous Delivery setzt nicht automatisch Microservices voraus. Wichtig sind passende Architekturmerkmale, kleine Deployment-Einheiten und die frühe Berücksichtigung von Betriebsanforderungen.

Der Begriff: Coordination Surface

Die Coordination Surface oder Koordinationsoberfläche eines Programms umfasst alle Schnittstellen, über die Arbeit, Informationen oder Entscheidungen zwischen eigenständigen Einheiten übergeben werden. Solche Einheiten sind Workstreams, Lieferanten, Systeme und Gremien. Zwei Eigenschaften machen die Koordinationsoberfläche für die Planung relevant.

  • Sie wächst mit den Beziehungen. Maßgeblich ist die Zahl der Verbindungen zwischen den Einheiten und weniger die Zahl der Einheiten selbst. Ein Programm mit fünf eng verflochtenen Workstreams hat eine größere Koordinationsoberfläche als ein Programm mit acht sauber entkoppelten.
  • Verschiedenheit verteuert jede Schnittstelle. Eine Übergabe zwischen zwei Teams mit demselben Tool, demselben Takt und demselben Vertragspartner kostet wenig. Dieselbe Übergabe zwischen zwei Lieferanten mit unterschiedlichen Ticketsystemen, Reifegraden und kommerziellen Interessen kostet ein Vielfaches, obwohl der Umsetzungsaufwand gleich ist.

Daraus folgt, dass jede Entscheidung über die Projektarchitektur zugleich eine Entscheidung über Koordination ist. Der Zuschnitt der Workstreams, die Struktur der Lieferanten und die Gremienlandschaft legen den Koordinationsaufwand fest, lange bevor die erste Aufgabe geplant wird.

Sechs Komponenten der Coordination Surface

Die Koordinationsoberfläche setzt sich aus sechs Treibern zusammen, die sich unabhängig voneinander steuern lassen.

  • Technische Abhängigkeiten: Welche Systeme, Komponenten, Daten und Releases hängen voneinander ab?
  • Organisatorische Übergaben: Wie oft wechselt ein Arbeitsergebnis zwischen Teams, Abteilungen oder Funktionen?
  • Vertragliche Grenzen: Welche Abhängigkeiten verlaufen zwischen verschiedenen Lieferanten oder Verträgen?
  • Ownership-Distanz: Wie weit ist die ausführende Person von der Rolle entfernt, die tatsächlich entscheidet?
  • Änderungsfrequenz: Wie oft ändern sich Anforderungen, Schnittstellen oder technische Verträge?
  • Zeitliche Distanz: Wie stark erschweren Zeitzonen oder unterschiedliche Arbeitsrhythmen die direkte Abstimmung?

Steuerungsbausteine nach Koordinationsoberfläche

Die passende Steuerung richtet sich nach der Größe der Koordinationsoberfläche. Mehr Koordination ist dabei nicht immer die richtige Antwort.

  • Niedrig: Ein funktionsübergreifendes Team stimmt sich direkt ab. Risiken und Abhängigkeiten werden mit wenig Aufwand gesteuert, und eine eigene Koordinationsfunktion ist nicht nötig.
  • Mittel: Jede Schnittstelle hat einen benannten Owner. Es gibt einen gemeinsamen Releaseplan, dokumentierte Abhängigkeiten und einen regelmäßigen Abgleich zwischen den Teams.
  • Hoch: Ein formales Dependency Board, ein Integration Lead, eine gemeinsame Definition of Done, eine Design Authority und eine abgestimmte Release-Governance kommen hinzu. Lieferanten und Schnittstellen werden gezielt gesteuert.
  • Sehr hoch: Auf dieser Stufe hilft mehr Koordination nicht weiter. Das Programm muss anders zerlegt werden, mit anderen Systemgrenzen, klareren Domänen, entkoppelten Release-Einheiten, weniger Schnittstellen zu Lieferanten und eigenen statt geteilten Ressourcen. Koordination hat Grenzen. Jenseits dieser Grenzen braucht ein Programm keinen größeren Meeting-Apparat, sondern einen anderen Zuschnitt.

Anwendung in Projekten

  • Abhängigkeitslandkarte vor der Kapazitätsplanung: Bevor der Aufwand geschätzt wird, werden Workstreams, Lieferanten, Systeme und Gremien mit ihren Beziehungen erfasst. Schnittstellen mit großer Verschiedenheit, etwa bei Tools, Verträgen oder Takt, werden markiert. Dort entsteht der teuerste Koordinationsaufwand.
  • Ausdrückliche Koordinationsrollen: Schnittstellen mit hohem Volumen erhalten eine benannte Verantwortung, zum Beispiel einen Integration Lead oder einen Vendor Coordinator. Die Erwartung, dass sich die Teams schon abstimmen werden, reicht nicht aus. Unbesetzte Schnittstellen koordiniert sonst die Projektleitung nebenbei mit, ohne dass dieser Aufwand sichtbar oder budgetiert ist.
  • Koordination in der Planung einpreisen: Die Kapazitätsplanung weist Koordination als eigene Position aus. Ihr Anteil steigt mit der Zahl der erfassten Schnittstellen, statt pauschal aufgeschlagen oder ganz weggelassen zu werden. Das macht auch Architekturentscheidungen vergleichbar, denn ein zusätzlicher Lieferant wird dann mit den Kosten seiner Schnittstellen bewertet und nicht nur mit seinem Tagessatz.

Grenzen

Coordination Surface ist ein Arbeitsbegriff aus der Praxis und keine validierte Kennzahl. Die Koordinationskosten pro Schnittstelle lassen sich in realen Programmen selten genau beziffern. Der Ansatz ergänzt die Aufwandsschätzung, er ersetzt sie nicht. Auch lässt sich nicht jede Schnittstelle durch eine andere Gestaltung vermeiden. Manche Verschiedenheit ist gewollt, etwa bei regulatorisch getrennten Systemen oder einer bewussten Strategie mit mehreren Lieferanten. In diesen Fällen geht es darum, die Koordinationsoberfläche bewusst einzupreisen, statt sie zu verkleinern.