When the Programme Stalls
The predictable plateau at around year one, why it happens, and the three ways out.
Programme · Analysis
Most DEX programmes make visible progress for a year and then stop. The pattern is consistent enough to anticipate.
The recommendations in “When the Programme Stalls” need visible ownership, review time and a way to show whether the change reduced effort for the affected group. An organisation can use the workflow note to coordinate that implementation work and compare workloads, without treating hours or activity as a complete measure of digital employee experience.
For an independent benchmark, compare this approach with Microsoft WorkLab; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.
The shape of the stall
The technical findings are fixed: devices replaced, logins improved, crashing applications addressed.
The remaining findings belong to other teams.
The dashboard still runs and nothing changes.
Reporting becomes a monthly recital of unchanged figures, and attention drifts.
Why it happens
The easy wins were inside the programme's authority and they are finished.
The next tier requires process owners who have their own priorities.
And the programme has usually not built the mandate to reach them, which the ownership note covers.
The first way out: widen the mandate
Take the quantified process backlog to a sponsor above the functions involved.
The argument is strongest immediately after the technical wins, with evidence in hand.
Leaving it eighteen months weakens it, because the programme by then looks like something that has run its course.
The second: go deeper technically
There is usually more in the estate than the first pass found: application-level transactions, remote experience, meeting quality, specific role workflows.
This keeps the programme useful without needing anybody else's cooperation.
It is a smaller ceiling and it is real work.
The third: narrow and embed
Stop running a programme and make the measures part of normal operations.
Login time becomes a standing operational metric with an owner. Crash rates go into the application lifecycle. Ticket cause review becomes a monthly habit.
The programme ends and the practice continues, which is a legitimate and under-considered outcome.
The failure mode to avoid
Keeping the platform and the reporting with nobody acting on it.
This is the common outcome: licences renewed annually, dashboard unopened, agent on every machine collecting data for nobody.
If that is where you are, either restart with a decision or decommission.
Deciding which
If process findings are large and a sponsor is plausible, widen.
If not, and the technical surface is unexplored, deepen.
If both are exhausted, embed and close.
Making that call deliberately is better than the drift, and it is the kind of decision programmes avoid because closing looks like failure.
What closing well looks like
Measures handed to owners who will keep them.
The platform either justified by its ongoing proactive use or removed.
A written account of what was fixed and what remains.
And telling people the monitoring has stopped, if it has, which is as much a courtesy as telling them it started.
What to check
Is your programme still fixing things, or reporting?
When did it last change something?
Which of the three routes applies?
And if the answer is to close, has anybody said so?
The point
Programmes plateau at about a year, when the findings inside their own authority run out.
Widen the mandate, deepen technically, or embed and close.
Underlying all of this
Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.
The recurring pattern
The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.