Warum wir TYPO3-Upgrades zum Festpreis anbieten können

Ein Festpreis für ein größeres TYPO3-Upgrade klingt zunächst widersprüchlich. Schließlich besteht der Reiz eines Time-&-Material-Projekts genau darin, dass sich unbekannte Risiken flexibel behandeln lassen. Warum entscheiden wir uns trotzdem in vielen Projekten bewusst für einen Festpreis? Die Antwort hat überraschend wenig mit Kalkulation und erstaunlich viel mit Engineering zu tun.

Es gibt kaum ein Thema, das in ersten Gesprächen mit Agenturen häufiger angesprochen wird als die Projektkalkulation.

Fast jeder hat bereits Projekte erlebt, die ursprünglich überschaubar wirkten und sich während der Umsetzung deutlich komplexer entwickelten als erwartet. Alte Extensions verhalten sich anders als dokumentiert, individuelle Anpassungen greifen tief in den TYPO3-Core ein oder während des Upgrades stellt sich heraus, dass ein entscheidender Geschäftsprozess ausschließlich in einer kaum dokumentierten Erweiterung implementiert wurde.

Je mehr solche Erfahrungen man gesammelt hat, desto nachvollziehbarer erscheint die Schlussfolgerung:

„Ein größeres TYPO3-Upgrade kann man eigentlich nicht seriös zum Festpreis anbieten."

Wir können diese Sichtweise gut verstehen. Tatsächlich hätten wir vor einigen Jahren vermutlich ähnlich argumentiert. Heute sehen wir den Zusammenhang etwas differenzierter.

Nicht weil Upgrade-Projekte einfacher geworden wären, sondern weil wir heute besser verstehen, wodurch Unsicherheit in solchen Projekten überhaupt entsteht.

 

Der größte Risikofaktor ist selten TYPO3 selbst

Wenn ein Projektbudget aus dem Ruder läuft, wird häufig angenommen, dass das Upgrade schwieriger war als erwartet. Unsere Erfahrung ist eine andere.

Die meisten Überraschungen existierten bereits vor Projektbeginn. Sie wurden lediglich erst während der Entwicklung sichtbar. Das ist ein entscheidender Unterschied.

Eine nicht mehr gepflegte Extension wird nicht plötzlich problematisch, weil das Upgrade begonnen hat. Eine historische Architektur entsteht nicht erst während der Migration. Und auch eine fünfzehn Jahre alte PI-based Extension wird nicht über Nacht kompliziert.

All diese Dinge waren bereits vorhanden. Der Unterschied besteht lediglich darin, wann sie erkannt werden.

Deshalb betrachten wir die Analysephase nicht als organisatorische Vorbereitung. Sie ist bereits ein wesentlicher Bestandteil des eigentlichen Engineering-Prozesses.

 

Gute Schätzungen entstehen nicht durch Erfahrung allein

Natürlich hilft Erfahrung. Nach mehr als 150 TYPO3-Upgrades erkennen wir viele technische Muster deutlich schneller als noch vor einigen Jahren. Wir wissen, welche Extension-Kombinationen regelmäßig Probleme verursachen, wir kennen typische Architekturen älterer Enterprise-Projekte, und wir haben ein gutes Gefühl dafür entwickelt, welche Bereiche eines Systems besondere Aufmerksamkeit verdienen.

Trotzdem wäre es aus unserer Sicht gefährlich, gute Schätzungen ausschließlich auf Erfahrung aufzubauen. Erfahrung ist wertvoll, sie bleibt jedoch subjektiv.

Deshalb versuchen wir, möglichst viele Erkenntnisse in einen reproduzierbaren Analyseprozess zu überführen:

  • Welche Extensions sind im Einsatz?
  • Welche davon werden aktiv gepflegt?
  • Wie groß ist der individuelle Code?
  • Welche Integrationen existieren?
  • Wie wurde die Plattform in den vergangenen Jahren weiterentwickelt?
  • Welche Bereiche besitzen erfahrungsgemäß das größte technische Risiko?

Je mehr dieser Fragen sich bereits vor Projektbeginn beantworten lassen, desto kleiner wird der Anteil der eigentlichen Unsicherheit.

 

Unser Ziel ist nicht, jedes Risiko auszuschließen

Manchmal entsteht der Eindruck, ein Festpreis bedeute automatisch, dass ein Projekt vollständig vorhersehbar sei. Das wäre weder realistisch noch ehrlich.

Auch nach einer sorgfältigen Analyse bleiben Fragen offen. Vielleicht existiert eine individuelle Erweiterung, deren tatsächlicher Funktionsumfang erst während der Migration vollständig sichtbar wird. Vielleicht stellt sich heraus, dass eine Third-Party-Extension in ihrer aktuellen Version wichtige Funktionen nicht mehr besitzt. Oder ein bisher unbekannter Sonderfall taucht während der Qualitätssicherung auf.

Solche Situationen lassen sich nicht vollständig vermeiden. Unser Ziel besteht deshalb nicht darin, Unsicherheit zu eliminieren. Unser Ziel besteht darin, sie so weit wie möglich sichtbar zu machen.

Je kleiner der unbekannte Bereich wird, desto belastbarer wird jede Kalkulation.

 

Warum Prozesse wirtschaftlicher sind als Heldentaten

