---
title: "Why web projects fail: 5 mistakes from 14 years of agency practice"
lang: en
type: blog
canonical: https://www.arocom.de/en/blog/why-web-projects-fail
alternate: https://www.arocom.de/blog/projektmanagement-fails-webprojekte
author: "Axel Roth"
published: 2026-05-28
last_updated: 2026-10-31
---

# Why web projects fail: 5 mistakes from 14 years of agency practice

From over 160 web projects since 2012, five recurring failure patterns emerge: budget and goals are never honestly reconciled before the project starts, a single empowered project owner is missing, content arrives last, scope grows unchecked, and no plan exists for the time after launch. An early-warning table shows how to spot each pattern within the first four project weeks. AI shifts the weighting: implementation becomes faster and cheaper, which makes decision and content bottlenecks on the client side stand out even more clearly.

## Why web projects fail: five mistakes from 14 years of agency practice

We wrote this article once before, in 2025, with nine pitfalls back
then. For the new edition we cut and prioritised: in our project
experience, five mistakes cause the bulk of the problems. And one
new factor has arrived that shifts the weights: AI in
implementation.

For each mistake we describe a typical course of events from our
projects. The examples are anonymised and condensed; we have lived
through each of them in this form several times.

## Mistake 1: budget and goals are never honestly reconciled

The pattern: a big vision meets a small, short-term budget.
Because the conversation about it is uncomfortable, it gets
postponed until it comes back as a budget overrun.

This is how it typically plays out: a machine builder wants a
relaunch, a product configurator, a dealer portal and four
languages. The budget visibly covers half of that, but nobody
says so in the kickoff. In month three the question returns as an
escalation, the configurator gets cut from scope, and the concept
work already paid for it is lost. The conversation from week 1 was
simply held later, at a higher price.

Open source sharpens the misunderstanding. Drupal costs no
licence, so the project looks cheap. Implementation and
customisation still cost money, and they are the largest part.

What helps: before the project starts, map every requested feature
to a business goal and sort it into must-have or nice-to-have. If
the wish list and the budget do not match, one of the two is
adjusted before work begins. In agile projects, every sprint
planning is the opportunity to keep checking this.

## Mistake 2: nobody is allowed to decide

Without a single, empowered project owner on the client side, a
committee decides. Committees deliver contradictory feedback on a
weekly cadence, and every design question becomes a voting round.

The typical course: marketing, sales and management give separate
feedback on the homepage draft, three rounds in three different
directions. After six weeks, the same page is still in review.
Only when management empowers one person is the decision made
within three days, and the rest of the project picks up that pace.

The problem is rarely a lack of competence among those involved,
but the missing authority that resolves conflicting goals: sales
wants leads, marketing wants brand, and one draft cannot maximise
both at once.

What helps: one person with a mandate. They collect the
stakeholders' opinions, but they decide. In our experience,
projects with this role move through feedback cycles twice as fast
as projects without it.

## Mistake 3: content comes last

"We will deliver the copy later" is the most reliable single
indicator of launch delays we know. Design and development are
done, then everyone waits three months for content.

A typical example: a service provider's website was technically
finished in spring; the launch happened in autumn. The
departments were supposed to write their section copy "in
between", alongside the day-to-day business, with no deadline and
no owner. What solved it in the end was a combination of AI first
drafts and a single approval round per department, with a fixed
deadline. The same construction would have prevented the
half-year delay from the start.

