Scope Creep entsteht beim unkontrollierten Hinzufügen von Anforderungen zum Projektumfang. Oft verursachen Kunden einen Scope Creep, indem sie Anforderungen wie neue Funktionalitäten im Projektverlauf hinzufügen, die nicht abgesprochen waren. Aber auch das Entwicklerteam selbst kann für den unkontrollierten Zuwachs an Anforderungen verantwortlich sein. Manchmal entwickeln sie mehr als verlangt war. Durch den Scope Creep wachsen Aufwände und Kosten unkontrolliert im Projekt und abgemachte Termine und Kosten können nicht eingehalten werden. Diese Gefahr muss daher kontrolliert werden. Es ist das Problem schlechthin bei den agilen Projektmanagement Methoden, die den Wert auf das flexible Zufügen von sich ändernden Anforderungen legen.
Oft kann die Schuld an einem Scope Creep nicht alleine den Stakeholdern zugeschoben werden. Es kann zum Beispiel der Fall sein, dass der Projektumfang und die Anforderungen unklar und ungenügend spezifiziert waren oder die Kunden nicht genügend in die Projektarbeit einbezogen waren. Darum verstehen die Stakeholder nicht, warum die Wünsche nicht zum abgemachten Projektumfang gehören. Der Scope Creep kann aber auch durch unrealistische Versprechungen des Managements entstehen, oder weil Änderungen am Umfang ungenügend kontrolliert wurden. Wenn der Projektumfang nicht definiert werden kann, spricht man von einem Scope Grope. Wenn der Projektumfang völlig verändert wird, spricht man von einem Scope Leap. Der Scope Creep nennt sich auch Requirement Creep, Function Creep oder Feature Creep und beschränkt sich auf das unkontrollierte Zufügen von neuen Anforderungen.
Gold Plating kann auch ein Grund für einen Scope Creep sein. Dabei werden neue Funktionen absichtlich dem Projektumfang hinzugefügt und es wird mehr als verlangt geliefert. Dabei ist das Entwicklerteam selbst der Verursacher vom Scope Creep, weil es mehr leisten will, als ursprünglich vereinbart.
Um einen Scope Creep zu verhindern, oder vielmehr zu kontrollieren, gibt es verschiedene Massnahmen. Zum einen müssen Anforderungen formal und schriftlich festgehalten werden. Schaffen Sie einen Ort an dem jede Anforderung landet, damit Sie den Überblick behalten können und die Traceability sicherstellen können. Damit bleiben Auswirkungen von Änderungen am Projektumfang transparenter.
Kunden sollten ausserdem von Anfang bis Schluss einbezogen werden. Oftmals werden Kunden nur zu Beginn befragt, was sie haben wollen und danach wird nicht mehr genug kommuniziert, bis schlussendlich das Produkt bereit ist. Das kann zu unzufriedenen Stakeholdern führen, weil sie sich je nach dem etwas anderes vorgestellt haben. Aber auch wenn die Kunden immer einbezogen wurden, können Missverständnisse vorkommen. Damit dieses Risiko reduziert werden kann, empfiehlt es sich Use Case-Diagramme oder Systemkontextdiagramme zu verwenden.
Alle Projektbeteiligten sollten die Anforderungen klar verstehen. Dafür lohnt es sich diese einem Review zu unterziehen. Unklarheiten, Unstimmigkeiten und Fehler können so von Anfang an beseitigt werden. Dieser abgesegnete Stand kann danach während des gesamten Projektes verwendet werden, um den Stakeholdern klarzumachen, dass ein weiterer Wunsch Aufwand, Kosten und Verzögerungen mit sich bringt.
Für das Änderungsmanagement sollte ein klarer Prozess vorhanden sein. Jeder Veränderungswunsch muss diesen Prozess dann auch wirklich durchlaufen. Wünsche sollten nicht durch E-Mails oder mündlich angenommen werden, sonst wird der Arbeitsaufwand unterschätzt. Es sollte klargestellt werden, was genau die Änderung umfasst, welche Auswirkungen sie mit sich bringt und welche Risiken damit verbunden sind. Dadurch können Sie zusätzliche Aufwände und damit verbundene Kosten kontrollieren.
