Zum Inhalt springen
Digitale Kumpel
Zurück zum Blog

Aufwand zu groß, Nutzen unbekannt: Warum gute Ideen nie gebaut werden

Manuel·

In einem Architektur-Board bei einem Kunden lagen kürzlich mehrere Ideen auf dem Tisch. Keine Luftschlösser, sondern Themen, über die dort seit Monaten gesprochen wird. Am Ende wurden fast alle verworfen, und die Begründung war jedes Mal dieselbe:

„Aufwand zu groß, Nutzen unbekannt.“

Diesen Satz höre ich oft. Unter den Bedingungen klassischer Softwareentwicklung ist er sogar die richtige Antwort. Genau darin liegt das Problem.

Warum „Nein“ bisher vernünftig war

Wer wissen will, ob eine Idee etwas bringt, muss sie bauen. Klassisch heißt das: Anforderungen sammeln, Konzept schreiben, Angebot einholen, Budget freigeben. Das erste Ergebnis, das ein Mitarbeiter wirklich benutzen kann, gibt es oft erst nach Monaten. Die Frage „Lohnt sich das?“ kostet damit fast so viel wie die Antwort.

Dazu kommt das Risiko. Bent Flyvbjerg und Alexander Budzier haben 1.471 IT-Projekte ausgewertet. Im Schnitt lagen die Kosten 27 % über Plan. Gefährlich ist aber nicht der Durchschnitt, sondern der Ausreißer: Jedes sechste Projekt überschritt das Budget um durchschnittlich 200 % und den Zeitplan um fast 70 %.

Wer das weiß, sagt bei unklarem Nutzen „Nein“. Das ist keine Mutlosigkeit, sondern Risikomanagement.

Nutzen lässt sich nicht vorhersagen, auch nicht von Profis

Naheliegend wäre, den Nutzen vorher gründlicher abzuschätzen: mehr Analyse, ein Business Case, noch ein Workshop. Das hilft weniger, als man denkt.

Ronny Kohavi hat bei Microsoft die Plattform aufgebaut, auf der Ideen in kontrollierten Experimenten getestet werden. Sein Befund ist ernüchternd: Nur etwa ein Drittel der getesteten Ideen verbesserte die Kennzahl, für die sie gedacht war. Der Rest brachte nichts oder machte es sogar schlechter. Dabei stammten die Ideen von erfahrenen Teams, die vorher überzeugt waren, dass sie funktionieren.

Wenn selbst dort zwei von drei Prognosen danebenliegen, ist „Nutzen unbekannt“ kein Mangel an Analyse. Es ist der Normalzustand. Den Nutzen erfährt man, indem man es ausprobiert.

Was verworfene Ideen kosten

Eine verworfene Idee taucht in keinem Budget auf. Ihre Kosten sind trotzdem da: die Excel-Liste, die weiter von Hand gepflegt wird, die Abstimmung per Mail, die jede Woche Stunden frisst, der Prozess, den niemand anfasst, weil „das System das nicht kann“.

Im Mittelstand ist das kein Einzelfall. Laut KfW-Digitalisierungsbericht hat im Zeitraum 2022 bis 2024 nur noch knapp ein Drittel (30 %) der mittelständischen Unternehmen ein Digitalisierungsvorhaben abgeschlossen. Das sind 5 Prozentpunkte weniger als in der Erhebung davor. Als Hemmnisse nennt der Bericht unter anderem fehlendes IT-Know-how, Schwierigkeiten bei der Umstellung vorhandener Systeme, Unsicherheit über die technische Entwicklung und die Finanzierung.

Wenn jede Idee gleich ein Projekt sein muss, werden eben wenige Ideen umgesetzt.

Was sich geändert hat: Ausprobieren ist billig geworden

Mit KI-gestützter Entwicklung, bei uns Agentic Development, ist ein funktionierender Prototyp kein Quartalsprojekt mehr. Was früher Wochen brauchte, steht oft in wenigen Tagen: mit echter Oberfläche, echten Daten und echten Nutzern, die es ausprobieren.

