Designing the Category List

More project codes produce worse data, not more detail. The category list is a usability decision before it is a reporting one.

The failure

Hundreds of codes, organised by a structure that made sense to finance.

People cannot find the right one, so they pick a plausible one.

Plausible-but-wrong entries are worse than coarse-but-right ones, because they look precise.

And the reporting built on them is confidently misleading, which is the expensive outcome.

How many

Someone should be able to hold their own list in their head.

Which for most roles means under twenty active options at any time, not the organisation's full catalogue.

Filter by what is relevant to the person: their projects, their team, their recent entries.

The full structure can be large; the list any individual sees should not be.

The two dimensions

Most organisations need both and conflate them.

What the work was for: project, client, product, matter.

What kind of work it was: delivery, rework, meetings, supervision, administration, support.

Recording both is a small extra cost and it is where most of the useful findings come from. Effort by project answers the costing question; effort by type answers the improvement question.

Keep the second list short and stable. Six or seven types, unchanged for years, so trends are comparable.

Naming

Use the words people actually use, not the accounting name.

Avoid abstractions. "Value-added activity" produces guessing; "reviewing someone else's work" does not.

Make the boundaries explicit where they are contested: is scoping delivery or business development, is a status meeting delivery or administration. Write the answer down once rather than letting every person decide.

Test the list by asking three people to categorise the same ten real entries. Disagreement is the signal that the definitions are not usable.

Maintenance

Close finished projects. A list that only grows becomes unusable within two years.

Review the "other" or "general" rate. A dominant catch-all means the list does not fit the work.

Add categories reluctantly and always by asking what decision the new one informs.

Archive rather than delete, so historical data remains interpretable.

The retrospective problem

Changing the structure breaks comparison with history.

Which is a reason to get the activity-type list right early and leave it alone, since that is the dimension used for trends.

Project codes can churn freely, because those comparisons are within a project rather than across time.

Where a structural change is necessary, map old to new and keep the mapping, or the previous years become unreadable.

What to check

Proportion of time recorded to a catch-all category.

Agreement between people on the same work, tested occasionally.

Number of active codes per person, which should be small.

Entries with a category that the project does not permit, which indicates the list is confusing rather than that people are careless.

Testing the list

Ten minutes that catches an unusable structure before it is deployed.

Write ten real scenarios from actual work.

Give them to three people to categorise, independently.

Measure agreement.

Disagreement means the definitions are not usable, which is a finding about the list rather than the people.

Fix the ambiguous boundaries and write them down — is scoping delivery or business development, is a status meeting delivery or administration.

Repeat when the structure changes.

Protecting the trend dimension

One list should churn freely and the other should not.

Project codes can change constantly, because comparisons are within a project.

Activity types should be stable for years, because that is the dimension used for trends across time.

Six or seven, unchanged, with the boundaries written down.

Where a structural change is unavoidable, map old to new and keep the mapping, or every prior year becomes unreadable.

Mark the break on any chart that spans it.

Turn the principle into a test

For an example that can make this requirement testable, consult open the field-mapping example. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, exceptions and permissions before relying on the result.