Zurück zur Methodenübersicht

Phasen

Phasen: Basis

Einleitung Phasen

Mit einem Phasenplan wird der geplanten Projektablauf grafisch durch grobe zeitliche und inhaltliche Abschnitte dargestellt. Der Phasenplan ist auch ein wichtiges Instrument für die Abstimmung mit Auftraggeber.

Phasenplan als zentrales Kommunikationsmittel und zur Meilensteinsteuerung in Wasserfallstruktur aufbauen

Ein Phasenplan stellt den geplanten Projektablauf grafisch durch grobe zeitliche und inhaltliche Abschnitte dar.

Ein Phasenplan ist

  • ein zentrales Kommunikationsmittel
  • eine gute Basis für eine erste Aufwands- und Kostenschätzung

Meilensteine sind Ereignisse besonderer Bedeutung mit Dauer Null.

Meilensteine ermöglichen, sofern sie mit Kriterien näher beschrieben werden,

  • proaktives Management während Phase
  • die Ausrichtung Projektteam
  • Ergebnisüberprüfung und Nachsteuerungen bis hin zum Projektabbruch

💡 Ich werde oft gefragt, warum ich einen solch groben Terminplan überhaupt erstelle. Ich könnte doch besser mit den Fachspezialisten direkt in die Detailplanung gehen. Zum einen ist so ein Vorgehen bei kurzfristigen Anfragen im Kundenauftragsgeschäft unrealistisch. Aber auch bei internen Projekten stehen mir zu einem frühen Zeitpunkt die Fachspezialisten, die das Projekt durchführen sollen, noch nicht zur Verfügung. Im Gegenteil: Ich benötige den Phasenplan oft als Voraussetzung für die Ressourcenplanung, weil ich den Ressourcenbedarf aus den Meilensteinkriterien und den daraus abgeleiteten Hauptaktivitäten einer Phase ableite. Außerdem ist es leichter, eine Art Baseline (Projektauftrag) relativ verbindlich als Grundlage für die Detailplanung festzulegen, zu der ich dann im Idealfall namentlich die Fachleute einlade, die mir vom Ressourcenmanagement genannt wurden und die das Projekt begleiten werden.

Stage Gate: Nach jeder Phase (Stage) folgt im planbasierten Projektmanagement ein Gate (Tor), durch das man in die nächste Phase treten kann, wenn die Kriterien des “Phasentors” (Stage Gate) erfüllt sind. Ein Stage Gate ist ein Teil des Stage Gate Prozesses in einem Entwicklungsmodell nach Cooper, bei dem ein Projekt in Phasen (Stages) und Gates unterteilt wird. Der Fokus ist eine strategische Entscheidung, ob das Projekt weitergeführt, gestoppt, verschoben oder überarbeitet wird. Varianten aus der Praxis:

  • Variante 1:
    • Ein Vertreter einer QS-Abteilung eines technischen Fachbereichs und/oder eines PMOs prüfen das Projekt meist formal den Meilenstein eher als “Quality Gate” (siehe unten), ob alle die technischen Kriterien erfüllt wurden und alle erforderlichen Pläne und PM-Aktivitäten durchgeführt worden sind. Es folgt oft ein Bericht an den Lenkungsausschuss einen Bericht mit einer entsprechenden Empfehlung, dass zumindest technisch und formal nichts gegen ein Durchschreiten des Gates in die nächste Phase spricht.
    • Es erfolgt natürlich zusätzlich noch eine inhaltliche Prüfung durch den Lenkungsausschuss vor der Freigabe, in der grundsätzliche strategische Fragen zum Weiterführen, Stoppen, Verschieben oder Überarbeiten durch das Management getroffen werden.
    • In einer strengen Version darf man nur durch das Gate gehen, wenn alle Qualitäts-Kriterien erfüllt sind. In einer wenigen strengen Variante erlaubt das Management das Gehen durch das Gate, auch wenn einige weniger wichtige Kriterien noch nicht erfüllt sind. Diese müssen dann aber in der Regel innerhalb einer gewissen Frist nachgereicht werden.
    • Der Unterschied zu einem normalen Meilenstein ist also hier eher der, dass in solchen Projekten zum Beispiel Zwischenmeilensteine als bloße Kontrollpunkte nur von Projektleitung und Projektteam freigegeben werden können. Insofern wäre nach dieser Definition ein “Stage Gate” die “strenge Variante” des Meilensteins.
  • In einigen Firmen stehen in Projektmanagementhandbüchern “Stage Gates”, die für alle Projekte zwingend einzuhalten sind. Das ist immer dann sinnvoll, wenn sich die Projekte in ihren Abläufen sehr ähneln. Die Projektleitung darf aber zusätzlichen Meilensteine definieren. Die beiden Varianten sind sich zwar recht ähnlich. Aber der entscheidende Unterschied ist, dass bei der vorliegenden Variante ein Stage Gate ein Standard-Meilenstein ist, der in jedem Projekt zu definieren ist. In der ersten Variante gibt es diese Standardisierung nicht.

