Zwei Modelle der Zusammenarbeit – und warum wir bei Operating Systems meistens den Retainer empfehlen.
Warum diese Frage wichtig ist
Bevor es um Architektur, Technologie oder Features geht, stellt sich eine grundlegende Frage: Wie arbeiten wir zusammen? Auf Festpreisbasis mit definiertem Umfang? Oder als laufende Zusammenarbeit mit einem monatlichen Kontingent? Beide Modelle haben ihre Berechtigung. Aber sie funktionieren grundlegend anders – und die Wahl hat Auswirkungen auf Flexibilität, Geschwindigkeit, Kosten und Ergebnis.
Wie Festpreis funktioniert
Beim Festpreismodell wird vor der Entwicklung ein Umfang definiert: Lastenheft, Pflichtenheft, Scope. Was drinsteht, wird gebaut. Was nicht drinsteht, wird nicht gebaut – oder nur über einen formalen Change-Request-Prozess nachträglich beauftragt. Der Ablauf:
- Anforderungen werden vorab detailliert dokumentiert
- Auf Basis des Dokuments wird ein fester Preis kalkuliert
- Entwicklung erfolgt entlang des definierten Scope
- Änderungen werden über Change Requests geregelt – mit separater Bewertung und Beauftragung
- Abnahme am Ende des Projekts
Vorteile:
| 💰 | Planbare Kosten – du weißt vorher, was es kostet |
| 📋 | Klarer Scope – was gebaut wird, ist dokumentiert |
| ✅ | Definierter Abschluss – es gibt ein Projektende |
Nachteile:
| 🔒 | Wenig Flexibilität – Änderungen kosten extra und dauern länger |
| ⏳ | Lange Vorlaufzeit – Anforderungen müssen vor der Entwicklung komplett definiert werden |
| 📄 | Hoher Dokumentationsaufwand – Lastenheft, Pflichtenheft, Change Requests |
| 🎯 | Falsche Sicherheit – der fixe Preis gilt nur für den fixierten Scope, nicht für das Ergebnis |
Wie Retainer funktioniert
Beim Retainer-Modell bucht der Kunde ein festes monatliches Kontingent an Entwicklertagen. Es gibt keinen fixierten Scope im klassischen Sinn. Stattdessen wird in kurzen Zyklen priorisiert: Was hat gerade den größten Hebel? Was haben wir aus dem letzten Zyklus gelernt? Was hat sich verändert?
Ablauf:
- Monatliches Kontingent an Entwicklertagen wird vereinbart
- Gemeinsame Priorisierung in regelmäßigen Abstimmungen
- Entwicklung in kurzen Iterationen mit schnellem Feedback
- Änderungen fließen natürlich in die laufende Arbeit ein
- Kein formales Projektende – das System wächst mit dem Unternehmen
Vorteile:
| 🔄 | Maximale Flexibilität – Prioritäten können sich jederzeit ändern |
| ⚡ | Schnellere Ergebnisse – keine monatelange Vorabdefinition |
| 🎯 | Bessere Ergebnisse – weil das System auf echtem Feedback wächst, nicht auf Annahmen |
| 📉 | Kein Change-Request-Overhead – Änderungen sind eingeplant, nicht die Ausnahme |
| 🤝 | Echte Partnerschaft |
Nachteile:
| ❓ | Weniger vorhersagbar – du weißt nicht exakt, welche Features in Monat 3 fertig sind |
| 🔁 | Erfordert laufende Beteiligung – regelmäßige Abstimmungen sind Pflicht |
| 📊 | Ergebnis hängt von der Zusammenarbeit ab – ohne Input vom Kunden entsteht nichts |
Warum Retainer bei Operating Systems besser passt
Ein Operating System ist kein Projekt mit Anfang und Ende. Es ist ein lebendes System, das sich mit dem Unternehmen weiterentwickelt. Und genau hier liegt das Problem mit Festpreis:
Du kannst nicht alles vorher wissen
Operative Systeme sind komplex. Die Anforderungen werden erst richtig klar, wenn das Team anfängt, mit der Software zu arbeiten. Wenn echte Daten fließen. Wenn Prozesse in der Praxis auf das System treffen. Ein Lastenheft, das vor der ersten Zeile Code geschrieben wird, kann diese Realität nicht vollständig abbilden – egal wie gründlich es erstellt wurde.
Änderungen sind kein Fehler – sie sind der Prozess
Im Festpreismodell sind Änderungen ein Problem: Change Request, Bewertung, Nachkalkulation, Freigabe. Im Retainer sind Änderungen der Normalfall. Jede Iteration bringt neue Erkenntnisse. Jedes Feedback macht das System besser.
Die besten Features in unseren Projekten waren selten die, die im ersten Konzept standen – sondern die, die aus der Praxis entstanden sind.
Das System ist nie fertig
Unternehmen verändern sich. Märkte verändern sich. Anforderungen verändern sich. Ein Operating System muss darauf reagieren können – nicht einmal im Jahr durch ein neues Projekt, sondern kontinuierlich. Der Retainer bildet diese Realität ab. Festpreis tut das nicht.
Typische Bedenken – und ehrliche Antworten
"Ohne Festpreis habe ich keine Kostenkontrolle."
Doch. Das monatliche Kontingent ist fix. Du weißt genau, was du pro Monat investierst. Was sich ändert, ist nicht der Preis – sondern der Inhalt. Und den bestimmst du mit.
"Woher weiß ich, dass die Zeit sinnvoll genutzt wird?"
Durch Transparenz. Wir arbeiten in kurzen Zyklen mit regelmäßigen Abstimmungen. Du siehst nach jedem Zyklus, was entstanden ist. Du priorisierst mit, was als nächstes kommt. Und du kannst jederzeit den Kurs anpassen.
"Festpreis gibt mir mehr Sicherheit."
Festpreis gibt dir Preissicherheit – nicht Ergebnissicherheit. Du weißt, was es kostet. Aber du weißt nicht, ob das Ergebnis tatsächlich zu deiner Realität passt. Weil die Realität sich zwischen Lastenheft und Abnahme verändert hat. Ein Retainer tauscht scheinbare Sicherheit gegen echte Anpassungsfähigkeit.
Wann Festpreis trotzdem sinnvoll ist
Wir sind keine Dogmatiker. Festpreis ist die richtige Wahl, wenn:
- Der Scope wirklich klar und stabil ist
- Es sich um ein abgegrenztes Einzelprojekt handelt, nicht um Systementwicklung
- Unser Kunde eine fixe Budgetfreigabe braucht, bevor er starten kann
- Die Anforderungen sich voraussichtlich nicht wesentlich ändern
In vielen Fällen starten wir mit einem Festpreis-Einstiegsprojekt – zum Beispiel der Entwicklung der ersten Stufe (Ordnung) – und wechseln danach in den Retainer. Das gibt beiden Seiten Sicherheit am Anfang und Flexibilität im weiteren Verlauf.
Die Kurzfassung
| Festpreis | Retainer | |
| Scope | Vorher definiert | Entwickelt sich laufend |
| Änderungen | Über Change Requests | Fließen in die Arbeit ein |
| Kosten | Fix für den Scope | Fix pro Monat, flexibler Inhalt |
| Flexibilität | Niedrig | Hoch |
| Ergebnis | Was im Lastenheft steht | Was dein Unternehmen wirklich braucht |
| Zusammenarbeit | Auftraggeber → Auftragnehmer | Partnerschaft auf Augenhöhe |
| Geeignet für | Abgegrenzte Einzelprojekte | Systementwicklung und laufende Weiterentwicklung |
Welches Modell passt, klären wir gemeinsam. In den meisten Fällen ist der Retainer der natürlichere Weg – weil ein Operating System kein Projekt ist, sondern ein Prozess.