The Implementation Has Stalled. Now What?

Nobody announces that a project has stalled. There is no meeting where it is declared. What happens instead is that the go-live date moves for the third time, the steering committee starts sending delegates, and a phrase appears in the status report that was not there before — usually "pending business input" or "awaiting clarification".

Then the reporting goes quiet in a particular way. The percentage complete stops moving but stays above eighty. The risk register has the same five items it had in March, all amber, none escalated. Somebody asks for a revised plan and receives one with the same shape as the last, shifted right.

By the time the word "stalled" is used out loud, the project has usually been stalled for two months. The useful question at that point is not who is to blame. It is which of four things is actually wrong, because there are only four, and the remedy for each is different enough that applying the wrong one costs you another quarter.

Stop the project for two weeks first

The instinct when a project slips is to add: more consultant days, more meetings, another workstream lead, a recovery plan with more detail than the plan that failed. This is almost always wrong, and it is wrong for a specific reason. A project that has stalled is producing very little value per day, and adding resource to a system that is not moving increases the burn rate without changing the constraint.

Stop it. Formally, in writing, for two weeks, with the vendor's clock paused and stated as such. Two weeks is long enough to find out what is true and short enough that nobody's nerve fails.

During those two weeks, three things get produced, and nothing else.

An honest inventory of what actually works. Not what is configured. What a real user could do tomorrow, end to end, with real data, without help. Test it by sitting a person down and watching. This list is almost always shorter than the status report suggests, and it is the only reliable baseline you have.

A written statement of the original problem. Go back to the business case and find the sentence describing what the company could not do. If nobody can find it, or it turns out to have been "improve visibility", you have already found a large part of your answer.

A diagnosis against the four causes below. One page. Written by someone who is prepared to be unpopular.

The stop has a second effect worth as much as the diagnosis. It converts an ambient sense of failure into a decision point with a date. Everybody has been avoiding a conversation for months, and most of what you need to know surfaces in the first three days simply because people are finally allowed to say it.

The four causes, and how to tell them apart

The symptoms overlap badly, which is why diagnosis by feel produces the wrong answer so often. Each cause has a test that does not rely on anyone's opinion.

A scope problem

The symptom. The project is not late on anything specific. It is late on everything slightly, and the list of requirements is longer now than it was at contract signature.

The test. Take the requirements list from the contract and the current one. Count both. Then take the current one and mark each line with the name of the person who will accept it at go-live. Count the unowned lines.

If the list has grown substantially and a meaningful share of it has no named owner, the project is not late. It is delivering a larger thing than the one that was scheduled. Nobody decided this; it accumulated, one polite yes at a time, because refusing a colleague's request in a workshop is socially expensive and accepting it is free until month seven.

The related tell is the phrase "phase two" being used to end arguments rather than to schedule work. If phase two has no date, no budget and no owner, it is not a phase. It is a place where difficult items go to be forgotten, and the items in it will return during user acceptance testing.

What it looks like when misdiagnosed. Scope problems are routinely reported as vendor performance problems, because the vendor is visibly behind. Firing the vendor moves the same oversized scope to a new team who will also be behind.

A data problem

The symptom. Configuration is broadly finished. Testing keeps failing for reasons that are described as data issues and treated as clerical. The go-live date moves in one-month increments, each time for a reason that sounds temporary.

The test. Ask for the reconciliation from the most recent full-volume trial load. Not a sample. Full volume, with control totals: record counts, trial balance, receivables, payables, stock value, source against target.

Three possible outcomes, and all three are informative. If the reconciliation exists and balances, data is not your problem. If it exists and does not balance, you know the size of the gap. If no full-volume trial load has ever been run — which is the most common answer at this stage — then nobody in the project knows whether cutover is achievable, and the dates that have been slipping were always guesses.

Ask one further question: who signed off each master data domain, by name. If the answer is IT, or a consultant, or nobody, the sign-offs mean nothing, because the reason data kills projects is not technical difficulty. It is that only the business can say whether two records are the same customer, and only the business will live with the answer.

What it looks like when misdiagnosed. Data problems are reported as testing problems. The remedy applied is another testing cycle, which fails in the same place, because the defects being logged are not defects.

A people problem