Ein Quality Gate ist ein definierter Prüfpunkt, an welchem fest definierten Qualitätskriterien erfüllt sein müssen, um durch ein “Tor” (Gate) in die nächste Phase gehen zu können. Oft wird Stage Gate und Quality Gate synonym verwendet. Wenn man es ganz genau nehmen möchte, könnte man ein Quality Gate auch als inhaltliche Qualitätsprüfung betrachten, bei der wie bei einer technischen Abnahme eher die folgende Frage gestellt wird: “Ist die Qualität der bisherigen Arbeit ausreichend?”

Ein Stage Gate ist oft übergreifender und enthält als Teil seiner Entscheidungsgrundlage ein Quality Gate. Aber ein Quality Gate ist nicht das gesamte Stage Gate, bei dem eher gefragt wird: “Machen wir das Projekt weiter?”

💡 Tipps zur Toolverwendung:

Ein Phasenplan vereinfacht durch seine Übersichtlichkeit die Kommunikation mit dem Auftraggeber und dem Team und wird in der Regel im Rahmen der Auftragsklärung erwartet. Wegen der Bedeutung für eine gute Managementkommunikation sollte zur Darstellung des Phasenplans ein Präsentationstool wie z.B. Powerpoint verwendet werden. In der Praxis wird oft nur ein Gantt-Chart verwendet, die einzelnen Vorgänge zugeklappt und dann ein Screenshot der Sammelvorgänge als Phasenplan verkauft. Hauptargument ist die Zeitersparnis, nicht zwei Pläne pflegen und aktualisieren zu müssen. Diese Zeitersparnis ist meist nur sehr gering und steht in keinem Verhältnis zu den Nachteilen, nämlich eine deutlich weniger aussagekräftigerer Kommunikation. MS Project und vergleichbare Gantt-Chart-Tools haben enorme Stärken, sind aber nicht für eine aussagekräftige Präsentation geeignet.

So ist zum Beispiel der Hinweis auf Probleme durch beispielsweise Blitzsymbole oder eine integrierte Kostensummenlinie zur Darstellung des Kostenverlaufs ist in Powerpoint kein Problem, in Tools wie MS Project aber schon. Außerdem sollte man bedenken, dass man einen sinnvollen Screenshot von Sammelvorgängen nur machen kann, wenn man zuvor einen phasenorientierten Projektstrukturplan gebildet hat. Bei einem objektorientierten Projektstrukturplan ist dieses Vorgehen nicht möglich. Bei dieser Strukturierungsvariante benötigt man also ohnehin einen Phasenplan.

💡 Tipps zur Ableitung der Meilensteine:

Meilensteine sollten analog der Ziele klar definiert werden, um ein proaktives Management zu ermöglichen. Sie sind Zwischenziele, die “als Weg zum Endprodukt” meist einfach aus der Zielhierarchie abgeleitet werden. Nur, wenn sie wie die übergeordneten Projektziele SMART beschrieben werden, ist proaktives Management hin zur Meilensteinerreichung möglich. Beispiel: Angenommen, man hat als eines von mehreren Kriterien für den Meilenstein “Testphase abgeschlossen” definiert, dass mindestens 500 Testfälle abgeschlossen sein müssen. Dann hat man als Projektleiter die Möglichkeit, sich rechtzeitig Maßnahmen für z.B. eine bessere Testeffizienz zu überlegen, wenn zur Hälfte der Testphase von den eigentlich definierten 500 Testfällen erst 100 Testfälle bearbeitet worden sind. Ohne klar definierte Meilensteine ist es meist nicht möglich, die empfehlenswerte Erreichung eines sauberen Phasenabschlusses ohne technische Restschulden zu erreichen. Man geht also im schlimmsten Fall in die nächste Phase, ohne alle relevanten Voraussetzungen (z.B. Detailkonzeption) erfüllt zu haben und riskiert eine schlechtere Qualität der Folgephase und Ineffizienzen durch mögliche Rücksprünge in die vorangegangene Phase.

