Projektstrukturplan (WBS): Definition und Beispiele

Die meisten Projekte scheitern nicht daran, dass dem Team die Kompetenz fehlte, sondern weil der Projektumfang nie klar in Teile aufgeteilt wurde, die einzelne Personen tatsächlich verantworten konnten. Ein Projektstrukturplan (WBS) löst dieses Problem, indem er jedes Projekt in eine Hierarchie von Liefergegenständen zerlegt und jedem Arbeitspaket einen klaren Verantwortlichen, eine Schätzung und eine Definition of Done gibt.

Dieser Leitfaden erklärt, was ein WBS ist, welche Regeln ihn funktionierend machen, welche drei Formate es gibt und wie man ihn von Grund auf erstellt, mit konkreten Beispielen aus verschiedenen Branchen.

Was ist ein Projektstrukturplan?

Ein Projektstrukturplan ist eine hierarchische, liefergegenstandsorientierte Zerlegung des gesamten Projektumfangs in kleinere, handhabbare Teile. Jede Ebene der Hierarchie stellt eine granularere Definition des Projektergebnisses dar, bis hin zur kleinsten Einheit, die realistisch geschätzt und zugeordnet werden kann.

Der WBS wurde 1962 vom U.S. Department of Defense durch MIL-STD-881 formalisiert, ursprünglich um die Komplexität von Verteidigungsprogrammen wie Polaris und Apollo zu bewältigen. Das Project Management Institute hat ihn später als grundlegendes Werkzeug im PMBOK-Leitfaden verankert, und er ist heute branchenübergreifend Standard, vom Bauwesen bis zur Software.

Der entscheidende Unterschied: Ein WBS beschreibt Liefergegenstände, keine Aktivitäten. Die Frage lautet "Was produzieren wir?" und nicht "Was tun wir?" Diese Verschiebung verhindert Umfangsausweitung, denn sobald alle erforderlichen Liefergegenstände definiert sind, ist alles, was nicht im WBS steht, ausdrücklich außerhalb des Projektumfangs.

Ein WBS lässt sich natürlich mit einem Projektplan, einer RACI-Matrix für die Verantwortungszuordnung und einem Gantt-Diagramm für die Terminplanung verbinden. Er ist außerdem die Grundlage für Kostenschätzung, Risikoidentifikation und Ressourcenzuteilung.

Key Facts

• Das PMI führt den WBS als grundlegenden Liefergegenstand des Projektumfangsmanagements im PMBOK, 7. Auflage auf und beschreibt ihn als unverzichtbar für die Definition und Steuerung dessen, was in einem Projekt enthalten ist und was nicht.
• Der U.S. DoD MIL-STD-881, erstmals 1962 herausgegeben und 2025 auf Version 881F aktualisiert, bleibt der maßgebliche WBS-Standard für Verteidigungsbeschaffungsprogramme.
• Ein Wellingtone State of Project Management Report von 2024 ergab, dass nur 46 % der Organisationen einen WBS konsistent projektübergreifend einsetzen, was auf eine erhebliche Lücke zwischen Best Practice und Realität hinweist.

Die 100-Prozent-Regel und die 8/80-Regel

Die 100-Prozent-Regel

Die 100-Prozent-Regel ist das wichtigste Prinzip beim WBS-Design: Der WBS muss 100 % der im Projektumfang definierten Arbeit abdecken. Das bedeutet, dass jeder Liefergegenstand, jeder Teil-Liefergegenstand und jedes Arbeitspaket auf 100 % der übergeordneten Ebene aufaddiert wird, ohne Lücken und ohne Überschneidungen.

Wenn ein Liefergegenstand nicht im WBS steht, wird das Team ihn nicht planen, schätzen oder liefern. Wenn Arbeit an zwei Stellen erscheint, wird das Team Aufwand duplizieren oder über die Verantwortung streiten. Die 100-Prozent-Regel verhindert beide Probleme, indem sie den Scope auf jeder Ebene vollständig und sichtbar macht.

Die Prüfung ist unkompliziert: Für jedes übergeordnete Element sollte die Summe seiner untergeordneten Elemente genau 100 % des übergeordneten Elements ergeben. Wenn Sie auf Arbeit hinweisen können, die nirgendwo passt, oder auf zwei Einträge, die denselben Bereich abzudecken scheinen, muss die Struktur überarbeitet werden.

