Samstag, 2. Mai 2020

Wichtiger als Sie denken: der Projektstrukturplan


WBS? PSP? Neue Organisationen? Ein neues Methodenkonzept? Wichtige Softwaretools? Mitnichten. WBS steht für „Work Breakdown Structure“, zu Deutsch: Projektstrukturplan (PSP) - und somit für den wichtigsten ersten Schritt eines Projektleiters nach der Projektinitiierung.


Autor bei der Erstellung eines WBS/PSP. Copyright: olaf knauer

„Alter Hut“, sagen Sie. „Jeder Projektleiter weiß das“, sagen Sie. Recht haben Sie. Aber es kann nicht oft genug gesagt und geschrieben werden: Ohne eine tiefgreifende, detaillierte WBS zu Beginn eines Projekts fehlt jegliche Grundlage für die weitere Projektplanung. Weder die Erstellung eines Projektplans, eines konsolidierten Phasenplans noch eines Risikoregisters oder einer RACI-Matrix ist möglich. Kein Tracking, kein Nachverfolgen. Kurz: nichts. Sie als Projektleiter können weder Transparenz noch Verbindlichkeit garantieren. Und das verkaufen Sie mal Ihrem Auftraggeber.

Die Gründe, weswegen eine WBS oftmals sträflich vernachlässigt wird, liegen meist in einer fehlenden Projektmanagementkultur. Viele Hands-on-Spezialisten beherrschen Ihren Arbeitsbereich im Unternehmen perfekt, arbeiten aber selten strukturiert. Wenn ein Projektleiter in so ein Arbeitsumfeld gerät, wird er sehr leicht mitgerissen von der unstrukturierten Arbeitsweise. Hier muss er ein Zeichen setzen. Er muss darauf drängen, dass sich alle beteiligten Spezialisten zusammensetzen und die Arbeitspakete gemeinsam aufstellen. Die Strukturierung übernimmt dann er selbst.
(Hinweis am Rande: Es mag dem Projekterfolg vermutlich abträglich sein, wenn der Projektleiter ebenfalls ein solcher Hands-on-Spezialist ist oder war.)

Wir notieren: Ohne WBS oder PSP kommt man nicht weit, ein Projektstrukturplan ist zwingend notwendig.

Das Erstellen eines Projektstrukturplans ist Teamarbeit. Der PSP bündelt Inputs und Perspektiven für das Projekt von allen Teammitgliedern aus einem gemeinsamen Brainstorming. Dabei können Whiteboards, Registerkarten oder Notizzettel verwendet werden, um größere Arbeitsbereiche, kleine und spezifische Arbeitspakete zu identifizieren und zu notieren. Karten können an eine Wand gepinnt und immer neu organisiert werden.

Was soll nun alles in einer WBS enthalten sein?

Ganz einfach:
  • Bezeichnung der Arbeitspakete
  • Aufteilung in (Arbeits-)Bereiche
  • Festlegen eines Verantwortlichen
  • Dauer des Projekts (Start- und Enddatum)
  • Projektkosten

Bei der Einschätzung von Dauer, Start- und Endtermin hat sich die Delphi-Methode als am wirkungsvollsten erwiesen. Die Standard-Delphi-Methode zieht mehrere Spezialisten zur Schätzung bzw. Prognostizierung eines Arbeitspaketes heran, die sich nicht untereinander abstimmen dürfen. Von allen Schätzungen werden die Mittelwerte errechnet und als finale Schätzung präsentiert. Die Delphi-Methode ist aus meiner Sicht nicht notwendig, wenn man mit den Spezialisten schon mehrfach gearbeitet hat und davon ausgehen kann, dass deren Zeit-Schätzwerte immer zutreffend sind, insbesondere dann, wenn es sich um wiederkehrende Arbeitspakete handelt.

Die Erstellung eines Projektstrukturplans zu Beginn des Projekts dient somit einerseits der Effizienzsteigerung bei der Planung und Durchführung mittels Darstellung des gesamten Leistungsumfangs bereits in der Startphase. Zum anderen werden von Anfang an planbare und kontrollierbare Arbeitspakete erstellt sowie eine Basis für das Projektcontrolling durch die ausführliche Gliederung geschaffen. Zudem soll die Gliederung auch eine eindeutige Zuordnung von Arbeitspaketen an die Projektmitglieder ermöglichen.

Ist die Erstellung einer/s separaten WBS/PSP noch zeitgemäß?

