• Phase oder Prozessgruppe?
• Klassisches (Wasserfall) Modell
• Agiles Modell
• Hybrides Modell
• Zusammenfassung

 Jeder Projektmanager weiß, dass die Projekte gewisse P​rojektphasen und Prozessgruppen durchlaufen müssen, um erfolgreich zu sein. 

Dabei ist es als Erstes wichtig zu wissen, was der Unterschied zwischen Pr​ojektphasen und Prozessgruppen ist.

Zweitens ist es entscheidend zu wissen, nach welchem Phasenmodell ein Projekt abgewickelt wird.

Denn eine falsche Entscheidung bezüglich der Gestaltung der Projektphasen am Anfang eines Projektes kann gravierende Folgen für den späteren Verlauf eines Projektes haben.

In diesem Beitrag möchte ich verschiedene Modelle von Projektphasen beschreiben und aufzeigen, dass es sehr wohl Unterschiede gibt und welche Art für welches Projekt empfehlenswert ist.

Phase oder Prozessgruppe?

Je nach Größe und Komplexität eines Projektes kann es eine oder mehrere Projektmanagement Phasen geben.

Dabei ist unbedingt zu beachten, dass eine Projektphase gemäß PMI (Project Management Institute) mehrere Prozessgruppen enthalten oder eine Prozessgruppe = eine Projektphase sein kann.

Einzelne Prozessgruppen heißen:

1.Initiierung

2.Planung

3.Durchführung

4.Überwachung und Steuerung

5.Abschluss

Prozessgruppe Initiierung

In dieser Prozessgruppe geht es darum, die wichtigsten Kriterien und das Ziel für den Phasenstart festzulegen.

Prozessgruppe Planung

Diese Prozessgruppe beschäftigt sich mit der Detailplanung einer Phase und welche Arbeiten während der nächsten Prozessgruppen erledigt werden sollen.

Prozessgruppe Durchführung

Hier geht es um das Doing. Alles, was in den Prozessgruppen Initiierung und Planung festgelegt wurde, soll entsprechend umgesetzt werden.

Prozessgruppe Überwachung und Steuerung

Diese Prozessgruppe findet im Prinzip während jeder Prozessgruppe statt, da die Überwachung und Steuerung der festlegten Phasenziele und Kriterien ein kontinuierlicher Prozess ist und regelmäßige Anpassungen notwendig sind

Prozessgruppe Abschluss

In dieser Prozessgruppe geht es um den Abschluss einer Phase. Dazu gehören z.B. Lessons Learned.

Wenn ein Projekt mehrere Phasen enthält, wiederholen sich die Prozessgruppen entsprechend pro Phase. Im folgenden gehe ich auf einzelne Phasenmodelle ein und ihre Anwendung in der Projektwelt.

Klassisches (Wasserfall) Modell

Ein klassisches Projekt mit dem Wasserfallmodell hat nur eine einzige Projektphase, welche folgende Prozessgruppen enthält: Projektstart, Projektplanung, Projektdurchführung, Projektüberwachung und Steuerung und Projektabschluss.

Projektstart

In dieser Prozessgruppe geht es vor allem darum, dass der Projektsteckauftrag auch Project Charter genannt als One-bzw. Zwei-Pager erstellt und offiziell für den Projektstart freigegeben wird. Dieses Dokument enthält unter anderem folgende Punkte:

• Projektziel
• Kurze Projektbeschreibung
• Stakeholder Gruppen
• Ressourcenanforderungen
• Getroffene Annahmen im Projekt
• Erwartete Vorteile durch das Projekt
• Projekteinschränkungen
• Kritische Erfolgsfaktoren
• Potentielle high level Risiken
• Erwartetes Budget
• Wichtigste zu erwartende Ergebnisse (Key Deliverables) und Akzeptanzkriterien
• Zeitschiene
• Ganz wichtig: Was gehört nicht zum Projektumfang

Darüber hinaus beschäftigt sich der Projektmanager in dieser Phase damit festzulegen, wer  als Stakeholder im Projekt sein wird

Projektplanung

In der Prozessgruppe Projektplanung geht es ganz viel um die Planung des Projektes für verschiedene Hauptbereiche wie z.B.:

• Detaillierte Planung des Projektumfangs
• Detaillierte Budget Planung
• Detaillierte Planung der Zeitschiene
• Detaillierte Risikobetrachtung
• Qualitätsmanagement Planung

Projektdurchführung

Nach einer ausführlichen Planung ist es selbstverständlich notwendig, dass die geplanten Aktivitäten auch umgesetzt werden. Im Idealfall läuft alles nach Plan und alle geplanten Aktivitäten werden umgesetzt.

Das passiert natürlich nie, sondern es müssen immer wieder Korrekturen im Projekt durchgeführt und ein aktives Projekt Change Management betrieben werden, was uns zur nächsten Projektgruppe Projektüberwachung und Steuerung führt.

