Why These Projects Fail
The technique works and most deployments produce no change. The recognisable patterns, each visible early.
Analysis
Process mining rarely fails technically. It fails by producing a detailed map that nobody acts on.
The map as the deliverable
The symptom: a beautiful discovered process, four hundred variants, a presentation, and an operation that runs exactly as before.
The cause: the project was scoped as analysis with no owner able to change the process.
The correction: define the decision the analysis will inform, before starting. If there is none, do not start.
Scoping too broadly
The symptom: eighteen months in, still extracting data.
The cause: an attempt to mine an end-to-end process across six systems as the first project.
The correction: one process, one system, one clear question, delivered in weeks.
The case identifier wrong
The symptom: a map that nobody recognises, and findings the business rejects.
The cause: the chosen case identifier does not correspond to the unit of work people think in.
The correction: validate the identifier with the operation before building anything on it.
Data quality discovered late
The symptom: findings disputed on grounds the analysis cannot settle, repeatedly.
The correction: profile the log first, document the defects and the exclusions, and report them alongside every figure.
Variant counting as a finding
The symptom: "we found 412 variants" presented as the result.
The cause: variant count is a property of granularity, not of the process. Finer activity naming multiplies it.
The correction: report what the variants cost, not how many there are.
Task mining deployed first
The symptom: resistance, works council objection, or a project halted after deployment.
The cause: a monitoring capability rolled out before anyone established what question it answers.
The correction: process mining first, name the specific gap, then a scoped and consulted task mining study.
Confusing the tool with the discipline
The symptom: a licence renewed annually, a platform nobody logs into.
The correction: ownership with allocated time, a standing operational forum, and findings tracked to closure.
No re-measurement
The symptom: improvements claimed and never verified.
The correction: the same log, the same query, the same period length, after the change — and report the null results.
The common thread
Every one of these is measuring the project rather than the process.
Systems connected, variants discovered, dashboards built — all rise while cycle time, rework and waiting stay where they were.
Reporting the process measures from the first week makes the difference visible while there is still time to correct it.
The two-day test before committing
A short screen that prevents most stalled projects.
Does a status history exist?
Does a case identifier persist end to end?
Do five hand-traced cases match the log?
Is there an owner who has named a decision they would make differently?
Is the scope one process and at most two systems?
Five questions, two days. A no on the fourth is the most common and the most fatal, and it is the one nobody checks.
Recovering a stalled project
For a project that has produced a map and no change.
Stop analysing.
Publish the four process measures: cycle time percentiles, waiting proportion, rework rate, handovers per case.
Take the single largest loss to the operation and validate it with them.
Fix one thing, re-measure from the same query, and report — including if nothing moved.
Add three compliance rules to a weekly refresh, which produces standing value cheaply.
One quarter, and it converts an analysis exercise into a programme.
Diagnosing a stalled deployment
Most stalls have one of a small number of causes, and the diagnosis determines the fix.
No question, so the output is a diagram nobody uses. Write one.
No owner able to change the process. Re-establish sponsorship with whoever controls it.
Log quality disputed, so every finding is argued rather than acted on. Fix the log and publish the checks.
Started with task mining, producing a consultation problem before any value. Step back to system logs.
Findings reported and never actioned. One finding, one owner, one date, re-measured.
Diagnose before buying more tooling, since a platform bought to restart a stalled project usually stalls with it.