Scope Creep - wenn das Projekt schleichend aus dem Ruder läuft

Wer im Projektgeschäft tätig ist, begegnet der Gefahr des „Scope Creeps“ häufig. Was genau hat es mit diesem Begriff auf sich, und wozu kann es führen, wenn sich dieser ominöse „Scope Creep“ erst einmal in ein Projekt „hineingeschlichen“ hat?

Beginnen wir zunächst einmal mit einer Geschichte.

Es war einmal… ein Projekt.

Zu Anfang schien es noch klar und beherrschbar. Der Kunde K bestellt bei Agentur A ein Stück Software: sagen wir, ein webbasiertes Event-Management-System. In dem System möchte Kunde K Veranstaltungen mit einer bestimmten Menge an Daten anlegen und administrieren können. Weiterhin sollen sich Interessierte bei diesen Veranstaltungen anmelden können.

Es soll die Option geben, kostenpflichtige Veranstaltungen anzubieten, und in diesem Fall sollen die Interessenten auch Adressdaten hinterlegen können, an die die Rechnung gehen kann.
Die Anbindung eines Zahlungsdienstleisters war nicht vorgesehen.

Klingt soweit machbar

Agentur A schaut sich die Anforderungen an – sieht alles machbar und überschaubar aus. Man unterbreitet K einen Kostenvoranschlag, den dieser akzeptiert.

Recht bald nach Beginn der Zusammenarbeit beginnen jedoch die Probleme, die sich hauptsächlich aus zwei Faktoren speisen:

• Agentur A hat bei ihrer Kostenschätzung und dem daraus resultierenden Angebot nur auf die explizit ausgesprochenen Anforderungen des Kunden geschaut. Ob es unausgesprochene und damit mögliche implizite Anforderungen gibt, die ebenfalls bedient werden müssen, wurde nicht eruiert.
• Agentur A hat Kunde K im Angebot zwar aufgelistet, was der Leistungsumfang ist. Sie hat jedoch keine Angaben dazu gemacht, was nicht im Leistungsumfang enthalten ist. Eben sowenig ist geklärt, wie damit umzugehen ist, wenn sich im Projektverlauf herausstellt, dass für den Projekterfolg vereinbarte Funktionen anders oder umfangreicher realisiert werden müssen, als es die Kalkulation angenommen hatte.

Das Projekt kommt vom Kurs ab

Die Probleme beginnen schleichend: In einer Testrunde moniert der Kunde, dass bei kostenpflichtigen Veranstaltungen eine gewisse Validation der Daten doch sicherzustellen sei, damit die Nutzer dort keine Fehleingaben machen. Eine Validierung von Feldern wie der PLZ war zwar nicht kalkuliert, ist aber keine große Sache, denkt der Projektmanager von Agentur A – also lässt er das noch implementieren.
Doch dann sagt der Kunde, dass in seltenen Fällen auch Nutzer aus dem Ausland bei den Veranstaltungen teilnehmen, und nicht nur aus Deutschland. Also benötigt man noch ein Dropdown-Feld für die Länderauswahl.
Und Moment, wie ist das jetzt mit der Validation der Daten für die ausländischen Adressen? Muss natürlich dann schon länderspezifisch angepasst sein.
Und müsste die Applikation dann nicht auch die Bestätigungsmails auf Englisch für die internationalen Teilnehmer versenden können? Und wo kann man die ganzen Mails überhaupt editieren? Kann man aktuell nicht? Doch, das muss gehen, denn einmal im Jahr gibt es ja ein spezielles Event, das hat eine ganz andere Wertigkeit, da muss auch die Ansprache an die Teilnehmer eine andere sein, das muss also individualisierbar sein.
Und es sollte in dem Zuge natürlich auch möglich sein, Teilnehmer im Vorfeld einer Veranstaltung über Rundmails auf dem Laufenden zu halten oder Änderungen am Programm anzukündigen
Da braucht es dann für den noch nicht vorhandenen Mail-Editor auch ein paar Formatierungs-Optionen wie Fettung, kursiv, Listen, Links... und: klar, alle diese Mails dürfen dann auch kein Plaintext sein wie das, was das Testsystem da bisher noch verschickt, die müssen im Live-System schon HTML-formatiert sein, also mit dem Corporate Design des Kunden ... und und und.

