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.
* Verlinkungen zur PMIstandards+ können nur bei Zugriff auf diese Website funktionieren.
Lesen Sie Teil 1: https://trainerknowledge.eu/2021/01/20/was-ist-ein-projekt/
Lesen Sie Teil 2: https://trainerknowledge.eu/2021/01/20/was-ist-projektmanagement-pmp-zertifizierung-590e-netto/
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 Träger- und Projektorganisation, bezüglich der ständig notwendigen Kommunikation her, was letztendlich auch zum Umfeld der Projektarbeit gehört.
Wie sieht der typische Verlauf von Projektphasen im Projektlebenszyklus aus.
Die Kurve der Risiken soll nicht andeuten, dass die Risiken mit zunehmendem Projektverlauf weniger oder monetär geringer werden, sondern nur transparenter werden, was bedeutet, das man die identifizierten Risiken mit adäquaten Bewältigungsmaßnahmen managed. Am Anfang ist die Transparenz sehr gering. Mit dem Eintauchen in die Abarbeitung des Scopes, steigt der Grad an Erkenntnis über das Projekt und der Risiken. KO Risiken sollten allerdings schon vor der Entscheidung, das Projekt zu genehmigen, eruiert werden. Nichts desto trotz nennt der PmBok Guide die „unknown Unknowns“, die unbekannten Unbekannten, Risiken, die niemand vorhersehen kann.
Mit der Einflussnahme ist primär der Liefergegenstand gemeint. Insbesondere physische Produkte sind davon betroffen.
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, 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 Prozessgruppen Initiierung, Planung, Ausführung, Kontrolle und Steuerung 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 auch
als Phasenübergänge, Stufenübergänge oder Entscheidungspunkte bezeichnet.
Projektphasen nach DIN 69900 :
Zeitlicher Abschnitt eines Projektablaufs, der sachlich gegenüber anderen Abschnitten getrennt ist
Phasenverläufe im Projektlebenszyklus
Die bisher dargestellte Sichtweise unterstellt, dass ein Liefergegenstand gemäß seiner geplanten Konfiguration zum Termin X fertig gestellt sein muss, um eine weitere Phase „anzustoßen“. Es handelt sich hier also um eine typisch sequenzielle Vorgehensweise (Wasserfall). Diese Vorgehensweise ist auch als „Anstoßplanung“ bekannt (Projektmanagement Fachmann; RKW Verlag) und spiegelt das uns allen bekannte Konzept „Schule“ wieder:
- Zeitliche Begrenzung (Schuljahr)
- Teilziele (Zwischenzeugnis)
- Leistungsinhalte (Lehrplan)
- Meilenstein (Schuljahresabschluss)
- Auditierung / Teilzielüberprüfung (Lehrerkonferenz)
- Risikoabschätzung für die nächste Phase; evtl. Wiederholung oder Abschluss
Neben der Anstoßplanung kann es auch sinnvoll sein, sich für eine überlappende Vorgehensweise zu entscheiden, auch revolvierende Planung (Wasserfallmodell) genannt. Diese Planungsweise gleicht dem Prinzip des Hochschulwesens:
- 1. Semester: in der Regel Vorlesungen, die dem 1. Semester zuzuordnen sind.
- Prüfungen mit dem Ergebnis „Scheine“ zu erlangen.
- 2. Semester: Neue Vorlesungen; Wiederholungen von Vorlesungen, für die „Scheine“ die nicht erlangt worden sind; Vorlesungen des 1. Semesters, die in das 2. Semester aus Zeitgründen verlegt wurden.
Dieses Modell wird häufig bei der Entwicklung von Software angewendet. Hier ist es wichtig, nach jeder Phase eine Verifizierung vorzunehmen, bei der es zu Rückkopplung zur vorhergehenden Phase kommen kann.
Anstoßplanung oder Wasserfallmodell?
Welche der beiden Phasenverläufe Präferenz erhält, ist i.d.R. von der Projektart abhängig. Die drei hauptsächlichen Projektarten werden allgemeinüblich in den Kategorien Investitionsprojekte, Organisationsprojekte und Entwicklungs- / Forschungsprojekte (F&E) zusammengefasst.
So zeichnen sich Investitionsprojekte (z.B. Erstellung eines technischen Produkts) primär durch klar abgegrenzte Phasen aus, die eine sequenzielle Planungsweise notwendig machen. Das Produkt als solches ist zwar einzigartig oder neu, aber grundsätzlich wird z.B. ein Unternehmen im Anlagenbau auf Erfahrungen verweisen können, die die Zielgrößen mit marginalen Abweichungen prognostizierbar machen.
Die Baubranche ist z.B. durch die „Honorarordnung für Architekten und Ingenieure“(HOAI) zu einer klaren Phasenteilung verpflichtet.
F&E Projekte dagegen, benötigen während einer Phase häufig Parallelinitiierungen, Rückkopplungen zu den Vorphasen aufgrund von Forschungsergebnissen, die bis dato nicht bekannt waren. Diese Projekte kennzeichnen sich durch hohe Innovationen und extreme „Black Box“ Inhalte. Arbeitspakete die zu keinen Ergebnissen führen, werden abgebrochen und mit einem neuen Ansatz initiiert.
Häufig handelt es sich hier auch um Systeme, da mehrere Produkte miteinander verflochten sind. ( z.B. Mauterfassungssystem = Teilsysteme Autobahnerfassungstechnik – LKW Sende- und Erfassungstechnik – Satellitenempfänger). Auch Software Entwicklung zählt zu den F&E Projekten.
Organisationsprojekte können dagegen auch eine Kombination beider Phasenverläufe erfordern, da neben den Planungszielgrößen, Zwischenergebnisse auch Parallelisierungs-zwänge oder neue Initiativen forcieren können.
Organisationsprojekte umfassen insbesondere Großvorhaben (Parteikongresse, Wahlen, Weltausstellungen). Aber auch Großumzüge von Organisationen oder „Elephantenhochzeiten“ (Fusionen) mit den darauf folgenden Zusammenlegungen von Firmenbereichen zählen zu den O-Projekten. Eine glasklare Phasenteilung ist in der Regel nicht möglich, da häufig viele kleine Projekte nebeneinander her laufen. Außerdem handelt es sich hier nicht um Objekt – Systeme, also es liegt keine Fremdsteuerung vor wie bei Maschinen oder Produkten sondern es sind Subjekt – Systeme, die selbst gesteuert ablaufen können. Also ein Bauteil (Objekt) kann nicht sagen „holla da wurde mir aber eine Schraube zu früh an den Flansch montiert, da muss vorher noch die Dichtung drunter“, wogegen ein Mensch (Subjekt) merkt, wenn zwei Termine in seinen Kalender eingetragen wurden, die sich widersprechen. In Subjekt – Systemen wird es automatisch zu „revolvierenden“ Maßnahme kommen.
.
Fast Tracking ist eine Art Überlappung der Projektphasen im Projektlebenszyklus.
Fast Tracking bezeichnet den Versuch, durch Überlappung von Phasen das Zeitfenster
eines Projekts zu verkürzen. Sie sind nicht zu verwechseln mit einer
revolvierenden Planung. Man spricht in diesem Fall auch von Concurrent oder Simultaneous Engineering. Häufig werden aber dadurch Risiken erzeugt, die eher Nachteile hervorbringen können.
Folgende Beispiele beziehen sich auf den überlappenden Teil:
- Besitzer Phase 1 sieht Änderungsbedarf, Besitzer Phase 2
sieht Probleme in der Umsetzung, da schon erarbeitete Ergebnisse verworfen
oder modifiziert werden müssen. - Ergebnisse von Besitzer 1 werden nicht ausreichend kommuniziert. Es kommt zu
Konfigurationsunterschieden. - Besitzer 2 akzeptiert nicht die Änderungswünsche von Besitzer 1, da für ihn zusätzlicher Aufwand entsteht.
- Die ursprüngliche Schnittstelle EA wird jetzt durch EA – x ersetzt, was zu erschwerenden
Abhängigkeitsdarstellungen führen kann
Projektart und Projektkontext
Abhängig von der Projektart, wird es in der Phasenbildung zu mehr oder weniger häufigen Kommunikationsschnittstellen kommen. So muss das Change Control Board über Änderungsanträge entscheiden, der Auftraggeber über den Sachstand informiert werden oder neue Freigaben bestätigen. Mit staatlichen Institutionen müssen Rahmen-bedingungen verhandelt werden. Eventuell müssen Interessengruppen und Journalisten
ins Boot geholt werden, um unangenehme Entscheidungen öffentlich besser zu
kommunizieren.
Wie ein solches Umfeld in der Planungsphase eruiert werden kann und Stakeholder identifiziert werden, soll in einem der nächsten Artikel beschrieben werden.
