#7 Projektarbeit strukturieren – WBS / Projektstrukturplan

Damit du für dein Projekt optimal versorgt bist, geht es heute um den Projektstrukturplan. Doch zuerst stellen wir uns die Frage:
Wofür wirst du als Projektmanager:in in egal welchem Projekt angeschaut? Wie wirst du bewertet?
Ich sehe hier zwei Kriterien: Einerseits ist es deine Aufgabe, die Arbeit in deinem Team zu strukturieren und andererseits muss der Zeitplan sitzen und aufs Team abgestimmt sein. Das ist der absolute Kern.

Wir werfen heute also einen Blick darauf,

1. … wie du eine geeignete Form der Strukturierung deines Projekts findest.
2. … wie du die Projektarbeitauf einzelne Arbeitspakete herunter brichst.
3. … und ab wann du getrost aufhören kannst, immer noch kleinere Arbeitspakete zu schnüren – damit du nicht wahnsinnig wirst und dich nicht im Kleinklein verlierst.

Starten wir mal mit dem Titel dieser Folge bzw. dieses Artikels. Da liest du WBS – dahinter steckt das etwas sperrig klingende Wortkonstrukt ,Work Breakdown Structure‘. Also ,Arbeitspaketstruktur‘ oder der offizielle deutsche Begriff ,Projektstrukturplan‘.

Was ist ein Projektstrukturplan?

Solltest du in der Produktentwicklung unterwegs sein, kennst du mitunter die Product Breakdown Structure, PBS. Klingt so ähnlich und wie du gleich sehen wirst, können wir uns das zu Nutze machen.

Die Produktstruktur oder Produktarchitektur beschreibt, aus welchen Komponenten und Systemen sich ein Produkt zusammensetzt.

Zur besseren Veranschaulichung ziehen wir uns jetzt ein Smartphone als Projektstrukturplan Beispiel heran.

• Auch wenn ein iPhone beispielsweise ein ziemlicher Monolith ist, in den du selbst nicht mal mehr eine Simkarte oder Speicherkarte einbauen kannst, setzt sich das Gerät aus verschiedenen Komponenten zusammen. Display, Akku, Kamera vorne, Kamera hinten, Mikrofon, Ladebuchse usw. Beim Fairphone, einer recht kleinen Handymarke, die in Insider- und Nachhaltigkeits-Kreisen sehr beliebt ist, sieht man das alles noch sehr schön – da kannst du diese Komponenten nämlich selbst aus- und einbauen. [Unbezahlte sowie unbeauftragte Werbung für Handymarken.]
• Neben dieser Hardware – fällt dir noch mehr zum Aufbau des Produktes ein? Nun, für den Verkäufer, sagen wir also Apple, ist da noch lange nicht das gesamte Produkt. Denk mal an das Zubehör. Was bekommst du da in der Regel?
• Genau, ein Ladekabel und gegebenenfalls auch Kopfhörer.
• Doch das ist auch noch nicht alles. Das Ganze kommt in einer Umverpackung – in diesem Karton ist noch allerhand Papierkram, den man meistens nicht groß liest. Und vielleicht auch noch eine Schutzfolie oder Schutzhülle.
• Jetzt haben wir alles, was man anfassen kann, beschrieben. Doch klar, da gibt es noch die Software, das iOS oder Android. Auch das ist ein Teil des Produkts, der bei der Entwicklung ganz sicher von ganz anderen Abteilungen mit anderem Know-How bearbeitet werden muss.
• Aus Herstellersicht hört es auch da oft noch nicht auf. Zusätzlich zum kleinen Karton, der Handy-Schachtel, braucht es dann noch eine transportfeste Umverpackung und oftmals Folie, um das alles auf der Palette während des Transports stabil und unkaputtbar zu halten und so weiter.

Wir sehen also: Von der Herstellung bis das Handy beim Kunden ankommt sind so einige Dingen zu beachten.

Arbeitspakete reduzieren Komplexität

Warum erzähle ich das, wenn es uns doch um Projekte geht? Und Projekte mitunter auch gar nix mit einem Produkt zu tun haben können. Ein Produkt zu entwickeln kann genauso ein Projekte sein, wie eine neue Produktionslinie ins Werk zu stellen oder einen Prozess zu optimieren. Oder zwei Organisationseinheiten zusammenzulegen. Oder eine Marketingkampagne. Oder ein Event.

