Skip to main content

Ein Projektstrukturplan (WBS) ist ein Werkzeug zur Projektplanung, das ein Projekt in kleinere, überschaubare Bestandteile zerlegt, sodass Teams sehen können, was geliefert werden muss, wer für die einzelnen Bestandteile verantwortlich ist und wie die Arbeit zusammenhängt. Die meisten Projektstrukturpläne sind entweder nach Liefergegenständen oder Projektphasen gegliedert.

In diesem Leitfaden erläutere ich, was ein WBS ist, welche Bestandteile und Arten es gibt, zeige echte Beispiele, erkläre Schritt für Schritt, wie man einen erstellt und wie man ihn im Alltag nutzt. Außerdem stelle ich dir eine kostenlose Vorlage zur Verfügung, mit der du starten kannst.

Was ist ein Projektstrukturplan (WBS)?

Ein Projektstrukturplan (WBS) ist eine Möglichkeit, die Aufgaben, Phasen, Liefergegenstände und Abhängigkeiten eines gesamten Projekts zu visualisieren. Er gliedert ein Projekt in kleinere Bestandteile, sodass Teams Liefergegenstände klar definieren, Verantwortlichkeiten zuweisen, den Aufwand schätzen und den Fortschritt während des gesamten Projektlebenszyklus verfolgen können.

Der WBS visualisiert Projektergebnisse, die Reihenfolge der erforderlichen Aktivitäten und die Liefergegenstände des Projekts. Projektmanager verwenden einen WBS, um den Umfang von Projekten festzulegen, Verantwortlichkeiten zuzuweisen, den Aufwand zu schätzen und den Fortschritt zu verfolgen. Er hilft Stakeholdern zu verstehen, welche Arbeiten zur Projektdurchführung gehören. Arbeiten, die nicht im WBS enthalten sind, gehören nicht zum Projekt.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Arten von Projektstrukturplänen

Es ist erwähnenswert, dass es zwei Möglichkeiten gibt, einen WBS zu erstellen – entweder meistens anhand von Liefergegenständen oder alternativ nach Projektphasen. 

  • Liefergegenstandsorientierter Projektstrukturplan: Auch als objektorientiert, nomenorientiert oder produktorientiert bezeichnet. Dies ist die häufigste Variante.
  • Phasenbasierter Projektstrukturplan: Stattdessen auf die Aufgaben konzentriert, die erforderlich sind, um diese Liefergegenstände fertigzustellen. Andere Bezeichnungen, denen du möglicherweise begegnest, sind aktivitätenorientiert, aufgabenorientiert, verborientiert oder prozessorientiert.

Für die meisten digitalen, Software- und funktionsübergreifenden Projekte ist ein liefergegenstandsorientierter WBS in der Regel die bessere Wahl. Er hält Teams auf Ergebnisse statt auf voneinander losgelöste Aktivitäten fokussiert. Dadurch wird es einfacher, den Umfang zu verwalten, Stakeholder auszurichten und den Fortschritt über Produkt-, Entwicklungs-, Design- und Betriebsteams hinweg zu verfolgen.

phasenbasierter Projektstrukturplan
Ein Beispiel für einen phasenbasierten WBS.
liefergegenstandbasierter Projektstrukturplan

Wie ein Projektstrukturplan aussieht

So sieht er häufig aus:

Screenshot eines Projektstrukturplans
Eine konzeptionelle Darstellung eines Projektstrukturplans.

Je weiter du in der Hierarchie nach unten gehst, desto spezifischer wird die Arbeit und desto einfacher lässt sie sich schätzen, zuweisen, planen und überwachen. Ein gut strukturierter WBS hilft Teams außerdem dabei, Aufgabenabhängigkeiten frühzeitig zu erkennen. Dadurch sinkt das Risiko, dass Arbeiten übersehen werden, Verantwortlichkeiten sich überschneiden oder unrealistische Zeitpläne entstehen.

Wichtige Begriffe zum Projektstrukturplan

Bevor wir näher darauf eingehen, findest du hier einige wichtige Begriffe, die dir im weiteren Verlauf dieses Leitfadens begegnen werden:

  • Baseline: Die genehmigte Version des Projektumfangs, Zeitplans oder Budgets, anhand derer Leistung und Fortschritt gemessen werden.
  • Meilenstein: Ein wichtiger Prüf- oder Abschlusszeitpunkt im Projektzeitplan, beispielsweise die Genehmigung durch Stakeholder oder das Ende einer wichtigen Phase.
  • Kritischer Pfad: Die Abfolge voneinander abhängiger Aufgaben, die den kürzestmöglichen Zeitrahmen für den Abschluss des Projekts bestimmt. Verzögerungen bei Aktivitäten auf dem kritischen Pfad wirken sich direkt auf den Liefertermin des Projekts aus.

WBS im Vergleich zum Projektzeitplan und Gantt-Diagramm

