Projektstrukturplan erstellen: Aufbau, Beispiele und Vorlage

Ein Projektstrukturplan (PSP) zerlegt den gesamten Projektumfang hierarchisch in eindeutig abgegrenzte, überschaubare Arbeitspakete. Er beantwortet vor allem: Was gehört zum Projekt? Nicht: Wann geschieht was? oder Wer arbeitet gleichzeitig woran? Damit schafft der PSP die belastbare Grundlage für Aufwandsschätzung, Verantwortungszuordnung sowie die spätere Termin- und Ressourcenplanung.

Dieser Leitfaden richtet sich an Projektleitende, PMO-Teams und Fachverantwortliche, die einen Projektstrukturplan erstellen oder eine PSP-Vorlage prüfen wollen. Sie lernen drei Gliederungsarten kennen, entwickeln ein vollständiges Beispiel für ein kleines Kundenportal und erhalten eine kopierbare Arbeitspaket-Vorlage. Wichtig: Der PSP ist eine Inhalts- und Leistungsstruktur. Ablaufplan, Terminplan, Organigramm und Aufgabenliste bleiben eigenständige Planungssichten.

Kurz erklärt

• Zweck: den Projektumfang vollständig, hierarchisch und möglichst überschneidungsfrei strukturieren.
• Endpunkt der Zerlegung: handhabbare Arbeitspakete mit Ergebnis, Verantwortung und Prüfkriterien.
• Darstellung: häufig als Baum, alternativ als nummerierte Gliederung oder Tabelle.
• Nicht enthalten: eine verlässliche Reihenfolge, Terminberechnung, Ressourcenabgleich oder Projektcontrolling.

Inhaltsverzeichnis

• Was ist ein Projektstrukturplan?
• Drei Arten der Projektstruktur
• Elemente und durchgängiges Beispiel
• Projektstrukturplan erstellen
• Arbeitspaket-Vorlage und Qualitätscheck
• Häufige Fehler
• Projektstrukturplan in AFFiNE dokumentieren
• FAQ

Was ist ein Projektstrukturplan?

Der Projektstrukturplan ist eine hierarchische Gesamtansicht des vereinbarten Projektumfangs. Auf Ebene 0 steht das Gesamtprojekt, darunter folgen geeignete Teilprojekte oder Strukturblöcke; an den untersten geplanten Ästen liegen die Arbeitspakete. Eine Codierung wie 2.2 macht jedes Element eindeutig referenzierbar. Das V-Modell XT Bund beschreibt den PSP als vollständige, hierarchische und überlappungsfreie Gliederung und nennt die 100-%-Regel: Die untergeordneten Elemente müssen ihren übergeordneten Ast vollständig abdecken.

Das ist keine Behauptung über eine bestimmte DIN-Definition. Für die praktische Abgrenzung ist entscheidend, welche Frage das Artefakt beantwortet:

Das V-Modell XT Bund trennt den PSP ausdrücklich vom Termin- und Ablaufplan: Zeitliche und logische Abhängigkeiten gehören in die nachgelagerte Ablaufplanung. Auch das Projektmanagement-Portal des Freistaats Sachsen ordnet Aufwandschätzung, Ressourcenzuordnung und Terminplanung als nachfolgende Schritte ein. Ein PSP kann dafür Eingangsdaten liefern, ersetzt diese Pläne aber nicht.

Drei Arten der Projektstruktur

Die passende Gliederung folgt dem Projektgegenstand, nicht einem starren Rezept. Die IPMA Individual Competence Baseline 4.0 gibt bewusst keine bestimmte Methode oder einen bestimmten Prozess vor. In der Praxis sind drei Grundformen hilfreich:

Objektorientierter PSP

Hier gliedern Sie nach Lieferobjekten oder Ergebnissen, etwa „Portal“, „Datenmigration“ und „Schulung“. Die Form passt gut, wenn abgrenzbare Produkte oder Komponenten entstehen. Kontrollfrage: Ist jedes geschuldete Ergebnis genau einem Ast zugeordnet?

Funktionsorientierter PSP

Diese Struktur folgt Tätigkeitsarten wie „analysieren“, „konzipieren“, „umsetzen“ und „testen“. Sie eignet sich für Vorhaben mit wiederkehrenden Fachfunktionen. Das Risiko: Ein Ergebnis kann über mehrere Funktionsäste verteilt sein; deshalb müssen Übergaben und Abnahmekriterien besonders klar sein.

Phasenorientierter PSP

Die oberste Ebene besteht aus Projektphasen, beispielsweise „Konzeption“, „Umsetzung“ und „Qualität und Freigabe“. Das ist verständlich, kann aber mit einem Ablaufplan verwechselt werden. Die Phasenüberschriften ordnen hier den Umfang; erst der separate Terminplan legt Reihenfolge und Daten verbindlich fest.

