Warum so viele Softwareprojekte ihr ursprüngliches Budget überschreiten

Mehr als die Hälfte aller Projekte überschreitet das ursprüngliche Budget. Die Ursache liegt selten dort, wo man sie sucht. Sie liegt in der Art, wie der Preis zu Beginn festgelegt wurde: eine Liste von Funktionen, eine Schätzung pro Funktion, eine Summe.

Budgetüberschreitung in IT-Projekten: was die Zahlen sagen

Das Szenario kennen Sie vielleicht. Ein unterschriebenes Angebot, ein vereinbarter Zeitplan. Dann, zwischen dem zweiten und dem sechsten Monat, ein erster Nachtrag, mit dem niemand gerechnet hatte. Dann ein zweiter.

Das ist kein Einzelfall. 52,1 % der Projekte, über alle Projektarten hinweg, überschreiten das geschätzte Budget, laut Flyvbjerg, How Big Things Get Done, 2023 (16.000 Projekte). Bei IT-Projekten ist es noch schlimmer: Die durchschnittliche Überschreitung erreicht 80 % gegenüber dem Angebot, laut Flyvbjerg et al., JMIS 2022 (4.677 IT-Projekte). In derselben Stichprobe von 16.000 Projekten halten branchenübergreifend nur 0,5 % der Großprojekte Budget, Zeitplan und erwarteten Nutzen gleichzeitig ein.

Jedes zweite Projekt: Das ist kein Pech mehr. Es ist auch kein Projektleiter, der seine Arbeit schlecht gemacht hätte. In dieser Größenordnung liegt es an der Methode: an der Art, wie der Preis eines IT-Projekts berechnet wird.

Wie die Branche den Preis einer Software festlegt

Bei IT-Dienstleistern, Agenturen und freiberuflichen Entwicklern ist die Methode dieselbe, und sie wirkt vernünftig. Man listet die Funktionen auf. Man schätzt jede einzelne: so viele Tage für diese, so viele für jene. Man addiert, als würde man Bausteine stapeln. Und heraus kommt ein Budget, auf den Tag genau.

Das sieht nach Wissenschaft aus. Die Zahlen sind präzise, die Tabelle ist sauber, die Summe stimmt. Aber jede Zeile der Tabelle ist eine Vermutung, und eine Summe von Vermutungen ist keine Messung. Das ist Pseudowissenschaft: Man hat die Form einer Berechnung, aber nicht das, was eine Berechnung verlässlich macht.

Aufgaben addieren, um eine Dauer vorherzusagen: Diese Idee stammt aus dem Maschinenbau. Es ist der Taylorismus, das industrielle Ingenieurwesen: in Aufgaben zerlegen, alles planen, bevor überhaupt etwas gebaut wird, liefern, sobald der Plan umgesetzt ist. Ein Jahrhundert später steuert man Software noch immer wie ein Fließband. Doch Software-Engineering ist kein Maschinenbau. In der Softwareentwicklung bringt das Addieren von Aufgaben keinerlei Vorhersagbarkeit.

Die Wissenschaft sagt es seit Langem: Das Ganze ist mehr als die Summe seiner Teile. 1972 veröffentlicht der Physiker Philip Anderson (Nobelpreis für Physik 1977) „More is Different“ in Science. Seine These: Auf jeder Ebene der Komplexität entstehen neue Eigenschaften, die sich nicht vorhersagen lassen, wenn man die Teile isoliert untersucht. Softwareentwicklung ist keine Addition von Aufgaben.

P.W. Anderson, „More is Different“, Science, 177(4047), 393–396, 1972.

Aufwandsschätzung: Eine Schätzung bleibt eine Vermutung

Es gibt heute kein wissenschaftliches Werkzeug, um Entwicklungszeit verlässlich zu schätzen: Schätzungen sind nichts als sehr gewagte Vermutungen, gestützt auf eine Liste von Funktionen, deren Nutzen noch niemand kennt.

Dieser Satz sagt zwei Dinge, und sie summieren sich.