Ein Projektstrukturplan wird häufig mit einem Projektzeitplan oder Gantt-Diagramm verwechselt, doch sie erfüllen unterschiedliche Zwecke. Ein WBS definiert, welche Arbeiten abgeschlossen werden müssen, während ein Projektzeitplan festlegt, wann diese Arbeiten stattfinden und in welcher Reihenfolge sie ausgeführt werden. Gantt-Diagramme bauen auf dem WBS auf, indem sie Aufgaben, Dauer, Meilensteine und Abhängigkeiten über einen Zeitverlauf abbilden.

Warum ist ein Projektstrukturplan wichtig?

Eine WBS hält Ihr Projekt fest in der Realität verankert. Ohne eine solche Struktur setzt schnell eine schleichende Ausweitung des Projektumfangs ein – Teams übersehen Liefergegenstände, Zeitpläne geraten ins Wanken, und niemand ist sich einig, wie „fertig“ eigentlich aussieht. Mit einer soliden WBS können Sie den Aufwand genau schätzen, Verantwortlichkeiten eindeutig zuweisen und Lücken erkennen, bevor sie zu Blockaden werden. Für Technologie- und Digitalteams, die gleichzeitig an Produkt-, Entwicklungs- und Designaufgaben arbeiten, ist sie oft der entscheidende Unterschied zwischen einer kontrollierten Umsetzung und einem chaotischen Projektverlauf.

Nutzen Sie diese Aufschlüsselung, um zu verstehen, was Sie durch die Verwendung einer WBS gewinnen – und welche Risiken Sie eingehen:

FaktorMit einer WBSOhne eine WBS
UmfangskontrolleKlare Grenzen verhindern ungeplante ArbeitenDie Ausweitung des Projektumfangs bleibt unbemerkt, bis sie teuer wird
AufwandsschätzungAufgaben sind detailliert genug, um sie genau zu schätzenSchätzungen sind vage und werden regelmäßig verfehlt
VerantwortlichkeitJeder Liefergegenstand hat eine eindeutig verantwortliche PersonDie Zuständigkeiten zwischen den Teammitgliedern sind unklar
AbhängigkeitsnachverfolgungTeams können Blockaden erkennen, bevor sie eintretenAbhängigkeiten werden erst sichtbar, nachdem Verzögerungen aufgetreten sind
Interessengruppen-AusrichtungAlle beziehen sich auf dieselbe ProjektstrukturInteressengruppen haben widersprüchliche Vorstellungen vom Projektumfang

Beispiele für gut umgesetzte Projektstrukturpläne

Wenn Sie sehen, wie ein Projektstrukturplan in der Praxis aussieht, wird klarer, wie Sie ihn in Ihren Projekten einsetzen können. Hier sind drei aussagekräftige Beispiele für WBS, an denen Sie sich orientieren können:

Aufschlüsselung der Einführung eines Softwareprodukts

Gliedern Sie die Arbeit in Planung, Erstellung, Benutzertests, Vorbereitung der Einführung und Unterstützung nach der Einführung. Jede Ebene wird in Aufgaben wie das Erfassen von Anforderungen, die Programmierung von Funktionen, das Verfassen von Testfällen, die Erstellung von Versionshinweisen und die Planung der Unterstützungsdokumentation unterteilt.

ein Beispiel für eine WBS zur Einführung eines Softwareprodukts
Beispiel für eine WBS eines Softwareeinführungsprojekts, aufgeteilt in Arbeitspakete für Planung, Entwicklung, Tests, Einführungsvorbereitung und Unterstützung nach der Einführung.

Projektstruktur für die Neugestaltung einer Website

Beginnen Sie mit den Hauptphasen wie Analyse, Design, Entwicklung und Bereitstellung. Führen Sie die Aktivitäten unter jeder Phase detailliert aus: Interviews mit Interessengruppen, Drahtmodelle, Aktualisierungen der Benutzeroberfläche, Einrichtung des CMS, Benutzerakzeptanztests und Migration der Website.

ein Beispiel für eine WBS zur Neugestaltung einer Website
Beispiel für eine WBS eines Website-Neugestaltungsprojekts mit Liefergegenständen und Aufgaben für Analyse, Design, Entwicklung und Bereitstellung.

Implementierung eines Lernmanagementsystems

Teilen Sie das Projekt in Bedarfsanalyse, Systemauswahl, Integration, Inhaltsmigration, Schulung und Einführung auf. Gehen Sie anschließend auf Schritte wie die Freigabe durch Interessengruppen, Produktvorführungen von Anbietern, Datenzuordnung, die Planung von Schulungsterminen und die Überwachung des Produktivstarts ein.

ein Beispiel für eine WBS zur Implementierung eines LMS
Beispiel für eine WBS eines LMS-Implementierungsprojekts mit Aktivitäten für Systemauswahl, Integration, Migration, Schulung und Einführung.
Treten Sie der DPM-Community bei und erhalten Sie Zugang zu exklusiven Inhalten, praxisnahen Vorlagen, Mitglieder-Events und wöchentlichen Leadership-Insights – die Teilnahme ist kostenlos. <br><br>

