Niemand startet ein Softwareprojekt mit dem Vorsatz, den Umfang später auszuweiten. Es passiert trotzdem, in fast jedem Vorhaben.
“Scope Creep” klingt nach einem Disziplinproblem: Der Kunde will immer mehr, der Dienstleister sagt nicht Nein. In unseren Projekten war es das selten. Meistens blieben am Anfang Dinge unklar, die zu diesem Zeitpunkt schlicht niemand klären konnte. Erst während der Umsetzung wird sichtbar, was das eigentliche Vorhaben war. Dann steht es plötzlich als Mehraufwand im Raum, obwohl es die ganze Zeit dazugehörte.
Vier Muster tauchen dabei immer wieder auf.
Die vier Muster
Muster 1
Der unsichtbare Sonderfall
Beschrieben wird der Prozess, wie er gedacht ist. Die siebzehn Ausnahmen, die eine Kollegin seit Jahren von Hand abfängt, tauchen erst auf, wenn die Software sie nicht abbilden kann. Sie standen in keiner Anforderungsliste, weil sie für alle Beteiligten längst normal waren.
Muster 2
Die späte Fachabteilung
Spezifiziert wird mit der Leitung, benutzt wird von der Fachabteilung. Sitzt die zum ersten Mal beim Abnahmetermin im Raum, kommen die Einwände zum teuersten Zeitpunkt.
Muster 3
Die Altdaten
Der zuverlässigste Kostentreiber überhaupt. Bestandsdaten sind nie so sauber wie angenommen: Dubletten, Felder mit doppelter Bedeutung, eine Spalte, in der seit 2014 zwei verschiedene Dinge stehen. Auffallen tut das bei der Migration, nicht bei der Schätzung.
Muster 4
Der Appetit beim Essen
Sobald etwas Funktionierendes da ist, entstehen neue Ideen. Oft gute. Zum Problem werden sie erst, wenn es kein Verfahren gibt, sie zu entscheiden.
Drei dieser vier Muster sind Erkenntnisgewinn, kein Fehlverhalten. Wer sie als Disziplinproblem behandelt, bekämpft das falsche Problem. Schlimmer noch: Es entsteht ein Klima, in dem Leute Bedenken lieber für sich behalten, weil jeder Einwand als Sonderwunsch gilt.
Warum der Festpreis das Problem nicht löst
Die naheliegende Reaktion: das Risiko vertraglich abgeben. Festpreis, klarer Leistungsumfang, alles Weitere kostet extra. Das funktioniert auch. Nur anders, als die meisten erwarten.
Erwartung
Der Festpreis begrenzt das Risiko
Der Dienstleister trägt die Unsicherheit, der Kunde hat Planungssicherheit. Was mehr wird, wird nachbeauftragt.
Realität
Der Festpreis verlagert es
Unsicherheit wird eingepreist. Ihr zahlt den Risikoaufschlag auch dann, wenn das Risiko nie eintritt. Und bei jeder Unklarheit steht im Raum, ob sie im Umfang enthalten war. Diese Diskussion kostet Vertrauen, genau in dem Moment, in dem beide Seiten es brauchen.
Ein Festpreis ist ein gutes Werkzeug, wenn das Vorhaben klar umrissen ist. Gegen Unklarheit hilft er nicht, weil er beide Seiten zwingt, so zu tun, als wäre alles bekannt.
Die ehrlichere Reihenfolge: erst klären, dann festpreisen.
Was tatsächlich hilft
Den Prozess aufnehmen, nicht die Wunschliste
Schaut zu, wie heute gearbeitet wird, statt zu fragen, was die Software können soll. Die Sonderfälle stehen in keiner Anforderungsliste. Sie zeigen sich, wenn jemand seinen Ablauf vorführt und dabei dreimal sagt: “und hier machen wir das immer noch von Hand”.
Früh in die echten Daten schauen
Ein Blick in die echten Werte, nicht ins Schema. Zwei Stunden hier ersparen regelmäßig zwei Wochen später. Der billigste Erkenntnisgewinn im ganzen Projekt.
Die Fachanwender von Anfang an dabei
Bei der Plattform für Statista war das der Hebel: Die Redaktion saß ab dem ersten Workshop mit am Tisch. Ein über Jahre gewachsenes Kernsystem ließ sich ablösen, ohne dass die Fachabteilung ihren Alltag verlor.
Ein Verfahren für neue Ideen
Gute Ideen während des Projekts sind ein Qualitätssignal. Sie brauchen einen Ort: eine Liste, die regelmäßig durchgegangen wird, mit einer Entscheidung am Ende. Jetzt, später oder gar nicht. Was entschieden ist, verschwindet aus den Statusrunden.
Der pragmatische Zuschnitt
Bewährt hat sich ein zweistufiges Vorgehen: ein kleiner, klar begrenzter Klärungsschritt vor der Umsetzung. Prozess aufnehmen, Daten sichten, Schnitt festlegen, Aufwand schätzen. Danach steht eine Grundlage, die trägt, und bei Bedarf ein Festpreis, der auf Fakten beruht statt auf Annahmen.
Manchmal kommt dabei heraus, dass das große Projekt gar nicht nötig ist. Wir hatten mehrere Fälle, in denen ein Bruchteil des ursprünglich Angedachten den eigentlichen Schmerz gelöst hat. Für genau diesen Schritt gibt es bei uns den Discovery-Workshop.
Wie wir Projekte insgesamt zuschneiden, steht auf der Seite zur Arbeitsweise. Wenn der Auslöser ein System ist, das nicht mehr mitwächst, passt eher der Artikel über die Grenzen der Branchensoftware.
Ein gesundes Projekt tut früh weh
Gegen Scope Creep helfen strengere Verträge wenig. Was hilft, ist Unsicherheit früh und billig aufzulösen statt spät und teuer.
Ein Projekt, in dem nach drei Wochen unangenehme Wahrheiten auf dem Tisch liegen, läuft gut. Eines, in dem alles glatt geht, bis es das plötzlich nicht mehr tut, ist meistens eines, in dem noch niemand nachgesehen hat.
