Unlocking Potential

Nach der Einleitung zum agilen PMBOK^® Guide gehe ich heute auf die Randbedingungen klassischer und agiler Projekte ein.

Derzeit fallen mir drei Gruppen von Projektrandbedingungen ein, die hier zu diskturieren sind:

1. Magisches Dreieck
   Das aus meiner Sicht veraltete Modell, welches Scope, Zeit und Budget als Randbedingungen eines Projektes definiert.
2. PMBOK^® Guide 4th edition
   Mit der neuen Version des Standards sind die Randbedingungen Scope, Qualität, Terminplan, Budget, Ressourcen und Risiko.
3. Pentagon
   Ich persönlich sehe ein Pentagon von Randbedingungen, bestehend aus Scope, Zeit, Budget, Qualität und Kundenzufriedenheit.

Welches Modell nun richtiger als weniger richtig ist, habe ich bereits in Beschreibung des Pentagon und in der Diskussion der Neuerungen des PMBOK^® Guide 4th edition angesprochen.

Im agilen Projekten werden die Randbedingungen nun meist relativiert, abhängig vom jeweilen Entwicklungsmodell für die Projektergebnisse wie beispielsweise Scrum. Klassisch geht man davon aus, dass man alle Bedingungen vorher festlegen kann und dann auch einhält. Diese Sichtweise wird vor allem durch das Magische Dreieck manifestiert.

Der neue PMBOK^® Guide führt nun weitere wichtige Themen wie Ressourcen und Risiko ein. Gerade Risiken ziehen sich nun durch alle anderen Randbedingungen derart stark durch, dass die Randbedingung nicht unabhängig von den anderen ist und mir damit nicht zusagt. Mit Ressourcen kann ich durchaus leben, hier muss jeder selbst entscheiden welcher Schule er folgen will.

Ich persönlich folge meinem Pentagon, welches dem Magischen Dreieck die häufig traditionell wenig beachteten Aspekte Qualität und Kundenzufriedenheit hinzufügt. Der letzte Punkt, die Kundenzufriedenheit ist der Aufhänger für viele Aspekte agiler Methodiken. Im Gegensatz zum Magischen Dreieck weiß der Kunde häufig vor dem Projekt nicht, was er exakt möchte. Während ihm die Teilergebnisse des Projektes gezeigt werden, ändern sich seine Wünsche und damit die Anforderungen.

Der große Vorteil der agilen Projekte ist eben, dass die Randbedingungen klassischenr Projekt verändert sind um eine hohe Flexibilität und Kundenzufriedenheit zu unterstützen. Die Herausforderung ist, dies den Verantwortlichen erfolgreich zu verkaufen. Ich präferiere aufgrund meiner Projekte folgende Randbedingungen agiler Projekte:

1. Kundenzufriedenheit
   Die Kundenzufriedenheit ist das oberste Prinzip eines agilen Projekts. Alle anderen Randbedingungen haben sich unterzuordnen. Damit einher geht eine intensivere Zusammenarbeit mit dem Auftraggeber (häufig über den Product Owner bei Scrum) als in klassischen Projekten.
2. Zeit und Budget
   Mindestens eine der beiden Randbedingungen muss von vornherein festgelegt werden, dabei sollten im Budget unbedingt auch die Aufwände interner Mitarbeiter eingerechnet werden.

Was passiert mit dem Rest?

• Ressourcen
  Agile Projekte sollten nicht nebenher von Projektmitarbeitern durchgeführt werden. Hier sollten ganz klar dedizierte Ressourcen freigestellt und aufgrund der intensiveren Kommunikation auch an einem Ort zusammengeführt werden (Colocation). Allerdings ergeben sich die Personalressourcen und alle anderen Ressourcen aus den Projektrandbedingungen oben und gehen über das Budget wiederum in die Randbedingungen ein. Somit sind die Ressourcen, wie sie der PMBOK^® Guide sieht, nicht als Randbedingung zu führen.
• Scope
  Der Scope ist ein initialer Wunsch des Auftraggebers hinsichtlich des finalen Inhalts und Umfangs. Er soll sich während des Projekts weiterentwickeln, gestützt durch intensive Zusammenarbeit mit dem Projektteam. Er dient als Grundlage der Grobplanung, ist aber keine Projektrandbedingung.
• Qualität
  Der Kunde wird nur zufrieden sein, wenn ihm gute Qualität geliefert wird. Ich hoffe, dass er unzufrieden ist, wenn der zeitliche Aufwand für besonders gute Qualität zu hoch wird. Damit sollte die Qualität über Zeit und Kundenzufriedenheit als Randbedingungen agiler Projekte ausreichend repräsentiert sein, ansonsten muss sie als solche hinzugefügt werden.
• Risiko
  Wie schon angedeutet, ist die Randbedingung Risiko aus dem PMBOK^® Guide keine Randbedingung für mich.

Ein Erfolgsfaktor agiler Projekte ist, die gewählten Randbedingungen den Stakeholdern nachhaltig zu vermitteln.

Welche Randbedingungen für agile Projekte verwenden Sie?

Dieser Artikel wurde von Andreas Heilwagen am 26.05.2009 um 08:00 gepostet und unter Best-of, Meinung, PMI, Scrum, Standards eingeordnet. Sie können Kommentaren über den RSS 2.0-Feed folgen. Das Posting steht unter der Creative Commons-Lizenz wenn nicht anders vermerkt.