A stalled project rarely announces itself

There's a particular meeting that most people in this industry have sat in.

The project is eight months old. The status report says amber, as it has for a while. Someone asks, reasonably, whether go-live is still realistic. And in the pause before anyone answers, everyone in the room works out independently that it isn't — and realises that everyone else has known for weeks.

Nothing went wrong in that meeting. It went wrong gradually, invisibly, over about four months.

I work in ERP, so the examples here are ERP ones — go-lives, data migrations, module scope. The pattern isn't ERP-specific. It turns up in any project that runs long enough for the people inside it to lose track of how far behind they are, and the reasons it hides are the same whether you're replacing a finance system or building a warehouse.

Stalls are quiet by design

We tend to describe failing implementations as if someone dropped something. More often, nobody did. The project slowed in a way the reporting structure was never built to notice.

Think about what a weekly status report actually asks. Is there a problem? It's a question answered by people who are mid-task, slightly behind, and reasonably confident they'll catch up — because they usually do. Three people each quietly absorbing four days is twelve days of slip that appears in nobody's report, because no individual has a problem worth raising. They have a busy fortnight.

The same applies to the client side, and this is where the industry's instinct is least useful. It's tempting to narrate a stall as the client not doing their part — data not cleansed, sign-offs not returned, testers not freed up. But look at what we actually ask of them: finish their day job, learn a system they've never seen, and make decisions about processes they've run on instinct for a decade — usually without anyone having been given time for it. When that work slips, it isn't negligence. It's an entirely predictable consequence of asking people to do a second job in the gaps of their first one.

A stall is a visibility failure before it is anything else. Nobody is hiding it. There's just no mechanism that adds up a dozen small, individually unremarkable slips and says this is now a different project than the one you planned.

The reflex that makes it worse

Once a stall becomes undeniable, there's a standard response, and it reliably compounds the problem.

Add people. Brooks wrote the definitive version of this in 1975 and it has lost none of its force: adding people to a late project makes it later. New people consume the time of the ones who were already behind.

Compress testing. Testing sits at the end, so it's the thing with apparent give. It is also the only part of the plan that tells you whether any of the rest worked. Compressing it doesn't save time — it moves the problem past go-live, where it costs several times more and lands on people who are already live.

Re-plan to the original date. A new plan is produced, arriving at the date already promised, by means nobody can quite explain. Everyone recognises what it is. The real cost isn't the plan — it's that it teaches the team that dates in this project are aspirational, which makes every subsequent estimate worse.

What these have in common is that they're attempts to avoid a conversation rather than to change an outcome.

What a restart actually needs

An honest baseline. Not percent-complete, which is the most optimistic number anyone produces. What is genuinely finished, what is genuinely started, and — the question most plans can't answer — what is unverified: work marked done by someone who has since left, or in an environment that's been rebuilt twice since. Unverified work isn't done. Counting it as done is how a restart fails for the second time.

An understanding that some finished work has expired. This is the part nearly every replan misses. If a project has been stalled for three months, some of what you completed isn't complete any more. The data migration validated in September is stale. The training delivered in August went to people who have since moved on. The UAT sign-off covers a version that's been patched twice. Work doesn't stay done while a project waits, and a restart plan that assumes it does is wrong before anyone starts.

Named root causes. Not "poor communication". Something you could actually act on: the finance lead was never given time, so every decision waits two weeks; there's no environment where anyone can test without disrupting someone; nobody has authority to close a scope question, so three of them have been open since March. Root causes you can't name are root causes you'll meet again.

A decision, made by someone with the authority to make it. Proceed, reshape or stop. This is the step projects skip, and skipping it is why so many stalls become permanent. In the absence of a decision the project continues at the pace that got it here, consuming budget, and the decision gets made eventually by exhaustion instead.

Reshaping is usually the right answer and the least popular, because it means saying out loud that some things you promised aren't happening this year. But a go-live without the warehouse module is a go-live. A project that stalls for another six months avoiding that sentence isn't.

The part that makes it stick

Whatever gets decided, write down what it was, who made it, when, and what evidence it was made against.

Not for governance theatre. Because in four months someone will ask why the warehouse module isn't live, and the difference between a project that can answer that and one that can't is the difference between a reshaped plan and a failed one. The same decision, undocumented, becomes a thing that mysteriously went missing.

---

This piece was prompted by Ganapathy Iyer's REBOOT — a book about restarting troubled projects that's worth reading if this is a situation you're in or have inherited. The framing here is my own; the nudge to write it was his.

---

ProjectPlanOS has a Recovery mode built around this sequence — assess the real position, score the factors behind the stall, record root causes, and put a proceed/reshape/stop decision in front of a sponsor with the evidence attached. It also models the expiring-work problem directly: when you plan a restart, you mark which completed tasks have to be re-run, and the schedule and cost account for it.

If you're in the middle of one of these, the honest baseline is the place to start, with or without us.