Projektstatus kontrollieren und anpassen

Mia sucht die aktuellen Zahlen

Mia scrollt durch das Ticketsystem, während die Projektleiterin in die Runde fragt: "Wo stehen wir eigentlich?" Samstag, 10:45 Uhr, Sonder-Statusmeeting zum Shop-Relaunch. Der Gantt-Chart an der Wand ist sechs Wochen alt. Die Datenmigration sollte seit Freitag fertig sein. Ob sie es ist, kann gerade niemand sicher sagen.

Go-Live ist in vier Wochen. Jeder Tag Verzug kostet geschätzt 8.000 Euro entgangenen Umsatz. Das Projektinformationssystem ist die Grundlage für genau diesen Moment: Ohne aktuelle Daten kann Mia keinen Soll-Ist-Vergleich erstellen. Beim Thema Datenaufbereitung hast du Soll-Ist-Vergleiche für Kennzahlen erstellt - jetzt wird das Werkzeug zur Projektsteuerung. Und die Risiken aus der Planungsphase? Die scheinen gerade einzutreten.

🔮 Bevor du weiterliest: Mia hat die aktuellen Zahlen aus dem Ticketsystem gezogen. In welchen drei Dimensionen wird sie Abweichungen finden - und welche hat vermutlich die größte Abweichung?

Drei Abweichungen schwarz auf weiß

Mia vergleicht die Projektplanung mit den aktuellen Daten. Drei Abweichungen fallen sofort auf:

1. Die Datenmigration sollte Freitag KW 44 fertig sein. Zwei Datenbanktabellen fehlen noch. Neuer Termin: Mittwoch KW 45, also +5 Tage Verzug.
2. Der externe Dienstleister für die Schnittstellenprogrammierung war mit 12.000 Euro kalkuliert. Durch Nacharbeiten liegt die Rechnung bei 15.600 Euro, also 30 % über Plan.
3. Das Personalisierungsfeature sollte komplett in Release 1 enthalten sein. Fertig ist nur die Basisversion. 60 % des geplanten Funktionsumfangs fehlen.

Die Tabelle mit Soll-, Ist- und Differenzspalte macht das Ausmaß sichtbar, statt es im Gefühl zu belassen.

Interne und externe Ursachen sortieren

Fünf Tage Verzug, 30 % Kostenüberschreitung, 60 % Feature-Lücke. Aber woher kommen diese Abweichungen? Mia muss die Ursachen sortieren, bevor sie Gegenmaßnahmen vorschlagen kann.

Zwei Ursachen liegen außerhalb des Teams (extern): Der Zahlungsanbieter hat seine API-Dokumentation drei Wochen zu spät geliefert. Und ein kritisches Sicherheitsupdate des Shopsystems erzwang ungeplante Testläufe.

Drei Ursachen liegen im Einflussbereich des Teams (intern): Die Aufwandsschätzung für die Migration war zu optimistisch - der Risikopuffer lag bei nur 10 %. Zwei Entwickler:innen arbeiteten parallel an einem Hotfix statt am Relaunch. Und die Anforderungen an das Personalisierungsfeature wurden erst in Sprint 3 statt in Sprint 1 konkretisiert.

Was passiert auf dem kritischen Pfad?

Die Datenmigration liegt auf dem kritischen Pfad des Projekts. Das bedeutet: Jeder Tag Verzug hier verschiebt den Go-Live um genau einen Tag. Aus der Risikomatrix, die das Team in der Planungsphase erstellt hat, war der Lieferverzug des Zahlungsanbieters als mittleres Risiko eingestuft. Die geplante Gegenmaßnahme - frühzeitige Anforderung der Dokumentation - wurde aber nie umgesetzt.

Die internen Ursachen verstärken das Problem: Weil die Entwickler:innen am Hotfix gebunden waren, konnte niemand die verspätete API-Doku sofort einarbeiten. Externe und interne Ursachen wirken hier wie eine Kettenreaktion.

🤔 Frage dich: Jemand aus dem Team sagt: "Der Zahlungsanbieter hat zu spät geliefert - da können wir nichts machen, das ist ein reines externes Problem." Stimmt das wirklich?

Drei Maßnahmen, drei Kategorien

Der Soll-Ist-Vergleich zeigt das Problem, die Ursachenanalyse zeigt das Warum. Jetzt braucht Mia einen konkreten Plan. Drei Maßnahmen aus unterschiedlichen Kategorien:

1. Eine zweite Entwicklungskraft wird ab Montag exklusiv für die Datenmigration abgestellt (Ressourcenanpassung). Die Teamleitung Entwicklung verantwortet die Umsetzung. Der Migrationsverzug verkürzt sich damit um etwa 3 Tage.
2. Das Personalisierungsfeature wird komplett in Release 2 verschoben (Scope-Reduktion). Der Product Owner entscheidet bis Dienstag. Das entlastet die Sprint-Kapazität sofort und gibt dem Team Luft für die Migration.
3. Sprint 8 wird um 3 Tage verlängert (Re-Scheduling). Die Projektleitung holt die Genehmigung bis Mittwoch ein. Der Go-Live verschiebt sich damit auf 2 Tage vor Kampagnenstart.

Zwei Tage Puffer statt Blindflug

Mia trägt die drei Maßnahmen in die Maßnahmentabelle ein und legt sie der Projektleiterin vor. Statt vier Wochen bis zum Go-Live hat das Team jetzt realistisch noch 26 Tage - mit einem Puffer von 2 Tagen vor der Weihnachtskampagne.

Ohne den Soll-Ist-Vergleich hätte das Team weiter im Blindflug gearbeitet. Die 8.000 Euro pro Tag Verzug wären erst aufgefallen, wenn der Go-Live-Termin bereits gerissen gewesen wäre. Frühzeitiges Erkennen von Abweichungen hat dem Projekt die Handlungsfähigkeit erhalten - nicht das Festhalten am ursprünglichen Plan.