Treten Sie der DPM-Community bei und erhalten Sie Zugang zu exklusiven Inhalten, praxisnahen Vorlagen, Mitglieder-Events und wöchentlichen Leadership-Insights – die Teilnahme ist kostenlos.

Wie detailliert sollte eine WBS sein?

Eine WBS zerlegt größere Teile der Projektarbeit in kleinere Aufgaben. Aber welcher Detaillierungsgrad ist für diese Aufschlüsselung der richtige?

Ähnlich wie bei Goldlöckchen sollten Sie einen goldenen Mittelweg finden. Bei zu vielen Details wird Ihre WBS unhandlich und schwer zu verwalten. Bei zu wenigen Details fehlen Ihrer WBS die Informationen, die Sie benötigen, um Ihr Projekt erfolgreich zu steuern.

Eine gute Faustregel: Wenn die Verwaltung des Arbeitspakets mehr Aufwand erfordert als die Erledigung der Arbeit selbst, haben Sie Ihre WBS wahrscheinlich zu stark aufgeschlüsselt. Das Ziel sind Klarheit und Verantwortlichkeit – nicht die Schaffung eines Verwaltungsaufwands, den Ihr Team nicht dauerhaft pflegen wird.

Streben Sie in Ihrer WBS drei Detailebenen an, jedoch nicht mehr als vier Ebenen. Wie bei anderer Projektdokumentation hängt die Gestaltung Ihrer WBS von den bewährten organisatorischen Vorgehensweisen und davon ab, ob Sie ein komplexes Projekt durchführen.

Schlüsselkomponenten eines Projektstrukturplans

Das Verständnis der Kernkomponenten eines Projektstrukturplans hilft Ihnen dabei, einen Projektplan zu erstellen, der während der Umsetzung tatsächlich nützlich ist – und nicht nur beim Projektauftakt organisiert aussieht. Jedes Element erfüllt eine bestimmte Funktion und hilft Teams dabei, den Umfang zu definieren, die Arbeit zu organisieren, Verantwortlichkeiten zuzuweisen und den Fortschritt zu verfolgen.

Lieferobjekte

Lieferobjekte sind die greifbaren Ergebnisse, die Ihr Projekt hervorbringen soll. Dazu können Dokumente, Systeme, Funktionen, Genehmigungen oder abgeschlossene Arbeitsphasen gehören. Die meisten modernen Projektteams strukturieren einen PSP nach Lieferobjekten und nicht nach Aktivitäten, da dadurch der Fokus auf Ergebnissen statt auf voneinander losgelösten Aufgaben liegt.

Beispiel: „Abgeschlossener Onboarding-Workflow“ ist ein stärkeres PSP-Element als „Onboarding-Bildschirme entwerfen“, da es das endgültige Ergebnis widerspiegelt, auf das das Team hinarbeitet.

Arbeitspakete

Arbeitspakete bilden die unterste Ebene eines PSP. Hier wird die Arbeit spezifisch genug, um sie zuzuweisen, zu terminieren und zu verwalten. Ein Arbeitspaket fasst zusammengehörige Aktivitäten zusammen, die zu einem Lieferobjekt beitragen.

Beispiele für Arbeitspakete können sein:

  • Anmelde-API entwickeln
  • CRM-Integration konfigurieren
  • Texte für Onboarding-E-Mails verfassen

Wenn Arbeitspakete zu weit gefasst sind, werden Schätzungen unzuverlässig und Verantwortlichkeiten unklar. Sind sie zu kleinteilig, wird der PSP schwer zu pflegen.

Steuerungskonten

Steuerungskonten sind Managementpunkte innerhalb des PSP, an denen Umfang, Zeitplan und Kosten gemeinsam verfolgt werden. Sie befinden sich oberhalb der Arbeitspakete und helfen Projektmanagern dabei, den Fortschritt größerer Arbeitsbereiche zu überwachen.

Beispielsweise könnte ein Softwareimplementierungsprojekt ein Steuerungskonto für „Benutzerauthentifizierungssystem“ verwenden, unter dem sich mehrere Arbeitspakete für Design, Entwicklung, Tests und Bereitstellung befinden.

Komponenten eines Projektstrukturplans mit Steuerungskonto, Planungspaketen und Arbeitspaketen,
So erscheinen Steuerungskonten, Planungspakete und Arbeitspakete typischerweise in einem Projektstrukturplan.

Planungspakete

Planungspakete sind Platzhalter, die verwendet werden, um zusammengehörige Arbeit zu gruppieren, die noch nicht vollständig definiert wurde. Sie helfen Teams dabei, zukünftige Arbeit zu berücksichtigen, und lassen gleichzeitig Raum für zusätzliche Planung und weitere Aufgliederung im späteren Projektverlauf.

Planungspakete sind besonders bei komplexen oder dynamischen Projekten nützlich, bei denen nicht jede Anforderung von Anfang an bekannt ist.

Hierarchische Struktur