💡 Immer eine Phase für die Abschlussaktivitäten planen

Es sollte immer eine Phase für Abschlussaktivitäten vorsehen werden. Oft können in der Praxis Phasenpläne beobachtet werden, die mit der Abnahme enden. Für die oft notwendigen oder zumindest sehr empfehlenswerten Abschlussaktivitäten fehlt dann ggf. das Personal, wenn es keine offizielle Planung dieser wichtigen Phase und eine entsprechende Beantragung der dazu erforderlichen Ressourcen gegeben hat. Der Endmeilenstein darf übrigens schlicht und langweilig „Projekt abgeschlossen“ genannt werden. Das sorgt i.d.R. für eine größere Klarheit bei den Stakeholdern als eine ggf. spezielle Bezeichnung, bei der sich der Betrachter nicht sicher ist, ob es nach diesem Meilenstein ggf. im Projekt noch weitergeht.

💡 Man muss nicht alle Details und exakte Start- und Endzeiten bereits im Phasenplan abbilden. Details zum Start- und Ende solcher Hauptaktivitäten können über zusätzliche Meilensteine oder (Empfehlung) eher später in der detaillierten Terminplanung (Gantt-Chart) hinterlegt werden.

💡 Mit der Bildung von übergreifenden Phasenbezeichnungen und zusätzlicher Benennung von 1-2 Hauptaktivitäten erzeugt man eine meist übersichtlichere „Wasserfallstruktur“. Bei der Phasenbezeichnung kann man sich an der wichtigsten und aufwändigsten Aktivität orientieren, die repräsentativ für die Phase steht. Das ist immer dann zu empfehlen, wenn die anderen zusätzlichen Hauptaktivitäten sehr unterschiedlich zu den dominierenden Aktivitäten sind und man sich schwertut, einen gemeinsamen Oberbegriff zu finden. Dann muss man sich meiner Meinung nach in der Begriffsfindung nicht zu sehr bemühen und nimmt einfach das Substantiv der dominierenden Hauptaktivität. Es ist übrigens kein Problem, zum Beispiel unter die Phase “Konzeption” als eine der Hauptaktivitäten zum Beispiel “Prototypenentwicklung” zu schreiben. Obwohl die Konzeption klar in der Phase dominiert, ist es bei der Präsentation gegenüber dem Auftraggeber sicher eine interessante Information, wenn man diese nicht ganz so typische aber trotzdem wichtige Aktivität angibt. Vielleicht möchte der Auftraggeber ja bei der Präsentation eines ersten Prototypen dabei sein.

💡 Empfohlene grobe Wasserfallstruktur:

  • In der späteren Ablauf- und Terminplan tut man sich deutlich leichter, wenn man einen „Wasserfall-Phasenplan“ in der Detailplanung konkretisieren darf.
  • Auch weil es in der Praxis oft nicht bekannt ist, dass man Details auch später in einem Gantt-Chart visualisieren kann, werden oft zu viele Details bereits in den Phasenplan „gequetscht“.

💡 X-Achse: Für einen Phasenplan immer eine konkrete Zeitskala verwenden (z.B. mit Monaten und Jahreszahl). Die Verwendung einer Darstellung z.B. mit Auftragseingang (T0) und den folgenden Phasen (T+x Wochen) ist im Kundenauftragsgeschäft verbreitet. Das ist aber kein konkreter Phasenplan, sondern eher ein Phasenmodell. Der Vorteil eines Phasenplans ist die Diskussion mit dem Auftraggeber über ganz konkrete Themen, die sich der zeitlichen Zuordnung der Phasen zur Zeitskala ergeben. Beispiel: Der Auftraggeber fragt kritisch nach, ob die für die Urlaubsmonate im Sommer geplante ressourcenintensive Testphase eine gute Idee ist. Dasselbe gilt für den Rohbau in 2.000 Meter Höhe, der im aktuellen Phasenplan für Dezember vorgesehen ist.

