Scope Creep: Wie Projekte leise aus dem Ruder laufen

Der Kickoff war sauber: klarer Auftrag, definierter Leistungsumfang, unterschriebenes Lastenheft. Drei Monate später sitzt die Projektleitung im Steuerkreis und erklärt, warum der Termin wackelt – obwohl niemand je "Nein, das schaffen wir nicht" gesagt hat. Dazwischen lagen zwanzig kleine Bitten: ein zusätzliches Feld im Formular, eine weitere Schnittstelle, "wo wir schon dabei sind, könnten wir dann auch gleich…". Jede für sich war plausibel. In Summe haben sie das Projekt in ein anderes verwandelt, als das, für das ursprünglich Budget und Zeit veranschlagt wurden. Das ist Scope Creep – und er ist fast nie das Ergebnis einer einzelnen falschen Entscheidung, sondern vieler kleiner, für sich genommen vernünftiger.

Was Scope Creep eigentlich ist – und was nicht

Scope Creep bezeichnet die unkontrollierte, meist informelle Ausweitung des Projektumfangs gegenüber der ursprünglich vereinbarten Baseline. Wichtig ist die Abgrenzung zu zwei Nachbarphänomenen, die gerne verwechselt werden. Legitime Scope-Änderungen sind kein Problem – neue Erkenntnisse, veränderte Marktbedingungen oder gesetzliche Vorgaben können eine Anpassung durchaus rechtfertigen. Entscheidend ist nur, dass sie bewusst entschieden werden, mit Blick auf Aufwand, Termin und Budget. Scope Creep dagegen passiert am Entscheidungsprozess vorbei. Die zweite Verwechslung ist Gold Plating: Hier weitet nicht der Auftraggeber den Umfang aus, sondern das Team selbst liefert mehr, als verlangt wurde – aus Perfektionismus oder dem Wunsch, zu begeistern. Beides frisst Ressourcen, beides bleibt unsichtbar, solange niemand systematisch hinschaut.

Warum es fast immer schleichend passiert

Drei Muster tauchen in der Praxis immer wieder auf. Erstens fehlt häufig eine wirklich verbindliche Baseline: Wenn der ursprüngliche Leistungsumfang schwammig formuliert war, lässt sich später kaum beweisen, dass eine Anforderung "neu" ist – sie wird einfach als "war doch klar" durchgewunken. Zweitens scheuen Projektleitungen den Konflikt mit Auftraggebern oder wichtigen Stakeholdern. Ein Nein zu einer kleinen Zusatzanforderung fühlt sich unkollegial an, ein Ja kostet scheinbar nichts – bis sich die Summe der Jas zeigt. Drittens gibt es im agilen Umfeld ein Missverständnis, das den Effekt sogar verstärken kann: Agilität wird als "wir sind doch flexibel" gelesen, dabei bedeutet agiles Arbeiten nicht, jede Änderung sofort einzubauen, sondern Änderungen bewusst und priorisiert in den Backlog aufzunehmen – und dafür etwas anderes bewusst zurückzustellen.

Die Baseline als Bezugspunkt

Ohne einen fixierten Referenzpunkt lässt sich Abweichung nicht erkennen, geschweige denn steuern. Im klassischen Projektmanagement übernimmt das der Projektstrukturplan zusammen mit der Leistungsbeschreibung; im agilen Kontext das Sprint-Ziel und eine klare Definition of Done. Beides muss zu Beginn nicht nur existieren, sondern für alle Beteiligten verständlich und einsehbar sein. Eine gute Faustregel: Wenn eine neue Anforderung nicht in einem Satz gegen die ursprüngliche Zielsetzung gehalten werden kann ("Das gehört dazu, weil…" oder "Das ist neu, weil…"), fehlt entweder die Baseline oder die Disziplin, sie zu nutzen.

Ein pragmatischer Umgang mit Änderungen

Der Gegenentwurf zu Scope Creep ist nicht Starrheit, sondern ein leichtgewichtiger, aber verbindlicher Änderungsprozess. In größeren klassischen Projekten übernimmt das ein Change Control Board; im Mittelstand reicht oft eine feste Kurzrunde aus Projektleitung, Auftraggeber und einer fachlichen Instanz. Entscheidend sind drei Schritte, die sich nicht abkürzen lassen. Erstens: jede Änderung wird schriftlich erfasst, und sei es nur in einem Ticket – keine mündlichen Zusagen "zwischen Tür und Angel". Zweitens: eine kurze Impact-Analyse, die Aufwand, Termin, Kosten und Qualität in Bezug setzt, nicht nur "wie lange dauert das zusätzlich". Drittens: eine bewusste Entscheidung, die auch "Nein" oder "Ja, aber dafür fällt etwas anderes raus" lauten darf. Genau dieser dritte Punkt ist der Kern: Scope-Management bedeutet zu tauschen, nicht nur zu addieren. Im agilen Setting übernimmt die Product-Owner-Rolle diese Funktion, indem neue Wünsche in den Backlog wandern und dort gegen bestehende Prioritäten antreten müssen, statt den laufenden Sprint zu unterbrechen. Eine Requirements-Traceability-Matrix, so unspektakulär sie klingt, leistet in beiden Welten gute Dienste: Sie macht sichtbar, welche Anforderung wann und von wem hinzukam – und entzieht dem "das haben wir doch immer schon so gemeint" den Boden.

Ein typisches Beispiel

Ein mittelständisches Unternehmen lässt sein Kundenportal überarbeiten. Der ursprüngliche Scope umfasst Login, Profilverwaltung und Bestellhistorie. Im Laufe der Umsetzung kommen aus dem Vertrieb ein Wunsch nach Rabattcodes, aus dem Kundenservice ein Live-Chat-Widget und aus der Geschäftsführung eine Anbindung an das neue CRM hinzu – jedes Mal mit dem Argument, es sei "nur eine Kleinigkeit". Keine dieser Anforderungen ist falsch. Aber weil keine davon formal bewertet und gegen den ursprünglichen Umfang gestellt wird, verdoppelt sich der Aufwand, ohne dass Termin oder Budget je offiziell angepasst wurden. Als die Projektleitung schließlich eine Nachkalkulation vorlegt, herrscht Verwunderung – dabei steckte die Antwort die ganze Zeit im E-Mail-Verlauf.

Auf den Punkt

Scope Creep ist selten ein einzelner Fehler, sondern die Summe vieler unentschiedener Kleinigkeiten. Wer ihn vermeiden will, braucht keine bürokratische Hürde für jede Änderung, sondern drei feste Gewohnheiten: eine klare Baseline, die schriftliche Erfassung jeder Änderung und die bewusste Entscheidung, was dafür weichen muss. Genau diese Disziplin unterscheidet Projekte, die am Ende liefern, was vereinbart war, von jenen, die zwar viel geliefert haben – nur nicht das, wofür sie beauftragt wurden.