Ein PSP verwendet eine Eltern-Kind-Hierarchie, um die Arbeit von übergeordneten Lieferobjekten bis hin zu immer detaillierteren Komponenten zu organisieren. Die oberste Ebene stellt das Gesamtprojekt dar, während die darunterliegenden Ebenen die Arbeit in Phasen, Lieferobjekte, Steuerungskonten und Arbeitspakete aufgliedern.

Diese Struktur hilft Teams zu verstehen, wie einzelne Aufgaben mit umfassenderen Projektergebnissen zusammenhängen, und macht große Projekte leichter verwaltbar.

Aufgliederung

Aufgliederung bezeichnet den Prozess, bei dem übergeordnete Lieferobjekte in kleinere Komponenten zerlegt werden. Projektmanager gliedern die Arbeit so lange weiter auf, bis jedes Arbeitspaket klar genug ist, um es effektiv zu schätzen, zuzuweisen und zu verfolgen.

So könnte ein Lieferobjekt wie „Neugestaltung der Website“ beispielsweise in folgende Bestandteile aufgegliedert werden:

  • UX-Recherche
  • Wireframes
  • Frontend-Entwicklung
  • CMS-Migration
  • Qualitätssicherungstests

Das Ziel besteht darin, die Arbeit so weit aufzuteilen, dass Klarheit entsteht, ohne unnötigen Verwaltungsaufwand zu erzeugen.

Definition des Umfangs (100-%-Regel)

Einer der wichtigsten PSP-Grundsätze ist die 100-%-Regel. Sie besagt, dass der PSP 100 % des genehmigten Projektumfangs abbilden sollte – nicht mehr und nicht weniger.

Jedes Lieferobjekt, jedes Arbeitspaket und jede Aufgabe sollte sich lückenlos und überschneidungsfrei auf den Gesamtumfang des Projekts zurückführen lassen. Wenn eine Arbeit nicht im PSP enthalten ist, sollte sie nicht als Teil des Projekts betrachtet werden.

Zum Beispiel: Wenn die Lokalisierung einer mobilen App nicht in der WBS enthalten ist, nehmen Teams möglicherweise fälschlicherweise an, dass die Übersetzungsarbeit an anderer Stelle abgedeckt wird.

Diese Regel hilft, schleichende Ausweitung des Projektumfangs, doppelte Arbeit und Verwirrung unter den Stakeholdern zu reduzieren.

WBS-Codes

WBS-Codes sind das Nummerierungssystem, mit dem jedes Element innerhalb der Struktur identifiziert wird. Codes wie 1.0, 1.2 oder 1.2.3 erleichtern die Referenzierung von Arbeitspaketen in Zeitplänen, Budgets, Statusberichten und Gesprächen mit Stakeholdern.

Diese Kennungen werden bei großen oder funktionsübergreifenden Projekten zunehmend wertvoll, da Teams eine einheitliche Möglichkeit benötigen, zusammengehörige Arbeiten nachzuverfolgen.

Meilensteine

Meilensteine stellen wichtige Kontrollpunkte oder Abschlusspunkte innerhalb des Projekts dar. Anders als Arbeitspakete enthalten Meilensteine selbst keine Arbeit – sie zeigen an, dass ein wichtiges Ergebnis oder eine Phase abgeschlossen wurde.

Beispiele können sein:

  • Genehmigung durch die Stakeholder abgeschlossen
  • Designfreigabe abgeschlossen
  • Markteinführung des MVP abgeschlossen

Die Verknüpfung von Meilensteinen mit Ihrer WBS trägt dazu bei, dass die Projektberichterstattung an tatsächliche Ergebnisse und Fortschritte gebunden bleibt.

Abhängigkeiten

Abhängigkeiten definieren die Beziehungen zwischen Ergebnissen und Arbeitspaketen. Sie zeigen, welche Aktivitäten abgeschlossen sein müssen, bevor andere Arbeiten beginnen können.

Zum Beispiel: Die Frontend-Entwicklung kann von genehmigten UX-Designs abhängen, die Inhaltsmigration kann eine CMS-Konfiguration voraussetzen oder eine API-Integration kann vor Beginn der Bereitstellung die Genehmigung einer Sicherheitsprüfung erfordern.

Die frühzeitige Erfassung von Abhängigkeiten hilft Teams, Engpässe zu erkennen, Arbeiten korrekt zu sequenzieren und später im Projekt Terminkonflikte zu reduzieren.

WBS-Wörterbuch

Ein WBS-Wörterbuch ist ein unterstützendes Dokument, das jedes Element der WBS detaillierter definiert. Es umfasst typischerweise:

Ohne ein WBS-Wörterbuch ist Ihre WBS oft nur eine Liste von Bezeichnungen. Das Wörterbuch liefert den Kontext, den Teams benötigen, um die Arbeit einheitlich auszuführen.

Ein WBS-Wörterbuch ist besonders bei verteilten oder funktionsübergreifenden Teams nützlich, bei denen Annahmen und unklare Verantwortlichkeiten leicht zu Problemen bei der Umsetzung führen können.

So erstellen Sie eine Projektstruktur

