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. Es ist Zeit für eine grundlegende Erneuerung. Die operativen Risiken steigen mit jedem Jahr des weiteren Einsatzes. Fachbereiche, IT, Unternehmensführung und Berater haben sich gemeinsam für einen bestimmten Plattformstack entschieden, der großteils Cloud- und SaaS basiert ist; einige Komponenten sollen aus regulatorischen Gründen jedoch weiterhin on-premise laufen. In mehreren kurzen Proof-of-Concepts wurden verifiziert, dass die Plattformen die funktionalen sowie technischen Anforderungen erfüllen – alleine sowie im Zusammenspiel miteinander. Jetzt geht es um die Budgetierung und die Zustimmung des Vorstandes sowie der vorgeschalteten Investitionsgremien.

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 à 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? Wie jeder IT-Leiter und CIO weiß, liegt der Teufel im Detail. Und mehrere Teufel zusammen können dann schon eine Projekthölle bilden, die sich schnell zum Ausgabengrab entwickeln kann – ein bekanntes Muster vieler gescheiterten Projekte.

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, sowie der Funktionsumfang inkrementell wächst (“Rom wurde auch nicht an einem Tag erbaut”), so vermittelt die Wasserfallmethodik dank ihres umfassenden Planungsprozesses vor der Umsetzung einen augenscheinlich hohen Grad an Sicherheit und Zuverlässigkeit. Letzteres ist gerade für die vielerorts gelebten Projektbudgetierungen wichtig. Eine Mittelfreigabe erfordert eben eine gewisse Planung.

Wie lässt sich dieser vermeintliche Widerspruch zwischen agiler Operations und wasserfallorientierten Finanzplanung lösen? Folgende Lösungsansätze kommen in Betracht:

Wer nicht plant, plant sein Scheitern (Lenin)

Alternative 1: 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 Sicherheitsaspekt wäre wohl als großer (vordergründiger) Vorteil zu sehen: Man hat alles bestmöglich bedacht, bevor auch nur eine Umsetzungsaktivität begonnen wird, und kann vor Projektbeginn bestmöglich entscheiden. Der große Nachteil dieser Lösung ist jedoch, dass erstens jegliche theoretische Spezifikation durch in der Praxis neu auftretende Erkenntnisse oder Probleme schnell ad absurdum geführt wird, während die dann großteils obsolete Planungszeit nicht mehr wettgemacht werden kann. Zweitens sind Erfahrungen aus vergangenen Projekten nur dann wertvoll, wenn es zu keiner technischen Zäsur kommt, bei der völlig neue Plattformen und Technologien zum Einsatz kommen sollen.

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

Alternative 2: Design to Aspiration (quality, time and budget) könnte eine weitere Möglichkeit sein. 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, gegen das es anzuarbeiten gilt. Das Ziel soll realistisch erscheinen, auch wenn es sportlich sein mag. Sollten Zeit oder Budget nicht ausreichen, so wird “nachbudgetiert”. Bis dahin ist jedoch ersichtlich, ob der eingeschlagenen Weg erfolgsversprechend sein wird. Vorteil ist hierbei, dass die Projektsteuerung einfach ist und man sehr schnell zu validen Resultaten kommt, ohne zeitintensive Planungsrunden durchlaufen haben zu müssen. Nachteil dieser Variante ist, dass ein “Nachschlag” an Zeit und Geld nur aufwändig durchsetzbar sein wird, gerade wenn es eine maßgebliche Größenordnung ist. Des Weiteren können Entscheider den Eindruck gewinnen, man wollte sie über eine “Salamitaktik” zu einem Projekt motivieren, dessen wahrer Größenordnung sie nicht ohne weiters zugestimmt hätten.

In the long run we are all dead (John Meynard Keynes)

