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)

In diesem Artikel behandeln wir die folgenden drei Unterschiede: 

Viel Spaß beim Lesen!

Achtung: Hinter den Begriffen klassisch und agil verbergen sich eine ganze Menge unterschiedlicher Vorgehensmodelle, Frameworks und Implementierungen. In der Praxis gibt es einige gemischte Ansätze verschiedenster Ausprägung. So kann ein klassisch organisiertes Projekt durchaus agile Teilprojekte enthalten. Selbst wenn ein Projekt offiziell zu 100% der einen oder der anderen Lehre folgt und der Rahmen fest vorgegeben ist, wird der gewiefte Projektmanager oftmals eine pragmatische Lösung finden, um die daraus resultierenden Probleme abzufangen. In dieser Serie gehen wir auf solche Mischformen und Workarounds nicht ein, sondern betrachten zum besseren Verständnis bewusst die extremen Ausprägungen von „klassisch“ und „agil“.

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.

Beispiel: Projekt zur Zulassung eines Medikaments nach gängigen Standards

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.

Beispiel: Entwicklung eines innovativen und kältebeständigen Akkus für Smartphones 

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).

Beispiele:

  • Die Anforderungen an die klinischen Tests eines neuen Medikaments werden bereits während der Konzeptphase des Projektes festgelegt. 
  • Beim Ausbau des Klärwerkes wird so früh wie nur eben möglich festgelegt, welcher Typ Pumpe beschafft werden soll, da es sich um eine Spezialanfertigung mit sehr langer Lieferzeit handelt.

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. 

Beispiel: Die Anforderungen für die konkrete Gestaltung der Filterfunktion auf einer Online-Shop-Seite werden erst kurz vor dem Moment festgelegt, in dem die Funktion umgesetzt werden soll. Dadurch ist die Filterfunktion ideal an die Produktpalette angepasst, welche erst kurz zuvor nach umfangreichen Marktanalysen definiert werden konnte.

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.

Beispiel: Ein Kunde will ein Fertighaus ohne komplizierte Sonderwünsche bei einem erfahrenen Anbieter bestellen. Der Anbieter kann bereits von Beginn an die Anforderungen festzurren und kann so eine solide Kostenschätzung abgeben.

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. 

Beispiel:

  • Zu frühe Definition der Anforderungn: In einem Spezifikationsdokument wird detailliert die Ausgestaltung des Bestellprozesses in einem Online-Shop mit Paypal beschrieben. Dieses Dokument muss aufgrund sich im Verlauf des Projektes immer wieder ändernder Schnittstellen immer wieder aufwändig überarbeitet werden. 
  • Agil: Die Spezifikationen zum Bestellprozess werden erst spät mit dem Kunden ausgearbeitet und können so mit der Implementierung der Schnittstellen abgestimmt werden.

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!