All das fällt natürlich erst einen Monat auf, bevor die neue Event-Management-Plattform live gehen sollte.

Die Eskalation

Der Projektmanager von Agentur A, der zunächst die scheinbar „leichten“ Änderungen im Scope noch durchgewinkt hatte (Motto: „Augen zu und durch“), versucht das Ganze nun wieder einzufangen. Das gelingt aber nur bedingt. Kunde K kommentiert wütend mit der Einlassung:

„Das war doch von Anfang an klar, dass das so sein muss, sonst funktioniert es doch nicht!“

Das Ganze eskaliert jetzt sowohl in der Agentur als auch beim Kunden durch die Entscheiderebenen hoch. Es wird hektisch nach einer Lösung gesucht... und im besten Fall rauft man sich im Interesse des gemeinsamen Projekterfolgs irgendwie wieder zusammen:

• Agentur A rüstet einen Teil der Features auf eigene Kosten nach.
• Kunde K akzeptiert die Verschiebung des Going-Live um zwei Monate.
  Er handelt aber in dem Zuge auch noch einen Rabatt auf den Stundensatz von A für alle noch nachzureichenden Dienstleistungen aus. Als Kompensation dafür, dass er jetzt so unglaublich viel Stress im Vorfeld seines wichtigen Jahres-Events hat, das er nun nicht wie geplant schon in der neuen Plattform organisieren kann: „das ist ja wohl das Mindeste, was Sie für uns tun können.“

Der Ausgang

Am Schluss ist die Plattform dann zwar live gegangen, aber alle Beteiligten haben schwer Federn lassen müssen:

• Kunde K hatte erheblichen Mehraufwand durch die verzögerte Produkteinführung und durch den Umstand, in der heißen Phase gleich mehrere Personen auf seiner Seite in die Abstimmung und Verhandlungen mit Agentur abstellen zu müssen
• und Agentur A hat mit dem Projekt durch die zuerst durchgewunkenen Änderungen und dann durch die anteilige Kostenübernahme für die Fertigstellung sowie den zwischenzeitlich reduzierten Stundensatz keinen Gewinn mit dem Projekt erwirtschaftet. Zusätzlich bleiben gestresste und frustrierte Mitarbeitende auf Projektmanagement- wie auch der Entwickler-Ebene zurück.

Kunde K ist nicht davon überzeugt, dass Agentur A in Summe einen guten Job gemacht hat, obwohl das Projekt handwerklich gelungen ist. Agentur A wiederum ist schwer angenervt von Kunde K, der eine schwere Delle in den laufenden Umsatz geschlagen hat und dessen Projekt bei den Mitarbeitenden jetzt extrem unbeliebt ist.

Am Ende löst man die Zusammenarbeit wenige Monate nach dem Launch auf und geht getrennte Wege.

Musste das so kommen?

Vorab: das beschriebene Szenario ist fiktiv. Es gibt Kunde K und das beschriebene Event-Management-System nicht wirklich. Aber einige Bausteine und Vorkommnisse, aus denen sich dieses Szenario speist, und auch die daraus resultierende Eskalationsspirale, die haben wir bei erdfisch in der Vergangenheit leider auch schon erleben müssen.

Szenarien wie das beschriebene drohen immer dann, wenn das Risikomanagement eines Projekts scheitert, oder wenn die Rahmenbedingungen, die zu Beginn für das Projekt abgesteckt worden sind, von vornherein unrealistisch gesetzt waren und der Dienstleister im Projektverlauf nicht rechtzeitig den „Mut“ aufbringt, dem Kunden dies aufzuzeigen.

