„Scope definieren“ ist der Planungsprozess, in dem aus einer Absicht eine überprüfbare Beschreibung von Projekt und Produkt wird. Sein Ergebnis ist die Beschreibung des Projekt-Scope: das Dokument, das festhält, was geliefert wird, welchen Wert das stiften soll und was ausdrücklich nicht dazugehört.
Was den Prozess brauchbar macht
Der eigentliche Nutzen steckt in der Abgrenzung. Ein Scope, der nur aufzählt, was geliefert wird, lässt jede spätere Zusatzforderung selbstverständlich erscheinen. Erst der ausdrückliche Ausschluss macht aus einem Wunsch eine Änderung, über die jemand entscheiden muss.
Der Prozess benennt außerdem die Qualitätsanforderungen und -standards für die Liefergegenstände und legt fest, wie das Projekt deren Einhaltung nachweisen soll. Wer diesen Teil überspringt, streitet später über den Zustand des Ergebnisses statt über seinen Umfang.
Praxis
- Zeitpunkt. Bei plangetriebenen Ansätzen zu Beginn des Projekts, bei adaptiven und hybriden Ansätzen zu Beginn jeder Iteration.
- Ausschlüsse gehören ins Dokument, nicht ins Besprechungsprotokoll. Was nicht schriftlich ausgeschlossen ist, gilt im Zweifel als zugesagt.
- Abnahmekriterien mitdenken. Wenn sich aus einer Scope-Aussage keine Prüfung ableiten lässt, ist sie noch ein Wunsch und keine Beschreibung.
- Detailtiefe nach Ansatz. Plangetrieben wird das Ergebnis im Projektstrukturplan strukturiert, adaptiv wächst es fortlaufend über das Backlog.
Einordnung im PMBOK Guide 8
Die achte Ausgabe führt „Scope definieren“ als Prozess der Leistungsdomäne Scope (Abschnitt 2.2.2.3). Als Inputs nennt sie unter anderem Projektauftrag, Annahmen-Protokoll, Projektmanagementplan und die Dokumentation der Anforderungen; als Werkzeuge Expertenurteil, Entscheidungsfindung, Datenanalyse, Zerlegung, Moderation und Produktanalyse; als Outputs die Beschreibung des Projekt-Scope und die aktualisierte Anforderungsdokumentation.
Im Ablauf steht der Prozess zwischen „Anforderungen ermitteln und analysieren“ und „Scope-Struktur entwickeln“. Sein Ergebnis wird später in „Scope überwachen und steuern“ gegen die Scope-Baseline gehalten und in Scope validieren förmlich abgenommen. Für adaptive Ansätze hält der Leitfaden ausdrücklich fest, dass der Scope allgemeiner gefasst wird und oft über die Produkt-Roadmap mit ihren Releases dargestellt ist.
Häufige Fragen
Was unterscheidet „Scope definieren“ von der Beschreibung des Projekt-Scope?
Das eine ist der Prozess, das andere sein Ergebnis. Der Prozess erzeugt das Dokument, das Dokument dient danach als Bezugspunkt für Änderungen und Abnahme.
Warum nicht „Scope-Definition“?
Die deutsche Ausgabe des PMBOK Guide benennt die Prozesse durchgehend mit Verbformen, also „Scope definieren“, „Scope validieren“, „Scope überwachen und steuern“. „Scope-Definition“ ist eine Rückübersetzung aus dem Englischen und kein Begriff des Leitfadens.
Brauchen agile Projekte diesen Prozess?
Ja, nur in anderer Form und Frequenz. Statt eines einmaligen Dokuments am Anfang steht eine grobe Produktbeschreibung, die zu Beginn jeder Iteration geschärft wird. Die Frage, was dazugehört und was nicht, verschwindet dadurch nicht.
Autor: Tom, seit 2004 PMP-zertifiziert. Zuletzt aktualisiert: August 2026.