Diagnosing a Stalled Programme
A short list of causes, each with a specific correction, and the recovery move for a programme that has produced maps and no change.
Analysis
Stalled process mining programmes have one of a small number of causes, and the diagnosis determines the fix.
No decision to inform
The symptom: analysis delivered, nothing changed, nobody asked for more.
The cause: the project was scoped as analysis with no owner able to act.
The correction: define the decision before the next analysis, and decline the request if there is none.
Scoped too broadly
The symptom: still extracting after a year.
The correction: cut to one process, one system, one question, delivered in weeks.
Findings rejected
The symptom: the operation says the map is wrong, repeatedly.
The cause: usually the case identifier or the boundary, occasionally a data defect.
The correction: trace twenty cases by hand with the operation present, and fix whichever it turns out to be.
Measured on activity
The symptom: reports of processes onboarded and variants discovered while cycle time is unchanged.
The correction: report the eight process measures from the first week, so the difference is visible.
Task mining first
The symptom: resistance, an objection, or a halted deployment.
The correction: process mining first, name the specific gap, then a scoped and consulted study.
The pipeline broke quietly
The symptom: numbers that have not moved in months and are still quoted.
The correction: alert on extract failure, volume anomaly and unmapped codes, and publish the data quality report on the same page as the findings.
No owner
The symptom: the project ended, the licence renews, nobody logs in.
The correction: a named owner with allocated time and a standing operational slot.
The common thread
Every failure above is a case of measuring the project rather than the process.
Systems connected, variants found, dashboards built — all rise while waiting, rework and cycle time stay where they were.
Reporting the process measures from week one is the single most effective preventive step, because it makes the gap visible while there is still time to correct it.
The diagnosis question
One question that identifies which failure you have.
Ask what changed in the process as a result of the programme, in the last quarter.
A specific answer means it is working.
"We built a dashboard" means it is measuring the project.
"We are still extracting" means the scope was too broad.
"The operation disputed it" means the identifier or the boundary is wrong.
"Nobody asked for more" means there was no decision to inform.
Each answer points at a different correction, and proposing more tooling before asking is how stalled programmes stay stalled.
What not to do about a stall
Three responses that make it worse.
Buying a bigger platform, which stalls with the programme.
Adding processes, which spreads a failing pattern.
Adding measures, which is the reporting failure applied harder.
The correction is always narrower: one process, one finding, one owner, re-measured.
And frequently it requires admitting that the original scope was wrong, which is the actual obstacle rather than any technical one.
The recovery move
For a deployment that has produced diagrams and no change.
Publish the baseline: duration percentiles, waiting proportion, rework rate, variant count.
Pick the largest single loss and fix it, with the process owner involved from the start.
Re-measure from the same log definition and report, including if nothing moved.
Fix the log quality and publish the checks, which removes the standard objection.
One quarter of work, and it converts an analysis exercise into a programme.