Eine gute WBS organisiert nicht nur Aufgaben – sie wird zur Grundlage für Umfangsplanung, Terminplanung, Ressourcenzuweisung, Budgetierung und Projektverfolgung während der gesamten Umsetzung. Befolgen Sie diese Schritte, um eine glasklare WBS zu erstellen:

1. Projektumfang und Ergebnisse definieren

Bevor Sie Ihre WBS erstellen, prüfen Sie grundlegende Projektdokumente wie die Projektcharta, die Leistungsbeschreibung (SOW), die Anforderungsdokumentation und die Genehmigungen der Stakeholder. Diese Dokumente helfen dabei, frühzeitig die Grenzen des Projektumfangs, die Ergebnisse und die Erfolgskriterien zu definieren.

Beginnen Sie damit, die wichtigsten Ergebnisse zu identifizieren, die Ihr Projekt liefern soll. Sie sollten die Resultate, Systeme, Genehmigungen oder Ausgaben darstellen, die für den erfolgreichen Abschluss des Projekts erforderlich sind.

In dieser Phase geht es vor allem um Klarheit hinsichtlich des Projektumfangs. Bevor Sie Ihre WBS erstellen, stellen Sie sicher, dass Sie sich über Folgendes abgestimmt haben:

  • Was zum Projektumfang gehört
  • Was nicht zum Projektumfang gehört
  • Wer für jedes Ergebnis verantwortlich ist
  • Woran sich „abgeschlossen“ erkennen lässt
  • Wie Änderungen des Projektumfangs geprüft und genehmigt werden

Wenn Ihr Projektumfang in dieser Phase unklar ist, wird sich diese Unsicherheit auf Ihren Zeitplan, Ihr Budget und Ihren Ressourcenplan übertragen.

Ich finde WBS-Software bei Planungsworkshops besonders nützlich, weil funktionsübergreifende Teams einen visuellen Baum viel leichter prüfen können, als eine Tabellenkalkulation zu analysieren.

2. Ergebnisse in kleinere Arbeitspakete aufteilen

Sobald Ihre Liefergegenstände definiert sind, unterteilen Sie sie in sogenannte Arbeitspakete. Fahren Sie mit der Aufteilung der Arbeit fort, bis jedes Paket spezifisch genug ist, um es effektiv zu schätzen, zuzuweisen, zu planen und auszuführen.

Ein Liefergegenstand wie „Neugestaltung der Website“ könnte beispielsweise wie folgt unterteilt werden:

  • UX-Recherche
  • Drahtmodelle
  • Frontend-Entwicklung
  • CMS-Migration
  • Qualitätssicherungstests

Als allgemeine Regel sollten Arbeitspakete mindestens mehrere Stunden Aufwand umfassen, aber nicht so kleinteilig werden, dass die WBS schwer zu pflegen ist.

3. Arbeitsschritte sequenzieren und Abhängigkeiten identifizieren

Nachdem Sie die Arbeit aufgeteilt haben, organisieren Sie die Aufgaben in der Reihenfolge, in der sie erledigt werden müssen. Hier werden Abhängigkeiten entscheidend.

Zum Beispiel:

  • Die Frontend-Entwicklung kann von genehmigten Drahtmodellen abhängen
  • Die Inhaltsmigration kann von der CMS-Konfiguration abhängen
  • Qualitätssicherungstests können vom Abschluss der Funktionen abhängen

Wenn Sie Abhängigkeiten frühzeitig abbilden, können Sie Engpässe erkennen, Terminüberschneidungen reduzieren und einen realistischeren Zeitplan für die Lieferung erstellen.

4. Aufwand schätzen und Ressourcen zuweisen

Sobald die Struktur feststeht, schätzen Sie den erforderlichen Aufwand für jedes Arbeitspaket. Arbeiten Sie nach Möglichkeit mit den Personen zusammen, die die Arbeit ausführen – genaue Schätzungen entstehen selten isoliert.

In dieser Phase sollten Sie (oder Ihr Ressourcenmanager) außerdem:

  • die erforderlichen Fähigkeiten identifizieren
  • Verantwortliche zuweisen (unter Berücksichtigung der Ressourcenverfügbarkeit)
  • die Kapazität des Teams überprüfen
  • mögliche Probleme durch Überzuweisung kennzeichnen

Eine gut strukturierte WBS erleichtert die Ressourcenverwaltung und -planung erheblich, da die Arbeit bereits in klar definierte Einheiten gegliedert ist.

Nutzen Sie diese Tabelle, um zu verstehen, wie die WBS-Struktur die Ressourcenentscheidungen auf jeder Ebene beeinflusst:

WBS-EbeneBeispielelementAktivität der Ressourcenplanung
Ebene 1GesamtprojektGesamtzahl der Mitarbeitenden und Budgetzuweisung
Ebene 2Phase der FunktionsentwicklungTeamzuweisung nach Fachbereich
Ebene 3Frontend-EntwicklungStundenaufwand einzelner Mitarbeitender geschätzt
Ebene 4Navigationskomponente entwickelnBestimmter Entwickler zugewiesen, Aufwand bestätigt

