Agile WBS

Die „Work Breakdown Structure“ (WBS), zu Deutsch Projektstrukturplan, gehört zu den klassischen Werkzeugen im Projektmanagement. Das zugrundeliegende Konzept entstand bereits vor gut 40 Jahren. Doch noch immer scheinen in vielen Augen große Fragezeichen auf, wenn das Kürzel erwähnt wird. Besonders in agilen Projekten ist die WBS ein seltener Gast. In welchen Projekttypen kann das WBS-Konzept eingesetzt werden? Ein kleiner Ausflug in die Welt des Projektcontrollings.

Die WBS wurde 1964 zum ersten Mal ausführlich behandelt („PERT Implementation Manual“ der US-Regierung), aufbauend auf dem zwei Jahre zuvor vom US-Verteidigungsministerium entworfenen Planungssystem „PERT“ („NASA DoD Guide to PERT cost“). Die WBS bildet bis heute einen wichtigen Grundstein des Projektmanagementsystems des US-Militärs. Es überrascht daher nicht, dass die WBS insbesondere in den USA große Popularität genießt. Im PMBoK, dem „Project Management Body of Knowledge“ des Project Management Institute (PMI), wird die WBS als eine der wesentlichen Praktiken betont. Auch in anderen Standards, wie z. B. im CMMI-Modell des Software Engineering Institute (SEI), wird die WBS als ein selbstverständliches Konzept empfohlen.

Die WBS basiert auf dem Dekompositionsprinzip. Wenn ein Produkt so komplex ist, dass sein Herstellungsprozess nicht „am Stück“ geplant und kontrolliert werden kann, muss es in kleinere, leichter handhabbare Komponenten zerlegt werden. Dies ist praktisch bei allen modernen Systemen und Softwareprodukten der Fall. Jede einzelne Komponente wird dann nach einem „Masterplan“ bewertet, geplant, entwickelt und ausgeliefert. Im deutschen Sprachraum hat sich der Begriff eines „Arbeitspakets“ etabliert, der mit der WBS gut harmoniert. Eine WBS enthält genau die Menge aller Arbeitspakete, die realisiert werden müssen, damit ein Projekt erfolgreich abgeschlossen werden kann. Dies bedeutet auf Projektneudeutsch: Die WBS legt den Scope (Projektumfang) fest.

Die folgende Abbildung zeigt die stark vereinfachte WBS eines Hardwaremigrationsprojekts und veranschaulicht zugleich das simple WBS-Prinzip:

Eine derart allgemein gehaltene WBS wird als „Top Level WBS“ bezeichnet. Sie enthält lediglich zwei Ebenen und dient dazu, die grundsätzliche Richtung der Dekomposition vorzugeben, ohne einzelne Arbeitspakete zu nennen. Trotzdem stellt sich bereits die Frage nach der Klassifikation der Arbeitspakete. Sollte man lieber aufgaben- bzw. prozessorientiert („Projektmanagement“) oder ergebnisorientiert („Rechner“, „Netzwerk“) vorgehen? Eine gute Lösung liegt in den meisten Fällen darin, Aktivitäten und Prozesse nur als Gliederungshilfe zu verwenden und die resultierenden Ergebnisse als Blätter zu organisieren. Bei Aufgaben, die kontinuierlich anfallen und viele kleine statt wenige große Resultate liefern, empfiehlt sich zudem pragmatisch zu bleiben und eine Tätigkeit als WBS-Blatt zuzulassen. Dies stellt in Bereichen wie Projekt- oder Konfigurationsmanagement eine gute Lösung dar:

Zu den Vorteilen dieser Vorgehensweise gehört die Möglichkeit, „Streuverluste“ explizit zu erfassen, die andernfalls im Projektalltag „versickern“. Sie werden häufig als „Linienaufgaben“ gebucht, was die tatsächlichen Projektkosten verschleiern kann.

Es gibt weitergehende Techniken bei der Gestaltung einer WBS-Struktur, auf die hier nicht weiter eingegangen wird, etwa eine Festlegung der Ebenentypen (z. B.: Zweite Ebene beinhaltet Prozesse, dritte Ebene Ergebnisse). Eine WBS kann außerdem recht umfangreich werden, daher erhalten WBS-Elemente einen eindeutigen Code, wie in der obigen Abbildung dargestellt. Diese Codes sind eindeutig, verändern sich nicht im Laufe des Projekts und können als Schnittstelle zum Rechnungswesen Verwendung finden. Außerdem müssen in jedem Fall weitere Regeln beachtet werden. Beispielsweise dürfen sich die WBS-Pakete inhaltlich nicht überschneiden und müssen zu genau einem übergeordneten Paket gehören (außer dem Wurzelpaket) etc. Diese und weitere Regeln und Tipps sind im Standardwerk „Practice Standards for Work Breakdown Structures“ des PMI nachzulesen.

