Klassisches Projektmanagement

Tuan scrollt durch die Fallstudie

Tuan scrollt auf seinem Tablet durch die Fallstudie, die gerade auf dem Beamer läuft. Samstag, 10 Uhr, PM-Schulung. Der Fall: Ein Online-Händler muss 800.000 Produktdatensätze wegen einer EU-Verordnung in 14 Wochen ins neue Shopsystem überführen. Beim Kickoff sagt der Teamleiter: "Wir fangen einfach an, die Daten rüberzuschieben." Drei Abteilungen sollen parallel loslegen, aber kein Dokument hält fest, was genau migriert wird und in welcher Reihenfolge.

Das Risiko: fehlerhafte Daten im Livesystem oder gerissene Frist. Shop offline, 20.000 Euro Umsatzverlust pro Tag. Tuan erkennt die Konstellation sofort: fixe gesetzliche Deadline, klar abgrenzbarer Umfang, mehrere abhängige Teams. Genau die Kriterien, die für ein sequenzielles Vorgehen sprechen. Aber ohne Dokumentation fehlt jede Steuerungsgrundlage.

Drei Dokumente, die den Unterschied machen

Bevor der erste Datensatz migriert wird, braucht das Projekt drei Dokumente, die aufeinander aufbauen:

Das Lastenheft beschreibt das WAS aus Sicht des Auftraggebers. Im Migrationsfall: welche Datenfelder (Name, Preis, Kategorie) übernommen werden und welche Qualitätsstandards gelten.

Das Pflichtenheft übersetzt das WAS in ein WIE. Das Projektteam legt den technischen Weg fest: Daten aus dem Altsystem extrahieren, bereinigen und ins neue System laden, mit Validierungsregeln (automatische Prüfregeln für Datenkorrektheit) und Testlauf vor Go-Live.

Der Projektstrukturplan (PSP) zerlegt das Projekt in Arbeitspakete. Beispiel: "AP 3.2: Datenbereinigung Kategorie-Stammdaten, 5 Personentage."

🎬 Vorstellung: Stell dir vor, du sitzt neben Tuan in der Schulung und sollst den Teamleiter überzeugen, nicht sofort loszulegen. Mit welchem der drei Dokumente argumentierst du zuerst?

Fünf Phasen bis zum Go-Live

Lastenheft, Pflichtenheft und PSP geben dem Projekt Struktur. Aber wann entsteht welches Dokument, und wie hängen die Phasen zusammen? Der Phasenplan für das Migrationsprojekt:

1. Initiierung (Woche 1-2): Lastenheft erstellen. Meilenstein: Alle Datenfelder dokumentiert und vom Auftraggeber freigegeben.
2. Planung (Woche 3-4): Pflichtenheft und PSP erarbeiten. Meilenstein: Technisches Verfahren und Zeitplan von Projektleitung und Auftraggeber abgenommen.
3. Analyse & Design (Woche 5-7): Daten-Mapping (Zuordnung der Datenfelder aus Alt- ins Neusystem) und Validierungsregeln definieren. Meilenstein: Mapping-Dokument von allen drei Abteilungen freigegeben.
4. Durchführung (Woche 8-12): Datenbereinigung und Testmigration. Meilenstein: Fehlerquote unter 0,1 % bestätigt.
5. Abschluss (Woche 13-14): Produktivmigration (der echte Umzug der Daten ins Live-System) und Übergabe. Meilenstein: 800.000 Datensätze im neuen System validiert, Abnahmeprotokoll unterschrieben.

Warum die Reihenfolge nicht verhandelbar ist

Jede Phase baut auf dem Ergebnis der vorherigen auf. Das Pflichtenheft kann erst entstehen, wenn das Lastenheft freigegeben ist. Die Testmigration setzt ein fertiges Daten-Mapping voraus. Diese strikte Abfolge ist der Kern des klassischen Modells: Kein Schritt beginnt, bevor der vorherige abgenommen wurde.

Der kritische Pfad verläuft durch die Phasen 3 bis 5. Hier gibt es keinen Zeitpuffer. Verzögert sich das Daten-Mapping um eine Woche, verschiebt sich der Go-Live um genau diese Woche. Bei einer gesetzlichen Frist ist das keine Option.

🔮 Bevor du weiterliest: In Woche 6 meldet die Produktabteilung, dass 15 % der Kategoriedaten im Altsystem fehlerhaft sind. Wie wirkt sich das auf den kritischen Pfad aus?

Neue Anforderung nach Planabschluss

Mitten in der Durchführungsphase meldet der Auftraggeber: "Wir brauchen zusätzlich 50.000 Produktvarianten im neuen System." Im klassischen Modell ist die Analysephase längst abgeschlossen. Das Pflichtenheft ist unterschrieben, das Mapping steht. Eine nachträgliche Änderung trifft das Projekt an drei Stellen:

Budget: Die Datenbereinigung für 50.000 zusätzliche Datensätze erfordert zwei weitere Fachkräfte für drei Wochen. Mindestens 15.000 Euro, die im ursprünglichen Plan nicht vorgesehen sind.

Termine: Das Mapping muss überarbeitet, die Testmigration wiederholt werden. Zwei Wochen Verzögerung auf dem kritischen Pfad. Der Go-Live rutscht hinter die gesetzliche Frist.

Qualität: Die bestehenden Validierungsregeln decken die neuen Varianten nicht ab. Ohne Anpassung steigt die Fehlerquote in der Produktivmigration.

Tuans Erkenntnis aus der Schulung

Zurück in Tuans Schulung: Das klassische Modell schützt das Projekt durch seine Phasenstruktur. Jede Abnahme ist ein Kontrollpunkt, der verhindert, dass ungeprüfte Arbeit in die nächste Phase fließt. Gleichzeitig macht genau diese Struktur das Modell anfällig für späte Änderungen. Je weiter ein Projekt fortgeschritten ist, desto teurer wird jede Anpassung.

Für das Migrationsprojekt heißt das: Wer das Lastenheft sauber formuliert und alle Anforderungen vor Projektstart klärt, spart sich die teuren Korrekturen in der Durchführung.

🤔 Frage dich: Was passiert mit dem 14-Wochen-Zeitplan, wenn der Auftraggeber in Woche 3 ein zweites Shopsystem als Migrationsziel ergänzt und kein Change-Request-Verfahren existiert?