Der Golden Circle für IT-Budgets

Zunächst haben wir uns an das Warum? gemacht - warum brauchen wir in IT-Projekten überhaupt Budgets und Budget-Planungen. Vielleicht ein triviale Frage, aber es lohnt sich, die verschiedenen Aspekte zu beleuchten:

• Plan vs. Realität: Budgets helfen, um sich über die Zeit den Plan abzugleichen, den man sich einmal gegeben hat. Und es ist die Möglichkeit, daraus für die Zukunft zu lernen.

• Budget Ja / Nein: Die Frage, ob ein Budget erstellt werden sollte, und in welchem Umfang, hängt insbesondere auch von der Komplexität des Projekts ab.

• Priorisierung: Ein Budget zwingt dazu, die verschiedenen Kostenbereiche zu priorisieren. Es hilft dabei, festzulegen, welche Ausgaben als notwendig erachtet werden und welche möglicherweise gekürzt oder verschoben werden können.

• Akzeptanz und Transparenz: Das erstellen eines Budgets ist Arbeit mit Stakeholdern (immer vor dem Hintergrund der Frage, wer darf mitentscheiden, wen muss ich «nur» informieren). Je früher und regelmäßiger Stakeholder eingebunden werden, werden sie ein Budget annehmen und vor allem verstehen. Das ist besonders wichtig in der Arbeit am Budget innerhalb eines Projekts (Forecast und Controlling).

• Gemeinnützigkeit: Nicht zuletzt ist in unserer Branche das Einhalten mancher Reporting-Standards enorm wichtig; nicht zuletzt um die eigene Gemeinnützigkeit abzusichern.

Als nächsten Schritt haben wir das Wie? erörtert - das heißt die verschiedenen Methodiken und Herangehensweisen, die man für einen Budget-Prozess anlegen kann:

• Zieldefinition und KPIs erstellen: Auch für Budgets können wir Zielmarken setzen. Dabei hilft die einfache Frage «Woran messen wir Erfolg?»; sie hilft uns, zu erkennen, welche harten Fakten wir für ein erfolgreiches Budget (und damit Projekt) setzen wollen. Auch, wenn wir sie mit dem aktuellen Projekt nicht erreichen, sind die Erfahrungen daraus Gold wert (bzw. Geld).

• Art der Erstellung 1: Budgets können - wie so vieles in einer Organisation - fix oder dynamisch erstellt werden. Das bedeutet, sie können für ein Projekt insgesamt oder nach jeweiligen Projektschritten neu erstellt und verfeinert werden. In der Softwareentwicklung würde man auch von «Waterfall vs. Agile» sprechen. Und tatsächlich macht es Sinn, für die Budgets solcher Projekte ähnlich vorzugehen. Dabei heißt agil bzw. dynamisch nicht, dass man sich nicht einen Gesamt-Budget-Rahmen setzt. Man anerkennt aber, dass Projekte mit jeder Anpassung teurer werden und dass sowohl Projekte, als auch Budgets zunächst auf die prioritären Themen fokussieren sollten («First things first»)

• Art der Erstellung 2: Budgets können top down (eine Gesamtsumme vorgeben und verteilen) vs. bottom up (Einzelbudgets erstellen, bspw. für Phasen) erstellt werden. Welcher Weg der richtige ist, hängt insbesondere von der Team-Kultur, als auch von den zeitlichen Ressourcen ab (Bsp. «bottom up»: Dauert länger in der Erstellung; hat aber den Vorteil, dass Stakeholder an Board sind und das «buy-in» für das Projekt höher ist).

• Ressourcen definieren: Es lohnt sich zu fragen, was budgetiert werden muss. Gerade bei großen Software-Implementierungs-Projekten ist das nicht nur Geld, sondern auch Zeit (interne wie externe)

• TCO - Total Cost of Ownership: Die TCO-Methodik versucht, die Gesamtkosten einer Implementierung, Betrieb und Wartung einer Softwarelösung über den gesamten Lebenszyklus zu berücksichtigen. Achtung: TCOs sollten als Richtwert und nicht als für in alle Zeit gültige Zahl gesehen werden. Je weiter wir in die Zukunft schauen, desto weniger planbar werden Kosten (und das kann auch bedeuten, dass Dinge, die heute teuer sind, in Zukunft günstiger werden).

Als letzten Schritt haben wir uns die Handlungsmöglichkeiten für die Erstellung von IT-Budgets angeschaut: Was? können wir unternehmen, um ein belastbares und für uns passendes Budget zu erstellen (das ist keine abschliessende Liste - ich bin sehr interessiert an weiteren Inputs)?

• Wir können uns bewusst machen, welche Kostenteile (und Folgekosten) innerhalb eines Projekts und danach entstehen, z. B.:

  • Software-Lizenzen (Kauf, Miete, Volumen)
  • Lizenzen «3rd party»-Anbieter (Kauf, Miete, Volumen)
  • Infrastruktur und ggf. Infrastruktur Anpassungen (bspw. Server bzw. Cloud)
  • Projekt Implementierung (Phase 1 - Phase x)
  • Testing
  • Dokumentation
  • Support-Kosten (nach Abschluss)
  • ggf. auch vorausschauende Erweiterungen (Phase y)

