Kapitel 4: Projektstrukturplan (PSP/WBS)

Lernziele

Das Konzept des Projektstrukturplans (PSP/WBS) verstehen
Einen PSP systematisch erstellen und validieren können
Die Bedeutung des PSP für Kosten- und Terminplanung erkennen

Einleitung: Die Zerlegung des Elefanten

"Alles in einem Schritt lösen – das ist der sicherste Weg zum Scheitern." Das mag trivial klingen, aber in der Praxis versuchen viele Projektmanager, komplexe Projekte in einem einzigen, undurchsichtigen Arbeitsschritt zu planen. Der Projektstrukturplan (deutsch: PSP, englisch: Work Breakdown Structure – WBS) ist das Werkzeug, das komplexe Projekte in handliche, steuerbare Arbeitpakete zerlegt.

Warum Zerlegung wichtig ist

Ein Kunde bittet um ein "E-Commerce-System". Ein Unerfahrener kalkuliert pauschal: "50.000 €, 6 Monate." Ein Erfahrener erstellt zuerst einen PSP: - Anforderungen analysieren (1 Woche) - Shop-Frontend entwickeln (8 Wochen) - Payment-Integration (4 Wochen) - Backend-API entwickeln (6 Wochen) - Datenbank designen (2 Wochen) - Testing & QA (4 Wochen) - Deployment & Go-Live (1 Woche) Ergebnis: 26 Wochen, nicht 24. Und detaillierte Kostenbasis.

Was ist ein Projektstrukturplan?

Definition

Der Projektstrukturplan (PSP) ist eine hierarchische Gliederung aller Arbeiten, die zur Erreichung der Projektziele erforderlich sind. Er bildet das "Was" des Projektes ab – alle Aufgaben, Meilensteine und Deliverables.

Kernmerkmale eines PSP

Merkmal	Beschreibung
Hierarchisch	Vom Gesamten zum Detail, von oben nach unten
Einzigartig	Jedes Element nur ein Mal im PSP
Vollständig	Alle Projektaufgaben erfasst
Messbar	Aufgaben sind klar definiert und abgrenzbar
Transparent	Struktur ist für alle Stakeholder verständlich

PSP vs. Zeitplan: Der fundamentale Unterschied

PSP (Projektstrukturplan)	Zeitplan / Ablaufplan
Was wird gemacht?	Wann wird es gemacht?
Aufgabengliederung	Zeitliche Reihenfolge
Basis für Kostenplanung	Basis für Steuerung
Statisch (in der Regel)	Dynamisch (aktualisiert)
Keine Zeitdimension	Zeitdimension essenziell

PSP kommt zuerst

Erstellen Sie zuerst den PSP, dann den Zeitplan. Der PSP ist die Basis für alle weiteren Planungen: Kosten, Ressourcen, Risiken, Qualität.

Die zwei PSP-Prinzipien

Prinzip 1: FBS (Funktionale Gliederung)

Gliederung nach Funktionen / Produktbereichen.

Beispiel E-Commerce-Projekt:

E-Commerce-System
├── Shop-Frontend
│   ├── Benutzerregistrierung
│   ├── Produktsuche
│   ├── Warenkorb
│   └── Checkout
├── Backend-API
│   ├── Benutzer-Management
│   ├── Produkt-Management
│   ├── Bestell-Management
│   └── Payment-Integration
└── Admin-Panel
    ├── Produktpflege
    ├── Bestellübersicht
    └── Berichte

Prinzip 2: PBS (Phasenorientierte Gliederung)

Gliederung nach Projektphasen / Prozessschritten.

Beispiel nach Phasen:

E-Commerce-Projekt
├── Analyse-Phase
│   ├── Anforderungen erheben
│   ├── Stakeholder-Interviews
│   └── Ist-Analyse
├── Design-Phase
│   ├── Architektur-Design
│   ├── UI/UX-Design
│   └── Datenbank-Design
├── Entwicklungs-Phase
│   ├── Frontend-Entwicklung
│   ├── Backend-Entwicklung
│   └── Integration
└── Test-Phase
    ├── Unit-Tests
    ├── Integration-Tests
    └── User-Acceptance-Tests

Hybride Gliederung: Der goldene Mittelweg

In der Praxis werden FBS und PBS oft kombiniert.

mindmap
  root((E-Commerce-Projekt))
    Phase 1: Analyse
      Stakeholder-Interviews
      Anforderungsdokument
    Phase 2: Design
      Architektur
      UI/UX
    Phase 3: Entwicklung
      Frontend
      Backend
      Integration
      Shop-Frontend
      Admin-Panel
      APIs
    Phase 4: Testing
      Unit-Tests
      UAT
    Phase 5: Deployment
      Staging
      Production

Arbeitsebenen des PSP

Ein PSP hat typischerweise 3-5 Ebenen. Jede Ebene repräsentiert ein anderes Detaillierungsgrad.

Beispiel: 4 Ebenen