Die Hinterlegung vieler Detailinformationen zu Phasen und Meilensteinen in einer Tabelle sorgt für Orientierung

💡 Bei einem erhöhten Platzbedarf können die eben gezeigten Informationen alternativ auch in einer eigenen Phasentabelle untergebracht werden. Der kleine Nachteil: Verteilung der Phaseninformationen auf zwei Seiten (Phasenplan und Phasentabelle)

Der Phasenplan beinhaltet vor allem wertschöpfende Aktivitäten und sollte nicht mit Projektmanagementphasen verwechselt werden

💡 Im Phasenplan sollte vor allem die Facharbeit visualisiert werden, also die “wertschöpfenden Aktivitäten” und nicht das Projektmanagement.

Ein durchgängiger Balken für Projektmanagement bringt keinen informatorischen Mehrwert. Oft beinhaltet nur die Setup-Phase reine oder zumindest dominierende Projektmanagement-aktivitäten. Sie deckt die Projektmanagementphasen Initialisierung, Definition und Planung ab und geht später im Projektstrukturplan in der “Teilaufgabe Projektmanagement auf”. Alle anderen Projektphasen beinhalteten vor allem Facharbeit, die für eine bessere Aussagekraft ausschlaggebend für die Phasenbezeichnung sein sollte. Selbst in der Abschlussphase fließt meist noch ein erheblicher Aufwand in die Facharbeit (z.B. Bugfixing, Schulungen, Übergabe an die Linie)

Mit einem strukturierten Vorgehen kann die Phasenplanung für eine erste grobe Kostenschätzung genutzt werden

In der Regel ist es eine gute Idee, mit einer kurzen Setup-Phase zu starten, in welcher die Auftragsklärung und Planung stattfindet und die die PM-Phasen „Initialisierung, Definition, Planung“ zusammenfasst.

💡 Ca. 4-6 wertschöpfende inhaltlich aufeinander aufbauender Phasen als Balkenplan mit möglichst wenigen Überlappungen. Ideal ist erfahrungsgemäß ein reines Wasserfallmodell ohne Überlappungen.

💡 Abschlussphase nicht vergessen. Hier finden oft noch viele Facharbeiten statt, die geplant werden müssen.

