Hybrides ProjektmanagementWie hybride Projekte gelingen
Was ist hybrides Projektmanagement?
Hybrides Projektmanagement ist die Kombination von zwei oder mehr Systemen für das Management eines Projekts. Am häufigsten wird von Hybridem Projektmanagement gesprochen, wenn klassische und agile Methoden miteinander kombiniert werden.
Die Zusammenarbeit läuft dann meistens nicht reibungslos. Die Ursache für den „Sand im Getriebe“ sind häufig Unsicherheiten und ungeklärte Fragen, die aus den unterschiedlichen Arbeitsweisen der Teams entstehen. Viele Konflikte, die in hybriden Projekten auftreten, lassen sich mit einfachen Strategien lösen oder vermeiden.
Beispiel für ein hybrides Projekt
Das folgende, fiktive Projekt-Szenario beschreibt eine typische Situation im hybriden Projektalltag:
Es geht um ein Projekt für die Produktentwicklung eines Maschinenbauers mit rund 250 Mitarbeitern und einem Jahresumsatz von 50 Millionen Euro. Die zu produzierende Maschine besteht aus Hardware- und Softwarekomponenten. Die Engineering-Teams sind für die Hardware zuständig und arbeiten klassisch nach dem Wasserfall-Modell. Es gibt eine Projektleitung, einen Phasen- und Meilensteinplan und einen übergeordneten Gates-Prozess, der durchlaufen werden muss.
Das Software-Team hingegen arbeitet mit agilen Methoden und nutzt für seine Arbeit das Scrum-Framework. Bei den im dreiwöchigen Turnus angelegten Sprints muss am Ende kein potenziell auslieferbares Produkt entstanden sein, wie es eigentlich in Scrum vorgesehen ist.
Das liegt daran, dass die Softwareentwicklung in das übergeordnete Produktentwicklungsprojekt eingebunden ist und die Software nicht unabhängig vom Produkt releast werden soll und kann. Der Product Owner des Software-Teams ist gleichzeitig Head of Software Development im Unternehmen. Eine Besonderheit besteht darin, dass das Scrum-Team gleichzeitig für mehrere Projekte im Unternehmen arbeitet.
In diesem Szenario knirscht es an verschiedenen Stellen. Ursache für die Reibung sind verschiedene Herausforderungen, mit denen die Teams umgehen müssen und die nachfolgend unter die Lupe genommen werden.
Typische Probleme in hybriden Projekten
Stockender Informationsfluss
In diesem Projekt hapert es immer wieder an der Kommunikation. Oft ist nicht klar, wer für welche Themen der zuständige Ansprechpartner ist. Die klassisch arbeitenden Teilprojektleiter wünschen sich einen engen Austausch mit den Softwareentwicklern, da ihre Lieferergebnisse stark von einer funktionierenden Software abhängig sind.
Umgekehrt reagiert das Software-Team gereizt, wenn seine Kapazität von zu vielen Projektmeetings aufgezehrt wird. Sobald Informationen nicht proaktiv und transparent fließen, entsteht Misstrauen, primär hinsichtlich der Zuverlässigkeit des selbstorganisierten Software-Teams.
Unklare Zeitplanung
Die Projektleitung steht anfangs vor der Herausforderung, einen Meilenstein- und Zeitplan für das Gesamtprojekt aufzustellen, der auch die Zulieferungen des agilen Teilprojekts beinhaltet. Immer wenn die Projektleitung engmaschige Meilensteine vom agilen Software-Team einfordert, stößt sie damit auf Widerstände.
Ohne verbindliche Zusage von Lieferterminen können aber wiederum die klassisch arbeitenden Teilprojektleiter mit ihren Abhängigkeiten keine verlässlichen Aussagen zu ihrer Teilprojektplanung treffen. Fast alle sind auf die pünktliche Bereitstellung von Funktionalität angewiesen. Und auch die Geschäftsleitung fordert von der Projektleitung eine konsistente Gesamtprojektplanung ein.
Inkonsistentes Reporting
Eine weitere Herausforderung: Die Projektleitung möchte einheitliche Statusreports auf der Ebene der Teilprojekte zu einem konsistenten Gesamtreport zusammenführen, um diesen der Geschäftsleitung zu präsentieren.
Die typischen Indikatoren, die in einem klassischen Projektstatusreport auftauchen – Meilensteintrendanalyse oder die üblichen Statusampeln für Zeit, Budget und Qualität beispielsweise – sind in agilen Projekten so nicht vorgesehen. Der durchaus gute Fortschritt im agilen Teilprojekt bleibt den Empfängern der Reports so häufig unklar. Auch hierdurch entsteht bei wichtigen Stakeholdern eine misstrauische Haltung.
Tipps für erfolgreiches hybrides Projektmanagement
Damit hybrides Projektmanagement mit klassisch organisierten Projektteams und Scrum-Teams funktioniert, gibt es einige Stellhebel, mit denen die typischen Probleme vermieden oder gelöst werden können.
Product Owner als Schnittstelle des hybriden Projekts einbeziehen
Dem Product Owner kommt in hybriden Projekten eine zentrale Rolle zu. Als Teil des Scrum-Teams steuert er durch die Priorisierung der Einträge im Product-Backlog nach Business Value die Aufgaben des Teams und kann gegebenenfalls korrigierend eingreifen.
Damit die Zusammenarbeit mit den klassischen Projektteams funktioniert, übernimmt er außerdem folgende Aufgaben:
- Der Product Owner pflegt eine Roadmap, die die übergeordnete Projektplanung und die Abhängigkeiten berücksichtigt.
- Dafür muss er sich eng mit der Gesamtprojektleitung abstimmen.
- Als Ansprechpartner für alle Stakeholder ist er zudem in der Lage, Auskunft über den Fortschritt des agilen Teams zu geben.
- Er nimmt als Teilprojektleiter auch an den Regelmeetings des Projektes teil.
- Ebenso muss der Product Owner dafür sorgen, dass Teilprojektleiter, die in ihren Abläufen abhängig vom agilen Teilprojekt sind, als Stakeholder zu den Sprint-Reviews eingeladen werden.
Dem Product Owner kommt also eine Doppelrolle zu: Zusätzlich zu seiner Verantwortung für das Produkt in der Rolle des Product Owners im agilen Team ist er im Gesamtprojekt Teilprojektleiter des agilen Teilprojekts und damit Bindeglied in die klassische Projekt-Organisation. Die Projektleitung hingegen hat kaum Möglichkeiten, von außen steuernd in das agile Team einzugreifen, ohne dabei dessen Selbstorganisation zu beschädigen.
Frühzeitige Klärung von Rollen und Verantwortung der Projektleitung und des Product Owners entschärfen in dieser Konstellation das Konfliktpotenzial. Entscheidend für einen reibungslosen Ablauf und eine kompetente Projektsteuerung ist ausreichend Kapazität, die der Product Owner benötigt, um seiner Doppelrolle gerecht werden zu können.
Transparenz und der Bericht an die Stakeholder sind wichtig, um Misstrauen und Unsicherheiten hinsichtlich der Leistungsfähigkeit des agilen Teams zu verhindern. Wenn der Product Owner mit Unterstützung durch den Scrum-Master die Prozesse des agilen Teilprojekts gegenüber den Stakeholdern transparent macht und er den Fortschritt proaktiv in die Projektorganisation trägt, entsteht gegenseitiges Vertrauen.
Sprint-Reviews als Plattform für die Kommunikation nutzen
Definitionsgemäß ist das Sprint-Review das Meeting, bei dem das Scrum-Team und die Stakeholder gemeinsam die Ergebnisse des jeweils abgelaufenen Sprints begutachten und bewerten. In diesem Projekt-Szenario sind die wichtigsten Stakeholder zum einen die Gesamtprojektleitung und zum anderen die Leiter der Teilprojekte, die in Abhängigkeit zum Teilprojekt Software stehen.
Der Product Owner muss als verantwortliche Person für das Stakeholder-Management dafür sorgen, dass die wichtigsten Parteien – also Projektleiter und Teilprojektleiter – zu diesem Meeting eingeladen sind und sie explizit dazu auffordern, in diesem Rahmen Feedback zu geben.
Sprint-Planning in die Projektsteuerung einbeziehen
Der entscheidende Punkt beim Sprint-Planning ist, dass sich das Software-Team selbst auf die zu erzielenden Lieferergebnisse für den nächsten Sprint verpflichtet. Sprich: Die Personen, die tatsächlich an der Umsetzung der Backlog-Items arbeiten, schätzen das Arbeitspensum nach ihrem Ermessen ein.
Das führt im besten Fall zu einer realistischeren Schätzung, als wenn etwa die Projektleitung die Dauer einzelner Arbeitspakete vorab abschätzen soll. Die selbst gesteckten Ziele wecken beim Team zudem meist den Ehrgeiz, diese auch zu erreichen. Im Sprint-Review können die Zusagen des agilen Teams von den Stakeholdern nach jedem Sprint überprüft werden.
Anhand von Velocity-Charts lassen sich die selbst gesteckten mit den real erreichten Zielen vergleichen. Sie visualisieren in Form von Balkendiagrammen die Summe zugesagter und realisierter Story Points pro Sprint und stellen Planung und Realität so anschaulich gegenüber. Anhand der Charts lässt sich mit der Zeit eine zuverlässige Aussage darüber treffen, wie viele Story Points das Team in einem Sprint schafft. Sie sind eine gute Grundlage für die Roadmap.
Projektroutinen und Meetings der Teilprojekte synchronisieren
Es empfiehlt sich, Sprintlängen und Berichtszeiträume des Gesamtprojekts miteinander zu synchronisieren. In dem skizzierten Projekt mit seinen dreiwöchigen Sprints ist jeder dritte Jour fixe gleichzeitig das Sprint-Review. Das bietet den Vorteil, dass sich der Beitrag des agilen Teams für das Gesamtprojekt auch im klassischen Reporting-Format abbilden lässt. Nach erfolgtem Sprint-Review für den zurückliegenden Sprint und dem Sprint-Planning für den nächsten Sprint kann das Reporting für das Gesamtprojekt erfolgen.
Dabei entsprechen die Ergebnisse aus dem Sprint-Review dem Feld „Aktivitäten und Entscheidungen im Berichtszeitraum“, das in dieser oder einer ähnlichen Form Teil eines klassischen Projektstatusreports ist. Das Feld „Aktivitäten im nächsten Berichtszeitraum“ hat wiederum seine Entsprechung im Sprint-Planning des Scrum-Teams.
Dieses Vorgehen erzeugt Transparenz für alle Teammitglieder und Stakeholder. Außerdem ermöglicht es dem Scrum-Team und dem Entwicklungsteam, sich über die Gründe auszutauschen, warum es zwischen Planung und Realität zu Abweichungen kommt.
Erfolgsfaktoren für hybrides Projektmanagement
Damit diese Stellhebel beim hybriden Projektmanagement funktionieren, braucht es außerdem einige übergreifende Prinzipien und Regeln. Bei hybriden Projekten kommt es vor allem auf klare Rollen, gut funktionierende Kommunikation und Transparenz unter den Teams an. Nur so kann Verständnis für die individuellen Herangehensweisen und damit Vertrauen geschaffen werden.
Speziell die Teilprojektleiter sind wichtige Stakeholder, die nicht vergessen werden sollten. Denn erfahrungsgemäß kommt in hybriden Projekten dann Misstrauen auf, wenn der Kommunikationsfluss zwischen dem agilen und dem klassisch arbeitenden Bereich nicht optimal funktioniert.
Jeder hat die agilen Methoden verstanden
Zu Beginn eines jeden Projektes ist es wichtig, allen Menschen aus dem Projektumfeld zu erklären, warum man sich für die jeweilige Methode entschieden hat und wie das Vorgehen aussehen wird. So lassen sich Konflikte vermeiden, die auf Unverständnis beruhen, weil jemand nicht genau verstanden hat, warum bestimmte Schritte und Vorgehen wichtig sind.
Gerade in Organisationen, in denen agile Methoden bisher noch nicht verankert sind, kann es Sinn ergeben, mit allen Projektbeteiligten zu Beginn des Projektes ein Agile Foundations Training durchzuführen. Das Training soll allen Beteiligten ein Grundverständnis von agilem Arbeiten vermitteln.
Die Rollen im hybriden Projekt sind klar verteilt
Die frühzeitige Rollenklärung darf nicht vernachlässigt werden. Der Product Owner muss auf seine Doppelrolle (Product Owner und Teilprojektleiter) gut vorbereitet werden, da ihm eine zentrale Funktion hinsichtlich der Projektsteuerung zukommt.
Der Product Owner muss verstehen, sich in beiden Welten – also im klassischen und agilen Umfeld – zu bewegen und beide zusammenzuführen, da er innerhalb des agilen Teams für die Einbindung der Stakeholder verantwortlich ist.
Kommunikation im Projekt wird laufend gefördert
Kommunikation ist ohnehin das A und O – in jeder Projektsituation. Wer merkt, dass es bei der Zusammenarbeit zwischen klassischen und agilen Teams hakt oder es beiderseitige Verständnisprobleme gibt, tut gut daran, das Gespräch zu suchen und Probleme anzusprechen. Viele Konflikte lassen sich so rechtzeitig entschärfen.
