Warum digitale Plattformprojekte scheitern – und wie sich das vermeiden lässt

1999 verglühte der Mars Climate Orbiter der NASA in der Marsatmosphäre. Nicht, weil die Technik versagt hätte – beide beteiligten Teams hatten exzellente Arbeit geleistet. Das eine rechnete in metrischen Einheiten, das andere in imperialen, und keines hatte je ausgesprochen, in welcher Einheit es arbeitete. Jeder hielt seine für selbstverständlich. Ein 125-Millionen-Dollar-Projekt scheiterte nicht an Können – sondern an einer Annahme, die alle für so offensichtlich hielten, dass niemand sie prüfte.

So entsteht das eigentliche Risiko fast nie aus einer falschen Entscheidung. Es entsteht aus dem, was implizit bleibt, statt explizit zu werden: Jeder füllt die offenen Stellen still mit seinen eigenen Annahmen, alle halten sie für offensichtlich – und niemand bemerkt, dass es längst verschiedene sind. Genau das macht diese Fehlerquelle so gefährlich. Eine strittige Entscheidung lässt sich austragen. Eine unausgesprochene Annahme bemerkt niemand, bis das Ergebnis vorliegt.

Digitale Plattformprojekte scheitern aus diesem Grund – selten an der Technologie. Das gilt besonders dort, wo escape arbeitet: in Verbänden, Hochschulen und Organisationen mit vielen Beteiligten und gewachsenen Strukturen. Hier gibt es selten den einen Auftraggeber. Vorstand, Geschäftsstelle, Fachreferate und Mitglieder haben jeweils eigene, plausible Vorstellungen davon, was die Plattform leisten soll. Jede für sich ist nachvollziehbar – zusammen ergeben sie nicht von allein ein stimmiges Bild.

Scheitern ist selten ein Knall

Die wenigsten Projekte fahren sichtbar gegen die Wand. Scheitern verläuft meist schleichend – und es zeigt sich auf mehr Arten, als die spektakulären Totalausfälle vermuten lassen. Fünf besonders häufige:

• Es wird zu teuer. Das Budget vervielfacht sich gegenüber dem Plan, weil Anforderungen nachwachsen und niemand rechtzeitig gegensteuert.

• Es verfehlt den Zweck. Die Plattform ist technisch fertig, wird im Alltag aber kaum genutzt – die gefährlichste Form, weil sie monatelang niemandem auffällt.

• Es skaliert nicht. Was für die Pilotgruppe funktioniert, bricht bei wachsender Nutzerzahl oder neuen Anforderungen – weil von Anfang an nicht langfristig gedacht wurde.

• Man kommt nicht mehr heraus. Das System ist so gebaut, dass jede Änderung zur Geiselnahme wird – gebunden an eine Architektur oder einen Dienstleister.

• Niemand kann sagen, ob es sich gelohnt hat. Es wurde nie definiert, woran sich Erfolg messen lässt – und so bleibt am Ende offen, ob die Investition etwas gebracht hat.

Diese fünf sind nicht die einzigen, aber sie teilen dasselbe Muster: Sie entstehen früh, lange bevor sie sichtbar werden. Die Weichen werden in den ersten Wochen gestellt – nicht beim Launch.

Wenn der Umfang zu Beginn feststeht, ist er meistens falsch

Viele Projekte starten in die Umsetzung, sobald eine Anforderungsliste existiert. Das wirkt effizient, ist aber das eigentliche Risiko. Denn eine Liste verdeckt, dass jeder Beteiligte stillschweigend eine andere Annahme zugrunde legt, ohne dass sie je geprüft wird.

Nehmen wir einen einzigen Begriff: „Mitglied". Für die Geschäftsstelle ist das eine zahlende Person, für den Vorstand ein Stimmberechtigter, für die IT ein Datensatz. Person oder Organisation? Ehrenmitglieder, die nichts zahlen, aber Rechte behalten? Fördermitglieder ohne Stimmrecht? Und das Stimmrecht selbst: übertragbar, und wie viele Stimmen darf eine Person bündeln? Jede dieser Unterscheidungen verändert Datenmodell, Rollenlogik und Oberfläche – und wird sie zu spät sichtbar, ist sie nicht nachträglich „einzubauen", sondern reißt die halbe Struktur auf.

