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.

Das Eiserne Dreieck des Projektmanagement
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 ist dafür verantwortlich, das Projektziel unter den gegebenen Rahmenbedingungen ‘durch die Tür’ zu bekommen (den Plan zu realisieren). Erfahrene Projektleiter wissen, dass Unvorhergesehenes immer geschieht.

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.

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.

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 Umsetzung: Scope ist variabel

Bei diesem Vorgehen ist der scope variabel — was nicht bedeutet, 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-haves 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

Weiter hinten, gegen Ende des Vorhabens kommen die nice-to-have Features, die einen geringeren Kundennutzen oder business value haben.

Die nice-to-have-Features sind 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 zielgerichtet dafür sorgen, dass die wichtigsten Dinge geliefert werden und produktiv mit Unsicherheiten umgehen.

Die Prognose, wann welches Feature vorhanden sein wird, hat mit agilen Methoden keinen Zeitpunkt, sondern einen Zielbereich.

In konventionellen Umgebungen steht stattdessen der gesamte Liefertermin und nicht einzelne Features zur Disposition. Für ein Umfeld mit vielen Veränderungen und auftretenden unerwarteten Ereignissen ist diese Planung  sehr einleuchtend.

Dass wir keine sicheren Aussagen über den Auslieferungstermin eines Features machen können, liegt nicht etwa an der verwendeten Methode — sondern an der mit Unsicherheiten behafteten, komplexen Umgebung und daran, dass wir zwei andere Ecken des Dreiecks fixieren..

Release burn-down Chart: wann kriege ich mein feature?

Die Grafik zeigt ein stilisiertes release burn-down eines Teams. Auf der vertikalen Achse sind die noch zu implementierenden Features aufgetragen, gemessen in story points als relative Aufwandschätzung. Auf der horizontalen Achse ist die Zeit bis zum geplanten Release-Datum aufgetragen.

Das release burn-down chart wird nach jedem Sprint aktualisiert.

Release burn-down Chart

Der Wert auf der y-Achse ‘schrumpft’ dabei um die story points der in diesem Sprint umgesetzten stories.

Dies ist die velocity des Teams, die teamindividuelle Geschwindigkeit, ihr footprint, wenn man so will … das Muster, dass sich nach ein paar Sprints für jedes stabile Team zeigen wird und das keinesfalls eine Vergleichsgröße zwischen Teams ist!

Gleichzeitig kann das release burn-down genutzt werden, um eine Prognose für die Zukunft zu erstellen und eine Orientierung zu geben ob es möglich sein wird, den noch im Backlog vorhandenen Feature-Umfang bis zum geplanten Release-Termin umzusetzen.

Embrace Change — Änderungen? Gerne!

In der agilen Entwicklung wird es als normal und erwartbar erachtet, wenn mitten im Projektverlauf neue Feature-Wünsche dazukommen. ‘Embrace change’ heisst es: heisse Änderungen willkommen.

Es ist eine gute Praxis, diese neu hinzukommenden Features in einer anderen Farbe im Backlog zu markieren. In diesem Beispiel ist dies der rote Balken unterhalb der Null-Linie.

Die blau gestrichelte Linie zeigt die Lieferprognose, wenn alles kommt, wie es soll. Das heißt: wenn dem Team nichts dazwischen kommt, die story-point-Schätzungen passen und … die velocity unverändert bleibt.

Die beiden roten Strichlinien zeigen die Prognosen für eine optimistische (steile Kurve links) bzw. pessimistische (flache Kurve rechts) Annahme für die velocity. Kommt das Team mit der Umsetzung schneller voran (Kurve links): gute Chancen, dass der rote Bereich auch noch geliefert werden wird. Treten Schwierigkeiten, impediments auf und die Dinge verzögern sich, sinkt die velocity und es werden weniger story points ausgeliefert. Natürlich werden nicht die Punkte geliefert sondern deren Äquivalent in Nutzen oder business value.

Dann zeigt der Schnittpunkt der rechten Linie mit dem Release-Datum, welche Features bis zu diesem Datum voraussichtlich fertig werden. Hoffentlich alle must-have-Features. Wenn dies nicht der Fall ist, kann der Product Owner frühzeitig mit seinen Stakeholdern über eine Verschiebung des Release-Datums nachdenken.

Das einfache burn-down chart erzeugt also Transparenz. Schwierigkeiten mit dem Lieferumfang kündigen sich rechtzeitig an, um angemessen darauf reagieren zu können.

Das muss man aushalten lernen und das Backlog laufend nach den Bedarfen aller Stakeholder priorisieren.

Reflexionsfragen

 

  • 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?
Scroll to Top