Die 8/80-Regel

Die 8/80-Regel ist eine praktische Größenrichtlinie für Arbeitspakete: Kein Arbeitspaket sollte kleiner als 8 Stunden oder größer als 80 Stunden Aufwand sein. Pakete unter 8 Stunden erzeugen Verwaltungsaufwand ohne nennenswerten Erkenntnisgewinn. Pakete über 80 Stunden sind zu groß, um sie zuverlässig zu schätzen oder genau zu verfolgen.

Die Regel ist eine Faustregel, kein Gesetz. Ein zweiwöchiges Projekt könnte einen Bereich von 4 bis 40 Stunden verwenden, während ein mehrjähriges Programm Pakete bis zu 160 Stunden erlauben kann. Die Absicht ist dieselbe: Arbeitspakete klein genug halten, um sie zu schätzen, einem Verantwortlichen zuzuordnen und innerhalb einer einzigen Berichtsperiode abzuschließen.

WBS-Ebenen und Komponenten

Ebene 1 ist das Projekt selbst. Es gibt genau ein Element auf dieser Ebene.

Ebene 2 stellt Hauptliefergegenstände oder Phasen dar. Bei einem liefergegenstandsbasierten WBS sind das greifbare Ergebnisse (Discovery, Design, Build, Launch). Bei einem phasenbasierten WBS sind es Projektphasen. Beide sind gültig; liefergegenstandsbasiert ist in der Regel beständiger, weil sich Phasen ändern, Ergebnisse aber nicht.

Ebene 3 und darunter sind zunehmend feinere Zerlegungen, bis man bei Arbeitspaketen ankommt: der untersten Ebene, auf der Arbeit geplant, geschätzt und zugeordnet wird. Ein Arbeitspaket sollte von einer Person oder einem Team innerhalb des 8/80-Stunden-Rahmens abgeschlossen werden können.

Das WBS-Lexikon ist ein ergänzendes Dokument, das jedes Element definiert: seine Beschreibung, Akzeptanzkriterien, zugeordneten Verantwortlichen, geschätzten Aufwand, benötigte Ressourcen und Vorgänger- und Nachfolger-Abhängigkeiten. Ohne das Lexikon ist der WBS eine Struktur ohne Substanz. Der WBS ist die Karte, das Lexikon ist die Legende.

3 WBS-Typen (Baum, Liste, Tabelle)

Baum (Organigramm-Stil)

Das Baumformat sieht wie ein Organigramm aus, mit dem Projekt an der Spitze und jeder Ebene, die nach unten verzweigt. Es ist das visuell intuitivste Format und macht die Hierarchie sofort deutlich.

Nutzen Sie das Baumformat für Stakeholder-Präsentationen, Kickoff-Meetings und alle Situationen, in denen Sie die gesamte Scope-Struktur auf einen Blick kommunizieren müssen. Die Einschränkung ist der Platz: Große Projekte mit vielen Arbeitspaketen werden in einem einzelnen Diagramm schwer lesbar.

Beispiel-Baum: Projekt an der Spitze, drei Liefergegenstand-Boxen in der Mitte, sechs Arbeitspaket-Boxen unten, durch Linien verbunden.

Eingerückte Liste (Gliederungsformat)

Die eingerückte Liste formatiert den WBS als nummerierte Gliederung. Sie ist kompakt, lässt sich in jedem Textverarbeitungsprogramm oder Projektwerkzeug erstellen und ist einfach in einer Klartextdatei zu versionieren.

1.0 Website-Redesign
  1.1 Discovery
    1.1.1 Stakeholder-Interviews
    1.1.2 Wettbewerbsanalyse
  1.2 Design
    1.2.1 Wireframes
    1.2.2 Visuelles Design

Nutzen Sie das Listenformat für Dokumentation, detaillierte Planungssitzungen und wenn Sie den WBS in einem textbasierten Tool teilen müssen. Es harmoniert gut mit Standard Operating Procedures, die auf spezifische Liefergegenstände nach WBS-Code verweisen.

Tabellarisch