Gerade bei komplexen Projekten entsteht leicht die Vorstellung, dass erfolgreiche Entwickler vor allem außergewöhnlich gut Probleme lösen. Das stimmt. Mindestens genauso wichtig ist jedoch die Fähigkeit, dafür zu sorgen, dass dieselben Probleme nicht in jedem Projekt erneut gelöst werden müssen.

Hier beginnt für uns Engineering:

  • unsere interne Upgrade-Checkliste,
  • der Legacy Updater,
  • eigene Rector-Regeln,
  • automatisierte Regressionstests,
  • Deployment-Skripte,
  • unsere Wissensdatenbank.

Keine dieser Investitionen wurde für ein einzelnes Projekt entwickelt. Sie entstanden, weil wir dieselben Muster immer wieder beobachtet haben.

Jedes neue Werkzeug reduziert einen kleinen Teil der Unsicherheit. Für sich genommen wirkt dieser Effekt oft unspektakulär. Über viele Projekte hinweg verändert er jedoch die gesamte Kalkulationsgrundlage.

 

Warum Qualität und Wirtschaftlichkeit zusammenhängen

Eine interessante Beobachtung hat uns in den vergangenen Jahren besonders beschäftigt: Viele Unternehmen betrachten Qualität als zusätzlichen Aufwand.

  • mehr Tests,
  • mehr Dokumentation,
  • mehr Reviews,
  • mehr Prozesse.

Kurzfristig stimmt das. Langfristig verändert sich jedoch die Wirtschaftlichkeit des gesamten Projekts.

Wenn visuelle Regressionstests bereits während der Entwicklung Unterschiede automatisch erkennen, reduziert sich später der manuelle Testaufwand erheblich. Wenn ein reproduzierbarer Deployment-Prozess existiert, entstehen beim Go-live deutlich weniger Überraschungen. Wenn häufige Migrationen automatisiert werden, sinkt nicht nur der Entwicklungsaufwand, sondern auch die Fehlerwahrscheinlichkeit.

Mit anderen Worten: Gutes Engineering spart nicht nur Entwicklungszeit, es reduziert gleichzeitig die Kosten für Qualitätssicherung. Gerade dieser Zusammenhang wird aus unserer Sicht häufig unterschätzt.

 

Es gibt Projekte, die wir bewusst nicht zum Festpreis anbieten

Vielleicht überrascht dieser Abschnitt. Trotz allem bieten wir nicht jedes Upgrade zum Festpreis an. Es gibt Situationen, in denen wir ganz bewusst davon abraten:

  • wenn wesentliche Teile der Plattform fehlen,
  • wenn die Installation nicht lauffähig ist,
  • wenn Quellcode oder Datenbank unvollständig sind,
  • oder wenn der eigentliche Projektumfang noch gar nicht definiert wurde.

In solchen Fällen wäre ein Festpreis keine Stärke. Er wäre Spekulation.

Wir glauben nicht, dass ein gutes Angebot dadurch entsteht, möglichst viel Risiko zu übernehmen. Ein gutes Angebot entsteht, wenn beide Seiten verstehen, welche Risiken tatsächlich existieren und welche bereits sauber bewertet wurden.

 

Warum das für Agenturen besonders interessant ist

Viele unserer Projekte entstehen in Zusammenarbeit mit Agenturen. Gerade dort beobachten wir häufig denselben Zielkonflikt.

Auf der einen Seite wünschen sich Endkunden Planungssicherheit. Budgets müssen frühzeitig freigegeben werden. Auf der anderen Seite möchte die Agentur kein wirtschaftliches Risiko eingehen, das sie nicht einschätzen kann.

Ein reproduzierbarer Engineering-Prozess hilft beiden Seiten. Er ersetzt keine Erfahrung, er reduziert jedoch die Zahl der unbekannten Faktoren, die eine seriöse Kalkulation erschweren.

Genau deshalb betrachten wir einen Festpreis nicht als Vertriebsinstrument. Er ist für uns vielmehr das Ergebnis eines Engineering-Prozesses, der Unsicherheit systematisch reduziert.

 

Was wir daraus gelernt haben

Wenn wir heute auf unsere ersten größeren Upgrade-Projekte zurückblicken, fällt uns auf, wie sehr sich unser Verständnis von Projektplanung verändert hat. Früher glaubten wir, eine gute Schätzung entstehe vor allem durch Erfahrung.

Heute würden wir sagen: Eine gute Schätzung entsteht dadurch, dass möglichst wenig geschätzt werden muss. Je mehr Wissen bereits vor Projektbeginn vorhanden ist, desto belastbarer wird jede Kalkulation.

Vielleicht beschreibt genau dieser Gedanke den eigentlichen Zusammenhang zwischen Engineering und Wirtschaftlichkeit. Engineering macht Projekte nicht einfacher. Engineering macht Projekte berechenbarer.

Und genau deshalb können wir heute bei vielen TYPO3-Upgrades einen Festpreis anbieten – nicht weil wir Risiken ignorieren, sondern weil wir gelernt haben, sie deutlich früher sichtbar zu machen.

← Vorheriger ArtikelWenn sich Third-Party-Extensions verändernNächster ArtikelWarum wir ins TYPO3-Ökosystem investieren

Wie groß ist euer TYPO3-Upgrade?

Schätzt Aufwand und Kosten eures Upgrades in wenigen Minuten — mit unserem TYPO3-Upgrade-Rechner.

Zum Upgrade-Rechner