The Code List Nobody Maintains

Open the code picker in any timesheet system that has been running for five years. There will be hundreds of entries, most of them dead, several of them near-duplicates, and at least one pair that differ by a space.

The record described in “The Code List Nobody Maintains” should be created close enough to the work that people are not reconstructing a polished week from memory. When teams assess view the solution for step rate compensation, they should keep entry, project selection and correction simple, while explaining which optional activity data is collected and how employees can review it.

The person recording their week has to choose from this. What they choose is what the organisation then uses to price work, bill clients, claim funding and decide what to do next, and the quality of that decision is bounded by the quality of the list.

For a separate benchmark relevant to “The Code List Nobody Maintains”, consult the ISO management-system resources. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

How lists decay

Codes are created freely and retired never. Creating one takes a request; retiring one requires knowing it is finished, which nobody tracks, and carries a risk of breaking a report, which nobody wants to own.

They are also reused. A code for a 2021 engagement gets picked up for a 2024 one with the same client because it is already there, and three years of unrelated history now sit under one identifier. Reporting on it produces a figure that is wrong in a way nothing will flag.

And they multiply at the edges. The same activity appears as Support, Client support, Support — BAU and Supt because four people needed a code on four different days and nobody checked.

What the state of the list does to behaviour

A long list is unusable from memory, so people search, and search returns the first plausible match rather than the right one. A list with near-duplicates distributes identical work across several codes, so no single figure is complete. A list with no code for a real activity pushes that activity onto the nearest wrong code.

The effect compounds: the longer the list, the more people default to whichever code they used last week, which is how a person who changed projects in March is still booking to the old one in July.

The measurements worth taking

Count active codes and compare it with codes used in the last quarter. A ratio of ten to one is common and tells you the picker is ninety percent noise.

Count how many codes account for eighty percent of hours. It is usually a small number, and it is the list people actually need. Count codes used exactly once — those are either mistakes or genuine one-offs, and either way they should not be in the picker. Look for near-duplicate names with a simple string comparison; the results are usually embarrassing and quick to fix.

And count entries against codes closed before the entry date. Every one of those is a control that should exist and does not.

Maintaining it

Give every code an owner and an expected end date at creation. The end date can be wrong; what matters is that something expires and prompts a decision rather than persisting silently.

Hide rather than delete. Retired codes must remain valid for historical records and must not be selectable for new entries, and most systems support this distinction even when the implementation did not use it.

Personalise the picker. Show the person the codes they are assigned to and the ones they used recently, with the full list behind a search. This single interface change does more for allocation accuracy than any amount of training, because it removes the opportunity for the wrong choice rather than asking people to avoid it.

Review quarterly, as a twenty-minute job for one person with the five numbers above in front of them. Annual reviews do not happen and monthly ones get skipped.

The structural question underneath

Most code lists are long because they serve several purposes at once: billing granularity, internal cost attribution, project reporting and funder work packages all pushed into one dimension.

Where the system supports more than one dimension — a project plus an activity type, say — using two short lists instead of one long one is a substantial improvement, and most organisations have the capability and have never turned it on. Where it does not, the honest move is to decide which single purpose the list serves and stop asking it to serve the others, because a list trying to answer four questions reliably answers none.

Who owns a code

Most lists have no owner per code, which is why nothing is ever retired. Attaching a named person to each one at creation changes the economics: there is somebody to ask whether it is still live, and somebody to whom a question about miscoding can be addressed.

The owner does not have to do anything most of the time. What they provide is an address. A code with no owner is a code where every question about it goes to the system administrator, who knows how the picker works and nothing about whether this engagement finished in March.