Zum Inhalt gehen

Hybrides Projektmanagement im öffentlichen Sektor – Teil 4

Capgemini Invent
10. Juni 2021
capgemini-invent

Die im dritten Artikel dieser Blog-Serie (Diverse Stakeholder für ein Miteinander im hybriden Projektumfeld gewinnen) diskutierten Rahmenbedingungen manifestieren sich im letzten Artikel in ihren unmittelbaren Auswirkungen auf die Begleitung der Anforderungen.

Insbesondere in einer diversen, teils risikoaversen Stakeholder-Landschaft ist proaktives Anforderungsmanagement essenziell – von Anforderungserhebung, deren Abstimmung bis zur fristgerechten technischen Umsetzung innerhalb der Entwicklungsteams.

Zahlreiche strukturelle (z. B. Request for Change (RfC) und entsprechende Vorlaufzeiten) und operative (z. B. Vielzahl von Anforderungsinstanzen durch beteiligte Fachbereiche und Schnittstellen) Rahmenbedingungen münden oft in widersprüchlichen Anforderungen. Diese entfalten oft komplexe Wechselwirkungen und Abhängigkeiten. Im hybriden Projektumfeld kommt daher internen, fachlichen Wissensträger*innen eine besondere Rolle zu – beispielsweise als Product Owner (PO) mit fachlichem Schwerpunkt. Teils fehlende Vorerfahrungen in agiler Software-Entwicklung müssen ausgeglichen werden – bspw. durch Unterstützung erfahrener Business Analyst*innen (BA) und Software Architekt*innen (SW-A [1]) bei der methodischen SW-Entwicklung, als auch durch Agile Coaches wie Scrum Master hinsichtlich agiler Vorgehensweisen.

PO müssen insbesondere die fachliche Produktvision und deren wesentlichen fachlichen Ziele immer im Blick haben, um „falsche“ Umsetzungsschwerpunkte zu vermeiden. Die Herausforderung ist hierbei die fachlichen Anforderungen Ende-zu-Ende zu begleiten, technische Anforderungen zu vereinbaren und proaktiv Konflikte zu navigieren. Dies gilt sowohl für die Zusammenarbeit mit verschiedenen Fachbereichen und Schnittstellen als Anforderungsstellern, als auch in einer „Übersetzungsfunktion“ mit den Entwicklungsteams – nur dann kann ein stabiles, anwenderfreundliches und systemintegriertes Produkt entwickelt werden

Drei Erfolgsfaktoren für die operative Anforderungsbegleitung

Die Achse entlang der PO, BA und SW-A ist im hybriden Projektumfeld entscheidend. Deren Zusammenarbeit muss über Agile Coaches, als auch Projektleitungen (und Rollen wie Qualitätsverantwortlichen) unterstützt werden, um die komplexen Rahmenbedingungen zu meistern. Mit Fokus auf die PO und BA-Konstellation sind diese drei Erfolgsfaktoren zu beachten:

  1. PO betreuen Anforderungen im Lebenszyklus Ende-zu-Ende

Die beschriebene Komplexität der Anforderungen muss bereits zum Projektstart auf unterschiedlichen Ebenen – mit Unterstützung der Projektleitung – über eine strukturierte Methodik berücksichtigt werden: Anstatt bspw. mit Fachbereichen einzelne User Stories zu diskutieren und sich dabei „in Details zu verlieren“, ist zunächst eine aggregierte Epics-Ebene eine geeignetere Grundlage für die weitere Planung des Projektscopes und einzelner Releases sowie die spätere Verfeinerung der Anforderungen.

Im weiteren Projektverlauf treiben die PO die Anforderungen proaktiv voran und lösen mögliche Konflikte auf. Mögliche Abweichungen, Lücken und Konflikte müssen kontinuierlich geprüft, dokumentiert, sowie mit den Anforderungsstellern und Schnittstellen diskutiert und priorisiert werden (z. B. anhand der MOSCOW-Kriterien: Priorisierung der Anforderungen nach „Muss“, „Soll“ und „Kann“), um Konsens zu forcieren. Die Projektleitung ist dabei explizit einzubinden, um die Gefahr eines „Scope Creeps“ (unkontrollierte Änderungen des Projektscopes) zu reduzieren. Dies entspricht auch deren Verantwortung, um die Umsetzung des geplanten Projektscope im Rahmen des Projektauftrages zu gewährleisten. Interessenskonflikte bei den PO, die als Vertreter der Anwender*innen das bestmögliche Produkt liefern sollen, werden zuzüglich minimiert.

  1. Requirements Engineering ist gemeinsame Aufgabe der PO und BA