5. Den Projektzeitplan erstellen

Ihre WBS bildet die Grundlage für Ihren Projektzeitplan. Jedes Arbeitspaket kann nun in geplante Aufgaben mit Dauer, Abhängigkeiten, Verantwortlichen und Fristen übertragen werden.

Beim Erstellen Ihres Zeitplans:

  • realistische Dauern festlegen
  • Aufgaben logisch sequenzieren
  • den kritischen Pfad identifizieren
  • den Zeitrahmen der Meilensteine validieren
  • die Liefererwartungen mit den Interessengruppen bestätigen

Ein Zeitplan, der auf einer detaillierten WBS basiert, ist wesentlich zuverlässiger als ein Zeitplan, der allein auf Annahmen auf hoher Ebene beruht.

Screenshot des Status von Arbeitspaketen und Meilensteinen
Beispiel einer WBS, die in einer Tabelle zur Projektplanung mit Zeitplanung, Meilensteinen, Verantwortlichkeiten und der Verfolgung des kritischen Pfads integriert ist.

6. Die Projektbasis festlegen

Sobald Umfang, Zeitplan und Budget genehmigt sind, legen Sie Ihre Projektbasis fest. Sie dient als Referenzpunkt, anhand dessen Sie die Leistung während des gesamten Projektlebenszyklus messen.

Ihre WBS unterstützt direkt:

  • Die Umfangsbasis
  • Die Terminplanbasis
  • Die Kostenbasis

Jede genehmigte Änderung des Projektumfangs sollte zunächst im WBS berücksichtigt werden, bevor Terminpläne oder Budgets aktualisiert werden. Wenn die Stakeholder mitten im Projekt ein neues Berichtsdashboard genehmigen, sollten sowohl der WBS als auch die Terminplanbasis aktualisiert werden, bevor die Arbeiten beginnen.

Verwenden Sie diese Tabelle, um zu sehen, wie die drei Basislinien mit Ihrem WBS verbunden sind:

Art der BasislinieWas sie erfasstVerbindung zum WBS
UmfangsbasisGenehmigte Liefergegenstände und ArbeitspaketeDirekt aus dem WBS abgeleitet
TerminplanbasisGenehmigte Start- und EndtermineAus WBS-Arbeitspaketen und Abhängigkeiten erstellt
KostenbasisGenehmigtes Budget je ArbeitspaketAus den Kostenschätzungen auf WBS-Ebene zusammengefasst

7. Überprüfen Sie den Plan mit den Stakeholdern und dem Projektteam

Bevor die Umsetzung beginnt, sollten Sie den fertiggestellten WBS und den Projektplan gemeinsam mit Ihrem Team und den Stakeholdern überprüfen, um die Abstimmung zu bestätigen und Unterstützung zu gewinnen.

Wenn Ihr Team den Aufgabenschätzungen im WBS nicht zustimmt, werden Sie bei der Umsetzung wahrscheinlich keinen Erfolg haben. Nehmen Sie sich ausreichend Zeit, den Arbeitsstrukturplan mit Ihrem Team zu überprüfen, um Abstimmung und Verantwortlichkeit zu fördern.

Diese Überprüfung hilft bei der Validierung von:

  • Vollständigkeit der Liefergegenstände
  • Logik der Reihenfolge
  • Annahmen zur Personalausstattung
  • Umsetzbarkeit des Terminplans
  • Klarheit der Zuständigkeiten

Es ist deutlich einfacher, Lücken frühzeitig zu erkennen, als sie während der Umsetzung korrigieren zu müssen.

So verwenden Sie einen Arbeitsstrukturplan

Ein WBS zahlt sich nur aus, wenn Sie ihn auch nach dem Projektstart weiter verwenden. Nutzen Sie ihn für diese sechs Aufgaben:

1. Sorgen Sie für Sichtbarkeit

Hängen Sie die einseitige Übersicht (Ebenen 1 und 2) in Ihrem Projektbereich, Ihrer Statusvorlage und Ihrer Präsentation zum Projektstart auf. Bewahren Sie die Details der Ebenen 3 und 4 für das Team auf. Wenn die Mitarbeitenden den WBS nicht innerhalb von zehn Sekunden finden können, wird er nicht genutzt.

2. Verwenden Sie ihn als Plausibilitätsprüfung für den Umfang

Wenn eine Anfrage eingeht, stellen Sie eine Frage: Ist sie im WBS enthalten? Wenn ja, handelt es sich um geplante Arbeit. Wenn nicht, ist es ein Änderungsantrag und kein Gefallen. Erfassen Sie ihn, schätzen Sie seinen Umfang und zeigen Sie, was sich dadurch verschiebt. „Ja, und hier ist, was dafür entfällt“ wird deutlich besser aufgenommen als ein schlichtes Nein.

3. Berichten Sie nach Liefergegenstand und nicht nach Aufgabe