Ebene	Beispiel	Detaillierungsgrad	Typischer Zeitrahmen
Ebene 1	E-Commerce-System	Gesamtes Projekt	Monate bis Jahre
Ebene 2	Shop-Frontend	Hauptkomponente	Wochen bis Monate
Ebene 3	Produktsuche-Funktion	Unterkomponente	Tage bis Wochen
Ebene 4	Suche implementieren (SQL)	Konkrete Aufgabe	Stunden bis Tage

Die 100%-Regel

Alle Ebenen zusammen ergeben 100% des Projektaufwands. Keine Aufgabe ist "vergessen", keine Aufgabe ist doppelt.

!!! example "Praxis-Beispiel: Software-Release PSP**

Software-Release 2.0 (Ebene 1)
├── Feature-Entwicklung (Ebene 2)
│   ├── Neues Login-System (Ebene 3)
│   │   ├── Frontend-Komponenten (Ebene 4)
│   │   ├── Backend-API (Ebene 4)
│   │   └── Integration Tests (Ebene 4)
│   └── Dashboard-Erweiterung (Ebene 3)
│       ├── Datenbank-Migration (Ebene 4)
│       └── UI-Updates (Ebene 4)
├── Bugfixing (Ebene 2)
│   ├── Kritische Bugs (Ebene 3)
│   └── Kleinere Issues (Ebene 3)
└── Deployment (Ebene 2)
    ├── Staging-Bereitstellung (Ebene 3)
    └── Production-Release (Ebene 3)

Arbeitselemente des PSP

Typen von Arbeitselementen

Arbeitspakete (Work Packages)
Kleinste steuerbare Einheiten
Eindeutiger Verantwortlicher
Messbarer Fortschritt
Abgeschlossene Deliverables
Meilensteine (Milestones)
Signifikante Ereignisse
Keine Dauer (Zeitpunkt)
Typisch: Projektabschluss, Phasenende, Abnahme
Zwischenprodukte (Deliverables)
Ergebnisse von Arbeitpaketen
Dokumente, Software, Hardware
Projektebene (Summary Element)
Zusammenfassung von Arbeitselementen
Keine direkte Zuweisung von Ressourcen

Unterschied: Arbeitspaket vs. Meilenstein

Kriterium	Arbeitspaket	Meilenstein
Natur	Tätigkeit	Ergebnis / Ereignis
Dauer	Hat Zeitdauer	Zeitpunkt, keine Dauer
Messbar	Fortschritt messbar	Ja / Nein
Beispiel	"Login-Implementierung"	"Login-Feature freigegeben"

gantt
    title Arbeitspaket vs. Meilenstein
    dateFormat  YYYY-MM-DD
    section Arbeitspaket
    Login implementieren       :a1, 2026-01-01, 7d
    section Meilenstein
    Login-Feature freigegeben :milestone, m1, 2026-01-08, 0d
    section Weiteres Paket
    Testing Login-Funktion    :a2, after m1, 5d

Schritt-für-Schritt: PSP erstellen

Schritt 1: Projektumfang definieren

Klären Sie, was zum Projekt gehört – und was nicht.

Projektumfang definieren: - Was ist "in scope"? - Was ist "out of scope"? - Was sind die kritischen Deliverables?

!!! example "Scope-Bestimmung Projekt: CRM-System In Scope: - Kontakte verwalten - Verkaufschancen tracken - Berichte erstellen Out of Scope:** - Marketing-Automatisierung (anderes System) - ERP-Integration (Phase 2)

Schritt 2: Erste Gliederung (Ebene 1-2)

Erstellen Sie die grobe Struktur des Projekts.

Frage: Welche Hauptkomponenten oder Phasen gibt es?

Schritt 3: Aufschlüsselung (Ebene 3-4)

Zerlegen Sie die Elemente weiter bis zu Arbeitsebene.

Regel: Brechen Sie auf, bis Aufgaben einem einzelnen Verantwortlichen zugewiesen werden können.

Schritt 4: Validierung

Prüfen Sie den PSP: - Vollständig? Haben wir nichts vergessen? - Eindeutig? Gibt es doppelte Elemente? - Messbar? Können wir Fortschritt messen? - Steuerbar? Sind Aufgaben zu groß?

Schritt 5: Arbeitselemente charakterisieren

Für jedes Element: - Dauer schätzen - Ressourcen zuweisen - Abhängigkeiten identifizieren - Risiken bewerten

PSP als Basis für Kostenplanung

Der PSP ist die direkte Basis für den Projektbudgetrahmen.

Vom PSP zum Budget

Arbeitsebene identifizieren (z. B. alle Ebene 3-Arbeitspakete)
Dauer schätzen (in Tagen oder Stunden)
Stundensatz anwenden (pro Rolle)
Summen bilden (aufsteigend bis Ebene 1)

Beispiel:

Ebene 3-Arbeitspaket	Dauer	Rolle	Stundensatz	Kosten
Frontend-Komponenten	40h	Senior Dev	80 €/h	3.200 €
Backend-API	60h	Senior Dev	80 €/h	4.800 €
Testing	20h	QA Engineer	60 €/h	1.200 €
Summe Ebene 2				9.200 €

