Was ist ein Scope Creep?

Scope Creep. Anforderungen schleichen sich in den Projektumfang.

Was versteht man unter Scope Creep? Wie entsteht er und was können Sie tun, um einen Scope Creep zu verhindern?

tooltip text
1

Scope Creep beschreibt das unkontrollierte Hinzufügen von Anforderungen zum Projektumfang.

2

In vielen Fällen verursachen Stakeholder wie Kunden einen Scope Creep. Denn sie fordern z.B. neue Features im Projektverlauf, die nicht abgesprochen waren.

3

Auch das Entwicklerteam selbst kann für den unkontrollierten Zuwachs an Anforderungen verantwortlich sein. So passiert es manchmal, dass diese mehr als verlangt entwickeln.

4

Durch einen Scope Creep wachsen Aufwände und Kosten unkontrolliert im Projekt. Daher birgt er eine Gefahr, die verhindert bzw. kontrolliert werden muss.

Was ist ein Scope Creep? Ein paar Beispiele.

 

Scope Creep – wieder ein englischer Begriff im Projektmanagement. Was genau bedeutet er auf Deutsch? Frei übersetzt erst einmal: schleichende Umfangsausweitung. Für das bessere Verständnis muss diese Wortkonstruktion aufgeschlüsselt werden:

Der Umfang bzw. Scope bezieht sich auf das Was, das in einem Projekt umgesetzt wird. Dazu gehören zum Beispiel Produkte, Services oder Ergebnisse, die erzielt werden. Grundlage für dieses Was bilden immer Anforderungen – also Wünsche, die Kunden an das zu entwickelnde Produkt stellen. Oftmals schleichen sich unkontrolliert Anforderungen in den Projektumfang hinein, weil die Kunden zum Beispiel neue Bitten hervorbringen und “wenn man schon einmal dabei ist, könnte man nicht ein weiteres Feature, das wir nicht abgesprochen haben, auch umsetzen?” Oder das eigene Entwicklungsteam ist “überfleißig” und entwickelt weitere Funktionen ohne vorherige Absprache. Ein Scope Creep entsteht. Der Arbeitsaufwand wächst dadurch nahezu unbemerkt und die Kosten erhöhen sich. Scope Creep ist somit eine Gefahr für jedes Projekt, die es zu verhindern bzw. zu kontrollieren gilt.

Definition von Scope Creep, übersetzt aus dem Project Management Body of Knowledge (PMBOK® Guide):

 

Scope Creep ist das “Hinzufügen von Features und Funktionalitäten (zum Projektumfang), ohne die Auswirkungen auf Termine und Kosten abzuwägen oder die Zustimmung des Kunden einzuholen“.

Gründe für die Entstehung eines Scope Creep

Es wäre zu einfach, Stakeholdern und ihrem unbändigen Wunschdrang die alleinige Schuld an einem Scope Creep zuzuschieben. Denn die Ursachen sind vielfältig. Im Falle der Stakeholder kann es zum Beispiel sein, dass der Projektumfang und damit die Anforderungen unklar oder ungenügend spezifiziert waren. Dadurch verstehen sie nicht, warum die Wünsche nicht zum abgemachten Projektumfang zählen. Oder aber sie werden ungenügend in die Projektarbeit einbezogen und haben wenig Gelegenheit, Klarheit zu schaffen. Im einfachsten Fall wollen sie aber auch nur mehr erhalten, als bezahlt.

Ein Scope Creep kann auch durch unrealistische Versprechungen des Managements entstehen oder weil Änderungen am Projektumfang ungenügend kontrolliert werden. Auch das Entwicklungsteam selbst kann der Verursacher sein: Wenn es nämlich ein Überflieger sein und mehr leisten will, als ursprünglich vereinbart (siehe Gold Plating).

Begriffe im Zusammenhang von Scope Creep

Scope Grope: Der Projektumfang kann nicht definiert werden.

Scope Leap: Der Projektumfang wird vollkommen geändert.

Scope Creep (auch Requirement Creep, Function Creep, Feature Creep): Neue Anforderungen werden dem Projektumfang unkontrolliert hinzugefügt.

Verwandter Begriff außerdem:

Gold Plating: Neue Funkionen werden absichtlich dem Projektumfang hinzugefügt, um mehr als verlangt zu liefern.

Den Scope Creep verhindern und kontrollieren

In den wenigsten Fällen können Sie einen Scope Creep ganz verhindern. Umso mehr ist es von Bedeutung, ihn zu kontrollieren.

Anforderungen richtig dokumentieren