💡 Tipps zur Festlegung und Beschreibung wichtiger Meilensteine und – sofern nötig – Zwischenmeilensteine sowie zur groben Ressourcenplanung und groben Aufwands- und Kostenschätzung:

  • Meilensteine im Passiv (z.B. „Konzeption abgeschlossen“) benennen.
  • Bei langen Phasen unter Umständen einen Zwischenmeilenstein vorsehen.
  • Meilensteine spezifisch und messbar im Passiv in einem abgetrennten Bereich oder in einer Phasentabelle beschreiben. Hier sind die Kriterien enthalten, die am Ende einer Phase vorliegen müssen, um ohne „technische Restschulden“ in die nächste Phase zu gehen. Diese Kriterien beschreiben im besten Fall den Zustand des Projekts am Ende der Phase (z.B. „100 Testfälle zu 98 % bugfrei durchgeführt“). Ersatzweise kann zusammenfassend auch gesagt werden, dass alle Phasenaktivitäten abgeschlossen sein müssen, eine Aufzählung aller einzelnen abgeschlossenen Aktivitäten als Meilensteinkriterien ist nicht empfehlenswert).
  • Hauptaktivitäten:
    • Unter jede Phase ca. 2 Aktivitäten benennen, die repräsentativ für die Phasen und für die Erreichung der Meilensteine erforderlich sind.
    • Ca. 2 deshalb, um das Ziel der Übersichtlichkeit nicht zu gefährden. Aus diesen Hauptaktivitäten kann die (eventuell etwas abstraktere) Phasenbezeichnung abgeleitet und ggf. nochmal nachjustiert werden.
  • Grobe Ermittlung der Phasendauer. *Unterschied zur Detailplanung der Ressourcen: Dort wird die Dauer eher vom Bottom-Up geschätzten Aufwand sowie von den – durch die Ressourcenmanager bereitgestellten – Ressourcen abgeleitet. Eine solche Bottom-Up-Kalkulation des Aufwands ist zu so einer frühen Phase der Projektplanung in der Regel nicht möglich, da ist eher eine Top-Down Schätzung oder Vorgabe der Dauer üblich.
  • Grobe Ermittlung von Aufwand und Kosten.
    • Welche Engpassressourcen (= hohe Kosten, stark beschränkt verfügbar) sind pro Hauptaktivität erforderlich? Was müssen sie können? Beispiel:
      • 3 Jahre Erfahrung im Anforderungsmanagement
      • 3 Jahre Betriebszugehörigkeit
      • 1 Jahr Erfahrung im jeweiligen Geschäftsbereich
      • GPM-Basistraining absolviert oder Basiszertifikat
    • Wie viele Spezialisten für einen „normalen, üblichen und wirtschaftlichen“ Ressourceneinsatz erforderlich? Hinweis: Zu wenige oder zu viele Spezialisten können den Aufwand und die Kosten pro Ressource erhöhen. Z.B. ist es meist nicht sinnvoll, eine Schnittstelle mit 10 Personen zu programmieren.
    • Der Aufwand kann mit der folgenden Formel berechnet werden: „Aufwand (PT) = Dauer (Kalenderwochen) x Ressourcen(einsatz)“.
    • Die entsprechenden Kosten können mit Verrechnungssätzen einfach kalkuliert werden. Positionen anderer Kostenarten können grob geschätzt und dazu addiert werden.
    • Was den prozentualen Ressourceneinsatz angeht, von dem man zunächst als Projektleitung ausgeht: Nach meiner Erfahrung ist das stark kontextabhängig.
      • Wenn das Projekt z.B. eine große Priorität hat und ich die Möglichkeit sehe, ggf. eine Qualifikation komplett für das Projekt abgestellt zu bekommen, würde ich erst mal von 80% Einsatz (4 Tage) ausgehen (ein Tag = Overhead).
      • Wenn ich von vorneherein weiß, dass ich aufgrund der engen Personaldecke eine Qualifikation wahrscheinlich nur für maximal 2 Tage bekommen kann, würde ich ggf. bei meiner ersten Anfrage beim Ressourcenmanagement eher von 40% Einsatz ausgehen.
      • Wenn weniger Personal angeboten bekomme als ich mir gewünscht habe, muss ich natürlich die Dauer im Phasenplan nochmal nachjustieren.

Mit Überlappungen (Fast Tracking) sollte man sparsam umgehen, weil sie oft kontraproduktiv sind und nicht die erwünschte Zeitersparnis bringen.

Der häufige Wunsch nach Beschleunigung sollte gut überlegt werden. Eine Überlappung - auch genannt Fast Tracking - muss intensiv durch die Projektleitung gemanagt werden. Wenn am Ende der Phase noch gravierende Änderungen passieren, nützt aber das beste Projektmanagement nichts. Viele Aktivitäten der bereits begonnenen überlappenden Phase sind unter Umständen in die falsche Richtung gelaufen. Es gibt einige empirische Studien der Bauindustrie, nach denen übertriebene Parallelisierungen nicht die gewünschte Zeit- und Kostenersparnis, sondern genau das Gegenteil bewirken. Diese Studien sind für mich plausibel.

⚠️ Natürlich kann sich trotz aller Risiken eine Überlappung lohnen. In der Praxis wird dann aber oft vergessen, die überlappende Phase mit einem Meilensteine beginnen zu lassen. Sie fängt dann “irgendwann” während der vorangehenden Phase an. Aber das kann ja kein vernünftiges Prozedere sein nach Motto: “Die Hälfte der vorangehenden Phase ist vorbei, jetzt beginnen wir mal mit der nächsten Phase.”

💡 Vielmehr muss es klar definierte sinnvolle Meilensteinkriterien geben, nach deren Erreichung die nächste Phase ohne technische Restschulden, also die Gefahr von Rücksprüngen in die Vorläuferphase, beginnen kann. Beispiel Meilenstein 3: “Prio 1 Methoden in wichtigstem Pilot erfolgreich getestet und optimiert.”

