Web-Projekt gescheitert? 5 Gründe - und der richtige zweite Anlauf

Es ist eine der teuersten Erfahrungen, die ein Unternehmen machen kann: Ein Web-Projekt wird beauftragt, Monate vergehen, Geld fließt - und am Ende steht etwas anderes da als bestellt. Oder gar nichts. Wenn Sie das schon einmal erlebt haben, sind Sie nicht allein.

Gescheiterte Softwareprojekte sind eher die Regel als die Ausnahme. Und in den seltensten Fällen liegt es daran, dass „programmieren eben schwer ist". Es liegt fast immer an Mustern, die man im Vorhinein erkennen kann. Nach über 25 Jahren in der Entwicklung von Business-Webapps habe ich diese Muster oft genug gesehen - meist, wenn jemand zu mir kam, nachdem es beim ersten Anbieter schiefgegangen war.

Dieser Beitrag zeigt die fünf häufigsten Gründe, warum Web-Projekte scheitern, und woran Sie erkennen, dass der zweite Anlauf diesmal gelingt.

TL;DR - Die Kurzfassung

• Niemand hat zugehört, was wirklich gebraucht wurde - gebaut wurde, was bestellt klang.
• Kein technisches Gegenüber auf Augenhöhe - niemand sagte, was nicht funktioniert.
• Unklarer oder wuchernder Scope - kein abgegrenzter Umfang, kein überprüfbarer Zwischenschritt.
• Abhängigkeit von einer Blackbox - kein Zugriff auf Code, Server, Doku.
• Zu lange Kommunikationskette - was Sie meinten, kam bei der Entwicklung nicht an.

1. Niemand hat zugehört, was Sie wirklich brauchen

Der häufigste Grund ist auch der unscheinbarste: Es wurde gebaut, was bestellt wurde - nicht, was gebraucht wurde.

Viele Anbieter nehmen eine Anforderungsliste entgegen und setzen sie um, ohne zu hinterfragen, welches Geschäftsproblem dahintersteckt. Das Ergebnis ist technisch korrekt und fachlich am Ziel vorbei. Eine gute Analyse fragt nicht „Was wollen Sie?", sondern „Was soll am Ende besser laufen?" - und übersetzt das in eine Lösung, oft eine schlankere als ursprünglich gedacht.

Warnsignal beim ersten Mal: Es gab kein echtes Vorgespräch über Ihre Prozesse, nur die Aufnahme Ihrer Wunschliste.

2. Es fehlte ein technisches Gegenüber auf Augenhöhe

Wenn Sie selbst nicht aus der IT kommen, brauchen Sie jemanden, der für Sie mitdenkt - nicht jemanden, der Ihre Annahmen unkommentiert umsetzt.

Scheiternde Projekte haben oft eines gemeinsam: Niemand hat dem Auftraggeber gesagt, was technisch nicht funktioniert, was teuer wird oder welche Hürde im Weg steht. Ein verlässlicher Partner sagt Ihnen zuerst, was nicht geht - auch wenn das den schnellen Auftrag kostet. Genau das unterscheidet jemanden, der ein Projekt verantwortet, von jemandem, der nur Stunden verkauft.

Warnsignal beim ersten Mal: Sie haben nie ein „Nein" oder „das würde ich anders lösen" gehört. Nur Zustimmung.

3. Der Scope war unklar - oder wuchs ungebremst

„Können wir das auch noch schnell einbauen?" - der Satz, der Projekte killt. Ohne klar abgegrenzten Leistungsumfang wächst jedes Projekt, bis Budget und Zeitplan reißen.

Seriöse Anbieter arbeiten modular: ein klar umrissener erster Schritt mit definiertem Ergebnis, dann der nächste. So sehen Sie nach jeder Stufe, was geliefert wurde, und entscheiden über den Weiterbau - statt am Ende vor einer Rechnung zu stehen, die mit dem ursprünglichen Angebot nichts mehr zu tun hat.

Warnsignal beim ersten Mal: Es gab einen großen Festbetrag für ein vages Gesamtziel - keine überprüfbaren Zwischenschritte.

4. Sie waren abhängig von einer Blackbox

Viele Projekte scheitern nicht beim Bau, sondern danach: Der Anbieter ist weg, niemand versteht den Code, jede Änderung kostet wieder Geld und Wartezeit. Häufig steckt ein Framework-Lock-in oder eine undokumentierte Eigenkonstruktion dahinter.

Eine nachhaltige Lösung gehört Ihnen - sauber dokumentiert, auf nachvollziehbarer Technik, auf einem Server, auf den Sie Zugriff haben. Sie sollen Ihren Anbieter wechseln können, ohne bei null anzufangen. Wer Sie an sich bindet, indem er Wissen zurückhält, löst nicht Ihr Problem, sondern schafft ein neues.