The symptom. The system works in the demonstration environment and nobody is using it. Attendance at workshops has thinned. Key users send juniors. Somewhere, a spreadsheet has appeared that mirrors what the system is supposed to do.

The test. Two questions, asked of the same three people separately. First: what will you personally do differently the week after go-live? Second: what have you stopped doing because the project needs your time?

If the first question gets a vague answer, the change has not been made real for the people who have to make it. If the second gets "nothing", the organisation has asked its best people to add a project to a full week, and they have quite rationally chosen their day job.

There is a third signal worth looking for, and it is often misread. The people resisting hardest are frequently the ones who understand the current process best. Their objection is usually specific, correct and unwelcome, and it has been categorised as resistance because that is easier than answering it. Read the objections that were logged and closed without a response. There is diagnostic gold in there.

What it looks like when misdiagnosed. People problems are reported as training problems. More training is delivered to people who understood perfectly well and disagreed.

A vendor problem

The symptom. Answers arrive slowly and change. The consultant you met at the demo has not been seen since kickoff. The people on your project seem to be learning the product on your time. Documentation of what has been configured does not exist.

The test. Ask three questions in writing and judge by the response, not the content.

Who is assigned to this project, at what percentage of their time, for the next eight weeks? Show me the configuration documentation for the finance and inventory design as it stands today. What is the list of open items on your side, with owners and dates?

A capable partner produces all three within a few days, because all three exist already. A struggling one produces a meeting invitation. The distinction is reliable, and it is a distinction about competence rather than intent — most partners in this position are not acting badly, they are under-resourced and hoping the situation improves.

There is a harder version of the vendor question that has to be asked separately: is this partner capable of this project, or was it always beyond them? A team can be diligent, responsive and pleasant and still be out of their depth in your sector, and no amount of goodwill closes that gap. The evidence is whether they have ever delivered something comparable, in your industry, at your complexity. If the honest answer is no and it was no at signature, the selection failed, not the delivery.

What it looks like when misdiagnosed. Vendor problems are reported as scope problems, by the vendor, and the buyer accepts this because it is flattering to neither side and therefore sounds neutral.

The mixed case, which is most of them

Real stalls are rarely pure. The common pattern runs in a specific order and is worth recognising, because it tells you where to intervene.

A governance vacancy comes first: nobody with authority is available weekly to settle small questions. Decisions queue. The vendor, needing to keep moving, makes assumptions. Those assumptions surface later as defects, which are reported as vendor performance. Meanwhile the queue of undecided items grows, and because deciding is slow, requests get accepted rather than argued about — so scope grows too. Data work, which needs sustained business attention, gets deprioritised because the business is busy answering the decision queue. By month seven all four symptoms are present and the argument about which is the real cause is unresolvable.

In that pattern, the constraint is the first one, not the loudest one. Fix decision latency and the other three become tractable. Fix the others while decisions still take five weeks and you will be back in the same place by the next quarter. This is the practical reason governance is worth setting up before anyone configures anything: it is the only intervention that makes the other remedies work.

Rescue, restart or walk away

Once the diagnosis is written, the decision is one of three. The mistake is treating this as a matter of resolve. It is a matter of what is salvageable.

Choose	When these are true	What it costs	What it risks
Rescue	The product genuinely fits, a usable core exists, the data has a path, and you can supply the governance	Time and internal attention more than money	Sunk-cost momentum carrying the original scope back in through the side door
Restart	The product fits but the design does not, or the implementation was never documented and cannot be reasoned about	Most of the configuration effort, rarely the licences or the data work	Restarting with the same team, the same scope and the same governance
Walk away	The product cannot do the core of what the business needs, or the partner cannot deliver and no replacement will inherit the build	The services spend, some of the licence commitment	Repeating the selection error, faster, because everyone is now in a hurry

Three tests help make the choice concrete rather than emotional.

The core transaction test. Can your single highest-volume transaction be completed, correctly, end to end, on real data, by a real user, today? If yes, there is something to rescue. If no, and it has never been true, ask whether anyone has ever seen it work in this product at your complexity.

