Define Clear Statuses

Statuses look like the easiest part of this guide and produce more bad reports than anything except missing dates.

The failure is rarely that a status is wrong. It is that two of them overlap, so which one a record lands on depends on who touched it last, and the report is then counting the habits of individual people rather than the state of the work.

Three properties

A usable status set is mutually exclusive, so no record could reasonably be two of them at once. It is collectively exhaustive, so every record is one of them and nothing falls through into a default nobody chose. And each value has one meaning, which is stricter than it sounds: if you have to ask a colleague what a value means and their answer starts with “well, it depends”, it fails.

The practical way to check is to take twenty real records and place each one. The values people argue about are the ones to fix.

The blank bucket is a finding, not a segment

When you group by a field and a large share of records come back blank, that is not a category. It is data quality surfacing inside a report.

Label it as such. A breakdown showing “unspecified” alongside real categories invites everyone to reason about it as though it were one, and it is not: it is a mixture of every other category plus some records that genuinely have no value, in unknown proportions.

One set per population, when the populations differ

A status set that is correct for one kind of record can be systematically wrong for another. If one population moves through stages on momentum and another moves through the same stages on a calendar, a status meaning “stalled” in the first means “behaving normally” in the second. Every report that groups them together will now report the second population as failing, permanently, for doing exactly what it should.

The fix is not a tuned threshold. It is a separate status treatment for the second population, and saying so where the metric is read.