Führungskräfte wollen nicht hören, dass 47 Tickets in Bearbeitung sind. Sie wollen wissen, ob der Zahlungsablauf fertig ist. Fassen Sie den Status auf Ebene der Liefergegenstände zusammen. Um das gefürchtete „90 % fertig“, das drei Wochen lang anhält, zu vermeiden, können Sie die 0/100-Regel anwenden: Ein Arbeitspaket ist so lange zu 0 % abgeschlossen, bis es fertiggestellt ist, und dann zu 100 %. Das ist strikt, aber ehrlich.

4. Prüfen Sie die Kapazität für jedes Arbeitspaket einzeln

Jedes Arbeitspaket hat eine verantwortliche Person, sodass Sie erkennen können, wer überlastet ist, bevor daraus eine Krise entsteht. Wenn ein Entwickler fünf Arbeitspakete besitzt, die in derselben Woche fällig sind, ist das ein Gespräch, das jetzt geführt werden sollte, nicht am Donnerstagabend vor dem Start.

5. Aktualisieren Sie den WBS vor dem Terminplan

Wenn eine Änderung genehmigt wird, überarbeiten Sie zuerst den WBS und anschließend den Terminplan und das Budget. Wenn Sie nur den Terminplan aktualisieren, ist der WBS nicht mehr die maßgebliche Quelle, und die 100-%-Regel wird unbemerkt verletzt.

6. Schließen Sie den Kreis, wenn das Projekt endet

Vergleichen Sie den geschätzten und den tatsächlichen Aufwand für jedes Arbeitspaket. Die Abweichungen zeigen Ihnen, wo Ihre Schätzungen zu hoch oder zu niedrig ausfallen. Speichern Sie den bereinigten WBS anschließend als Vorlage für das nächste ähnliche Projekt, damit Sie mit einem Vorsprung statt mit einer leeren Seite beginnen.

Vorlage für einen Arbeitsstrukturplan

Damit Sie direkt loslegen können, finden Sie hier eine kostenlos herunterladbare WBS-Vorlage. Um die Datei zu bearbeiten, laden Sie sie als XLSX-Datei herunter und verwenden Sie sie in Google Tabellen oder Excel. Die Datei enthält außerdem einen Beispiel-WBS, den Sie als Vorlage verwenden können.

Screenshot der Vorlage für die Arbeitsstruktur
Hier ist eine Vorschau auf unsere WBS-Vorlage – der andere Tab enthält eine ausgefüllte Version, damit du genau sehen kannst, wo was hingehört.

Plattformen für Projektmanagement

Projektmanagementplattformen mit nativer Unterstützung für Hierarchien ermöglichen es dir, deine WBS direkt in einen umsetzbaren Bereitstellungsplan zu verwandeln. Wenn sich deine Arbeitspakete in demselben Tool befinden, das dein Team für die Umsetzung verwendet, besteht ein deutlich geringeres Risiko, dass die WBS nicht mehr mit der tatsächlichen Projektarbeit übereinstimmt.

Diese Plattformen sind besonders nützlich für:

  • Verfolgung von Zuständigkeiten
  • Meilensteinmanagement
  • Abbildung von Abhängigkeiten
  • Ressourcenplanung
  • Fortschrittsberichte

Häufig gestellte Fragen zu Projektstrukturplänen

Dies sind die Fragen, die mir von Projektmanagern am häufigsten gestellt werden, wenn sie ihren ersten Projektstrukturplan erstellen oder mehr aus den bereits vorhandenen herausholen möchten:

Wer verwendet einen WBS?

Projektmanager, PMOs und Projektteams verwenden einen Projektstrukturplan, um Projektarbeit zu definieren, zuzuweisen und nachzuverfolgen. Projektmanager erstellen und pflegen ihn, während technische Leiter, Designer und die Qualitätssicherung ihn verwenden, um Arbeitspakete zu bestätigen und Schätzungen auf ihre Plausibilität zu prüfen. Ressourcenmanager verwenden ihn zur Kapazitätsplanung, Finanzteams nutzen ihn, um die Kostenbasis zusammenzufassen, und Führungskräfte, Kunden und Anbieter verwenden seine oberen Ebenen, um sich auf den Umfang zu einigen und Liefergegenstände nachzuverfolgen.

Der WBS hat seine Ursprünge in staatlichen und militärischen Programmen und ist im Bauwesen sowie im Ingenieurwesen Standard. Er ist gleichermaßen für Software-, Marketing- und Agenturprojekte nützlich – überall dort, wo sich die Arbeit über mehrere Fachbereiche erstreckt.

Sollte ich einen Projektstrukturplan oder ein Gantt-Diagramm verwenden?

Wie bei den meisten Dingen lautet die Antwort: Es kommt darauf an.

Wann Sie einen WBS verwenden sollten

Ein WBS zerlegt das, was Sie erstellen, in kleinere, besser handhabbare Komponenten. Er zeigt, was Sie in einem Projekt tun. Daher ist der WBS für die Steuerung des Umfangs nützlich, einschließlich des Änderungsmanagements.

