Scope Creep oder Change Request? Ein 5-Minuten-Entscheidungsraster

Nicht jede Kundenanfrage, die nicht explizit im Angebot steht, ist automatisch Scope Creep. Manche Anfragen sind eindeutig durch eine bestehende Position gedeckt, andere gehören klar in einen formalen Change Request, und nur ein Teil verschwindet unbemerkt im Tagesgeschäft. Der Unterschied zwischen diesen drei Fällen liegt selten in der Anfrage selbst, sondern darin, wie mit ihr umgegangen wird.

Warum diese Unterscheidung überhaupt wichtig ist

Ohne klare Kategorien wird jede Diskussion über eine Zusatzanfrage zur Einzelfallentscheidung nach Bauchgefühl: mal wird großzügig nachgegeben, mal unnötig hart verhandelt, je nach Tagesform und Stimmung. Ein festes Raster schafft stattdessen Konsistenz: Dieselbe Art von Anfrage wird über verschiedene Projekte und Kunden hinweg gleich behandelt, was sowohl intern für weniger Diskussionen sorgt als auch gegenüber Kunden fairer und nachvollziehbarer wirkt.

Drei Kategorien, eine Anfrage

Der entscheidende Punkt: Scope Creep und Change Request können exakt dieselbe Anfrage sein. Der einzige Unterschied ist, ob sie erkannt und dokumentiert wurde oder nicht.

Das Entscheidungsraster

Drei Beispiele durchgespielt

Beispiel 1: Der Kunde bittet um eine dritte Korrekturrunde, obwohl im Angebot zwei vereinbart waren. Die Leistung steht nicht im Scope, der Mehraufwand ist messbar (eine weitere Runde). Wird das vor Beginn kommuniziert und freigegeben, ist es ein sauberer Change Request. Wird die Runde einfach durchgeführt, ist es Scope Creep.

Beispiel 2: Der Kunde fragt, ob ein bereits beauftragtes Formular auch auf Mobilgeräten getestet wird. Responsive Testing gehört bei den meisten Webprojekten implizit zum Scope. Hier reicht ein kurzer Blick ins Angebot, um zu bestätigen: im Scope, keine weitere Aktion nötig.

Beispiel 3: Der Kunde möchte „nur kurz“ eine zusätzliche Landingpage für eine Kampagne, die im Angebot nicht vorkommt. Die Leistung ist eindeutig außerhalb des Scopes und der Aufwand nicht trivial. Wird das nicht vor Beginn angesprochen, ist es ein klassischer Fall von Scope Creep.

Beispiel 4: Der Kunde bittet in einem Call beiläufig um eine kleine Textänderung auf einer bereits abgenommenen Seite. Der Aufwand ist minimal (unter 15 Minuten), eine formale Freigabe wäre unverhältnismäßig. Hier ist es wirtschaftlich sinnvoller, die Änderung kulant vorzunehmen und kurz zu dokumentieren, statt sie als Change Request zu behandeln.

Grauzonen: wenn das Raster nicht eindeutig ist

Nicht jede Anfrage lässt sich sauber in eine der drei Kategorien einordnen. Besonders bei Beratungsmandaten mit offenem Themenzuschnitt oder bei sehr langjährigen Kundenbeziehungen verschwimmen die Grenzen zwischen „gehört eigentlich dazu“ und „ist eindeutig zusätzlich“. In diesen Fällen hilft eine einfache Zusatzregel: Im Zweifel wird die Anfrage kurz angesprochen, auch wenn sie am Ende kostenlos bleibt. Das kostet fast nichts, verhindert aber, dass sich Grauzonen-Anfragen unbemerkt zum Muster summieren.