Projektüberwachung und Steuerung

Diese Prozessgruppe ist allgegenwärtig. In regelmäßigen Abständen wird der Fortschritt eines Projektes überprüft und mit dem ursprünglichen Plan abgeglichen und in die Richtung Projektziel nachgesteuert.

Dabei werden z.B. folgende Hauptbereiche regelmäßig überprüft:

• Validierung und Steuerung des Projektumfangs
• Überwachung und Steuerung des Projektplans
• Budgetüberwachung und ggf. Korrektur
• Qualitätskontrolle
• Überwachung der Risiken
• Überwachung der Lieferanten

Projektabschluss

Am Ende eines Projektes ist es erforderlich, ein Projekt offiziell abzuschließen. Dafür kann eine Checkliste behilflich sein, die z.B. folgende Elemente enthält:

• Sind alle Projektarbeiten abgeschlossen worden, die im Rahmen der Arbeitspakete definiert worden?
• Sind alle Arbeitspakete geprüft und akzeptiert worden?
• Sind alle Projektziele erreicht worden?
• Ganz wichtig: Ist der Projekterfolg gefeiert, dem Team gedankt und gute Leistungen anerkannt worden?
• Sind alle Projektressourcen für andere Projekte freigegeben worden?
• Auch ganz wichtig und oft vergessen: Sind alle Projektinformationen gesammelt, geprüft und gemäß Organisationsvorgaben archiviert worden?
• Sind Lessons Learned durchgeführt, dokumentiert und daraus resultierende Maßnahmen für die nächste Projektphase und neue Projekte berücksichtigt worden

V-Modell

In der technischen Produktentwicklung kommt oft das V-Modell zum Einsatz, dass folgende Schritte enthält:

1. Anforderungsanalyse

2. Systemarchitektur und Systementwurf

3. Detailliertes Design z.B. auf der Modulebene

4. Domänenspezifische Umsetzung (Mechanik, Software, Elektronik)

5. Integrationstets z.B. auf der Modulebene

6. Systemintegration

7. Produktabnahmetests und Übergabe an den Kunden.

Agiles Modell

Das agile Phasenmodell enthält immer mehrere Projektmanagement Phasen, die in SCRUM in Form von Sprints (Iterationen) erfolgen. Ein Sprint dauert maximal einen Monat.

Der nächste Sprint startet nahtlos nach dem vorherigen Sprint. SCRUM ist das am meisten verbreitete Framework als agile Projektmanagementmethode.

Ein Sprint enthält mehrere Events: Sprint Planung, Daily Scrum, Sprint Review und Sprint Retrospektive.

Beim Vergleich von Prozessgruppen und Sprint Events fallen viele Ähnlichkeiten auf:

Initiierung + Planung = Sprint Planung

Sprint Planung verfolgt zwei Hauptthemen 1. Was kann in einem Sprint gemacht werden und 2. Wie kann die gewählte Arbeit gemacht werden.

Darüber hinaus wird ein Sprint Ziel festgelegt, das das Team während der Abarbeitung der Aufgaben ständig vor Augen hat.

Damit ähneln die Prozessgruppen Initiierung und Planung im klassischen Sinne der Sprint Planung. 

Durchführung = Daily Scrum

Daily Scrum ist ein tägliches 15 minütiges Treffen eines agilen Entwicklungsteams, wo jedes Teammitglied drei Fragen beantwortet:

1. Was hast du gestern gemacht, das dem Entwicklungsteam geholfen hat, das Sprint Ziel zu erreichen

2. Was willst du heute machen, um dem Entwicklungsteam zu helfen, das Sprint Ziel zu erreichen.

3. Siehst du Hindernisse, die dich davon abhalten, das Sprint Ziel zu erreichen?

Auch wenn während der Prozessgruppe Durchführung diese drei Fragen nicht explizit beantwortet werden müssen, geht es letztendlich wie im Daily Scrum um die tägliche Abarbeitung der geplanten Aufgaben. 

Überwachung und Steuerung = Sprint Review

Wie bereits beschrieben, erfolgt die Überwachung und Steuerung in einer Phase wie auch im klassischen Modell, indem unter anderem die Validierung und Qualitätskontrolle des gelieferten Umfangs überprüft wird.

Während eines Sprint Reviews werden die im Sprint umgesetzten Funktionalitäten in Anwesenheit von erforderlichen Stakeholdern überprüft, wenn es z.B. um ein technisches Produkt oder Software Funktionen geht. 

Damit hat die Prozessgruppe Überwachung und Steuerung viele Ähnlichkeiten zum Sprint Review.

Abschluss = Sprint Retrospektive

