Unterscheiden sich traditionelles und agiles Projektmanagement wirklich so grundlegend? Diese Artikelserie beleuchtet verschiedene Aspekte genauer. Falls noch nicht gelesen, findest du die ersten beiden Teile hier:

Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 1)
Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 2) 

Dieser Artikel beschäftigt sich mit drei weiteren Aspekten im Projektmanagement, die eng mit den vorhergehenden verknüpft sind:

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

Vorgegebenes vs. adaptives Vorgehen

Erst die Bodenplatte, dann die Außenwände, das Dach, schließlich der Innenausbau: Der Bau eines Hauses folgt vorgegebenen Schritten. Ist das bei agilen Projekten auch so? Nun … vergleichen wir mal!

Klassisches Projektmanagement: 

Zu Beginn des Projektes wird ein Plan erstellt, der später befolgt wird. In den Plan fließen zwei Arten von Informationen ein:

  • Wissen, das bekannt und vorhersehbar ist
  • Annahmen über Unbekanntes, das vorausgesagt wird

Dieser Plan ist die Vorgabe für die Projektdurchführung. Läuft das Projekt, wird der Fortschritt daran gemessen, inwieweit er dem Plan entspricht. Basiert der Plan auf besonders vielen Annahmen über Unbekanntes, so besteht die Gefahr, dass der Plan später über den Haufen geworfen werden muss.

Beispiel A: In einem Online-Shop soll eine innovative Sprachsteuerung implementiert werden. Obwohl es (verständlicherweise) noch keine Erfahrung mit Sprachsteuerungen gibt und auch keine vergleichbaren Technologien existieren, werden nach bestem (Un-)Wissen Annahmen getroffen, „wie es vielleicht funktionieren könnte“. Es wird darauf basierend ein Plan erstellt, wann und vor allem wie die Sprachsteuerungsfunktion umgesetzt werden soll. Später stellt sich heraus, dass das gewählte Vorgehen nicht funktioniert und es muss von vorn begonnen werden und alles neu geplant werden. Ein klares Negativbeispiel!

Beispiel B: Nachdem der erfahrene Architekt in enger Absprache mit dem Bauherren das Gebäude detailliert geplant hat, erstellt die mit der Ausführung des Bauvorhabens beauftragte Firma einen Plan zur Umsetzung. Da viele Details bereits geklärt sind, können benötigte Materialien rechtzeitig bestellt werden und Personalkapazitäten frühzeitig eingeplant werden. Dem Bauherren ist klar, dass spätere prinzipielle Änderungen teuer werden können, daher „sitzt schon der erste Spatenstich an der richtigen Stelle“. Sofern keine größeren unvorhersehbaren Störungen eintreten (Unwetter, Lieferantenausfall usw.) wird das Bauvorhaben im angestrebten Zeitrahmen und innerhalb des geplanten Budgets abgeschlossen werden. Ein klares Positivbeispiel!

Eine Anmerkung aus der realen Welt: Es kommt leider immer wieder vor, dass bewusst zu knapp und sehr optimistisch geplant wird, z.B. um sich bei der Auftragsvergabe gegen einen Konkurrenten durchsetzen zu können. Erhebliche Verzögerungen und Kostenüberschreitungen sind die unausweichliche Folge. Das ist jedoch ein anderes Thema und kein Problem des klassischen Ansatzes an sich.

Agiles Projektmanagement: 

In agilen Projekten wird ein erkundender Ansatz gewählt. Das Motto: Wir versuchen nicht, Unsicheres vorauszusagen, sondern probieren aus und handeln entsprechend der Ergebnisse. 

Beispiel A: Dem Team ist zu Beginn unklar, ob und wie eine innovative Sprachsteuerung im Online-Shop möglich ist. Statt einen Plan mit Annahmen zu erstellen, werden kleine Funktionen und Umsetzungsvarianten getestet und basierend auf dem gewonnenen Wissen wird weiter vorgegangen. Nicht-funktionierende Ansätze werden so frühzeitig erkannt und gestoppt bzw. angepasst. Umfangreiche Programmierarbeit, die sich erst später als wertlos herausstellt, kann weitgehend vermieden werden. Ganz klar ein gutes Beispiel!

Beispiel B: Ein Bauherr erwirbt ein Grundstück und erteilt einer Firma den Auftrag für ein Villa-artiges Einfamilienhaus mit Pool. Statt sich lange mit den Planungen aufzuhalten, soll die Firma einfach loslegen und zeigen, was sie für Ideen hat. Während der Aushubarbeiten für das Fundament besichtigt der Bauherr die Baustelle und stellt fest, dass er den Pool lieber an der Südseite hätte und statt eines L-förmigen Grundrisses ein U bevorzugt. Teile des bereits riesigen Loches müssen wieder aufgefüllt werden und an anderer Stelle wird zusätzlich ausgehoben. Im weiteren Verlauf werden mehrfach Zwischenwände eingerissen, Türen zugemauert und neue Durchbrüche durch Betonelemente geschaffen. Badezimmer und Küche werden mehrfach verlegt, jedes Mal müssen Teile der Verrohrung neu verlegt werden. Nach vier Jahren Bauzeit, kurz vor dem Richtfest, hat der Bauherr ein Grundstück in noch besserer Lage gefunden. Zugegeben, abgesehen von Superreichen würde aus gutem Grund niemand auf diese Weise ein Haus bauen. Ein übertriebenes Negativbeispiel! Es veranschaulicht allerdings auf drastische Weise, wann ein adaptives Vorgehen unangebracht ist.

