BuzbyTimeRead the requirements guide

Getting people to record · 1.6

Adoption decays, and what to watch

Adoption decays, and what to watch. What decides it, what it costs, and what usually goes wrong. For another implementation reference, see the Monitask overview.

Adoption decaysThe pattern

Completion is highest in month two and drifts afterwards. This is not a failure of will: the novelty passes, the person who championed it moves on, a new starter is never told why, and a category stops fitting.

Every one of those is addressable and none of them announces itself. Teams comparing the wider operating context can also consult Asana.

Four things to watch

  • Entries made the same day, as a proportion. The first thing to slip.
  • Use of the catch-all category, rising.
  • Corrections, falling to zero, which usually means people have stopped reading their own records.
  • New starters, whose completion tells you whether induction covers this.

None is a target. Each is a prompt to ask what changed.

Induction

New people learn how this works from whoever sits near them, which means they inherit that person's habits including the bad ones. Ten minutes in induction, from somebody who can explain why rather than which button, is the cheapest maintenance available.

The annual review of the whole thing

Once a year, ask: what did this answer, what did it cost in people's time, and are the categories still right.

Organisations rarely stop doing something that has stopped being useful, because nobody has the standing to propose it. Putting the question in a calendar gives somebody that standing.

When to record less

A legitimate outcome. If the record answers one question and is collected at ten levels of detail, drop the levels that answer nothing. Precision nobody uses is a cost paid daily by the people entering it.

Reducing what is asked for is also the strongest possible signal that the data is for a purpose rather than for its own sake, and teams notice.

The honest summary of this part

Adoption is not a persuasion problem. It is a design problem with four parts: cheap entry, sensible categories, something coming back, and nobody being measured against it.

Get those right and completion looks after itself. Get them wrong and no amount of reminding, escalation or gamification will produce a record worth reading.

The champion leaves

Most decay traces to one person moving on. Whoever introduced it answered the questions, fixed the categories and explained why, and none of that was written down.

Write it down while they are still there: the categories and their reasoning, what the data is for, who to ask. A page.

A new team arrives

An acquisition, a new department, a new site. They inherit a system with categories designed for somebody else and no explanation, and their entries will show it.

Treat each as a small rollout rather than an account provisioning exercise.

When to stop

If the honest annual review finds the record answering nothing, stopping is a legitimate decision and it is almost never taken. Somebody should have the standing to propose it, and a supplier worth having will say so too.

The quiet drift in categories

Work changes and categories do not. Within a year some describe things nobody does and others cover half the business. The catch-all grows, and the reports built on the old structure quietly stop meaning what they meant.

An annual review catches this. Nothing else does, because the drift is gradual and no single week looks wrong.

Reporting back is the maintenance

The monthly summary to the team is not a courtesy; it is what keeps completion up. People who see their data used keep producing it, and people who never see it again conclude it goes into a drawer.

A note on this whole part

Everything here is cheap. Cheap entry, a sensible list, something coming back, nobody ranked. None of it is a feature somebody sells, and together they decide whether any of the rest of this site matters.

What to do first

Put the annual review in a calendar now, with a named owner. It is the only mechanism in this part that survives the person who introduced the system leaving.

The signal that it has stopped mattering

Nobody asks about the numbers. No decision references them. The monthly summary stops being sent and nobody notices.

When that happens, either find the question the record should be answering or stop collecting it. Continuing to collect data nobody uses is a tax on everybody's day with no offsetting benefit, and it is astonishingly common.

A closing thought

Nothing here survives without somebody owning it. Not a committee: a person, with the time allocated and the standing to propose stopping.

Ownership after the project ends

Most implementations have a project owner and no operational one. When the project closes, the categories, the questions and the monthly summary become nobody's job, and the decay described here begins immediately.

Name the operational owner before the project closes, with the time allocated in their objectives. It is a line in a document and it is the difference between a system that lasts and one that is replaced in three years by somebody who concludes this kind of software does not work.

A last observation

Systems of this kind are rarely abandoned deliberately. They fade: completion drifts, the summary stops, the categories rot, and eventually somebody proposes replacing a system that was never actually being used.

The replacement then fails the same way, because nothing that caused the first decay was addressed.

Handing it to somebody new

Give them the category list with its reasoning, the questions the record answers, the monthly summary and the annual review date. Four things, on one page, and they are what the role actually consists of.

Also in getting people to record