2.5.3 Projektstrukturplan-WBS

Projektstrukturplan-WBS

In diesem Abschnitt wird erläutert, was ein Projektstrukturplan ist, auch bekannt als PSP auf Deutsch und WBS auf Englisch, sowie wie er erstellt wird. WBS steht für “Work Breakdown Structure” auf Englisch.

Ein Projektstrukturplan ist eine hierarchische Aufgliederung der Arbeit, die vom Projektteam durchgeführt werden muss. Der Zweck dieser Struktur besteht darin, komplexe Arbeit in kleinere, handhabbare Teile zu unterteilen. Als Ergebnis dieser Aufteilung ist der Projektstrukturplan eines der wichtigsten Dokumente im Projektmanagement.

Es gibt zwei Arten von WBS. Der erste Typ basiert auf Liefergegenständen, während der zweite Typ auf den Projektphasen basiert. Der am häufigsten verwendete Ansatz ist der liefergegenstandsbasierte Ansatz. Der Hauptunterschied zwischen den beiden Ansätzen liegt in den Elementen, die auf der ersten Ebene der Struktur identifiziert werden.

Hier ist ein Beispiel für eine liefergegenstandsbasierte WBS. Die Elemente der ersten Ebene sind zusammenfassende Beschreibungen der Liefergegenstände, während die Elemente der zweiten Ebene die einzelnen Liefergegenstände darstellen, die den jeweiligen zusammengefassten Liefergegenstand der ersten Ebene ausmachen.

Hier ist ein Beispiel für eine phasenbasierte WBS. Die Elemente der ersten Ebene sind Phasen dieses Projekttyps. Die Elemente der zweiten Ebene sind die Liefergegenstände jeder Phase.

Eine gute Struktur für den Projektstrukturplan (WBS) ist einfach die, die das Projektmanagement erleichtert. Jedes Projekt ist unterschiedlich. Jeder Projektmanager ist unterschiedlich. Und somit ist jede Struktur für die Projektstrukturplan anders. Daher ist die richtige Struktur für die Projektstrukturplan diejenige, die die gesamte zu erledigende Arbeit am besten erfasst.

Es ist oft ratsam, mit einer Struktur für die Projektstrukturplan nach Liefergegenständen zu beginnen und nachdem alle Elemente identifiziert wurden, ohne sich um die Phasen zu kümmern, diese bereits unterteilten Elemente in eine andere Struktur für die Projektstrukturplan basierend auf Phasen zu überführen, wodurch die Erstellung des Projektterminplans vorbereitet wird.

Wie baut man einen Projektstrukturplan auf?

Die beste Art, einen Projektstrukturplan aufzubauen, ist, auf der obersten Ebene mit den Zusammenfassungsliefergegenständen zu beginnen und von dort aus nach unten zu arbeiten.

Dies ist eine Teamarbeit und keine Aufgabe, die dem Projektmanager allein zugewiesen wird. Der Projektmanager benötigt das technische Wissen und die Erfahrung der Teammitglieder, denn sie sind die technischen Experten, die wissen, was speziell getan werden muss, um den jeweiligen Liefergegenstand zu erstellen. Durch die Teamarbeit mit den Spezialisten wird nicht nur das Risiko verringert, Dinge zu übersehen, die getan werden müssen, sondern es hilft auch, das Team für das Projekt zu gewinnen.

• Als Team beginnen wir zunächst mit der Identifizierung der Zusammenfassungsliefergegenstände auf der obersten Ebene.
• Anschließend organisieren sich kleinere Gruppen im Team, um diese Zusammenfassungsliefergegenstände in kleinere Komponenten aufzuteilen.
• Abschließend kommt das gesamte Team zusammen, um die Ergebnisse zu überprüfen und etwaige Mängel zu beheben.
• Falls ein Teil des Teams nicht anwesend ist, arbeiten wir mit den verfügbaren Informationen, um den Detailgrad zu erreichen, der möglich ist. Wenn später weitere Spezialisten dem Projektteam beitreten, können zusätzliche Details zum ursprünglichen Projektstrukturplan hinzugefügt werden, insbesondere in den Bereichen, die anfänglich zu grob zusammengefasst wurden.

Wir starten damit, den Projektumfang und die im Dokument erwähnten Liefergegenstände zu verwenden, um die Zusammenfassungsliefergegenstände auf oberster Ebene zu identifizieren. Anschließend zerlegen wir jedes dieser Zusammenfassungsliefergegenstände in kleinere Teile.

Nehmen wir das Zusammenfassungsliefergegenstand Logistik als Beispiel, da dies das komplizierteste zu sein scheint, weil für die Logistik in unserem Beispiel derzeit kein bestehendes System vorhanden ist und alles von Grund auf neu erstellt werden muss.

