Wie wir mit Änderungen während der Entwicklung umgehen – und warum sie kein Problem sind, wenn der Prozess stimmt.
Änderungen sind normal
Software entsteht nicht im luftleeren Raum. Sie entsteht im Kontakt mit der Realität. Und die Realität verändert sich – während der Entwicklung genauso wie danach. Neue Erkenntnisse aus dem Tagesgeschäft. Ein Prozess, der sich als komplexer herausstellt als gedacht. Eine bessere Idee, die erst beim Arbeiten mit dem System entsteht. Ein Markt, der sich verschiebt. Das ist kein Zeichen schlechter Planung. Das ist der normale Verlauf jedes Softwareprojekts, das nah genug am echten Geschäft gebaut wird. Die Frage ist nicht, ob Änderungen kommen – sondern wie wir damit umgehen.
Zwei Modelle, zwei Wege
Wie flexibel wir mit Änderungen umgehen können, hängt davon ab, wie wir zusammenarbeiten. Wir arbeiten je nach Projekt mit zwei Modellen:
Retainer – laufende Zusammenarbeit
Beim Retainer-Modell arbeiten wir mit einem festen monatlichen Kontingent an Entwicklertagen. Es gibt kein starres Lastenheft und keinen formalen Change-Request-Prozess. Stattdessen priorisieren wir gemeinsam in kurzen Zyklen: Was hat gerade den größten Hebel? Änderungen fließen natürlich in die laufende Arbeit ein. Neue Erkenntnisse, veränderte Anforderungen, bessere Ideen – alles wird in der nächsten Iteration berücksichtigt. Ohne Bürokratie, ohne Nachtragsverhandlungen. Das Retainer-Modell eignet sich besonders für:
- Langfristige Systementwicklung und kontinuierliche Weiterentwicklung
- Projekte, bei denen sich Anforderungen im Laufe der Zeit konkretisieren
- Unternehmen, die ihr Operating System dauerhaft weiterentwickeln wollen
Lastenheft – definierter Projektumfang
Bei manchen Projekten ist ein klar definierter Umfang sinnvoll. In diesem Fall arbeiten wir mit einem Lastenheft: einem dokumentierten Scope, auf dessen Basis wir entwickeln, kalkulieren und liefern. Das funktioniert gut – solange sich nichts ändert. Sobald sich aber etwas ändert, greift unser Change-Request-Prozess:
Wie der Change-Request-Prozess funktioniert
Wenn wir mit einem Lastenheft arbeiten und eine Änderung am vereinbarten Umfang nötig wird, läuft das so:
1. Änderung melden
Du meldest die gewünschte Änderung – ob neue Anforderung, geänderte Logik oder zusätzliches Feature. Das geht formlos, per E-Mail oder im gemeinsamen Projektkanal.
2. Bewertung
Wir prüfen die Änderung: Was bedeutet sie für die Architektur? Wie viel Aufwand entsteht? Beeinflusst sie den Zeitplan? Gibt es Abhängigkeiten zu anderen Komponenten?
3. Angebot
Du bekommst eine transparente Einschätzung: geschätzter Aufwand in Manntagen, Auswirkung auf den Zeitplan und – falls relevant – auf andere Teile des Systems.
4. Entscheidung
Du entscheidest: Umsetzen, verschieben oder verwerfen. Erst nach deiner Freigabe beginnt die Umsetzung. Keine versteckten Kosten, keine Überraschungen.
Was Änderungen kosten
Änderungen sind nicht kostenlos – das wäre unrealistisch. Aber sie sollten transparent sein. Deshalb gilt bei uns:
| 📋 | Jede Änderung wird dokumentiert und bewertet, bevor sie umgesetzt wird |
| 💰 | Der Aufwand wird in Manntagen geschätzt – auf derselben Basis wie das ursprüngliche Projekt |
| ⏱️ | Auswirkungen auf den Zeitplan werden offen kommuniziert |
| ✅ | Nichts passiert ohne deine Freigabe |
Eine Erfahrung aus vielen Projekten: Änderungen, die früh kommen, kosten wenig. Änderungen, die spät kommen, kosten viel. Das liegt in der Natur von Software – je mehr bereits gebaut ist, desto mehr wird von einer Änderung berührt.
Wie du Änderungen minimierst
Änderungen lassen sich nie ganz vermeiden. Aber sie lassen sich deutlich reduzieren – durch gute Vorarbeit: Das System-Audit macht den Unterschied. Je gründlicher wir dein Unternehmen vor der Entwicklung durchdringen, desto weniger Überraschungen tauchen währenddessen auf. Die Interviews mit allen relevanten Stakeholdern – von der Geschäftsführung bis zu den operativen Schlüsselusern – decken Anforderungen auf, die sonst erst Monate später sichtbar werden. Der System-Audit-Report liefert eine fundierte Ist-Analyse, eine klare Architektur und einen konkreten Umsetzungsfahrplan. Das ist die beste Versicherung gegen teure Nachträge. Kurze Entwicklungszyklen helfen. Wir entwickeln nicht monatelang im stillen Kämmerlein und präsentieren dann das Ergebnis. Wir liefern in kurzen Iterationen, holen Feedback ein und korrigieren den Kurs früh. Das reduziert die Wahrscheinlichkeit großer Änderungen drastisch. Ehrliche Kommunikation spart Geld. Wenn sich in deinem Unternehmen etwas ändert – ein neuer Prozess, ein neuer Kunde, eine neue Priorität – sag es uns früh. Je früher wir davon wissen, desto günstiger ist die Anpassung.
Die Kurzfassung
| Retainer | Lastenheft | |
| Änderungen | Fließen in die laufende Arbeit ein | Über Change-Request-Prozess |
| Flexibilität | Hoch – Priorisierung in jedem Zyklus | Definierter Scope, Änderungen kosten extra |
| Planbarkeit | Festes monatliches Budget, flexibler Inhalt | Fester Scope, festes Budget |
| Geeignet für | Langfristige Systementwicklung, sich entwickelnde Anforderungen | Klar abgegrenzte Projekte mit stabilem Scope |
Beide Modelle haben ihre Berechtigung. Welches besser passt, klären wir gemeinsam – meistens schon im Erstgespräch.