Was bedeutet Scope-Management?
Der Scope, also der Umfang eines Projekts, beschreibt alle Ergebnisse und die dafür nötige Arbeit. Scope-Management umfasst zwei Aufgaben: den Umfang zu Beginn klar festzulegen und ihn während des Projekts zu kontrollieren. Die achte Auflage des PMBOK Guide führt Scope als eine von sieben Performance-Domänen, gleichrangig mit Terminen, Finanzen und Risiken [1]. Die ISO 21502 beschreibt die Festlegung und Kontrolle des Umfangs ebenfalls als Kernaufgabe des Projektmanagements [2].
Festgelegt wird der Umfang über drei Elemente: die Ziele und Nicht-Ziele im Projektauftrag, den Projektstrukturplan mit allen Arbeitspaketen und die Beschreibungen der Ergebnisse mit Abnahmekriterien. Zusammen bilden sie die sogenannte Scope-Baseline, gegen die Änderungen gemessen werden. Ohne diese Baseline lässt sich nicht entscheiden, ob ein Wunsch eine Änderung ist oder schon immer dazugehörte.
Wie entsteht Scope Creep?
Scope Creep bezeichnet das schleichende, unkontrollierte Wachsen des Umfangs. Es entsteht selten durch einen grossen Wunsch, sondern durch viele kleine: noch ein Feld im Formular, noch eine Auswertung, noch eine Sprachversion, noch ein Abstimmungstermin. Jeder Wunsch für sich wirkt harmlos, und niemand möchte als unflexibel gelten. In der Summe verbrauchen sie Zeit und Budget, die im Plan nicht vorgesehen sind, und am Ende wundern sich alle, warum das Projekt zu spät und zu teuer ist.
- Unklare Abgrenzung: Ohne Nicht-Ziele ist schwer zu argumentieren, dass etwas nicht dazugehört.
- Direkte Absprachen: Fachbereiche wenden sich direkt an Teammitglieder statt an die Projektleitung.
- Gold Plating: Das Team liefert mehr als vereinbart, weil es das Ergebnis verbessern möchte.
- Fehlender Prozess: Es gibt keinen definierten Weg, Änderungen zu beantragen und zu entscheiden.
- Angst vor Konflikten: Wünsche werden angenommen, um Diskussionen zu vermeiden.
Das wirksamste Gegenmittel ist eine klare Abgrenzung zu Projektbeginn. Wer im Auftrag festhält, was das Projekt nicht leistet, hat später eine sachliche Grundlage, siehe Projektziele formulieren. Das zweite Mittel ist ein schlanker Änderungsprozess, der Änderungen nicht verhindert, sondern sichtbar und entscheidbar macht.
Wie sieht ein schlanker Änderungsprozess aus?
- 1Antrag: Wer eine Änderung wünscht, beschreibt sie kurz mit Begründung und gewünschtem Termin.
- 2Erfassung: Die Projektleitung erfasst den Antrag in einer Änderungsliste mit Nummer und Datum.
- 3Bewertung: Das Team schätzt die Folgen für Umfang, Termin, Kosten, Qualität und Risiken.
- 4Entscheid: Die befugte Stelle entscheidet, gestützt auf die Bewertung, über Annahme, Ablehnung oder Verschiebung.
- 5Umsetzung: Angenommene Änderungen werden in Strukturplan, Terminplan und Budget übernommen.
- 6Kommunikation: Antragstellende und Team werden über den Entscheid informiert.
Entscheidend ist der Schritt Bewertung. Ein Wunsch, der auf den ersten Blick klein wirkt, kann Folgen haben, die erst bei genauer Betrachtung sichtbar werden, etwa zusätzliche Tests, Anpassungen an Schnittstellen oder eine Verschiebung auf dem kritischen Pfad. Die Bewertung macht diese Folgen transparent, und der Entscheid wird zu einer bewussten Abwägung statt zu einem Gefallen. Für eine schnelle Einschätzung der Kostenfolgen eignet sich der Change-Request-Rechner.
Wer darf über Änderungen entscheiden?
| Grösse der Änderung | Entscheid durch | Dokumentation |
|---|---|---|
| Kein Einfluss auf Termin und Budget, innerhalb der Ziele | Projektleitung | Änderungsliste |
| Mehraufwand bis zu einer festgelegten Grenze, kein Einfluss auf Meilensteine | Projektleitung nach Rücksprache mit Auftraggeber | Änderungsliste, Statusbericht |
| Einfluss auf Meilensteine, Budget oder Ziele | Auftraggeber | Änderungsantrag, angepasster Projektauftrag |
| Grundlegende Änderung von Zielen oder Umfang | Auftraggeber, gegebenenfalls Steuerungsausschuss | neuer Projektauftrag, Neuplanung |
Diese Befugnisse gehören in das Projekthandbuch, siehe Projekthandbuch erstellen. Sie verhindern, dass einerseits jede Kleinigkeit beim Auftraggeber landet und andererseits wesentliche Änderungen ohne seine Zustimmung umgesetzt werden. In HERMES werden Änderungen über eine Änderungsstatusliste geführt; flenio.ch bietet dazu eine Vorlage HERMES-Änderungsstatusliste.
Beispiel: Ein Änderungswunsch im Website-Projekt
Drei Wochen vor dem Livegang wünscht der Marketingleiter eine Mehrsprachigkeit für die neue Website, zunächst Französisch. Im Projektauftrag ist Mehrsprachigkeit als Nicht-Ziel festgehalten. Die Projektleitung erfasst den Wunsch als Änderungsantrag. Das Team bewertet: Die technische Vorbereitung kostet drei Personentage, die Übersetzung der 25 Seiten erfolgt durch den Kunden, die Einpflege der Texte dauert zwei Tage, und der Livegang verschiebt sich um eine Woche, weil die Aufgaben auf dem kritischen Pfad liegen.
Die Projektleitung legt dem Auftraggeber zwei Optionen vor: Option A, Mehrsprachigkeit jetzt mit einer Woche Verschiebung und fünf zusätzlichen Personentagen; Option B, Livegang wie geplant und Mehrsprachigkeit als zweite Etappe einen Monat später. Der Auftraggeber entscheidet sich für Option B, weil der Livegang an eine Kampagne gekoppelt ist. Der Entscheid wird dokumentiert, die zweite Etappe als neues Arbeitspaket angelegt. Niemand musste Nein sagen, und trotzdem bleibt der Plan stabil.
Scope-Management in agilen Projekten
In agilen Projekten ist der Umfang bewusst flexibel. Neue Wünsche werden ins Backlog aufgenommen und priorisiert; was in einen Zyklus passt, entscheidet die Priorität. Das bedeutet nicht, dass Scope-Management entfällt. Stattdessen verschiebt es sich: Der Rahmen aus Budget, Termin und Zielen bleibt fix, der Umfang innerhalb dieses Rahmens wird laufend gesteuert. Neue Einträge verdrängen andere, und die Produktverantwortung entscheidet, welche.
In hybriden Projekten bewährt sich eine Kombination: Änderungen an Zielen, Budget und Endtermin laufen über den formalen Änderungsprozess mit Entscheid des Auftraggebers, Änderungen an Details innerhalb des Rahmens über das Backlog. Wie diese Kombination im Alltag funktioniert, beschreibt der Beitrag Hybrides Projektmanagement in der Praxis.
Änderungen im Werkzeug nachvollziehbar führen
Eine Änderungsliste muss nicht kompliziert sein: Nummer, Datum, Beschreibung, antragstellende Person, Bewertung, Entscheid, Status. Wichtig ist, dass sie gepflegt wird und dass angenommene Änderungen tatsächlich in Pläne und Budget einfliessen. In Flenio lassen sich Änderungen als eigene Aufgaben mit Status, Aufwand und Verknüpfung zum betroffenen Arbeitspaket führen, sodass Plan und Ist nachvollziehbar bleiben. Für die Prüfung einzelner Anträge bietet sich die Checkliste Change Request prüfen an.
Wie wird der Umfang validiert und abgenommen?
Zum Scope-Management gehört nicht nur die Kontrolle von Änderungen, sondern auch die Bestätigung, dass die vereinbarten Ergebnisse geliefert wurden. Diese Validierung erfolgt idealerweise schrittweise: Teilergebnisse werden nach ihrer Fertigstellung vom Fachbereich geprüft und abgenommen, nicht erst am Projektende alle auf einmal. So werden Missverständnisse früh sichtbar, wenn Korrekturen noch günstig sind. Grundlage sind die Abnahmekriterien, die zu Beginn für jedes Ergebnis festgelegt wurden.
Für die Validierung bewährt sich ein einfaches Protokoll: Ergebnis, geprüft durch, Datum, Ergebnis der Prüfung, offene Punkte. Offene Punkte werden entweder als Mängel im Projekt behoben oder als Änderungen behandelt, wenn sie über den vereinbarten Umfang hinausgehen. Diese Unterscheidung ist wichtig: Ein Mangel ist eine Abweichung vom Vereinbarten und wird ohne Zusatzkosten behoben, eine Änderung ist ein neuer Wunsch und läuft über den Änderungsprozess.
Woran erkennen Sie, ob der Umfang im Griff ist?
Drei einfache Kennzahlen zeigen, ob das Scope-Management funktioniert. Erstens die Zahl offener Änderungsanträge und ihr Alter: Viele alte, nicht entschiedene Anträge deuten auf Entscheidungsstau hin. Zweitens der Anteil der Arbeit, die keinem Arbeitspaket zugeordnet werden kann: Steigt er, wird Arbeit ausserhalb des Plans geleistet. Drittens die Summe der angenommenen Änderungen im Verhältnis zum ursprünglichen Budget, die zeigt, wie stark sich das Projekt seit dem Auftrag verändert hat.
Diese Kennzahlen gehören in den regelmässigen Statusbericht. Sie machen sichtbar, was sonst erst bei der Schlussabrechnung auffällt, und geben dem Auftraggeber die Möglichkeit, rechtzeitig über Prioritäten zu entscheiden. Wer Zeiten konsequent gegen Arbeitspakete und Änderungen erfasst, kann sie ohne Zusatzaufwand ermitteln.
Ein weiterer Hinweis aus der Praxis: Halten Sie auch abgelehnte und verschobene Änderungsanträge fest. Sie zeigen am Projektende, welche Wünsche bewusst nicht umgesetzt wurden, und sind oft eine gute Grundlage für ein Folgeprojekt oder eine zweite Etappe. Zudem verhindern sie, dass derselbe Wunsch alle paar Wochen erneut diskutiert wird, weil der frühere Entscheid mit Begründung nachgelesen werden kann. Gerade in langen Projekten mit wechselnden Beteiligten ist diese Nachvollziehbarkeit Gold wert, weil sie Diskussionen versachlicht und Entscheide stabil hält.
Scope-Management ist damit weniger eine Frage der Strenge als der Transparenz: Wer jederzeit zeigen kann, was vereinbart, was geändert und was bewusst verschoben wurde, hat das Projekt im Griff.
Scope-Management in PMBOK, ISO 21502 und HERMES
Der PMBOK Guide behandelt Scope als eigene Performance-Domäne mit Festlegung, Validierung und Kontrolle des Umfangs. Die ISO 21502 beschreibt Umfangsdefinition und Änderungssteuerung als Teil der Projektsteuerung. HERMES führt Änderungen über die Änderungsstatusliste und verankert wesentliche Entscheide bei den Phasenfreigaben, bei denen der Auftraggeber den Stand bestätigt [3]. Gemeinsam ist allen: Änderungen sind normal, aber sie werden bewusst entschieden. Den Gesamtzusammenhang zeigt der Leitfaden Projektplanung Schritt für Schritt.