Requirements carry the most weight
At 24 points, it is the largest single item, because unsettled requirements were the primary cause in 31% of the stalled projects we examined — more than any other factor.
Free tool
Seven questions, weighted by how often each condition turned out to be the primary cause across forty-one stalled implementations we were brought into. Three of them account for nearly two-thirds of the score, and all three are decided before configuration starts.
Tell us where it is and what has slipped. We will tell you honestly whether it is recoverable.
Largest exposures
Tick only what is genuinely true today. A score built on what you intend to do rather than what you have done is worse than not scoring at all.
How to read it
The number matters less than which items are unticked, because the weights reflect how often each one was the difference between a project landing and stalling.
At 24 points, it is the largest single item, because unsettled requirements were the primary cause in 31% of the stalled projects we examined — more than any other factor.
At 20 points and rarely on anyone’s risk register. A sponsor who attends every meeting and cannot decide across departments is a bottleneck with a title.
It means the conditions that predict failure are largely absent. The remedy is to stop configuring and fix the foundation, which feels like losing time and is faster than the alternative.
They are the inverse of the primary causes in our stalled-project sample. Requirements never settled, data worse than anyone knew, no internal owner with authority, customisation replacing process change, partner capacity, and — rarest by some distance — the software genuinely being incapable.
The weights are that distribution, adjusted so the three conditions that precede configuration carry roughly two-thirds of the score. That reflects what the sample shows: 74% of stalled projects failed for reasons that existed before anyone configured anything.
“Requirements were derived from transactions, not only interviews.” Almost every project has a requirements document, so the instinct is to tick it. The question is whether the requirements were checked against what the data actually shows happens.
What people say they do and what their transactions show they do diverge more than anyone expects, and the divergence surfaces during configuration as a series of small surprises that each reopen a settled decision. By the fourth or fifth, the schedule has absorbed its slack.
Not the vendor. Changing vendors after a failure addresses about a quarter of the actual risk, because requirements, data, and authority all transfer intact to whoever comes next.
What it should change is sequence. Stop configuration, examine the data properly, derive requirements from transactions, and name someone who can make cross-departmental decisions within a day. Of the 27 stalled projects we recovered, nearly all of them started that way, and the average recovery took eleven weeks.
Check whether the answers are optimistic. The most common failure of self-assessment here is ticking an item because it is planned rather than done — the data assessment scheduled for next month, the decision-maker who has been asked but not confirmed.
A useful test: for each ticked item, name the artefact. The transaction analysis, the diagnostic report, the written delegation of authority. Items without an artefact are usually intentions.
Weights derive from primary-cause analysis across 41 stalled or failed deployments we were brought into between January 2024 and June 2026, published in full on our failure modes page.
Primary cause is our assessment after access to the project record, the data, and interviews — not the cause recorded in the project post-mortem, which in our experience skews toward the software and the partner and away from internal decision-making.
The sample is self-selecting toward severe failures, since these are projects that went badly enough for somebody to call an outside party. It over-represents bad outcomes and says nothing about the base rate of success.
Band thresholds — 78 and 52 — are our judgement rather than a statistically derived cutoff. Treat the score as a ranking of your own exposures rather than as a probability.
Questions
Requirements from transactions, data examined properly, and someone who can decide across departments.