Alternative 3: Value at Risk ist jedem Finanzcontroller und Financial Services Manager bekannt. Im Kern soll die Frage beantwortet werden, wie hoch die Kosten oder der Schaden oder der Umsatz usw. wäre, wenn man auf statistische Daten zurückgreifend eine mit einem hohen Prozentsatz valide Aussage treffen möchte; z.B. wie hoch wären die Projektkosten mit 95%ige Sicherheit, auch wenn man (im Mittelwert) von deutlich niedrigeren Kosten ausgeht? Diese Variante strebt ein konservatives Planen an und eignet sich gerade für vergleichbare Projekte unter bekannten technischen sowie organisatorischen Voraussetzungen, sofern das Projektcontrolling gewissenhaft die Ist-Werte seiner Projekte erfasst hat. Nachteil dieser Betrachtungsweise sind ggf. sehr hohe theoretische (!) Projektkosten, wenn man sein Sicherheitsbedürftnis sehr hoch ansetzt. Zudem handelt es sich in der Regel um Schätzungen, da valide statistische Werte fehlen oder nur mit einer hohen Ungewissheit belegt sind.

Was also tun? Keiner der Ansätze überzeugt alleine. Was liegt also näher, als einen eklektischen Ansatz zu wählen, und die nützlichsten Aspekte jeder Projektplanungsmethode zu einem pragmatischen Vorgehen zu kombinieren?

Ein Projekt verläuft regelmäßig in mehreren Phasen; seine Artefakte werden agil in Inkrementen erzeugt, deren Leistungsfähigkeit stets zunimmt. Warum soll die Budgetierung nicht auch als Vorgehen mit wachsender Genauigkeit begriffen werden? Essenziell für das Management ist in der Regel nicht, dass der exakte Aufwand a priori feststeht, sondern ob sich das Unternehmen das Projekt leisten kann und dass der gewünschte Erfolg sich einstellt. Folglich wollen wir eine iterative Budgetierungsmethode ohne Schnörkel vorstellen, die aus drei Schritten besteht.

a. Vor Projektstart – Triangulation mit Sicherheitsmarge: 

Budgetierung findet in der Regel vor Projektbeginn statt. Sind inhaltlich und aufwandsmäßig vergleichbare Projekte nicht vorhanden, was der Regelfall ist, lohnen sich mehrere praktisch orientierte Maßnahmen zur Aufwandsschätzung:

1. Proof-of-Concept: Ein kurzes, gut vorbereitetes auf überschaubare aber repräsentative Use Cases beschränktes 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. Diesen Faktor notiert man sich.
2. Referenzwerte: Systemhäuser und Plattformlieferanten verfügen über eine gute Zahl an Referenzkunden. Deren funktionaler Umfang (Scope) sowie die dafür benötigte Dauer bei gegebenen Projektmitgliedern und Entwicklern kann als zweite Anhaltsgröße dienen, sofern deren Leistungen und Produkte zum Einsatz kommen. Zudem liefern Referenzgespräche wertvolle Erkenntnisse über etwaige Schätzfehler anderer Anwender.
3. Wiederherstellungswert: Bei Ablösungsprojekten können unterschiedliche Softwaremetriken im Rahmen eines Assessments eine guten Anhaltspunkt liefern, wie lange die Neuentwicklung der bestehenden Funktionalität dauern würde, wenn derselbe Technologiestack erneut zur Anwendung käme.
4. Relativschätzung: Vergangene Software-Projekte, auch wenn sie inhaltlich anders geartet sind und andere Technologien zum Einsatz kamen, sind ein weiterer Referenzpunkt. Ihr Aufwand und ihre Dauer sind bekannt. Die Größenordnung im Vergleich mit dem Projektvorhaben kann bei gutem Willen zumindest mit “T-Shirt-Größen” (XL, L, M, S usw.) ins Verhältnis gesetzt werden. 