Gemäß GPM/IPMA und PMI ist diese administrative Tätigkeit notwendig und wichtig. Nach meinen Erkenntnissen ist es aber grundsätzlich nicht erforderlich ein separates Tool zu benutzen. Aus meiner Sicht ist es durchaus legitim und ausreichend sämtliche Arbeitspakete in ein Balkendarstellungsprogramm (z. B. Microsoft Project) ohne separate PSP-Darstellungsoption umzusetzen. Man kann also durchaus und ohne schlechtes Gewissen als ersten Schritt den kompletten PSP in MS Project abbilden. Die meisten meiner Kollegen handhaben es so. Vorteil für den Projektleiter: Einsparung von unnötiger administrativer Arbeitstätigkeit, keine zusätzlichen Tools notwendig, Import- und Export von Daten zwischen verschiedenen Programm entfallen.    

Einige Empfehlungen für das Erstellen eines PSP mit MS Project

Wenn MS Project gestartet wird, enthält die Tabelle auf der linken Seite die Einträge:
  • i (wie Information oder Notiz)
  • Vorgangsname
  • Dauer
  • Anfang
  • Ende
  • Vorgänger
  • Ressourcennamen.

Dies verleitet leider dazu viele Dinge auf einmal zu planen:
  • was alles zu tun ist (Vorgangsname)
  • wie lange es dauern wird (Dauer)
  • wann es getan wird (Anfang, Ende)
  • in welcher Reihenfolge es geplant wird (Vorgänger)
  • und wer es tut.

Deshalb empfehle ich die Felder so zu konfigurieren, dass nur noch die folgenden Spalten zu sehen sind:
  • i (fleißigst gebrauchen)
  • Vorgangsname
  • Notizen
  • PSP-Code

Mit dieser Darstellung können Sie nun den PSP erstellen. 


Beispiel eines WBS/PSP in MS-Projekt, Copyright: olaf knauer

Die weiteren Angaben wie Start- und Enddatum, Kosten und Ressourcennamen folgen anschließend.

Wie detailliert soll der Projektleiter planen?

Fürwahr eine schwierige Frage. Es sollte die Devise gelten: Plane genau das, was du kontrollieren kannst, willst und musst. Das heißt, man braucht eine genaue Vorstellung davon, wie man den Projekt-Fortschritt kontrollieren möchte. Je nach Projekt kann dies extrem unterschiedlich ausfallen: Wenn Sie einen großen Rollout organisieren, kann die Vorbereitung durchaus ein halbes Jahr vorher beginnen. Sie werden in dieser Phase aber vermutlich nur gelegentlich, vielleicht einmal pro Woche den Status kontrollieren. Beim Start des Rollouts werden Sie dann vermutlich mehrmals am Tag nach dem Rechten sehen müssen. Dabei gilt als wichtigstes Kriterium die Frage nach dem tolerierbaren Risiko: Sie müssen einen Vorgang so genau im Auge behalten, dass Sie noch reagieren können, wenn etwas schief läuft – und zwar, bevor inakzeptabler Schaden am Projekt entsteht.

Wie strukturiert man einen Projektstrukturplan?

Erfahrungsgemäß stellen sich erschreckend wenige Projektleiter diese Frage. Das Problem ist, dass häufig unterschiedliche Kriterien verwendet werden: Die einen orientieren sich an den Schichten der Organisation, andere an Tätigkeitsbereichen. Dadurch ist für ein Arbeitspaket nicht klar, wo es in dieser Struktur einzuordnen ist. Dies führt zu unnötigen Suchvorgängen, zu vergessenen oder doppelt geplanten Arbeitspaketen.

Grundsätzlich sollten innerhalb eines Sammelvorgangs bzw. Bereichs die Untervorgänge nach einem einheitlichen Kriterium strukturiert werden, zum Beispiel nach:
  • Projektphasen (hier überlappende Phasen beachten)
  • Objekten, d. h. Teilen des zu erstellenden Projektergebnisses (bspw. Maschinenteile in einem Bauprojekt, Programm-Module in einer Anwendung)
  • Tätigkeiten (Designen, Analysieren, Programmieren, Testen usw.
  • Personengruppen/Abteilungen, die für die Vorgänge zuständig sind: (Analysten, Architekten, Tester).
Welches das richtige Kriterium ist, hängt vom Projekt und vom Geschmack des Projektleiters ab.

Keine Kommentare:

Kommentar veröffentlichen