Ein ehrlicher Blick auf die Studienlage gehört dazu, denn KI macht nicht alles schneller:

  • In einem kontrollierten Experiment von GitHub und Microsoft lösten Entwickler eine neue, überschaubare Aufgabe mit KI-Unterstützung 55,8 % schneller als ohne.
  • Die Forschungsorganisation METR fand 2025 das Gegenteil: Erfahrene Entwickler brauchten in großen, über Jahre gewachsenen Codebasen mit KI 19 % länger, obwohl sie sich selbst als schneller einschätzten. Eine Folgeuntersuchung mit neueren Werkzeugen lieferte Anfang 2026 so unsichere Ergebnisse, dass METR das Studiendesign umgestellt hat.
  • Der DORA-Report 2025 von Google beschreibt KI vor allem als Verstärker: Sie vergrößert die Stärken und die Schwächen, die eine Organisation ohnehin hat.

Für unser Thema ist das eine gute Nachricht. Der größte Hebel liegt genau dort, wo Experimente stattfinden: bei neuen, kleinen, klar abgegrenzten Aufgaben, die neben dem Bestandssystem laufen statt mitten darin. Ein Prototyp ist genau so eine Aufgabe.

Ein Beispiel aus unserer Arbeit: Bei einem Online-Shop kam die Frage auf, ob eine andere Hintergrundfarbe besser zur Marke passt. Früher hätte das Entwürfe, Abstimmungsrunden und mehrere Tage gekostet. Stattdessen stand nach Minuten eine Vergleichsseite im echten Shop, auf der sich sieben Farben mit echten Produkten umschalten ließen. Entschieden wurde am Ergebnis, nicht am Bauchgefühl.

Vom Projekt zum Experiment

Der Unterschied liegt weniger in der Technik als in der Frage, die man stellt. Statt „Was kostet die Umsetzung?“ lautet sie: „Was ist das kleinste Experiment, das uns den Nutzen zeigt?“

MerkmalKlassisches ProjektExperiment
StartpunktLastenhefteine Frage und eine Kennzahl
Erstes Ergebnisnach Monatennach Tagen bis wenigen Wochen
Wenn die Idee nicht trägtProjekt gescheitertErkenntnis gewonnen
EntscheidungsgrundlageSchätzungMessung

So gehen wir dabei vor:

1. Hypothese statt Lastenheft. Welche Kennzahl soll sich bewegen? Weniger Rückfragen, kürzere Durchlaufzeit, weniger doppelte Pflege?

2. Feste Zeitbox. Das Experiment bekommt einen festen zeitlichen Rahmen. Was nicht hineinpasst, gehört nicht ins Experiment.

3. Neben dem Bestand, nicht darin. Der Prototyp arbeitet mit echten Daten, verändert aber nichts am Kernsystem. So bleibt das Risiko klein.

4. Abbruchkriterium vorher festlegen. Was muss am Ende der Zeitbox sichtbar sein, damit es weitergeht?

5. Danach bewusst entscheiden. Verwerfen, nachschärfen oder als richtiges Produkt bauen, dann mit bekanntem Nutzen.

Punkt 5 ist wichtig: Ein Prototyp ist kein Produkt. Was sich bewährt, wird sauber gebaut, getestet und betrieben, mit Monitoring und Alarmen auf genau den Kennzahlen, die das Experiment gezeigt hat. So wird aus dem Versuch ein internes Werkzeug, auf das sich das Team verlassen kann.

Was das für die nächste Architektur-Runde heißt

„Aufwand zu groß, Nutzen unbekannt“ sollte nicht das Ende einer Diskussion sein, sondern ihr Anfang. Die bessere Anschlussfrage lautet: Wie finden wir den Nutzen in zwei Wochen heraus, statt ihn zu schätzen?

Dann ändert sich die Rechnung. Statt einer großen Wette auf eine Idee gibt es mehrere kleine Experimente. Wenn Kohavis Zahlen auch hier gelten, bringen etwa zwei Drittel davon nichts. Das ist in Ordnung, denn sie waren günstig. Das eine Drittel, das trägt, hätte es unter den alten Bedingungen nie gegeben.

Liegen bei Ihnen Ideen in der Schublade, die an genau diesem Satz gescheitert sind? Sprechen Sie uns an. Wir sagen Ihnen ehrlich, welche davon sich für ein Experiment eignen. Mehr zur Entscheidung zwischen Standard und Eigenbau: Software kaufen oder entwickeln? und Was kostet Software-Entwicklung?

Quellen