Coordination Surface: Wie Schnittstellen und Koordinationsaufwand mit Projektarchitekturen wachsen.

Der Koordinationsaufwand eines Programms wächst nicht mit der Anzahl der Aufgaben, sondern mit der Anzahl und Heterogenität seiner Schnittstellen. Wer Kapazität nur nach Umsetzungsaufwand plant, unterschätzt Koordination systematisch.

Beobachtung

In Programmplanungen wird Kapazität fast immer vom Umsetzungsaufwand her gedacht: Wie viele Personentage kostet die Migration, das Customizing, das Testing? Die Frage, wie viel Kapazität die Abstimmung zwischen den Beteiligten kostet, wird selten gleichrangig gestellt — obwohl in Multi-Vendor-Programmen erfahrungsgemäß ein erheblicher Teil der Programmzeit in Klärungen, Übergaben und Statusabgleichen liegt.

Das Muster zeigt sich besonders deutlich, wenn ein Programm wächst: Ein zusätzlicher Workstream fügt nicht eine Einheit Arbeit hinzu, sondern eine neue Beziehung zu jedem bestehenden Workstream, jedem betroffenen System und jedem Gremium, das ihn steuert. Die Arbeit wächst linear, die Abstimmung nicht. Diese Beobachtung stammt aus eigener Praxis in Programm-Setups und PMO-Mandaten.

Einordnung

Dass große Programme systematisch teurer werden und weniger liefern als geplant, ist gut belegt: Die Untersuchung von Bloch, Blumberg und Laartz (McKinsey & University of Oxford, 2012) über mehr als 5.400 IT-Projekte beziffert die durchschnittliche Budgetüberschreitung großer IT-Programme auf 45 Prozent — bei einem Wertbeitrag, der im Schnitt 56 Prozent unter Plan liegt.¹ Die BCG-Studie von 2024 nennt als eine der zentralen Scheiterursachen das Fehlen eines durchgängigen Master-Plans mit kritischem Pfad und klaren Abhängigkeiten — von mehr als 60 Prozent der befragten Programme angegeben.²

Beide Studien messen die hier beschriebene Mechanik nicht direkt. Die Deutung, dass ein wesentlicher Teil der Abweichungen aus unterplanter Koordination an Schnittstellen entsteht, ist eine eigene Synthese aus diesen Befunden und Projekterfahrung — keine Studienaussage.

Die Software-Engineering-Forschung liefert allerdings direkte Belege für den Mechanismus. Cataldo und Kollegen entwickelten das Konzept der Coordination Requirements: Technische und aufgabenbezogene Abhängigkeiten zwingen bestimmte Personen zur Zusammenarbeit; fehlt eine dazu passende Kommunikationsstruktur, sinkt die „socio-technical congruence" — die Lücke zwischen technisch notwendigem und organisatorisch vorhandenem Austausch.³ MacCormack, Rusnak und Baldwin prüften empirisch die Mirroring Hypothesis: Produktarchitektur und Kommunikationsstruktur der entwickelnden Organisation nehmen tendenziell dieselbe Form an — technische und organisatorische Modularität sind nicht unabhängig voneinander.⁴ Herbsleb und Mockus fanden im untersuchten Kontext, dass geografisch verteilte Arbeitspakete rund zweieinhalbmal so lange dauerten wie vergleichbare, lokal bearbeitete — vor allem durch zusätzlichen Kommunikations- und Koordinationsbedarf.⁵ Und die Studie von Shahin und Kollegen zeigt, dass sich Koordination nicht einfach „wegarchitekturieren" lässt: Continuous Delivery verlangt nicht automatisch Microservices, entscheidend sind passende Architekturmerkmale, kleine Deployment-Einheiten und die frühe Berücksichtigung von Betriebsanforderungen.⁶

Der Begriff: Coordination Surface

Die Coordination Surface — Koordinationsoberfläche — eines Programms ist die Menge aller Schnittstellen, über die Arbeit, Informationen oder Entscheidungen zwischen eigenständigen Einheiten übergeben werden müssen: zwischen Workstreams, Lieferanten, Systemen und Gremien. Zwei Eigenschaften machen sie planungsrelevant:

1. Sie wächst kombinatorisch, nicht additiv. Maßgeblich ist nicht die Anzahl der Einheiten, sondern die Anzahl der Beziehungen zwischen ihnen. Ein Programm mit fünf eng verflochtenen Workstreams hat mehr Koordinationsoberfläche als eines mit acht sauber entkoppelten.
2. Heterogenität verteuert jede Schnittstelle. Eine Übergabe zwischen zwei Teams mit gleichem Tool, gleichem Takt und gleichem Vertragspartner ist billig. Dieselbe Übergabe zwischen zwei Lieferanten mit unterschiedlichen Ticketsystemen, Reifegraden und kommerziellen Interessen ist ein Vielfaches teurer — bei identischem Umsetzungsaufwand.

Die praktische Konsequenz: Projektarchitektur ist Koordinationsdesign. Der Schnitt der Workstreams, die Wahl der Lieferantenstruktur und die Gremienlandschaft legen den Koordinationsaufwand fest, lange bevor die erste Aufgabe geplant ist.

Sechs Komponenten der Coordination Surface

Die Koordinationsoberfläche setzt sich aus mehreren, unabhängig steuerbaren Treibern zusammen:

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

Steuerungsbausteine nach Koordinationsoberfläche

Die passende Steuerung skaliert mit der Oberfläche — mehr Koordination ist nicht immer die richtige Antwort:

• Niedrig. Ein cross-funktionales Team, direkte Abstimmung, leichtgewichtiges Risiko- und Dependency-Management, keine separate Koordinationsfunktion.
• Mittel. Benannte Schnittstellen-Owner, ein gemeinsamer Releaseplan, dokumentierte Abhängigkeiten, ein regelmäßiger Cross-Team-Sync.
• Hoch. Ein formales Dependency Board, ein Integration Lead, eine gemeinsame Definition of Done, eine Design Authority, abgestimmte Release-Governance sowie dediziertes Vendor- und Schnittstellen-Steering.
• Sehr hoch. Hier ist die Antwort nicht mehr Koordination, sondern die Frage nach struktureller Zerlegung: andere Systemgrenzen, klarere Domänenschnitte, entkoppelte Release-Einheiten, weniger Vendor-Schnittstellen, dedizierte statt geteilte Ressourcen. Koordination hat Grenzen — jenseits davon braucht ein Programm keinen größeren Meeting-Apparat, sondern einen anderen Schnitt.

Anwendung in Projekten

• Abhängigkeitslandkarte vor Kapazitätsplanung. Vor der Aufwandsschätzung werden Workstreams, Lieferanten, Systeme und Gremien mit ihren Beziehungen kartiert. Schnittstellen mit hoher Heterogenität — unterschiedliche Tools, Verträge, Taktungen — werden markiert: Dort entsteht der teuerste Koordinationsaufwand.
• Explizite Koordinationsrollen. Schnittstellen mit hohem Volumen erhalten eine benannte Verantwortung (etwa Integration Lead oder Vendor Coordinator) statt der impliziten Erwartung, dass „die Teams sich schon abstimmen“. Unbesetzte Schnittstellen werden sonst faktisch von der Projektleitung mitkoordiniert — unsichtbar und unbudgetiert.
• Koordination in der Planung bepreisen. Kapazitätsplanung weist Koordination als eigene Position aus, deren Anteil mit der kartierten Schnittstellenzahl steigt — statt sie als Pauschalzuschlag oder gar nicht zu führen. Das macht auch Architekturentscheidungen vergleichbar: Ein zusätzlicher Lieferant wird mit seinen Schnittstellenkosten bewertet, nicht nur mit seinem Tagessatz.

Grenzen

Coordination Surface ist ein Arbeitsbegriff aus der Praxis, keine validierte Metrik; eine exakte Quantifizierung („Koordinationskosten pro Schnittstelle“) ist in realen Programmen selten sauber möglich. Der Ansatz ersetzt keine Aufwandsschätzung, sondern ergänzt sie. Und nicht jede Schnittstelle lässt sich wegdesignen: Manche Heterogenität — etwa regulatorisch getrennte Systeme oder bewusste Multi-Vendor-Strategien — ist gewollt. Dann ist das Ziel nicht weniger Oberfläche, sondern bewusst bepreiste.