Das tabellarische Format präsentiert den WBS als Tabelle. Jede Zeile ist ein WBS-Element mit Spalten für Code, Liefergegenstandsname, Verantwortlichen, geschätzte Stunden und Status.

Nutzen Sie das tabellarische Format, wenn der WBS direkt in Ressourcenplanung, Kostenschätzung oder Projektverfolgung einfließt. Es lässt sich sauber in Tabellenkalkulationen und die meisten Projektmanagement-Tools integrieren.

So erstellen Sie einen WBS in 6 Schritten

Schritt 1: Das Projektziel definieren

Beginnen Sie mit dem Projektauftrag oder der Umfangsbeschreibung. Sie brauchen einen Satz, der den endgültigen Liefergegenstand des Projekts definiert: "Launch einer neu gestalteten Unternehmenswebsite bis Q4 2026." Ohne ein klares Ziel wird der WBS von Stakeholdern, die Scope hinzufügen, in alle Richtungen gezogen.

• Bestätigen Sie das Projektziel mit dem Auftraggeber.
• Legen Sie fest, wie Erfolg aussieht (Akzeptanzkriterien).
• Dokumentieren Sie, was ausdrücklich außerhalb des Scope liegt.

Schritt 2: Hauptliefergegenstände (Phasen) identifizieren

Unterteilen Sie das Projekt in 4 bis 8 Hauptliefergegenstände oder Phasen. Diese werden zu Ebene 2 im WBS. Bei den meisten Projekten ergeben sich natürliche Phasen aus der Arbeit: Discovery, Design, Entwicklung, Test, Deployment und Übergabe.

• Listen Sie alle Hauptergebnisse auf, die das Projekt produzieren muss.
• Fassen Sie verwandte Ergebnisse zusammen, wenn es auf dieser Ebene mehr als 8 gibt.
• Vermeiden Sie es, Liefergegenstände und Phasen im selben WBS zu mischen, es sei denn, die Projektstruktur erfordert es.

Schritt 3: In Arbeitspakete zerlegen

Nehmen Sie jeden Ebene-2-Liefergegenstand und unterteilen Sie ihn in Teil-Liefergegenstände, bis Sie den 8/80-Stunden-Schwellenwert erreichen. Das ist der zeitaufwendigste Schritt, und hier passieren die meisten WBS-Fehler.

• Einen Zweig nach dem anderen von oben nach unten zerlegen.
• Aufhören, wenn ein Liefergegenstand einem einzigen Verantwortlichen zugewiesen und zuverlässig geschätzt werden kann.
• Nicht tiefer zerlegen als die Ebene, auf der tatsächlich nachverfolgt wird.

Schritt 4: Die 100-Prozent-Regel anwenden

Überprüfen Sie, ob jede Ebene zu 100 % ihres übergeordneten Elements aufaddiert. Jeden Zweig durchgehen und fragen: "Gibt es Arbeit, die zur Produktion dieses Liefergegenstands erforderlich ist und hier nicht erfasst ist?" Falls ja, ergänzen. Falls sich zwei Einträge überschneiden, zusammenführen oder aufteilen.

• Auf fehlende Liefergegenstände prüfen (Lücken).
• Auf doppelte Liefergegenstände prüfen (Überschneidungen).
• Bestätigen, dass Arbeit, die nicht im WBS steht, ausdrücklich außerhalb des Scope liegt.

Schritt 5: Das WBS-Lexikon erstellen

Für jedes Arbeitspaket dokumentieren: Beschreibung, Verantwortlicher, geschätzter Aufwand, erforderliche Eingaben, Liefergegenstandskriterien und Abhängigkeiten. Das Lexikon verwandelt den WBS von einem Diagramm in einen Vertrag.

• Eine konsistente Vorlage für jeden Eintrag verwenden.
• Jedem Element einen eindeutigen WBS-Code zuweisen (z. B. 1.2.3).
• Das Lexikon mit dem Projektplan und dem Terminplan verknüpfen.

Schritt 6: Baseline festlegen und aktualisieren

Sobald der Auftraggeber den WBS und das Lexikon genehmigt, liegt eine Umfangs-Baseline vor. Jede Änderung an einem Arbeitspaket erfordert nun eine formale Änderungssteuerung.

