Agil oder klassisch – welches Vorgehen passt für welches Projekt am besten? Sollten Sie sich diese Frage stellen und die Vor- / Nachteile der beiden Projektmanagement-Methoden abwägen, dann ist dieser Artikel interessant für Sie. Im Zweifelsfall empfehlen wir: nutzen Sie hybrides Projektmanagement als Kombination beider Methoden!
Hier lernen Sie, wann und wie Sie den hybriden Ansatz am besten nutzen. Ein hybrides Projektmanagement-Beispiel zeigt zudem die Anwendung in der Praxis.
Folgende Kapitel warten auf Sie:
- Hybrides Projektmanagement Definition
- Vorteile hybrides Projektmanagement
- Rollen und Prozesse im klassischen Projektlebenszyklus
- Methoden im agilen Projektmanagement
- Unterschiede zwischen agilen und klassischen Methoden (Tabelle)
- Gemeinsamkeiten zwischen agilen und klassischen Methoden
- Hybride Vorgehensmodelle im Projektmanagement
- Multiprojektmanagement – agil, klassisch oder hybrid?
- Hybrides Projektmanagement Beispiele
- Tipps zur Einführung von hybridem Projektmanagement (Checkliste)
- Zusammenfassung und Empfehlung
Legen wir los mit einer kurzen Definition von hybridem Projektmanagement.
Hybrides Projektmanagement Definition
„Hybrid“ bedeutet eine Kombination oder Vermischung. Demnach ist hybrides Projektmanagement die Kombination von PM-Methoden. Dabei kommen sowohl die exakten Planungsansätze aus der klassischen PM-Welt als auch die flexiblen Reaktionsmöglichkeiten aus der agilen Welt nach Bedarf zum Einsatz. So lässt sich ggf. der Projektnutzen erhöhen, ein besseres Ergebnis erzielen und mit geringen Kosten schneller das Ziel erreichen.
Seit Jahren spielt Software in immer mehr Hardware-Produkten eine zunehmend wichtige Rolle. Agile Methoden mit ihrem iterativen Vorgehen und der flexiblen Zielgestaltung von Sprint zu Sprint sind auf dem Vormarsch. Und das lässt sich mit den klassischen Methoden verbinden.
Ein solches hybrides Vorgehen, also agile und klassische Vorgehensmodelle im Zusammenspiel, kann z.B. die Integration klassischer Methoden nach PMI mit agilen nach Scrum oder den Einsatz diverser Elemente unterschiedlicher Methoden bedeuten.
Vorteile hybrides Projektmanagement
Durch die Kombination von klassischen und agilen Bestandteilen können Sie die jeweils besten Aspekte aus beiden Welten nutzen. Daraus ergibt sich die Chance für die folgenden Vorteile von hybridem Projektmanagement Sie können ggf.
- den Projektnutzen erhöhen,
- ein besseres Ergebnis erzielen und
- Ihr Projektziel schneller bzw. mit geringen Kosten erreichen.
Hinweis: Die Studie „The Drivers of Agility“ des PMI kommt zu dem Ergebnis, dass Unternehmen mit einer hohen Agilität deutlich mehr Projekte erfolgreich abschließen als andere. Auf die genutzte Projektmanagement-Methode bezogen sind das bei den Unternehmen mit hoher Agilität 68% mit Agile, 71% mit Predictive und 72% mit Hybrid. Bei Unternehmen mit einer niedrigen Agilität sind es nur 41% mit Agile, 45% mit Predictive und 51% mit Hybrid.
Jetzt vergleichen wir zuerst die klassische Vorgehensweise im Projektmanagement mit den agilen Ansätzen.
Download (PDF): Hybrid – Wie Sie agile und klassische PM-Methoden verbinden
Laden Sie sich dieses PDF mit vielen praktischen Tipps zum Um- und Einsetzen von hybridem Projektmanagement jetzt kostenlos herunter.
* Pflichtfeld | Datenschutzhinweise
Rollen und Prozesse im klassischen Projektlebenszyklus
Im klassischen Projektmanagement liefern Ihnen das Konzept und die darauf basierende Spezifikation die Basis für die Umsetzung. Erst am Ende geht es um die Abnahme und die Nutzung des erstellten Gesamtergebnisses. Die beteiligten Rollen sind:
- Projektsponsoren
- ein:e Projektleiter:in
- diverse Teamleiter:innen
- deren Mitarbeitende
- ein Project Management Office (PMO)
Der klassische Prozess im Projektmanagement kann etwa so aussehen:
- Die Projektsponsoren definieren das Vorhaben und die zu erreichenden Ziele.
- Im Prozess des Projektportfoliomanagement wird das neue Projekt priorisiert.
- Die Teamleitenden der Projektbeteiligten müssen zuvor für eine valide Kapazitätsplanung auf Portfolioebene die Voraussetzung schaffen, damit die Ressourcenzuordnung fundiert erfolgen kann. Dabei werden die Teammitglieder für jedes Projekt immer wieder neu zusammengestellt.
- Die Detailplanung erfolgt in Gantt-Charts und mit Meilensteintrendanalysen.
- Bei Verschiebungen und inhaltlichen Änderungen steht der geplante Endtermin mit dem vorgegebenen Ziel. Teammitglieder werden ggf. aus anderen Projekten abgezogen.
- Im regelmäßigen Projektportfoliomeeting wird mittels Projektstatusbericht für ausgewählte Projekte dargestellt, wie weit die bestellten Lieferungen schon fortgeschritten sind.
- Am Ende steht die Abnahme, in der das gelieferte Ergebnis mit der Beauftragung verglichen wird. Je nach Umstand werden Mängel aufgenommen und entsprechend nachgearbeitet.
- In der Abschlusssitzung werden die Lessons Learned für kommende Vorhaben dieser Art festgehalten.
Vielleicht fragen Sie sich jetzt, was daran besser gemacht werden könnte? Ziele zu erreichen und geeignete Ressourcen dafür einzuteilen, ist doch erforderlich?
Ja, aber das geht nur, wenn die Ziele so klar sind und auch genauso erreicht werden müssen. Nur dann ist das klassische Vorgehen im Projektmanagement genau richtig.
Lesetipp: Projektmanagement-Methoden im Vergleich – klassisch, agil oder hybrid?
Agile Projektmanagement-Methoden
Agile Methoden hingegen sind dann passend, wenn Sie:
- Ergebnisse liefern müssen, die auf verschiedenen Wegen erreicht werden können,
- im Laufe der Zeit neue Erkenntnisse und Technologien verfügbar werden, die im Sinne einer besseren Lösung auch einfließen sollen, oder
- es gar nicht möglich ist, ein so genaues Bild der geforderten Lieferung vorab zu spezifizieren, weil die Beteiligten dies nicht können.
Vor allem bei der Software-Produktentwicklung ist das Vorgehen heute meist agil. Immer mehr kommt dieser Ansatz aber auch in anderen hochtechnologischen und komplexen Umgebungen zum Einsatz.
Die Rollen im agilen Projektmanagement (wie etwa bei Scrum) sind die folgenden:
- Product Owner: entscheidet alles zum Produkt, priorisiert und pflegt das Backlog und ist permanent erreichbar
- Scrum Master: managt den Prozess, räumt Hindernisse aus dem Weg
Lesetipp: Was ist ein Product Owner und was macht er in agilen Teams?
Wichtigste Merkmale des agilen Projektmanagements sind:
-
- Kick-off-Meetings gibt es in agilen Umgebungen nicht mehr zwingend.
- Agile Teams sind so weit wie möglich selbstorganisiert oder auch selbstverwaltend.
- Die Teams schätzen aus ihrer eigenen Erfahrung heraus Aufwände ab (zu Beginn grob, feiner im Projektverlauf).
- Die Fortentwicklung läuft oft parallel zum Einsatz des bisherigen Produkts durch die User.
- Das Entwicklungsteam bespricht täglich den Fortschritt im Hinblick auf das Sprint-Ziel.
- Regelmäßige Sprint-Planungen, Reviews und Retrospektiven sind Pflicht.
- Vorgaben gibt es nur im Product Backlog bzw. Sprint Backlog als Untermenge davon für jeden Sprint. Wenn etwas nicht im Backlog zu finden ist, wird es auch nicht behandelt.
- Zur Kommunikation mit den Stakeholdern über die Reviews hinaus gibt es öffentliche Boards mit Backlog und Sprint- oder Produkt-Burndown-Charts. Berichte über Termine, Kosten und Status im klassischen Sinne sind deshalb bestenfalls überflüssig.
- Feste Produkt- und Projektteams sowie die feste Taktung vereinfachen die allgemeine Planung und den Mitarbeiterwechsel zwischen Projekten erheblich.
Lesetipp: Agiles Projektmanagement – Grundlagen und Methoden für Einsteiger
Unterschiede zwischen agilen und klassischen Methoden
Die wichtigsten Unterschiede zwischen klassischem und agilem Projektmanagement lassen sich tabellarisch grob zusammenfassen wie folgt:
| Klassisches Projektmanagement | Agiles Projektmanagement |
|---|---|
| Team: Meist temporär (Projektorganisation) | Team: Idealerweise fest und permanent (Produktorientierung) |
| Organisation: Aufgaben durch eine:n Projektmanager:in verteilt | Organisation: Selbstverwaltung der Arbeit und flache Hierarchien |
| Rollen: Klassische Teams haben eine:n Projektleiter:in und ein Projektteam. Dedizierte Projektteamrollen, oft parallel zu anderen, funktionalen Rollen (Matrix-Organisationen) |
Rollen: Product Owner, Entwickler:innen, Coach (Scrum, XP) oder Beibehaltung der klassischen Rollen, aber mit mehr funktionsübergreifenden und selbstorganisierten Teams (Kanban) |
| Planung: So viel wie möglich auch längerfristig, detailliert, häufig mit wenig Stakeholder-Kontakt zwischendurch. Mischform: Bei der „Rollierenden Planung“ werden bewusst Details zu einem gewissen Grad offengelassen. |
Planung: Langfristig grob und kurzfristig detaillierter („Just-in-Time-Planung“). Teams gehen Schritt für Schritt und im engen Austausch mit Stakeholdern vor. |
| Methoden: Projektplan, inhaltlicher Projektstrukturplan, Earned Value Management,… | Methoden: Produktvision, Product Backlog, Burndown Charts,… |
| Prozesse: Fest vorgegebene zur Änderungssteuerung. | Prozesse: Vereinfachter Umgang mit häufigen Veränderungen, da von Anfang an erwartet. |
| Anforderungsdokumentation: Ausführlich (z.B. Use Cases). | Anforderungsdokumentation: Schlank (Backlog). |
| Fix / Variabel: Inhalt als festes Ziel, Kosten und Zeit oft variabler. | Fix / Variabel: Kosten und Zeit als fixe Ziele, Inhalt deshalb variabler. |
| Projektteams: Größere, oft variable Projektteams mit hierarchischen Berichtsstrukturen. | Projektteams: Fokus auf kleinen Entwicklungsteams, die sich zusammen auf die Verwirklichung von Produktvisionen konzentrieren dürfen. |
| Im Vordergrund: Die Aufgabe, die zu Beginn dokumentierte Kundenanforderungen zu erfüllen und Pläne einzuhalten. | Im Vordergrund: Der Wert für den Kunden, aber auch für die eigene Organisation. Ziel ist, Verschwendung und Nacharbeit zu vermeiden. |
| Lerneffekte: Setzen bei Langfrist-Planung ohne Offenheit für Änderungen später ein und können nicht mehr richtig berücksichtigt werden. |
Lerneffekte: Schnell durch kürzere Horizonte der Detailplanung, Rhythmisierung der Arbeit und häufige Präsentation von Zwischenergebnissen. |
| Management: Klassisch Top-down. Projektmanager:in gibt Teammitgliedern Anweisungen, wie sie ihre Arbeit tun sollen, übernimmt dafür aber auch die Verantwortung. |
Management: Selbstorganisation und Bottom-up-Management (Steuerung der Arbeit aus dem Team heraus). Braucht besonders am Anfang Unterstützung von außen. Steigert die Motivation und Zusammenarbeit im Team. |
| Teammitglieder: Wenn noch mehr Anleitung nötig ist, sind sie in klassischen Teams manchmal besser aufgehoben. | Teammitglieder: Hohe Disziplin und Eigenverantwortung nötig, um in agilen Teams arbeiten zu können. |
| Messwerkzeuge und Methoden: Viele, die auch mit agilen Arbeitsweisen kombiniert werden können, wo sinnvoll. | Messwerkzeuge und Methoden: Versuch, möglichst „schlank“ zu arbeiten. Die Kenntnis vieler Ansätze hilft für passgenaues oder situatives Projektmanagement. |
| Ressourcenplanung: Dediziert pro Arbeitspaket und Phase | Ressourcenplanung: Iterations- oder Flow-basierte Kapazitätsplanung |
Gemeinsamkeiten zwischen agilen und klassischen Methoden
Die Gemeinsamkeiten zwischen agilen und klassischen Projektmanagement-Methoden sind folgende:
- Die Arbeit findet in Teams statt.
- Die Vorhaben, die sie umsetzen, sind einzigartig (im Gegensatz zu wiederkehrenden Abläufen, etwa im betrieblichen Tagesgeschäft eines Unternehmens).
- Es gibt Stakeholder mit Anforderungen und Wünschen, die es zu verstehen und erfüllen gilt.
- Vorhandene Ressourcen werden effektiv und effizient eingesetzt, um maximalen Nutzen aus dem Vorhaben zu gewinnen.
- Methodenkenntnis und -vielfalt aus diversen Bereichen können helfen, fallbasierte Lösungen für Probleme zu finden.
Seminartipp: Besuchen Sie unser Seminar Hybrides Projektmanagement und kommen Sie sicher vom klassischen ins teilweise agile Projekt- & Portfoliomanagement.
Hybride Vorgehensmodelle im Projektmanagement
Jetzt kennen Sie die wichtigsten Unterschiede und Gemeinsamkeiten zwischen klassischem um agilem Projektmanagement. Wie können Sie diese unterschiedlichen Welten nun für hybrides Projektmanagement verbinden?
Es gibt mehrere hybride Vorgehensmodelle, die Sie anwenden können.
1. Paralleler Einsatz von klassischen und agilen Methoden
Das hybride Vorgehensmodell des parallelen Einsatzes der Methodenmischung in einzelnen Bereichen des Unternehmens zeichnet sich wie folgt aus:
- Manche Bereiche eines Unternehmens arbeiten immer klassisch (z.B. das Consulting), andere immer agil (z.B. die Softwareentwicklung)
- Einige Projekte laufen klassisch ab, andere agil
- Einzelne Teile eines Projekts werden klassisch durchgeführt, andere Teile agil
- Die Grobplanung in Projekten findet klassisch statt und die Detailplanung dann agil
Unser Tipp: Dass manche Bereiche eines Unternehmens klassisch und andere agil arbeiten, ist eine der häufigsten und reibungslosesten Umsetzungen von hybridem Projektmanagement. Hier haben Sie normalerweise eine hohe Prozessstabilität.
2. Vermischter Einsatz von klassischen und agilen Methoden
Die hybriden Vorgehensmodelle des vermischten Einsatzes der Methoden in demselben Projekt können, je nach Schwerpunkt – vorrangig klassisch oder vorrangig agil, wie folgt aussehen:
- Klassische Projekte:
- Engere Abstimmung mit Nutzer:innen und häufigere, nutzbare Zwischenergebnisse
- Regelmäßige Stand-up-Meetings zum Fortschritt (muss nicht täglich sein – einmal pro Woche ist schon ein guter Anfang)
- Planung in Phasen und Meilensteinen übergeordnet zu Sprints
- Retrospektiven (Lessons Learned) nach jedem Statusbericht-Meeting, nicht erst am Projektende
- Fixes Team für die gesamte Laufzeit des Projekts
- Backlog pro Phase als Spezifikation
- Projektplanung synchron mit Sprint-Längen
- Agile Projekte:
- Scrum Master sind gleichzeitig auch Projektleitende im klassischeren Sinne
- Ein Backlog wird für jede Projektphase angelegt, statt als Spezifikation fürs Gesamtprodukt
- Die Projektplanung wird mit den Sprint-Längen synchronisiert
- Planen in Phasen und Meilensteinen – den Sprints übergeordnet und ergänzend dazu
- Es gibt weiterhin Statusberichte und Meilensteintrend-Analysen fürs Management und die übrigen relevanten Stakeholder
(Die beiden letzten Beispiele werden übrigens von vielen Experten der agilen Welt nicht so gerne gesehen, da sie die agilen Grundprinzipien verwässern können.)
Wie könnte das in einzelnen Projekten genauer aussehen? Zum Beispiel könnten in einem hybriden Projekt die folgenden Dokumente und Methoden zum Einsatz kommen:
Die Zutaten für ein “hybrides Rahmenwerk” in einem konkreten Projekt lassen sich z.B. anhand des folgenden Spektrums auswählen:
Mögliche Risiken und Abstriche der Zutaten des „hybriden Rahmenwerks“ sind:
- Arbeitsrhythmen: zu lang: Bezug zur Realität verlieren,
zu kurz: ins Chaos verfallen - Arbeitsmanagement-Tool: zu schwergewichtig: schwer zu handhaben,
zu leicht: unklare Planung - Langfristige Planung und Terminierung: zu detailliert: schwer zu integrierende Änderung,
zu wenige Details: unklare Richtung und Ziele - Schätzung: absolute Einheiten: möglicher negativer psychologischer Effekt,
relative Größe: Bewusstsein muss vorhanden sein - Prozessverbesserung: Lessons Learned am Projektende: zu spät für aktuelles Projekt,
Iterationsretrospektiven: benötigen gute Moderation - Fortschrittsüberwachung und Statusreporting: Earned Value Management: benötigt verlässliche Daten, Expertise und die richtigen Tools,
agile Metriken und Visualisierungen: keine integrierte Sicht auf Umfang / Zeitplan / Kosten - Auftragsvergabe und Beschaffung: Festpreisverträge: Umfangsänderungen erschwert,
iterative Vertragsmodelle: kann schwer zu verhandeln sein - Einbindung und Feedback von Stakeholdern: geringe Häufigkeit von Feedback: harte Niederlage gegenüber Stakeholdern,
hohes Stakeholder-Engagement: schwer zu gewinnen - Risikomanagement: dedizierte Risikoanalyse: zeitaufwendig, basierend auf Annahmen,
Risikoentdeckung durch iteratives Arbeiten: große Risiken können zu spät erkannt werden - Anforderungen: im Vorfeld definiert: kann sich als falsch oder missverstanden erweisen,
dynamisch entdeckt und just-in-time im Detail verfeinern: erfordert Team- und Stakeholder-Flexibilität - Kapazitätsplanung: dedizierte Ressourcenplanung: benötigt solide Ressourcenmanagement-Methoden,
iterationsbasierte Kapazitätsplanung: arbeitet nur mit einem festen Team und kann zu kurzfristig sein, um Kapazitätsprobleme vorherzusehen - Teamrollen: dedizierte Projektteamrollen: kann zu viel administrativer Aufwand und Kontrolle sein, erfordert klare Verantwortlichkeiten,
3 agile Kernteamrollen (Kundenvertreter, Entwickler, Coach – Scrum, XP): passt möglicherweise nicht in den organisatorischen Kontext
Methodenkombination und -wechsel im Projekt
Häufiges Wechseln zwischen klassischen und agilen Ansätzen von Projekt zu Projekt kann in wackeliger Prozessstabilität enden. Eine weitere Möglichkeit ist es deshalb, in Projekten nicht zwischen Methoden hin- und herzuwechseln, sondern sie gleich sinnvoll zu kombinieren.
Das kann zum Beispiel so aussehen:
- Konzept, Spezifikation und Umsetzung mit Hardware klassisch
- Softwareentwicklung agil
- Abnahme klassisch
Oder:
- Konzept und Spezifikation agil
- Umsetzung und Abnahme klassisch
Oder:
- Alles bis zur Integration am Schluss klassisch
- Integration agil
Unser Tipp: Bei Durchmischung der Methoden innerhalb des gleichen Projekts hat es sich bewährt, unklare Teile des Projekts agil und klarere Teile klassisch zu planen. Bei häufigen Wechseln zwischen klassischen und agilen Ansätzen von Projekt zu Projekt besteht die Gefahr, dass die Prozessstabilität leiden kann.
Klassische Grobplanung und agile Detailplanung im Projekt
Bei hybriden Ansätzen im Projekt hat sich Folgendes bewährt:
- Planen Sie alles auf höherer Ebene grob klassisch als eine Art „Überbau“.
- Fügen Sie dann durch agile Arbeitsweisen iterative Elemente im Nachhinein hinzu.
Auf diese Weise lassen sich etwa Meilensteine und Statusmeetings weiterhin einplanen. Aber die Vorteile agiler Arbeitsweisen kommen dennoch zum Tragen.
Die Meetingfrequenz zu rhythmisieren, minimiert außerdem Reibungen und den allgemeinen Koordinationsaufwand – was am Ende zu mehr Produktivität führt.
Unser Tipp: Trennen Sie die Methoden klar nach Bereichen. Das bringt die höchste Prozesssicherheit. Als erster Schritt ist das meist ein guter Einstieg.
Multiprojektmanagement – agil, klassisch oder hybrid?
In Umgebungen für Multiprojektmanagement sind folgende Übersichten immer erforderlich:
- Status
- Notwendige Entscheidungen
- Liefertermine
Probleme beim Projektstatus müssen schnell und klar sichtbar werden (etwa durch eine rote Ampel).
Hier ist auch ein Unterschied: In typischen (Multi-)Projektlandschaften werden Sie klassische Methoden immer brauchen. Bei laufenden Produktentwicklungen von Version zu Version als „Kleinprojekte“ ist das aber anders. Letztere können Sie generell etwas problemloser agil strukturieren.
Und da es im agilen Umfeld keine Methoden für Multiprojektmanagement gibt, erübrigt sich jede weitere Frage.
Unser Tipp: Im Hybrides Projektmanagement Seminar von TPG bekommen Sie ein Grundgerüst an die Hand, mit dem Sie richtig in ein erfolgreiches hybrides Multi-Projektumfeld starten können. Besonders interessant ist dies für Mitarbeitende in PMOs.
Download (PDF): 8 Tipps für erfolgreiches Programmmanagement
Lesen Sie praktische Tipps, die Ihnen beim Aufbau und der Verbesserung Ihrer Multiprojekt-/Programmmanagement-Umgebung nützlich sein werden.
* Pflichtfeld | Datenschutzhinweise
Unser Tipp: Sind die Anforderungen auf Kundenseite unklar und unsicher formuliert und außerdem der Lösungsansatz im Projekt noch unklar und neu? Dann sind agile Methoden besonders gut für Sie geeignet. Für solche Situationen wurden sie entwickelt.
Hybrides Projektmanagement: Beispiele zur Umsetzung
Folgend geht es um zwei Beispiele im hybriden Projektmanagement.
Beispiel 1: Parallele Consulting- und Produktentwicklungsprojekte
In einem Unternehmen werden Kundenprojekte in Form von Consulting und Produktentwicklung (z.B. Softwareprodukte) parallel durchgeführt. Die Lösung mit hybridem Projektmanagement kann als Beispiel nun so aussehen:
- fremdbestimmte Beratungsprojekte für Kunden werden immer klassisch durchgeführt
- die selbstbestimmte Produktentwicklung läuft agil ab.
Unser Tipp: Beachten Sie bei einem solchen Umfeld aber, dass Kundenwünsche zwischen den Abteilungen abgestimmt werden müssen. Das heißt im Klartext, die Sales-Abteilung muss bei der Release Planung für die Produktentwicklung mitreden dürfen.
Beispiel 2: Softwareentwicklung im Automotive-Bereich mit >100 Teammitgliedern
Ausgangssituation und Problemstellung:
- Über 100 Projektteammitglieder
- Teammitglieder sowie Stakeholder aus verschiedenen europäischen Ländern
- Teammitglieder aus ~5 verschiedenen Unternehmen
- Komplett neues Produkt
- Viele Datenschnittstellen notwendig
- Moderne Architektur-Technologie gefordert
- Zukünftiger Einsatz an vielen Standorten notwendig
Einige Lösungsansätze waren:
- Projektvision: Als Powerpoint-Präsentation, abgelegt in Projektbereich auf Atlassian Confluence
- Teamaufstellung:
- Teams aufgeteilt in verschiedene Bereiche der zu entwickelnden Anwendung
- Jedes Team hat einen eigenen PO-Vertreter sowie zusätzlich einen Business Analyst und ca. 8 Developer, zusätzlich UX-Designer und Tester
- Projektrollen:
- Typische Scrum-Rollen vorhanden
- Übergeordnete Rollen zur Koordination von Themen wie Security, Architektur, Releaseplanung, agiles Arbeiten, Qualitätssicherung etc.
- Arbeitsrhythmus und Planung:
- Vorgehen der Teams in Sprints (miteinander synchronisiert), in denen sie aus einem gemeinsamen Product Backlog so unabhängig wie möglich arbeiten und sich bei Abhängigkeiten abstimmen, außerdem zusätzliche Meetings für die übergeordnete Planung
- Integration der Ergebnisse möglichst früh und regelmäßig
- Release- und Meilensteinpläne sowie pro Unterauftragnehmer definierte Arbeitspakete und Lastenhefte
- Abnahme und Betrieb:
- Abnahmeprozess für Unterauftragnehmer: Erfolgt über Sprint Reviews
- Abnahmeprozess mit Endnutzern: User Acceptance Tests dienen als „Gate“ vor betrieblicher Nutzung
- Teams kümmern sich nach erfolgreicher Abnahme weiter um die Software, aber mit einem etwas anderen Prozess (Arbeit muss in Sprints neben Neuentwicklung ebenfalls untergebracht werden)
- Statusberichterstattung: In Richtung Sponsoren: einmal monatlich Bericht über aktuelle Qualitätsthemen und bekannte Probleme sowie Ursachen, Status-Meetings mit ganzem Team
Tipps zur Einführung von hybridem Projektmanagement (Checkliste)
Die Einführung von hybridem Projektmanagement ist nicht nur ein methodischer Schritt, sondern auch ein kultureller und organisatorischer Veränderungsprozess. Neben der Auswahl geeigneter Tools und Prozesse ist es entscheidend, dass Sie alle Beteiligten durch aktives Change Management mitnehmen. So können Sie Widerstände minimieren, Akzeptanz schaffen und langfristig erfolgreichere Projekte realisieren.
Folgend die praxisorientierte Checkliste für die Einführung von hybridem Projektmanagement:
- Auslöser identifizieren:
- Management-Entscheidung dokumentieren
- Gründe für den Hybrid-Ansatz klar kommunizieren (z.B. mehr Flexibilität, höhere Erfolgsquote)
- Situation analysieren:
- Bestehende Prozesse, Methoden und Tools überprüfen
- Projektklassifikations-System neu aufsetzen oder anpassen
- Change-Initiierung vorbereiten:
- Verantwortliches Kernteam benennen
- Konkreten Umsetzungsplan mit Meilensteinen und Roadmap erstellen
- Umsetzung starten:
- Geeignete Dokumentationsstandards und Prozessvorlagen bereitstellen
- Passende Werkzeuge (z.B. Projektportfoliomanagement-Tool) einführen
- Schulungen durchführen & Go-Live begleiten:
- Teams in Methoden, Tools und neuen Abläufen schulen
- Erste Projekte unter neuer Arbeitsweise starten und eng begleiten
- Erfolg messen:
- Prüfen, ob eingeführte Tools wie geplant funktionieren
- Veränderungen bei Produktivität, Projekttransparenz und Ressourcenplanung messen
- In den Alltag integrieren:
- Tägliche Arbeitsabläufe kontinuierlich unterstützen und optimieren
- Regelmäßig nachsteuern, um langfristige Verbesserung sicherzustellen
Wichtig: Die Umstellung auf hybrides Projektmanagement ist kein Selbstläufer. Sie benötigen fortlaufende Betreuung, klare Kommunikation und das aktive Engagement aller Beteiligten, damit Sie damit dauerhaft erfolgreich sein werden.
Zusammenfassung und Empfehlung zu hybridem Projektmanagement
In diesem Artikel haben Sie eine Übersicht aller drei Projektmanagement-Methodenbereiche kennengelernt: klassisch, agil und hybrid. Sie wissen jetzt, wie hybrides Projektmanagement als Mischung von agilen und klassischen Ansätzen in der Praxis aussehen kann.
Sie haben gelernt, dass es von parallelen Einsätzen in verschiedenen Bereichen bis hin zu Mischungen der Ansätze innerhalb desselben Projekts viele Arten für hybrides Projektmanagement gibt. Zwei Beispiele für hybrides Projektmanagement haben Ihnen die praktische Umsetzung verdeutlicht.
Besonders geeignet erscheint uns vor allem die Einführung verschiedener geeigneter Methoden getrennt nach Organisationsbereichen (z.B. fremdbestimmte Kundenprojekte klassisch und selbstbestimmte Entwicklungsprojekte agil). Dabei ist die enge Einbindung aller relevanten Abteilungen (wie z.B. Sales) von Anfang an extrem wichtig.
Versuchen Sie bei der Einführung von Methoden Schritt für Schritt vorzugehen und einen guten Teamrhythmus fürs Projekt zu finden.
Außerdem gilt: Oft verlangen besondere Situationen oder Umgebungen nach speziellen Kombinationen von Methoden. Eine für jedes Projekt individuelle Lösung (wie in den obigen Beispielen) ist immer besser als ein einfach von außen übergestülpter Ansatz.
Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).
Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad Ihres Projektmanagements!
Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen zu hybridem Projektmanagement im Multiprojektumfeld stellen? Dann sind Sie genau richtig beim TPG Seminar Hybrides Projektmanagement für PMOs.
Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.
Immer informiert sein: TPG MonatsInfos abonnieren (praxisstarke Tipps)
Jetzt abonnieren und Sie verpassen keine neuen Experten-Tipps in Form von Blogartikeln, Webinaren, eBooks etc. Keine Kosten, kein Risiko, Abmeldung mit nur einem Klick.
* Pflichtfeld | Datenschutzhinweise
Über den AutorJohann Strasser
Nach mehrjähriger Erfahrung als Entwicklungsingenieur im Automotive- und Energiesektor arbeitete Johann Strasser für zehn Jahre als selbständiger Trainer und Berater im Bereich Projektmanagement. In dieser Zeit war er zudem als Projektleiter für Softwareprojekte in der Bauwirtschaft tätig und unterstützte Großbauten im Rahmen von Termin- und Kostenmanagement. Seit 2001 fließt seine Expertise bei TPG in die Produktentwicklung und in die Beratung internationaler Kunden ein. Besonderen Fokus legt er auf die Themen PMO, Projektportfolio, hybrides Projektmanagement und Ressourcenplanung. Sein Wissen gibt er seit vielen Jahren in Form von Vorträgen, Seminaren, Artikeln und Webinaren weiter.
Mehr über Johann Strasser auf Linkedin.
Über die Autorin:Antje Lehmann-Benz, PMP, PMI-ACP, PSM
Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.
Mehr über Antje Lehmann-Benz auf Linkedin.
3 Kommentare
Hinter hybriden Ansätzen im Projektmanagement steht meist der Wunsch, die Geschwindigkeit von Agilität mit der Sicherheit des traditionellen Projektmanagements zu bündeln: Scrum + Prince2 = Geschwindigkeit * niedriges Risiko. Dabei lassen wir das sich widersprechende Mindset der Ansätze außer acht. Aus diesem Grund werden die gewünschten Ergebnisse verfehlt.
Viele verschiedene Möglichkeiten zur Kombination agiler und klassischer Methoden wurden genannt. Die meisten davon erscheinen mir unproblematisch.
Eine Kombination jedoch könnte schwierig werden: ein klassischer Überbau, der aus der Umsetzungsphase ein bestimmtes Ergebnis erwartet (z.B. da zuvor eine genaue Spezifikation erstellt wurde). Die Umsetzung dann „agil“ zu gestalten, würde außer Acht lassen, dass ein agiles Vorgehen vom Feedback lebt und das zu entwickelnde Produkt daran anpasst. Natürlich könnte man einfach die Umsetzung in Iterationen strukturierten, aber ein emergentes, inkrementelles Produkt kann nicht der Output sein und geht somit an der Komplexität des Produktes vorbei.
Toller Artikel! Freue mich auf mehr!
Lieber Herr Bernasconi,
Damit haben Sie völlig recht. Sollte das Ergebnis wirklich genau spezifiziert sein, wird es schwierig mit dem Verhandlungsspielraum hinsichtlich des Scopes. Besser wäre es, hierzu ein gut definiertes Produktziel zu erarbeiten und das Produkt dann inhaltlich agil ausgestalten zu lassen.
Wir freuen uns, wenn Ihnen der Artikel gefallen hat, und vielen Dank für Ihren Kommentar!
Beste Grüße
Antje Lehmann-Benz