Die Verantwortung und die Arbeitsbelastung ist für PO im hybriden Projektumfeld besonders hoch. Deshalb müssen insbesondere die BA methodisch entlasten. Während PO über die Produktvision und Priorisierung einen fachlichen Schwerpunkt haben, sollten BA als „Übersetzende“ zwischen PO und dem restlichen Entwicklungsteam agieren: BA analysieren „fachliche Lösungsoptionen“, teilen fachliche und technische Auswirkungen dieser mit den PO, und schätzen mit Entwicklern und Testern jeweils Aufwände für Umsetzung und Tests über ausgewählte Analyse- und Schätzmethoden. Die PO übernehmen somit federführend die Erhebung und Abstimmung der Anforderungen, während BA diese mit gründlichen Analysen – oft nach bewährten Prinzipien des Requirements Engineering – operativ unterstützen, dokumentieren und verwalten. Durch die Spezifizierung der Anforderungen werden mögliche unvorhergesehene Mehraufwände, Widersprüche, Lücken und Konflikte identifiziert und im besten Fall aufgelöst. Ein weiteres Beispiel der engen Zusammenarbeit zwischen PO und BA ist die arbeitsintensive Erstellung von „klassischen Artefakten“ wie Fachkonzepten. Je besser diese Konstellation zwischen PO und BA (und SW-A) funktioniert, umso stabiler ist Ihr hybrides Projekt und damit Ihr Produkt.

  1. Agile Coaches fördern und fordern Eigenverantwortung – und agieren als Bindeglied zwischen Rollen innerhalb der Entwicklungsteams und Schnittstellen

In beliebigen Guides zu Agilen Rahmenwerken und Methoden ist die Eigenverantwortung der Teams ein zentrales Thema. Agile Coaches – bspw. in Form von Scrum Mastern – unterstützen die Teams und beteiligte Schnittstellen in der Weiterentwicklung der Eigenverantwortung und Kollaboration. In hybriden Projekten ist diese Kollaboration aufgrund der in vorherigen Artikeln beschriebenen Rahmenbedingungen wie hoher Komplexität und zahlreicher Abhängigkeiten – von Anforderungserfassung über Entwicklung bis zur Einführung – besonders wichtig.

Wenn dieses Unterfangen der Eigenverantwortung scheitert (z. B. durch fehlende Akzeptanz der hybriden Rahmenbedingungen, fehlende agile Reife der Entwicklungsteams oder Agiler Coaches) drohen eine Lähmung des Projektfortschritts und die Notwendigkeit von Mikromanagement. Entscheidungen werden dann oft zu spät in der Projektorganisation nach oben „gespült“ und landen auf dem „letzten“ Tisch – dem „Eskalations-Tisch“ der Projektleitung. Agile Coaches können diesen Prozess mitigieren, indem sie die hybriden Rahmenbedingungen anerkennen, Eigenverantwortung der Entwicklungsteams fördern und fordern, als auch die Zusammenarbeit mit und zwischen den Schnittstellen aus diesem Blickwinkel betrachten. Gut strukturierte Termine und Werkzeuge wie Jira oder Confluence, inklusive der Prozesse dahinter, fördern gegenseitige Transparenz und damit Vertrauen zwischen den Informationsgebern und -Empfängern. Agile Zeremonien und -Regeln allein genügen nicht!

Die Rolle des Agilen Coach ist deshalb im hybriden Projekt besonders wichtig und deren Verantwortungsbereich ist – je nach Besonderheiten der Projektsituation – erweitert: Eigenverantwortung wird nicht nur in den Entwicklungsteams unterstützt. Auch die Zusammenarbeit mit den Schnittstellen muss kontinuierlich optimiert werden, und ggf. als Risiko betrachtet und proaktiv mitigiert werden.

Ein stabiles Produkt gelingt dann, wenn alle beteiligten Schlüsselrollen optimal harmonieren

Wenn BA als „rechte Hände“ Ihrer Product Owner agieren können, legen Sie einen wesentlichen Grundstein für den Erfolg Ihres hybriden Projekts. Diese Rollen gewährleisten – mit der Unterstützung anderer Schlüsselrollen im Projekt – die Ende-zu-Ende Begleitung der komplexen Anforderungen und somit eine aus Anwendersicht vollständig integrierte IT-Infrastruktur. Eigenverantwortung ist im hybriden Projektumfeld kein Selbstläufer: Diese muss über Vertrauen und Zusammenarbeitsmodelle (z. B. zwischen PO und BA sowie Schnittstelle zur Projektleitung) erarbeitet werden.

Herzlichen Dank an alle an der Erstellung dieses Artikels beteiligten Personen – Nadja D. (vor allem die methodische Inspiration und die sehr gute Zusammenarbeit), Christof Ziegler, Alexander Dexheimer und Daniel Szabó.

[1] In diesem Artikel liegt der Schwerpunkt auf der Zusammenarbeit der PO und BA; andere Rollen wie Software Architekten, Projektleitungen und Qualitätsverantwortliche sind wichtige Unterstützer für beide Rollen, jedoch nicht im Fokus dieses Artikels


Alle Blogposts der Reihe

Reinventing Work

Hybrides Projektmanagement im öffentlichen Sektor – Teil 4

Capgemini Invent
10. Juni 2021
Reinventing Work

Hybrides Projektmanagement im öffentlichen Sektor – Teil 3

Capgemini Invent
27. Mai 2021
Reinventing Work

Hybrides Projektmanagement im öffentlichen Sektor – Teil 2

Capgemini Invent
12. Mai 2021
Reinventing Work

Hybrides Projektmanagement im öffentlichen Sektor – Teil 1

Capgemini Invent
29. Apr. 2021

Blog-Updates per Mail?

Abonnieren Sie unseren Newsletter und erhalten Sie alle zwei Monate eine Auswahl der besten Blogartikel.