Eine der am meisten unterschätzten Annahmen ist zudem die Migration. „Die Altdaten übernehmen wir natürlich" steht in keinem Lastenheft – und hängt doch oft am halben Projekt. In welcher Qualität liegen die Bestandsdaten vor? Wer bereinigt über Jahre gewachsene Einträge, Dubletten, fehlende Mailadressen? Genau hier zeigt sich, ob früh die richtige Frage gestellt wurde – oder ob es erst beim Import auffällt, wenn es teuer wird.

Bleibt das unausgesprochen, treffen am Ende die Entwickler die Entscheidungen, die eigentlich der Kunde treffen müsste – technisch sauber, aber an den Erwartungen vorbei. Es folgen Korrekturschleifen, der Umfang wächst, das Budget gerät unter Druck. Nicht, weil schlecht gearbeitet wurde, sondern weil zu früh gearbeitet wurde.

Was der Kunde nicht bestellt – und trotzdem braucht

Wenn ein Kunde beschreibt, was die Plattform können soll, meint er fast immer das Sichtbare: Funktionen, Masken, Abläufe. Das Anforderungsmanagement kennt diese als funktionale Anforderungen – und sie sind nur ein Teil des Bildes. Daneben stehen die Qualitätsanforderungen wie Skalierbarkeit, Wartbarkeit, Sicherheit und Performance sowie die Randbedingungen wie Budget, Termine und rechtliche Vorgaben.

Diese beiden letzten Kategorien benennt ein Kunde selten von sich aus. Niemand bestellt „Wartbarkeit". Trotzdem entscheidet sie darüber, ob die Plattform in drei Jahren noch weiterentwickelt werden kann oder zum Sanierungsfall wird. Hier liegt ein Trade-off, der oft missverstanden wird: Eine günstig gebaute Lösung ist nicht automatisch eine sparsame. Wer Skalierbarkeit weglässt, spart heute – und zahlt beim ersten Wachstumsschub doppelt, wenn die Plattform unter Last einbricht oder neu gebaut werden muss.

Ein Beispiel: Eine Eventplattform für einen Verband läuft elf Monate im Jahr tadellos. Dann öffnet die Anmeldung zur Jahreskonferenz, und tausende Mitglieder klicken in derselben Minute – genau dann bricht sie ein. Funktional war alles korrekt; was fehlte, war eine Qualitätsanforderung, die niemand gestellt hatte: dass das System dem kurzen, heftigen Ansturm standhält, nicht nur der durchschnittlichen Last. Mehr Serverleistung allein löst das oft nicht – entscheidend ist, ob der Lastspitzenfall überhaupt je bedacht wurde.

Auch das ist eine implizite Annahme: Der Kunde geht selbstverständlich davon aus, dass die Plattform „funktioniert". Dass darin Erwartungen an Last, Lebensdauer und Wartung stecken, die er nie formuliert hat, wird ihm erst bewusst, wenn sie verletzt sind. Diese unausgesprochenen Anforderungen sichtbar zu machen und gegen das Budget abzuwägen, bevor sie sich nur noch teuer nachrüsten lassen, ist Teil unserer Arbeit.

Unsere Aufgabe: das Unausgesprochene explizit machen

Hier liegt der Kern unserer Arbeit – und er ist weniger technischer als moderierender Natur. Bevor wir entwickeln, holen wir das heraus, was implizit geblieben ist. Das heißt konkret:

• Widersprüche aktiv hervorholen. Unterschiedliche Erwartungen liegen selten offen auf dem Tisch. Wir bringen sie zur Sprache, bevor sie zu teuren Annahmen werden – mit visuellen Hilfen: Wireframes und Klickdummys machen die spätere Oberfläche greifbar, Prozess- und Ablaufdiagramme die Abläufe dahinter, ein Proof of Concept die technische Machbarkeit. Allen gemeinsam ist, dass alle dasselbe sehen, statt es sich verschieden vorzustellen.

• Folgen und Risiken benennen. Jede Anforderung hat Konsequenzen für andere Prozesse, für Aufwand und Zeit. Was an einer Stelle einfach erscheint, kann an anderer erheblichen Aufwand auslösen. Wir legen diese Zusammenhänge offen, statt Wünsche unkommentiert weiterzureichen.

