Was ist ein Projektstrukturplan?
Der Projektstrukturplan, kurz PSP, im Englischen Work Breakdown Structure, ist die hierarchische Zerlegung des gesamten Projektumfangs. Auf der obersten Ebene steht das Projekt, darunter folgen Teilprojekte oder Hauptergebnisse, dann Teilaufgaben und auf der untersten Ebene die Arbeitspakete. Das Project Management Institute beschreibt den Strukturplan in seinem Praxisstandard als Werkzeug, das den gesamten Umfang eines Projekts organisiert und die für den genehmigten Umfang festgelegte Arbeit abbildet [1].
Der Strukturplan beantwortet die Frage, was zu tun ist. Wann es zu tun ist, klärt erst der Terminplan, der auf dem Strukturplan aufbaut, siehe Terminplanung mit Netzplan und kritischem Pfad. Diese Trennung ist wichtig: Wer Struktur und Termine gleichzeitig plant, vermischt zwei Fragen und übersieht leicht Arbeit, die keinen offensichtlichen Platz im Zeitablauf hat, etwa Projektmanagement, Qualitätssicherung oder Schulung.
Seit der dritten Auflage seines Praxisstandards von 2019 wendet das PMI den Strukturplan ausdrücklich auch auf agile, iterative und inkrementelle Lebenszyklen an, nicht nur auf klassisch geplante Projekte [1]. In agilen Projekten zerlegt der Strukturplan typischerweise in Releases, Epics und Features, während die Detailplanung in Sprints erfolgt.
Welche Regeln gelten für einen guten Strukturplan?
- 100-Prozent-Regel: Die Elemente einer Ebene decken zusammen genau den Umfang des übergeordneten Elements ab, nicht mehr und nicht weniger.
- Ergebnisse statt Tätigkeiten: Elemente werden möglichst als Ergebnisse benannt, etwa «Anmeldeformular», nicht «Programmieren».
- Überschneidungsfreiheit: Jede Arbeit taucht genau einmal auf; Doppelungen führen zu doppelten Schätzungen.
- Projektmanagement als eigenes Element: Leitung, Steuerung, Berichtswesen und Abschluss kosten Zeit und gehören in den Plan.
- Eindeutige Nummerierung: Jedes Element erhält einen Code, der in Schätzung, Termin- und Kostenplanung wieder verwendet wird.
- Verantwortung je Arbeitspaket: Für jedes Paket gibt es genau eine verantwortliche Person.
Nach welchen Prinzipien wird gegliedert?
Für die zweite Ebene gibt es drei verbreitete Prinzipien. Die objekt- oder ergebnisorientierte Gliederung zerlegt nach den Bestandteilen des Ergebnisses, etwa Website, Inhalte, Schnittstellen. Die phasenorientierte Gliederung folgt dem Projektablauf, etwa Konzept, Realisierung, Einführung. Die funktionsorientierte Gliederung ordnet nach Fachbereichen, etwa Design, Entwicklung, Marketing. Mischformen sind üblich: auf der zweiten Ebene nach Phasen, darunter nach Ergebnissen.
| Prinzip | Geeignet für | Risiko |
|---|---|---|
| Objekt- oder ergebnisorientiert | Projekte mit klar abgrenzbaren Lieferobjekten | Querschnittsarbeit wie Tests wird leicht vergessen |
| Phasenorientiert | Projekte nach Phasenmodellen wie HERMES | gleiche Ergebnisse tauchen in mehreren Phasen auf |
| Funktionsorientiert | Organisationen mit starken Fachabteilungen | Schnittstellen zwischen Abteilungen bleiben unklar |
Wer nach HERMES arbeitet, erhält mit dem Sizing auf HERMES Online einen Durchführungsstrukturplan nach Phasen und Modulen, der sich als Ausgangspunkt eignet [2]. Für die Arbeitspakete darunter empfiehlt sich trotzdem eine ergebnisorientierte Benennung, weil sie die Abnahme erleichtert.
Wie gross sollte ein Arbeitspaket sein?
Ein Arbeitspaket ist die kleinste Einheit des Strukturplans, die geschätzt, einer Person zugewiesen und überwacht wird. Eine verbreitete Faustregel lautet, dass ein Paket zwischen einigen Personentagen und wenigen Personenwochen umfassen sollte. Kleinere Pakete erzeugen Verwaltungsaufwand, grössere lassen sich kaum zuverlässig schätzen und verbergen Probleme zu lange. Entscheidend ist, dass zu jedem Paket ein überprüfbares Ergebnis gehört.
| Feld | Inhalt | Beispiel |
|---|---|---|
| Code und Name | eindeutige Nummer und ergebnisorientierter Name | 2.3 Anmeldeformular |
| Ergebnis | was am Ende vorliegt | Formular mit Validierung, an CRM angebunden, getestet |
| Verantwortlich | genau eine Person | Entwickler A |
| Aufwand | Schätzung mit Bandbreite | 6 bis 9 Personentage |
| Abhängigkeiten | was vorher fertig sein muss | 2.1 Designsystem, 4.2 CRM-Schnittstelle |
| Abnahmekriterium | woran Fertigstellung erkannt wird | Testfälle bestanden, Freigabe durch Produktverantwortliche |
Beispiel: Strukturplan für einen Website-Relaunch
Eine Agentur plant den Relaunch einer Unternehmenswebsite. Der Strukturplan gliedert auf der zweiten Ebene nach Ergebnissen: 1 Projektmanagement, 2 Design und Entwicklung, 3 Inhalte, 4 Schnittstellen, 5 Einführung. Unter 2 folgen etwa 2.1 Designsystem, 2.2 Seitenvorlagen, 2.3 Anmeldeformular, 2.4 Barrierefreiheitsprüfung. Unter 3 stehen 3.1 Inhaltskonzept, 3.2 Texte für 25 Seiten, 3.3 Bilder und Grafiken, unter 5 etwa 5.1 Weiterleitungen, 5.2 Schulung der Redaktion, 5.3 Livegang.
Die 100-Prozent-Regel zwingt zu Fragen, die sonst erst spät auftauchen: Wer erstellt die Texte, die Agentur oder der Kunde? Wer kümmert sich um Weiterleitungen alter Adressen? Gehört die Schulung der Redaktion zum Projekt? Was im Strukturplan fehlt, wird nicht geschätzt, nicht geplant und nicht bezahlt. Was ausdrücklich nicht dazugehört, wird als Nicht-Ziel im Auftrag festgehalten, siehe Projektziele formulieren.
So erstellen Sie den Strukturplan im Team
- 1Projektauftrag und Ziele gemeinsam lesen, damit alle denselben Umfang vor Augen haben.
- 2Gliederungsprinzip für die zweite Ebene festlegen.
- 3Elemente sammeln, etwa mit Karten an einer Wand oder in einem digitalen Whiteboard.
- 4Elemente ordnen, Lücken und Doppelungen anhand der 100-Prozent-Regel prüfen.
- 5Bis zur Ebene der Arbeitspakete zerlegen und Verantwortliche festlegen.
- 6Strukturplan mit dem Auftraggeber abgleichen, bevor geschätzt wird.
Der Strukturplan entsteht idealerweise gemeinsam mit den Personen, die die Arbeit später ausführen. Sie kennen Arbeitsschritte, die in der Projektleitung niemand auf dem Schirm hat, und ihre Beteiligung erhöht die Verbindlichkeit der späteren Schätzungen. Der nächste Schritt ist die Schätzung je Arbeitspaket, siehe Aufwandsschätzung.
Typische Fehler beim Projektstrukturplan
- Strukturplan als Terminplan missverstanden: Reihenfolgen und Daten gehören nicht in den Strukturplan.
- Tätigkeitslisten statt Ergebnissen: «Meetings», «Abstimmungen» und «Programmieren» sind keine überprüfbaren Pakete.
- Projektmanagement vergessen: Leitung und Steuerung kosten in mittleren Projekten spürbar Zeit.
- Zu fein oder zu grob: hunderte Kleinstpakete oder wenige Pakete über Monate.
- Einmal erstellt, nie gepflegt: Genehmigte Änderungen müssen im Strukturplan nachgeführt werden.
In Flenio lässt sich der Strukturplan als Hierarchie aus Phasen, Aufgabengruppen und Aufgaben abbilden; Zeiterfassung und Budget hängen an denselben Elementen. So bleibt der Bezug zwischen Plan und Ist erhalten. Eine Übersicht zum Begriff bietet das Glossar unter Projektstrukturplan, den Gesamtzusammenhang zeigt der Leitfaden Projektplanung Schritt für Schritt.
Wofür wird der Strukturplan im Projekt genutzt?
Der Strukturplan ist mehr als eine Gliederung. Auf ihm bauen die Aufwandsschätzung, die Kostenplanung, der Terminplan und die Zuweisung von Verantwortung auf. Im Projektverlauf dient er als Rahmen für die Zeiterfassung: Wer Zeiten gegen Arbeitspakete erfasst, sieht, wo der Aufwand höher ist als geplant. Am Projektende bildet er die Grundlage für die Nachkalkulation und für Erfahrungswerte im nächsten Projekt.
Die Norm ISO 21502 beschreibt die Planung des Umfangs und die Zerlegung in steuerbare Einheiten als Teil des Projektmanagements, unabhängig vom gewählten Vorgehen [3]. Ob ein Team klassisch oder agil arbeitet, ändert daran wenig: Auch ein agiles Team braucht eine Vorstellung vom gesamten Umfang, um Budget und Termine abschätzen zu können.
Wie wird ein Strukturplan dargestellt?
Verbreitet sind zwei Darstellungen. Die grafische Baumstruktur zeigt die Hierarchie auf einen Blick und eignet sich für Workshops und Präsentationen. Die Listendarstellung mit eingerückten Codes eignet sich für grössere Pläne und lässt sich leicht mit Schätzungen, Verantwortlichen und Terminen ergänzen. Viele Teams beginnen in einem Workshop mit Karten an der Wand und übertragen das Ergebnis anschliessend als Liste in ihr Projekttool, wo die Arbeitspakete zu Aufgaben werden.
Wie prüfen Sie einen Strukturplan auf Vollständigkeit?
Bevor geschätzt wird, lohnt sich eine kurze Prüfung. Fragen Sie für jedes Element der zweiten Ebene, ob seine Unterelemente zusammen genau sein Ergebnis ergeben. Prüfen Sie, ob Querschnittsarbeiten wie Projektmanagement, Qualitätssicherung, Tests, Schulung, Dokumentation und Übergabe enthalten sind. Lassen Sie den Plan von einer Person lesen, die nicht an der Erstellung beteiligt war; sie findet Lücken, die das Team übersieht. Und gleichen Sie den Strukturplan mit den Zielen und Nicht-Zielen im Auftrag ab.
Wie nummeriert man Elemente sinnvoll?
Jedes Element erhält einen hierarchischen Code: 1 für das erste Hauptelement, 1.1 für sein erstes Unterelement, 1.1.1 für das nächste Niveau. Diese Codes sind mehr als Ordnung. Sie verbinden den Strukturplan mit Schätzung, Terminplan, Budget und Zeiterfassung, sodass jede Stunde und jeder Franken einem Element zugeordnet werden kann. Ändert sich der Strukturplan, sollten bestehende Codes nicht neu vergeben werden, damit historische Daten zuordenbar bleiben; neue Elemente erhalten neue Nummern am Ende ihrer Ebene.
Ein praktischer Nebeneffekt der Nummerierung: In Statusberichten, Änderungsanträgen und Rechnungen lässt sich präzise auf Arbeitspakete verweisen. Statt «die Formulararbeit» heisst es dann «Arbeitspaket 2.3», und alle Beteiligten wissen, welcher Umfang, welche Schätzung und welche Verantwortung gemeint sind. Das reduziert Missverständnisse, besonders in Projekten mit externen Partnern und mehreren Teams.
Ein sauber nummerierter Strukturplan ist damit die gemeinsame Sprache des Projekts, von der ersten Schätzung über die Zeiterfassung bis zur Nachkalkulation am Ende. Er lohnt die Sorgfalt, die in seine Erstellung fliesst.