Der Begriff der Work-Breakdown-Structure (WBS bzw. PSP für Projektstrukturplan lt. PMA-Terminologie) ist den meisten ProjektleiterInnen bekannt und dank den Möglichkeiten der PM-Planungs-Software wird auch rasch versucht eine erste WBS zu erstellen und mit dem Team gemeinsam dann zu verfeinern.
Fast nie habe ich aber die Erstellung einer eigenen Product-Breakdown-Structure (PBS bzw. OSP für Objektstrukturplan lt. PMA-Terminologie) erlebt – und möchte mit diesem Artikel daher Lobying für die PBS machen und Missverständnissen zwischen PMs unterschiedlicher „PM-Schulen“ ausräumen.
Aus der PRINCE2-Definition „A Project Product is broken down into the major products which in turn are broken down into further products to give a hierarchical overview. This is called a Product Breakdown Structure (PBS).„
Das Ziel der PBS ist es also, all die vom Projekt zu erstellenden Arbeitsergebnisse (aka „Deliverables“ bzw. „Objekte“) festzuhalten – damit es am Ende des Projektes nicht zu Überraschungen samt Mehrkosten und Verzögerungen bei der Fertigstellung / Abnahme kommt.
Analog zur WBS (wo die notwendige Arbeits-Pakete strukturiert und vom großen Ganzen ausgehend aufgedröselt werden) wird bei der PBS das Gesamt-Produkt strukturiert und in klar beschreibbare Deliverables aufgeteilt. Der englische Begriff „… Breakdown-Structure“ beschreibt die Vorgehensweise sehr gut – das deutsche Wort „Dekomposition“ ist dafür recht sperrig – das Verb „aufdröseln“ aber sogar als umgangssprachlich im Duden aufgenommen.
Die grobe Strukturierung der PBS kann anfangs schon auch alleine vom Projektleiter begonnen werden – aber benötigt zur Finalisierung sicherlich die SpezialistInnen des Teams und vor allem auch den Auftraggeber. Im Vertrag oder Projekt-Auftrag etc wird man nämlich nicht alles finden – und je früher klar ist, wer letztendlich für die Abnahme der einzelnen Deliverables zuständig ist, desto besser kann auch das Projektmarketing dazu erfolgen. Bitte also bei der Stakeholder-Analyse bzw. Projektumweltanalyse schon danach die Augen offen halten – das zahlt sich am Ende des Projektes dann aus.
Das Aufdröseln kann man natürlich mit Papier und Bleistift, am Flipchart mit Post-Its oder mit der OrgChart-Funktion von Präsentations-Software machen – meine Empfehlung ist aber stattdessen die Darstellung als Baum-Struktur oder Fishbone-Diagramm in einem Mindmapping-Tool zu verwenden. Dort kann man dann auch einfach Symbole zum Fertigstellungs-Grad von Deliverables und/oder farblichen Markierung von Problem-Bereichen hinzufügen. In manchen Mindmap-Tools kann man die numerische Struktur (1, 1.1, 1.2, … 1.1.1, 1.1.2, …..) auch automatisiert hinzufügen lassen – damit kann man sich einiges an Zeit ersparen…
Ob man dann genau diese numerische Struktur als Fertigstellungs-Milestone ins GANTT-Chart übernimmt, oder den Namen eines Deliverables angibt, ist Geschmackssache – meine Empfehlung ist aber auf alle Fälle solche „xyz completed“-Milestones anzugeben, weil damit am einfachsten die Verbindung zwischen PBS und WBS hergestellt werden kann.
Damit stellt sich natürlich sofort die Frage, ob zuerst die WBS angegangen werden soll – oder doch besser die PBS. Hier vertraue ich dem Grundsatz, dass man zuerst wissen muss, was man machen soll, bevor man sich überlegen kann, wie man das tut. Also ist für mich die PBS die Basis für die Erarbeitung der WBS – im jeweils ähnlichen Detaillierungs-Grad. (von der Idee, dass man ein Projekt am Anfang am Reisbrett bis ins letzte Detail planen kann, ist man ja Gott-sei-Dank schon länger abgekommen)
Neben der grundlegenden Funktion als Basis für das „Wie“ und als Werkzeug zur Dokumentation des Fortschritts aus der Perspektive des Auftraggebers gibt es für mich einen dritten wichtigen Grund Zeit und Hirnschmalz in die PBS zu investieren: letztendlich sind die Endknoten der PBS die vom Projekt zu erstellenden Deliverables (aka Lieferobjekte) zu denen jeweils Abnahme-Kriterien festgelegt werden müssen. Nichts ist schlimmer als dann bei der Abnahme zu hören, dass das fertige Lieferobjekt nicht den Erwartungen entspricht – ohne als Projektleiter mit etwas Handfestem (eben die vereinbarten Abnahme-Kriterien) dagegen argumentieren zu können.
>> Wie geht es Euch damit ? Wie sind Eure Erfahrungen ? (die „Kommentar-Funktion“ auf www.goebl-projects.at ist deaktiviert – bitte gebt Eure Anmerkungen oder gerne auch Widersprüche in XING oder LinkedIn ein – dort sind sie auch für andere dann sichtbarer..)
P.S.: PMI weicht hier übrigens von PRINCE2 und PMA ab. Bei PMI packt man auch das Aufdröseln des „Produktes“ in die WBS – siehe Link , plant dann die Workpackages zu den Deliverables und erstellt aus den Workpackages dann den Zeitplan. Dagegen kann man nicht viel einwenden – schade aber, dass dadurch Missverständnissen zwischen PMs aus unterschiedlichen „PM-Schulen“ Tür und Tor geöffnet ist.
Weiterführende Links: