Six early signs a project needs a hand, and what to do about each

Most website projects don’t go wrong all at once. They drift for a few quiet weeks, where everyone can feel it and nobody quite says it, and everybody hopes it will sort itself out.

If that sounds like yours, start here: drift is completely normal. It happens on good projects, run by capable people who are all trying their best, and every one of the six signs below is fixable.

It’s a bit like the door at home that’s started to stick. Everyone gives it a shove for a month, nobody mentions it, and then somebody has a proper look and it’s a loose screw.

None of the six are technical either. When a project gets into difficulty, the code is rarely the reason. It’s usually about decisions, and how people are talking to each other.

So here are the six, each with one simple thing to do about it. Spotting them early, and saying them out loud kindly, is a big part of what delivery lead cover is for.

The six signs

The six signs

Not one of them is about the code. They are all about decisions, and how people are talking to each other, and each card carries what it costs if nothing is done.

1. The status has been amber for a month and nothing has changed

Green means on track. Red means there’s a problem and someone needs to act. Amber sits in between. It means “I’m a bit worried”, and it can stay there for weeks, because nothing in the process asks it to become green or red.

That’s completely understandable. Nobody wants to be the one who turns a project red, so amber feels like the safe choice. The trouble is that people tend to read the colour and skip the note underneath, so the worry never quite gets talked about.

Why amber stays

Amber is the only one of the three with no exit built into it, which is why it lasts a month. One question ends it: what would need to happen for this to be green? A clear answer is a to-do list, and no answer in a sentence means a proper conversation.

How to check it: put the last four status reports next to each other and read only the note under the colour, not the colour itself. If the wording has barely changed in a month, the report is describing a feeling rather than a position, and nobody is being asked to do anything about it.

A month of amber is a month nobody spent fixing whatever the amber was for, and that thing is almost always cheaper to deal with in week four than in week twelve, when it arrives with a launch date attached to it.

What to do about it: ask one friendly question. “What would need to happen for this to be green?” If there’s a clear answer, you now have a to-do list. If nobody can answer in a sentence, the project needs a proper conversation, and it’s much easier to have it now.

2. It isn’t clear who signs off the next decision

This one isn’t about the stakeholder list. It’s about who actually says yes, this week, to the specific thing that’s holding up the work.

If you ask three people and get three different names, or a committee, you’ve found what’s slowing things down. Work rarely stops because a decision is hard. It stops because nobody is quite sure who makes it, and everyone is politely waiting for someone else. Which is a relief, really, because it’s one of the easier ones to put right.

If some of the work sits with a subcontractor, the answer also depends on which white-label model everyone agreed to, because that decides who they are allowed to ask in the first place.

How to check it: look at when each open decision was first raised, not how important it is. Anything that has been sitting for more than a fortnight is usually waiting on a person rather than on information, and the name of that person is the thing nobody has written down.

A decision that waits a fortnight rarely costs a fortnight. It costs the fortnight, plus unpicking whatever got built around the team’s best guess while they waited.

What to do about it: write one name next to each of the next three decisions and share it with the team. If a name is wrong, people will say so, and that’s a good thing. Either way, you end up with a clear, agreed answer about who decides what.

3. “We’ll pick that up later” has been said about the same thing twice

Saying it once is fine. That’s sensible planning, putting off something that isn’t blocking anything yet.

Saying it twice about the same thing is worth noticing. The thing being put off is often the hardest part of the project: the integration nobody fully understands, the data migration that doesn’t map cleanly, the approval from a department that hasn’t replied yet.

Hard things don’t get easier by waiting. They just turn up at the end, when there’s much less time to deal with them. That’s why a problem that was visible in week two so often lands in the final fortnight.

How to check it: search the last month of notes, tickets and messages for “later”, “park” and “phase two”. Anything that comes back twice with the same subject attached goes on the list, whether or not it’s blocking anything today.

The cost isn’t the work itself, which was always going to have to happen. It’s doing that work in the last fortnight, when there’s no room left to be wrong about how long it takes.

What to do about it: keep a simple list of everything that’s been put off, with a date next to each one for when it will be picked up. If something appears on the list twice, talk about it at the next catch-up, even if it isn’t blocking anything yet.

4. The demo always shows the same screen

It’s natural for a demo to show the parts that are finished and working. Everyone wants the meeting to go well, and that’s a nice instinct.

