Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 2)

Vorhang auf für Teil 2 der Artikelserie zu den Unterschieden zwischen klassischem und agilem Projektmanagement! Du hast den ersten Artikel verpasst? Kein Problem: Klicke einfach auf folgenden Link: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 1)

Dieser Artikel ist Teil 2 der Serie über die Unterschiede im klassischen und agilen Projektmanagement. Du willst mehr erfahren? Dann schau gern in die anderen Teile rein:
Teil 1: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 1)
Teil 2: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 2)
Teil 3: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 3)
Teil 4: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 4)

In diesem Artikel behandeln wir die folgenden drei Unterschiede: 

• Geringe vs. starke Veränderlichkeit des Ergebnisses
• Frühe vs. späte Entscheidungen
• Vollständige vs. sich entwickelnde Anforderungen

Viel Spaß beim Lesen!

Geringe vs. starke Veränderlichkeit des Ergebnisses

Soll in einem Unternehmen ein Standard eingeführt werden (z. B. Qualitätsmanagement nach ISO 9001), dann ist das Ergebnis von vornherein vorgegeben – davon abzuweichen wäre grob fahrlässig. Aber ist das immer so? Mitnichten! Manche Projekte werden aus „vagen Ideen“ heraus geboren – und auch diese haben ihre Daseinsberechtigung. 

Klassisches Projektmanagement: 

In traditionellen Projekten ist von vornherein klar, wie das Ergebnis aussehen soll. Die Anforderungen sind eindeutig definiert, und das Ergebnis wird (hoffentlich) kaum von diesen abweichen. Dies trifft insbesondere auf Routineprojekte mit bewährten Rezepten zu. Der Projektleiter muss sich über eines im Klaren sein: Wesentliche Abweichungen werden vom Auftraggeber vermutlich nicht akzeptiert – und selbst kleinere Abweichungen können zu lauten Rufen nach Nachbesserungen führen.

Agiles Projektmanagement: 

Für ein agiles Vorgehen eignen sich Vorhaben, bei denen die Anforderungen zu Beginn unklar sind oder aber absehbar ist, dass sie sich noch ändern werden. Die Beteiligten mögen sich auf die Idee einigen können, das konkrete Ergebnis steht jedoch oft noch nicht fest. Bei innovativen Projekten steht mitunter zu Beginn noch nicht fest, was technisch überhaupt im Detail möglich/machbar ist. Im Laufe des Projektes werden Erkenntnisse gesammelt, die den Projektverlauf stark beeinflussen werden, z. B. neue technologische Erkenntnisse oder geänderte Anforderungen des Marktes.

Frühe vs. späte Entscheidungen

Weißt du schon, was du am dritten Tag deines nächsten Sommerurlaubs machen wirst? Oder welche Packungsgröße des Lieblingsdeodorants du deinem/r Liebsten zu Weihnachten schenken wirst? Vermutlich nicht, da dir zum jetzigen Zeitpunkt noch nicht alle Informationen vorliegen: Wie wird das Wetter an besagtem Tag sein? Welche Packungsgrößen gibt es vor Weihnachten im Angebot? Genauso ist es in manchen Projekten: Frühe Entscheidungen sind manchmal nicht nötig und eine zu frühe Festlegung kann am Ende sogar schädlich und teuer werden.

Klassisches Projektmanagement: 

Entscheidungen werden oft in sehr frühen Projektphasen getroffen über 

• Anforderungen
• Ziele
• Ressourcen (Wer macht wann was?)
• Termine und Budget (Wann liegt genau was vor und was kostet es?)

In Projektstrukturplänen und Arbeitspaketbeschreibungen werden Details formuliert, wie einzelne Aufgaben umgesetzt werden sollen. Dieses Vorgehen funktioniert wunderbar, wenn das gewünschte Ergebnis von Beginn an klar definiert werden kann und wenn bewährte Vorgehensmuster zum Ziel führen können. In vielen Fällen sind frühe Entscheidung sogar dringend angesagt: Wenn knappe Ressourcen rechtzeitig gesichert werden müssen, langwierige Genehmigungsprozesse absehbar sind oder mit langen Bestellzeiten für Spezialkomponenten gerechnet werden muss. Ebenfalls wäre es töricht, mit Entscheidungen zu warten, wenn diese durch Kundenwunsch, Regeln oder Standards vorgegeben sind (Schein-Entscheidungen).

Agiles Projektmanagement: 

