When a website project goes badly, it's common to blame the technology. Either the developer used the wrong platform, or the CMS was too complicated, or the hosting wasn't up to the job. I hear this all the time.

Occasionally, it's true. But in my experience, it's rarely the real reason websites fail.

I've been involved in digital projects for over twenty years. I've run them, rescued them, and occasionally watched them crash and burn spectacularly despite everyone's best efforts. But the problems that cause projects to go wrong are almost always human and organisational, not technical.

The communication breakdown

The most common failure mode is straightforward: the people building a website have a different understanding of what's being built than the people who asked for it.

This sounds like an obvious thing to avoid, and yet it happens constantly. Requirements get discussed in a meeting, captured loosely, and then assumed to be understood. Weeks later, when the first version arrives, both sides are surprised by how far apart they are.

Digital projects require a level of specificity that most initial conversations never reach. "I want a website where customers can book appointments" can mean fifty different things depending on how you build it and what the business actually needs. If nobody pinned that down at the start, you'll spend the back end of the project arguing about what was agreed.

The "nobody's in charge" problem

The second most common failure is that everyone assumes someone else is managing the project. Or worse, that everyone is managing the project

The client assumes the developer is keeping track of timelines and deliverables. The developer assumes the client is making decisions about content and approvals. The designer is waiting for copy. The copywriter is waiting for sign-off on the sitemap. Meanwhile nothing is moving.

This is so common that it barely registers as a problem anymore. It's just how projects go. But it's not inevitable. It happens because no one was explicitly given the role of keeping everything moving. Developers are hired to build things. Designers are hired to design things. Neither of them is hired to chase decisions, maintain the project plan, and flag when things are slipping.

That job needs to belong to someone. And on most small business web projects, it doesn't belong to anyone.

I've seen this happen in real-time, where projects that used to take 6 weeks to complete, now stretch into months of back & forth, with no real progress, far too many compromises, and ultimately, a disappointing result for everyone involved.

Scope creep and the polite yes

The third pattern is scope creep, which on the surface looks like a budgeting problem but is actually a communication problem.

Scope creep usually starts with a reasonable-sounding request mid-project. "While you're in there, can you also..." is the phrase that should put every project manager on alert. One addition becomes two. Two become five. The timeline stretches but the budget doesn't, and eventually the developer starts cutting corners to get it done.

The solution isn't to say no to every change request. It's to make the trade-offs visible every time. "Yes, we can add that. It'll take two days and push the launch date back by a week" is a clear, honest response. What usually happens instead is a polite yes that doesn't get written down, and a project that slowly bleeds out over three months.

There's also this weird expectation that "you're working on it anyway, so it won't cost more, right?". Wrong. Sure, if a new request takes 10 minutes, raising the paperwork takes longer than doing the job. But two days of work is two days you're not working on another project, and someone has to pay for that.

The approval bottleneck

Digital projects rely on clients making decisions quickly. Which photo to use. Whether to approve the design. What the homepage headline should say.

On the client side, these feel like small things that can wait. On the project side, they're blockers. A developer who is waiting for a content decision can't finish the pages. A designer waiting for logo sign-off can't finalise the colour system.

Most project timelines are built assuming prompt responses. Most clients are busy and don't respond promptly, or accurately. The gap between those two realities is where timelines go to die.

What actually helps

None of this is complicated to fix in principle. The same things help on almost every project:

  • A written brief that everyone has agreed to before anything is built.
  • Clear ownership of the project manager role. Either by the client, the agency, or a freelance PM like me.
  • A process for logging and pricing change requests.
  • Realistic timelines that account for client response times rather than assuming instant turnarounds.
  • Regular check-ins where the actual status is discussed honestly, not optimistically.

These things aren't exciting. They don't involve any particular technology or methodology. But they're what separates projects that land well from projects that limp over the finish line six months late and over budget.

Oh, and the technology, for what it's worth, is usually fine. Despite what everyone on LinkedIn would have you believe.