Two dashboards can show different numbers without either containing an arithmetic error. They may use different populations, dates or definitions of completion. Before debating performance, create a shared metric definition. This article shows what that definition should contain and how to reconcile a disagreement without hiding uncertainty in the data.
Name the decision the metric supports
A metric is a quantitative value describing an aspect of work, such as request volume or completion rate. A key performance indicator (KPI) is selected to measure progress towards an important objective against a defined target. Not every dashboard number is therefore a KPI.
A metric should answer a practical question: are requests completed within the promised time, or are repeat errors increasing? State who uses the answer and what action it may trigger. A number collected merely because the system makes it available may add reporting work without improving a decision.
The KPI design article discusses links to objectives and targets. This article addresses a different problem: making the same measure mean the same thing to its users. NIST’s Baldrige resources provide a wider framework for organisational assessment; the definition sheet below is a practical working example.
Build a minimum definition sheet
A metric definition sheet records the rules needed to reproduce a calculation. For a completion rate, the numerator is completed requests and the denominator is requests included in the assessment. Divide the numerator by the denominator and multiply by 100 to calculate the percentage.
| Field | Question to settle |
|---|---|
| Name and purpose | What decision does this measure support? |
| Population | Which cases are included and excluded? What event counts as completion? |
| Formula | What are the numerator, denominator and unit? |
| Time rule | Which event date, timezone and reporting window apply? |
| Refresh | How often is the result updated, and up to what time do the data cover? |
| Source | Which system, fields and extraction version are used? |
| Owner | Who prepares and checks the data? Who owns the metric and approves definition changes? |
| Limitations | What is missing, estimated or not comparable? |
Keep the sheet close to the dashboard. A short visible definition is more useful than an inaccessible document that users cannot connect to the displayed number.
Reconcile a fictional completion rate
In a hypothetical example for illustration, suppose 90 of 100 requests received in a month are completed by month-end. The rate for that received cohort is 90%. Another team reports 110 completions during the month, including 20 requests received earlier. Both counts can be correct because they answer different questions. Dividing 110 by the 100 new requests does not measure the completion rate of that cohort.
A cohort is a group of cases sharing a rule, such as receipt within one month. Agree whether the intended view follows that group or counts activity during a period. Reconcile individual case identifiers, opening backlog, new work, completions and closing backlog. Make cancellations and reopened cases explicit so the totals can be explained.
Check the balance before interpreting the rate
Backlog means requests still unfinished at a specified date. Extend the earlier example by assuming 20 open requests at the start of the month, 100 new arrivals and 110 completions. With no cancellations, reopened cases or transfers between teams, the closing backlog is 10: 20 plus 100 minus 110. This is consistent with completing the 20 older requests and 90 from the new cohort. All these figures are fictional and illustrate the calculation.
Reconcile request identifiers as well as totals. Two errors can offset each other, leaving an apparently correct balance with one duplicate case and one missing case. Sample records covering opening and closing positions and changes during the period. Check that the event counted as completion matches the definition, and retain the reason for any adjustment so a later extract can explain the difference.
If requests can be reopened, specify whether you report unique completed requests or closure events. A single request can generate more than one event. Do not substitute one count for the other without explanation, or treat a reopened request as a new arrival when the arrival definition covers only newly created requests.
Handle missing and late data visibly
Distinguish zero from missing. Zero may mean no event occurred; missing may mean the source was not received or the field was incomplete. Define how late updates affect a published period and mark provisional results. Do not silently replace an earlier figure if that change matters to the decision.
Check duplicate identifiers, time boundaries and joins between systems. Retain the extract date and a reproducible calculation. Access to detailed records should remain proportionate to the purpose; a management dashboard rarely needs unrestricted personal data.
Compare only like with like
Before comparing teams or periods, check scope, case complexity, working hours and exclusions. A faster result for simpler cases does not necessarily show a better process. Show sample size and explain changes in the mix of work. Avoid turning an external statistic into a local target without checking its method and relevance.
Historical forecasts from an old article should not be relabelled as current facts. If an external number is needed, record the original publisher, publication date, measurement period and population. Otherwise, use an explicitly illustrative example and focus on the decision method.
Aggregate rates using their denominators
In a separate hypothetical example for illustration, one team completes 8 of 10 requests, a rate of 80%. Another completes 45 of 90, a rate of 50%. If the populations do not overlap and the completion definition and period are identical, the combined rate is 53 of 100, or 53%. The simple average of the two rates, 65%, does not describe the proportion of all requests completed.
A simple average gives each team equal weight; the combined rate gives each request equal weight. They may answer different questions, but the result must be labelled clearly. Do not combine rates with different units, reporting periods or exclusion rules merely because they appear beside each other on a dashboard.
If the denominator is zero, show that the rate cannot be calculated under the definition instead of automatically reporting 0% or 100%. A change from 50% to 60% is a difference of 10 percentage points: 60 minus 50. The relative increase is 20%: divide the difference of 10 by the original value of 50, then multiply by 100. Keeping those expressions distinct prevents an executive summary from overstating or understating the change.
Separate the measured result from the target and the required action. A mathematically correct figure may still be insufficient for a decision without service quality, demand or an explanation of the change. Add a short comment on what the team knows and what needs investigation, then assign follow-up ownership and timing.
Control changes and assign follow-up
Give the definition a version and effective date. When it changes, explain whether historical values have been recalculated and whether the trend has a break. Assign a named role to investigate discrepancies and a separate decision owner where appropriate.
Start with one disputed number, settle its definition and reconcile it to source records. Check cases, dates and the formula before interpreting performance. Show missing data and the effect of any change. A comparison becomes useful when readers understand what the number measures and what it does not.
The Strategic Planning and KPIs service can connect reliable measurement with objectives and review routines. Agreement on the definition comes before confidence in the comparison.