Project Attribution

Recording that someone worked eight hours is one requirement. Recording which of six things they worked on is a different one, and products vary more here than anywhere else.

What it has to support

A list a person can hold in their head, filtered to their own work rather than the organisation's full catalogue.

Two dimensions: what the work was for, and what kind of work it was. Most organisations need both and record only the first.

Splitting a period across several codes without re-entering the times.

Recent and frequent items first, since most entries repeat.

Entry from where the work happens — the ticket, the calendar, the phone — rather than a separate system.

The structure questions to ask a vendor

How deep can the hierarchy go, and can a person be restricted to a branch?

Can a code be closed to new entries while historical entries remain valid?

Is a retired code blocked from reuse? Reuse silently corrupts every historical report and should be impossible by configuration.

Can the list differ by person or team?

Effective-dated hierarchy, for a cost centre that moved mid-year. Most products cannot, and the workaround is a parallel set of codes.

The activity dimension

Delivery, rework, meetings, supervision, administration, support.

Six or seven options, stable for years, because this is the dimension used for trends across time.

Short and unchanging, unlike project codes which churn freely.

Where a product supports only one dimension, you will end up encoding activity into project codes, which produces a list nobody can navigate.

Where it goes wrong

Hundreds of codes visible to everyone, so people pick something plausible. A plausible-but-wrong entry is worse than a coarse one because it looks precise.

Mandatory narrative on every entry, which is a reason to postpone.

No way to split a day, so the whole day goes to whichever code was largest.

A list that only grows, because nobody closes finished projects.

Testing it

Give three people the same ten real scenarios and compare their coding. Disagreement means the definitions are unusable, which is a finding about the list rather than the people.

Time a normal week's entry in the trial.

Count how many options a typical person sees. If it is more than twenty, ask how it is filtered.

Check what the catch-all rate looks like in a reference customer's deployment, which vendors can sometimes tell you and which is diagnostic.

Two dimensions, one stable

The design decision that determines whether trends are possible.

Project codes churn freely, 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 product supports only one dimension, activity gets encoded into project codes and the list becomes unnavigable within two years.

Trace time to the project output

For an example of how a vendor frames project attribution, review this project page. The pilot should still prove code closure, corrections and export behaviour with your hierarchy.