Das Dashboard ist aktuell.
Der Projektstatus ist rot.
Die Abweichung ist beschrieben.
Alle relevanten Führungskräfte haben die Unterlagen erhalten.
Und trotzdem passiert nichts.
Dieses Szenario klingt paradox.
Schließlich scheint genau das vorhanden zu sein, was gute Projektsteuerung benötigt: Transparenz.
Doch Transparenz und Steuerungsfähigkeit sind nicht dasselbe.
McKinsey beschreibt in einem am 14. September 2026 veröffentlichten Beitrag zur Skalierung agentischer KI genau dieses Problem. In einem Beispiel hatte ein Unternehmen ein Steering Committee eingerichtet, das monatlich Dashboards prüfte – aber keine tatsächliche Befugnis besaß, Budget umzuschichten, den Scope eines Vendors zu ändern oder schwache Workstreams zu stoppen. Die eigentlichen Entscheidungsrechte lagen außerhalb des Gremiums.
McKinsey behandelt das als Problem von AI-Programmen.
Die zugrunde liegende Managementfrage ist jedoch wesentlich älter:
Was nützt ein Steering Committee, wenn es Probleme sehen, aber nicht über ihre Lösung entscheiden kann?
Reporting zeigt ein Problem. Governance entscheidet darüber.
Statusreporting beantwortet Fragen wie:
- Wo stehen wir?
- Welche Meilensteine sind erreicht?
- Welche Risiken sind offen?
- Wie entwickelt sich das Budget?
- Welche Themen benötigen Aufmerksamkeit?
Diese Informationen sind unverzichtbar.
Aber sie lösen noch nichts.
Governance beginnt mit anderen Fragen:
- Wer darf entscheiden?
- Welche Optionen stehen zur Verfügung?
- Bis wann muss die Entscheidung fallen?
- Welche finanziellen, operativen oder vertraglichen Konsequenzen hat sie?
- Wer setzt sie anschließend um?
- Wie wird überprüft, ob sie gewirkt hat?
Damit besteht ein fundamentaler Unterschied zwischen Information und Entscheidungsfähigkeit.
Ein Projekt kann hervorragend reportet und trotzdem schlecht gesteuert sein.
Die rote Ampel ist kein Steuerungsinstrument
Eine rote Ampel hat zunächst nur eine Bedeutung:
Hier besteht eine Abweichung.
Sie sagt nicht automatisch,
warum diese Abweichung entstanden ist, wie groß ihre wirtschaftliche Wirkung ist, welche Handlungsoptionen existieren, wer zwischen ihnen entscheiden darf oder bis wann entschieden werden muss.
Genau deshalb können Projekte wochenlang „rot“ sein.
Das Problem ist bekannt.
Die Ursache ist bekannt.
Vielleicht ist sogar die Lösung bekannt.
Doch die Entscheidung hängt bei einer Person, die im Gremium nicht sitzt. Oder Procurement muss zunächst einen Vendor-Scope prüfen. Finance muss Budget freigeben. Der Fachbereich muss eine Priorität setzen. Ein Sponsor ist nicht verfügbar.
Die Ampel funktioniert.
Die Governance nicht.
Entscheidungslatenz ist ein eigenes Projektrisiko
Projektorganisationen beschäftigen sich intensiv mit Ausführungsdauer.
Wie lange dauert Entwicklung? Wie lange dauert Migration? Wie lange dauert Testing? Wie lange dauert eine Freigabe?
Weniger sichtbar ist häufig die Zeit zwischen Problem und Entscheidung.
Nehmen wir an, ein externer Dienstleister meldet, dass der vereinbarte Scope innerhalb des Budgets nicht mehr vollständig geliefert werden kann.
Technisch ist die Abweichung erkannt.
Jetzt müssen vielleicht drei Optionen bewertet werden:
- zusätzliches Budget freigeben,
- Scope reduzieren,
- einen Meilenstein verschieben.
Wenn die Entscheidung drei Wochen dauert, hat das Projekt drei Wochen lang kein technisches Informationsproblem.
Es hat ein Governanceproblem.
Denn während dieser Zeit laufen Kosten möglicherweise weiter, Ressourcen bleiben reserviert und nachgelagerte Arbeitspakete warten.
Nicht nur eine falsche Entscheidung kostet Geld. Auch eine zu späte Entscheidung kann teuer werden.
McKinseys Warnung: Governance, die nur reportet
McKinsey identifiziert in seiner aktuellen Analyse aus eigenen Transformationsprojekten mehrere wiederkehrende Probleme bei der Einführung agentischer KI. Eines davon bezeichnet die Beratung sinngemäß als Governance, die berichtet, aber nicht kontrolliert.
Besonders relevant sind dabei drei Punkte:
Erstens: Das Steering Committee erhält Informationen, besitzt aber nicht zwingend die notwendigen Entscheidungsrechte.
Zweitens: Entscheidungsrechte können bei Sponsoren oder Führungskräften liegen, die im entscheidenden Moment nicht Teil des Gremiums sind.
Drittens: Der Governance-Rhythmus kann zu langsam sein, sodass Probleme bereits mehrere Iterationen weitergewandert sind, bevor sie formal entschieden werden.
Das sind McKinsey-Beobachtungen aus der eigenen Beratungspraxis, keine repräsentative Studie zur Qualität von Steering Committees.
Als Managementhypothese sind sie dennoch hochrelevant.
Denn dieselbe Logik lässt sich auf nahezu jedes komplexe Multi-Supplier-Projekt übertragen.
Fünf Merkmale einer entscheidungsfähigen Projektgovernance
Ein Steering Committee wird nicht dadurch wirksam, dass die richtigen Titel am Tisch sitzen.
Es benötigt eine konkrete Entscheidungsarchitektur.
1. Jedes kritische Signal braucht einen Owner
Nicht jede Abweichung gehört automatisch ins Steering Committee.
Aber für jedes relevante Risiko sollte klar sein:
Wer trägt Verantwortung dafür, dass daraus eine Entscheidung entsteht?
Ein Owner ist nicht zwangsläufig die Person, die allein entscheiden darf.
Aber sie sorgt dafür, dass die Frage nicht zwischen Funktionen liegen bleibt.
2. Entscheidungsrechte müssen vor der Eskalation klar sein
Wer darf Budget verschieben?
Wer darf einen Lieferumfang reduzieren?
Wer darf einen externen Anbieter zusätzlich beauftragen?
Wer darf einen Workstream stoppen?
Wer darf einen Meilenstein verschieben?
Wenn diese Fragen erst diskutiert werden, nachdem das Problem eingetreten ist, beginnt die Eskalation mit Organisationsklärung.
Das kostet Zeit.
3. Jede Eskalation braucht eine Deadline
„Bitte im Steering Committee besprechen“ ist noch kein Entscheidungsprozess.
Besser ist:
Entscheidung erforderlich bis Freitag, 12 Uhr, weil danach Meilenstein B nicht mehr gehalten werden kann.
Damit wird aus einem offenen Punkt ein steuerbares Managementereignis.
4. Entscheidungen brauchen echte Optionen
Ein Steering Committee sollte nicht nur erfahren, dass das Budget überschritten wird.
Es sollte verstehen:
Welche Optionen bestehen und was bedeutet jede davon?
Zum Beispiel:
- +80.000 Euro Budget, Termin bleibt unverändert.
- Scope-Paket C entfällt, Budget bleibt stabil.
- Termin verschiebt sich um vier Wochen.
- Supplier-Scope wird aufgeteilt.
Damit kann das Management tatsächlich steuern.
5. Entscheidung und Umsetzung müssen verbunden bleiben
Ein Beschluss ist nicht automatisch umgesetzt.
Deshalb muss nach jeder wesentlichen Entscheidung sichtbar bleiben:
- Was wurde beschlossen?
- Wer setzt es um?
- Bis wann?
- Welche Kosten-, Termin- oder Scope-Änderung entsteht?
- Woran erkennen wir, ob die Maßnahme funktioniert?
Governance endet nicht mit dem Sitzungsprotokoll.
Das einfachste Steuerungsmodell: SIGNAL → OWNER → ENTSCHEIDUNG → TERMIN → MASSNAHME
Komplexe Projekte benötigen oft komplexe Daten.
Die Entscheidungslogik dahinter kann trotzdem einfach bleiben.
SIGNAL
Was ist passiert?
Budgetabweichung, Terminrisiko, Qualitätsproblem, fehlende Ressource, Supplier-Verzug oder Scope-Änderung.
OWNER
Wer sorgt dafür, dass die Frage entscheidungsfähig gemacht wird?
ENTSCHEIDUNGSRECHT
Wer darf verbindlich zwischen den Optionen wählen?
TERMIN
Bis wann muss entschieden werden, damit noch gehandelt werden kann?
MASSNAHME
Was verändert sich nach der Entscheidung konkret?
Diese fünf Elemente machen aus einem roten Status eine steuerbare Abweichung.
Besonders kritisch wird Governance bei mehreren Dienstleistern
In Multi-Supplier-Projekten kommt eine zusätzliche Dimension hinzu.
Ein Problem lässt sich dann nicht immer einem einzigen Team zuordnen.
Beispielsweise:
Ein Implementierungspartner wartet auf Daten des internen Teams.
Das interne Team wartet auf eine Schnittstelle eines Softwareproviders.
Der Provider verweist auf eine offene Change-Request-Freigabe.
Procurement wartet auf die kaufmännische Bewertung.
Finance wartet auf eine belastbare Kostenauswirkung.
Jede einzelne Position kann nachvollziehbar sein.
In Summe steht das Projekt.
Dann hilft es wenig, wenn jeder Beteiligte seinen eigenen Status korrekt meldet.
Das Management benötigt eine gemeinsame Sicht darauf:
Welche Abhängigkeit blockiert das Ergebnis, welche Optionen existieren, wer darf entscheiden und was kostet weiteres Warten?
Genau hier treffen Projektsteuerung und Supplier Governance aufeinander.
Gute Governance braucht nicht mehr Meetings
Wenn Entscheidungen zu lange dauern, lautet eine häufige Reaktion:
mehr Abstimmung.
Ein zusätzlicher Jour fixe. Ein wöchentliches Managementmeeting. Ein neues Eskalationsformat.
Das kann sinnvoll sein.
Aber zusätzliche Meetings lösen kein fehlendes Entscheidungsrecht.
Ein Gremium, das dreimal pro Woche tagt und nichts entscheiden darf, ist nicht automatisch wirksamer als eines, das einmal im Monat tagt.
Die bessere Frage lautet:
Welche Entscheidung muss in welchem Rhythmus tatsächlich möglich sein?
Kritische operative Themen benötigen möglicherweise schnelle Eskalationswege.
Strategische Portfolioentscheidungen können in einem anderen Rhythmus getroffen werden.
Governance sollte sich deshalb an der notwendigen Entscheidungsgeschwindigkeit orientieren – nicht an einem historisch gewachsenen Meetingkalender.
KI macht das Problem sichtbarer, aber sie erzeugt es nicht
Der aktuelle McKinsey-Beitrag beschäftigt sich mit agentischer KI.
Das ist der Anlass.
Es ist aber nicht der Kern dieses Artikels.
Denn auch ohne KI scheitern Projekte an:
unklaren Zuständigkeiten, langwierigen Freigaben, getrennten Datenständen, Supplier-Abhängigkeiten, Budgetgrenzen und Entscheidungen, die zu spät getroffen werden.
Agentische Systeme können diese Schwäche verstärken, weil Prozesse schneller laufen und mehr Entscheidungen automatisiert vorbereitet oder ausgelöst werden.
PMI betont in seinem 2026 veröffentlichten AI-Standard deshalb ebenfalls klare menschliche Verantwortlichkeit, definierte Punkte für menschliches Urteil und eindeutige Eskalationswege.
Die Grundregel gilt aber für jedes Projekt:
Wer informiert ist, ist noch nicht automatisch entscheidungsfähig.
Welche Informationen ein Steering Committee wirklich benötigt
Ein gutes Steering Committee braucht nicht zwingend mehr Daten.
Es braucht die richtigen Verbindungen zwischen Daten.
Bei einer kritischen Abweichung sollten mindestens folgende Fragen beantwortbar sein:
- Welches Projektziel ist betroffen?
- Welche konkrete Abweichung liegt vor?
- Welcher Supplier oder welches Team ist beteiligt?
- Welche Abhängigkeiten bestehen?
- Welche Budgetwirkung entsteht?
- Welche Terminwirkung entsteht?
- Welche Optionen gibt es?
- Wer besitzt das Entscheidungsrecht?
- Bis wann muss entschieden werden?
- Was passiert, wenn nicht entschieden wird?
Das ist deutlich mehr als ein Ampelstatus.
Aber es ist weniger komplex als ein hundertseitiges Monatsreporting.
Project Intelligence verbindet Information mit Entscheidung
Aus Ramp7-Perspektive liegt der entscheidende Schritt deshalb nicht darin, noch ein weiteres Dashboard bereitzustellen.
Project Intelligence betrachtet Projekte, externe Leistungen, Budgets, Risiken und Managemententscheidungen in ihrem Zusammenhang.
Die relevante Kette lautet:
SIGNAL → KONTEXT → VERANTWORTUNG → ENTSCHEIDUNG → MASSNAHME
Eine Budgetabweichung ohne Supplier-Kontext ist unvollständig.
Ein Supplier-Risiko ohne Projektwirkung ist unvollständig.
Ein Projektproblem ohne Entscheidungsverantwortung ist unvollständig.
Und ein Dashboard ohne Handlungsmöglichkeit bleibt Reporting.
Daraus folgt ausdrücklich nicht, dass Ramp7 automatisch Eskalationen auslöst, Realtime-Alerts versendet, Entscheidungsrechte verwaltet oder Projektprobleme prognostiziert. Solche Produktclaims benötigen eine gesonderte Product-Owner-Freigabe.
Die Managementperspektive ist allgemeiner:
Transparenz schafft nur dann Wert, wenn sie rechtzeitig zu einer Entscheidung führt.
Acht Fragen für das nächste Steering Committee
Bevor der nächste Statusbericht diskutiert wird, können Führungskräfte ihre Governance mit acht Fragen testen:
- Welche drei Entscheidungen müssen in diesem Meeting tatsächlich getroffen werden?
- Sitzen die Personen mit den erforderlichen Entscheidungsrechten im Raum?
- Ist für jede Eskalation ein klarer Owner benannt?
- Ist sichtbar, welche Kosten-, Termin- und Supplier-Auswirkungen jede Option hat?
- Gibt es für jede kritische Entscheidung eine Deadline?
- Können Scope- oder Vendor-Entscheidungen getroffen werden, ohne eine weitere Gremienrunde abzuwarten?
- Wird nachverfolgt, ob frühere Entscheidungen tatsächlich umgesetzt wurden?
- Wissen wir, welche Konsequenz entsteht, wenn heute keine Entscheidung fällt?
Wenn ein Steering Committee diese Fragen nicht beantworten kann, fehlt möglicherweise nicht Reporting.
Es fehlt Governance.
Fazit: Die wichtigste Spalte im Dashboard heißt nicht Status
Die aktuelle McKinsey-Analyse bringt ein verbreitetes Projektproblem sehr prägnant auf den Punkt:
Ein Steering Committee kann regelmäßig tagen, professionelle Dashboards erhalten und trotzdem zu wenig Kontrolle über das Programm besitzen, wenn ihm reale Entscheidungsrechte und funktionierende Eskalationswege fehlen.
Der aktuelle Anlass ist Agentic AI.
Die Managementlektion ist zeitlos.
Projektgovernance ist nicht die Organisation von Statusmeetings.
Sie ist die Organisation von Entscheidungen.
Deshalb sollte neben Kosten, Timing, Scope, Qualität und Risiko immer eine weitere Frage sichtbar sein:
Wer muss was bis wann entscheiden, damit das Projekt steuerbar bleibt?
Erst wenn diese Antwort eindeutig ist, wird aus Transparenz tatsächliche Projektsteuerung.