Wir waren doch bei „Scope Creep“...!?

Genau. Aber, um zu verstehen, was Scope Creep eigentlich ist, ist es wichtig, sich erst einmal das thematische Umfeld klarzumachen, in dem Scope Creep auftreten kann. Wir müssen uns ebenfalls ansehen, welche Protagonisten im Projekt Einfluss darauf haben, dass Scope Creep überhaupt entsteht – und ebenso Einfluss darauf haben, ihn zu verhindern.

Wie äußert sich Scope Creep, wenn man ihn zulässt?

Ein paar Folgen, wenn ungeplante Änderungen am Leistungsumfang unkontrolliert zugelassen werden, konnten wir schon in unserem Eingangsszenario beobachten:

• die mit dem Kunden vereinbarte Frist zur Fertigstellung des Projekts konnte nicht eingehalten werden, da mehr Funktionen konzeptioniert, umgesetzt und getestet werden mussten, als in der ursprünglichen Beauftragung vorgesehen waren
• der Abstimmungsaufwand zwischen Kunde und Dienstleister war deutlich größer als geplant
• das Projekt hat das vorgesehene Budget gesprengt und somit Mehrkosten verursacht, die der Anbieter zum Teil selbst zu tragen hatte, was die Rentabilität des Projekts zunichtegemacht hat – aber auch der Kunde musste mehr bezahlen, als er veranschlagt hatte
• es konnte im Rahmen des Projekts kein wechselseitiges Vertrauen zwischen Anbieter und Kunde aufgebaut werden, da beide Seiten keinen praktikablen Umgang mit der Situation gefunden haben

Scope Creep kann sich aber auch noch in vielerlei anderer Hinsicht negativ auswirken:

• möglicherweise spart der Dienstleister an Sorgfalt und Qualität bei der Umsetzung, um seine Verluste durch den zugelassenen Scope Creep zu begrenzen, sodass das Endprodukt weniger sicher, stabil und zukunftsfähig ist
• möglicherweise müssen andere und eigentlich wichtigere Funktionen, die geplant waren, nun geopfert werden
• wenn der Kunde für das neue Produkt ein anderes ablösen möchte, muss er dieses nun ggf. länger betreiben als gewünscht und hat somit länger parallele Kosten
• wenn der Dienstleister parallel auch die Projekte anderer Kunden betreut, können diese aufgrund der ungeplanten Mehrarbeiten am „Problem-“Projekt ebenfalls in Verzug geraten

Aber ist Scope Creep bei komplexen Projekten nicht normal?

Hier gilt es zu unterscheiden. Der springende Punkt ist: initial vergessene Funktionen oder unerwartete Änderungen und Erweiterungen gegenüber einem ursprünglich vereinbarten Funktionsumfang sind bei komplexen Projekten durchaus normal und üblich.

Oft haben Kunde und Anbieter zu Projektbeginn nur eine unvollständige gemeinsame Vorstellung davon, was den Scope des Projekts überhaupt ausmacht. Entsprechend können beide Parteien Auslöser für Funktionsanpassungen sein:

• der Kunde selbst, beispielsweise weil er während der Umsetzung merkt, dass Teile seiner Geschäftsprozesse mit dem zur Verfügung gestellten Funktionsumfang noch nicht wie gewünscht abgebildet werden können
• aber auch der Dienstleister, beispielsweise weil dieser seinerseits erst nach Beginn der Umsetzung feststellt, dass initial angedachte technische Konzepte nicht funktionieren und Funktionen anders realisiert werden müssen

Es gibt zudem auch noch weitere Interessengruppen oder Einflussnehmer, deren Erwartungen oder Bedürfnisse Änderungen am Feature-Set erforderlich machen können.

Beispiele sind:

• weitere, bisher nicht im Projekt involvierte, Kundenabteilungen werden zu neuen Stakeholdern mit eigenen Interessen im Projekt, da
  • ihre Geschäftsprozesse davon berührt werden, oder
  • weil erst im Rahmen der Umsetzung klar wird, dass Systeme, mit denen diese anderen Abteilungen arbeiten, mit dem neu umzusetzenden Projekt interagieren sollen
• die Zielgruppe des Kunden, also die Endbenutzer, für die das umzusetzende System vorgesehen ist
• Drittfaktoren – etwa im Falle von zusätzlichen Software-Plattformen, die über Schnittstellen anzubinden sind

Zu Scope Creep werden geänderten Anforderungen von einer der genannten Interessengruppen aber erst, wenn sie durch das Projekt- oder Risikomanagement entweder unbemerkt oder von diesem unkontrolliert in die laufende Entwicklung einsickern.

Das kann zum Beispiel passieren, wenn entwickelnde Personen direkten Kontakt zu Kunden-Stakeholdern haben, ohne dass agentur-intern auch eine entsprechende Kommunikation beispielsweise zum verantwortlichen Projektmanager oder auch dem zuständigen Solution-Architect erfolgt, so dass diese von möglichen Zusatzwünschen auch erfahren und darauf reagieren können.

Aber auch ein Projektmanager selbst kann Scope-Creep verursachen, wenn sie oder er konfliktscheu ist oder aber die gegebenen vertraglichen Rahmenbedingungen mit dem Kunden nicht so gestaltet sind, dass der Scope Creep abgewehrt werden kann.

Welche Arten von Projekten sind für Scope Creep anfällig?

Im Grunde alle. Natürlich läuft ein klassisches Festpreisprojekt mit einem vermeintlich vorab klar umrissenen Projektumfang und einem zeitlich bereits ausdefinierten Projektplan besondere Gefahr, bei zugelassenem Scope Creep vom Kurs abzukommen, da sofort alle drei der vorab sorgfältig gegeneinander austarierten Projektparameter Budget, Zeit und Funktionsumfang ins Ungleichgewicht zueinander geraten werden.

Aber auch agil gemanagte Projekte, die bewusst darauf ausgelegt sind, zumindest zwei der drei genannten Projektparameter Budget, Zeit und Funktionsumfang flexibel zueinander balancieren zu lassen, können bei Scope Creep in Schwierigkeiten geraten.

Eine Möglichkeit dafür ist, wenn beispielsweise bei iterativen Software-Sprints, die vorab als in sich geschlossene Einheit mit einem bestimmten Aufgabenpaket für einen bestimmten Zeitpunkt geplant worden sind, während der Sprintlaufzeit die Menge an Anforderungen geändert wird. Wird der Sprint dann nicht abgebrochen, neu priorisiert und neu gestartet, können auch die Sprintziele nicht mehr erreicht werden.

Welche Defizite im Projektmanagement begünstigen Scope Creep?

1. Das Versäumnis,
den Kunden zu Projektbeginn über mögliche Gefahren und Risiken aufzuklären.

Zugegeben: Viele Gefahren und Risiken im Projektgeschäft kennt man erst, wenn man selbst schon einmal in das jeweilige Fettnäpfchen getreten ist und dafür bitteres Lehrgeld hat zahlen müssen. Fehler machen wir alle, und innovative und mutige Menschen machen vielleicht sogar mehr Fehler, weil sie stetig bereit sind, ausgetretene Pfade zu verlassen und etwas Neues zu probieren (mehr Chancen = mehr Risiken). Solange wir aus diesen Fehlern lernen und sie nicht wiederholen, so lange haben Fehler also auch ihr gutes. Zumindest wenn der Fehler nicht so schwerwiegend war, dass er uns „den Kopf gekostet hat“.

