✁
digitalien.org — Stefan Knecht
Das Eiserne Dreieck des Projektmanagement
Drei Variablen des Eisernen Dreiecks
Das ‘Eiserne Dreieck des Projektmanagements’ zeigt die drei Variablen Scope, Ressourcen und Termin:
- Scope (Inhalt und Umfang): Was soll während des Projektes entstehen und in welche Qualität? Welche inhaltlichen Ziele wurden mit dem Stakeholder vereinbart?
- Ressourcen (Kosten): Was für ein Budgetvolumen habe ich zur Verfügung? Was kostet mich die Umsetzung des Projektes?
- Termin (Zeit): Wann startet das Projekt und bis wann ist der Scope zu erreichen? Welche Meilensteine gibt es?
In plangetriebenen Projektmanagement-Methoden ist der Umfang (scope) fixiert.
Was am Ende eines Projektes als Ergebnis stehen soll, wird zuvor festgelegt.
Die Dreiecksbeziehung bedeutet: mindestens eine der beiden anderen Größen ist variabel.
Kommen neue Informationen hinzu, ändern sich Annahmen oder Voraussetzungen — dann muss der Plan angepasst werden.
Wenn es Vorgangsregeln gibt oder eine process governance befolgt werden muss, dann müssen auch die dort vorgegebenen Schritte des Umsetzungsplanes, Nachkalkulationen und Abhängigkeiten berücksichtigt werden.
Änderungen führen damit zu eine Kaskade an Anpassungen an der Planung — wie in einem Wasserfall.
Der Projektleiter? Folgt dem Plan.
Der Projektleiter ist dafür verantwortlich, das Projektziel unter den gegebenen Rahmenbedingungen ‘durch die Tür’ zu bekommen und den vordefinierten Plan zu realisieren. Erfahrene Projektleiter wissen: Unvorhergesehenes geschieht immer.
Fast alle Entscheidungen in Projekt und nicht kalkulierte äußere Einflussfaktoren haben Einfluss auf diese Dimensionen. Wird eine der drei Größen verändert, so hat dies direkte Auswirkungen auf die beiden anderen Größen.
Um die Projektziele trotzdem zu erreichen, müssen Änderungen in einem Parameter durch die beiden anderen Größen ausgeglichen werden. Der Projektleiter hat die Aufgabe diese Zielgrößen so auszubalancieren, so dass das Projekt erfolgreich umgesetzt werden kann.
Um sicher zu gehen und den Plan auch unter widrigen Umständen zu erfüllen, werden daher häufig Zeit- und Budgetpuffer in die Aufwandschätzungen eingeplant. Darunter leidet jedoch die Transparenz.
Ändern sich Bedingungen, dann auch der Plan.
Kann ein Projekt in time, in scope, in budget beendet werden, dann heißt es noch lange nicht, dass der Kunde auch zufrieden ist. Er erhält zwar, was bestellt wurde — doch sind die Bedürfnisse und Randbedingungen noch dieselben wie zum Projektstart?
Es kann also leicht geschehen, dass der Kunde ein Ergebnis erhält, mit dem er wenig anfangen kann. Alle nachträglichen Änderungswünsche würde der Kunde über change requests teuer bezahlen und auf deren Umsetzung warten.
Stimmt das denn ...?
- Wie oft haben Sie in Ihren Projekten eine Punktlandung erreicht?
- Und wenn es gelang: was waren die Gründe?
Was hat dazu geführt, dass eine Planung auch wie geplant umgesetzt wurde? - Was hat dazu geführt, dass Planungen im konventionellen Projektgeschäft nicht eingehalten werden konnten?
- Wie zufrieden waren die Kunden mit dem Ergebnis bei einem konventionellen Projekt?
Gab es nachträglich change requests?
Agil organisierte Vorhaben planen fließend
Agile Entwicklung liefert Wert in kurzen Zyklen der Validierung.
Idealerweise kann man nach jedem neu entwickelten feature eine Auslieferung starten.
Damit eröffnet sich eine neue Option und das ‘Eiserne Dreieck’ stellt sich auf den Kopf —
- Ressourcen (d.h. das Team) werden stabil gehalten — es gibt keine ständige Neufindung des Teams, was einen positiven Einfluss auf die Qualität und Produktivität hat und
- Termine (regelmäßige Releases) werden festgelegt — es geschehen regelmäßige Lieferungen wertstiftender Funktionalität nach jedem Sprint. Ungefähr alle zwei Monate werden die Ergebnisse der Sprints in einem release gebündelt und die Verbesserungen ausgeliefert. Das Feedback des Kunden fließt in kurzen Abständen direkt in die Weiterentwicklung ein.
Agile Planung = variabler Scope
Ist der scope variabel, dann heisst das nicht dass ‘alles mögliche’ herauskommen kann.
Ein variabler Scope bedeutet: Das Team versucht so gut als möglich mit den gegebenen Randbedingungen das zu liefern, was der Kunde am Nötigsten braucht, diejenigen features zuerst zu implementieren, die akut den meisten Nutzen stiften.
Natürlich macht man sich auch zu Beginn einer agile organisierten Entwicklung Gedanken über den Scope: in der Produktvision werden Eigenschaften des fertigen Produktes festgelegt ohne ins Detail zu gehen. Schließlich weiß am Anfang noch niemand — auch der Kunde nicht — wo genau die Reise hingeht.
must-have features stiften den Nutzen
Es wird immer ein paar must-have-Features geben, die den Produktkern ausmachen. Und ebenso nice-to-have-Features, die nicht ganz so entscheidend sind. Diese finden sich im Laufe des Projektes und wenn ‘Luft ist’ dafür.
Hier wird der Hauptnutzen eines sauber gepflegten Backlog einleuchtend: da immer die wertvollsten Eigenschaften oben liegen, kann man sicher sein, dass die Dinge mit dem höchsten Wert auch zuerst erledigt werden.
nice-to-haves stecken im Feature-Puffer
Gegen Projektende kommen die nice-to-have Features in die Umsetzung. Das sind jene, die einen relativ geringeren Kundennutzen oder business value haben. Das wirklich essentiell Notwendige ist dann schon umgesetzt. Die Ralleystreifen kommen am Ende.
Die nice-to-have-Features sind also ein ‘Feature-Puffer’. Man kann jederzeit transparent sehen, was noch erledigt werden könnte, wenn etwas Luft im Projekt bleibt. Das ist ein großer Unterschied zu Zeitpuffern in traditioneller Planung.
Die Planung ist damit weniger abhängig von der Präzision einzelner Schätzwerte.
Bewegung im Anforderungskorridor
Wenn sich an den ursprünglich formulierten Anforderungen nichts ändert, wird man in einem Korridor zwischen einer optimistischen und einer pessimistischen Schätzung dieser Anforderungen landen. Und wenn sich doch etwas ändert, dann bemerken wir das frühzeitig – und nicht erst am Ende des Projekts und können abwägen was in der Zeit noch umgesetzt werden soll.
Es stimmt also nicht, dass ‘man agil nichts planen kann’. Im Gegenteil: man kann durch laufende Priorisierung und die Integration von Nutzerfeedback sehr produktiv dafür sorgen, dass die wichtigsten Dinge auch wirklich geliefert werden und mit Unsicherheiten entspannter umgehen.
Die Prognose, wann welches Feature vorhanden sein wird, hat mit agilen Methoden also keinen Zeitpunkt, sondern einen Zielbereich.
Davon mehr im Beitrag zum ➚ release burn-down chart, das eine Prognose geben kann, wann spezifische Lieferungen geschehen.