Mischformen sind zulässig, wenn die Regel pro Ebene klar bleibt. Ein Portalprojekt kann auf Ebene 1 nach Phasen und innerhalb der Umsetzung nach Objekten gegliedert sein. Dokumentieren Sie diese Logik in einem Satz; sonst lesen Teammitglieder gleiche Ebenen unterschiedlich.

Elemente und durchgängiges Beispiel

Ein belastbarer PSP enthält mindestens Projektname, Hierarchieebenen, eindeutige Codes, benannte Arbeitspakete und eine verantwortliche Rolle. Für jedes Arbeitspaket kommen Ergebnis, Abgrenzung, Eingaben, Prüfkriterien, geschätzter Aufwand und bekannte Abhängigkeiten hinzu. „Frontend bearbeiten“ ist zu offen; „freigegebenes Registrierungsformular gemäß Akzeptanzliste“ beschreibt ein prüfbares Ergebnis.

Als rein illustratives Beispiel dient ein Kunden-Onboarding-Portal mit 6 Wochen, 5 Rollen und insgesamt 30 Personentagen. Die Zahlen sind keine Benchmark und keine Empfehlung. Sie zeigen nur, wie eine kleine Struktur konsistent gelesen werden kann:

• 0 Kunden-Onboarding-Portal
  • 1 Konzeption
    • 1.1 Anforderungen bestätigen
    • 1.2 Informationsarchitektur freigeben
  • 2 Umsetzung
    • 2.1 Registrierungsformular umsetzen
    • 2.2 Profilbereich umsetzen
  • 3 Qualität und Freigabe
    • 3.1 Ende-zu-Ende-Test durchführen
    • 3.2 Übergabe und Freigabe dokumentieren

Die fünf Rollen sind Projektleitung, Fachverantwortung, UX, Entwicklung und Qualitätssicherung. Die 30 Personentage werden erst nach der Strukturierung auf Arbeitspakete verteilt. Diese Summe gehört zur Aufwandssicht; die sechs Wochen entstehen später aus Verfügbarkeit, Abhängigkeiten und Kalender. Der PSP allein beweist nicht, dass der Zeitrahmen realistisch ist.

Für 2.2 Profilbereich umsetzen könnten acht Personentage illustrativ angesetzt werden. Verantwortlich ist die Rolle Entwicklung; Eingaben sind freigegebene Anforderungen und Informationsarchitektur. Ergebnis ist ein testbarer Profilbereich, akzeptiert, wenn Pflichtfelder, Bearbeiten, Speichern und Fehlermeldungen die vereinbarte Prüfliste erfüllen. Abhängigkeiten zu 1.1, 1.2 und 3.1 werden dokumentiert, aber erst im Ablaufplan logisch angeordnet.

Der PSP-Code sollte während der Planung stabil bleiben. Ändert sich der Umfang, dokumentiert das Team, welches Paket ergänzt, geteilt oder gestrichen wurde, und prüft anschließend betroffene Schätzungen sowie Folgepläne. So bleibt 2.2 eine verlässliche Referenz in Besprechungsnotizen, Entscheidungen und Prüfprotokollen, ohne dass der PSP selbst zum Statusbericht wird.

Projektstrukturplan erstellen: Top-down und Bottom-up

Die Universität Würzburg beschreibt beide Vorgehensweisen: Top-down zerlegt die Projektaufgabe schrittweise; Bottom-up sammelt notwendige Arbeitspakete und gruppiert sie anschließend. Für kleine Projekte funktioniert oft ein kombinierter Ablauf am besten.

1. Auftrag und Grenzen klären. Notieren Sie Ziel, erwartete Ergebnisse, Ausschlüsse und Abnahmestelle. Ohne klare Scope-Grenze kann kein Vollständigkeitscheck gelingen.
2. Gliederungslogik wählen. Entscheiden Sie für Ebene 1 zwischen Objekt, Funktion oder Phase. Begründen Sie die Wahl in einem Satz und mischen Sie Kriterien nicht unbemerkt auf derselben Ebene.
3. Top-down zerlegen. Brechen Sie das Gesamtprojekt in drei bis sieben überschaubare Hauptäste herunter. Zerlegen Sie weiter, bis ein Ergebnis klar beauftragt, geschätzt und geprüft werden kann.
4. Bottom-up ergänzen. Sammeln Fachteam und Stakeholder alle konkret erwarteten Leistungen. Ein gemeinsames kostenloses Online-Whiteboard hilft beim Workshop; ordnen Sie danach jede Karte genau einem PSP-Ast zu.
5. Arbeitspakete ergebnisorientiert formulieren. Nutzen Sie Verb plus prüfbares Substantiv oder ein eindeutiges Ergebnis. Vermeiden Sie Sammelwörter wie „Sonstiges“, solange der Inhalt nicht begrenzt ist.
6. Codes und Verantwortung vergeben. Verwenden Sie stabile Codes wie 1.2 oder 3.1. Pro Arbeitspaket gibt es eine verantwortliche Rolle, auch wenn mehrere Personen mitarbeiten.
7. Vollständigkeit und Überschneidungen prüfen. Vergleichen Sie Auftrag, Lieferliste, Schnittstellen und Ausschlüsse mit dem Baum. Jedes Scope-Element soll vorkommen, aber nicht doppelt geplant sein.
8. Folgepläne ableiten. Schätzen Sie Aufwand, ordnen Sie Abhängigkeiten und bauen Sie anschließend Termin- und Ressourcenplan. Eine Wochenplan-Vorlage kann die operative Woche strukturieren, ist aber kein Ersatz für den PSP.