The catch is that, over a few weeks, what people see in the demo and where the build really is can drift apart. It’s easy to miss, because the meetings feel positive, and the gap only shows up when someone asks for something specific.

How to check it: write down which screen was shown at each of the last four demos. If the same one appears three times, it isn’t that the rest is hidden, it’s that nobody has had a reason to open it.

Left alone, the gap turns up in user testing or launch week, which are the two worst weeks to find it. At that point the choice is usually between moving the date and cutting something, and both are decisions everyone would rather have made in month two.

What to do about it: ask to see a different part of the site. Nothing formal, just “could we have a look at the checkout this week?” It gives everyone a clearer picture, and it gives the team an easy moment to mention anything that’s been on their mind.

5. The date hasn’t moved, but the scope has

Scope usually grows in small, reasonable steps. A field here, an extra template there, “while we’re in there, could we”. Each one really is small, and re-planning the whole project for half a day’s work feels like overkill, so it doesn’t happen.

Then twenty of them have happened, and the date everyone is still working towards was set for a smaller project.

How to check it: open the signed scope and the current backlog side by side, and mark everything in the backlog that isn’t in the scope. It takes about twenty minutes, and it’s usually the most surprising twenty minutes of the month.

Nobody pays for this in the middle of a project. It gets paid for in the last two weeks, with evenings, a feature quietly dropped, or a date that moves after everyone has already announced it.

What to do about it: count the changes since the scope was agreed and add up the estimates, even roughly. If the total is more than a week and the date hasn’t moved, the date probably needs another look. Raise it now. At this stage it’s a calm conversation about the plan, rather than a difficult one about the launch.

If the work is being done by a contractor, a scope written as a deliverable with an end on it is far easier to re-plan than one bought by the week. It’s also what keeps a contract engagement clearly a supplier arrangement, which is worth getting right for its own reasons.

6. Decisions have stopped being written down

This is the clearest sign of the six, and often the earliest.

When a team stops recording decisions (no notes, no updated tickets, no decisions log), it usually isn’t laziness. It’s because people aren’t sure the decisions will stick. Writing something down that might change next week feels like wasted effort, so it quietly stops. Then the same discussion comes round again in month three, because there’s nothing to look back on.

It also makes the other five signs harder to spot, because there’s no record to compare against.

How to check it: pick a decision from two months ago that you know was made, and try to find where it was written down and who agreed it. If that takes more than a few minutes, it isn’t recorded, it’s remembered, and memories disagree with each other in perfectly good faith.

The cost lands in month three, when the same discussion comes round again and nobody can say what was decided the first time. Then it lands again, in whatever was built on the first answer and now has to change.

What to do about it: start a decisions log yourself, with the last three decisions in it, somewhere everyone can see. Most teams are happy to join in once someone has made a start. If they don’t, that’s a useful, gentle conversation to have about whether people feel the decisions are settled.

What to do with this

Caught early, any of these is a short, friendly conversation. Left for a while, it becomes a harder one, with less time to act on it.

The reason they often don’t get raised isn’t that people can’t see them. It’s that raising them feels awkward, especially while everyone else is being positive and you might turn out to be wrong.

That’s one of the good reasons to have someone from outside helping with the plan. I’m not caught up in the team’s day to day, so it’s easier for me to raise the tricky thing early, kindly, and while there’s still plenty of time to do something about it.

If the project has stopped altogether rather than drifted, that’s usually a different thing, and more often about nobody wanting to be the one who touches it first. And if you’re thinking about what happens when the current team moves on, that’s a handover problem, and it’s much easier to sort out before it becomes one.

One record, five checks

Start the decisions log: the last three decisions, who made them and when, somewhere everyone can see. It is the record the other five signs get checked against, and it takes an afternoon.

What delivery cover already does about these six

If you bring me in as someone standing in as delivery lead, most of this is the job rather than something extra you ask for.

• Decisions get logged as they’re made, not written up at the end. It’s one of the six things listed on that page, and it’s the record the other five signs get checked against.
• A weekly status with the real risks in it. Progress, risk, and what’s waiting on whom, in a sentence each. Anything amber gets a name and a date next to it, or it becomes green or red.
• The first thing I’d do is read the signed scope against the current backlog, and write down who signs off the next three decisions. That’s usually a day, and it tells us whether this is a plan problem or a people one.
• It’s £400 a day, and delivery cover is usually two or three days a week. You get a written scope of what I’d take on and where I’d start within 2 working days of the first call, and a reply to your message within 12 working hours.