Komplexität sieht auf einem Projektboard erstaunlich harmlos aus

Backlog gepflegt. Meilenstein grün. Budget im Rahmen. Steering Committee vorbereitet.

Und trotzdem kippt drei Wochen später der Go-live.

Dieses Muster ist in IT-Projekten nicht ungewöhnlich. Der Grund ist selten, dass niemand Aufgaben gepflegt hat. Komplexe Projekte scheitern eher daran, dass Zusammenhänge zu spät sichtbar werden.

PMI widmet seinen Pulse of the Profession 2026 genau diesem Thema. Laut PMI berichten 97 Prozent der befragten Projektprofessionals, im vergangenen Jahr mindestens ein komplexes Projekt gesteuert zu haben. Rund ein Drittel komplexer Projekte scheitert; PMI beschreibt die Fehlerrate als beinahe doppelt so hoch wie bei Projekten insgesamt.

Die interessante Schlussfolgerung ist für mich nicht: „Komplexe Projekte brauchen mehr Projektmanagement.“

Sondern:

Komplexe Projekte brauchen weniger Illusion von Kontrolle und mehr Systemtransparenz.

Der grüne Status ist manchmal Teil des Problems

Ein Statusbericht komprimiert Realität.

Das ist notwendig. Ein Steering Committee kann nicht 500 Tasks durchgehen. Aber jede Verdichtung birgt das Risiko, dass relevante Unsicherheit verschwindet.

Ein Projekt kann grün sein, obwohl:

  • zehn Entscheidungen offen sind,
  • ein externer Lieferant zwei Wochen Verzug hat,
  • Testdaten fehlen,
  • der Fachbereich den Zielprozess unterschiedlich versteht,
  • die Schnittstelle technisch fertig, aber fachlich nicht getestet ist,
  • Key User im Go-live-Monat nicht verfügbar sind.

Keiner dieser Punkte muss heute einen Meilenstein verletzt haben.

Gemeinsam können sie den nächsten Meilenstein unmöglich machen.

Deshalb sollte Projektstatus nicht nur fragen:

„Sind wir im Plan?“

Sondern auch:

„Welche Annahmen müssen wahr bleiben, damit der Plan noch realistisch ist?“

Komplexität entsteht zwischen den Arbeitspaketen

Viele Tools sind hervorragend darin, einzelne Tasks abzubilden.

Komplexität entsteht jedoch häufig in Beziehungen:

  • Prozess A braucht Daten aus System B.
  • System B kann erst getestet werden, wenn Lieferant C liefert.
  • Lieferant C wartet auf eine Entscheidung des Managements.
  • Das Management entscheidet erst, wenn Fachbereich D die Kostenwirkung kennt.
  • Fachbereich D hat gerade keine Kapazität.

Jeder einzelne Task kann korrekt geplant sein. Das System ist trotzdem blockiert.

Genau deshalb müssen komplexe Projekte Abhängigkeiten als First-Class-Objekte behandeln und nicht als Randnotiz im Projektplan.

Systemlandkarte eines komplexen Projekts mit Business, IT, Daten, Lieferanten, Entscheidungen und Abhängigkeiten.

Vier Ebenen, die ich separat steuern würde

1. Delivery

Was wird konkret geliefert? Welche Meilensteine, Ergebnisse und Akzeptanzkriterien gelten?

2. Decisions

Welche Entscheidungen sind offen? Wer entscheidet? Bis wann? Welche Konsequenz hat eine Verzögerung?

3. Dependencies

Welche internen und externen Abhängigkeiten gefährden Delivery?

4. Adoption & Value

Wird das Ergebnis später tatsächlich genutzt und erzeugt es den erwarteten Nutzen?

Viele Projekte steuern Ebene 1 gut und behandeln 2 bis 4 eher informell.

Dort entsteht die Lücke zwischen „Projektstatus grün“ und „Realität rot“.

Entscheidungsstau ist technische Schuld im Projektmanagement

Offene Entscheidungen verhalten sich ähnlich wie technische Schulden.

Man kann sie eine Zeit lang ignorieren. Die Kosten erscheinen später.

Beispiel:

Die Entscheidung über einen Zielprozess wird vier Wochen verschoben. Das technische Team baut deshalb mit Annahmen weiter. Später fällt die Entscheidung anders. Jetzt müssen Konfiguration, Tests, Dokumentation und Training angepasst werden.

Aus einer verspäteten Entscheidung wird Rework in mehreren Streams.

Deshalb sollte jedes grössere Projekt ein sichtbares Decision Log führen:

  • Entscheidung
  • Optionen
  • Empfehlung
  • Entscheidungsträger
  • Deadline
  • Auswirkung bei Verzögerung
  • Status

Nicht als Bürokratie, sondern als Delivery-Instrument.