Doch was haben alle gemeinsam? Dass du versuchen wirst den Elefanten, dein Projekt, in Scheiben zu schneiden und in Tätigkeiten oder managbare Arbeitspakete zu zerlegen. Das lässt sich schlichtweg leichter aufteilen als zu sagen: „Hier, bau mal ein Handy, ich kümmere mich um den ganzen Rest.“ Kann man machen, wird bei etwas größeren Unterfangen aber irgendwie der Sache nicht gerecht. Wahrscheinlich passiert dann nämlich erst mal gar nix. Denn: Wo soll man anfangen?

Und da sind wir bei einem wichtigen, weiteren Punkt: warum es so wichtig ist, die Arbeit strukturiert zu zerlegen. Denn hast du das erst einmal getan, ist die Komplexität reduziert und du erkennst viel leichter die logischen Abhängigkeiten und kannst bestimmen, womit angefangen werden soll, was parallel abgearbeitet werden kann und wo genau was wieder zusammen geführt werden muss.

Organigramm und 100% Regel

Und weil sich das am Beispiel der Produktstruktur so leicht abbilden und nachvollziehen lässt, ist das eine sehr gängige und beliebte Form, auch die WBS, also die Arbeitspaketstruktur abzubilden.

Dies geschieht in den meisten Fällen im Stile eines Organigramms, also hierarchisch. Da stehen dann ganz oben Smartphone und in Eben 2 Hardware, Software und Verpackung ganz oben. Hardware unterteilt sich dann noch einmal in Handy und Accessoires. Handy unterteilt sich dann in Display, Hülle, Kameras, Speicher usw. Kameras unterteilt sich dann noch einmal in Front und Rückseite usw. So entsteht eine Art Verästelung. Alles zusammen ergibt dann das fertige Endprodukt.

Und da sind wir bei einer ganz wichtigen Stelle angelangt:

Wenn du dein Projekt herunterbrichst und in logische Einheiten zerteilst, beachte die 100% Regel.

Die besagt, dass alle Komponenten je Ebene stets 100% ergeben müssen. Wie in einem Organigramm auch. Da sind einer Abteilung ja auch alle Mitarbeitenden eben dieser Abteilung zugeordnet. Keiner mehr, keine weniger.
Damit stellst du sicher, dass du nichts vergessen hast. Oder doppelt enthalten ist.

Achte beim Herunterbrechen also je Ebene in deinem Diagramm immer auf Vollständigkeit. Vollständigkeit, also die 100%, sind immer wichtiger als die Detailtiefe.

Bevor wir schauen, wie weit du den Spaß denn nun herunterbrechen sollst, beleuchten wir, welche Formen es außer der Produktstruktur noch gibt, um die Arbeit herunter zu brechen.

Fünf Arten von WBS

Es gibt eine ganze Menge an Wegen, um dein Projekt in kleinere Pakete aufzuteilen. Wenn du nicht ohnehin schon Stift und Zettel zur Hand hattest: Ab jetzt willst du dir wieder Notizen machen, um sie mit in dein Projekt zu nehmen.

Diese fünf Möglichkeiten, wie du deine Projekte strukturieren kannst, stelle ich dir vor:

1: Produktstruktur-orientiert
2: Phasen/Workstream-orientiert
3: Organisations-orientiert
4: Standort-orientiert
5: Sub-Projekt-orientiert

und 6: eine beliebige, geeignete Kombination aus 1 bis 5. Beispielsweise Sub-Projekt-orientiert auf der obersten Ebene und darunter in Phasen heruntergebrochen. Oder zunächst in Abteilungen, also Organisations-orientiert und in den Ebenen darunter wiederum Produkt-orientiert. Du entscheidest, was Sinn macht.

Also, wie kann eine WBS, ein Projektstrukturplan, aussehen?

1. So wie du das Projekt in Produkt-Komponenten zerlegen kannst, kannst du es auch in Phasen unterteilen.