Erstens: Schätzen kann man nicht. Eine Arbeit, die man identisch wiederholt, wird vorhersagbar, und irgendwann automatisiert man sie. Software dagegen wird immer zum ersten Mal entwickelt. Sonst würde man sie installieren.

Zweitens: die Liste selbst. Das Lastenheft wird geschrieben, bevor die Software existiert. Und wenn Microsoft die Wirkung seiner Ideen per kontrolliertem Experiment misst, verbessert nur eine von drei den angestrebten Indikator. Ein Drittel hat keine Wirkung, ein Drittel verschlechtert ihn (Kohavi und Thomke, Harvard Business Review, 2017). Kalkuliert man ein Lastenheft Zeile für Zeile, kalkuliert man also auch die zwei Drittel mit, die nicht den erwarteten Nutzen bringen werden. Welche das sind, weiß noch niemand.

Manche Teams sagen, sie hätten aufgehört zu schätzen. In der Praxis zählen sie die in einem Zeitraum abgeschlossene Arbeit, bilden daraus den Durchschnitt und rechnen dieses Tempo auf den Rest hoch. Das ist ehrlicher als Raten. Aber es bleibt eine Vorhersage. Eine Vermutung über die Zukunft wurde durch eine Extrapolation der Vergangenheit ersetzt. Und wenn diese Teams dort angekommen sind, dann deshalb, weil in ihrem Umfeld weiterhin Prognosen verlangt werden.

Ein Preis auf Basis von Vermutungen

Einen Preis auf diese Vermutungen zu stützen, erzeugt die Mehrkosten, von denen sich viele Projekte nicht mehr erholen. Und nutzbar ist die Software während der Entwicklungsmonate trotzdem nicht.

Ein Preis, der auf einer Funktionsliste beruht, behandelt das Projekt als einen einzigen Block, der am Ende geliefert wird. Doch eine Software ist keine Gruppe festgeschriebener Funktionen. Sie ist eine Menge von Funktionen, die sich jeweils einzeln nutzen lassen und die man eine nach der anderen liefern kann. Der Block zwingt dazu, alles im Voraus zu planen und dann bis zum Schluss auf alles zu warten.

Wenn man Preis und Funktionsliste gleichzeitig festschreibt, fällt das gesamte Risiko auf eine der beiden Parteien. Und niemand kann sich mehr anpassen. Jede Entdeckung, die man unterwegs macht, wird zum Nachtrag. Jeder Nachtrag vergrößert den Abstand zum Angebot. Die Projektsteuerung läuft am Ende auf eine einzige Sache hinaus: eine Liste zu verteidigen, die an dem Tag geschrieben wurde, an dem man am wenigsten wusste.

Währenddessen warten Ihre Teams. Sie lernen die Software kennen, wenn das Budget bereits verbraucht ist. Und genau dann erfahren Sie, was sie wirklich brauchten. Nicht vorher.

Was kostet individuelle Software?

Die Kosten für die Entwicklung individueller Software hängen von der Zeit ab, die Sie in ihre Entwicklung und in die täglichen Anpassungen an Ihr sich wandelndes Geschäft investieren möchten, gemessen daran, was Sie das Fehlen der Software kostet.

Was Sie ihr Fehlen kostet, wissen Sie bereits. Dieselben Daten, eingegeben in mehrere Tools, die nicht miteinander kommunizieren. Die Fehler, die dadurch entstehen. Die eine Person im Unternehmen, die all das auf dem neuesten Stand hält. Die teure Software, von der Ihre Teams nur einen Teil nutzen und deren Anbieter die Anpassungen, um die Sie bitten, nicht umsetzt. Mit dieser Zahl ist die Investition zu vergleichen. Nicht mit einer Schätzung.

