Klassisches oder agiles Projektmanagement? Diese Frage hat sich in vielen Unternehmen zu einer Glaubensfrage entwickelt. Dabei haben beide Ansätze Stärken und Schwächen. Deshalb ist es in der Praxis oft sinnvoll, beim Planen und Managen von Projekten das Beste bzw. Zielführendste aus beiden Welten zu vereinen.
Die Tektonik befasst sich mit den Kontinentalplatten der Erde. Diese bewegen sich, also entfernen sie sich voneinander und driften aufeinander zu. Die hieraus resultierenden Spannungen führen zu Erdbeben und Vulkanausbrüchen. Und diese lösen wiederum Tsunamis und Überschwemmungen aus, die oft unvorstellbare Schäden bewirken – wie zum Beispiel der Tsunami 2004 im indischen Ozean und 2011 im japanischen Fukushima.
Ähnliche Spannungen, die zu folgenschweren Schäden führen, registriert man nicht selten in Unternehmen, wenn es um die Frage geht: Auf welche Methoden setzen wir beim Projektmanagement – auf agile Methoden oder die (klassischen) Wasserfall-Methoden? Dann stehen sich die Anhänger der beiden Vorgehensweisen, weil es für beide Pro- und Contra-Argumente gibt, oft unversöhnlich gegenüber. Und welches Vorgehen letztendlich gewählt wird, hängt häufig primär von der Kultur im Unternehmen sowie den Machtverhältnissen in ihm ab und nicht davon, welches Vorgehen zielführend ist.
Deshalb gibt es in dem damit verbundenen Meinungsbildungs- und Entscheidungsprozess in der Regel auch Verlierer bzw. Personen oder Bereiche, die sich als solche empfinden. Und hieraus resultiert oft ein Dauerkonflikt, der nicht selten zu einem Scheitern der Projekte führt. Das legt zumindest eine Studie des Researchunternehmens Forrester nah. Ihr zufolge scheitert circa die Hälfte aller (Change-)Projekte in Unternehmen, und nicht unwesentlich verantwortlich hierfür ist die „organisatorische Kollision“ der Methoden.
Das klassische Projektmanagement gemäß dem Wasserfall-Modell
Dem Wasserfall-Modell zufolge besteht ein Projekt aus genau definierten, aufeinander folgenden Phasen; ebenso ist dies beim V-Modell, einer Weiterentwicklung des Wasserfall-Modells.
Ursprünglich stammt dieses Modell aus dem Bau- und Produktionsprozess, bei dem hochstrukturierte Abläufe eingehalten werden müssen, da späte Änderungen teuer oder sogar unmöglich sind. Ziel ist es, das bestmögliche Endprodukt zu produzieren – mit wenig Flexibilität für Änderungen, wenn das Produkt fertig ist.
Die wesentlichen Projektphasen im Wasserfall-Modell zum Beispiel beim Hausbau sind:
1. Anforderungsphase
2. Entwurfsphaseoft
3. Implementierung
4. Überprüfung und
5. Inbetriebnahme
(6. Wartung)
In der Phase 1 „Anforderungsphase“ werden zunächst die Anforderungen vollständig dokumentiert, um daraus ein Lasten- oder Pflichtenheft zu entwickeln. Erst danach wird ein Projektplan erstellt und werden die wahrscheinlichen Aufwendungen ermittelt. Große Aufgaben werden im Zuge der Projektplanung in kleine Teilaufgaben gegliedert und alle Aufgaben bezüglich des Zeit- und Ergebnisverlaufs miteinander verbunden.
In der Entwurfsphase (Phase 2) wird das Lösungskonzept erarbeitet. Die Implementierungsphase (Phase 3) umfasst die gesamte Umsetzung der Anforderungen auf Basis des Lastenhefts und innerhalb des Projektplans. Das Ergebnis der Implementierungsphase ist ein Haus, das in der nachfolgenden Überprüfungsphase (Phase 4) zum ersten Mal als Gesamtprodukt getestet wird (Alpha-Test).Dies geschieht in der Regel durch die Planer selbst. Nach dem erfolgreichen Abschluss derÜberprüfungsphase wird das Produkt für die Nutzung freigegeben – in der fünften undletzten Phase des Modells (Inbetriebnahme). Auftretende Fehler werden behoben, notwendige Verbesserungen und Ergänzungen eingebaut.
Wo liegen die Risiken?
Theoretisch soll das Wasserfall- bzw. V-Modell Projektrisiken sowohl kosten- als auch terminseitig vermeiden. Sinnvoll ist sein Einsatz daher bei Projekten, bei denen sich auf Sicht nichts ändert und bei denen es fast keine Anpassungen gibt. Ideal sind Projekte, die sich in Struktur und Aufgabenstellung wiederholen und über einen überschaubaren Zeitraum laufen. Das sind oft regulierte Projekte, bei denen es darauf ankommt, Gesetze und Vorschriften einzuhalten, und bei denen eine umfassende Dokumentation nötig ist, wie z. B. im Baubereich, in der Pharmaindustrie oder Medizintechnik.
Die Erfahrung zeigt jedoch, dass nicht alle Projekte diesen Parametern unterliegen. Deshalb birgt die Wasserfall-Methode auch viele Risiken. Ähnlich verhält es sich bei fast allen größeren Change- und Transformationsprojekten in Unternehmen – unter anderem, weil in ihnen meist auch eine passende unterstützende Software-Lösung entwickelt und/ oder implementiert werden muss. Dies ist ein Grund, warum viele Unternehmen nach anderen Projektmanagement-Ansätzen suchen.
Ein weiterer ist: Die Komplexität der Anforderungen und die bestehenden Wechselwirkungenim System lassen es bei vielen Projekten kaum zu, klare Projektphasen zu planen.Hinzu kommt ein sich schnell wandelndes Umfeld mit nicht planbaren neuen Erkenntnissenund Einflüssen. Ungeplante Verläufe, neue Informationen und komplexe Strukturen führen beim klassischen Projektmanagement oft dazu, dass Projekte gestoppt und neu ausgerichtet werden müssen. Drastische Terminund Kostenverschiebungen sind die Folge.
Das agile Projektmanagement: eine Antwort auf die gestiegene Komplexität
Das agile Projektmanagement – zum Beispiel bei der Softwareentwicklung – bedient sich meist des Scrum-Modells. Dies steht im Gegensatz zum Wasserfall- bzw. V-Modell. Der wesentliche Unterschied ist: Das (Entwicklungs-) Projekt wird nicht von vorne bis hinten durchgeplant, vielmehr folgt das Vorgehen einer Vision. Dadurch entfallen detaillierte Lasten- und Pflichtenhefte. Zudem ist das Vorgehen inkrementell, also in kleinen aufeinander aufbauenden Schritten erfolgend, und iterativ, also sich in Reflexions- und Wiederholungsschleifen vollziehend. Ein Scrum-Projekt hat drei Kernelemente: das Product Backlog, das Sprint Backlog und das Produkt-Inkrement. Im Mittelpunkt des Geschehens stehen jedoch die Stakeholder (Kunden/Anwender) und die User-Stories. Die User-Stories beschreiben die Anforderungen an das Endprodukt bzw. die Problemlösung aus der Perspektive eines Benutzers. Sie werden meist vom Product- Owner – also der Person, die letztlich für die Arbeit des Entwicklungsteams und die Qualität des Endprodukts verantwortlich ist – mit den Stakeholdern verfasst.
Die User-Stories werden parallel zur Entwicklung in einem fortlaufenden Prozess definiert.
Das Projekt selbst gliedert sich beim agilen Projektmanagement nicht in Phasen, sondern eine Abfolge circa drei- bis vierwöchiger Sprints. In ihnen werden die User-Stories den Entwicklungsteams zugewiesen und zwar jeweils so viele, wie vom Team in dieser Zeit leistbar sind. Tägliche Kurzmeetings, Dailies genannt, dienen der Transparenz und Kommunikation innerhalb der Scrum- bzw. Planungsteams. Probleme werden dort angesprochen und gegebenenfalls sofort gelöst. Ist ein Sprint zu Ende, steht das entwickelte Produkt-Inkrement dem Scrum-Team und den Stakeholdern zur Verfügung. Der nächste Sprint kann gestartet werden.
Das Scrum-Modell entstand aus der Erkenntnis, dass viele Bau-Projekte heute sehr komplex sind und einer permanenten Veränderung im Projektverlauf unterliegen. Zudem sind zu Beginn die Vorgaben und Anforderungen oft unklar. Ein agiles Vorgehen ist jedoch keine Erfolgsgarantie. Das zeigen zahlreiche Projekte. Die wesentliche Schwachstelle bei Scrum-Projekten ist die Abschätzung der Stories durch die Entwickler. Oft sind diese zu optimistisch. Deshalb werden die Ziele der Sprints nicht erreicht. Das erschwert es der Projektleitung, einen längeren Zeitraum zu planen und zu budgetieren. Eine gewisse Planungssicherheit besteht meist nur in einem, maximal zwei Sprint-Zyklen.
Ein zentraler Erfolgsfaktor bei agilen Projekten ist die Reife und Homogenität des Entwicklungsteams. Dieser Anforderung wird in der Praxis oft kaum Rechnung getragen; am wenigsten in Organisationen, die im Übergang von der traditionellen zur agilen Planung sind. Sie unterschätzen oft auch die damit verbundene kulturelle und organisatorische Herausforderung.
Unternehmen im Übergang beim Projektmanagement
Die meisten Unternehmen sind heute als Gesamtorganisation weder agil, noch nicht agil. Denn sie sehen sich seit Jahren mit einer erhöhten Komplexität konfrontiert und suchen nach Möglichkeiten, flexibler auf neue Herausforderungen zu reagieren. Dabei wird das Einbeziehen der Mitarbeiter meist als Schlüssel zu mehr Flexibilität und einer höheren Performance gesehen. Und agile Vorgehensweisen werden „ausprobiert“ in der Hoffnung auf bessere und kundenspezifischere Lösungen.
Deshalb existieren in den Unternehmen Managementbeim Projektmanagement oft „Zwitter“: Neue Mitarbeiter werden an Bord geholt mit dem Versprechen einer agilen, selbstbestimmten Arbeitsweise. Zugleich „leben“ in der Organisation jedoch noch die alten Strukturen und das klassische Projektmanagement: Es existieren beim Projektmanagement sozusagen Parallelwelten. Diese sind im Stadium des Übergangs normal und müssen gemanagt werden. Das gilt insbesondere dann, wenn die Entscheidungsträger in der IT oder der Geschäftsführung einem agilen Projektmanagement eher kritisch bzw. abwartend skeptisch gegenüberstehen.
Herausforderung:
Parallelwelten managen
Eine klare Kommunikation der Parallelwelten ist das Fundament, auf das Unternehmen in der Übergangsphase setzen sollten, denn klar ist: Es ist nicht möglich, den berühmten Schalter umzulegen, um vom klassischen zum agilen Projektmanagement zu kommen. Und wäre es so, dass mit einem ausschließlich agilen Projektmanagement alle Probleme beseitigt wären, dann hätten die Unternehmen jahrzehntelang große Fehler gemacht. Agile Projekte haben auch Probleme, jedoch andere. Deshalb ist es wichtig, klar zu kommunizieren, welche Projekte nach welchen Regeln durchgeführt werden – und hierfür ist auch eine Kenntnis der verschiedenen Projektarten wie Routine-, Innovationsprojekte, Akzeptanz- und Wandel- bzw. Changeprojekte nötig.
Ein agiles Projektmanagement ist darauf ausgerichtet, die Kunden und Anwender direkt in den Entwicklungs- bzw. Problemlösungsprozess einzubinden und schnell sichtbare Zwischenergebnisse zu erzielen; das klassische Projektmanagement hingegen fokussiert auf eine umfassende Planung und Dokumentation vor dem Projektstart. Irritationen entstehen in Unternehmen, wenn zum Beispiel neue Mitarbeiter mit dem Versprechen von Agilität „an Bord“ geholt werden, sich dann jedoch mit dem klassischen Projektmanagement-Ansatz konfrontiert sehen. Diese Irritationen wirken leistungsmindernd.
Da beide Vorgehensweisen ihre Berechtigung haben, stellt sich die Frage: Wann die eine, wann die andere? Um diese zu beantworten, ist eine eindeutige Kommunikation nötig; außerdem muss auch auf der Führungsebene ein Verständnis für ein „sowohl als auch“ geschaffen werden. Erfahrene Projektleiter spielen ohnehin in beiden Segmenten. Die Praxis zeigt: Wenn beide Seiten – also „Befürworter“ und „Gegner“ der verschiedenen Projektmanagement-Ansätze – wenig Verständnis füreinander haben und deshalb eine Schein-Agilität eingeführt wird, ist dies der schlechteste Weg. Also gilt es, bei den Stakeholdern und den Projektbeteiligten das nötige Verständnis für die beiden Ansätze herbeiführen. Dann kann undogmatisch und erfolgsorientiert entschieden werden, welches Prinzip bei welchem Projekt gilt.
Hybrides Projektmanagement:
Das Beste aus zwei Welten vereinen
Ein hybrides Projektmanagement hat zum Ziel, eine optimale Arbeitsumgebung für die Teams zu schaffen – ohne Dogmen. Deshalb werden in hybriden Projekten Methoden und Werkzeuge aus beiden Welten genutzt.
Am Anfang eines hybriden Projektmanagements steht die Analyse-Phase – jedoch nicht des Gesamtprojekts in der Tiefe, sondern in einer eher groben Granulierung.
Diese Phase wird begleitet von einer generellen Planung. Nun wird das Grobgranulare aufgeteilt in Projektschritte und ab diesem Augenblick werden agile Methoden eingesetzt und Anforderungs- und Entwurfsphase, Implementierung sowie die Überprüfung parallel gefahren. Regelmäßige Dailies sorgen dabei dafür, dass sich alle Beteiligten synchronisieren können.
Die Phasen des Wasserfalls werden beim hybriden Projektmanagement in Iterationen, also Sprints, aufgeteilt. Dabei können alle Phasen des klassischen Wasserfall-Modells in einem Sprint vorkommen. So kann zum Beispiel innerhalb eines Sprints die Analyse detailliert werden, ebenso das Systemdesign. Daraus entstehen im laufenden Sprint dann die User-Stories für den nächsten Sprint. Analog dazu finden in einem Sprint die Entwicklung, der Test und am Ende des Sprints auch die Inbetriebnahme der Alpha-Version des Sprint-Ergebnisses statt. Dabei sind alle Methoden der agilen Vorgehensweise jedoch eingebettet in Wasserfall-Prinzipien.
Anstelle eines Statusmeetings endet der Sprint mit einem Review und der Retrospektive, bevor der nächste Sprint gestartet wird. Alle gesammelten Erfahrungen kommen hierbei auf den Tisch und werden mit dem gesamten noch folgenden Projekt abgeglichen. Es kann sein, dass dadurch Termine verschoben, Ressourcen angepasst und Erwartungen verändert werden müssen. Aber das Wesentliche hierbei ist: Die Risiken des Projekts werden mit jeder Iteration kleiner und treten nicht erst gegen Ende des Projekts zutage.
Changemanagement gehört dazu
Aus dem Geschriebenen geht hervor: Das Zusammenspiel agiler und konventioneller Projektmethoden stellt beim Bestreben, die Agilität von Unternehmen zu erhöhen, einen natürlichen Entwicklungsschritt dar und damit geht ein Kultur- und Strukturwandel in der Organisation einher. Deshalb sollte dieser Prozess durch ein professionelles Change-
Management bewusst sowie gezielt und geplant gesteuert werden. Die Aufgabe des Managements hierbei ist es, das Nebeneinander neuer und konventioneller Arbeitsweisen in Projekten zu ermöglichen und die erforderlichen Rahmenbedingungen hierfür zu schaffen. Dazu gehört es auch, die unterschiedlichen Rollen, die in den verschiedenen Projekten wahrgenommen werden, zu kommunizieren und für eine größtmögliche Transparenz zu sorgen.
Für viele „Anhänger“ der agilen Methode bzw. des klassischen Projektmanagements wurde es zur Glaubensfrage, welcher Ansatz in Projekten den Vorzug verdient. Eine Kultur der Offenheit und Unvoreingenommenheit ist hier von Vorteil. Diese gilt es bereichs-, funktions- und hierarchieübergreifend in den Unternehmen zu schaffen. Dann ist beim Projektmanagement auch die Tektonik beherrschbar.
