Ein passgenaues Projektmanagement ist erfolgsrelevant. Zum Verständnis dazu ein kleiner Exkurs ins tägliche Leben – am Fallbeispiel Mittagspause.
Oft entscheidet sich, was ich genau essen will, erst direkt vor Ort, sei es beim Bäcker, im Supermarkt oder in der Kantine. Denn erst wenn ich sehe, was es im Angebot gibt, kann ich beurteilen, was davon ich will. Bei komplexeren Dingen, wie zum Beispiel einem Autokauf, lerne ich erst durch Probefahrten und Gespräche mit Verkäufern, was es alles gibt. Und siehe da, nach einer Probefahrt will ich auf einmal eine Sitzheizung, deren Nutzwert mir vorher vielleicht nicht in den Sinn gekommen wäre. Hätte ich mein Wunschauto also vor der ersten Orientierung spezifizieren müssen – ich hätte spätestens im nächsten Winter gefroren.
Die Unterschiede zwischen Agil und Wasserfall in Kürze
Im Wasserfall-Modell werden alle zu erreichenden Ziele in der Projektdefinitionsphase festgezurrt, nach der Realisierung dann auf ihre Erfüllung hin gemessen. Es findet also sehr früh die definitive Festlegung der Ziele und der Weg zu deren Erreichung statt. Ändern sich die Ziele während der Projektlaufzeit, ist die Gefahr groß, im bekannten Change-Request-Dschungel zu landen, der erfahrungsgemäß Zeit und Nerven kostet.
In agilen Projekten werden die Ziele deshalb anfangs nur grob abgesteckt, damit die Richtung klar ist, die tatsächlichen Funktionsanforderungen dann aber pro Sprint / Time Box implementiert und am Ende jedes Sprints auf Erfüllung hin gemessen. Anforderungen, die spätere Sprints betreffen, sollten nur so formuliert sein, dass Wechselwirkungen mit der aktuellen Implementierung so gering wie möglich bleiben. Die exakte Ausformulierung des Zielsystems kann also fortlaufend nachgeschärft werden.
Schaut man jetzt einmal auf die 46 Projektmanagementelemente der GPM (Link Quelle), so stellt man fest, dass hiervon nur eine knappe Handvoll betroffen sind. Dies sind:
- Projektanforderungen und Projektziele
- Leistungsumfang und Lieferobjekte
- Projektphasen, Ablauf und Termine
- Überwachung und Steuerung, Berichtswesen
Die Unterschiede von Agil und Wasserfall im Detail
Projektanforderung und Projektziele / Leistungsumfang und Lieferobjekte
Beim agilen Vorgehen müssen die Anforderungen jeweils erst kurz vor der Time Box, in der sie implementiert werden, zur Verfügung stehen. Der Leistungsumfang und vor allem die Lieferobjekte werden demzufolge relativ kurzfristig festgelegt. Im Wasserfallmodell müssen alle Anforderungen hingegen zu Beginn der Implementierung schon stehen, auch wenn sie gemäß Planung erst in sechs Monaten implementiert werden.
Projektphasen, Ablauf und Termine
Im Wasserfallmodell werden alle Phasen und Termine zu Beginn festgelegt. Anschließend beginnt man den Abweichungen, die zwangsläufig entstehen, entgegenzusteuern. Inwieweit die langfristige Planung als Stütze oder Hindernis empfunden wird, ist hier von den Projektbeteiligten abhängig. Agilität heißt nicht, dies alles über den Haufen zu werfen. Es werden zwar wahrscheinlich weniger Meilensteine definiert, aber die klassischen wie Proof of Concept, User Acceptance Tests und Go-live werden sich nach wie vor wiederfinden. Der Ablauf erfolgt in Time-Boxen, die in ihrer zeitlichen Dauer (zwei bis vier Wochen) dem Projektinhalt entsprechend frei gewählt werden können.
Überwachung und Steuerung, Berichtswesen
Das Berichtswesen hat eventuell inhaltliche Unterschiede, kann aber in beiden Vorgehensarten problemlos erfolgen. Die Überwachung und Steuerung läuft ähnlich ab, allerdings bekommt der Auftraggeber im agilen Vorgehen früher Ergebnisse zu sehen, da am Ende einer jeden Time Box eine lauffähige Software ausgeliefert wird. Die Ergebnisüberwachung ist somit für den Auftraggeber in agilen Projekten einfacher als beim Wasserfall, wo es schon mal Monate dauert, bis der Kunde ein Ergebnis sehen und testen kann.
Zwischenfazit
Agilität im Projektvorgehen bietet Vorteile. Bei der Softwareerstellung entstehen neue Anwendungen, die es so vorher noch nicht gab. Über ein schrittweises Vorarbeiten lernt der Auftraggeber, was technisch alles möglich ist, und der Entwickler lernt die Fachlichkeit der Anwendung immer besser kennen. Hieraus entstehen Synergien, die die passende Lösung häufiger treffen, als eine drei Monate vorher geplante Lösung. Nichtsdestotrotz hat auch das Wasserfallmodell seine Berechtigung, bei hoher Klarheit der Ziele, verbunden mit einem guten Anforderungsprofil und einem relativ geringen Aufkommen von Change Requests, ist es eine durchaus brauchbare Vorgehensweise.
Die Kunst ist es, die passende Methode zu Projektbeginn zu erkennen und/oder das Beste aus beiden Welten zu kombinieren.
Und nun?
Mit den passenden Fragen können wir ein Gespür dafür zu entwickeln, welche der beiden Methoden geeigneter ist oder auch welche Mischform sich anbietet. Der folgende Fragenkatalog bietet eine Hilfestellung bei der Entscheidung darüber.
- Wie fest zementiert sind die Projektziele und wie klar kann das gewünschte Ergebnis spezifiziert werden?
Je größer die Unsicherheit, um so mehr empfiehlt sich ein iteratives Vorgehen, bei dem der Auftraggeber das Produkt so früh wie möglich sieht. Damit entsteht die Chance, an den richtigen Ecken die Ziele zu schärfen.
- Welche angestrebten Funktionen haben den größten Nutzen?
Gibt es Kernfunktionen, die frühzeitig implementiert werden müssen und von denen sich weitere Funktionen ableiten? Wenn ja, dann ist dies ein weiteres Argument für ein agiles Vorgehen.
- Qualität, Kosten, Zeit: Welche zwei sind in diesem Projekt führend?
Wenn die Zeit einer der wichtigsten Punkte ist, dann kann ein agiles Vorgehen dabei helfen, die wichtigsten Funktionen so früh wie möglich zu realisieren. Damit ist eine verkürzte Time-to-Market möglich, sofern es akzeptabel ist, weiter Funktionen nachzuliefern.
- Welche Durchführungsrisiken sind bekannt?
Gemeint sind nicht die technischen, sondern um die organisatorischen und sozialen Risiken. Wenn das Projektvorgehen und auch die Inhalte nicht bahnbrechend neu sind, bietet sich das Vorgehen an, mit dem schon vergleichbare Projekte im Unternehmen durchgeführt wurden.
- Ist dieses Projekt schon einmal gescheitert?
Wenn ja, so sollte genau analysiert werden, woran es lag. Ein Wechsel der Vorgehensmethodik kann die bereits bestehenden Probleme entweder verstärken oder mildern.
- Welche Art von Projektvorgehen passt besser zur Organisation?
Streng hierarchisch geführte Unternehmen haben mit dem flexiblen Vorgehen agiler Projekte unter Umständen massive Kulturprobleme. Hier ist ggf. ein zusätzliches Change-Projekt geboten. um die Kultur zu verändern.
- Lässt der Projektinhalt ein flexibles Vorgehen zu?
Bestimmte Randparameter (Materialbeschaffung, Vertragslaufzeiten u. Ä.) verhindern evtl. ein flächendeckendes agiles Vorgehen. Hier kann allerdings auch das Projektmanagement der zwei Geschwindigkeiten helfen. Zum Beispiel kann dieElektronik gemäß Wasserfall und die Bediensoftware agil entwickelt werden.
- Passt das Projektvorgehen zum Projektleiter und den Architekten?
Agiles Projektmanagement basiert unabhängig von der Variante auf dem Modell des Servant Leaderships. Die Projektleitung, organisatorisch und technisch, hat hier eher die Aufgabe, zu moderieren. Entscheidungen werden nicht basis-demokratisch getroffen, aber sie sollten aus allen Blickwinkeln der Stakeholder betrachtet worden sein. Hierbei ist anzumerken, dass ein Projektleiter, der seine Arbeit am Servant Leadership orientiert, keine Wasserfall-Projekte leiten kann.
Diese Fragen stellen nur einen Grundstein dar und sind möglicherweise nicht alle zutreffend. Dieser Fragenkatalog erhebt auch nicht den Anspruch, vollständig zu sein und sollte während der Projektinitiierungsphase mit erfahrenen Kollegen erweitert bzw. erarbeitet werden.
Fazit
Die Entscheidung über das geeignete Vorgehen sollte so früh wie möglich gefällt und beibehalten werden. Ein Bruch im Vorgehen während des Projektverlaufs führt in den seltensten Fällen zu einer Verbesserung. Wichtig ist, dass die Stakeholder und die Projektbeteiligten auf Auftraggeber- und Auftragnehmerseite hinter dem Vorgehen stehen. Je nach Erfahrung ist es empfehlenswert, den Projektmitarbeitern einen Vorgehensexperten zur Seite zu stellen, so dass die Möglichkeit besteht, Vorgehensprobleme getrennt von den inhaltlichen Problemen des Projektes zu analysieren und zu lösen. Dies entlastet auch den Projektleiter, dem sonst eine Doppelrolle zufiele.
Empfehlung der Redaktion: Zu einem erfolgreichen Projektmanagement gehört auch ein professionelles Qualitätsmanagement. In diesem Blogbeitrag von Tobias Pressel erfahren Sie mehr dazu.