Was AI im Projektmanagement sinnvoll übernehmen kann

2026 ist AI längst auch im Projektmanagement angekommen. PMI hat im Juni 2026 einen eigenen globalen Standard für AI in Portfolio-, Programm- und Projektmanagement veröffentlicht. Das zeigt, dass AI nicht mehr nur ein persönliches Produktivitätstool ist, sondern zunehmend Teil professioneller Projekt-Governance wird.

Ich sehe mehrere sinnvolle Aufgaben für AI:

Statusinformationen verdichten

Aus Jira, Meeting Notes, Risk Logs und Entscheidungslisten einen Management-Entwurf erstellen.

Widersprüche finden

Ein Meilenstein ist grün, aber drei kritische Abhängigkeiten sind überfällig. AI kann solche Muster sichtbar machen.

Meeting-Vorbereitung

Offene Entscheidungen, Risiken und Follow-ups aus den letzten Sitzungen zusammenstellen.

Change Impact vorbereiten

Welche Stakeholder, Prozesse und Dokumente sind von einer Entscheidung betroffen?

Dokumentation

Decision Records, Minutes, Actions und Statusentwürfe automatisch vorbereiten.

Aber AI sollte keine falsche Sicherheit erzeugen.

Eine gute Zusammenfassung ist nicht automatisch ein gutes Projektverständnis.

Was AI nicht ersetzt: Business Acumen

PMI betonte bereits im Pulse 2025 Business Acumen als wichtigen Differenzierungsfaktor für Projektprofessionals. Das halte ich für entscheidend.

Ein Projektleiter muss verstehen:

  • Warum machen wir das Projekt?
  • Wo entsteht Business Value?
  • Welche Konsequenz hat eine Verzögerung?
  • Welche Lösung ist „gut genug“?
  • Welche Risiken sind für das Geschäft relevant?
  • Wann lohnt sich zusätzliche Komplexität nicht mehr?

AI kann Daten aufbereiten. Die Einordnung in Unternehmensrealität bleibt eine Führungsaufgabe.

Zehn Warnsignale, die ich ernster nehme als einen grünen Status

1. Entscheidungen haben kein Fälligkeitsdatum

Dann sind sie Wünsche, keine Steuerungspunkte.

2. Kritische Abhängigkeiten haben keinen Owner

„IT wartet auf Fachbereich“ ist kein Owner-Modell.

3. Scope wird über Beispiele statt Akzeptanzkriterien erklärt

Dann verstehen Beteiligte wahrscheinlich unterschiedliche Dinge.

4. Statusberichte zeigen nur Vergangenheit

Ein guter Status muss auch Forecast und Unsicherheit zeigen.

5. Risiken bleiben über Wochen identisch

Entweder werden sie nicht aktiv gesteuert oder das Risk Log ist nur Dokumentation.

6. Key User fehlen in Design und Test

Das rächt sich meist im Go-live.

7. Alles ist Priorität 1

Dann existiert keine echte Priorisierung.

8. Der Go-live-Termin ist fix, aber Scope und Ressourcen bleiben variabel

Mindestens eine Dimension muss realistisch steuerbar sein.

9. Meetings berichten viel und entscheiden wenig

Das Projekt produziert Kommunikation statt Fortschritt.

10. Grün basiert auf Gefühl statt Evidenz

„Wir sollten das schaffen“ ist kein belastbarer Forecast.

Illustrativer Business Case: Multi-System-Rollout

Ein Unternehmen führt eine neue Business Application ein. Gleichzeitig werden zwei Schnittstellen erneuert, Daten migriert und mehrere Fachprozesse verändert.

Das Projektboard zeigt die meisten Streams grün.

Tatsächlich bestehen folgende Abhängigkeiten:

  • Migration benötigt bereinigte Stammdaten.
  • Stammdatenbereinigung hängt an Fachbereichen.
  • Integrationstest benötigt eine externe Testumgebung.
  • Externer Partner wartet auf Spezifikation.
  • Spezifikation hängt an einem noch offenen Prozessentscheid.

Die klassische Task-Sicht zeigt fünf Themen.

Eine System-Sicht zeigt eine Kette.

Der Projektleiter stellt deshalb die Steuerung um:

  1. Kritische End-to-End-Szenarien definieren.
  2. Abhängigkeiten zwischen Streams visualisieren.
  3. Entscheidungen mit Deadline und Impact führen.
  4. Readiness je Go-live-Dimension messen: Daten, Prozess, Technik, Menschen, Support.
  5. Status nicht nach Team, sondern nach End-to-End-Fähigkeit berichten.

Plötzlich wird sichtbar, dass „80 Prozent fertig“ nicht bedeutet, dass ein einziger Geschäftsprozess vollständig go-live-ready ist.

