Learning from Failed Projects: Warning Signs in Week One

Almost every digital project that eventually falls apart sent signals long before its deadline slipped. The trouble is that those signals never look like large problems at the moment they appear. They look like small things that can be sorted out next week — and by next week there are three of them.

This article collects the eleven early signals that most often precede a project going off course, why each is easy to ignore, and the correction still available at each stage. It applies in both directions: for clients assessing a vendor, and for delivery teams assessing the health of their own project.

Signals in week one

1. The goal cannot be stated in one sentence

If after the kickoff nobody can say what has to change in the business once the project is finished, the project has no checkable direction. Every subsequent decision will be made on taste, and taste changes.

Correction: stop and write a one-page goal statement before continuing. This is cheap in week one and nearly impossible in month three.

2. There is no single decider on the client side

When feedback arrives from four people pulling in different directions and nobody has authority to resolve them, the number of revision rounds has no natural limit.

Correction: ask for one name who delivers the final decision. They may consult anyone, but one voice comes out.

3. Scope is described with adjectives

A proposal reading "a modern, complete website" with no page or feature list will produce mismatched expectations that only surface mid-build, when changing them is expensive.

Correction: ask for a concrete deliverables list before contracting. How many pages, which pages, which features, what is excluded.

Signals in month one

4. Content does not exist and nobody owns preparing it

This is the number one cause of delay on website projects, and it is almost always visible early — usually as the phrase "we will send the content later".

Correction: name a content owner, and set deadlines per page rather than one combined deadline.

5. Approvals are given verbally

An unrecorded approval will be disputed later, not because anyone is dishonest but because memories of who approved what genuinely do not survive two months.

Correction: one dated line per stage is enough. No formal document required.

6. The wireframe stage gets skipped

Going straight to coloured design mixes the discussion about arrangement with the discussion about taste, and neither gets resolved.

Correction: step back one stage. Wireframing five page types usually takes a day and saves weeks.

Signals mid-project

7. Progress updates stop arriving

A vendor who reported weekly and then becomes hard to reach is almost always dealing with a problem. Silence is not a sign that everything is fine.

Correction: ask directly and specifically: what finished this week, what is in progress, what is blocking. The third question matters most.

8. Small requests keep arriving with no impact assessment

Scope rarely expands through one large request. It expands through a dozen that each feel reasonable and are never added up.

Correction: keep one open list of every addition with its time estimate, then review it together every two weeks.

9. Deadlines slip with no stated cause

Slipping a week is not a big problem. Slipping a week with no explanation of what caused it is, because it means the cause is unaddressed and will recur.

Correction: ask for the cause, not just the new date. If the cause is waiting on something from your side, that is good news — it can still be accelerated.

Signals near the end

10. Testing is treated as a formality

A review done casually the day before launch almost certainly misses something important: forms not arriving, tracking not firing, redirects not installed.

Correction: provide a checklist, divide it, and do not launch until every item is ticked. A usable list is in our website project flow guide.

11. There is no plan for the two weeks after launch

Most real problems appear once actual visitors arrive. A project considered finished on launch day leaves those problems without an owner.

Correction: agree who monitors what for two weeks, and how problems get reported.

Warning signs are rarely something that is wrong. They are usually something not yet decided, with everyone assuming somebody else will decide it.

Signals specific to ongoing marketing engagements

The framework above was written with time-boxed projects in mind — websites, systems, launch campaigns. Ongoing monthly marketing work has additional signals of a different shape, because there is no large deadline available to slip.

• Reports that read identically every month. Repeating sentences with changed numbers usually indicate nobody is analysing, only copying a dashboard.
• The reported metric keeps changing. Reach this month, engagement next, clicks after that. Rotating metrics often means what is reported is whatever happened to rise.
• Nothing is ever stopped. A healthy engagement occasionally shuts down a campaign that is not working. If everything is permanently "being optimised", no decisions are being made.
• Every recommendation is to increase budget. Sometimes that is the right answer, but if it is the only answer for six months, the diagnosis deserves questioning.
• Nobody knows what next month's work is. An engagement without a plan turns into paid maintenance.

The correction for all of them is the same and simple: ask for a one-page monthly plan stating what will be done, what is expected to change, and which number will be used to judge it. That request is easy for a partner who works from a plan and very hard for one who does not — and the difference in reaction is itself informative.

Judging how serious a signal is

Not all signals carry equal weight. A simple framework for assessing them: how expensive is fixing it now, and how expensive is fixing it later.

Signal	Cost to fix now	Cost to fix later
Unclear goal	One meeting	The entire project
No single decider	One conversation	Unlimited revisions
No content	Scheduling the writing	Delayed launch
Wireframes skipped	One day	Redesign
Scope expanding	One list	Budget exhausted
Testing as formality	Two days	Lost traffic

