Why vague metrics cause trouble
Suppose two departments both report “average resolution time” for the same service. One counts calendar hours, the other working hours. One includes tickets that were reopened, the other does not. Both numbers are honest, and they cannot be compared. Meetings then turn into debates about whose figure is right instead of what to do.
A precise definition prevents this. It is a short written description that makes a number mean one thing, to everyone, now and in the future. It matters most in centralized settings, where several teams or sites feed the same measure.
What a definition should contain
A workable template has a handful of fields. None need to be long.
- Name: a plain name used consistently everywhere.
- Purpose: the question the measure answers and the decision it informs. A measure with no purpose is hard to defend.
- Owner: the person or role responsible for the definition and for answering questions about it.
- Data source: the system, table or report the raw data comes from, and who maintains it.
- Calculation: the exact formula, written out in words and, where helpful, as an expression.
- Unit and period: for example, hours per ticket, measured monthly.
- Inclusions and exclusions: what counts and what does not.
- Time rules: when the clock starts and stops, time zones, working versus calendar time.
- Known limitations: gaps, delays or biases the reader should be aware of.
- Version and date: when the definition last changed.
A worked illustration
The numbers below are invented purely to show the arithmetic.
Metric: Average time to resolve a request.
- Purpose: show how long people wait for a request to be completed.
- Data source: the request-tracking system, using the “created” and “resolved” timestamps.
- Calculation: for all requests resolved in the month, add up the working hours between creation and resolution, then divide by the number of requests.
- Exclusions: requests cancelled by the requester; requests logged as duplicates.
- Time rules: working hours only, Monday to Friday, in the service’s local time zone.
Now take three requests resolved in a month, taking 4, 6 and 20 working hours. The total is 4 + 6 + 20 = 30 hours, and 30 divided by 3 is 10 hours. The definition makes this number reproducible. It also exposes a limitation: the single 20-hour request pulls the average up, so a note about using the median alongside it might be added. The median of 4, 6 and 20 is 6.
Decide the tricky cases in advance
Most disagreements come from edge cases rather than the main formula. It is worth asking, before publishing a number:
- What happens when an item is reopened? Is it one item or two?
- If an item is waiting for the customer, does the clock keep running?
- Which date counts when work spans a month boundary: the start, the end or the day it was reported?
- How are items handled that are moved between teams?
- Are test records, internal items or duplicates removed, and by what rule?
Writing the answers down once is much cheaper than rediscovering them each quarter.
Pick a source and stick to it
A metric should have one agreed source. When the same figure can be pulled from three different systems, three different numbers will appear. This is the practical meaning of a single source of truth: not that only one system exists, but that everyone agrees which one is authoritative for a given measure.
Check how reliable the source is. Missing timestamps, free-text fields used as categories and manual entry are common causes of data quality issues, and they affect the metric whatever the formula says. If the data is weak, say so in the limitations field rather than hiding it.
Where an organization has formal data stewardship, stewards are natural reviewers of metric definitions, because they usually know how each field is populated.
Keep a glossary and control changes
Definitions are most useful when they sit in one place that people can find, such as a shared register or a business systems glossary. It need not be elaborate; a single shared document with consistent fields is a good start. Wider data governance arrangements, where they exist, often decide who may approve a change.
Definitions will change. When they do:
- Record the change, the date and the reason.
- Note whether past figures were recalculated. If not, mark the point on any trend chart where the definition changed, because the line before and after are not strictly comparable.
- Tell the people who use the figure.
Silent changes are one of the more common reasons trends cannot be trusted.
Test the definition on someone else
A good test is to give the written definition and a sample of raw data to someone who has not seen the metric before, and ask them to calculate it. If they arrive at the same result, the definition works. If not, the gaps will be obvious, and it is better to find them in a test than in front of senior stakeholders.
Limits of precision
A tight definition does not make a metric a good one. It can be perfectly reproducible and still measure the wrong thing. Precision answers “what exactly is being counted?”, not “is this worth counting?”. The second question belongs to the earlier choice of what to measure, and to the later question of how a number can be misread or gamed.