Projektmanagement

Hybrides Projektmanagement - das Beste aus zwei Welten

| Autor / Redakteur: Reiner Marquart, Alexander Pifczyk / Monika Zwettler

Klassisches Wasserfall- oder agiles Projektmanagement? Diese Frage hat sich zu einer Glaubensfrage entwickelt. Dabei haben beide Ansätze Vor- und Nachteile.
Klassisches Wasserfall- oder agiles Projektmanagement? Diese Frage hat sich zu einer Glaubensfrage entwickelt. Dabei haben beide Ansätze Vor- und Nachteile. (Bild: gemeinfrei / CC0)

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. Wie das Beste aus beiden Welten kombiniert werden kann.

Wenn es um die Frage geht: Auf welche Methoden setzen wir beim Projektmanagement – auf agile Methoden oder die (klassischen) Wasserfall-Methoden? stehen sich die Anhänger der beiden Vorgehensweisen oft unversöhnlich gegenüber, weil es für beide Pro- und Contra-Argumente gibt.

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.

SEMINARTIPP Im Seminar „Agile Führung“ lernen die Teilnehmer in interaktiven Übungen, Workshops, Impulsvorträgen und Diskussionen mit erfahrenen Kollegen agile Werte, Arbeitsweisen und Methoden in der Anwendung kennen.
Weitere Informationen

Studie: etwa die Hälfte aller Projekte scheitert

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 zum Beispiel bei der Softwareentwicklung sind:

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

Projektphase 1: Lasten- und Pflichtenheft erstellen

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 kleine Teilaufgaben gegliedert und alle Aufgaben bezüglich des Zeit- und Ergebnisverlaufs miteinander verbunden.

Vom Lösungskonzept zum Endprodukt

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 in der Regel durch die Entwickler selbst.

Tipp: Anwendertreff Maschinenkonstruktion Verfügbarkeit und Produktivität, Flexibilität, Adaptivität – diese Ziele erreichen Konstrukteure und Entwickler bis heute mithilfe klassischer Technologien und Methoden. Doch angesichts zunehmender Digitalisierung und Vernetzung von Maschinen und Anlagen stellt sich die Frage: Wo bieten sich neue Maschinenkonzepte an, wo spielen bewährte Technologien ihre Stärken auch in Zukunft aus? Der Anwendertreff Maschinenkonstruktion will diese Fragen klären und konkrete Lösungsansätze aufzeigen.
Anmeldung: Anwendertreff Maschinenkonstruktion

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.

Projektrisiken kosten- und terminseitig minimieren

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 einen überschaubaren Zeitraum dauern. 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. in der Pharmaindustrie oder Medizintechnik.
Software-Entwicklung und Fahrzeugtechnik: Sprints treffen auf Integrationsstufen

Agile Methoden

Software-Entwicklung und Fahrzeugtechnik: Sprints treffen auf Integrationsstufen

21.03.19 - Wie funktioniert die Kommunikation zwischen einem Konstrukteur und einem Softwareentwickler? Für das Internet der Dinge verschmelzen oft deren Welten. So treffen Abteilungen aufeinander, die vorher nur wenig Schnittstellen hatten. Dennoch sind sie innovativ. lesen

Risiken der Wasserfallmethode

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 – 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 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. Dieses 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.

SEMINARTIPP Das Seminar „TRIZ Training Level 1: Systematisch Ideen finden und Probleme lösen“ der konstruktionspraxis-Akademie versetzt Konstrukteure und Ingenieure in die Lage, durch Anwendung der TRIZ-Tools ihre Probleme in Konstruktion und Entwicklung schneller und effizienter zu lösen und zu mehr und besseren neuen Ideen zu kommen.
Info & Anmeldung: www.b2bseminare.de/konstruktion/triz-training-level-1

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 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-Storys werden parallel zur Entwicklung in einem fortlaufenden Prozess definiert.

Transparenz und Kommunikation im Entwicklerteam

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.

Agiles Vorgehen ist keine Erfolgsgarantie

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. Die wesentliche Schwachstelle bei Scrum-Projekten ist die Abschätzung der Storys 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.

Erfolgsfaktor: Reife und Homogenität des Entwicklungsteams

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.

Parallelwelten im Projektmanagement

Deshalb existieren 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 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ü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 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.

Sichtbare Zwischenergebnisse für Kunden und Anwender

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.

Wann eignet sich welches Projektmanagement?

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 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.

Der klassische Wasserfall als Sprint

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.

Review und Retrospektive ersetzt Statusmeeting

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.

Offenheit und Unvoreingenommenheit als Grundlage

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.

* Reiner Marquart ist Senior Consultant und Spezialist für Softwareentwicklung bei der Unternehmensberatung Dr. Kraus & Partner, Bruchsal (www.kraus-und-partner.de); Alexander Pifczyk ist Senior Consultant und Partner bei Dr. Kraus und Partner mit dem Arbeitsschwerpunkt Change- und Projekt- Management.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45855993 / Entwurf)