Also beispielsweise in Bewertungsphase, Entwicklungsphase, Implementierungs- und Testphase, Markteinführungsphase. Schön daran ist, dass das schon eine zeitliche Einteilung vorweg nimmt. Kniffelig hier ist es aber, Arbeiten nicht doppelt aufzuführen. Soll heißen, du musst so präzise formulieren, was in welcher Phase zu tun ist, dass sich die Arbeit klar von anderen Phasen abgrenzt.

Deliverables sind deine Arbeitsergebnisse. Je Ebene und je Paket hast du also immer ein konkretes Resultat vor Augen. Die unterste Ebene deiner Struktur spuckt stets dieses Ergebnis aus. Die Überbegriffe in der Struktur darüber kannst du beliebig selbstredend wählen. Doch die unterste Ebene ist stets Deliverable-orientiert. Dann lassen sich auch die eigentlichen Arbeitspakete einfacher beschreiben. Wenn du möchtest, kannst du hierzu auch einen Blick auf Folge #4 werfen – darin formulieren wir im Zuge des Anforderungsmanagements ganz konkret, wie du gewünschte Ergebnisse und den Nutzen des (Teil-)Projekts für dein Team transparent formulierst.

Zurück zu den Projektphasen als zentrales Strukturelement. In der Bewertungsphase kommt wahrscheinlich so etwas wie ein Business Case heraus. Oder ein „Profit and Loss Sheet“, kurz P&L. Also eine Kosten-Nutzen-Rechnung. Vielleicht sogar ein noch nicht voll funktionsfähiger Prototyp. Oder ein digitaler Mockup – eine Attrappe, ein Modell. In der Entwicklungsphase kommt garantiert ein Sample, ein Muster heraus. In der Implementierung läuft das fertig vom Band bzw. wenn wir in Software denken, haben wir etwas funktionsfähiges vor uns. Am Ende der Testphase ist die auch von den meisten Bugs, Fehlern bereinigt. Und in der Markteinführung gibt es z.B. das fertige Produkt mit einem Preis-Tag und einem Volumenplan für die Fertigung und den Einkauf.

2. Eine weitere, sehr verbreitete Möglichkeit ist es nach Organisationseinheiten/Abteilungen vorzugehen. Das liegt nahe, denn der PSP ähnelt in seiner Erscheinungsform ja bereits einem Organigramm.
Was tragen also die verschiedenen Abteilungen bei? Marketing, Entwicklung, Qualitätsabteilung, Logistik, Customer Service? Sie alle tragen ihren Teil bei – und diese Aufteilung zu nutzen klingt einleuchtend, da die Arbeit in Unternehmen oft ohnehin bereits so strukturiert ist.

Hier muss du allerdings mit größter Vorsicht und Achtsamkeit vorgehen – denn eine strikte Aufteilung führt leider allzuoft zu ,Silo-Denken‘, d.h. dass jeder nur im Rahmen der Standardtätigkeiten in seiner Abteilung denkt. Da rutscht gerne mal was durch, es ergeben sich sehr viele Schnittstellen, die das Team langsamer werden lassen. Sind dabei Zuständigkeiten und Schnittstellen sauber definiert, passt sehr schnell vorne und hinten nix mehr zusammen. Das zu koordinieren und kompensieren wird dann plötzlich die eigentliche Herausforderung. Ich rate davon also prinzipiell ab, verstehe aber warum es auf den ersten Blick praktisch erscheint.

3. Viel eleganter ist es, stattdessen in Workstreams zu denken. Also in Phasen, wie bereits oben beschrieben. Nachteil daran ist jedoch, dass du stets ein strenges Auge darauf haben musst, unnötig doppelte Arbeitsschritte und ebenso zu kleine Iterationsschleifen zu vermeiden. In beiden Fällen ist die Gefahr groß, dass sich das Projekt aufgrund der vielen Schritte hinauszögert – und das möchtest du ja auf jeden Fall besser hinbekommen.