Beziehen Sie die fünf Rollen des Beispielprojekts in Schritt 4 ein. Die Projektleitung moderiert, die Fachverantwortung prüft den Scope, UX und Entwicklung ergänzen Lieferobjekte, die Qualitätssicherung formuliert Prüfbarkeit. So begegnen sich Managementsicht und Ausführungserfahrung, bevor der Plan verbindlich wird.

Arbeitspaket-Vorlage und Qualitätscheck

Die Universität Würzburg nennt für Arbeitspaketbeschreibungen unter anderem Titel, Nummer, Verantwortung, Termine, Dauer, Bedingungen, Risiken und Ergebnis. Für die PSP-Phase kann folgende kopierbare Vorlage dienen; Termine werden nach der Ablauf- und Ressourcenplanung ergänzt:

PSP-Code:
Name des Arbeitspakets:
Ziel / erwartetes Ergebnis:
Inhalt:
Nicht enthalten:
Verantwortliche Rolle:
Mitwirkende Rollen:
Benötigte Eingaben:
Abnahmekriterien:
Geschätzter Aufwand:
Bekannte Abhängigkeiten:
Risiken / Annahmen:
Status der Freigabe:

Prüfen Sie danach jedes Arbeitspaket mit acht Fragen:

1. Ist das Ergebnis eindeutig benannt?
2. Gehört es genau zu einem PSP-Ast?
3. Ist die Abgrenzung zu Nachbarpaketen klar?
4. Gibt es genau eine verantwortliche Rolle?
5. Sind Eingaben und Abnahmekriterien nachvollziehbar?
6. Ist der Aufwand mit einer Einheit angegeben?
7. Sind Annahmen, Risiken und Abhängigkeiten sichtbar?
8. Kann ein Außenstehender den Freigabestatus verstehen?

Häufige Fehler bei PSP-Vorlagen

Aktivitäten mit Ergebnissen vermischen. „Workshop halten“ beschreibt eine Handlung; das erwartete Ergebnis könnte „abgestimmte Anforderungsliste“ sein. Ergebnisorientierte Namen machen die spätere Abnahme leichter.

Terminplan im Baum verstecken. Phasen können eine Gliederung bilden, doch Pfeile, Daten und kritischer Pfad gehören in Ablauf- und Terminplanung. Der PSP bleibt lesbar, wenn er nicht jede Sicht zugleich darstellen soll.

Doppelte oder fehlende Leistungen akzeptieren. Ein Testpaket unter „Umsetzung“ und dasselbe Testpaket unter „Qualität“ erzeugen Doppelplanung. Umgekehrt fällt eine notwendige Datenschutzprüfung leicht zwischen Äste. Ein Scope-Abgleich und die 100-%-Prüfung verhindern beide Fehler.

Arbeitspakete zu groß oder zu klein schneiden. „Portal entwickeln“ ist kaum verlässlich schätzbar; „Button-Farbe ändern“ kann für die Steuerung zu kleinteilig sein. Die passende Größe ist erreicht, wenn Verantwortung, Ergebnis, Aufwand und Abnahme sinnvoll beschreibbar sind.

Eine Aufgabenliste als PSP behandeln. Laufende To-dos verändern sich täglich, während PSP-Codes als stabile Referenz dienen sollten. Persönliche Unterlagen lassen sich ergänzend mit der PARA-Methode ordnen; der vereinbarte Projektumfang braucht dennoch eine gemeinsame Struktur.

Den Plan nach Freigabe vergessen. Scope-Änderungen müssen kontrolliert in PSP und Folgepläne einfließen. Gute Wissensmanagement-Tools halten Entscheidungen und Versionen auffindbar, ersetzen aber weder Change-Entscheidung noch Verantwortlichkeit.

Projektstrukturplan in AFFiNE dokumentieren