Wie bereits erwähnt, werden zum Abschluss einer Phase auch Lessons Learned durchgeführt. Die Sprint Retrospektive ist ähnlich der Prozessgruppe Abschluss. Während einer Sprint Retrospektive geht es um Folgendes:

1. Reflektieren, wie der vergangene Sprint in Bezug auf das Team, Beziehungen, Prozesse und Tools gelaufen ist

2. Identifikation und Priorisierung von Hauptelementen, die während eines Sprints gut gelaufen sind und welche Verbesserungen notwendig sind.

3. Einen Plan erstellen, wie die Umsetzung von Verbesserungen in einem der nächsten Sprints erfolgen kann.

Dieser Vergleich zeigt nochmal, dass die Gestaltung einer Projektphase mit entsprechenden Prozessgruppen gleiche Grundprinzipien bei der Abwicklung eines Projektes hat unabhängig davon, ob ein Projekt klassisch oder agil abgewickelt wird.

Der Hauptunterschied eines klassischen vom agilen Phasenmodell besteht darin, dass es bei der agilen Vorgehensweise eine viel häufigere Überprüfung der Teilergebnisse eines Produktes durch Sprints erfolgt, als dies im klassischen Phasenmodell der Fall ist und somit die Korrekturen viel früher erfolgen können.

Ein weiterer wichtiger Bestandteil eines agilen Phasenmodells ist der starke Fokus auf das zu entwickelnde Produkt, was im klassischen Modell leider in vielen Fällen verloren geht, da viele Prozesse letztendlich doch im Wege stehen.

Hybrides Modell

Ein hybrides Modell besteht aus der Integration der klassischen und agilen Methoden natürlich abhängig von der Komplexität und Größe eines Projektes.

WIN-WIN Lösung

Es gibt ca. 10% der Projekte, die einfach und linear abgewickelt werden können, wenn dafür das klassische Modell mit einer einzigen Projektphase und entsprechenden 5 Prozessgruppen angewandt wird.

Weitere 10% der Projekte sind ziemlich komplex und sind oft im innovativen Bereich zu finden.

Da macht es keinen Sinn, ein klassisches Modell zum Einsatz zu bringen, da bei solchen Projekten eine ganz andere Denkweise erforderlich ist wie dies z.B. bei Design Thinking der Fall ist.

Die restlichen 80% der Projekte befinden sich irgendwo zwischendrin und solche Projekte sind am besten aufgehoben, wenn aus beiden Welten das Beste angewandt wird.

Wenn es z.B. in einem Projekt um eine technische Entwicklung geht, wo Hardware und Software im Spiel sind, wäre es sehr gut möglich für die Softwareentwicklung agile Methoden und für die Hardwareentwicklung klassische Methoden anzuwenden.

Eine Festlegung der hybriden Vorgehensweise ist für jedes Unternehmen unterschiedlich und soll auch individuell betrachtet werden.

Dabei ist ganz wichtig, die Unternehmensstrategie im Auge zu behalten und die Projekte im Rahmen des Projektportfolios ganzheitlich zu betrachten.

Wenn dieses Mindset in einem Unternehmen gegeben ist, steht nichts mehre im Wege, eine hybride Lösung zu erarbeiten, die einen deutlichen Vorsprung gegenüber der Konkurrenz bieten kann.

Zusammenfassung

In den letzten 15+ Jahren konnte ein Kampf zwischen beiden Projektwelten klassisch und agil beobachtet werden.

Die Verfechter der agilen Projektwelt haben alles dran gesetzt, den Verfechtern der klassischen Welt zu beweisen, dass rein die agile Methode die Beste.

Das umgekehrte Spiel seitens der Verfechter der klassischen Welt war auch zu beobachten. Dieser Kamp ist heutzutage auch noch spürbar.

Besonders schade ist es, wenn diese Kämpfe innerhalb eines Unternehmens ausgetragen werden. Denn in diesem Fall verlieren letztendlich beide, da die Ziele des Unternehmens nicht mehr im Fokus sind.

In meiner langjährigen Erfahrung als Projektmanager habe ich immer den Fokus darauf gerichtet, viele Vorgehensweisen in Projekten  zu testen, auszuprobieren, zu kombinieren und das Beste aus beiden Welten mitzunehmen.  Und das ist mir jedes Mal gelungen.

Letztendlich geht es darum, dass die Projekte effektiv, effizient und mit Erfolg abgewickelt werden, unabhängig davon, welche Projektmanagementmethode angewandt wird.

Meine klare Empfehlung ist, das Beste aus beiden Welten zu nehmen. Bei der Umsetzung ist es immer hilfreich, 2-3 Pilotprojekte zu starten, wo hybride Methoden in Projektmanagement Phasen ausprobiert und getestet werden.

Wenn das gut funktioniert, kann eine Umstellung aller Projekte nach Abstimmung mit allen wichtigen Stakeholdern in Betracht gezogen werden.