What helps: run content as its own workstream with its own owner
and its own deadlines, in parallel with development. AI-assisted
first drafts speed up that workstream considerably, but they do
not replace the expert approval (this is
[how we work with it ourselves](https://www.arocom.de/en/blog/drupal-ai-content-workflows)).

## Mistake 4: scope grows quietly

No single change is the problem. The problem is twenty small
"while we are at it" requests that are never weighed against
budget and schedule.

Typical course: an extra slider here, a special view for a
landing page there, a "small" export feature for sales. Every
wish is kindly agreed to on the call; none is assessed
individually. At the end of the project, the effort sits roughly
30 percent above plan, and nobody can say exactly where it came
from. After visible change prices were introduced in this
project, the number of requests dropped on its own, because
suddenly people prioritised.

What helps: every change gets a price in money or time, visible
to both sides. That sounds bureaucratic and is the opposite: it
makes decisions fast, because the costs are on the table.

## Mistake 5: after the launch comes the standstill

Many projects budget up to go-live and not a day further. Then
there is nobody for updates, content, analytics and further
development. The website starts ageing from day one.

Here too, a typical pattern: a website runs untouched for two
years after launch, security updates are postponed, content goes
stale. Then a critical security release forces a rush job under
time pressure that costs more than two years of regular
maintenance combined. Meanwhile, the news page ends in the year
of the launch, which every visitor can see.

What helps: plan operations from the start. Maintenance, content
care and a quarterly budget for further development belong in the
project budget, not in a later negotiation. As a rule of thumb
from our support contracts: expect around ten to fifteen percent
of the project sum per year for maintenance and moderate further
development.

## Early warning signals: how to spot the mistakes in weeks 1 to 4

All five mistakes announce themselves early, usually before the
first invoice is written. Take these signals seriously, whether
you are the client or the agency:

| Mistake | Warning signal in weeks 1–4 | Your counter-question |
| --- | --- | --- |
| Budget and goals unclear | Money is only mentioned in passing, yet the feature wish list keeps growing | Which three features do we cut if the budget falls short? |
| Nobody is allowed to decide | Feedback arrives bundled from several departments and contradicts itself | Who decides in case of dissent, and by when? |
| Content comes last | The project plan says "copy: client", with no date and no name | Which page already has final copy today? |
| Scope grows quietly | Wishes are agreed to on calls without anyone noting the effort | What does this change cost, and what do we postpone for it? |
| No plan after launch | The budget ends exactly on the go-live date | Who maintains, measures and develops the website from day one after launch? |

## What AI changes about this list

Since AI agents started contributing to development,
implementation times and implementation costs have dropped
noticeably. That sounds like relief, but it does the opposite:
the bottlenecks move entirely to the client side. When the agency
delivers in days what used to take weeks, missing decisions
(mistake 2) and missing content (mistake 3) become obvious
immediately.

An example from one of our recent projects, as an order of
magnitude from our own observation: the component library and
around 40 page templates were in place after a good two weeks, where we
would previously have planned two to three months. What slowed us
down was something else. We waited nine days for a single design
decision, while implementing it afterwards took two. The content
for ten pages only arrived after the technical work was done. So
the total runtime was no longer determined by development, but by
the waiting time for decisions and copy.

Our consequence: today we staff projects more around decision and
content processes than around development capacity. And we
address the five mistakes openly in the kickoff, because the
higher pace has made their costs more visible, not smaller.

### Does this also apply to small projects?

Yes, if anything more sharply. Small projects have no buffers to cushion the five mistakes. A website for 15,000 euros with three co-deciders and no content plan fails just as reliably as one for 150,000, only faster. Fortunately, the remedies also work at small scale: one deciding person, a one-page must-have list, a fixed date for content.

### How do we recognise an agency that avoids these mistakes?

By the questions in the first conversation. A good agency asks about business goals and budget range, insists on an empowered point of contact, describes how it handles change requests and brings up operations and maintenance after launch on its own initiative. An agency that only talks about features and design in the first conversation is skipping exactly the topics on which projects fail.

### What does poor project management really cost?

From our observation, as an order of magnitude: in projects where two or more of the five mistakes occur, 20 to 40 percent extra cost and three to six months of delay are the rule rather than the exception. On top come the opportunity costs: every month of delay is a month without the inquiries and leads the new website is being built for.

## Five questions before the project starts

Before your next web project, check your own setup first. Five
questions are enough:

- **1.** Are budget and desired scope reconciled, with a
  must-have and a nice-to-have list?
- **2.** Who is the one empowered person who decides?
- **3.** Who delivers which content by when, and is that in the
  project plan with names and dates?
- **4.** How do we handle change requests, and who sees their
  price?
- **5.** Who operates, maintains and measures the website after
  launch, and with what budget?

With five solid answers, the project is half saved before it
begins. Take the list into your next kickoff, or better: into the
conversation before it.