Angenommen, das Expertenteam schlägt vor, dass für die Entwicklung eines Logistikmanagementsystems ein Anbieter für solche Lösungen benötigt wird. Infolgedessen wird dem Lebenszyklus gefolgt, den dieser Anbieter vorschlägt. Das bedeutet, dass im Moment nur bekannt ist, dass eine Lösung für das Logistikmanagement entwickelt und implementiert wird, die mit Hilfe eines spezialisierten Dienstleisters auf diesem Gebiet erstellt wird.

In Bezug auf die Beschaffung eines spezialisierten Dienstleisters erinnert uns ein Mitglied der Einkaufsabteilung daran, dass der Beschaffungsprozess des Unternehmens für neue Anbieter immer derselbe ist und dass wir diesen Unternehmensprozess übernehmen müssen, um den neuen Anbieter zu erhalten, den wir benötigen.

In Bezug auf die notwendigen Elemente für die Entwicklung und Implementierung einer Lösung für das Logistikmanagement haben wir derzeit nur begrenzte Informationen. Daher können wir vorläufig ein generisches Lebenszyklusmodell verwenden.

Die meisten Projektmanager definieren Arbeitspakete, die zwischen 40 und 80 Stunden Aufwand erfordern. Das Detailniveau der Arbeitszerlegung sollte dem gewünschten und verwaltbaren Detailgrad entsprechen.

Verschiedene Teile eines Projekts können unterschiedliche Detailgrade in der Arbeitszerlegung erfordern. Wir machen uns keine Sorgen über die anfängliche Organisation unseres Projektstrukturplans, da sie später bei Bedarf neu organisiert werden kann, wenn wir mehr über das Projekt erfahren.

Ein letztes Wort zur Struktur des Projektstrukturplans und zu agilen Lebenszyklen: Es gibt oft das Missverständnis, dass ein Projektstrukturplan eine Zeitverschwendung ist, wenn ein agiler Ansatz verwendet wird. Diese Annahme basiert auf der Vorstellung, dass bei einem agilen Projekt der Projektumfang nicht zu Beginn festgelegt wird. Das ist zwar richtig, jedoch zerlegen auch Projekte mit einem agilen Entwicklungsansatz die Arbeit in kleinere Bestandteile und entwickeln sowohl eine Roadmap für einen guten Überblick über die Funktionalitätsumsetzung in den verschiedenen Phasen der Produktentwicklung (Releases genannt in Agile) als auch eine feinere Zergliederung der Komponenten anhand des Produktbacklogs.

Dieses Backlog ist eine dynamische Liste ausstehender Arbeiten, die ständig aktualisiert und vor Beginn der nächsten Iteration nach Priorität geordnet wird, um Anforderungen in der vom Kunden bevorzugten Reihenfolge umzusetzen. Das heißt, das Backlog ist eine Art Projektstrukturplan, der ständig nach Implementierungsreihenfolge neu organisiert wird.

Außerdem, ähnlich wie wir es mit den Arbeitspaketen eines traditionellen Projektstrukturplans machen, werden auch die Elemente des Backlogs feiner zerlegt, wenn sie kurz vor der Entwicklung stehen und detaillierter erforscht werden.

Es gibt keinen Grund, warum wir nicht ähnlich vorgehen können, wenn ein eher plangetriebener Entwicklungsansatz verwendet wird, indem wir die zu erledigende Arbeit bis zum nächsten Meilenstein oder für die nächste Iteration weiter zerlegen und detaillierter definieren. Dabei nutzen wir die traditionelle Technik der sogenannten Wellenplanung, die darin besteht, Details allmählich zu planen, je weiter das Projekt voranschreitet.

In Zusammenfassung können wir die zu erledigende Arbeit entweder nach den Liefergegenständen, die die Lösung bilden, oder nach den Projektphasen zerlegen. Dadurch erhalten wir die Möglichkeit, die Arbeit schrittweise von Meilenstein zu Meilenstein feiner zu gliedern, indem wir eine hybride Methode der schrittweisen Zerlegung anwenden, während das Projekt fortschreitet.

Das Wichtigste ist, dass wir die zu erledigende Arbeit identifizieren. In einer idealen Welt könnten wir die gesamte bevorstehende Arbeit erfassen. Doch in der Realität ist uns bewusst, dass uns ein Teil, vielleicht sogar ein wichtiger, entgehen könnte. Aus diesem Grund bilden wir Reserven für Unvorhergesehenes, über die wir in einem anderen Abschnitt sprechen werden.

Verschiedene Detailgrade der Zerlegung können nebeneinander existieren. Für Projektteile, die zunächst nur grob zergliedert werden können, werden mehr Details nach und nach hinzugefügt, sobald mehr Informationen verfügbar sind. Die detaillierteste, also die niedrigste Ebene des Projektstrukturplans, sind die Arbeitspakete. Diese müssen mit dem erforderlichen Detailgrad definiert werden, um sie einem Team zuzuweisen, das sie unter der Leitung eines jeweiligen Arbeitspaket-Leiters erstellen wird.