In einigen Vorgehensmodellen (Beispiel Simultaneous Engineering) ist eine Phasenüberlappung erwünscht, um frühzeitig Erkenntnisse für die aktuelle Phase zu erlangen. Beispiel: Entwicklung eines Prototypen, um Rückschlüsse für die Konzeption zu erhalten.

Tipp: Vermeidung „Roadmap- oder Multi-PM – Look and-feel“

Die Gestaltung eines übersichtlichen Phasenplans setzt deshalb eine gewisse kognitive Anstrengung voraus und sollte nicht unterschätzt werden.

Es geht beim Phasenplan und der Phasenbezeichnung um Übersichtlichkeit, nicht Exaktheit. Insofern bildet eine Phase immer den Schwerpunkt bzw. Fokus der Aktivitäten, um zu einem Zwischenziel zu kommen. Es können sich nicht alle Detailaktivitäten einer Phase in der Phasenbezeichnung widerspiegeln. Die schon erwähnte Ergänzung mit Hauptaktivitäten stellt insofern einen guten Kompromiss aus Übersichtlichkeit und Vollständigkeit dar.

Außerdem kann beim „Roadmap- oder Multi-PM-Look-and-Feel“ nicht wirklich ein wesentlicher Aspekt der Wasserfall-Philosophie gelebt werden, gezielt auf das Phasenende und die entsprechenden Kriterien „hinzumanagen“, um ohne technische Restschulden in die nächste Phase gehen zu können.

Tipp: Wasserfallstrukturen sind meist übersichtlicher und als (eine) Basis für den späteren vernetzten Balkenplan oft deutlich einfacher darstellbar.

  • Man muss nicht alle Details und exakte Start- und Endzeiten bereits im Phasenplan abbilden.
  • Mit der Bildung von übergreifenden Phasenbezeichnungen und zusätzlicher Benennung von 1-2 Hauptaktivitäten erzeugt man eine meist übersichtlichere „Wasserfallstruktur“.
  • Details zum Start- und Ende können über zusätzliche Meilensteine oder (Empfehlung) eher später in der detaillierten Terminplanung (Gantt-Chart) hinterlegt werden.
  • Auch weil dieser spätere Detailplan oft nicht bekannt ist oder praktiziert wird, werden oft zu viele Details in den Phasenplan „gequetscht“.
  • Die Gestaltung eines übersichtlichen Phasenplans setzt deshalb eine gewisse kognitive Anstrengung voraus und sollte nicht unterschätzt werden.
  • Es geht beim Phasenplan und der Phasenbezeichnung um Übersichtlichkeit, nicht Exaktheit. Insofern bildet eine Phase immer den Schwerpunkt bzw. Fokus der Aktivitäten, um zu einem Zwischenziel zu kommen. Es können sich nicht alle Detailaktivitäten einer Phase in der Phasenbezeichnung widerspiegeln. Die schon erwähnte Ergänzung mit Hauptaktivitäten stellt insofern einen guten Kompromiss aus Übersichtlichkeit und Vollständigkeit dar.
  • Außerdem kann beim „Roadmap- oder Multi-PM-Look-and-Feel“ nicht wirklich ein wesentlicher Aspekt der Wasserfall-Philosophie gelebt werden, gezielt auf das Phasenende und die entsprechenden Kriterien „hinzumanagen“, um ohne technische Restschulden in die nächste Phase gehen zu können und ggf. den Start der Folgephase zu verzögern. Dieses in vielen Fällen sinnvolle Prinzip kann beim „Roadmap-Look-and-Feel“ kaum durchgehalten werden.

Zwischen übergreifenden Phasenplänen und Phasenplänen pro Teilprojekt abwägen

Eine Phasenplanung für Teilprojekte ist in der von mir erlebten Praxis eher selten. Für ein Projekt ist es üblich, einen übergreifenden Phasenplan zu verwenden. Wenn ein solch übergreifender Phasenplan unmöglich erscheint, könnte man sich auch überlegen, die Teilprojekte zu Projekten mit einem eigenverantwortlichen Projektleiter zu machen.