• Die Baseline-Version mit Datumsstempel speichern.
• Den WBS aktualisieren, wenn genehmigte Umfangsänderungen eintreten.
• Änderungen an alle Stakeholder kommunizieren, die betroffene Arbeitspakete verantworten.

WBS-Beispiele nach Branchen

Website-Redesign

Eingerückte Liste:

1.0 Website-Redesign
  1.1 Discovery
    1.1.1 Stakeholder-Interviews
    1.1.2 Wettbewerbsanalyse
  1.2 Design
    1.2.1 Wireframes
    1.2.2 Visuelles Design
    1.2.3 Komponentenbibliothek
  1.3 Build
    1.3.1 Frontend-Entwicklung
    1.3.2 CMS-Konfiguration
  1.4 Launch
    1.4.1 QA-Tests
    1.4.2 Go-Live-Deployment

Software-Release

1.0 Software v2.0 Release
  1.1 Anforderungen
    1.1.1 Funktionsspezifikationen
    1.1.2 Akzeptanzkriterien
  1.2 Entwicklung
    1.2.1 Backend-API-Änderungen
    1.2.2 Frontend-UI-Updates
    1.2.3 Datenbankmigrationen
  1.3 Tests
    1.3.1 Unit-Tests
    1.3.2 Integrationstests
    1.3.3 UAT
  1.4 Release
    1.4.1 Release Notes
    1.4.2 Produktions-Deployment

Büroumzug

1.0 Büroumzug
  1.1 Planung
    1.1.1 Grundrissplanung
    1.1.2 Lieferantenauswahl
  1.2 Logistik
    1.2.1 IT-Infrastrukturumzug
    1.2.2 Möbeltransport
  1.3 Einrichtung
    1.3.1 Arbeitsplatzkonfiguration
    1.3.2 Netzwerktests
  1.4 Abschluss
    1.4.1 Stilllegung des alten Büros
    1.4.2 Adressänderungsmeldungen

WBS vs. Projektterminplan vs. Gantt-Diagramm

Diese drei Instrumente ergänzen sich, sind aber nicht austauschbar. Viele Teams überspringen den WBS und gehen direkt zum Gantt-Diagramm, was bedeutet, dass sie Arbeit terminieren, die noch nicht vollständig definiert ist.

Der WBS speist den Terminplan: Wenn alle Arbeitspakete vorliegen, werden sie sequenziert, mit Dauern versehen und Ressourcen zugewiesen, um den Terminplan zu erstellen. Das Gantt-Diagramm ist der Terminplan als Balkenvisualisierung auf einer Zeitachse.

Mehr über Sequenzierung und visuelle Planung finden Sie im Leitfaden zu Kanban und Waterfall-Methodik.

Best Practices und häufige Fehler

Best Practices:

• Liefergegenstände, keine Aktivitäten. Der WBS beantwortet "Was produzieren wir?" Wenn ein Element wie ein Verb klingt (z. B. "Interviews durchführen"), als Liefergegenstand umformulieren (z. B. "Interview-Ergebnisbericht").
• Ein Verantwortlicher pro Arbeitspaket. Wenn zwei Personen die Verantwortung teilen, das Paket aufteilen oder einen Hauptverantwortlichen mit unterstützenden Mitwirkenden im Lexikon festhalten.
• Richtige Detailtiefe. Mit dem Zerlegen aufhören, wenn ein Arbeitspaket den 8/80-Stunden-Schwellenwert erfüllt und ein klares Akzeptanzkriterium hat. Zu feine Zerlegung erzeugt Bürokratie ohne Erkenntnisgewinn.
• WBS-Lexikon ist unverzichtbar. Ein Diagramm ohne Lexikon lässt zu viel Interpretationsspielraum.
• Das Team einbeziehen. WBS-Sitzungen, die allein vom Projektmanager durchgeführt werden, erzeugen blinde Flecken. Die Personen, die die Arbeit erledigen, wissen, was die Arbeit wirklich erfordert.

Häufige Fehler:

• Aktivitäten statt Liefergegenstände aufnehmen. "Code schreiben" statt "Backend-API-Modul" einzutragen führt zu einem Terminplan, der als WBS getarnt ist.
• Verwaiste Arbeit. Arbeit, die geleistet wird, aber in keinem WBS-Element erfasst ist, ist für Planung, Schätzung und Änderungssteuerung unsichtbar.
• Überschneidungen zwischen Arbeitspaketen. Zwei Pakete, die dasselbe Ergebnis abdecken, verursachen Verwirrung und Doppelzählung bei Schätzungen.
• Die 100-Prozent-Prüfung überspringen. Die meisten Scope-Lücken werden erst nach Projektstart entdeckt, wenn der fehlende Liefergegenstand zur Krise wird.
• Die Baseline nie aktualisieren. Ein WBS, der genehmigte Scope-Änderungen nicht widerspiegelt, wird ungenau, und das Team hört auf, ihm zu vertrauen.

Der WBS ergänzt auch Business-Process-Management Praktiken: Wenn Prozesse und Projektumfang gemeinsam dokumentiert werden, lässt sich genau erkennen, wo Projektergebnisse mit dem laufenden Betrieb übereinstimmen müssen.

Häufig gestellte Fragen

Was ist die 100-Prozent-Regel beim WBS?

Die 100-Prozent-Regel besagt, dass der WBS 100 % des Projektumfangs abdecken muss. Jeder Liefergegenstand, Teil-Liefergegenstand und jedes Arbeitspaket auf jeder Ebene muss zu 100 % der auf der übergeordneten Ebene definierten Arbeit aufaddieren, ohne Lücken und ohne Doppelungen. Wenn Arbeit nicht im WBS steht, wird sie nicht geplant, geschätzt oder gesteuert.

Was ist die 8/80-Regel?

Die 8/80-Regel ist eine Größenfaustregel für Arbeitspakete: Kein Paket sollte kleiner als 8 Stunden oder größer als 80 Stunden Aufwand sein. Pakete unter 8 Stunden erzeugen unnötigen Verwaltungsaufwand; Pakete über 80 Stunden sind zu groß, um sie zuverlässig zu schätzen. Die Regel stellt sicher, dass Arbeitspakete innerhalb eines einzigen Berichtszyklus handlungsfähig und nachverfolgbar sind.

Was ist der Unterschied zwischen einem WBS und einem Projektterminplan?

Ein WBS definiert, was produziert werden muss (Liefergegenstände und Arbeitspakete). Ein Projektterminplan definiert, wann jedes Arbeitspaket stattfinden wird und in welcher Reihenfolge. Der WBS kommt zuerst: Ohne ein vollständiges Bild des Scope lässt sich kein verlässlicher Terminplan erstellen. Der WBS speist außerdem Kostenschätzungen und Ressourcenpläne, während der Terminplan sich auf die Zeit konzentriert.

Sollte ein WBS Aufgaben oder Liefergegenstände zeigen?

Nur Liefergegenstände. Das ist das häufigste WBS-Missverständnis. Aufgaben beschreiben Aktivitäten ("Code schreiben"), während Liefergegenstände Ergebnisse beschreiben ("Backend-API-Modul"). Ein liefergegenstandsbasierter WBS ist im Laufe der Zeit beständiger, weil er sich nicht ändert, wenn das Team seinen Ansatz zur Erstellung des Ergebnisses ändert.

Welche Tools kann ich zum Erstellen eines WBS verwenden?

Ein WBS lässt sich in nahezu jedem Tool erstellen. Gängige Optionen sind Lucidchart oder Miro für visuelle Baumdiagramme, Excel oder Google Sheets für tabellarische Formate und dedizierte Projektmanagement-Tools wie MS Project, Asana oder Jira für integrierte Planung. Für einfache Projekte reicht eine einfache Textgliederung in jedem Editor. Das Format ist weniger wichtig als die Disziplin: vollständiger Scope, keine Lücken, keine Überschneidungen und ein WBS-Lexikon als Absicherung.

Einen WBS zu erstellen ist das deutlichste Signal, dass Ihre Projektmanagement-Kompetenz in Scope-Disziplin verwurzelt ist und nicht in Terminplan-Optimismus. Die Struktur richtig aufzubauen, bevor der Zeitplan erstellt wird, macht den Rest des Plans wesentlich leichter zu verteidigen.