Das ist unbequem – aber steuerbar.

Change ist kein Kommunikationsstream am Ende

Komplexe IT-Projekte verändern fast immer Arbeit.

Neue Rollen, neue Kontrollen, neue Masken, andere Verantwortlichkeiten oder andere Entscheidungswege.

Wenn Change erst kurz vor Training und Go-live beginnt, ist es zu spät.

Change Leadership sollte bereits während Design und Entscheidungsfindung stattfinden:

  • Betroffene früh einbinden.
  • Auswirkungen konkret machen.
  • Widerstände als Information verstehen.
  • Key User als Übersetzer zwischen Projekt und Alltag nutzen.
  • Feedback sichtbar in Entscheidungen zurückführen.

Das reduziert nicht jede Diskussion. Es reduziert Überraschungen.

Ein besseres Steering Committee

Ich würde ein Steering nicht mit 30 Minuten Statusfolien füllen.

Die Kernfragen sollten sein:

  1. Was hat sich seit dem letzten Steering relevant verändert?
  2. Welche drei Entscheidungen brauchen wir heute?
  3. Welche Annahmen gefährden den aktuellen Forecast?
  4. Welche Abhängigkeit benötigt Management-Unterstützung?
  5. Hat sich der Business Case verändert?

Alles andere kann im Pre-Read stehen.

Managementzeit sollte für Managemententscheidungen verwendet werden.

Ein Projekt-Cockpit, das ich 2026 sinnvoll finde

Ein modernes Cockpit sollte nicht nur Ampelfarben anzeigen. Es sollte sechs Perspektiven verbinden:

Delivery Forecast

Was wird wann voraussichtlich fertig – inklusive Confidence, nicht nur Plantermin.

Decision Debt

Wie viele kritische Entscheidungen sind offen und wie lange bereits?

Dependency Health

Welche Abhängigkeiten liegen ausserhalb der direkten Kontrolle des Teams?

Business Readiness

Sind Prozess, Daten, Menschen, Support und Betrieb bereit – nicht nur die Software?

Value

Sind die ursprünglichen Nutzenannahmen noch gültig?

Change Pulse

Wo gibt es Widerstand, Unsicherheit oder fehlende Adoption?

AI kann helfen, Signale aus mehreren Quellen zusammenzuführen. Die Ampel sollte aber aus nachvollziehbaren Kriterien entstehen und nicht aus einem generierten Bauchgefühl.

Wie AI im PMO konkret eingesetzt werden kann

Ein AI-gestütztes PMO könnte wöchentlich:

  1. Statusberichte, Backlog und Decisions einlesen.
  2. neue Risiken und Widersprüche markieren.
  3. überfällige Entscheidungen priorisieren.
  4. Steering-Pre-Read entwerfen.
  5. Änderungen zum letzten Reporting hervorheben.
  6. offene Actions je Owner zusammenfassen.

Der Projektleiter prüft und ergänzt Kontext. So wird AI zum Sensor und Redaktionsassistenten – nicht zum Projektverantwortlichen.

Fragen, die ich in einem Projekt-Health-Check stellen würde

  • Können drei Schlüsselpersonen unabhängig voneinander denselben Zielzustand erklären?
  • Welche fünf Entscheidungen gefährden aktuell den kritischen Pfad?
  • Welche Abhängigkeit hat den schwächsten Owner?
  • Welche Annahme im Plan wurde seit Projektstart nie validiert?
  • Welche Go-live-Voraussetzung ist technisch nicht als Task sichtbar?
  • Wo gibt es bereits Rework?
  • Welcher Scope-Teil erzeugt am wenigsten Business Value?
  • Welche Stakeholder werden heute nur informiert statt eingebunden?
  • Was würde passieren, wenn der Go-live um vier Wochen verschoben wird?
  • Woran erkennt der Kunde oder Fachbereich sechs Monate später, dass das Projekt erfolgreich war?

Die Antworten zeigen oft mehr über Projektrisiko als ein perfektes Gantt-Diagramm.

Fazit: Projektsteuerung ist Systemsteuerung

Komplexe Projekte lassen sich nicht vollständig kontrollieren. Aber sie lassen sich besser verstehen.

Tools, Boards und AI helfen dabei. Sie ersetzen jedoch nicht die Fähigkeit, Beziehungen zwischen Entscheidungen, Menschen, Daten, Systemen und Business Value zu erkennen.

Der wichtigste Status ist deshalb nicht die Farbe im Dashboard.

Der wichtigste Status lautet:

„Verstehen wir heute, was unseren nächsten wichtigen Projekterfolg verhindern könnte – und tun wir aktiv etwas dagegen?“

Wenn diese Frage ehrlich beantwortet wird, wird Projektmanagement zu echter Delivery Leadership.