Wann Sie ein Gantt-Diagramm verwenden sollten

Im Gegensatz dazu zeigt ein Gantt-Diagramm, wann Sie die Arbeit erledigen. Verwenden Sie Ihren WBS als Grundlage für Ihr Gantt-Diagramm, um Aufgaben über einen Zeitraum hinweg nachzuverfolgen. Das Gantt-Diagramm zeigt das Start- und Enddatum jeder Aufgabe, ihre Abhängigkeiten und ihre Beziehung zueinander. Sie verwenden ein Gantt-Diagramm zur Terminplansteuerung.

Sind ein WBS und die Methode des kritischen Pfads dasselbe?

Der kritische Pfad ist die Liste der zentralen Projektaktivitäten, die abgeschlossen werden müssen, um das Projekt innerhalb des magischen Dreiecks (Zeit, Budget und Umfang) zu liefern. Wenn sich der kritische Pfad verzögert, wirkt sich dies nachteilig auf einen dieser drei Bereiche Ihres Projekts aus.

Der WBS organisiert Projektaktivitäten und Liefergegenstände hierarchisch – nicht nur die Aktivitäten des kritischen Pfads.

Zu welchem Zeitpunkt im Projektlebenszyklus sollte ich den WBS erstellen?

Es ist wichtig, den WBS während der Projektplanungsphase zu erstellen, da er Ihnen hilft, die für die Durchführung des Projekts erforderliche Arbeit zu verstehen. Der WBS ist außerdem eine wichtige Grundlage für den Projektzeitplan, das Budget und den Risikomanagementplan, die alle bereits früher im Projektlebenszyklus benötigt werden.

Kann ich einen Projektstrukturplan in agilen Projekten verwenden?

Ja, ein WBS lässt sich gut mit einer agilen Umsetzung kombinieren, wenn Sie ihn auf der richtigen Ebene einsetzen. Definieren Sie Ihre übergeordneten Liefergegenstände und Arbeitspakete im WBS und überlassen Sie die Zerlegung auf Aufgabenebene der Sprintplanung. So erhalten Sie vollständige Transparenz über den Umfang, ohne Ihr Team zu stark einzuschränken. Viele Teams für digitale Produkte nutzen diesen hybriden Ansatz, um die Berichtserfordernisse der Stakeholder zu erfüllen und gleichzeitig die Umsetzung flexibel zu halten.

Wie gehe ich mit Umfangsänderungen um, nachdem der WBS als Basisplan festgelegt wurde?

Jede genehmigte Umfangsänderung sollte eine Aktualisierung des WBS auslösen, bevor die Arbeit beginnt. Das bedeutet, betroffene Arbeitspakete zu überarbeiten, das WBS-Wörterbuch zu aktualisieren und einen neuen Basisplan zu erstellen, wenn die Änderung erheblich genug ist. Das Überspringen dieses Schritts ist eine der schnellsten Möglichkeiten, die Kontrolle über Ihr Projekt zu verlieren. Ich empfehle, die Aktualisierung des WBS als erforderlichen Schritt in Ihre Checkliste für die Änderungssteuerung aufzunehmen – nicht als optionale Nachbereitung.

Wer sollte an der Erstellung eines Projektstrukturplans beteiligt sein?

Der Projektmanager leitet normalerweise die Entwicklung des WBS, aber die besten Ergebnisse entstehen, wenn die Personen beteiligt werden, die die Arbeit tatsächlich erledigen. Das bedeutet, technische Leiter, Designer, die Qualitätssicherung und alle anderen wichtigen Mitwirkenden während des Zerlegungsprozesses einzubeziehen. Bei einem Projekt zur Migration einer Plattform wird Ihr Infrastrukturteam beispielsweise Arbeitspakete identifizieren, an die Ihr PM niemals denken würde. Durch ihre Beiträge wird aus einer von oben nach unten erstellten Gliederung ein Plan, dem das gesamte Team vertraut.

 

 

Verbessern Sie Ihre Fähigkeiten in der Projektdurchführung und bei WBS

Wenn du exklusive Ressourcen, praktische WBS-Vorlagen und ein globales Netzwerk nutzen möchtest, um die Arbeitsstrukturplanung in echten Projekten zu meistern, tritt der Community von The Digital Project Manager bei.

sarah m. hoban photo

Sarah ist eine PMP-zertifizierte Projekt-/Programmmanagerin und Strategieberaterin mit 10 Jahren Erfahrung in der Leitung komplexer Projekte im Wert von mehreren Millionen Dollar und der Leitung verschiedener globaler Teams. Ihre Leidenschaft ist es, angesichts der Unsicherheit widerstandsfähig zu sein, und ihre Karriere hat sich (manchmal heimlich) darauf konzentriert, Techniken des Projektmanagements zur Verbesserung der organisatorischen Geschäftsprozesse einzusetzen. Sarah ist eine Denkerin im Projektmanagement und Autorin eines wöchentlichen Blogs und Podcasts, The Stealthy Project Manager, der sich auf Projektmanagement und Produktivität konzentriert.