Wenn der Dienstleister, also aus Erfahrung weiß, was alles im Projekt schieflaufen kann, dann ist er gut beraten, den Kunden am Beginn der gemeinsamen Reise oder vielleicht sogar schon während der Vertragsverhandlungen darüber aufzuklären, welchen Risiken das Projekt ausgesetzt sein kann (und welche er als Kunde davon selbst beeinflussen kann) –  und ihm so auch eine Teilverantwortung für den Projekterfolg zu übertragen. Denn schließlich wollen Kunde und Dienstleister ja gemeinsam das Ziel erreichen.

2. Das Versäumnis, den Modus Operandi im Projekt vor dessen Start klar kommuniziert zu haben

Am liebsten möchte jeder Kunde natürlich ein Projekt mit sicherem Budget, sicherer Zeitschiene und garantiertem Funktionsumfang, wo aber bei Bedarf auch noch Sachen „on top“ kommen können, und am besten auch, ohne dass dies zu Mehrkosten oder Verzögerungen führt.

Diesen „heiligen Gral“ der Projektorganisation hat unserem Wissen nach bisher niemand gefunden – also muss es immer an irgendeiner Stelle Abstriche geben:

• eine Kombination aus festem Budget, Zeitplan und Feature-Set schließen Flexibilität aus
• ist das Feature-Set gegeben, soll aber flexibel änder- und erweiterbar sein, können Budget und Zeitraum nicht fix bleiben
• soll das Budget und der Zeitrahmen konstant bleiben, aber auch flexibles Änderungsmanagement am vereinbarten Funktionsumfang möglich sein, muss sich das abzuliefernde Feature-Set verkleinern können

Im Vorfeld des Projekts muss daher mit dem Kunden abgesprochen und auch vertraglich vereinbart sein, welche organisatorischen Projektparameter für das Projekt gelten werden, und welche Vor- und welche Nachteile der gewählte Modus Operandi für den Kunden jeweils hat.

3. Das Versäumnis, den Kunden im Vorfeld darüber zu informieren, was nach dem Verständnis des Dienstleisters kein Projektbestandteil ist

Auch hier muss eingeräumt werden, dass dies eine sehr schwierige Aufgabe sein kann, denn dazu muss man sich als Dienstleister ja erst einmal selbst darüber klar sein, welche potenziellen „Rattenschwänze“ eine bestimmte Kundenanforderung möglicherweise nach sich zieht.

 Auch hier hilft letzten Endes nur: Erfahrung sammeln. Viele Anforderungen ähneln sich über die Projekte hinweg, und wenn man bei einem anderen Projekt mit einer vergleichbaren Anforderung schon „derb auf die Schnauze“ gefallen ist, muss dieser Erfahrungsgewinn genutzt werden, um im neuen Projekt ein gemeinsames Verständnis mit dem Kunden für den abzuliefernden Funktionsumfang zu erlangen – und für das, was außen vor bleibt. Oft kommen auf diesem Wege auch einige der berüchtigten „impliziten Anforderungen“ ans Licht, die sich in jedem Projekt irgendwo tief drinnen versteckt halten.

4. Das Versäumnis, getroffene Annahmen nicht auszusprechen

Explizite Anforderungen an das Projekt sind nämlich das eine. Sie werden aber in der Praxis nie vollständig abdecken, was der Kunde von seinem Projekt erwartet. Es wird also immer implizite Anforderungen geben, die nicht ausgesprochen werden, die aber später auf dem Tisch des Dienstleisters landen oder die er schon während der Konzeptionsphase identifiziert und sich damit beschäftigt hat.

Da es für diese Anforderungen keine Passage im Lastenheft oder keine User Story im Backlog gibt, muss der Dienstleister sich selbst überlegen, wie er die Anforderung abdecken würde. Dazu werden Annahmen in der technischen Anforderungsanalyse getroffen, anhand derer die implizite Anforderung bei entsprechender Implementierung mutmaßlich abgedeckt wäre. Aber der Dienstleister ist nur Ersteller der Software, nicht deren Betreiber.

