Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 4)

Auf zur letzten Runde! In den ersten drei Artikeln dieser Serie hast du bereits eine gehörige Menge Unterschiede zwischen den beiden Projektmanagement-Methodiken kennengelernt:

Dieser Artikel ist Teil 4 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 erhältst du Informationen zu folgenden Themen:

• Kleine vs. große Aufgabenblöcke
• Orientierung an Plänen vs. nutzbaren Arbeitsfortschritten
• Wichtigkeit von Dokumenten vs. Auslieferung von Werten
• Viel vs. wenig Overhead

Kleine vs. große Aufgabenblöcke

Dieser Punkt bezieht sich auf Aufgabenblöcke, an deren Ende ein nutzbares Ergebnis steht – wenn etwas „fertig“ ist. Stell dir vor, du sollst in einem Haus zehn Räume renovieren. Was ist dir lieber:

• Erst in allen Räumen die Böden austauschen, dann in allen Räumen die Wände streichen usw.
• Oder stellst du lieber erst die Küche vollständig fertig, bis du zum nächsten Raum übergehst?

Hier liegen die Unterschiede zwischen klassisch und agil:

Klassisches Projektmanagement:

In traditionellen Projekten wird häufig in Phasen gedacht. Zuerst werden in allen Räumen die Böden ausgetauscht. Damit ist die Phase „Renovierung des Fußbodens“ abgeschlossen oder „fertig“. Es gibt jedoch am Ende der Phase keinen fertig-renovierten, nutzbaren Raum. Zwar können sich in traditionellen Projekten Phasen überlappen, doch in der Regel werden unterschiedliche, große Arbeitsblöcke zunächst vollständig bearbeitet, die sich erst spät im Projekt zu nutzbaren Ergebnissen zusammenfügen.

Je nach Aufgabe kann diese Vorgehensweise erhebliche Vorteile bieten, z. B. geringere Kosten (Skaleneffekte bei Stückkosten, Spezialressourcen müssen nicht über das gesamte Projekt reserviert werden, etc.). Andererseits werden oft erst relativ spät fertiggestellte, überprüfbare und nutzbare Einheiten erstellt.

Agiles Projektmanagement:

In agilen Projekten wird mit kleineren Aufgabenblöcken bzw. „Stückzahlen“ gearbeitet, die früh zu nutzbaren Ergebnissen oder überprüfbaren Prototypen führen. Im obigen Beispiel würde zum Beispiel zunächst die Küche teilweise fertiggestellt. Auch wenn neue der Herd und der Geschirrspüler erst in zwei Wochen geliefert und angeschlossen wird, ist die Küche dank Mikrowelle und bereits eingebautem Spülbecken bereits eingeschränkt nutzbar.

Überschaubare Aufgabenblöcke mit frühen, nutzbaren Ergebnissen haben folgende Vorteile:

• Kleinere Aufgabenblöcke können mit weniger Aufwand erledigt werden, wodurch sie schneller abgeschlossen werden.
• Es kann schneller Feedback eingeholt und eingearbeitet werden.
• Das Risiko von Fehlern und falschen Entscheidungen sinkt.
• Kleinere Aufgabenblöcke können einfacher verwaltet werden.
• Konzentration und Fokus auf die Aufgaben wird gestärkt.
• Fehler haben geringere Auswirkungen. Zeigt sich zum Beispiel, dass der Fußbodenbelag bei weitem nicht so haltbar ist wie angepriesen, und es zeigen sich bereits nach den ersten Tagen der Küchennutzung Kratzer und Schrammen, so kann für die übrigen Räume mit geringem Aufwand ein alternatives Bodenmaterial ausgewählt werden.

Nicht zu vergessen: Ein Team arbeitet oft deutlich motivierter, wenn eine überschaubare Anzahl von Arbeitsobjekten erledigt werden muss und wenn frühzeitig nutzbarer Mehrwert entsteht.

Orientierung an Plänen vs. nutzbaren Arbeitsfortschritten

Klar: In allen Projekten sollen Ergebnisse erreicht werden. Manche mögen meinen, hier unterscheiden sich traditionelles und agiles Projektmanagement nicht. Doch es gibt leicht unterschiedliche Sichtweise auf das Thema, wie der Fortschritt auf dem Weg zum gewünschten Ergebnis zu messen ist:

Klassisches Projektmanagement:

In traditionellen Projekten ist der Plan das maßgebliche Instrument zur Projektsteuerung. Zum Beginn des Projekts wird festgelegt, wann welche Arbeit auf welche Weise erledigt werden soll. Sobald das Projekt umgesetzt wird, werden regelmäßig Plan und Fortschritt verglichen. Abweichungen können entweder als Fehler gewertet werden oder eine Änderung des Plans zur Folge haben.

Der Fortschritt wird üblicherweise im Vergleich zum detaillierten Zeitplan beurteilt: Ein Projekt „liegt zeitlich im Plan“, „hinkt diesem hinterher“ oder „eilt diesem Plan voraus“.

Agiles Projektmanagement: 

In agilen Projekten wird davon ausgegangen, dass in langfristigen Plänen oft Details übersehen werden, was wiederum zu ständigen Anpassungen in Dokumenten und Plänen führt. Die Lösung: Die Arbeit wird wie oben beschrieben in kurzen und überschaubaren Abschnitten organisiert. In jedem dieser Abschnitte sollen bestimmte Arbeitsergebnisse erzielt werden.

Am Zuwachs überprüfbarer und nutzbarer Ergebnisse wird der eigentliche Fortschritt gemessen.

Wichtigkeit von Dokumenten vs. Auslieferung von Werten

Dieser Punkt geht direkt auf einen Vorwurf zurück, den glühende Verfechter von agilen Methodiken häufig gegenüber den klassischen Methoden anführen: Dem Erschaffen von Dokumenten wie Anforderungskatalogen, Plänen und Protokollen würde im traditionellen Projektmanagement ein (zu) großer Wert beigemessen. Doch worauf geht dieser Vorwurf zurück?

Klassisches Projektmanagement:

Im sequentiellen Vorgehen steht die Integration einzelner Komponenten und die Auslieferung oft am Ende des Projekts.

Dies birgt folgende Gefahr: Termine und Budget werden mitunter eng und ohne Ausweitung des Projekts können nicht alle wichtigen Ergebnisse geliefert werden. Der detaillierte Plan für alle nicht mehr umgesetzten Inhalte wurde mit viel Aufwand bereits zu Beginn des Projektes erzeugt, hat aber keinerlei Wert für das Ergebnis des Projektes.

Beispiel: In einem Software-Projekt existieren zwar ausführliche Anforderungskataloge, am Ende der geplanten Projektlaufzeit konnten jedoch aus Zeitmangel nicht alle Funktionen vollständig integriert ausgeliefert werden.

Agiles Projektmanagement:

Der Wert für den Kunden steht in agilen Projekten im Mittelpunkt: Anforderungskataloge und Designs gelten nicht als werthaltiges Projektergebnis, sondern als Mittel zum Zweck, um den eigentlichen Kundenwert zu erschaffen.

Ziel ist es somit, in regelmäßigen Abständen vollständige Komponenten oder Teilfunktionen zu liefern, die vom Kunden nutzbar sind.

Beispiel: In einem Software-Projekt wurden nur Anforderungen für eine Teilkomponente ausführlich definiert. Diese Komponente wird vollständig ausgeliefert und stellt für den Kunden einen nutzbaren Wert dar.

Die beiden Beispiele zeigen: Dieser Vergleich kommt vor allem aus den Erfahrungen der Softwareentwicklung mit ihren schnell wechselnden und kleinteiligen Anforderungen, getrieben vom Markt, von der starken Konfigurierbarkeit des gewünschten Ergebnisses und so manches Mal sogar vom unberechenbaren Kunden, der selbst oft erst während des Projektes lernt, was er wirklich benötigt.

Viel vs. wenig Overhead

Zugegeben … dieser Abschnitt kann kontrovers diskutiert werden. Oftmals schreiben sich Verfechter der agilen Methoden eine leichtgewichtigen Prozess ohne Overhead auf die Fahnen. Wer jedoch schon einmal in einer vollständigen Scrum-Implementierung gearbeitet hat, wird auch dort auf einen erheblichen Anteil an Prozessen und Ereignissen stoßen. Rollen sind streng und kompromisslos festgelegt.

Klassisches Projektmanagement:

In vielen traditionellen Projekten wird Wert auf definierte Prozesse und Dokumentation gelegt. Was für das eine Projekt genau richtig ist, wird für das andere übertrieben und überbürokratisch sein. So entstehen immer wieder Vorbehalte gegen das klassische Projektmanagement, weil zu viel Ballast erschaffen wird, der das Projektergebnis nicht verbessert. Sobald unnötige Formalitäten nur noch um des Prozesses willen erstellt werden müssen, schießt Projektmanagement am Ziel vorbei.

Doch das muss nicht so sein: Ein sinnvolles und effizientes Vorgehen findet auch im klassischen Projektmanagement immer genau das Maß an Bürokratie, das für das jeweilige Projekt notwendig ist.

Agiles Projektmanagement:

Unnötige Formalitäten sind in agilen Projekten so weit wie möglich eliminiert. Trotzdem wird in keiner Weise komplett auf Planung und Dokumentation verzichtet. Die Planung erfolgt jedoch im Vergleich eher „auf Sicht“ und auch die Dokumentation folgt dem Leitsatz „So viel wie nötig, so wenig wie möglich“. Wichtig ist immer die Frage, ob das jeweilige Dokument einen Wert hat, wirtschaftlich vertretbar ist oder die Qualität verbessert.

Beispiele:

• Eine Benutzerdokumentation wird dann erstellt, wenn sie Teil des auslieferbaren Produkts ist.
• Protokolle werden dann verfasst, wenn Entscheidungen später nachvollzogen werden sollen.
• Nur weil es im Unternehmen so üblich ist, wird noch lange kein mehrtägiger Workshop durchgeführt, wenn das Projekt für diesen Workshop zu klein ist.

Die Kernfrage ist immer: Schafft unser Vorgehen einen Wert für das Endprodukt und für den Kunden?

Fassen wir es wie folgt zusammen: In agilen Ansätzen ist ein möglichst kleiner Overhead fester Teil der Philosophie. Allerdings sollte sich jedes Projekt – egal ob agil oder nicht – am „Lean“-Ansatz orientieren: Nicht so viel wie möglich, sondern so viel wie nötig, um werthaltige Ergebnisse zu erreichen.

Fazit

Voilà! Herzlichen Glückwunsch! Nach dem Lesen aller vier Artikel dieser Serie hast du einen guten Überblick über die Unterschiede zwischen traditionellem und agilem Projektmanagement. Anhand der Beispiele hast du sicher bemerkt, dass sich die beiden Ansätze für unterschiedliche Aufgabenstellungen unterschiedlich gut eignen. Welche Methodik am besten für ein bestimmtes Vorhaben geeignet ist, wird in manchen Fällen leicht zu entscheiden sein. In anderen ist es weniger eindeutig oder aber die Wahl hängt von der jeweiligen Phase ab, in der sich das Vorhaben befindet.