Choosing What to Fix First

The measurement phase produces more findings than anybody will act on. Ordering them properly is the difference between a programme that changes things and one that reports.

The recommendations in “Choosing What to Fix First” need visible ownership, review time and a way to show whether the change reduced effort for the affected group. An organisation can use this time-management reference 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 Nielsen Norman Group; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

The two questions

How much total time does this cost, across everybody affected?

How much effort is the fix?

Score each roughly and the ordering falls out. Nothing more sophisticated is needed and anything more sophisticated does not get done.

Total time, not severity

The instinct is to start with the worst individual experience.

But four minutes a day for two thousand people is a far larger figure than an hour a week for five.

Rank by population multiplied by frequency multiplied by duration.

This ordering usually differs sharply from the complaint ordering, because the loudest complaints come from the most vocal rather than the most affected.

The quadrants

High time, low effort: do these this month. Logins, startup applications, an approval threshold, uninstalling unused software.

High time, high effort: schedule these. Hardware refresh, application replacement, process redesign.

Low time, low effort: do when convenient.

Low time, high effort: write them down as declined, so they stop reappearing and generating guilt.

Starting with the cheap ones

Not because they matter most, but because they build the case.

A programme that has visibly fixed three things in two months gets the authority to attempt the expensive ones.

One that starts with a hardware refresh business case spends six months in procurement with nothing to show.

The things to do regardless

Replacing the worst hundred devices.

Removing never-opened software.

Auditing group policy.

Each is cheap, each affects a known population, and each is defensible without further analysis.

Declining explicitly

The list will contain things not worth fixing.

Write them down with the reason rather than leaving them open.

A visible declined list is better than a silent backlog, because people stop re-reporting and the programme stops looking unresponsive.

Revisiting

After each fix, and whenever the organisation changes.

New applications and new policies generate new friction continuously, so the list regenerates.

The question is whether you are closing faster than new items arrive, which is worth tracking as a number.

What to check

Is your list ordered by total time or by severity?

What have you fixed in the last quarter?

Is there a written declined list?

And are you closing faster than new findings arrive?

The point

Rank by population times frequency times duration, not by severity.

That ordering usually differs sharply from the complaint ordering.

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.