!!! warning "Schätzungstoleranzen beachten** Schätzungen haben Unsicherheiten. Berücksichtigen Sie Puffer: - Ebene 1: ± 20-30% - Ebene 2: ± 15-20% - Ebene 3: ± 10-15% - Ebene 4: ± 5-10%

PSP in agilen Projekten

Kann man in agilen Projekten (Scrum, Kanban) einen PSP verwenden? Absolut.

Scrum-Backlog als PSP

Der Product Backlog ist im Grunde ein PSP – er listet alle Aufgaben auf, die für das Projekt erforderlich sind.

Anpassung: - Ebene 1: Epic (z. B. "E-Commerce-System") - Ebene 2: Feature (z. B. "Shop-Frontend") - Ebene 3: User Story (z. B. "Als Kunde kann ich Produkte suchen") - Ebene 4: Tasks (z. B. "Implementiere Such-API")

Scrum-spezifische PSP-Elemente

Element	PSP-Entsprechung
Sprint	Zeitbox für eine PSP-Ebene
Sprint Goal	Zusammenfassung der Aufgaben
Velocity	Schätzung der PSP-Aufwandsumme

Agile Nuance

In Scrum ist der PSP nicht statisch – er wird kontinuierlich angepasst. Neue User Stories werden hinzugefügt, priorisiert oder entfernt. Die Grundprinzipien (Vollständigkeit, Eindeutigkeit) bleiben jedoch erhalten.

Typische PSP-Fehler

Fehler 1: Zu tief gegangen

Problem: PSP hat 10 Ebenen, 1.000 Elemente.

Auswirkung: Nicht mehr steuerbar, Overhead überwiegt.

Lösung: Halten Sie 3-4 Ebenen. Brechen Sie nur auf, bis Aufgaben zuweisbar sind.

Fehler 2: Zu grob gegangen

Problem: PSP hat nur 2 Ebenen, keine konkreten Aufgaben.

Auswirkung: Keine Basis für Kosten- und Terminplanung.

Lösung: Zerlegen Sie bis zu einer granularen Ebene.

Fehler 3: Unvollständig

Problem: Aufgaben vergessen (z. B. Testing, Deployment).

Auswirkung: Kosten unterschätzt, Verzögerungen.

Lösung: Nutzen Sie Checklisten für typische Phasen (Analyse, Design, Entwicklung, Testing, Deployment).

Fehler 4: Abhängigkeiten ignoriert

Problem: PSP listet Aufgaben, aber keine logischen Abhängigkeiten.

Auswirkung: Zeitplan unrealistisch, Konflikte bei der Reihenfolge.

Lösung: Identifizieren Sie Abhängigkeiten (A muss vor B geschehen), bereits im PSP.

PSP-Template für Software-Projekte

Nutzen Sie dieses Template als Ausgangspunkt:

Software-Projekt [Ebene 1]
├── Projektmanagement [Ebene 2]
│   ├── Projektplanung [Ebene 3]
│   ├── Status-Reporting [Ebene 3]
│   └── Stakeholder-Management [Ebene 3]
├── Analyse & Requirements [Ebene 2]
│   ├── Stakeholder-Interviews [Ebene 3]
│   ├── Anforderungsdokument [Ebene 3]
│   └── Use-Cases definieren [Ebene 3]
├── Design [Ebene 2]
│   ├── Architektur-Design [Ebene 3]
│   ├── UI/UX-Design [Ebene 3]
│   └── Datenbank-Design [Ebene 3]
├── Entwicklung [Ebene 2]
│   ├── Frontend-Entwicklung [Ebene 3]
│   ├── Backend-Entwicklung [Ebene 3]
│   └── Integration [Ebene 3]
├── Testing [Ebene 2]
│   ├── Unit-Tests [Ebene 3]
│   ├── Integration-Tests [Ebene 3]
│   └── User-Acceptance-Tests [Ebene 3]
└── Deployment & Go-Live [Ebene 2]
    ├── Staging-Bereitstellung [Ebene 3]
    ├── Production-Deployment [Ebene 3]
    └── Monitoring-Setup [Ebene 3]

Zusammenfassung

Der Projektstrukturplan (PSP/WBS) ist das Fundament jeder Projektplanung. Er zerlegt komplexe Projekte in handliche Aufgaben und bildet die Basis für Kosten-, Ressourcen- und Terminplanung.

Kernprinzipien:

Hierarchische Gliederung: Vom Gesamten zum Detail (3-5 Ebenen)
100%-Regel: Alle Aufgaben erfasst, keine Doppelungen
Einzigartigkeit: Jedes Element nur einmal im PSP
Vollständigkeitsprüfung: Systematisch auf vergessene Aufgaben prüfen
Validierung: PSP auf Fehler und Konsistenz prüfen
Basis für Folgeplanungen: Kosten, Ressourcen, Risiken, Qualität

Ein guter PSP macht das Unsichtbare sichtbar. Er transformiert ein vages "Baue mir ein System" in ein konkretes, planbares Projekt mit klaren Meilensteinen und Budgetrahmen. Ohne PSP ist Projektplanung Schätzung im Dunkeln – mit PSP wird sie zur methodischen Disziplin.

Nächstes Kapitel: Ablaufplanung