Show me the money

Jeder CFO möchte drei Dinge zu einem IT-Projekt wissen: Was bringt es? Wie viel kostet es? Wie hoch sind die Risiken? Verfolgt der Projektsponsor oder Projektleiter eine agile Vorgehensweise, lässt sich der zweite Punkt häufig sehr schwer a priori beantworten. Auch zu den Risiken weiß man nicht alles, während der Nutzen meist in den schillerndsten Farben dargestellt werden kann. Zahlenmenschen befriedigt das nicht. Nein, sie werden vielmehr skeptisch und halten ihre Zustimmung möglichst lange zurück, auch wenn der Schrei nach Innovation, Automatisierung sowie Optimierung groß ist und der Wettbewerb einem das Leben schwer macht. Das muss jedoch nicht so sein.

Lassen Sie uns ein Beispiel aus der genuin risikoaversen Versicherungswirtschaft betrachten, welches sich so oder so ähnlich in jeder Branche abgespielt haben könnte.

Ein Antrags- und Policierungssystem eines mittelgroßen Mehrspartenversicherers soll modernisiert werden. Über 40 Jahre gewachsene und verdiente Prachtstücke der Kernanwendungs-IT sollen würdig ins Software-Museum verabschiedet werden. Zu schwerfällig sind sie in der heutigen VUCA-Welt, zu wenig Menschen beherrschen ihre in die Jahre gekommenen Sprachen, Entwicklungsmuster und Architekturen.

I. Das Problem

War für alle Beteiligten sofort klar, dass eine auf die organisatorischen Bedürfnisse der Versicherung zugeschnittene agile Vorgehensweise nach SCRUM die Methodik der Wahl sein soll, so war auch die Sinnhaftigkeit einer finanziell umsichtigen Planung a la Wasserfall nicht bestreitbar. Versicherungen tragen ja Risikoaversion in ihrer DNA - und in ihren Regularien.

Alleine die Paradigmen scheinen nicht zu passen. Wie soll ein Budget benannt sowie Risiken samt Mitigationsmaßnahmen identifiziert werden, wenn vor Projektbeginn die funktionalen Anforderungen im vollen Umfang noch nicht feststehen?

Im Kern erscheinen diese beiden Herangehensweisen, Agile und Wasserfall, nicht miteinander vereinbar. Entfaltet die agile Entwicklung ihre Stärken dadurch, dass die Anforderungen gleichsam parallel zu ihrer Spezifikation umgesetzt und damit in der Praxis verprobt werden, so vermittelt die Wasserfallmethodik dank ihres umfassenden Planungsprozesses vor der Umsetzung einen augenscheinlich hohen Grad an Sicherheit und Zuverlässigkeit.

II. Die Lösungsansätze

Wie lässt sich dieser vermeintliche Widerspruch zwischen agiler Operations und wasserfallorientierten Finanzplanung lösen?

Wer nicht plant, plant sein Scheitern - Lenin

Alternative 1: Umfassende Spezifikation vor Projektstart

Naheliegend wäre, möglichst viele funktionale Aspekte der technischen Umsetzung vor Projektstart zu spezifizieren und dafür Aufwands- sowie Risikoabschätzungen anhand vergleichbarer Erfahrungen zu machen. Der große Nachteil dieser Lösung ist jedoch, dass jegliche theoretische Spezifikation durch in der Praxis neu auftretende Erkenntnisse oder Probleme schnell ad absurdum geführt wird.

Jede Sache sollte nur so viel Aufmerksamkeit erhalten, wie es inhaltlich angemessen ist - Aristoteles

Alternative 2: Design to Aspiration

Anhand aller zur Verfügung stehenden Fakten, Einschätzungen und Referenzen wird ein anspruchsvolles Ziel top-down in Bezug auf Zeit, Finanzen sowie Funktionsumfang vorgegeben. Nachteil dieser Variante ist, dass ein "Nachschlag" an Zeit und Geld nur aufwändig durchsetzbar sein wird.

In the long run we are all dead - John Meynard Keynes

Alternative 3: Value at Risk

Im Kern soll die Frage beantwortet werden, wie hoch die Kosten wären, wenn man auf statistische Daten zurückgreifend eine mit einem hohen Prozentsatz valide Aussage treffen möchte. Diese Methode eignet sich für vergleichbare Projekte unter bekannten technischen sowie organisatorischen Voraussetzungen.

III. Die Synthese

Ein Projekt verläuft regelmäßig in mehreren Phasen; seine Artefakte werden agil in Inkrementen erzeugt. Warum soll die Budgetierung nicht auch als Vorgehen mit wachsender Genauigkeit begriffen werden?

a. Vor Projektstart - Triangulation mit Sicherheitsmarge

Sind inhaltlich und aufwandsmäßig vergleichbare Projekte nicht vorhanden, lohnen sich mehrere praktisch orientierte Maßnahmen zur Aufwandsschätzung:

Proof-of-Concept: Ein kurzes, gut vorbereitetes PoC zeigt am besten, wie schnell der Projektfortschritt sein kann. So zeigt sich beispielsweise, dass ein Low-Code Projekt um den Faktor 3 bis 5 schneller ist als eine klassische Softwareentwicklung.
Referenzwerte: Systemhäuser und Plattformlieferanten verfügen über eine gute Zahl an Referenzkunden. Deren funktionaler Umfang sowie die dafür benötigte Dauer kann als Anhaltsgröße dienen.
Wiederherstellungswert: Bei Ablösungsprojekten können unterschiedliche Softwaremetriken im Rahmen eines Assessments einen guten Anhaltspunkt liefern.
Relativschätzung: Vergangene Software-Projekte sind ein weiterer Referenzpunkt. Ihr Aufwand und ihre Dauer sind bekannt.

b. MVP - Go or No Go

Im Rahmen des MVP werden mehrere funktionale Inkremente und innerhalb derer zahlreiche Sprints durchlaufen. Sie bieten dem Management eine exzellente Möglichkeit, Plan-Werte mit Ist-Werten zu vergleichen und so die eigene Aufwands- und Budgetschätzung zu verbessern.

Zeitgleich sollten die operativen Fortschritte einem möglichst großen Publikum live demonstriert werden: Tue Gutes und rede darüber! So sehen Entscheidungsträger sowie Anwender mit eigenen Augen, wie sich der Erfolg einstellt.

c. Roll-out - Kontinuierliche Schärfung

Geht die Entscheidung für die Projektfortsetzung aus, so steht jetzt der Roll-out bevor. Es empfiehlt sich ein kluger "Design-to-Time-and-Budget" Ansatz während des Roll-out: Es werden jene Features in diesem Ausmaß realisiert, wie sie sich innerhalb des Zeit- und Budgetplans einhalten lassen.

d. Kontinuierliche Verbesserung - der Evergreen-Ansatz

Wurde die erste vollständige und operativ nutzbare Release fertiggestellt, gilt ein weiteres Bonmot: Der König ist tot, es lebe die Königin! Das ehemalige Projekt ist im kontinuierlichen Verbesserungsprozess angekommen, so wie heute alle moderne Software einem Evergreen-Ansatz unterworfen ist.

Finanziell bedeutet dies, dass ein jährliches Budget für die Weiterentwicklung der Systeme festgelegt wird. Die IT entwickelt sich weg von einer CAPEX-orientierten Betrachtung hin zu einer OPEX-orientierten Welt.