Was bedeutet hybrides Projektmanagement?
Klassisches Projektmanagement plant Umfang, Termine und Kosten früh und steuert gegen diesen Plan. Agiles Projektmanagement legt Ziele und Rahmen fest, plant die Umsetzung aber in kurzen Zyklen und passt den Umfang laufend an neue Erkenntnisse an. Hybrides Projektmanagement verbindet beides: Es nutzt die Verbindlichkeit klassischer Planung dort, wo sie gebraucht wird, und die Flexibilität agiler Arbeit dort, wo Anforderungen unsicher sind oder sich schnell ändern.
In der Praxis ist hybrides Arbeiten längst Normalfall. Auftraggeber brauchen Budgets, Termine und Entscheidungspunkte; Teams wollen und müssen flexibel auf neue Erkenntnisse reagieren. Die Norm ISO 21502 trägt dem Rechnung und nennt ausdrücklich prädiktive, inkrementelle, iterative, adaptive und hybride Vorgehen einschliesslich agiler Ansätze als mögliche Liefermodelle [1]. Auch die achte Auflage des PMBOK Guide ist ausdrücklich für unterschiedliche Vorgehen ausgelegt und hat die früheren Prozessgruppen als flexible Fokusbereiche zurückgebracht [2].
Welche Muster hybriden Arbeitens gibt es?
| Muster | Aufbau | Geeignet für | Risiko |
|---|---|---|---|
| Klassischer Rahmen, agile Umsetzung | Auftrag, Meilensteine, Freigaben und Abschluss klassisch; Umsetzung in Sprints | Software, digitale Produkte, Organisationsprojekte | Rahmen und Backlog laufen auseinander |
| Phasenweise gemischt | Konzept klassisch, Realisierung agil, Einführung klassisch | Projekte mit klaren Vorgaben am Anfang und Ende | Übergänge zwischen den Phasen |
| Teilprojekte unterschiedlich | z. B. Hardware oder Bau klassisch, Software agil, gemeinsame Meilensteine | Vorhaben mit physischen und digitalen Anteilen | Abhängigkeiten zwischen Teilprojekten |
Das erste Muster ist am verbreitetsten und entspricht dem Vorgehen von HERMES agil. Das zweite findet sich oft in öffentlichen Projekten, in denen Konzept und Einführung formalen Vorgaben folgen. Das dritte ist typisch für Vorhaben, bei denen ein Teil der Arbeit physisch ist, etwa ein Umbau mit digitaler Steuerung. In allen Fällen ist die Schnittstelle zwischen den Welten der kritische Punkt.
Wie kombiniert HERMES klassisch und agil?
HERMES unterscheidet seit der Ausgabe 2022 ein klassisches und ein agiles Vorgehen. Initialisierung und Abschluss sind beiden gemeinsam und werden aus Projektmanagementsicht immer klassisch abgewickelt. Dazwischen liegt die Lösungsentwicklung: klassisch mit den Phasen Konzept, Realisierung und Einführung, agil mit der einzigen Phase Umsetzung [4]. Der agile Leitfaden beschreibt, wie Releases, Sprints und die HERMES-Steuerung zusammenspielen [3].
Für die Praxis bedeutet das: Auftraggeber und Steuerung arbeiten mit vertrauten Elementen wie Projektauftrag, Phasenfreigaben, Statusberichten und Projektschlussbeurteilung, während das Team innerhalb der Umsetzung agil plant und liefert. Wer ein HERMES-Projekt agil umsetzt, findet die Details im Beitrag HERMES agil.
Wie gestalten Sie die Schnittstelle zwischen Rahmen und Team?
| Element | Klassisch festgelegt | Agil gesteuert |
|---|---|---|
| Ziele und Nutzen | im Projektauftrag, vom Auftraggeber freigegeben | Konkretisierung in Release- und Sprintzielen |
| Budget und Endtermin | Rahmen im Auftrag, Änderungen über Auftraggeber | Kapazität pro Sprint innerhalb des Rahmens |
| Umfang | Grobumfang, Nicht-Ziele, Muss-Anforderungen | Detailumfang im priorisierten Backlog |
| Meilensteine | wenige, verbindliche Termine, etwa Releases | Inhalt der Releases ergibt sich aus der Priorisierung |
| Berichte | Statusbericht an Auftraggeber in festem Rhythmus | Sprint Review, Burn-up, Velocity |
| Änderungen | an Zielen, Budget, Termin: formaler Entscheid | an Details: Backlog-Priorisierung |
Diese Aufteilung sollte im Projekthandbuch stehen, damit alle wissen, welche Entscheide wo fallen, siehe Projekthandbuch erstellen. Besonders wichtig ist die Regel für Änderungen: Neue Wünsche, die den Rahmen nicht verletzen, landen im Backlog und werden priorisiert. Wünsche, die Ziele, Budget oder Endtermin berühren, laufen über den formalen Prozess, siehe Scope-Management und Änderungskontrolle.
Wie werden Rollen in hybriden Projekten besetzt?
Hybride Projekte brauchen Rollen aus beiden Welten, und deren Zusammenspiel muss geklärt sein. Typisch ist eine Projektleitung, die den Rahmen verantwortet, gegenüber dem Auftraggeber berichtet und Abhängigkeiten steuert, und eine Produktverantwortung, die das Backlog priorisiert und mit dem Fachbereich die Anforderungen klärt. Im Team kann eine Person die agilen Abläufe moderieren. Konflikte entstehen, wenn Projektleitung und Produktverantwortung dieselben Entscheide für sich beanspruchen.
- Auftraggeber: verantwortet Ziele, Budget und Freigaben, nimmt an ausgewählten Reviews teil.
- Projektleitung: steuert Rahmen, Termine, Budget, Risiken und externe Abhängigkeiten.
- Produktverantwortung: priorisiert das Backlog, vertritt den Fachbereich, nimmt Ergebnisse ab.
- Team: plant und liefert in Zyklen, schätzt Aufwände, verbessert seine Arbeitsweise.
- Moderation agiler Abläufe: unterstützt Team und Produktverantwortung, beseitigt Hindernisse.
Eine RACI-Matrix hilft, die Abgrenzung festzuhalten, etwa: Die Produktverantwortung entscheidet über die Reihenfolge im Backlog, die Projektleitung über die Einhaltung des Budgetrahmens, der Auftraggeber über Änderungen am Rahmen. Mehr zur Rollenklärung im Beitrag Projektorganisation.
Wie wird in hybriden Projekten geplant?
Geplant wird auf zwei Ebenen. Die Rahmenplanung legt Ziele, Budget, Releases und Meilensteine fest und wird klassisch geführt, mit einem Grobplan über die gesamte Laufzeit. Die Umsetzungsplanung erfolgt in kurzen Zyklen: Das Team plant am Anfang jedes Sprints, was es liefern kann, gestützt auf das priorisierte Backlog und seine beobachtete Kapazität. Damit beide Ebenen zusammenpassen, wird der Grobumfang zu Projektbeginn geschätzt, etwa in Epics oder Features, und die Schätzung im Verlauf anhand der tatsächlichen Geschwindigkeit des Teams nachgeführt.
Ein praktisches Instrument ist das Burn-up-Diagramm: Es zeigt den gesamten geplanten Umfang und den erledigten Umfang über die Zeit. Wächst der Umfang schneller als die erledigte Arbeit, ist der Endtermin gefährdet, und der Auftraggeber muss über Umfang oder Termin entscheiden. So verbindet ein einziges Diagramm die agile Arbeit mit der klassischen Steuerung. Wie Aufwände in beiden Welten geschätzt werden, beschreibt der Beitrag Aufwandsschätzung.
Beispiel: Kundenportal für ein Dienstleistungsunternehmen
Ein Dienstleistungsunternehmen lässt ein Kundenportal entwickeln. Der Projektauftrag legt das Ziel fest, ein Portal, über das Kundinnen und Kunden Aufträge einsehen und Dokumente herunterladen, ein Budget und einen Endtermin in neun Monaten. Muss-Anforderungen sind Anmeldung mit Zwei-Faktor-Authentifizierung, Auftragsübersicht und Dokumentenablage; als Nicht-Ziel gilt eine Bezahlfunktion. Drei Releases sind als Meilensteine geplant: interne Vorabversion, Pilot mit zehn Kunden, allgemeine Einführung.
Die Umsetzung erfolgt in Sprints von zwei Wochen. Die Produktverantwortung aus dem Kundendienst priorisiert das Backlog, die Projektleitung berichtet alle vier Wochen an den Auftraggeber mit Ampel, Burn-up und Budgetverbrauch. Nach dem Pilot zeigt sich, dass Kunden eine Benachrichtigung bei neuen Dokumenten wünschen. Da sie den Rahmen nicht verletzt, kommt sie ins Backlog und verdrängt eine weniger wichtige Auswertungsfunktion. Ein Wunsch nach einer Bezahlfunktion dagegen berührt ein Nicht-Ziel und geht als Änderungsantrag an den Auftraggeber, der sie in ein Folgeprojekt verschiebt.
Typische Fehler im hybriden Projektmanagement
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Hybrid als Ausrede für fehlende Regeln | jeder arbeitet nach eigener Vorstellung | Schnittstelle im Projekthandbuch festhalten |
| Detailplanung über die ganze Laufzeit trotz agiler Umsetzung | doppelte Planung, ständige Anpassungen | Rahmen grob, Umsetzung in Zyklen planen |
| Agile Teams ohne verbindlichen Rahmen | Budget und Termin geraten aus dem Blick | Burn-up, Budgetverbrauch und Releases sichtbar machen |
| Unklare Rollen zwischen Projektleitung und Produktverantwortung | Konflikte, doppelte Entscheide | Entscheidungsbereiche in RACI festlegen |
| Auftraggeber nur bei Freigaben beteiligt | Überraschungen bei Reviews | Auftraggeber zu ausgewählten Sprint Reviews einladen |
Welche Werkzeuge unterstützen hybrides Arbeiten?
Hybrides Arbeiten braucht ein Werkzeug, das beide Welten abbildet: Phasen, Meilensteine und Budget für den Rahmen, Backlog, Sprints und Boards für das Team, und Berichte, die beides zusammenführen. Werden zwei getrennte Werkzeuge genutzt, etwa ein Gantt-Werkzeug für die Steuerung und ein Board für das Team, entsteht doppelte Pflege und die Gefahr widersprüchlicher Daten. In Flenio lassen sich Projekte mit Phasen und Meilensteinen führen und Aufgaben gleichzeitig auf Boards in Zyklen planen; Zeiten und Budget laufen in denselben Projektdaten zusammen. Für die agile Seite bieten die Seiten zu Scrum und Kanban weitere Grundlagen.
Ein bewährter Einstieg für Teams, die bisher klassisch gearbeitet haben: Beginnen Sie mit einem klar abgegrenzten Teil des Projekts, etwa einem Release, agil zu arbeiten, während Rahmen und Berichte wie gewohnt bleiben. Nach zwei bis drei Zyklen wird gemeinsam ausgewertet, was funktioniert, und die Schnittstelle bei Bedarf angepasst. So wächst das hybride Vorgehen aus der eigenen Erfahrung statt aus einer theoretischen Vorgabe.
Hybrides Vorgehen in HERMES, PMBOK und ISO 21502
Alle drei Referenzen erkennen hybride Vorgehen ausdrücklich an. HERMES mit einem agilen Vorgehen, in dem Initialisierung und Abschluss klassisch bleiben, der PMBOK Guide mit Fokusbereichen und Tailoring für unterschiedliche Vorgehen, die ISO 21502 mit der ausdrücklichen Nennung hybrider Liefermodelle. Einen Vergleich der Ansätze bietet etwa die ZHAW [5]. Entscheidend ist in allen Fällen nicht das Etikett, sondern eine bewusste, dokumentierte Entscheidung, welches Element wie geführt wird. Den Gesamtzusammenhang zeigt der Leitfaden Projektplanung Schritt für Schritt.