Tipp: Wir sollten uns bei Budgets nicht nur auf Kosten fokussieren. Optimalerweise sparen wir durch neue Software und/oder nehmen mehr ein. Es lohnt sich, auch das zu «budgetieren» (das kann hilfreich sein, um eine Zieldefinition zu formulieren oder zu untermauern). Beispiele: Einsparungen manuelle Prozesse (in Min pro Jahr); erwartete zusätzliche Einnahmen Spenden (in EUR / Jahr) etc.

• Know-how-Transfer und zeitliche Ressourcen budgetieren (intern): Wenn wir das Team schulen, dann kostet das Zeit. Zudem braucht es immer eine Eingewöhnungsphase mit neuen Tools (das ist in einer Werkstatt genauso wie mit Software).

• Accountability klar machen: Wir sollten klar machen, wer für das Budget verantwortlich ist (Erstellen, Pflege, Abschluss) bzw. für jeweilige Teil-Budgets. Es lohnt sich, hierfür auch regelmäßige Meetings einzuberufen, um während eines Projekts den Stand des Budgets klar zu machen (Tipp: IT-Dienstleister machen das normalerweise von sich aus. Es ist ein Zeichen von Vertrauen, das eigene Gesamtbudget offenzulegen und gemeinsam gegen euer internes zu reporten). Eine Möglichkeit hierbei sind sogenannte Steering Commitees, die ihr mit euren Partnern (d. h. Dienstleistern) aufsetzt.

• Es sollte immer nur eine - das heißt: e-i-n-e ! - Version eines Budgets geben. Dafür ist es auch von höchster Bedeutung, dass klar ist, wer für das Budget und den Budget-Prozess verantwortlich ist (Achtung: Das bedeutet nicht, dass diese Person auch für das Einhalten des Budgets verantwortlich ist. Es bietet sich sogar an, diese Funktionen nicht auf einer Person zu vereinen).

• Stakeholder sollten frühzeitig in das Erstellen des Budgets eingebunden werden. Das bedeutet nicht, dass sie auch bei allem mitentscheiden dürfen. Überlegt euch aber, wen ihr als Entscheider*innen braucht, wer in Tiefe und wer ggf. nur High-Level informiert werden sollte. Diese Einbindung hilft, das «buy-in» der Stakeholder zu bekommen (siehe auch oben «Wie? - Art der Erstellung 2»)

• Phasen abgrenzen: Wenn ihr es euch erlaubt, das Projekt agil zu gestalten, grenzt Phasen (und damit Budgets) mit wichtigsten Milestones voneinander ab. Definiert dabei auch Minimal-Ziele, die ihr erreichen wollt, um in die nächste Phase zu gehen. In der Software-Entwicklung spricht man auch von Akzeptanzkriterien.

• Versucht euren ROI des Projekts zu berechnen: Dabei ist es hilfreich, wenn ihr euch von Beginn des Projekts auch Gedanken über ein «Positives-Budget» macht. Das heißt, über ein Budget, dass eure Kosteneinsparungen, zusätzlichen Erträge etc. zunächst plant und dann (in der Arbeit mit eurer Software) trackt. So lernt ihr, auch für zukünftige Projekte, besser zu budgetieren. Das ist insbesondere in der Arbeit mit Phasen und in agilen Projekten leichter umgesetzt, da schneller reagiert werden kann.

• Forecasting: Ein Budget ist ab dem Zeitpunkt, zu dem es finalisiert wird, schon veraltet. Das ist leider die Realität - denn ebendiese verändert die Bedingungen, zu denen ihr ein Projekt umsetzt. Aber es gibt eine einfache Lösung: Forecasting, das regelmäßige gegenüberstellen eures Budgets zur Realität. Gerade mit neuen Partnern und zu Beginn eines Projekts lohnt es sich, dies eher häufiger zu machen, um den richtigen Forecast-Modus zu finden; der Forecast sollte dann auch essentieller Bestandteil eures Steering Committees sein.

Die oben aufgeführten Aspekte sind sicherlich nur ein Teil der «Kunst des Budgetierens», aber sie zeigen, warum Budgets nicht nur graue Excels, sondern ein essentieller Kern erfolgreicher Projekte sind. Wenn ihr Inputs habt, freue ich mich, wenn ihr diese mit mir teilt, sodass ich den «Golden Circle des Budgetierens» weiter verfeinern kann.

Eine abschliessende Bemerkung erlaube ich mir aus Sicht eines Dienstleisters: Standards können helfen, Budgets im Rahmen zu halten. Standard-Produkte sind Software-Pakete, die für viele Use Cases von Kund*innen entwickelt und ausgeliefert wurden. Sie ermöglichen es Software-Entwicklern, günstiger zu entwickeln (Skaleneffekt) und die Software aktuell zu halten (Maintainability, Updates). Je individueller eine Software angepasst wird, desto a) teurer und zeitintensiver wird das Projekt (Anpassung = Zeitressourcen) und b) schlechter pflegbar wird die Lösung (keine Dokumentation, fehlender Know-How-Transfer).

Es lohnt sich daher, zunächst zu prüfen, wie weit man mit Standards kommt, als von vornherein die custom-Lösung zu verlangen - oder eben zu akzeptieren, dass custom = höhere Kosten bedeutet.