Projektlebenszyklus, Projektmanagementlebenszyklus, Produktlebenszyklus
Ein Projektlebenszyklus enthält nicht nur Projektphasen!
Im agilen Projektmanagement kennt man im Rahmen des Projektlebenszyklus anstatt der Projektphasen auch Sprints. Zudem unterscheidet PMI neben dem Projektlebenszyklus den Entwicklungsansatz. Dieser bezieht sich nur auf die Generierung der Liefergegenstände. Der Entwicklungsansatz kann prognostiziert, hybrid oder agil (iterativ oder inkrementell) umgesetzt werden.
Das von PMI präferierte „Rolling Wave Planning“ implizierte immer schon einen Ansatz der agilen Vorgehensweise. Phasen können letztendlich auch die Dauer eines Sprints übernehmen.
Beim Rolling Wave Planning werden nahe bevorstehende Arbeiten im Detail geplant, während fernere Projektphasen zunächst nur auf hoher Ebene grob strukturiert bleiben. Diese Form der iterativen Feinplanung berücksichtigt, dass der Informationsgehalt im Projektverlauf zunimmt, und wendet damit das agile Prinzip der schrittweisen Konkretisierung (Progressive Elaboration) direkt im klassischen Projektkontext an.
Die drei Projektentwicklungsansätze
Plangetriebene Ansätze
Die Phasen eines klassischen Projekts werden durch zwei Prozessebenen durchlaufen: Die Projektmanagementprozesse und die Produktprozesse. Beide Prozessebenen bilden in jeder Phase Ausgangswerte: Die Liefergegenstände (LG) des Produkts und die Liefergegenstände des Projektmanagements. Nach der letzten Phase wandern die LG Produkt weiter auf dem Produktlebenszyklus in den Betrieb. Die LG des PM wandern in die Assets (Organizational Process Assets (OPA)).
Adaptive Ansätze
Im klassischen Modell verläuft der Prozess sequenziell und plangetrieben, wodurch das finale Produkt – wie beispielsweise ein Mountainbike – erst am Ende des Projekts nach Abschluss aller Phasen an den Betrieb übergeben wird. Das agile Modell hingegen setzt bei komplexen Vorhaben wie der Softwareentwicklung auf iterative Schleifen, bei denen nach jedem Sprint bereits nutzbare Inkremente entstehen. Während im klassischen Vorgehen die Anforderungen zu Beginn festgeschrieben und über starre Phase Gates kontrolliert werden, erlaubt der agile Ansatz kontinuierliches Feedback und flexible Anpassungen des Product Backlogs. Beide Modelle trennen jedoch klar zwischen den unterstützenden Projektmanagementprozessen, deren Ergebnisse als OPAs archiviert werden, und den eigentlichen Produktprozessen. Der wesentliche Unterschied liegt somit in der Steuerung: Das klassische Modell minimiert Risiken durch Vorab-Planung, während das agile Modell Risiken durch schnelle Lernzyklen und frühe Teil-Lieferungen reduziert
Hybride Ansätze= Plan + Adaptiv
Das hybride Modell fängt die Realität komplexer Industrieprojekte, wie die Entwicklung eines vernetzten Elektrofahrzeugs, perfekt ein.
Um das Beste aus beiden Welten zu zeigen, ist die Spur für die Produktprozesse (unten) in den Phasen 2 und 3 visuell zweigeteilt:
Oben (Klassisch): Die hardwareseitige Planung und physische Konstruktion (Karosserie, Chassis, Fertigungsstraßen).
Unten (Agil): Die softwareseitige Entwicklung der On-Board-Systeme, App-Anbindungen und Steuerungen im Sprint-Format.
Am Ende, in Phase 4, wachsen diese Ströme im integrierten Elektrofahrzeug an der Ladesäule (mit interaktiven Dashboards) wieder zusammen, bevor sie in den laufenden Fahrzeug- und Software-Lebenszyklus im Betrieb übergehen.
Die drei Parameter des Projektlebenszyklus
Dieses Diagramm zeigt den typischen Verlauf der drei Kernparameter im plangetriebenen Projektlebenszyklus: Während die kumulierten Kosten während der Umsetzung ihren Höhepunkt erreichen und vor dem Abschluss steil abfallen, nehmen Risiken durch steigende Transparenz und die Möglichkeit zur Einflussnahme auf das Produkt im Projektverlauf stetig ab.
Also die Risiken werden nicht weniger, sie werden nur transparenter. Ausnahme bilden die „unknown Unknowns„. Vollkommen unbekannte Risiken, bspw. archäologischer Zufallsfund beim Bau einer Autobahn,
TRAINERKNOWLEDGE AI – Ihre smarte PMP®-Vorbereitung!
Bestehen Sie die PMP®-Zertifizierung sicher und flexibel über unsere innovative Online-Plattform. Wählen Sie passgenau: Komplettkurs inklusive der offiziellen 35-Stunden-Kontaktstunden oder als reines Prüfungstraining. Nutzen Sie KI-gestützte Lerneinheiten für maximalen Lernerfolg zu einem absolut unschlagbaren Preis. Jetzt informieren auf trainerknowledge-ai.training und die Karriere auf das nächste Level heben!
Trainer Live Videos – Storytelling – ECO 2026 Bezug
Im klassischen Projektverlauf bleibt das Risiko bis zur späten Produktübergabe extrem hoch, da Fehler oder Fehlplanungen erst ganz am Ende auffallen. Agile Projekte reduzieren dieses Risiko durch kurze Sprints drastisch: Nach jeder Iteration entsteht ein funktionierendes Produktinkrement, wodurch technisches und fachliches Feedback sofort einfließt. Statt Risiken durch starre Vorab-Planung zu verwalten, wird das Gesamtrisiko in kleine, beherrschenbare Einheiten zerlegt und finanzielle Fehlinvestitionen auf wenige Wochen begrenzt.
Allerdings darf man eben auch nicht vergessen, wenn agile Projekte primär in der „warmen Stube“ ablaufen, sind physische Projekt weit mehr potenziellen Risikoeintritten ausgesetz:
Risikohäufigkeit: Extrem hoch. Durch Witterung, Baugrund, Zulieferketten, Genehmigungen und Handwerker-Schnittstellen treten fast täglich unvorhergesehene Ereignisse und Störungen auf.
Risikointensität (Schadensausmaß): Ebenfalls extrem hoch. Fehler oder Verzögerungen lassen sich nicht einfach „zurückrollen“ (Rollback), sondern führen direkt zu teurem Materialverlust, Baustopps und immensen Folgekosten.
Fokussierte Projektsteuerung: Lebenszyklen als Governance-Werkzeug statt technischer Abfolge
Im Gegensatz zu anderen Organisationen assoziiert das PMI das Thema Projektlebenszyklus und Projektphasen mit dem Projektmanagementkontext oder der Analyse des Umfelds von Projekten.
Das PMI stellt den Zusammenhang dieser Methode (=Erstellung eines phasenorientierten Ablaufs), primär aufgrund der Schnittstellenbildung zwischen Ausführender- und Projektorganisation, bezüglich der ständig notwendigen Kommunikation her, was letztendlich auch zum Umfeld der Projektarbeit gehört.
Während viele Standardorganisationen oder Branchenmodelle (wie z.B. die HOAI im Bauwesen oder klassische V-Modelle in der IT) Projektphasen als rein technische Entwicklungsabschnitte definieren, hebt das PMI das Thema auf eine völlig andere Ebene.
Hier ist die detaillierte Aufschlüsselung, warum das PMI den Projektlebenszyklus und die Phasen so stark mit dem Managementkontext und der Umfeldanalyse verknüpft:
1. Phasen als Management-Kontrollpunkte (Governance)
Für das PMI ist eine Projektphase keine bloße Aneinanderreihung von Aufgaben, sondern ein Steuerungswerkzeug des Managements.
- Die Logik: Das PMI verknüpft das Ende einer Phase immer mit einem sogenannten Phase Gate (auch Kill Gate, Stage Gate oder Phase Review genannt).
- Der Zweck: Hier wird nicht nur geprüft, ob das technische Ergebnis vorliegt, sondern ob das Projekt im aktuellen Unternehmensumfeld noch Sinn ergibt. Passt der Business Case noch? Haben sich die Rahmenbedingungen der Trägerorganisation geändert? Das Phasenende dient dem Management als expliziter Entscheidungspunkt, um das Projekt fortzuführen, anzupassen oder geordnet abzubrechen.
2. Die Verknüpfung mit den "Enterprise Environmental Factors" (EEFs)
Wenn das PMI von Phasen spricht, analysiert es immer das Projektumfeld. Der Lebenszyklus eines Projekts wird maßgeblich von den internen und externen Umweltfaktoren (EEFs) der Organisation beeinflusst:
- Interne Kultur und Struktur: Ein agiler oder prädiktiver Lebenszyklus wird nicht nur nach dem Produkt gewählt, sondern danach, wie die Organisation gesteuert werden kann. Hat die Organisation eine hohe Risikotoleranz? Wie sind die Entscheidungswege?
- Externe Faktoren: Marktbedingungen, gesetzliche Vorgaben oder technologische Trends bestimmen, wie lang Phasen sein dürfen, um das Risiko eines Fehlschlags im dynamischen Umfeld zu minimieren.
3. Trennung von Projektmanagement-Lebenszyklus und Produkt-Lebenszyklus
Das PMI trennt strikt zwischen dem, was getan wird (Produkt) und wie es gesteuert wird (Management):
- Andere Organisationen vermischen oft den Produktlebenszyklus (Konzeption, Entwicklung, Test, Betrieb, Ausmusterung) mit dem Projekt.
- Das PMI sagt: Der Projektlebenszyklus ist der Rahmen, den das Projektmanagement um den Produktlebenszyklus legt, um Risiken zu kontrollieren. Ein Projekt kann beispielsweise nur eine einzige Phase des Produktlebenszyklus abbilden (z. B. eine reine Machbarkeitsstudie als eigenständiges Projekt).
Richtigstellung: Der Produktlebenszyklus beginnt mit der Idee!
4. Der Bezug zur ECO (Examination Content Outline)
In der ECO (insbesondere in der Domain Business Environment) wird genau dieses Verständnis abgeprüft. Ein PMP-Anwärter muss verstehen, dass die Wahl des Lebenszyklus (prädiktiv, agil oder hybrid) eine strategische Managemententscheidung ist, die auf der Analyse des Projektumfelds basiert:
- Ist das Umfeld stabil? → Prädiktiver Lebenszyklus.
- Ist das Umfeld hochgradig volatil und die Anforderungen unklar? → Adaptiver/Agiler Lebenszyklus.
Fazit
In anderen Systemen lernt man: „Ein Projekt hat die Phasen A, B und C.“
Beim PMI lernt man: „Phasen sind die Brille, durch die das Management auf das Projektumfeld blickt, um Risiken zu minimieren, Werte zu sichern und die Governance aufrechtzuerhalten.“
Eigenschaften von Projektphasen
Das PMI kennzeichnet das Ende einer Phase durch Fertigstellung eines oder mehrerer Liefergegenstände (Key-Deliverables), ein bekannter Begriff aus dem Prozessmanagement.Dieser „Liefergegenstand“, sollte quantifizierbar oder überprüfbar sein.
Erst die positive Validierung des Liefergegenstands über den Fokusbereich „Abschluss“, beendet eine Phase (oder auch das Projekt) und startet eine neue Phase. Fehler oder Fehlentwicklungen können somit früh erkannt und behoben werden. Der Übergang zwischen den Phasen wird auch u.a. als Phase Gate bezeichnet.
Dieses Gate kann eben auch verschlossen bleiben, was eine Übergabe an die nächste Phase erst einmal verhindert.
Die Fokusbereiche (ehemals Prozessgruppen) Initiierung, Planung, Ausführung, Kontrolle und Steuerung sowie Abschluss sind
ohne eine Phasenunterteilung kaum praktizierbare Instrumente, da sich die Prozessgruppen im Rahmen jeder Phase wiederholen und damit den Projektmanagementlebenszyklus (seit PmBok 5 nicht mehr so bezeichnet) beschreiben.
Die Liefergegenstände ermöglichen über die „Phasenschnittstelle“ hinaus einen Rückblick in die letzte Phase und einen Ausblick in die nächste Phase.
Durch den Ausblick in die nächste Phase wird auch eine signifikante Risikoeinschätzung und Chanceneinschätzung ermöglicht, was wiederum die Philosophie der „rollierenden Planung“ spiegelt. Technische und wirtschaftliche Risiken werden minimiert.
Neben dem Begriff „Phase Gate“ werden die Schnittstellen dieser Überprüfungen auchals Phasenübergänge, Stufenübergänge oder Entscheidungspunkte bezeichnet.
Phasenverläufe im Projektlebenszyklus
Anstoßplanung: Dargestellt als starre Dominosteine oder feste, nacheinander geschaltete Blöcke mit einer harten Barriere (Pfeile zeigen nur nach vorn, kein Weg zurück).
Revolvierende Planung: Dargestellt nach dem Hochschul-Prinzip (Phasen/Semester als Blöcke, bei denen ein gebogener Rückhol-Pfeil aus späteren Phasen zurück in eine frühere Phase führt, um offene „Scheine“ nachzuholen).
Rolling-Wave-Planning: Dargestellt als ein in die Ferne reichender Horizont, bei dem der vordere Bereich scharf und detailliert (Arbeitspakete) und der hintere Bereich neblig-grob (Planungspakete) dargestellt ist, der sich schrittweise schärft.
Achtung!
Die Begriffe Anstoßplanung und revolvierende Planung werden im PMI Kontext nicht benutzt. Die Anstoßplanung ist vergleichbar mit einem sehr stringentem Wasserfallmodell (PMBOK 8.0, 4.2.1).
Die revolvierende Planung wird eher immanent verwendet: Phasen enden in der Regel mit einer Überprüfung (Phase Gate / Governance Review). Wenn die Kriterien nicht erfüllt sind, entscheidet das Management, ob die Phase wiederholt, korrigiert oder ob das Projekt abgebrochen wird. Eine „revolvierende“ Dauerschleife im Sinne von überlappenden Semestern ist im klassischen PMI-Sinne jedoch so nicht vorgesehen; dort trennt man eher strikt zwischen prädiktiv (sequenziell) und iterativ/agil (schleifenbasiert)
Anstoßplanung, Rolling Wave Planning oder revolvierende Planung?
Welcher Phasenverlauf oder Planungsansatz zum Einsatz kommt, ist in der Regel stark von der jeweiligen Projektart abhängig. Die drei hauptsächlichen Projektarten werden allgemeinüblich in die Kategorien Investitionsprojekte, Organisationsprojekte und Entwicklungs- / Forschungsprojekte (F&E) unterteilt.
Investitionsprojekte (z. B. Erstellung eines technischen Produkts oder Anlagenbau):
Diese zeichnen sich primär durch klar abgegrenzte Phasen aus, die eine sequenzielle Planungsweise (Anstoßplanung) notwendig machen. Das Produkt als solches ist zwar einzigartig oder neu, aber ein Unternehmen kann im Anlagenbau auf langjährige Erfahrungswerte zurückgreifen, wodurch die Zielgrößen mit marginalen Abweichungen sehr gut prognostizierbar sind. Zudem ist die Baubranche beispielsweise durch rechtliche Vorgaben wie die Honorarordnung für Architekten und Ingenieure (HOAI) zu einer strikten Phasenteilung verpflichtet.
Entwicklungs- und Forschungsprojekte (F&E / Softwareentwicklung):
Solche Vorhaben erfordern während einer Phase häufig Parallelinitiierungen und direkte Rückkopplungen zu Vorphasen, da Forschungsergebnisse oft völlig neue, bis dato unbekannte Erkenntnisse liefern. Sie kennzeichnen sich durch hohe Innovationen und extreme „Black Box“-Inhalte. Arbeitspakete, die zu keinen Ergebnissen führen, werden konsequent abgebrochen und mit einem neuen Ansatz initiiert. Häufig handelt es sich hierbei um komplexe Gesamtsysteme, in denen mehrere Teilsysteme eng miteinander verflochten sind (wie etwa bei einem Mauterfassungssystem aus Autobahnerfassungstechnik, LKW-Sende- und Erfassungstechnik sowie Satellitenempfängern). Auch die klassische Softwareentwicklung fällt in diesen Bereich – und genau hier kommt sehr häufig das Rolling Wave Planning zum Tragen: Ein Softwareteam plant beispielsweise die nächsten zwei Sprints (ca. 4 Wochen) absolut detailliert mit festen Arbeitspaketen durch, während die Features für das nächste Quartal (der ferne Horizont) zunächst nur als grobe Planungspakete im Backlog stehen und erst bei Annäherung schrittweise operationalisiert werden.
Organisationsprojekte (Großvorhaben und Change-Vorhaben):
Organisationsprojekte erfordern oft eine Kombination verschiedener Vorgehensweisen, da neben den Planungszielgrößen auch Zwischenergebnisse, Parallelisierungszwänge oder völlig neue Initiativen den Verlauf beeinflussen. Dazu zählen Großvorhaben wie Parteikongresse, Wahlen, Weltausstellungen, aber auch Großumzüge oder Fusionen („Elefantenhochzeiten“) inklusive der nachfolgenden Zusammenlegung von Firmenbereichen. Eine glasklare, starre Phasenteilung ist hier in der Regel nicht möglich, da viele kleine Teilprojekte parallel nebeneinander herlaufen.
Grundsätzliches zu Objekt-Systemen
Ein entscheidender Faktor ist zudem, dass es sich hierbei nicht um Objekt-Systeme handelt (bei denen keine Fremdsteuerung von außen möglich ist wie bei einer Maschine). Ein mechanisches Bauteil kann nicht rufen: „Holla, da wurde mir aber eine Schraube zu früh an den Flansch montiert, da muss vorher noch die Dichtung drunter!“ In Subjektsystemen (also Systemen mit Menschen) merken Beteiligte sofort, wenn sich beispielsweise zwei Termine im Kalender widersprechen. Daher kommt es in Organisationsprojekten ganz immanent und automatisch zu revolvierenden Maßnahmen, bei denen Phasen über Governance-Reviews oder Kontrollschleifen so gestaltet sind, dass offene Posten oder unvorhergesehene Reibungspunkte in den nächsten Schritten gemeinsam aufgegriffen und nachgeholt werden können.
Fast Tracking
Fast Tracking ist primär eine Methode Terminplanvorgänge (Arbeitspakete) teilweise oder ganz zu parallelisieren. Das geht nur, wenn der steuernde Vorgang (Vorgang 1) Arbeiten enthält, die nicht abgeschlossen sein müssen, bevor Vorgang 2 beginnt. In der Regel bewirkt dies die Beschleunigung eines Projekts.
Fast Tracking ist nicht zu verwechseln mit einer revolvierenden Planung. Man spricht in diesem Fall auch von Concurrent oder Simultaneous Engineering. Häufig werden dadurch aber Risiken erzeugt, die eher Nachteile hervorbringen können.
Der Begriff Fast Tracking wird manchmal auch auf überlappende Phasen benutzt z. B. „Beginn der Ausführungsphase, bevor die Planungsphase zu 100 % abgeschlossen ist“.
Bezug auf einzelne Sprints
Wendet man den Begriff „Fast-Tracking“ direkt auf Sprints an, muss man präzisieren:
- Sprints selbst sollten in ihrer Länge nicht überlappt oder verkürzt werden: Ein Scrum-Sprint hat eine feste Timebox (z. B. 2 Wochen). Diese Box wird nicht „schneller gemacht“, indem man sie verkürzt oder mitten im Sprint den nächsten startet – das würde den iterativen Rhythmus und die Integrität des Sprints zerstören.
- Aber: Die Inhalte bzw. die Arbeitspakete innerhalb oder zwischen Sprints können „fast-getrackt“ werden:
- Wenn beispielsweise ein Backlog-Eintrag für den nächsten Sprint (Sprint 2) bereits im laufenden Sprint 1 vorbereitet (refined oder konzipiert) wird, während die letzten Tests für Sprint 1 noch laufen, ist das im Grunde ein agiles Äquivalent zu einer überlappenden Planung (ähnlich einer EA-Beziehung mit negativem Lag).
- Auch das parallele Arbeiten an User Stories, die eigentlich sequenziell geplant waren (z. B. Entwicklung beginnt schon, bevor die UX-Abnahme des Vorgängers komplett finalisiert ist), entspricht dem Prinzip des Fast-Trackings, birgt im agilen Kontext allerdings das Risiko von Nacharbeit (Rework).