• Entscheidungen herbeiführen statt aufschieben. Das größte Risiko ist nicht die falsche Entscheidung, sondern die ausbleibende. Wir sprechen Konflikte an und moderieren sie zu einer Lösung – auch wenn das bedeutet, früh eine unbequeme Frage zu stellen.

• Ein gemeinsames Bild erzeugen. Nicht der lauteste Stakeholder ist das Risiko, sondern der stille, der erst beim Launch merkt, dass seine Anforderung fehlt. Am Ende dieser Phase wissen alle, was entsteht, warum, und in welcher Reihenfolge.

Für all das gibt es einen großen Werkzeugkasten – Event Storming, User Story Mapping, Domain Storytelling, und mit Domain-Driven Design einen ganzen Ansatz, der darauf zielt, Fachbereich und Technik dieselbe Sprache sprechen zu lassen. Diese Methoden zu kennen und situativ einzusetzen, hilft. Aber keine von ihnen klärt etwas von allein. Sie schaffen den Rahmen; die eigentliche Arbeit ist, im Gespräch zu bemerken, wenn zwei Beteiligte dasselbe Wort für Verschiedenes benutzen – und es so zu übersetzen, dass beide es merken. Am Ende entscheidet nicht die Methode, sondern Feingefühl und Übersetzungskunst.

Gute Tunnel werden von beiden Seiten eines Bergs gebohrt und treffen sich in der Mitte auf wenige Zentimeter genau – aber nur, weil beide Teams vorher dieselbe Vermessungsgrundlage festgelegt haben. Diese gemeinsame Grundlage herzustellen, ist unsere eigentliche Leistung.

Fehler sind nicht das Problem – zu spät erkannte Fehler sind es

So gründlich die Vorbereitung auch ist: Fehler lassen sich nicht ausschließen – bei uns nicht und beim Kunden nicht. Annahmen erweisen sich im Verlauf als überholt, Prioritäten verschieben sich. Das ist normal. Der Unterschied zwischen einem stabilen und einem entgleisenden Projekt liegt nicht darin, ob Fehler passieren, sondern darin, wie früh sie auffallen – und wie leicht sie sich dann noch korrigieren lassen. Ein Fehler, der in der Konzeptphase auffällt, kostet ein Gespräch. Derselbe Fehler beim Launch kostet eine Neuentwicklung. Bei Projekten dieser Größenordnung – meist mehrere Hunderttausend Euro über ein bis zwei Jahre – ist das der Unterschied zwischen einer Korrektur und einem fünfstelligen Schaden.

Deshalb ist Controlling für uns kein nachgelagertes Berichtswesen, sondern ein Frühwarnsystem. Solange der Umfang nicht vollständig geklärt ist, bleibt jede Aufwandsschätzung eine Momentaufnahme – wir versprechen deshalb keine Präzision, die es zu diesem Zeitpunkt nicht geben kann. Stattdessen betrachten wir Budget und Fortschritt entlang einzelner Arbeitspakete, nicht nur als Gesamtsumme. Erst der laufende Abgleich – wie viel ist verbraucht, wie weit ist das Projekt fachlich wirklich – macht eine Fehlentwicklung sichtbar, solange sie noch mit geringem Aufwand zu korrigieren ist. So bleiben Entscheidungen über Prioritäten und Budget jederzeit beim Kunden, auf belastbarer Grundlage.

Das gilt auch agil. Agilität heißt nicht, dass Ziele und Budgets beliebig flexibel sind – sie verlangt im Gegenteil klare Prioritäten und schnelle, gut vorbereitete Entscheidungen.

Fazit: Erfolg entsteht vor der Technik

Erfolgreiche Plattformprojekte unterscheiden sich selten durch bessere Technologie – sondern dadurch, dass das Unausgesprochene früh ausgesprochen wird. Wer implizite Annahmen sichtbar macht, ihre Folgen offenlegt und Abweichungen erkennt, bevor sie teuer werden, verhindert das schleichende Scheitern, an dem andere Projekte zugrunde gehen. Genau hier liegt unsere Arbeit: Wir bringen Struktur in komplexe Anforderungen und übersetzen zwischen allen Beteiligten, bis aus vielen stillen Annahmen ein gemeinsames Bild wird.