Score your project honestly against these five signs. It'll take you ten minutes. And if you recognise three or more, you're not reading this for entertainment — you're reading it because something in your gut already knows.
I want to be direct about who this is for. Not someone deciding whether to start a transformation. Someone mid-flight who's started to feel that familiar tightening in the stomach — the one that says this isn't going the way it was supposed to. Maybe you're a COO three months into a platform migration. Maybe you're a head of digital watching your steering group circle the same decisions for the fourth time. Maybe you're a managing partner who approved a significant budget and is now quietly dreading the next update.
The signs of a stalling project are almost always visible before the project actually stalls. The problem isn't that they're hard to spot. It's that they're easy to rationalise.
Every project has problems. That doesn't mean it's going to fail. We're managing it.
Yeah, maybe. But I've sat in enough post-mortems to know that every single one of them contains a moment where someone says, "We probably should have acted on that back in March." I've been that person. Not in a post-mortem — worse, in the middle of a live project where I'd been watching a steering group avoid a scope decision for six weeks and kept telling myself it would resolve. It didn't. We lost two months and had to rebuild a chunk of work we'd already delivered. That one still stings a bit.
The window between "this is heading somewhere difficult" and "this has already failed" is brutally short. So the question isn't whether your project has problems. It's whether the problems you're seeing are the kind that resolve themselves — or the kind that compound.
Here are the five patterns I've seen most often, ordered roughly by how early they tend to appear, which also happens to correlate with how fixable they are.
Try this: ask three stakeholders on your project what success looks like. If you get three different answers, you have a problem. If all three answers are about outputs — features shipped, pages migrated, users trained — rather than outcomes, you have a bigger problem.
I was in a quarterly review with a professional services firm about four months into a website and CRM rebuild. The partner sponsor said success meant "a website that reflects who we are." The head of marketing said it was "more leads." The IT director said it was "getting off the old platform before the licence renewal." All valid. None measurable. And none of them the same thing.
This happens because the project was approved around a vision rather than a specific problem. Someone painted a picture of the future state, the board liked the picture, and the business case got filed the moment the budget was released. Speaking of which — when was the last time anyone in your steering group actually opened the original business case? If it's been more than six weeks, that's part of this pattern.
What to do this week: Block out a half-day with your key stakeholders. Define three measurable outcomes the project must deliver, and agree how you'll measure them. Not outputs. Outcomes. "Enquiry conversion rate increases by 15%" is an outcome. "New website launches by September" is a deadline. If the conversation proves impossible — if you can't get three people to agree on three numbers — that itself is diagnostic. I've written separately about why digital projects don't deliver, and this is usually where the rot starts.
Pull up the minutes from your last three steering group meetings. Look for decisions — actual decisions, with a named person responsible and a date attached. Not discussions. Not "agreed to revisit." Not "further input needed."
If you're struggling to find any, welcome to the club. The maddening thing about this pattern is that everyone in the room feels busy. The meetings are long. The discussions are detailed. People leave feeling like progress was made. But when the delivery team goes back to their desks, nothing has actually been unblocked.
The symptom that really gives it away: the same issues appearing on consecutive agendas. I reviewed a steering group action log for a financial services client once where the question of whether to include the broker portal in scope had appeared in four consecutive meetings. Four. Each time it was "discussed" and "carried forward." Meanwhile, the delivery team was designing around both scenarios — which is another way of saying they were doing double the work and making bets on which version would eventually get approved.
The root cause is diffuse accountability. The steering group feels collectively responsible for outcomes but individually protected from consequences. Nobody wants to be the person who made the wrong call, so nobody makes any call.
What to do this week: Identify the three or four categories of decision your project requires — scope changes, design approvals, integration priorities, whatever they are. For each category, name one person with explicit authority to decide. Not "consulted." Not "involved." The person who says yes or no. Then remove those categories from the steering group agenda entirely. The steering group's job becomes strategic oversight, not operational decision-making. Clear ownership at this level is the single biggest predictor of whether a programme ships or stalls — I've seen it turn around projects that looked genuinely terminal.
This one's sneaky because it feels like progress. Status updates are full of activity: workshops held, documents drafted, architecture designed, environments configured. Everyone's working hard. The budget is being spent. But has a single end user seen anything they can actually use yet?
If you're four months in and the answer is no, you've probably designed a programme around a big reveal. All the value is back-loaded into a launch that keeps getting pushed. And every week that passes without something visible being shipped, the organisational expectation drifts further from reality.
I saw this with a 200-person consulting firm rebuilding its client portal. Eight months in, the delivery partner had produced an extraordinary amount of documentation — architecture diagrams, user research reports, wireframes, sprint reports. The internal team was drowning in artefacts. But not a single client had logged into anything new. When the first working version finally appeared in month ten, it bore so little resemblance to what the steering group had been imagining that the project nearly got cancelled. The timeline had already been revised once. It was about to be revised again.
What made it worse — and I'll be honest, we should have pushed harder on this earlier — was that the client had flagged in month five that they were nervous about the lack of visible progress. We treated it as stakeholder management rather than a genuine signal. That was a mistake.
What to do this week: Identify the single smallest thing that could be shipped to real users within the next three weeks. Not a prototype. Not a demo environment. Something real, even if it's rough. Maybe it's a simplified enquiry form. Maybe it's one section of the new portal. Maybe it's a single automated workflow. Ship it. The act of delivering something — anything — resets the organisational conversation from "when will it be ready?" to "here's what we've learned from real usage." That shift is worth more than another month of architecture documentation.
Be honest. When was the last time anyone in a progress meeting referred to the original ROI projections? Not the budget. Not the timeline. The expected return on the investment.
If your project is like most I've seen, the business case was written to get approval. It was a persuasion document — compelling enough to unlock the budget, detailed enough to satisfy the finance director, and then never opened again. Cost overruns get managed as budget variances. Scope changes get justified on their own merits. The conversation about value gradually shifts entirely to scope and timeline, because those are easier to track than outcomes.
This is dangerous because it means nobody is asking the most important question: given what we now know about costs, timeline, and complexity, does this investment still make sense on its original terms?
Sometimes the honest answer is yes — the project is more expensive than planned, but the return still justifies it. Sometimes it's "yes, but only if we cut scope X and double down on scope Y." And sometimes — this is the hard one — the original business case was built on assumptions that haven't survived contact with reality. I've had that conversation with a client. It's grim. But it's significantly less grim than the conversation six months later when the budget is gone and the return hasn't materialised.
What to do this week: Reopen the original business case at your next steering group meeting. Not as an academic exercise. Walk through what the current trajectory implies for the projected return. Update the assumptions. Have the conversation. If the governance around your programme needs attention at board level, there's a companion piece on what boards should know before approving a digital transformation budget that's worth reading alongside this.
This one catches people off guard because it often looks like professionalism. Your agency or implementation partner delivers polished milestone updates on schedule. The reports are thorough. The demos are well-prepared. But between milestones? Silence. Or vague answers when you ask how things are going.
When a delivery partner communicates only at formal checkpoints, it usually means the informal picture is messier than the formal one. The things a delivery partner mentions in passing — and doesn't write down — are often the most important signals. The developer who just left. The integration that's proving harder than expected. The assumption in the original scope that turned out to be wrong.
The commercial incentive is worth understanding. Most agency engagements are structured around milestones, which means the partner is commercially motivated to manage the milestone conversation. That's not malicious — it's structural. But it means you, as the client, need to create a channel that exists outside that structure.
We've been on the other side of this too, and I'm not proud of it. Early in a financial services project, we were carrying a technical risk for about three weeks before we surfaced it formally. We thought we'd resolve it ourselves. We didn't, and by the time we raised it, the client had less time to respond than they should have had. The relationship survived, but it was a lesson in why informal communication channels matter as much as formal ones.
What to do this week: Set up a standing weekly fifteen-minute call with the delivery lead. Not the account manager. The delivery lead. Not to review status — that's what the milestone updates are for. Just to ask: "What's worrying you this week?" and "What would you mention if we were having a coffee rather than a formal meeting?" You'll be surprised what comes out. And if the answers are consistently "all fine, nothing to report" — that's its own kind of signal.
Give yourself 0, 1, or 2 for each warning sign — 0 means it doesn't apply, 1 means you see some of the symptoms, 2 means it's clearly present.
Three or below: normal project friction. Keep an eye on it.
Four or five: specific areas that need intervention. You've probably caught them early enough to act.
Six or above: you need an honest conversation with your steering group this week, not this month. The interventions above are still available to you, but the window is closing. And honestly, a structured external perspective — even a short one — can be the thing that turns a difficult internal conversation into a productive one.
If you want a version of this checklist formatted for sharing and structured for a 30-minute honest conversation about project health — [download it here].
And if your project has already stalled — if you're past the warning signs and into the consequences — the next piece covers what to do then. Because the restart conversation is different from the intervention conversation, and confusing the two is how organisations end up spending twice.
I've never seen a transformation fail overnight. They fail in slow motion, with plenty of warning. The organisations that recover are the ones where someone had the nerve to say "hang on, let's look at this properly" while there was still time. That person might be you.