Work Breakdown Structure (WBS) / Projektstrukturplan

Neben der Project Charter ist eine WBS (im Deutschen “Projektstrukturplan” und auch als PSP abgekürzt) ein weiterer wesentlicher Bestandteil des Projektmanagements. In der PMBOK-Definition ist eine WBS

[e]ine an Liefergegenständen orientierte hierarchische Strukturierung der durch das Projektteam auszuführenden Arbeit, um die Projektziele zu erfüllen und die erforderlichen Liefergegenstände zu erstellen (PMBOK, S. 373).

Auch wenn es abstrakt klingt, so ist eine WBS kein bürokratischer Overhead, den Projektmanager erfunden haben, um sich selbst eine Existenzberechtigung zu geben. Das Projekt wird dabei in einzelne Bestandteile heruntergebrochen, und diese Bestandteile werden weiter heruntergebrochen, so dass eine Hierarchie entsteht.

wbs.jpg

Ganz oben ist der Projektname. Darunter wird das Projekt heruntergebrochen, wobei es verschiedene Ansätze gibt:

  • Phasen-orientiert, d.h. bei einem Softwareprojekt zum Beispiel Initialisierung, Planung, Durchführung, Testing und Closing
  • Deliverable-orientiert, bei einem Softwareprojekt zum Beispiel Front End, Middleware und Backend.

Der Deliverable-orientierte Ansatz ist der “reine” Ansatz, wenn man das so nennen will, aber auch der andere Ansatz kann gut funktionieren. Welcher Ansatz auch gewählt wird, darunter werden die Deliverables weiter runtergebrochen, der Teil “Front End” zum Beispiel in Design, Designabnahme durch den Kunden, Front End Coding, Front End Verbindung mit der Middleware und so weiter. Diese Punkte werden dann noch weiter heruntergebrochen, zum Beispiel kann das Front End Coding noch weiter herunter gebrochen werden in die einzelnen Teile des Front Ends wie Homepage, Hilfeseiten, Produktseiten, Shop etc. Das Ziel ist, dass man Deliverables erhält, die man einfacher managen kann.

Wenn ein Entwickler eine Abschätzung für die Entwicklung des Front Ends abgeben soll, so würde er innerlich wahrscheinlich überlegen, was er dafür alles tun müsste und eine Gesamtabschätzung abgeben, vielleicht 30 Arbeitstage. Das Problem dabei ist, dass er dem Projektmanager dann nach 30 Tagen sagen wird, dass er noch nicht fertig ist und noch weitere 10 Tage braucht; zum einen vielleicht deswegen, weil der Entwickler einige Komponenten bei der ersten Abschätzung vergessen hat, zum andern auch, weil etwas dazwischen gekommen ist. Wird aber für jedes einzelne Modul eine Abschätzung abgegeben, so merkt der Projektmanager viel früher, wenn es Verzögerungen gibt, zum Beispiel wenn das erste Modul bereits 3 Tage braucht anstatt 2 Tage. Gleichzeitig ist es weniger wahrscheinlich, dass Komponenten vergessen werden, wenn alles durchgesprochen und visualisiert wird.

Dabei sollte das Projekt natürlich nicht zu granular heruntergebrochen werden, denn das wäre wiederum nicht zu managen. Es gibt hierzu keine Faustregel, denn was für manche Projektmanager ein Projekt ist, ist für andere wiederum nur ein Arbeitspaket. So kann ein Webprojekt 3 Monate dauern, was bei einem Airbus-Projekt wiederum die Dauer eines Arbeitspaketes sein kann. Ich habe unterschiedliche Faustregeln gehört, und sie variieren zwischen 4 und 80 Stunden. Es hängt einfach von dem Projekt ab: Bei einem 4 Monate dauernden Projekt wäre es fatal, erst nach 2 Wochen zu erfahren, dass sich das 80 Stunden-Arbeitspaket verzögert, bei einem 3 Jahre dauernden Projekt ist es zwar auch schlimm, aber in Relation zur Projektdauer vielleicht noch zu kompensieren.

Die WBS wird zusammen mit dem Team erstellt. Das bringt gleich mehrere Vorteile: Zum einen kann ein Projektmanager in der Regel gar nicht wissen, was im Detail für ein Projekt getan werden muss, zum anderen bekommt das Projektteam ein besseres Verständnis davon, wie der eigene Projektteil in das große Ganze hineinpasst. Dadurch, dass das Team die WBS erstellt und die Projektdetails nicht diktiert bekommt, werden die Mitglieder auch besser in das Projekt eingebunden: Sie sind Teil der Erstellung des Projektplans, und in einem Team ist es weniger wahrscheinlich, dass Komponenten vergessen werden.

Eine WBS hat weitere Vorteile: Dadurch, dass die notwendige Arbeit visualisiert wird, kann den Stakeholdern vermittelt werden, warum ein Projekt so viele Ressourcen benötigt und so lange dauert (das sind die typischen Fragen). Gleichzeitig erlaubt die WBS eine bessere Kommunikation zwischen den Projektteammitgliedern. Und schließlich hilft die WBS auch im Scope Management: Alles, was in der WBS ist, ist Teil des Projekts. Alles, was nicht in der WBS ist, ist nicht Teil des Projekts. Scope Creep, also das Einschleichen von Features, kann so gleich zu Beginn verhindert werden.

Es gibt eine Reihe von Software-Tools, die die Erstellung einer WBS für MS Project ermöglichen, zum Beispiel WBS Chart Pro, das ich auf einem anderen Blog besprochen habe. Man benötigt aber nicht unbedingt Software dafür, eine WBS kann genau so gut auf einem Flip Chart oder simpel auf einem Blatt Papier erstellt werden. Für ein großes, professionelles Projekt wird das natürlich schnell schlecht handhabbar, insbesondere, wenn man mehrere Iterationen in der Erstellung einer WBS benötigt.

{ 1 Trackback }

Scrum: Die nächste Generation des Projektmanagements? | Projektmanagement: Definitionen, Einführungen und Vorlagen
11. Juli 2009 um 21:01

{ 0 Kommentare… erstellen Sie einen }