--- title: "Warum Webprojekte scheitern: 5 Fehler aus 14 Jahren Agenturpraxis" lang: de type: blog canonical: https://www.arocom.de/blog/projektmanagement-fails-webprojekte alternate: https://www.arocom.de/en/blog/why-web-projects-fail author: "Axel Roth" published: 2026-05-28 --- # Warum Webprojekte scheitern: 5 Fehler aus 14 Jahren Agenturpraxis Aus über 160 Webprojekten seit 2012 lassen sich fünf wiederkehrende Scheiter-Muster ableiten: Budget und Ziele werden nicht vor Projektstart abgeglichen, es fehlt ein einzelner bevollmächtigter Projektverantwortlicher, Inhalte kommen zu spät, der Scope wächst unkontrolliert, und für die Zeit nach dem Launch existiert kein Plan. Eine Frühwarn-Tabelle zeigt, woran ihr jedes Muster schon in den ersten vier Projektwochen erkennt. KI verändert die Gewichtung: Umsetzung wird schneller und günstiger, wodurch Entscheidungs- und Inhaltsengpässe auf Kundenseite noch deutlicher zum Flaschenhals werden. ## Warum Webprojekte scheitern: fünf Fehler aus 14 Jahren Agenturpraxis Wir haben diesen Artikel 2025 schon einmal geschrieben, damals mit neun Stolperfallen. Für die Neufassung haben wir gekürzt und priorisiert: Fünf Fehler verursachen nach unserer Projekterfahrung den Großteil der Probleme. Und ein Faktor ist neu hinzugekommen, der die Gewichte verschiebt: KI in der Umsetzung. Zu jedem Fehler beschreiben wir einen typischen Verlauf aus unseren Projekten. Die Beispiele sind anonymisiert und verdichtet; jedes davon haben wir in dieser Form mehrfach erlebt. ## Fehler 1: Budget und Ziele werden nie ehrlich abgeglichen 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. ## Fehler 2: Niemand darf entscheiden 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. ## Fehler 3: Inhalte kommen zuletzt "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](https://www.arocom.de/blog/drupal-ki-content-workflows)). ## Fehler 4: Der Scope wächst leise 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. ## Fehler 5: Nach dem Launch ist vor dem Stillstand 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. ## Frühwarnsignale: woran ihr die Fehler in Woche 1 bis 4 erkennt 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: | Fehler | Warnsignal in Woche 1–4 | Eure Gegenfrage | | --- | --- | --- | | Budget und Ziele unklar | Über Geld wird nur in Nebensätzen gesprochen, der Funktionswunsch wächst trotzdem | Welche drei Funktionen streichen wir, wenn das Budget nicht reicht? | | Niemand darf entscheiden | Feedback kommt gesammelt aus mehreren Abteilungen und widerspricht sich | Wer entscheidet bei Dissens, und bis wann? | | Inhalte kommen zuletzt | Im Projektplan steht "Texte: Kunde", ohne Datum und ohne Namen | Welche Seite hat heute schon einen finalen Text? | | Scope wächst leise | Wünsche werden im Call zugesagt, ohne dass jemand den Aufwand notiert | Was kostet diese Änderung, und was schieben wir dafür? | | Kein Plan nach Launch | Das Budget endet exakt am Go-live-Termin | Wer pflegt, misst und entwickelt die Website ab Tag eins nach dem Launch? | ## Was KI an dieser Liste ändert 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. ### Gilt das auch für kleine Projekte? Ja, eher verschärft. Kleine Projekte haben keine Puffer, die die fünf Fehler abfedern. Eine Website für 15.000 Euro mit drei Mit-Entscheidern und ohne Content-Plan scheitert genauso zuverlässig wie eine für 150.000, nur schneller. Die Gegenmittel funktionieren zum Glück auch in klein: eine entscheidende Person, eine einseitige Must-have-Liste, ein fester Termin für Inhalte. ### Wie erkennen wir eine Agentur, die diese Fehler vermeidet? An den Fragen im Erstgespräch. Eine gute Agentur fragt nach Geschäftszielen und Budgetrahmen, besteht auf einem bevollmächtigten Ansprechpartner, beschreibt ihren Umgang mit Änderungswünschen und spricht von sich aus über Betrieb und Pflege nach dem Launch. Wer im Erstgespräch nur über Features und Design redet, lässt genau die Themen aus, an denen Projekte scheitern. ### Was kostet schlechtes Projektmanagement wirklich? Aus unserer Beobachtung als Größenordnung: Bei Projekten, in denen zwei oder mehr der fünf Fehler auftreten, sind 20 bis 40 Prozent Mehrkosten und drei bis sechs Monate Verzögerung eher Regel als Ausnahme. Dazu kommen die Opportunitätskosten: Jeder Monat Verspätung ist ein Monat ohne die Anfragen und Leads, für die die neue Website gebaut wird. ## Fünf Fragen vor dem Projektstart 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.