Für diesen Beitrag haben wir am 06.08.2026 im AFFiNE-Webclient einen lokalen Browser-Workspace mit dem illustrativen Kundenportal angelegt. In der Page-Ansicht ließen sich PSP-Ebenen, Codes und die Beschreibung von Arbeitspaket 2.2 manuell als strukturierter Text erfassen. Anschließend wechselten wir in die Edgeless-Ansicht; der Inhalt blieb für eine manuelle räumliche Anordnung und manuelle Durchsicht zugänglich.

Diese Beobachtung ist bewusst eng formuliert: AFFiNE generiert keinen Projektstrukturplan automatisch, berechnet keine Terminfolge, führt keinen Ressourcenabgleich durch und übernimmt kein Projektcontrolling. Page und Edgeless unterstützen hier die manuelle Dokumentation und das Review. Fachliche Vollständigkeit, Schätzung, Freigabe und Pflege bleiben Aufgaben des Projektteams.

Einziger nächster Schritt: AFFiNE im Browser öffnen, Auftrag, drei Hauptäste und die Arbeitspaket-Vorlage manuell übertragen und den ersten Entwurf mit den verantwortlichen Rollen prüfen.

FAQ zum Projektstrukturplan

Was ist ein Projektstrukturplan einfach erklärt?

Ein Projektstrukturplan zerlegt den gesamten Projektumfang hierarchisch in Teilprojekte, Teilaufgaben und handhabbare Arbeitspakete. Er zeigt, was geleistet werden muss und wie die Leistungen zusammengehören. Zeitliche Reihenfolge, konkrete Termine und Ressourcenauslastung werden anschließend in eigenen Planungssichten festgelegt. Er ist damit eine Inhaltsübersicht und keine Kalenderansicht.

Wie erstelle ich einen Projektstrukturplan?

Klären Sie zuerst Ziel, Ergebnisse und Ausschlüsse. Wählen Sie dann eine objekt-, funktions- oder phasenorientierte Gliederung, zerlegen Sie den Umfang top-down und ergänzen Sie fehlende Pakete bottom-up. Vergeben Sie eindeutige Codes und Verantwortungen, prüfen Sie Vollständigkeit sowie Überschneidungen und leiten Sie erst danach Folgepläne ab.

Was gehört in ein Arbeitspaket?

Ein Arbeitspaket braucht mindestens PSP-Code, eindeutigen Namen, erwartetes Ergebnis, Abgrenzung und eine verantwortliche Rolle. Für die Ausführung sind außerdem Eingaben, Mitwirkende, Abnahmekriterien, geschätzter Aufwand, Abhängigkeiten, Risiken und Annahmen hilfreich. Termine sollten mit dem späteren Ablauf- und Ressourcenplan abgestimmt werden.

Was ist der Unterschied zwischen PSP und Ablaufplan?

Der Projektstrukturplan ordnet den Leistungsumfang hierarchisch und beantwortet die Frage „Was gehört zum Projekt?“. Der Ablaufplan ordnet Vorgänge sachlogisch und beantwortet „In welcher Reihenfolge wird gearbeitet?“. Arbeitspakete aus dem PSP können in den Ablaufplan eingehen; der PSP selbst berechnet weder Abhängigkeiten noch den kritischen Pfad.

Welche Projektstrukturplan-Art ist die beste?

Die beste Struktur passt zum Projektgegenstand und wird vom Team einheitlich verstanden. Lieferobjekte sprechen oft für einen objektorientierten, wiederkehrende Tätigkeiten für einen funktionsorientierten und klar getrennte Abschnitte für einen phasenorientierten PSP. Mischformen funktionieren, wenn das Kriterium je Ebene dokumentiert und konsequent angewandt wird.

Fazit: Projektstrukturplan als belastbare Umfangsbasis

Ein guter Projektstrukturplan macht den vollständigen Umfang sichtbar, ordnet ihn eindeutig und endet in prüfbaren Arbeitspaketen. Er bleibt bewusst getrennt von Ablauf, Terminen, Ressourcen und Controlling. Wer Top-down-Zerlegung mit Bottom-up-Wissen verbindet, die 100-%-Regel prüft und Arbeitspakete ergebnisorientiert beschreibt, erhält eine tragfähige Basis für alle weiteren Planungsschritte.

Quellen und Prüfstand

• V-Modell XT Bund, „Projektplan“, Abschnitt Projektstrukturplan — abgerufen am 06.08.2026.
• Freistaat Sachsen, „Projektstrukturplan“ — abgerufen am 06.08.2026.
• International Project Management Association, „ICB4“ — abgerufen am 06.08.2026.
• Julius-Maximilians-Universität Würzburg, „Handbuch Projektmanagement“, Abschnitt 2.2.3 — abgerufen am 06.08.2026.