← ITIL 4 DPI: direct, plan, and improve
06 / 7 · 30 MIN

Metrics and reporting for decisions

Use definitions, denominators, and segments consistent with the decision.

Concept and mechanism

A metric should help someone decide or evaluate an objective. If the goal is fewer batch delays, completion within the business deadline is more direct than counting dashboards. Define the unit, population, period, and classification rules. Distinguish counts from rates: ten failures in one hundred changes represent 10%; eight in forty represent 20%. The count fell while the proportion rose. This proves neither a cause nor a statistically significant difference. It indicates a need to investigate context, complexity, and impact while exposing the numbers used in calculation and comparison limits.

Guided application

Averages may also conceal different outcomes. Lower mean resolution time can coexist with slower critical incidents. Segment by impact and context and observe the distribution before announcing overall improvement. Do not remove inconvenient cases to make the trend more stable. Adapt reporting to the recipient’s decision: operations may need actionable detail while a committee needs a summary connecting performance to risk and outcomes. If nobody uses a metric, review its objective, recipient, and collection cost. Increasing frequency without knowing the resulting decision may merely create more reporting work.

IN PRACTICE

10/100 = 10% and 8/40 = 20%; two fewer failures alone do not establish better quality.

Common pitfalls

Count as rate; average as every group; frequent collection as usefulness; correlation as cause.

Related topics: Streams, practices, and optimization · Direction, planning, and outcomes

Take this idea with you

Present the indicator with enough context to support the decision.

Create account

Reference: PeopleCert DPI syllabus and exam specification, Japanese · ITIL 4 DPI; observed JA v1.3.1, current detailed revision comparison pending