Signals with the largest gap between the two columns deserve immediate attention, even when they feel non-urgent at the time.

Client-side signals that go unnoticed

The list above mostly assesses the delivery side. It is only fair to name the signals coming from the client side too, because projects that slip usually have causes on both — and these are the ones least often discussed openly.

• Feedback always arrives late. A vendor waiting two weeks for approval cannot meet any deadline.
• Decisions get reopened by someone who was not in the meeting. A symptom of a single decider not genuinely established.
• Access never gets granted. Domain, hosting, and analytics accounts are often only hunted for on launch day.
• Feedback is taste without reasons. "It does not feel right" cannot be acted on; it produces paid guessing.
• Goals change without adjusting scope. Shifting business priorities are normal — but the deadline and budget need revisiting too.

That last one causes the most disappointment on both sides. Changing direction mid-project is not a problem; expecting a new outcome on the old deadline and budget is.

A fortnightly health check

The simplest way to catch signals early is a short recurring check. Every two weeks, answer four questions together: is the goal still the same, is the deadline still realistic, what is each side waiting on, and is any decision more than a week overdue.

The last question rescues the most. Overdue decisions rarely announce themselves; they simply make everything run slightly slower until it becomes obvious the project is not moving.

Raising concerns without damaging the relationship

Naming a warning sign often feels like an accusation, which is why many people stay quiet until things have gone too far. A few ways to raise them that preserve the relationship while still solving the problem:

• Talk about the pattern, not the person. "No update has arrived for three weeks" is easier to answer than "you are not communicative".
• Ask rather than conclude. Some signals have reasonable explanations you do not know about.
• Frame the impact on the shared goal, not on your discomfort.
• Offer a concrete correction. A concern arriving with a proposal is far easier to accept.
• Raise it early. A concern in week two reads as attentiveness; the same concern in week eight reads as an accusation.

Recovering a project that is already circling

When signals have piled up and the project feels stuck, forcing it forward the same way rarely works. More effective is pausing and restructuring, usually in four steps.

1. Stop new work for a few days. Adding work on top of an unagreed foundation only enlarges the loss.
2. Write down the actual state. What is finished, what is half-built, what has not been touched — without either side defending itself.
3. Re-agree the minimum scope worth launching. It is almost always smaller than the original plan, and almost always sufficient.
4. Reset the deadline and decider for that new scope, with a fortnightly check.

The third step matters most and is emotionally hardest, because it feels like admitting failure. Yet launching a smaller version that is genuinely finished almost always beats waiting for a complete version that never arrives — and the rest can be built once something is live.

Writing down the lesson so it does not repeat

A project that went wrong has value if its lessons are recorded, and almost none if they are not. Unfortunately, post-project review is least likely to happen exactly when it is most needed, because everyone wants to move on quickly.

A useful review does not need to find who was at fault. Four questions, answered in writing about two weeks after the project ends or stops, are enough: when did the problem actually start, which signals were already visible then, why were those signals not acted on, and what rule will we use next time.

The third question produces the most useful findings. The answer is usually not "we did not see it" but "we saw it and felt it was not the moment to speak" — and that is fixable with a simple agreement on the next project, such as a fortnightly check that makes such conversations scheduled rather than dependent on someone's courage.

Storing it somewhere it will be read

Lessons filed in someone's personal folder are never read again. Store them alongside the project documents, and build the habit of rereading them at the next project's kickoff. Five minutes reading the previous project's notes often prevents an exact repeat.

When to stop a project

Some projects genuinely should be stopped, and recognising that point is cheaper than continuing because money has already been spent. Three conditions usually indicate stopping beats fixing:

1. The goal is no longer relevant. The business changed, and what is being built answers a problem that no longer exists.
2. Corrections have been tried twice with no behaviour change. The same signal recurring after two conversations is usually structural.
3. The cost to finish exceeds the remaining benefit. Money already spent does not come back by spending more.

If you decide to stop, ask for three things before parting: all files and code produced so far, credentials for every account, and a written note of what is complete. All three are far harder to obtain once the relationship has soured.

Prevention is cheaper than correction

Most of the signals above are prevented by four habits that take little time: writing the goal down at the start, naming one decider on each side, recording approvals and changes, and asking for a written weekly update that states what is being waited on.

Those four sound bureaucratic for a small project. In reality their impact is greatest on small projects, because small projects have no spare time or budget to absorb mistakes.

In summary

Learn the early signals: a vague goal, no single decider, scope described in adjectives, content with no owner, verbal approvals, skipped wireframes, updates that stop, unassessed requests, deadlines slipping without cause, testing as formality, and no post-launch plan. Judge each by the gap between fixing now and fixing later. Raise them early with a concrete proposal. And know when stopping is the right decision.

Want your project reviewed before it goes too far? Talk to our team.