Ein zweiter Grauzonenfall entsteht, wenn sich der Scope selbst über die Zeit weiterentwickelt hat, ohne dass das ursprüngliche Angebot formal angepasst wurde, etwa weil frühere Change Requests informell durchgewunken wurden. In diesem Fall lohnt es sich, in regelmäßigen Abständen eine aktualisierte Zusammenfassung des tatsächlich gelebten Scopes zu erstellen, damit das Raster wieder eine verlässliche Referenz hat, statt gegen ein längst überholtes Ausgangsangebot zu prüfen. Eine solche Aktualisierung muss nicht aufwendig sein: Oft reicht eine kurze, gemeinsam mit dem Kunden abgestimmte Notiz, die den aktuell gelebten Scope in wenigen Sätzen zusammenfasst und beiden Seiten als gemeinsamer Bezugspunkt für alle künftigen Anfragen dient.

Die Frage ist nie nur „gehört das dazu?“, sondern immer auch „wurde das rechtzeitig angesprochen?“

Wie du das Raster im Team einführst

Ein Entscheidungsraster nützt wenig, wenn es nur eine Person kennt. Gerade in Agenturen mit mehreren Projektverantwortlichen entscheidet jede Person sonst nach eigenem Ermessen, was noch im Scope liegt, mit entsprechend unterschiedlichen Ergebnissen. Drei Schritte helfen, das Raster tatsächlich im Alltag zu verankern:

• Das Raster einmal gemeinsam an zwei oder drei echten Beispielen aus vergangenen Projekten durchspielen, statt es nur als Dokument zu verteilen.
• Eine einzige verantwortliche Ansprechperson pro Projekt festlegen, die im Zweifel die Einordnung trifft. Das verhindert, dass unterschiedliche Teammitglieder dieselbe Anfrage unterschiedlich bewerten.
• Grenzfälle nicht einzeln diskutieren, sondern sammeln und in regelmäßigen Abständen (z. B. monatlich) gemeinsam besprechen, um das Raster bei Bedarf zu schärfen.

Das Raster für Retainer-Kunden anpassen

Bei Projektaufträgen mit klarer Abgrenzung funktioniert das vierstufige Raster meist direkt. Bei Retainer-Kunden ohne feste Leistungsliste lässt sich die erste Frage, steht die Leistung im Angebot, dagegen kaum beantworten, weil der Scope selbst zu vage formuliert ist. Hier hilft eine Zwischenlösung: Statt das Angebot zu prüfen, wird das monatliche Stundenkontingent oder die vereinbarte Leistungsliste als Referenz herangezogen. Fehlt auch diese, ist das eigentliche Problem nicht die einzelne Anfrage, sondern der fehlende Referenzpunkt. Dann lohnt sich zuerst eine Nachschärfung des Retainer-Vertrags, bevor das Raster überhaupt zuverlässig angewendet werden kann.

Warum das Raster nur so gut ist wie der Moment, in dem es angewendet wird

Dieses Raster funktioniert zuverlässig, vorausgesetzt, es wird bei jeder Anfrage angewendet, bevor die Arbeit beginnt. In der Praxis scheitert genau dieser Schritt: Bei hohem E-Mail-Volumen und mehreren parallelen Projekten wird das Raster nicht vergessen, weil es schlecht ist, sondern weil niemand daran denkt, es anzuwenden, bevor die Anfrage bereits bearbeitet wurde.

scopendo wendet dieses Prinzip automatisiert an: Die Software gleicht eingehende Kunden-E-Mails gegen den definierten Scope ab und markiert Anfragen, die eine der vier Fragen mit „Achtung“ beantworten würden, bevor du überhaupt entscheiden musst, ob du reagierst. Das Raster bleibt dabei die gedankliche Grundlage, die Software übernimmt lediglich den Teil, der im Tagesgeschäft am zuverlässigsten vergessen wird: das konsequente Anwenden bei jeder einzelnen eingehenden Nachricht, unabhängig davon, wie viele Projekte gerade parallel laufen. So bleibt das Raster auch dann zuverlässig, wenn ein Team wächst und die Anzahl gleichzeitiger Kundenprojekte irgendwann die Kapazität für manuelle Prüfung übersteigt.