Eine so gestaltete WBS stellt ein praktisches Werkzeug dar, mit dem Projektmanager sowohl die Planungs- als auch die Ausführungsphase meistern können. Dafür wird die WBS in einer frühen Phase des Projektlebenszyklus erstellt und spielt im weiteren Projektverlauf eine zentrale Rolle.

Stark abgekürzt gestaltet sich der Einsatz der WBS in der klassischen Projektmanagementwelt wie folgt: Auf der Grundlage der vollständigen WBS, die durch eine ordentliche Beschreibung der einzelnen Pakete ergänzt wird („WBS Dictionary“), wird zunächst eine Aufwandsschätzung durchgeführt. Diese liefert Daten für die Ressourcen- und Zeitplanung, die meist als Gantt-Diagramm visualisiert wird, z. B. mit MS Project. Da dieser Planungsstand eine wichtige Grundlage für die Projektgenehmigung bildet, wird er als Baseline eingefroren. Diese Baseline kann nur im Rahmen eines streng sanktionierten Änderungsprozesses modifiziert werden (sprich: Eine neue Baseline wird gültig, die bisherige ungültig). Sie definiert den vollständigen, genehmigten Projektumfang (Scope) und ermöglicht eine darauf aufbauende systematische Kosten- und Fortschrittskontrolle.

Ein klassisches Instrument für die WBS-basierte Projektüberwachung ist das von dem Department of Defense (DoD) entwickelte „Earned Value Management“ (EVM), das als „Management des Fertigstellungswerts“ übersetzt werden könnte. Hierbei werden die WBS-Pakete über die gesamte Dauer eines Projekts unter Berücksichtigung von Ressourceneinschränkungen verteilt, womit sich die voraussichtliche Reihenfolge und die Lieferzeitpunkte der WBS-Pakete ergeben. Der zeitliche Verlauf heißt „Planned Value“ (PV). Im Verlauf des Projekts werden der Fertigstellungswert („Earned Value“, EV) und die tatsächlichen Kosten („Actual Cost“, AC) mit dem PV-Verlauf verglichen.

Mit dieser Technik können Risiken (z. B. Gefährdung des Liefertermins) frühzeitig erkannt werden. Das EVM stellt eine Grundlage für eine Vielzahl hilfreicher Metriken dar, wie Schedule Variance (SV, Planabweichung) Schedule Performance Index (SPI, Terminentwicklungsindex), oder einfach zu berechnende Prognosen, wie zum Beispiel EAC (Estimate at Completion, erwartete Gesamtkosten zum aktuellen Zeitpunkt).

Ohne nun auf weitere Details dieser Metriken einzugehen, soll nicht unerwähnt bleiben, dass sich dieses Projektcontrollingsystem in zahlreichen Projekten gut bewährt hat und inzwischen weltweit anerkannt ist. Das EVM und damit einhergehend die WBS-Methodik sind vor allem in den USA so weit verbreitet, dass ihre Beherrschung für Zulieferer großer Konzerne als zwingende Voraussetzung für die Zulassung zu Ausschreibungsverfahren genannt wird.

Quadratur des Kreises: agiles Projektcontrolling

Trotz der Popularität der WBS/EVM-Methodik in typischen Großprojekten wird es von manchen Anhängern der agilen Methodologie skeptisch beäugt. Ist es möglich, ein derart stringentes Projektcontrolling zu betreiben?

Es gibt eine Vielzahl agiler Projektmanagementtechniken, die in der Praxis Verbreitung gefunden haben, z. B. FDD (Feature Driven Development), Scrum oder Extreme Programming. Da Scrum eine vergleichsweise stringente Systematik enthält, soll es im Folgenden stellvertretend für die Familie agiler Methodiken betrachtet werden.

Scrum-Projekte sind stark iterativ strukturiert und werden strikt anforderungsgetrieben abgewickelt. Das klassische Lastenheft wird durch den Product Backlog ersetzt. Iterationen heißen bei Scrum „Sprints“. In jedem Sprint wird ein Teil des Product Backlog umgesetzt (Sprint Backlog). Jeder Sprint bildet einen kompletten Entwicklungszyklus, bestehend aus Planung des Sprint Backlogs, Umsetzung der Anforderungen, Qualitätssicherung und Abnahme des Ergebnisses. Der Fortschritt des Projekts wird mithilfe des Burn-down-Charts verfolgt. Eine lineare Abarbeitung der Aufwände wird in Scrum explizit empfohlen.