Um einen Scope Creep zu verhindern, müssen Sie sicherstellen, dass alle Anforderungen formal – das bedeutet schriftlich und am besten in einem Tool – festgehalten werden. Dadurch schaffen Sie einerseits einen definierten Platz, an dem jede Anforderung landet, und Sie behalten den Überblick. Andererseits schaffen Sie die Grundlage für Änderungsmanagement, denn Sie können die Traceability (deutsch: Nachvollziehbarkeit) sicherstellen. Mithilfe von Traceability lassen sich Anforderungen bis zu den Stakeholdern und ihren Zielen zurückverfolgen sowie verbundene Systemkomponenten und Testfälle identifizieren. Auswirkungen von Änderungen am Projektumfang, den der Scope Creep bewirkt, sind so transparenter.

Lesen Sie hier weiter, um mehr über Traceability zu erfahren »

Den Stakeholdern den Projektumfang klar vermitteln

Oftmals machen Projektleiter den Fehler, ihre Kunden nur ganz am Anfang und ganz am Ende einzubeziehen. Nach dem Motto: Sag uns, was du haben willst. Danach herrscht Funkstille und schließlich: Hier ist dein Produkt. Das führt in vielen Fällen zu unzufriedenen Stakeholdern, weil diese sich etwas ganz anders vorgestellt hatten. Doch auch wenn Sie die Stakeholder während des gesamten Projekts einbeziehen und ausreichend mit ihnen kommunizieren, gehören Missverständnisse und damit verbundene “Nachanforderungen” zum Projektalltag. Um den Stakeholdern den Projektumfang zu verdeutlichen und ihnen ihre Erwartungen an das Produkt klarer zu machen, empfiehlt es sich, mit Diagrammen wie Use Case-Diagrammen oder Systemkontextdiagrammen zu arbeiten.

Download objectiF RPM Whitepaper

Wissen zum Mitnehmen

Bedarf ermitteln, Lösungen vorschlagen & Mehrwert schaffen mit objectiF RPM Whitepaper

PDF Zum Download »

Mehr Downloads rund ums Thema

  • Whitepaper
  • Tipps & Tricks
  • Software

Zum Downloadcenter »

Anforderungen prüfen, abnehmen und durch Baselines sichern

Damit alle Projektbeteiligten die Anforderungen klar verstehen, sollten Sie diese zusammen einem Review unterziehen. Dadurch lassen sich Unklarheiten, Unstimmigkeiten und Fehler noch vor der Realisierung aus dem Weg räumen. Wenn alle Anforderungen die Reviews überstanden haben und von den Stakeholdern akzeptiert wurden, empfiehlt es sich, eine Baseline zu ziehen. Sie schaffen damit einen Referenzpunkt für die Entwicklung, auf den Sie sich im Verlauf des Projekts immer beziehen können. Ein Stakeholder stellt weitere Forderungen? Sie können nun immer auf diesen Stand, den auch dieser abgesegnet hat, verweisen und dem Stakeholder klar machen, dass sein Wunsch Aufwand, Kosten und zeitliche Verzögerungen nach sich ziehen würde.

Lesen Sie hier weiter, um mehr über Baselines zu erfahren »

Prozess für Änderungsmanagement einführen

Um einen Scope Creep kontrollieren zu können, brauchen Sie einen Prozess für das Änderungsmanagement. Hier müssen Sie sicherstellen, dass jeder Veränderungswunsch diesen Prozess auch wirklich durchläuft. Schnell schleicht sich eine Vielzahl an Anforderungen in den Projektumfang, weil ein Team-Mitglied mündlich oder durch E-Mails kommunizierte Wünsche “nebenbei” annimmt und den Arbeitsaufwand unterschätzt.

Zum Änderungsmanagement gehört es, u.a. folgende Fragen zu beantworten:

Was genau umfasst die Änderung? Welche Auswirkungen hat die Änderung (z.B. auf Anforderungen, Systemkomponenten etc.)? Welche Risiken sind mit ihr verbunden? Wie beeinflusst die Änderung die Kosten und den Arbeitsaufwand?

So verhindern und kontrollieren Sie einen Scope Creep mit objectiF RPM

objectiF RPM ist eine Application Lifecycle Management-Software, mit der Sie den Scope Creep im Griff haben. Für das bessere Verständnis des Systems können Sie Diagramme wie ein Systemkontextdiagramm einsetzen oder die Ziele der Stakeholder mithilfe von Zieldiagrammen festhalten. Auch Anforderungen oder Use Cases lassen sich durch Diagramme erfassen sowie in textlicher Form dokumentieren und mit Stakeholdern, Zielen, Testfällen usw. verbinden. Dadurch stellen Sie die Traceability jederzeit sicher und Auswirkungen von Änderungen an den Anforderungen sind kontrollierbar. Des Weiteren können Sie zusammen mit den Stakeholdern Reviews der Anforderungen durchführen und Projektinhalte leicht miteinander teilen. Das Ziehen von Baselines für Ihre Anforderungen ist natürlich auch möglich.

Anforderungsdiagramm in objectiF RPM