Daher ist es unerlässlich, getroffene Annahmen immer frühzeitig mit dem Kunden zu erörtern. Denn vielleicht fällt dann auf, dass die Annahmen falsch oder unvollständig waren und der Kunde ganz andere Erwartungshaltungen mitbringt.

5. Das Versäumnis, den Kunden nicht regelmäßig einzubinden

Wenn ein Kunde

• während des gesamten Umsetzungsprozesses eines Projekts stetig an der Seite des Dienstleisters ist,
• es regelmäßige Abstimmungstermine zwischen dem Kunden und dem Projekt-Team des Dienstleisters gibt,
• und der Kunde frühzeitig Prototypen oder frühe Entwicklungsstadien des umzusetzenden Projekts „sehen und anfassen“ kann,

können etwaige Deltas zwischen der Implementierungslösung des Dienstleisters und der Erwartung des Kunden schon erkannt werden, wenn sie noch klein sind und eine ggf. notwendige „Kurskorrektur“ nur wenig Impact auf das Gesamtprojekt hat.

Nach einem ggf. initial stattgefundenen „Kickoff“-Termin als Dienstleister für mehrere Monate abzutauchen und ohne regelmäßigen Austausch mit dem Kunden das Produkt mehr oder weniger „auf gut Glück" zu implementieren, ist dagegen ein Spiel mit dem Feuer und geht in den seltensten Fällen gut.

6. Das Versäumnis, nicht einfach mal "Nein" zu sagen

Der Kunde ist König, der Dienstleister da, um dessen Wünsche zu erfüllen? Radio Eriwan würde sagen: „Im Prinzip ja. Aber nicht dann, wenn dessen Wünsche den Projekterfolg gefährden und er sich damit letztlich selbst schaden würde.“

Änderungswünsche begründet abzublocken und damit ggf. eine kurzfristige Enttäuschung beim Kunden zu verursachen, kann das bei Weitem kleinere Übel gegenüber der Möglichkeit sein, dass das ganze Projekt in Schieflage gerät.

7. Das Versäumnis, auf Kundenseite einen Teampartner mit Entscheidungsmacht zu haben

Zugegeben, es ist ein Problem, das der Dienstleister unter Umständen selbst nicht lösen kann: wenn der zuständige Ansprechpartner auf Kundenseite selbst nur begrenzt maßgebliche Projekt-Entscheidungen treffen darf und sich für alle möglichen und unmöglichen wegweisenden Entschlüsse immer erst Freigaben von für den Dienstleister nicht greifbaren Hintergrund-Stakeholdern einholen muss.

Noch schlimmer wird es, wenn dann auch noch mehrere Stakeholder-Gruppen mit ggf. sich widersprechenden Vorstellungen involviert sind, sodass Entscheidungen entweder aufgrund von wechselseitigen Blockaden gar nicht fallen oder getroffene Entscheidungen wieder revidiert werden.

Ist man erst einmal in einer solchen Situation, ist das wiederholte Auf- und Wiederverschnüren von Arbeitspaketen praktisch nicht mehr zu vermeiden – auf Kosten von Zeit und Budget. Wichtig ist in diesem betrüblichen Szenario aber immer, dass der Dienstleister es an Kommunikation nicht mangeln lässt und belegbar auf die erkannten Probleme und ihre Folgen hinweist.

Dann ist er zumindest seiner Beratungspflicht nachgekommen, auch wenn die internen Strukturen des Kunden den Projekterfolg zumindest im vorab angestrebten Rahmen verunmöglicht haben.

8. Das Versäumnis, den Kunden frühzeitig und kontinuierlich zur Mitarbeit und zu Feedback zu bewegen

Von Seiten eines guten Dienstleisters besteht an den Kunden immer das Angebot – oder man könnte es auch „Forderung“ nennen – seinerseits ebenfalls frühzeitig und regelmäßig für das gemeinsame Projekt Zeit einzuplanen, daran mitzuarbeiten und es kontinuierlich durch Testing und Feedback dem Produkt anzunähern, das er gerne hätte.