Das oben beschriebene Vorgehen im klassischen Projektmanagement fällt jedoch dann schwer, wenn nur begrenztes Wissen vorliegt, prinzipielle Aspekte noch unklar sind und erst während des Projektes geklärt werden können. Frühe Entscheidungen können richtig teuer werden, wenn später zurückgerudert werden muss: Bereits beschaffte Komponenten werden z. B. nicht genutzt, da sie sich im Verlauf des Projektes als untauglich herausstellen. In agilen Projekten sollen daher Entscheidungen immer so spät wie möglich getroffen werden. Häufig wird das Konzept des „Last Responsible Moments“ genannt – der letzte Augenblick zum Entscheiden, der verantwortet werden kann. 

Ein oftmals guter Indikator für diesen letzten zu verantwortenden Augenblick zum Entscheiden ist der Moment, wenn die Kosten, die Entscheidung nicht zu treffen, höher werden als die Kosten für die Entscheidung:

Anmerkung: So schön symmetrisch wie in der sehr vereinfachten Abbildung sieht die Realität selbstverständlich nicht aus. Der ideale Entscheidungsmoment (minimale Gesamtkosten) kann durchaus vor oder nach dem Schnittpunkt der beiden Kurven liegen. Hinzu kommt, dass sich in einem realen Projekt die zwei Kurven in der Regel nicht exakt vorhersagen lassen. Oft wirst du sehr grob schätzen müssen!

Vollständige vs. sich entwickelnde Anforderungen

Wie in den vorherigen Abschnitten gezeigt: Nicht immer steht alles vom ersten Moment an fest, sondern entwickelt sich im Projektverlauf. Dies spiegelt sich selbstverständlich auch in den Anforderungen wider. Werfen wir einen Blick auf die Unterschiede:

Klassisches Projektmanagement: 

Anforderungskataloge, Lastenheft und Pflichtenheft: In traditionellen Projekten werden Anforderungen zu Projektbeginn vollständig erfasst und detailliert ausgearbeitet. Es wird davon ausgegangen, dass alle oder möglichst viele Informationen bereits zu Beginn vorliegen und daraus auch die richtigen Schlüsse gezogen werden. Der Auftraggeber/Kunde muss von Anfang an wissen, was er will bzw. benötigt.

Ein klarer Vorteil dieses Vorgehens liegt auf der Hand: Gibt es in einem Projekt nur wenige Unwägbarkeiten und kann man mit bewährtem Vorgehen zum Ziel kommen, so können auf dem Fundament unumstößlicher Anforderungen besonders gut die Kosten und die Projektdauer geschätzt bzw. geplant werden. Andererseits muss sich der Auftraggeber bewusst sein, dass jede nachträgliche Änderung der ursprünglichen Anforderungen zu erheblichen Zusatzaufwänden und Verzögerungen führen kann.

Agiles Projektmanagement: 

In vielen Projekten sieht die Realität allerdings ganz anders aus als oben beschrieben: Häufig werden während des Projektes neue Erkenntnisse gewonnen, Anforderungen ändern sich – und Pläne und Dokumente müssen immer wieder angepasst werden. 

Was im klassischen Projektmanagement als Störung gesehen wird (Änderung der Anforderungen), wird in agilen Projekten als selbstverständliche Rahmenbedingung akzeptiert. Es wird davon ausgegangen, dass sich die Anforderungen ändern bzw. zu Beginn schlichtweg noch nicht feststehen. Es kann nicht alles sofort richtig gemacht oder geplant werden. Oft ergeben sich benötigte Erkenntnisse erst während der Ausführung. 

Selbstverständlich werden auch bei agilem Vorgehen präzise Anforderungen erstellt und detailliert beschrieben. Der Unterschied liegt jedoch im Zeitpunkt: Die Anforderungen werden nicht alle auf einmal zu Beginn festgelegt, sondern immer nur so viele und in dem Detailgrad, wie es für das unmittelbare weitere Vorgehen nötig ist.

Fazit

Wir werden nicht müde, es zu betonen: Die Suche nach „dem“ perfekten Projektmanagement-Ansatz ist müßig – auf das richtige Werkzeug in der jeweiligen Situation kommt es an. Diese Artikelserie gibt einen Überblick über Unterschiede zwischen den Methodiken und hilft (hoffentlich) bei der Auswahl. 

Übrigens: Hier geht es zum dritten Teil der Serie!