Warum Webprojekte scheitern: fünf Fehler aus 14 Jahren Agenturpraxis

Das Muster: Eine große Vision trifft auf ein kleines, kurzfristiges Budget. Weil das Gespräch darüber unangenehm ist, wird es verschoben, bis es als Budgetüberschreitung zurückkommt.

So läuft es typischerweise: Ein Maschinenbauer wünscht sich Relaunch, Produktkonfigurator, Händlerportal und vier Sprachen. Der Budgetrahmen reicht erkennbar für die Hälfte, aber niemand spricht es im Kickoff aus. In Monat drei kommt die Frage als Eskalation zurück, der Konfigurator fliegt aus dem Scope, und die bereits bezahlte Konzeptarbeit dafür ist verloren. Das Gespräch aus Woche 1 wurde nur teurer nachgeholt.

Open Source verschärft das Missverständnis. Drupal kostet keine Lizenz, also wirkt das Projekt günstig. Implementierung und Anpassung kosten trotzdem Geld, und zwar den größten Teil.

Was hilft: vor Projektstart jede gewünschte Funktion einem Geschäftsziel zuordnen und in Must-have oder Nice-to-have einsortieren. Wenn Wunschumfang und Budget nicht zusammenpassen, wird eines von beiden angepasst, bevor die Arbeit beginnt. In agilen Projekten ist jede Sprintplanung die Gelegenheit, das nachzuhalten.

Ohne einen einzelnen, bevollmächtigten Projektverantwortlichen auf Kundenseite entscheidet ein Ausschuss. Ausschüsse liefern widersprüchliches Feedback in Wochenfrist, und jede Designfrage wird zur Abstimmungsrunde.

Der typische Verlauf: Marketing, Vertrieb und Geschäftsführung geben getrennt Feedback zum Startseiten-Entwurf, drei Runden lang in drei verschiedene Richtungen. Nach sechs Wochen steht dieselbe Seite noch immer in Abstimmung. Erst als die Geschäftsführung eine Person bevollmächtigt, fällt die Entscheidung in drei Tagen, und der Rest des Projekts übernimmt das Tempo.

Das Problem ist dabei selten mangelnde Kompetenz der Beteiligten, sondern die fehlende Instanz, die Zielkonflikte auflöst: Vertrieb will Leads, Marketing will Marke, und ein Entwurf kann nicht beides zugleich maximieren.

Was hilft: eine Person mit Mandat. Sie sammelt die Meinungen der Stakeholder ein, aber sie entscheidet. Projekte mit dieser Rolle laufen in unserer Erfahrung doppelt so schnell durch Feedback-Zyklen wie Projekte ohne.

"Die Texte liefern wir nach" ist der zuverlässigste Einzelindikator für Launch-Verschiebungen, den wir kennen. Design und Entwicklung sind fertig, dann warten alle drei Monate auf Inhalte.

Ein typisches Beispiel: Die Website eines Dienstleisters war im Frühjahr technisch fertig, der Launch fand im Herbst statt. Die Fachabteilungen sollten ihre Bereichstexte "zwischendurch" schreiben, neben dem Tagesgeschäft, ohne Termin und ohne Verantwortlichen. Gelöst hat es am Ende eine Kombination aus KI-Erstfassungen und einer einzigen Freigaberunde pro Bereich, mit fester Deadline. Dieselbe Konstruktion hätte das halbe Jahr Verzögerung von Anfang an verhindert.

Was hilft: Inhalte als eigenen Arbeitsstrang mit eigenem Verantwortlichen und eigenen Deadlines führen, parallel zur Entwicklung. KI-gestützte Erstfassungen beschleunigen den Strang erheblich, ersetzen aber nicht die fachliche Freigabe (wie wir selbst damit arbeiten).

Kein einzelner Change ist das Problem. Das Problem sind zwanzig kleine "wo wir schon dabei sind", die nie gegen Budget und Zeitplan gerechnet werden.