Diese vier Maßnahmen zusammen ergeben eine Streuung des zu erwartetenen Aufwands sowie der daraus abgeleiteten erwartbaren Projektausgaben, die eine erste Indikation sind. Folgt man in dieser Phase vor Projektgenehmigung der Value-at-Risk Methode würde man einen hohen Wert ansetzen, diesen ggf. um (zumeist) Ab- oder Zuschläge aus Einschätzungen erfahrener Entwickler und Projektmitglieder korrigieren, um ihn dann erneut mit einem Risikopuffer zu versehen. Das erhöht die Chance deutlich, den finanziell tragbaren Rahmen nicht zu sprengen. Selbstredend: Je größer das Sicherheitsbedürfnis ist, desto höher sollte der Risikopuffer ausfallen.

Mit diesem Betrag – oder wenn möglich einem Intervall – kann man die Budgetgespräche beginnen und eine Mittelfreigabe für ein Minimal Viable Product (MVP) anstreben. In diesem MVP soll ein möglichst kleiner aber mit allen operativen sowie technischen Herausforderungen versehener funktionsfähiger Prototypen erstellt werden. Nur so ist ersichtlich, ob der Technologiestack, die Vorgehensweise und die Ressourcensituation zum Erfolg führen. Aus Theorie wird Praxis. 

b. MVP – Go or No Go

Im Rahmen des MVP werden mehrere funktionalen 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. Der eigenen Schätzfehler wird dadurch quantifiziert und für die neuen Schätzungen bzw. Hochrechnungen nutzbar gemacht. Diese Methode der Erkenntnisgewinnung muss umbedingt im Vorhinein mit dem Management abgesprochen werden. Widrigenfalls läuft man Gefahr, das Vertrauen in die Projektarbeit zu verlieren, wenn die eigenen Schätzungen mit jedem Inkrement revidiert wird. Diese Flexibilität muss man ertragen können.

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 und können zudem wertvolles Feedback zur späteren praktischen Eignung des Produkts geben. Der Wurm muss dem Fisch schmecken und so zeitnah wie möglich richtig zubereitet werden.

Parallel findet die Überprüfung der nicht-funktionalen Anforderungen, also der technischen Eignung statt. Hält der Technologiestack, was er verspricht? Wie zukunftssicher ist die erstellte Lösung in Bezug auf die etablierten Kriterien eines well-architected frameworks (Performance, Skalierbarkeit, Sicherheit, Betrieb, Kosten)? Passt die Projektdurchführungsmethode und das vorhandene Skillset?

Mit diesen Evidenzen kann das Management nach MVP-Ende entscheiden, ob es die revidierten Kosten sowie Ressourceneinsatz akzeptiert. Das Budget kommt dank der Messerfahrung und der über mehrere Messpunkte (hier Inkremente) korrigierten Kostenabschätzung einer a priori Planung à la Wasserfall schon deutlich nahe, auch wenn ein Teil des Umsetzungsweges im MVP bereits zurückgelegt wurde. Man hat bereits etwas “in der Hand”, nicht nur Absichtserklärungen und Powerpoint-Charts.

c. Roll-out – Kontinuierliche Schärfung

Entscheidet sich das Management gegen das Projekt, ist selbstverständlich eine Alternative zu wählen. Selbst dann kann auf die Erfahrungen und konkreten Einschätzungen aus dem MVP zurückgegriffen werden. Wurde im MVP bereits eine produktiv einsetzbare Release erschaffen, steht dieses zur Weiterverwendung innerhalb der Alternativlösung zur Verfügung.

Geht hingegen die Entscheidung für die Projektfortsetzung aus, so steht jetzt der Roll-out bevor. In diesem wird regelmäßig anhand eines erneuten Plan-Ist-Abgleichs der Projektfortschritt inkl. Budgeteinhaltung geprüft. Es empfiehlt sich ein Monatsintervall, um den administrativen Aufwand für das Projektteam gering zu halten. Um den Verlockungen des “Nichts ist unmöglich” zu widerstehen und am Ende mit der Erkenntnis zu hadern “zu viel gewollt, ist nix gekonnt”, lohnt 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. All jene Entwicklungen, die keine technischen Schulden in der Systemarchitektur verursachen und die operativ nicht unbedingt nötig sind, sollten auf die Zeit nach dem abgeschlossenen Roll-out verschoben werden. Das ist die Zeit der kontinuierlichen Verbesserung. Intelligente Prokrastination könnte man das nennen.