Nicht wenige Kunden sind aber mit diesem „Angebot“ gar nicht so glücklich, denn es kostet sie etwas, von dem sie meist noch weniger haben als Budget: Zeit. Vielleicht wurde von Kundenseite die Annahme getroffen: „ich schreibe einmal auf, was ich ungefähr benötige, nehme mir ein, zwei Mal Zeit für ein Kickoff- und ein Status-Meeting, und irgendwann bekomme ich dann geliefert, was ich bestellt habe".

Dass er jetzt jede Woche in Weeklies mit dem Dienstleister-Team muss, Stunden damit verbringt, ein „halb fertiges“ System zu testen, und weitere Stunden damit, sich mit dem Projektmanager des Dienstleisters über den genauen Wortlaut von Akzeptanzkriterien auszuauschen und dann auch noch ständig deren Richtigkeit und Vollständigkeit bestätigen muss („alles andere ist nicht in Scope“) – das hat er sich so vielleicht nicht vorgestellt.

Und doch ist das oftmals der einzige Weg, um sicherzustellen, dass sich nicht kurz vor dem geplanten Going-Live plötzlich eine riesige Bugwelle an „unverzichtbaren Last-Minute-Aufgaben“ auftürmt, ohne die der Launch keinesfalls stattfinden kann. Entsprechend wichtig ist es daher, auch "partizipations-unwillige" Kunden argumentativ abzuholen, ihnen klarmachen, warum ihre Mitarbeit für den Projekterfolg unabdingbar ist, und welche Konsequenzen eintreten können, wenn der Kunde die ihm zugedachte Rolle im Projekt nicht gemäß der getroffenen Vereinbarungen ausübt.

Wie reagieren die Projektbeteiligten richtig auf sich ändernde Anforderungen

Um es nochmals deutlich zu machen: nicht sich ändernde oder zusätzliche Projekt-Anforderungen an sich sind das Problem, sondern der falsche Umgang mit ihnen. Es wird nie funktionieren, in ein durchgetaktetes Festpreis-Projekt neue Anforderungen zu kippen, ohne dass dies entweder

• zulasten des bisher vereinbarten Funktionsumfangs geht oder
• länger dauert und mehr kostet bzw. die Qualität des Gesamtprojekts leidet

Aber auch in einem agilen Projekt funktioniert das „Draufpacken“ veränderter oder zusätzlicher Anforderungen nicht ohne weiteres Zutun des Projektmanagements. Denn auch hier muss dann zuerst überprüft werden, wie sich die Balance der drei Projektparameter - Budget, Zeit und Funktionsumfang – nun ändert, welche Implikationen das auf das Backlog und dessen Priorisierung hat.

Daher gilt in beiden Fällen:
Sobald klar wird, dass eine Anforderung neu oder modifiziert ist oder die vom Kunden erwartete Ausprägung nicht den Annahmen entspricht, die der Dienstleister bei seiner Kalkulation angenommen hat, muss seitens des Projektmanagements der Kontakt zum Kunden gesucht, auf den Sachverhalt hingewiesen und erörtert werden, wie mit dieser „Scope-Änderung“ umzugehen ist. Dabei ist auch der Anlass der „Scope-Änderung“ einzubeziehen bzw. die Wahrnehmung des Kunden:

• ist er sich selbst bewusst, dass er vom vereinbarten Funktionsumfang abweicht?
• oder teilt er die Wahrnehmung des Dienstleisters an dieser Stelle gar nicht, dass überhaupt eine „Scope-Änderung“ stattgefunden hat? (Stichwort: „das war doch klar, dass das so sein muss“)

Naturgemäß ist der letztgenannte der beiden Fälle derjenige, der deutlich unangenehmer ist und mit dem schwieriger umzugehen ist. Aber es nützt nichts, sich dieser Konfrontation nicht zu stellen. Es wird nur immer schlimmer werden, wenn man die Sache einfach laufen lässt – und für das nächste Projekt nimmt man dann in jedem Fall wichtige „Learnings“ mit.