Das Leben einer Software beginnt in der Produktion. Sie wie ein abgeschlossenes Projekt zu behandeln und die Wartung danach auf ein Minimum zu reduzieren: Genau das macht sie zu einem Fass ohne Boden statt zu einem Vermögenswert. Sie ist übrigens drei- bis viermal teurer zu warten als zu entwickeln (Applied Software Measurement, Capers Jones). Das Enddatum des Projekts spielt also eine eher geringe Rolle. Was zählt, ist, was Sie über die gesamte Lebensdauer investieren.

Um zu erfahren, was die Entwicklung Ihrer Software mit unserem Ansatz kostet, bei dem sie innerhalb eines Monats nutzbar ist, kontaktieren Sie uns.

Monat für Monat entscheiden, wie viel Zeit Sie investieren

Bevor Sie eine Entwicklung starten, erwarten Sie vermutlich eine Dauer und einen Preis. Das ist es, was man üblicherweise nennt. Als ließe sich alles vorhersehen. Wir wissen nicht alles im Voraus. Wir sagen es lieber. Trotzdem eine Dauer zu nennen, hieße, Ihnen eine gewagte Vermutung zu geben, die unser Metier fälschlich eine Schätzung nennt. Das tun wir nicht.

Der adaptive Ansatz sagt voraus, was vorhersehbar ist: das Monatsbudget und die Entwicklungstage pro Monat. Er versucht nicht, das Unvorhersehbare vorherzusagen: was Ihre Nutzer mit einer Funktion tun werden, bevor sie sie in der Hand haben. Er stellt eine einzige Frage: Was ist jetzt das Nützlichste? Und er beantwortet sie mit dem, was man in diesem Moment weiß. Nicht mit dem, was man sich am Tag des Angebots vorgestellt hatte.

Er sucht auch nicht nach der vollständigen Lösung, bevor geliefert wird. Diese Suche hat kein Ende: „ein Problem vollständig oder perfekt lösen zu wollen, ist das Versprechen einer Dauer, die gegen unendlich strebt“ (Frédéric Leguédois, Vortrag „Éloge de la simplicité“ (auf Französisch)). Man akzeptiert eine unvollständige Lösung, gibt sie Ihren Teams so früh wie möglich in die Hand und passt sie anhand dessen an, was sie dazu sagen.

So arbeiten wir. Wir entwickeln Ihre individuelle Anwendung zu einem festen Budget, das am Ende jedes Monats für die geleistete Arbeit abgerechnet wird. Sie ist innerhalb eines Monats nutzbar. Nutzbar heißt nicht fertig: Ihre Teams arbeiten ab dem ersten Monat damit, und diese Nutzung entscheidet, was wir im folgenden Monat entwickeln. Danach passen wir sie an Ihre sich wandelnden Anforderungen an, so lange Sie es wünschen. Das Budget bleibt gleich. Was wir entwickeln, folgt dagegen dem, was Ihre Teams bei der Nutzung lernen.

Mit Ihrem Budget kaufen Sie Arbeit an diesem Problem, nicht seine Lösung. Jeden Monat sehen Sie, was dabei herauskommt, und Sie entscheiden, ob Sie weitermachen.

Und damit das, was im letzten Monat funktioniert hat, auch in diesem Monat noch funktioniert, wenden wir die Null-Regressions-Garantie an: Jede Regression wird behoben und durch einen automatisierten Test abgesichert, damit sie nicht wiederkehrt, ohne Aufpreis.

Eine Testphase von bis zu 15 Arbeitstagen im ersten Monat, und die Arbeitsergebnisse gehören Ihnen, sobald Sie bezahlen.

Es gibt keine Schätzung mehr, die sich überschreiten ließe. Es gibt ein Budget, das Sie gewählt haben, und eine Software, die Ihre Teams bereits nutzen.

Weiterlesen

Unser Leitfaden behandelt diese Quellen ausführlich. Dort finden Sie auch die Fragen, die Sie stellen sollten, bevor Sie ein Angebot für Softwareentwicklung unterschreiben.

Möchten Sie eine Software entwickeln lassen, oder haben Sie ein Tool, das mit Ihrem Geschäft nicht mehr mithält? Sprechen wir darüber?