Bereits seit Anfang der 1990er Jahre kommt die agile Projektmanagementmethodik Scrum zum Einsatz (s. Abb. 2). War die Methodik damals vor allem in der Software-Entwicklung zu finden, wird sie heute auch auf andere Projektklassen (Organisationsentwicklung, Change Management, Produktentwicklung etc.) oder Planungsprozesse übertragen.[1] In der Scrum-Methode existieren die Rollen des Product Owners, des Scrum Masters und des Development Teams.[2] Diese Rollen werden im Folgenden noch näher beschrieben werden. Scrum setzt konsequent auf die Bottom-up-Organisation und lässt dem Entwicklungsteam mehr Freiraum für eigenständiges, kreatives Arbeiten als bei klassisch geführten Projekten.
3.1 Rollen in der Scrum-Organisation
Product Owner: Der Product Owner ist das Bindeglied nach außen. Er vertritt die Interessen der Stakeholder und nimmt die Anforderungen in den Product Backlog auf, die anschließend priorisiert werden. Dafür sind insbesondere gute Marktkenntnisse von Vorteil.[1]
Scrum Master: Der Scrum Master steht dem Development Team als Moderator und Vermittler zur Verfügung und ist für die Organisation sowie die Einhaltung der Abläufe zuständig. Er hält dem Development Team den Rücken frei, sodass es ungestört arbeiten kann.[2]
Development Team: Das Development Team setzt die Anforderungen in die Produktfunktionalität um. Es besteht aus 5 bis 10 Personen. Als Idealgröße gilt ein Team aus 7 Entwicklern. Das Team ist sein eigener Manager (Self-Organisation) und jedes Mitglied kennt den Sinn und das "große Ganze" des Projekts.[3]
Abb. 2: Scrum Framework[4]
3.2 Steuerung in der Scrum-Organisation
Aus diesen Steuerungsrollen lassen sich verschiedene Bereiche der Steuerung ableiten. Differenziert werden können die Steuerung des Inhalts- und Umfangsmanagements von Projekten, das Termin- und Kostenmanagement und das Risikomanagement.
3.2.1 Steuerung nach Inhalt und Umfang
Die Steuerung des Inhalts und des Umfangs bei einem Transformationsprojekt muss die Ausrichtung des Projekts an der Strategie des Unternehmens sicherstellen. Der Grad der Komplexität bestimmt dabei maßgeblich die Auswahl der Methode. Aufgrund der Komplexität von Transformationsprojekten werden in diesen vermehrt agile Methoden eingesetzt, in denen sich die Steuerung des Inhalts und Umfangs unterscheidet. Die Flexibilität, mit Veränderungen im Projekt umzugehen, ist eine Stärke der agilen Methoden in Transformationsprojekten. In klassischen Methoden werden in Bezug auf die Projektsteuerung lediglich Abweichungen beim Inhalt und Umfang in Bezug auf die zu Beginn definierten Ergebnisse gemessen. Die Inhalte werden dabei nicht hinterfragt, wobei gerade das in der Transformation zu unbefriedigenden Ergebnissen führen kann. Dennoch ist das Management, das in der Steuerung mit klassischen Projektmanagementmethoden vertraut ist, mit dem flexiblen Inhalt und Umfang der agilen Methoden oft überfordert.[1] Klassische Kennzahlen, die den Fertigstellungsgrad während des Projekts aufzeigen, funktionieren bei agilen Methoden häufig nicht mehr. Meilensteine werden in agilen Methoden erst in der Iteration Schritt für Schritt erreicht und bei sich änderndem Umfang sinkt der Fertigstellungsgrad oftmals plötzlich.
3.2.2 Steuerung der Zeitplanung und Kosten
Agile und klassische Methoden unterscheiden sich deutlich in der Art der Steuerung des Zeitplans (z. B. Meilensteine) und der Kosten. Änderungen am Inhalt und Umfang wirken sich in klassischen Methoden direkt auf Termine und Kosten aus. Dabei sind in der Transformation ebenfalls diejenigen agilen Methoden im Vorteil, die zu einem definierten Kosten- und Zeit-Budget das zu erreichende Ergebnis erzielen. In klassischen Projektmethoden wird zu Beginn des Projekts oft viel Aufwand betrieben, um Kosten und Termine möglichst genau zu schätzen und einen Puffer einzurechnen.[1] Wenn sich Änderungen ergeben, kann dies für die beteiligten Projektmitarbeitenden frustrierend sein. Sowohl das Arbeiten als auch Urlaube wurden zu Beginn an der Initialplanung ausgerichtet und müssen nun verschoben werden. Die Steuerung des Projekts verliert dadurch an Akzeptanz. Mit der agilen Vorgehensweise wird ein Folge- oder Zusatzprojekt notwendig, wenn das Ergebnis zum definierten Zeitpunkt mit den vorgegebenen Kosten weiterentwickelt werden muss. Dank laufender Zwischenergebnisse kann das aber bereits früh im Projektverlauf abgeschätzt werden. Das dient wiederum als Entscheidungshilfe für das Management, wenn abzusehen ist, dass ein Projekt frühzeitig abgebrochen werden sollte, weil es die gesetzten Ergebnisse nicht erreichen kann.
Das ist nur ein Ausschnitt aus dem Produkt Haufe Finance Office Premium. Sie wollen mehr?
Jetzt kostenlos 4 Wochen testen
Anmelden und Beitrag in meinem Produkt lesen