Typischer Verlauf: ein zusätzlicher Slider hier, eine Sonderansicht für eine Landingpage da, ein "kleines" Export-Feature für den Vertrieb. Jeder Wunsch wird im Call freundlich zugesagt, keiner einzeln bewertet. Am Projektende liegen die Aufwände rund 30 Prozent über Plan, und niemand kann sagen, woher genau. Nachdem in diesem Projekt sichtbare Change-Preise eingeführt wurden, sank die Zahl der Wünsche von allein, weil plötzlich priorisiert wurde.

Was hilft: jede Änderung bekommt einen Preis in Geld oder Zeit, sichtbar für beide Seiten. Das klingt bürokratisch und ist das Gegenteil: Es macht Entscheidungen schnell, weil die Kosten auf dem Tisch liegen.

Viele Projekte budgetieren bis zum Go-live und keinen Tag weiter. Dann gibt es niemanden für Updates, Inhalte, Auswertung und Weiterentwicklung. Die Website altert ab dem ersten Tag.

Auch dafür ein typisches Muster: Eine Website läuft nach dem Launch zwei Jahre unangetastet, Sicherheitsupdates werden aufgeschoben, Inhalte veralten. Dann erzwingt ein kritisches Security-Release eine Hauruck-Aktion unter Zeitdruck, die mehr kostet als zwei Jahre reguläre Wartung zusammen. Die Neuigkeiten-Seite endet derweil im Jahr des Launches, was jeder Besucher sieht.

Was hilft: den Betrieb von Anfang an mitplanen. Wartung, Inhaltspflege und ein Quartalsbudget für Weiterentwicklung gehören ins Projektbudget, nicht in eine spätere Verhandlung. Als Faustwert aus unseren Betreuungsverträgen: Rechnet mit rund zehn bis fünfzehn Prozent der Projektsumme pro Jahr für Wartung und maßvolle Weiterentwicklung.

Alle fünf Fehler kündigen sich früh an, meist bevor die erste Rechnung geschrieben ist. Diese Signale solltet ihr ernst nehmen, egal ob ihr Kunde oder Agentur seid:

Seit KI-Agenten in der Entwicklung mitarbeiten, sinken Umsetzungszeiten und Umsetzungskosten spürbar. Das klingt nach Entspannung, bewirkt aber das Gegenteil: Die Engpässe wandern vollständig auf die Kundenseite. Wenn die Agentur in Tagen liefert, was früher Wochen brauchte, fallen fehlende Entscheidungen (Fehler 2) und fehlende Inhalte (Fehler 3) sofort auf.

Ein Beispiel aus einem unserer jüngeren Projekte, als Größenordnung aus eigener Beobachtung: Komponentenbibliothek und rund 40 Seitentemplates standen nach gut zwei Wochen, wofür wir früher zwei bis drei Monate angesetzt hätten. Gebremst hat etwas anderes. Auf eine einzige Designentscheidung warteten wir neun Tage, die Umsetzung danach dauerte zwei. Die Inhalte für zehn Seiten kamen erst nach dem technischen Abschluss. Die Gesamtlaufzeit bestimmte also nicht mehr die Entwicklung, sondern die Wartezeit auf Entscheidungen und Texte.

Unsere Konsequenz: Wir besetzen Projekte heute stärker über Entscheidungs- und Inhaltsprozesse als über Entwicklungskapazität. Und wir sprechen die fünf Fehler im Kickoff offen an, weil ihre Kosten durch das höhere Tempo sichtbarer geworden sind, nicht kleiner.

Prüft vor eurem nächsten Webprojekt zuerst die eigene Aufstellung. Fünf Fragen genügen:

• 1. Sind Budget und Wunschumfang abgeglichen, mit einer Must-have- und einer Nice-to-have-Liste?
• 2. Wer ist die eine bevollmächtigte Person, die entscheidet?
• 3. Wer liefert welche Inhalte bis wann, und steht das mit Namen und Datum im Projektplan?
• 4. Wie gehen wir mit Änderungswünschen um, und wer sieht deren Preis?
• 5. Wer betreibt, pflegt und misst die Website nach dem Launch, mit welchem Budget?

Mit fünf belastbaren Antworten ist das Projekt zur Hälfte gerettet, bevor es beginnt. Nehmt die Liste mit ins nächste Kickoff, oder besser: in das Gespräch davor.