Blog

Umgang mit Scope Creep

Ein insbesondere in der IT leider allzu verbreitetes Problem: Irgendwann hat das Projekt dann mal in etwa 2 Monate Verspätung. Den Aufwand für diese zwei Monate extra Entwicklungszeit trägt der Auftragnehmer wenn er zum Festpreis arbeitet und nicht aufpasst schnell selbst. Manchmal zu recht. Denn teilweise ist das auch eine selbst verschuldete Fehlkalkulation, was bedeutet, dass der Auftragnehmer den Aufwand an manchen Stellen schlicht unterschätzt hat. Was andererseits leider bei Projekten ab einer gewissen Größenordnung relativ leicht passieren kann. Teilweise hat das aber auch mit einem Phänomen zu tun, welches man im Projektmanagement und insbesondere bei IT-Projekten als schleichenden Funktionszuwachs oder als Scope Creep bezeichnet.

Was ist Scope Creep?

Dies ist ein sehr verbreitetes Problem, mit dem in der IT-Branche alle zu kämpfen haben. Im Projektmanagement ist das eine komplette Disziplin für sich. Es gibt auch schöne dicke Bücher, welche sich mit schicken mathematischen Formeln und Diagrammen zu diesem Thema auseinandersetzen. So sehr ich mir wünschen würde so etwas wegrechnen zu können hilft das aber leider zumeist auch nicht weiter.

Scope Creep kommt in der Regel durch neue Sichtweisen oder Erkenntnisse zu stande die sich erst während der Entwicklung ergeben. Diese neuen Erkenntnisse können wesentlich zur Verbesserung des Produkts beitragen. Schleichender Funktionszuwachs geht wie der Name schon sagt auch mit einem Zuwachs der Funktionalität einher. Das heisst nach Abschluß des Projekts erhält der Auftraggeber dann auch mehr als vorab abgesprochen wurde. Häufig realisiert der Auftraggeber auch erst während der Entwicklung, dass noch weitere Funkionen benötigt werden. Im Grunde genommen ist Schleichender Funktionszuwachs also nichts Schlechtes. In der Regel spricht man aber erst dann vom schleichenden Funktionszuwachs, wenn diese Erweiterungen nicht über formelle Prozesse sondern über informelle Absprachen in die Entwicklung einfließen. (Vergleiche auch die Definition im Projekt Magazin)

Vorab: Ich denke Scope Creep ist in fast allen Fällen nicht die Schuld von jemandem. Weder vom Auftraggeber noch vom Auftragnehmer. Es ist einfach das Problem, dass man vorab gemeinsam eine Spezifikation erarbeitet hat nach dem zu diesem Zeitpunkt besten Wissen und Gewissen und dann während der Entwicklung erhöht sich schleichend der Aufwand. Es ist meiner Meinung nach keine Schuldfrage. Aber es geht hier um ein “Phänomen”, welches alle Projektverantwortlichen anerkennen sollten.

Noch einfacher ausgedrückt ist das Problem, dass man vor dem Projekt ein Angebot auf Basis des besten zu diesem Zeitpunkt gegebenen Wissensstandes schreibt und die Projektkalkulation auch auf Basis dieser Definition durchführt. Während der Entwicklung kommen Funktionen hinzu die in der Spezifikation nicht beinhaltet waren, die aber für alle Beteiligten später Sinn machen. Der Aufwand steigt aber und wenn man nicht aufpasst trägt man diesen Aufwand als Auftragsnehmer allein.

Es mag absurd klingen. Aber ich denke fast jeder der regelmäßig an größeren IT-Projekten mit arbeitet wird im Grunde seines Herzens bestätigen, dass es manchmal auch schwierig ist eine eindeutige Antwort zu finden, warum ein Projekt plötzlich zwei Monate Verzögerung hat. Ob das jetzt ausschließlich an einer Fehlkalkulation, bzw Unterschätzung des Aufwands auf Auftragnehmerseite lag oder ob man es überwiegend mit schleichendem Funktionszuwachs zu tun hat. In der Praxis gehen diese beiden Perspektiven leider auch häufig nahtlos in einander über. Wenn man nicht aufpasst dann merkt man bei einem großen Projekt plötzlich lediglich, dass man zwei Monate mit dem Projekt hinten dran liegt und dass man diese Überschreitung der Entwicklungszeit gerade aus der eigenen Kasse finanziert.

Was tun bei schleichendem Funktionszuwachs?

Es gibt eigentlich nur zwei Möglichkeiten wie das gelöst werden kann. Entweder (und insbesondere für größere Projekte ist das irgendwann fast zwingend) man denkt über einen formellen Prozess für Änderungsanforderungen nach, oder man versucht den Verwaltungsaufwand möglichst gering zu halten und über eine Pauschale oder ähnliches einen Weg zu finden wie man die Last des schleichenden Funktionszuwachses zumindest gemeinsam tragen kann.

Während bei kleineren Projekten und ein wenig Kulanz auf beiden Seiten schleichender Funktionszuwachs tatsächlich mit gelegentlichen Pauschalzuzahlungen abgedeckt werden kann, kommt man bei großen Projekten in der Regel um ein professionelles Änderungsmanagement kaum herum.

Zudem gilt es von Anfang an wachsam zu sein. Denn wenn der Aufwand dann mal höher ist wie anfangs angenommen, kann man das leider nicht mehr ändern. Häufig ist der Aufwand dann auch nicht völlig über die ursprüngliche Kalkulation hinaus. Dennoch sollte man sich möglichst früh gemeinsam mit allen Projektbeteiligten fragen, ob man eher die minimale in der ursprünglichen Spezifikation vorgegebene Variante verwirklichen will. Oder ob man alle Features die erst während der Umsetzung einfallen auch verwirklichen will und ob man dafür in Kauf nimmt, dass der Aufwand wächst und in irgendeiner Form zumindest gemeinsam getragen werden muss.

Man muss dabei wirklich im Hinterkopf behalten, dass es sich ja dann auch nicht um einen höheren Aufwand für das gleiche Produkt handelt sondern um einen erhöhten Aufwand für ein dann besseres Produkt als ursprünglich geplant. Verhindern kann man diese Problematik leider nicht ganz. Man kann höchstens durch klare Kommunikation, Dokumentation und die entsprechenden Prozesse versuchen, dass das Problem maximal transparent wird und der Auftraggeber eine maximal transparente Entscheidungsgrundlage hat.

SHARE

Ansprechpartner:

ANDI PÜHRINGER

Wir freuen uns auf lhre Anfrage und beraten Sie gerne.

+49 4239 9599791
andi.puehringer@netzrezepte.de