Das gilt ausdrücklich auch für die Zusammenarbeit mit mir: Weil alles dokumentiert und in Ihrer Hand ist, sind Sie selbst dann nicht abhängig, wenn Sie mich irgendwann nicht mehr an Bord haben. Genau so vermeiden Sie, dass aus einem Dienstleister ein neuer Single Point of Failure wird.

Warnsignal beim ersten Mal: Sie hatten keinen Zugriff auf Code, Server oder Dokumentation - jede Kleinigkeit lief nur über den Anbieter.

5. Die Kommunikation lief über zu viele Stationen

Bei größeren Agenturen sprechen Sie mit dem Vertrieb, der an einen Projektleiter übergibt, der an ein Entwicklerteam weiterreicht. Auf jeder Station geht Information verloren - wie bei der stillen Post. Was Sie meinten, ist am Ende nicht, was umgesetzt wurde.

Je kürzer der Weg zwischen Ihnen und der Person, die tatsächlich baut, desto weniger geht verloren. Bei kleinen, spezialisierten Anbietern sprechen Sie direkt mit der Entwicklung - die Person, die zuhört, ist dieselbe, die liefert.

Warnsignal beim ersten Mal: Sie haben die Person, die tatsächlich entwickelt hat, nie gesprochen.

Woran Sie den richtigen Partner für den zweiten Anlauf erkennen

Wenn Sie ein zweites Mal starten, achten Sie nicht auf das Hochglanz-Angebot, sondern auf diese Signale:

• Es wird zugehört, bevor angeboten wird. Ein echtes Gespräch über Ihr Geschäftsproblem geht jeder Lösung voraus.
• Sie hören auch, was nicht geht. Ehrlichkeit über Grenzen ist ein Qualitätsmerkmal, kein Verkaufshindernis.
• Es wird modular gearbeitet. Klare Schritte, überprüfbare Ergebnisse, Entscheidung nach jeder Stufe.
• Die Lösung gehört Ihnen. Dokumentiert, nachvollziehbar, ohne Abhängigkeit.
• Sie sprechen direkt mit der Entwicklung. Kein Stille-Post über drei Stationen.

Wie ich einen zweiten Anlauf aufsetze

1. Zuhören zuerst: Was soll am Ende besser laufen? Was ist beim letzten Mal konkret schiefgegangen? Daraus entsteht das Zielbild - nicht aus einer Wunschliste.
2. Machbarkeit und Notwendigkeit prüfen: Was geht technisch, was lohnt sich, wo ist der schlankere Weg? Lieber ein ehrliches „das brauchen Sie gar nicht" als ein teures „bauen wir auch noch".
3. Modular vorgehen: Ein klar umrissener erster Schritt mit überprüfbarem Ergebnis. Sie entscheiden nach jeder Stufe über die nächste.
4. Übergabe sichern: Code, Doku und Zugänge gehören Ihnen. Kein Lock-in, keine Blackbox.
5. Direkter Draht: Sie sprechen mit der Person, die baut - nicht mit drei Vermittlern dazwischen.

Diese Arbeitsweise ist der Grund, warum die meisten meiner Projekte aus genau solchen Situationen kommen: Jemand wurde einmal enttäuscht und sucht beim zweiten Mal nicht den lautesten Anbieter, sondern den, der zuerst zuhört. Ich setze solche Projekte zum Festpreis mit klar definierten Modulen auf.

Checkliste für den zweiten Anlauf

• Wurde Ihnen zugehört - oder nur Ihre Wunschliste aufgenommen?
• Sagt Ihnen jemand auch, was nicht geht oder was teuer wird?
• Gibt es klar abgegrenzte Module mit überprüfbaren Ergebnissen?
• Bekommen Sie Code, Server und Dokumentation in die Hand?
• Sprechen Sie direkt mit der Person, die entwickelt?
• Wissen Sie, woran das letzte Projekt gescheitert ist - und ist das diesmal abgedeckt?

Fazit: Ein gescheitertes Projekt ist die beste Vorbereitung

Dass ein Web-Projekt scheitert, ist fast nie Pech und fast immer eine Folge erkennbarer Muster: kein Zuhören, kein technisches Gegenüber, unklarer Scope, Blackbox, zu lange Kommunikationswege.

Die gute Nachricht: Wer das einmal erlebt hat, weiß beim zweiten Mal genau, worauf zu achten ist. Ein gescheitertes Projekt ist teuer - aber es ist auch die beste Vorbereitung auf ein gelingendes. Sie wissen jetzt, worauf es ankommt.

Sie planen einen zweiten Anlauf und wollen diesmal jemanden, der zuerst zuhört und Ihnen auch sagt, was nicht geht? Schreiben Sie mir kurz, worum es geht und was beim letzten Mal schiefging - ich schaue mir Ihre Situation an und nenne einen Festpreis-Rahmen für einen sauberen Neustart.