Aus Tausend werden Zehntausend, aus Millionen werden Milliarden und der Projekterfolg wird immer wieder verschoben. Insbesondere öffentliche Projekte geraten immer wieder in die Schlagzeilen. Projekte im Bereich der öffentlichen Verwaltung werden meist in klassischer Form organisiert. Diese zeichnet sich vor allem durch eine klare Hierarchie mit einem Projektverantwortlichen aus. Im Weiteren sind die einzelnen Projektschritte als Meilensteine geplant. Dies hat zur Folge, dass der Umfang definiert ist und Abweichungen wie z. B. unvorhergesehene Bedarfsänderungen als störend wahrgenommen werden.
Könnten hier agile Methoden zu einem effektiveren Projektmanagement beitragen?
Vereinfacht lassen sich Projekte aus dem Umfang, der dafür veranschlagten Zeit und dem Budget zusammensetzen.
Beim klassischen Projektmanagement wird der Umfang des Projekts zur Erreichung des Ziels zum Projektstart festgelegt. Die zur Zielerreichung erforderliche Zeit und das dafür zu veranschlagende Budget werden dazu geschätzt. Problematisch ist, dass auf Änderungen des Bedarfs während der Projektdurchführung nur schwer reagiert werden kann. Änderungen wirken vielmehr als Störungen. Die Vorteile im klassischen Arbeiten bestehen darin, definierte Ziele, die einer geringen bis keinen Bedarfsänderung unterliegen, zügig umsetzen zu können.
Während größerer Projekte kommt es jedoch oftmals zu veränderten Bedingungen, insbesondere bei Projekten im Bereich der Digitalisierung. Daher bieten agile Arbeitsweisen Potenzial, Projekte effektiver umzusetzen. Grundsätzlich werden als feste Rahmenbedingungen das Budget und die Zeit festgelegt. Der Umfang des Projekts wird jedoch geschätzt und kann somit dem Bedarf zur Erreichung des Projektziels angepasst werden. Eine agile Methode des Projektmanagements ist Scrum.
Rollen der Projektbeteiligten
Im Rahmen der Scrum-Methode gibt es im Wesentlichen drei Rollen:
Product Owner:
Der Produkteigner vertritt die Produktanwender, die ein Interesse am Erfolg des Projekts haben. Soll in einem Unternehmen eine IT-Lösung eingeführt werden, liegt die reibungslose Nutzung im Interesse der Anwender. Daher sollte der Product Owner die Bedürfnisse und Interessen der Anwender genau kennen.
Scrum Master:
Der Scrum Master ist kein Projektverantwortlicher. Vielmehr unterstützt er das Team in dessen Aufgabenerfüllung und fördert die Zusammenarbeit. Er kümmert sich um die Ressourcenbeschaffung und ist Ansprechpartner für Außenstehende. Er verantwortet die korrekte Durchführung des Scrum-Prozesses.
Scrum-Team:
Das Scrum-Team, bestehend aus fünf bis zehn Personen, zeichnet sich durch eine gleichberechtigte und selbstorganisierte Arbeitsweise aus. Es gibt innerhalb des Teams keine Hierarchie. Aufgrund der interdisziplinären Zusammensetzung des Teams hat jedes Teammitglied einen eigenen Kompetenzbereich. Alle Fachbereiche, die zum Erfolg des Projekts beitragen, sollten im Team vertreten sein.
5 Schritte des Scrum-Prozesses
Mit dem Auftraggeber wird das Projektziel zu Beginn besprochen. Dieser formuliert eine Projektidee, die eine grobe Vorstellung des Projekts bildet. Dabei werden Elemente, Merkmale und Funktionen des Produkts beschrieben. Im Anschluss arbeitet das Team selbstorganisiert an dem Projekt. Ein Merkmal der agilen Arbeitsweise ist hier, dass es keinen festgelegten Projektplan gibt. Das gesamte Projekt ist in einzelne Abschnitte – sogenannte Sprints – untergliedert, an deren Ende dem Auftraggeber ein funktionsfähiges Produkt vorgelegt wird. Dadurch kann, im Gegensatz zum klassischen Projektplan, bei jedem Abschnitt auf Änderungsbedarf eingegangen werden, bis das vollständige Projekt umgesetzt wurde.
1. Anlage und Pflege des Product-Backlog
Aus den Anforderungen des Product Owner wird das Product-Backlog, welches sämtliche Funktionen und Merkmale des Produktes enthält, erstellt. Dieses wird im Verlaufe des Projekts immer konkreter und umfangreicher.
Ebenfalls werden den Elementen und Funktionen Prioritäten vergeben und festgehalten. Diese werden danach vergeben, um die höchste Zufriedenheit der Anwender sicherzustellen. Auch wird hier festgehalten, wenn etwas nicht realisierbar ist oder verschoben werden muss. Damit dient das Projekt-Backlog der Steuerung und Dokumentation des gesamten Prozesses.
2. Sprint-Planning und Sprint-Backlog
Ein Sprint ist eine Zeitbox von ca. einem Monat. Im Plannig wird der nächste Sprint vorbereitet. Die Sprint-Aufgaben und -Ziele werden in das Sprint-Backlog aufgenommen und um die Einträge aus dem Product-Backlog ergänzt. Insbesondere wird festgehalten, was im nächsten Sprint entwickelt, erstellt oder durchgeführt werden wird und wie die entsprechenden Aufgaben und Arbeiten erledigt werden sollen. Im Anschluss arbeiten die einzelnen Teammitglieder an ihren Aufgaben, bis diese erledigt sind.
3. Daily Scrum
Bei einem täglichen 15-minütigen Meeting tauschen sich die Teammitglieder kurz über das Erreichte aus und planen das weitere Vorgehen. Dadurch ist eine stetige Kommunikation gewährleistet. Alle Teammitglieder haben dabei das Sprint-Ziel im Blick.
4. Sprint-Review
Am Ende eines Sprints präsentiert das Team das entwickelte Produkt. Das Produkt wird überprüft und es erfolgt die Anpassung des Product-Backlog. Fernerkönnen der Product Owner sowie die Anwender Input geben. Dies ist die Stelle, an der auf Änderungen eingegangen werden kann und so der Umfang ggf. erweitert oder verringert wird.
5. Analyse mithilfe der Sprint-Retrospective
In einer Retroperspektive wird der Sprint begutachtet. Es wird geschaut, ob die Zusammenarbeit im Team funktioniert hat, was zur Optimierung beitragen kann oder ob es Hindernisse gegeben hat. Dies dient dazu, die Arbeit für den nächsten Sprint effektiver zu gestalten. Somit ist ein Sprint auch Teil eines Lernprozesses für zukünftige Scrum-Projekte.
Nach Abschluss eines Sprints beginnt dieser Prozess für den nächsten Abschnitt unter Berücksichtigung der gewonnenen Erkenntnisse von vorn. Dadurch wächst das Product-Backlog, bis alle zu Beginn festgelegten Merkmale und Funktionen eines Ziels erreicht sind und das gesamte Projekt erfolgreich und unter Berücksichtigung des Änderungsbedarfs umgesetzt wurde.
Fazit:
Agile Methoden, wie z.B. das Scrum-Verfahren sind nicht für alle Projekte geeignet. Für die Prozessoptimierung der öffentlichen Verwaltung könnte es jedoch ein geeignetes Verfahren sein. Insbesondere, da die gewonnen Erkenntnisse bei einzelnen Sprints einbezogen werden, wie auch die Erfahrungen der Mitarbeitenden. Ebenfalls könnte die Akzeptanz der Mitarbeitenden für die Veränderung von Prozessen durch deren Einbindung im Sprint-Review gestärkt werden.
