BuzbyTimeRead the requirements guide

Getting people to record · 1.2

Choosing the categories

The list somebody picks in week one governs everything the record can later answer. For another implementation reference, see the Monitask overview.

The categories are the whole designThe decision that governs

Everything a time record can later answer depends on the list somebody chose in week one. Too few and the data says nothing; too many and entries land wherever the person gave up.

The workable number for most teams is between six and twelve at the top level. Beyond that, people stop reading the list and pick from the first three. A useful outside reference is monday.com.

Who should choose them

The people who will use them, in one session, with whoever needs the output in the room to say what it must support.

That conversation is an hour and it prevents the commonest failure, which is a list that is correct from an accounting perspective and unusable at the moment of entry.

Three tests for a category list

  • Can somebody choose in two seconds without reading all of it?
  • Does every plausible hour have an obvious home?
  • Would two people categorise the same work the same way?

The third is the one that fails. Test it before launch by describing five real pieces of work and asking three people to categorise them independently.

The catch-all

Every list needs one, and it is the most informative category you have. Hours landing in it are hours the list does not describe, and a growing catch-all is the signal to revise.

What it must not be is a punished category. If choosing it invites a question, people will pick something else and the signal disappears.

Changing them later

Expensive, because historical comparison breaks. Which is an argument for spending the hour at the start and for revising deliberately at a period boundary rather than continuously.

When you do revise, keep a note of what changed and when. A year later somebody will ask why a category jumped, and the answer is usually that its definition moved.

Depth

Two levels is almost always enough: a category and a thing. Three-level hierarchies are built by people designing reports and abandoned by people entering time.

Client, project, task: which of the three

Most teams need two of these and configure three. Establish which questions the record must answer, and then include only the dimensions those questions need.

A third dimension added because it might be useful later is paid for at every entry by everybody, forever, and is almost never used in the report it was added for.

Billable as a property, not a category

Whether an hour is billable is generally a fact about the work and the contract rather than a category somebody chooses. Deriving it from the project rather than asking removes a decision from the entry moment and removes an argument later.

Naming

Use the words the team already uses, including the informal ones. A category named as it appears in the accounting system will be mis-picked by everybody who does not work in the accounting system.

Map to the accounting names in the report rather than at the point of entry.

Testing the list before launch

Describe five real pieces of work and ask three people to categorise them independently. Disagreement identifies exactly which definitions are unclear, and it costs half an hour.

Almost nobody does this, and almost every list has at least one category two people read differently.

Codes people can say out loud

On a site or a floor, a code has to be sayable across noise. Numeric codes work in a system and fail in a conversation, which matters because the conversation is how a supervisor tells somebody what to put down.

Keeping the list short as things grow

Lists grow by addition and never by subtraction, because removing a category is somebody's project disappearing. Review annually with a rule: anything under one per cent of hours merges into its parent.

What to do first

Write the questions the record must answer, in one list, before designing anything. Every category then either serves one of them or does not exist.

Two lists that must agree

The categories people enter against and the categories finance reports on. Where these differ, somebody translates monthly, the translation is undocumented, and it breaks when they leave.

Agree one mapping, write it down, and automate it. This is an afternoon at setup and a recurring cost forever if skipped.

Projects that end

Closed projects should stop appearing in the picker and remain in the history. Lists that only grow become unusable within two years, and the fix is archival rather than deletion.

An example list that works

For a professional services team: client work, internal projects, business development, administration, training, absence, and one catch-all. Seven, chooseable in a second, and every plausible hour has a home.

Yours will differ and the shape should not: a handful, unambiguous, with somewhere for the unexpected.

A closing thought

Spend the hour. Everything the record can ever tell you was decided in it, and no amount of reporting sophistication recovers a list that people cannot use.

Sub-categories, and when they earn their place

A second level is worth having when a first-level category regularly exceeds a fifth of all hours and somebody needs to know what is inside it. Below that threshold it adds an entry decision for no answerable question.

Introduce them one at a time, into the category that needs them, rather than designing a symmetrical hierarchy. Symmetry is a property of diagrams and not of work.

Also in getting people to record