The documentation test. Can a competent consultant who has never seen this project understand the current configuration from what is written down? If not, a rescue is really a restart with the old system still installed, and it should be priced and planned as one. Undocumented configuration is not an asset; it is a liability that looks like progress.

The fit test. Separate the failures that were caused by how this was implemented from failures caused by what was bought. A product that cannot represent your commercial model will not start being able to under new management. This is the boundary between a delivery problem and a selection problem, and confusing the two is how companies spend a second budget proving the first conclusion.

Walking away carries the most stigma and is occasionally the cheapest option on the table. The relevant arithmetic is not what has been spent but what remains to be spent, against the value of what you would get. Money already gone appears on both sides of that comparison and cancels out, however strongly it does not feel that way in the room.

If you rescue, rescue like this

A rescue is a different kind of project from the one that stalled, and it fails when it is run as a continuation.

Cut the scope to something that can go live. Not the ideal system. The smallest configuration that lets the business run and that solves the original problem statement. Everything else moves to a phase with a date and a budget, or it is refused honestly. If the resulting first phase does not fix the sentence in the business case, you have cut the wrong things.

Re-baseline the plan from evidence, not from the contract. The old plan is not recoverable. Build the new one from the working inventory produced during the pause and from measured throughput, not from what should have been possible.

Fix the decision machinery before anything else. One named person per process, with authority. A standing weekly hour with someone who can settle anything that has queued. A written record of what was settled. Track decision latency in working days and put it on the front page of the report — it is the earliest reliable indicator of trouble and it moves months before any milestone does.

Run a full-volume data rehearsal within the first six weeks. Whatever else is uncertain, this converts the largest unknown into a number. Everything about cutover planning downstream depends on it, including whether the date you are about to announce is a plan or a hope.

Give the customisation register a hard review. A stalled project usually contains code that was added to avoid a decision. Each line should have a business fact justifying it; the ones that do not are the cheapest scope to remove, and removing them makes the upgrade path recoverable. The judgement involved is the one described in telling configuration, customisation and building apart, applied in reverse to work already done.

Rebuild credibility with something visible. Ship one thing to real users within weeks, however small. A stalled project has trained the organisation to expect nothing, and only working software changes that. Announcements do not.

Budget the rescue honestly. The recovery has a real cost, and it lands in the same underestimated places as the original — data, internal staff time, the second training round. It is worth re-reading where implementation money actually goes before writing the number that goes to the board, because a rescue budget that repeats the original omissions stalls in exactly the same way.

Before you set the new date

The single most common failure in a rescue is announcing a go-live date to restore confidence, and then defending it after it stops being achievable. A date that has to be defended stops being a plan and becomes a reason to skip the rehearsals, the reconciliations and the training that would have made it work.

Set the date from evidence: from a completed full-volume trial load, from a core transaction that a real user has performed unaided, from a reconciliation that balances. Before you commit it publicly, run the same readiness questions a competent reviewer would ask — the go-live risk check walks through them in the order they usually break, and an honest half hour with it is considerably cheaper than a cutover weekend that has to be reversed.

Then hold one gate meeting with a real answer available. Not "are we ready", which is a question nobody wants to be the first to answer badly, but "what specifically would break if we went live on Monday". Write down every answer. Do not filter. That list is your remaining plan, and if it is short, you have your date.

The uncomfortable part

Most stalled implementations were diagnosable in month three. The signals were there: decisions queuing, a data workstream nobody had staffed, a scope list growing without a corresponding change to the plan. They were not acted on because acting on them required somebody to say something unwelcome to somebody senior, and the reporting format made it possible to avoid that for another fortnight, and then another.

The practical lesson is not about heroics. It is that project reporting built on milestones and percentage complete will stay green until the moment it cannot, and that a small number of leading measures — decision latency, trial loads completed, defects reopened, steering attendance by the named members rather than delegates — will tell you months earlier and cost nothing to collect. The projects that get rescued cheaply are the ones where someone was watching those numbers and was allowed to say so. The rest get rescued expensively, or not at all. That distinction is the practical case for reading the leading signals rather than the milestone report, from week one rather than from the quarter it becomes unavoidable.

If a project has stopped moving and you want an independent read on which of the four causes you actually have, that written diagnosis is the first thing we produce, and how we go about it is public before anything is quoted.