Was ist kein Scope Creep?

Wir haben ja bereits gelernt, dass Änderungswünsche während der Implementierungsphase bei einem komplexen Projekt durchaus normal und legitim sein können – und es auf den Umgang mit ihnen ankommt, der entscheidet, ob daraus Scope Creep entsteht oder nicht.

Im Idealfall kommen Änderungsanfragen oder zusätzliche Feature-Wünsche auch relativ früh im Projektverlauf – was dann wahrscheinlicher ist, wenn der Kunde stetig in die Entwicklung eingebunden ist und sich regelmäßig die Zeit nimmt, den vorliegenden Entwicklungsstand in Augenschein zu nehmen und zu testen.

Denn je früher im Projektverlauf Änderungsbedarf erkannt und benannt wird, desto mehr Spielraum haben Kunde und Dienstleister, die Projektparameter Budget, Zeit und Funktionsumfang neu gegeneinander auszutarieren.

Korrekterweise muss der Änderungswunsch oder das neue Feature wie auch schon der bestehende Arbeitsumfang auf seinen Aufwand und auf seine Implikationen hin analysiert und eingeschätzt werden:

• wie groß ist der zusätzliche Aufwand?
• reichen die vorhandenen Risikopuffer im Projekt dafür aus oder muss die Projektplanung angepasst werden?
• genügt das kalkulierte Budget für die Ergänzung, oder muss nachbudgetiert werden?
• falls keine Nachbudgetierung möglich ist: auf welche andere vom Umfang her vergleichbare und noch nicht implementierte Funktion wäre der Kunde bereit, zu verzichten?
• selbst wenn das Budget kein Problem darstellt und die Erweiterung finanzierbar ist: stehen dafür ausreichend Entwicklerkapazitäten zur Verfügung? Bedeutet die Umsetzung der Erweiterung eine merkliche Verzögerung im Zeitplan? Falls ja, ist die Verzögerung für den Kunden tolerierbar?

Erst wenn alle diese Aspekte benannt und vom Kunden in enger Absprache mit dem Dienstleister gegeneinander abgewogen worden sind, sollte die Entscheidung gefällt werden, den Projekt-Scope zu ändern. Und – ganz wichtig: diese Entscheidung muss der Kunde bewusst treffen, und sie muss dokumentiert werden, damit beide Seiten sich bei Bedarf im Nachgang darauf berufen können.

Fazit

Scope Creep kann eine große Gefahr für den Projekterfolg darstellen. Denn wenn unkontrolliert Funktionsänderungen oder neue Anforderungen in einen bestehenden Scope hineinwandern, sind sowohl Zeitpläne als auch initial vereinbarte Budgets schnell Makulatur: Das Projekt droht zu scheitern.

Entsprechend wichtig ist es, Änderungswünsche, die sich bei komplexen Projekten unweigerlich einstellen werden, korrekt zu adressieren, zu bewerten und alle Faktoren gegeneinander abzuwägen. Erst wenn das geschehen ist, muss  der Kunde selbst die ausdrückliche Entscheidung treffen, den Scope zu ändern – bei vollem Wissen über die sich daraus ergebenen Implikationen.

Dafür braucht es ein kompetentes Projektmanagement, das über ein verlässliches Gesamtbild des Projekts verfügt und einen erfahrenen Solution Architect, der die Folgen und Wechselwirkungen von Änderungswünschen auf das technische Konzept des Projekts bewerten kann.
Außerdem braucht es natürlich auch einen Kunden, der – sofern ihm die postulierten Änderungen wirklich wichtig sind – auch die Bereitschaft mitbringt, über den Umfang und die Ausgestaltung des Feature-Sets für sein Projekt ggf. immer wieder aufs neue in den Dialog zu treten und diesen neu auszuhandeln.