4. In globalen Konzernen oder auch bei EU-Förderprojekten wie bspw. bei der Raumfahrt, ist es üblich, das Projekt zunächst nach Standorten zu schneiden und dann je Standort tiefer zu legen. In einem Land findet dann die Entwicklung der Hardware bis zum Prototypenstatus statt, die Software wird ganz woanders entwickelt. Ab dem Milestone ,Prototyp erfolgreich entwickelt‘ übernimmt dann die Produktion – ebenfalls wieder an einem anderen Standort. Die Logistik wird jeweils lokal gesteuert. Qualität zentral überwacht, Mission Control hat auch eine Zentrale, aber wieder ganz woanders.

Und so kommt es gerne mal zu so irren Geschichten, wie dass ein ganzer Flugzeugrumpf in einem extra dafür gebauten Flugzeug an einen anderen Standort zur Endmontage geflogen wird. Und bleibt es bei nur einem solchen Schritt, haben wir noch Glück gehabt. Denn manche Firmen verteilen bspw. alleine schon die Entwicklung über den halben Globus.

Der Abstimmungsaufwand ist dabei verständlicherweise riesig. Doch wenn Fördermittel je Land vergeben werden oder die Personal- oder andere Kosten so dramatisch voneinander abweichen, dass unschlagbare Standortvorteile entstehen, oder ein 24h, rund-um-die-Uhr-Ansatz möglich wird, dann siegen nicht selten finanzielle und zeitliche Überlegungen.
Wir als Projektmanager:innen müssen uns mit diesen Gegebenheiten oftmals einfach abfinden und sie als gegebene Rahmenbedingungen annehmen – das sind denn die Konditionen, zu denen wir eben das Projekt zu managen haben.

5. Dann behilft man sich häufig damit, das Projekt in einzelne Unterprojekte zu zerlegt und je Standort eigene Projektleiter:innen zu installieren. Von zentraler Stelle muss man lediglich diese managen und zusammenführen – doch bei dieser Koordinationsarbeit läuft im Hintergrund stetig die Suche nach einer organisatorischen Vereinfachung, ich spreche aus Erfahrung.

Wann sind Arbeitspakete zu kleinteilig?

Was ist das Ziel der ganzen Übung?
Auf aller unterster Ebene möchtest du mit konkreten Arbeitspaketen enden. Daher sind die Namen Arbeitspaketstruktur oder Work Package Breakdown Structrue auch so passend.

Wir sprechen hier von Arbeitspaketen, die an Ergebnissen/Deliverables festgemacht sind, die ihr als Team dann in eine logische Abhängigkeit bringt. Anschließend könnt ihr sie genauer planen.

Die Schlüsselfrage ist also: Wann höre ich auf, die Arbeitspakete weiter herunterzubrechen?

Ganz einfach, wenn du die folgende Regel beachtest.

Die 3 R Regel

Die 3 R Regel besagt, dass du aufhören kannst die Arbeit weiter herunter zu brechen, …

• wenn sie ein eindeutiges Result beschreibt, also ein klares Ergebnis produziert.
• wenn du eine R wie Responsible Person, also eine Person die für das Ausführen der Arbeit zuständig ist, eindeutig zuordnen kannst. An der Stelle werfe ich kurz ein, dass es einen entscheidenden Unterschied macht ob jemand responsible/zuständig oder accountable/verantwortlich ist. Das beleuchten wir näher in der Podcast-Folge #15 zum Thema Rollen und Verantwortlichkeiten.
• wenn du die benötigen R wie Ressourcen klar zuordnen kannst. Das sind immer Zeit und Budget, aber auch Materialien. Diese drei Parameter machen das ganze Arbeitspaket auch managbar.

Tipps und Hinweise zum Projektstrukturplan