Die zeit- und budgettreue Finalisierung des Projekts bringt den Vorteil mit sich, dass auch weiterhin inkrementell sowie bewusst abwägend gearbeitet wird und nicht plötzlich in völliger Selbstüberschätzung oder Überoptimismus “Rom an einem Tag erbaut werden soll”. Dieser Tag dauert sonst unendlich lange und vor der Abenddämmerung hat das Management schon den Glauben an und das Vertrauen in den Projekterfolg verloren. Die für so viele Projekte fruchtbaren Voraussetzungen für ein fulminantes und teures Scheitern wird so wirksam vermieden.

d. Kontinuierliche Verbesserung – der Evergreen-Ansatz

Wurde die erste vollständige und operativ nutzbare Release fertiggestellt und – im Falle von Modernisierungsprojekten – der Cut-Over von den Altsystemen auf das Neusystem vollzogen, so 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. Ab jetzt werden laufend neue Features entwickelt und zur Verfügung gestellt, sodass große Versionsumstellungen gar nicht mehr oder nur sehr selten stattfinden – Microsoft 365 macht das anschaulich vor.

In dieser Phase sind die enge Zusammenarbeit zwischen Fachbereichen, Management und IT bereits in Fleisch und Blut übergegangen. Unternehmenszweck, Leistungsangebot und technische Umsetzung gehen Hand-in-Hand. IT spricht in funktionalen Fragestellungen mit, Fachbereich in technischen Punkten. Aus inhaltlich konstruktiven Diskussionen ohne verklärende Begrifflichkeiten entsteht kontinuierlich Neues und Mehrwert für die Kunden – die Voraussetzung für unternehmerischen Erfolg.

Finanziell bedeutet dies, dass ein jährliches Budget für die Weiterentwicklung der Systeme festgelegt wird. Weiterentwicklungen und neue Releases werden als “Abo” aufgefasst, wie das von Software-as-a-Service bekannt ist: Die IT entwickelt sich weg von einer CAPEX-orientierten Betrachtung hin zu einer OPEX-orientierten Welt. “Regelmäßigkeit” soll direkten Einzug in die GuV erhalten ohne den Umweg über die Abschreibung. Die Ausgaben sollen über die Nutzungsdauer gestreckt werden und nicht nach längerer Zeit in voller Höhe anfallen. Anbieter und Kunde können finanziell besser planen.

Planung und Flexibilität sollen bei IT-Projekten heute Hand-in-Hand gehen. Operative Agilität muss nicht notwendigerweise finanzielle Unplanbarkeit bedeuten. Ein eklektischer Ansatz hilft, das Kostenrisiko frühzeitig transparent zu machen und bewusst über das Leistbare entscheiden zu können. Dennoch darf man zwei wichtige Grundsätze nicht übersehen: Kompetente, verantwortungsbewusste und mutige Projektmitarbeiter sind die wichtigste Voraussetzung erfolgreicher IT-Projekte. Die zweite wichtige Voraussetzung ist eine stringente und dogmenfreie Führung dieser Mannschaft – mal im Detail und hands-on, mal mit Weitsicht und Abstand, mal motivierend, mal kritisch, aber immer geistig unabhängig und im vollen Bewusstsein, dass Irren und Korrigieren zum Erfolg gehört.

Business Automatica senkt Prozesskosten durch Automatisierung manueller Tätigkeiten, hebt die Qualität beim Datenaustausch in komplexen Systemarchitekturen und verbindet On-premise Systeme mit modernen Cloud- und SaaS-Architekturen.