Interessant ist bei Scrum der Wegfall der Projektmanagerfunktion. Stattdessen werden die meisten Managementaufgaben vom Product Owner übernommen. Die Prozessqualitätssicherung, das Coaching und einige Organisationsaufgaben übernimmt der Scrum Master. Die Entwickler sind nach Scrum ein weitgehend sich selbst organisierendes Team. Weitere Rollen werden nicht explizit gefordert.

Während einige Scrum-Aspekte einem „alten Hasen“ ungewohnt vorkommen mögen, liegen die beiden Welten bei einer näheren Betrachtung nicht so weit auseinander. Zum einen wäre der im Scrum festgeschriebene Product Backlog als eine stark vereinfachte Form der WBS anzusehen. Allerdings werden hierbei Verwaltungsaufwände (z. B. die Arbeit des Scrum Masters) nicht als separate Arbeitspakete erfasst, so dass der Koordinationsaufwand in einem Projekt nicht einfach zu messen ist. Zugleich könnte man jedoch argumentieren, dass die Product-Backlog-Einträge implizit alle für die Realisierung erforderlichen Aktivitäten beinhalten, daher ist auch die Aufwandsschätzung vollständig. Auf diese sehr pragmatische Weise kann die Frage des Scope-Managements gelöst werden. Eine vollständige WBS definiert den Umfang eines klassischen Projekts. In einem Scrum-Projekt kann der Product Backlog am Anfang des ersten Sprints als Festlegung des Projektumfangs dienen.

Nun könnte man die in Abbildung 4 dargestellte Idee an die Scrum-Methodologie anpassen. Die geplante Backlog-Umsetzungslinie (Summe aller Sprint Burndown Charts, dargestellt relativ zu allen Requirements)

Passt man die klassischen Messgrößen wie SPI (Schedule Performance Index) und CPI (Cost Performance Index) an diese Vorgehensweise entsprechend an (von absoluten zu relativen Größen), erhält man plausible Kennzahlen. Somit steht eine vereinfachte, aber wirksame Projektcontrollingmethode zur Verfügung, die in agilen Projekten einsetzbar ist.

Zusätzlich zu beachten wären noch weitere Aspekte, die ein agiles von einem klassisch gemanagten Projekt unterscheiden. Dies bei einer genauen Betrachtung der Kernaussagen des „Manifesto for Agile Software Development“,  an dem sich agile Methodologien orientieren. Das Manifest postuliert im englischen Wortlaut folgende Prinzipien:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Die beiden letzten Punkte sind besonders interessant, denn sie verdeutlichen, dass das traditionelle, strenge Scope-Management in agilen Projekten infrage gestellt wird. Dagegen bildet eine stringente Handhabung des Projekt-Scopes in der traditionellen Projektwelt ein unumstößliches Axiom. Prinzipiell stellt dies jedoch kein unlösbares Problem dar. Fasst man nämlich den Change-Management-Prozess etwas flexibler (also: agiler) auf, kann die Scope-Verwaltung in einer kontrollierten Art und Weise erfolgen.

Fazit

Ob man nun die umfangreiche WBS-Methodik des DoD mit all ihren Regeln und eine schwergewichtige EVM-Vorgehensweise wählen oder sich für eine agile Version entscheiden sollte, hängt von der Art des Projekts ab. In einem Webentwicklungsprojekt etwa könnte die zweite Variante einfach kostengünstiger sein. Bei der Entwicklung kritischer Systeme wie in der Raumfahrt oder im Rüstungsbereich und ab einer bestimmten Budgetgrößenordnung ist das bewährte WBS/EVM-Vorgehen die bessere Wahl.

In jedem Fall ist man als Budgetverantwortlicher gut beraten, auch bei agilen Projekten verlässliche Kennzahlen zu definieren, damit das Risikomanagement nicht auf der Strecke bleibt. Das erfordert eine besondere Auslegung der traditionellen Controlling-Standards wie EVM im Kontext einer agilen Vorgehensweise. Bei einer geschickten Prozessgestaltung ist es möglich, Vorteile agiler Methodiken mit Vorzügen erprobter Standards erfolgreich zu kombinieren.