• Oft ist es am Anfang gänzlich unmöglich, alles so haargenau herunterzubrechen. Viel eher gehst du stets so weit in die Tiefe, wie du oder ihr als Team das Projekt bereits durchdrungen habt und managt das Projekt auf dieser Basis. Eben so lange, bis du im Projektverlauf genauere Infos hast, dazulernst und dann weiter in die Details vorstößt. Deshalb ist die 100% Regel so wichtig. Brich erst weiter runter, wenn du alle nachfolgenden Ergebnisse hinreichend beschreiben kannst, damit du allzeit vollständig unterwegs bist. Mein Tipp: Bloß nicht im Detail verlieren und dadurch ganze Teile des Projekts an anderer Stelle aus dem Blick verlieren.
• Was sich jedoch nicht verändern sollte, ist die grundsätzliche Struktur deines Projekts. Die Detailtiefe ja, aber nicht die Form der Strukturierung. Das ist sinnig, denn wenn du die laufend änderst, sagen wir von produktstruktur-orientiert zu phasen-orientiert zu abteilungs-orientiert, kennt sich bald niemand mehr aus, dem/der du das Projekt erklärst.
• Ein abschließender Tipp an dieser Stelle. Unser Hirn ist ziemlich limitiert dahingehend, wie viele Elemente oder Komponenten es auf einmal leicht erfassen kann. Wer viele Computerspiele spielt ist klar im Vorteil, weil sie das Hirn darauf trainieren, viele Dinge gleichzeitig im Blick zu behalten. Doch in der Regel liegt das Limit irgendwo zwischen fünf und neun Dingen, die wir gleichzeitig gut erfassen können. Daher möchtest du je Ebene nicht mehr als eben diese fünf bis neun Elemente aufführen. Fass bestimmte Elemente also wieder zu einer Überschrift zusammen, bevor es zu viel wird. Beachte aber stets die 3 R Regel.
• In den kommenden Folgen schauen wir uns an, wie es ab hier weiter geht. Also ab dem Moment, wie du deinen Projektstrukturplan erstellt hast. Wir werden den Arbeitspaketen eine logische Reihenfolge verpassen, uns über Rollen und Verantwortlichkeiten bzgl. der Zuteilung von Aufgaben unterhalten und natürlich reinschauen, wie du eine Zeitplan/eine Timeline erstellst und den Status der darin befindlichen Aufgaben im Blick behältst. Mit diesem Ausblick wird auch deutlich, dass es durchaus Sinn macht, deine Arbeitspakete nicht nur zu benennen, sondern auch zu nummerieren, um sie dann später eindeutig verknüpfen und darauf referenzieren zu können.

Auf zur Brillanz

Und jetzt würde ich sagen: Probiere es einfach mal für dein Projekt aus. Wenn du zu Beginn noch nicht weißt welche Struktur die beste ist, schreib einfach erstmal eine Liste mit allen Aktivitäten auf, die dir einfallen und strukturiere dann. Hast du schon ein Team, binde es gerne gleich mit ein. Dann wird es auch gleich euer PSP und allen wird es leichter fallen, sich mit dem Projekt zu identifizieren.
An der Stelle vielen Dank fürs Zuhören, viel Erfolg mit den Strukturhilfen, um dein Projekt leichter zu organisieren. Und für den Fall, dass du dir denkst, „Ach Struktur, brauch ich nicht, ich kenn mich aus.“ Denk an die Denktypen aus Folge #3. Das mag auf dich zutreffen, aber nicht auf alle anderen Mitarbeitenden. Denen ist echt geholfen, wenn du ihnen eine anbietest oder ihr sie gemeinsam erarbeitet.

Nimm dir auch gerne noch sechs Minuten für dieses Video zum Struktur-Experiment, das sehr eindrucksvoll aufzeigt, warum eine gewisse Struktur so wichtig ist. Und wie du mit einer guten Struktur deine Projektlaufzeit halbieren kannst. Teile das Video und mach das Experiment also ruhig auch mit deinem gesamten Team. Es macht Spaß und ist lehrreich.

Solltest du darüber hinaus noch Fragen oder Wünsche oder große Ziele haben, bei denen ich dir behilflich sein kann und dein Leben einfacher machen kann, dann kontaktiere mich gerne via email chris@pm-botschaft.com oder vereinbare über meine Website www.pm-botschaft.com ein kostenloses Erstgespräch oder schreib mit auf LinkedIn.
Ach ja Website, genau. Neben allen Skripten zum „Projetmanagement on demand“-Podcast Highlight ist ganz sicher findest du hier auch die Aufzeichnung meines Online-Events zu den 7 Magischen Zutaten im Projekt – deine Erfolgsfaktoren für mehr Leichtigkeit in der Projektarbeit. Schau gerne vorbei.

Bis dahin, auf zur Brillanz!

Chris