Web Project Going Wrong? Warning Signs to Catch Early

A web project almost never goes off track in a single day. The first warning signs appear in delayed decisions, unclear approvals, a steady flow of new requests and the absence of reliable measurement. Catching them early protects the budget, the working relationship and the outcome users need.

A one-off delay can be recovered. Drift becomes structural when several symptoms keep recurring, the scope continues to move and nobody can clearly explain what is complete, what remains to be done and who has authority to decide.

This guide provides a practical diagnosis, a ten-working-day recovery plan and indicators that help an SME, an association or a small team confirm that the project is genuinely coming back under control.

In this article

1. Eight warning signs you should not ignore
2. Return to user needs
3. Check project governance
4. Run a fact-based audit without assigning blame
5. A ten-working-day recovery plan
6. Prevent the next drift
7. Indicators that the project is back under control
8. Practical example: scope grows but the date does not move
9. Key takeaways

The first warning sign is a phrase that has become routine: “we will decide later.” It means structural choices are accumulating without an owner or deadline while the team continues to work on fragile assumptions.

Other signs include meetings without decisions, content that never arrives, designs reviewed by people who were absent from the initial framing, features added without removing anything else, estimates repeatedly exceeded, testing postponed and an inability to demonstrate a usable version.

An isolated incident does not necessarily mean the project is drifting. When several symptoms recur across two work cycles and the same issue returns without arbitration, however, the problem has become part of the project’s operating model.

To make the diagnosis objective, record each warning with a date, its effect on schedule or budget and the decision required. This record turns a vague concern into a list of problems that can be addressed.

The GOV.UK Service Manual recommends understanding the problem, the users and their context before committing to build. This discipline prevents the imagined solution from being mistaken for the actual need.

Restate the project on one page: who uses the website, what action that person must complete, what difficulty must disappear and what evidence will show that the service works. This frame lets the team judge every request by its contribution to the outcome.

If a feature supports no priority user need, it should be postponed, simplified or removed. This is not an arbitrary refusal; it is explicit protection of the scope and delivery date.

Validate this page with the decision-maker, the delivery team and, when possible, a few users. Shared understanding reduces contradictory feedback and provides a reference point for every later trade-off.

A project slows down when everyone can comment but nobody has authority to approve. Name one accountable lead on the client side and one on the delivery side, with clear decisions and known deadlines.

The client lead arbitrates priorities, supplies content and consolidates feedback. The delivery lead explains technical consequences, maintains the schedule and makes progress visible.

GOV.UK describes product, user research, content, design and development responsibilities. An SME does not need five different employees, but it must cover these functions and know who decides when their constraints conflict.

Create a simple matrix: decision, accountable person, contributors, deadline and consequence of no response. This visibility prevents approvals from disappearing between meetings.

Hold a 60-to-90-minute meeting with four inputs: the approved scope, the list of added requests, the latest visible version and the register of pending decisions. The goal is to establish facts, not assign blame.

Classify every item in four groups: complete and verified, complete but awaiting approval, required for the current release, or postponed. Any request without an owner or acceptance criterion must be clarified before it remains in the schedule.

Do not measure progress by hours consumed. Measure it by genuinely usable journeys: requesting a quote, registering, buying, finding information or contacting the organisation.

End the audit with three short lists: what blocks launch, what can be delivered immediately and what must leave the scope. These lists become the foundation of the recovery plan.

Day 1: freeze new requests, name the decision-maker and publish the list of urgent trade-offs. Days 2 and 3: inventory pages, content, integrations, access, dependencies and everything that has not yet been tested.

Day 4: choose the three outcomes that are essential for launch. Day 5: rebuild a short schedule with owners, dates and verifiable acceptance criteria.

Days 6 to 8: complete one end-to-end journey, then test it on mobile and desktop. Day 9: correct critical obstacles and verify forms, measurement, security and access.

Day 10: the decision-maker chooses to launch, extend with a firm date or reduce the scope again. That decision must be based on a real demonstration, not a declared percentage of completion.

Work in small, visible releases. Agile practice does not mean moving forward without a plan; it means planning continuously from evidence, feedback and what has actually been delivered.

Every cycle should produce a demonstration, a decision and an updated priority list. A visible version exposes misunderstandings earlier than a long report or an isolated estimate.

Maintain a decision register: date, question, options, owner, decision and consequence. Add a change rule: every new request must state its value, cost and the item it replaces in the current release.

Schedule checkpoints for content, integrations and testing as well. These dependencies become critical when they are discovered only at the end of the project.

The project is returning to control when critical decisions are made within the agreed time, content arrives according to a shared schedule and a testable version is demonstrated regularly.

Track the gap between planned and delivered work, the number of pending decisions, the average age of blockers and the share of journeys tested end to end. Trends matter more than a single measurement.

After launch, observe useful actions rather than visits alone: submitted forms, registrations, calls, purchases or downloads. Compare these results with the needs defined at the start.

A durable recovery also means the scope no longer changes silently and accountable people can explain the priorities, risks and next decision required.

Consider an SME that initially approves a five-page website with a contact form. During the project it then requests a member area, two languages and a catalogue while still expecting the original launch date.

This example illustrates a decision method; it does not describe a specific client experience. The team estimates the new requests, explains their dependencies and shows their effect on the schedule and testing.

Three options are presented: postpone the new features, move the date or increase resources. The decision-maker chooses a complete five-page first release and schedules the remaining work.

The date becomes credible again because the compromise is explicit, documented and tied to a testable scope. The right response is not to accelerate silently, but to make the choices visible.

The best time to recover a web project is before delay becomes routine. Weak signals should be discussed as soon as they start to recur.

Return to the user need, make the work visible, restore decision authority and reduce the scope until the team has a complete, testable release.

A useful recovery plan combines named owners, acceptance criteria, short deadlines and regular demonstrations. It protects the relationship, the budget and the quality of the result.

Recovery is successful when the team can explain what has been delivered, what remains to be decided and how results will be measured after launch.

• GOV.UK — Core principles of agile
• GOV.UK — How the discovery phase works
• GOV.UK — What each role does in a service team