Anmerkung: Selbstverständlich hat ein agiles Vorgehen seinen Platz im Hausbau, allerdings vor allem in der Planungsphase mit dem Architekten. Dieser erstellt erste Skizzen und grobe Vorschläge, da der Bauherr zu Beginn noch gar nicht weiß, was er genau will. Diese ersten Ideen werden anschließend besprochen, verworfen oder angepasst und schließlich bis zum endgültigen Plan weiterentwickelt.

Vermeiden vs. Begrüßen von Änderungen

Kennst du auch diese Projekte, die vor dem Kunden vorgestellt werden und plötzlich kommt der gefürchtete „Das hab ich mir aber anders vorgestellt!“-Moment? Das passiert gar nicht so selten!

Kaum ein Projekt kommt ohne Änderungen aus. Ob Fehler, neue Erkenntnisse oder geänderte Anforderungen: In jeder Projektphase können Änderungswünsche auftreten. Werden diese spät bekannt – dann wird’s oft teuer!

Klassisches Projektmanagement: 

In traditionellen Projekten trifft man häufig auf diese zwei Ansätze, mit Änderungen umzugehen:

  • Sie werden stark reglementiert und kontrolliert: Ein bewährter Ansatz für Projekte in Umgebungen sehr harten äußeren Vorgaben und Richtlinien. Festgelegte Änderungs- und Dokumentationsprozesse stellen eine Hürde dar, die allzu leichtfertige Änderungen verhindern. Der damit verbundene hohe Aufwand lässt sich dadurch rechtfertigen, dass so die Einhaltung der externen Vorgaben und Richtlinien sichergestellt wird und eine Nachverfolgung jederzeit möglich ist. 
  • Sie werden soweit wie möglich vermieden: Dieser Ansatz kann extrem schädlich sein, wenn ein Produkt z.B. am Markt vorbei entwickelt wird. Werden Änderungen in solchen Fällen nicht akzeptiert, müssen Produkte im Nachgang häufig stark überarbeitet oder sogar verworfen werden. Daher gilt: Auch wenn in klassischen Projekten Änderungen weniger willkommen sind, müssen notwendige Änderungen so früh wie möglich vollzogen werden, um z.T. extreme Folgekosten zu vermeiden. Wie die Skizze verdeutlicht, steigen die Kosten für eine Änderung mit Fortschreiten des Projektes in der Regel erheblich.

Agiles Projektmanagement: 

In agilen Projekten werden Änderungen begrüßt und als normal angesehen. Die Grundannahme ist hier: Unsicherheiten und Unklarheiten in Projekten können nicht durch Annahmen ausgeräumt werden. Stattdessen wird ein empirischer Ansatz bevorzugt: Wissen und Erkenntnisse aus der aktuellen Arbeit fließen in die zukünftigen Aufgaben ein. 

Anforderungen, Konzepte und Tests werden erst dann erstellt, wenn sie benötigt werden. So wird vermieden, dass im Fall von Änderungen umfangreiche Projektbestandteile überarbeitet werden müssen.

Annahmen vs. Validieren

Eine Annahme ist eine Vorstellung oder Vermutung über etwas, das auf eine gewisse Art eintreten könnte, deren Gültigkeit aber noch nicht nachgewiesen ist. Im Projektmanagement wird unterschiedlich mit Annahmen umgegangen:

Klassisches Projektmanagement: 

In traditionellen Projekten basieren viele Anforderungen und Pläne zum Zeitpunkt ihrer Erstellung auf Annahmen. Manche dieser Annahmen werden eintreten, andere werden sich als falsch herausstellen und müssen daher später verworfen werden. Anforderungen und Pläne müssen dann ebenfalls angepasst werden.

Annahmen sind oft riskant, da sie bei Nichteintreten zu umfangreichen Änderungen und im Extremfall zum Abbruch von Projekten führen können. Im klassischen Projektmanagement leiten sich daher aus Annahmen häufig Risiken ab, die im Rahmen des Risikomanagements adressiert werden müssen.

Anmerkung: Im klassischen Projektmanagement fällt das Validieren einer kritischen Annahme häufig in den Bereich des Risikomanagements. Basiert z.B. der Großteil eines Technologieprojektes auf der Annahme, dass eine bestimmte elektronische Komponente auch im Dauereinsatz funktioniert, so tut der Projektleiter gut daran, diese Komponente frühzeitig im Projekt ausgiebig testen zu lassen – falls möglich sogar bereits vor dem eigentlichen Projektbeginn und vor der Detailplanung. 

Agiles Projektmanagement: 

Auch in agilen Projekten existieren Annahmen – doch diese werden so schnell wie möglich validiert. Gemäß des iterativen und inkrementellen Ansatzes werden Unklarheiten häufig mehr oder minder „automatisch“ so schnell wie möglich durch Überprüfung beseitigt. Auf diese Weise können Probleme oder Fehler schnell entdeckt werden. 

Fazit

Mittlerweile solltest du einen guten Überblick über Unterschiede zwischen den beiden Methodiken haben. Beide können ihre Stärken nur dann voll ausspielen, wenn sie auf jeweils passende Projektvorhaben angewendet werden. Doch wir sind noch nicht fertig – freu dich auf einen weiteren Teil!