Klassisches oder agiles Projektmanagement? Oder: Spielt die Tektonik mit?

Klassisches oder agiles Projektmanagement – Oder doch hybrides 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, das Beste bzw. Zielführendste aus den beiden Projektmanagement-Welten zu vereinen.

Die Tektonik befasst sich mit den Kontinentalplatten der Erde. Diese bewegen sich, also entfernen 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.

Ähnlich 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 oder die (klassischen) Wasserfall-Methoden? Dann stehen sich die Anhänger der beiden Vorgehensweisen oft unversöhnlich gegenüber. Und welches Vorgehen letztendlich gewählt wird, hängt 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 nahe. 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. Die wesentlichen Phasen im Wasserfall-Modell sind zum Beispiel bei der Softwareentwicklung:

1. Analyse
2. Design
3. Implementierung
4. Test und
5. Betrieb

In der Phase 1 „Analyse“ 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 Teilaufgaben gegliedert und alle Aufgaben bezüglich des Zeit- und Ergebnisverlaufs miteinander verbunden.

In der Design-Phase (Phase 2) wird das Lösungskonzept erarbeitet. Bei Software-Projekten sind dies die Architektur und das Systemdesign. Die Implementierungsphase (Phase 3) umfasst die gesamte Programmierung der Anforderungen auf Basis des Lastenhefts und im Rahmen des Projektplans. Das Ergebnis der Implementierungsphase ist ein Software-Produkt, das in der nachfolgenden Test-Phase (Phase 4) zum ersten Mal als Gesamtprodukt getestet wird (Alpha-Test). Dies geschieht meist durch die Entwickler selbst. Als Beta-Version geht die Software danach an ausgewählte Endnutzer, und erst hier zeigt sich, ob das Produkt die zuvor definierten Anforderungen und Erwartungen der Anwender erfüllt. Nach dem erfolgreichen Abschluss der Testphase wird die Software für den Betrieb freigegeben bzw. ein Release erstellt. Mit dem Release beginnt der Einsatz der Software und die fünfte und letzte Phase des Modells (Betrieb). Auftretende Fehler werden behoben, notwendige Verbesserungen und Ergänzungen eingebaut.

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 es kaum Anpassungen gibt. Ideal sind Projekte, die sich in Struktur und Aufgabenstellung wiederholen und einen überschaubaren Zeitraum dauern. Das sind oft regulierte Projekte, bei denen

• es darauf ankommt, Gesetze und Vorschriften einzuhalten, und
• eine umfassende Dokumentation nötig ist wie z.B. in der Pharmaindustrie oder Medizintechnik.

Die Erfahrung zeigt jedoch, dass zum Beispiel nur wenige Software-Projekte diesen Parametern unterliegen. Deshalb birgt die Wasserfall-Methode bei der Softwareentwicklung viele Risiken. Ähnlich verhält es bei fast allen größeren Change- und Transformationsprojekten in Unternehmen. Dies ist ein Grund, warum viele Unternehmen nach anderen Projektmanagement-Ansätzen suchen. Ein weiterer ist: Die Komplexität der Anforderungen und die bestehenden Wechselwirkungen im System lassen es bei vielen Projekten kaum zu, klare Projektphasen zu planen. Hinzu kommt ein sich schnell wandelndes Umfeld, mit nicht planbaren neuen Erkenntnissen und 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 Termin- und 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. Sein wesentlicher Unterschied zum Wasserfall- bzw. V-Modell 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-Storys. Die User-Storys beschreiben die Anforderungen an das Endprodukt bzw. die Problemlösung aus der Benutzerperspektive. 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-Storys 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-Storys den Entwicklungsteams zugewiesen und zwar jeweils so viele wie vom Team in dieser Zeit leistbar sind. Tägliche Kurzmeetings, Dailys genannt, dienen der Transparenz und Kommunikation innerhalb der SCRUM- bzw. Entwicklungsteams. 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 zum Beispiel als lauffähige Software zur Verfügung. Der nächste Sprint kann gestartet werden.

Das SCRUM-Modell entstand aus der Erkenntnis, dass viele Software-und IT-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. Eine wesentliche Schwachstelle bei SCRUM-Projekten ist: Die Einschätzung des Machbaren in einem Sprint durch die Entwickler ist oft zu optimistisch. Deshalb werden die Sprintziele nicht erreicht. Das erschwert es der Projektleitung, einen längeren Zeitraum zu planen und zu budgetieren.

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 erachtet. Also werden agile Vorgehensweisen „ausprobiert“.

Deshalb existieren aktuell in den Unternehmen beim 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 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über stehen.

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 gelangen. Zudem haben agile Projekte auch Probleme, jedoch andere. Deshalb ist es wichtig, klar zu kommunizieren, welche Projekte nach welchen Regeln durchgeführt.

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. 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 insbesondere auf der Führungsebene ein Verständnis für ein „sowohl, als auch“ geschaffen werden. 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 einem generellen Systemdesign. Nun wird das Grobgranulare aufgeteilt in Projektschritte, und ab diesem Augenblick werden agile Methoden eingesetzt und sowohl Analyse, Design, Implementierung, Test als auch Alpha-Betrieb parallel gefahren. Regelmäßige Dailys 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 im Rahmen 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 findet 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 auf das gesamte, noch folgende 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.

Über die Autoren:

Reiner Marquart ist Senior Consultant und Spezialist für Softwareentwicklung bei der Unternehmensberatung Dr. Kraus & Partner, Bruchsal, die Unternehmen u.a. beim Einführen eines agilen bzw. hybriden Projektmanagement unterstützt sowie Agile Coaches und Transformation Consultants ausbildet.

Alexander Pifczyk ist Senior Consultant und Partner bei Dr. Kraus und Partner mit dem Arbeitsschwerpunkt Change- und Projekt- Management.