Why Software Projects Run Late — and Who Controls It

Ask a supplier why a project is late and you'll usually hear about technical complexity. Ask the client and you'll hear the supplier was slow.

Both are sometimes true. But in our experience the most common causes are neither technical nor a matter of effort — they're decisions that didn't get made, content that didn't arrive, and scope that grew without anyone calling it growth.

Here's an honest split: what suppliers cause, what clients cause, and what to do about each.

What the supplier causes

1. Optimistic estimates. Given an ambiguous brief, suppliers estimate the version of the project they imagine, which is usually the simplest one. The fix is on us — specify properly before quoting, and price what's actually there.
2. Underestimating integration. "Connect it to your accounting system" is one line in a brief and sometimes weeks of work, depending entirely on what that system allows. Any supplier who hasn't investigated the integration before quoting has guessed.
3. Too many projects at once. The most common invisible cause. Your project is on time until another client's emergency arrives. You can't see this from outside, which is why asking about capacity is a fair question.
4. No defined process. Without milestones, review points and a change procedure, a project drifts by a few days at a time until it's a month behind and nobody can say exactly when it happened.

What the client causes

This is the half most agencies leave out. It isn't a complaint — these are genuinely the things only you can fix.

1. Content arriving late. The single biggest cause of website delays. Design and development are predictable; copy, product data and photography are not. A project waiting on twelve product descriptions is stopped, regardless of how fast the developer works.
2. Approval by committee. When feedback comes from four people who disagree, the supplier can't act on it. One decision-maker who consolidates input before sending it is worth more than any efficiency gain elsewhere in the project.
3. Slow responses at decision points. A three-day wait for approval during a two-week build phase isn't a three-day delay — the team moves to other work and returning to yours costs more than the wait itself.
4. Late-arriving requirements. "Can it also do X?" is a legitimate question at scoping. Six weeks in, it's a new project wearing the old project's name.
5. Access not granted. Server credentials, third-party accounts, the person who knows how the existing system works. Projects sit idle for weeks waiting for a password — which is one more reason to know who actually owns your website and accounts before a project starts.

The one that's nobody's fault

Sometimes the requirement genuinely wasn't knowable at the start. A process turns out to have an exception nobody mentioned because it's "just how we've always done it." A third-party system behaves differently in reality than in its documentation.

This is normal, particularly in operations software. It's not a failure by either side — but it does have to be named when it happens, quoted as a variation and added to the timeline, rather than quietly absorbed until the schedule collapses.

How to protect the timeline

1. Specify before building. A written scope with exclusions removes most of the ambiguity that causes both bad estimates and mid-project surprises. How to brief a project before you ask for quotes covers what that scope should contain.
2. Get the content done first. Before development starts, ideally. If you can't, agree a date for it and treat that date as seriously as the launch date, because it controls the launch date.
3. Name one decision-maker. One person who can approve scope, design and copy. Others can advise; one person decides.
4. Agree response times both ways. Two business days for feedback, two for supplier replies. Written down, so neither side has to be the one chasing.
5. Use a change procedure. Any new requirement gets quoted with its cost and its timeline impact before it's built. Not to prevent changes — to make their price visible at the moment of deciding.
6. Ask for milestones, not a single deadline. Five checkpoints tell you at week three whether you're on track. One end date tells you at week ten.

What to ask before signing

• How many other projects will be running alongside mine?
• Who is actually doing the work, and are they allocated to my timeline?
• What do you need from me, and by when?
• What happens if I'm late with content?
• How are new requirements priced?
• What are the milestones and what do I see at each one?

The last one matters most. A supplier who can name five checkpoints has a plan. One who offers only a final date has an intention.

How we work

We specify before we design, and the specification includes exclusions — the things not in this project — because unnamed assumptions are where timelines break.

We name what we need from you and when, at the start. If content or approvals arrive late, we say so in writing at the time rather than absorbing it and revealing a three-week overrun at the end. And any new requirement is quoted as a variation with its timeline impact attached, so the decision is yours with the cost visible. That applies whether it's a website, an ERP or an app.

That doesn't make us immune to delays. It makes them visible early, which is the part that matters.

The short version

Most projects don't run late because the work was hard. They run late because a decision waited, content didn't arrive, or scope grew without being priced.

Fix what you control: content ready, one decision-maker, fast responses, changes quoted before they're built.

And ask your supplier for milestones. If they can't name five, the timeline is a hope rather than a plan.