Build a KPI Tree and Dashboard Spec — with a Gaming-Risk Critique per Metric

Workflow area: Data & Evidence · Tier: Foundation · Hands-on time: ~30 minutes

Every measurement system is also an incentive system. "Reduce onboarding cycle time" becomes clerks parking hard cases in a side queue; "increase first-call resolution" becomes agents discouraging callbacks. Analysts are asked to spec dashboards constantly, and the specs usually stop at the formula — nobody budgets time to think like the people being measured. AI changes the economics: decomposing an objective into a metric tree is fast, and running an adversarial "how would I game this?" pass over every node costs one more prompt. The output is a dashboard spec whose metrics have definitions, owners, sources, and named failure modes — before data owners are asked to build anything.

When to use — and when not to

• Use it when a project needs success metricsbenefits tracking, process improvement targets, or the measurement section of a business case (it feeds pb-09's benefit math directly).
• Use it when speccing any dashboardthe tree forces every tile to justify its existence by connecting to the objective; orphan tiles are how dashboards become wallpaper.
• Use it when an existing metric behaves suspiciouslya KPI that improved while the outcome it proxies did not is a gamed metric; the critique pass diagnoses how.
• Skip it when the objective itself is undecideda KPI tree for a vague goal launders the vagueness into numbers; get the objective sentence agreed first.
• Skip the full tree for operational monitoringsystem-health dashboards (uptime, queue depth) need runbooks, not objective decomposition.

The recipe

1. 1.

   Write the objective as one measurable sentence. "Reduce vendor onboarding cycle time from 9 days to 4 by Q3 without weakening compliance controls." The "without" clause matters — it becomes the tree's guardrail branch.

2. 2.

   Generate the KPI tree with full metric cards.

   Copy

   You are a business analyst designing a measurement system.
   Objective: [ONE SENTENCE, WITH THE "WITHOUT" GUARDRAIL CLAUSE]
   Process context: [2-3 LINES on the process and systems involved]
   Available data: [KNOWN SYSTEMS/TABLES, e.g. "CRM events, ERP
   vendor master, approval timestamps in workflow tool" — or "unknown"]
   
   Produce:
   1. KPI TREE — the objective at the root, decomposed into 2-4
      driver branches, each with 1-3 metrics. Include a GUARDRAIL
      branch for the "without" clause.
   2. METRIC CARDS — for every metric: name; precise definition
      (including what is excluded); formula; grain and frequency;
      likely source system/fields, marked (UNVERIFIED) until a data
      owner confirms; suggested owner role; target-setting note
      (baseline needed first?).
   3. For each metric, one line: WHAT DECISION does this metric
      change? If none, mark it (VANITY).
   
   Rules: definitions must be precise enough that two people would
   compute the same number. Do not claim a source field exists —
   propose and mark (UNVERIFIED).
   

3. 3.

   Run the gaming-risk critique as a second, adversarial pass.

   Copy

   Now switch roles: you are a clever, rational team lead whose
   bonus depends on these metrics, and you will optimize them with
   the least real work.
   
   For each metric in the tree:
   1. GAMING MOVES — the 2-3 most likely behaviors that improve the
      number without improving the objective (reclassification,
      timing games, denominator management, case-picking, queue
      hiding).
   2. DETECTION — what companion signal would expose each move.
   3. FIX — a definition change, paired metric, or audit that makes
      the move unprofitable.
   
   Then list the tree's STRUCTURAL risks: which single metric, if
   over-weighted, does the most damage? Where do two metrics
   conflict?
   

4. 4.

   Read a sample of good critique output.

   Copy

   METRIC: Median onboarding cycle time (submit → active)
   - Gaming move: reject-and-resubmit — hard cases "rejected" and
     re-entered, resetting the clock. Detection: resubmission rate
     by clerk. Fix: measure from FIRST submission of a vendor
     identity (tax ID), not latest.
   - Gaming move: pre-work off the clock — clerks hold applications
     in email until documents are complete. Detection: gap between
     email receipt and system entry (sampled). Fix: pair with
     "time to first entry" spot audits.
   

5. 5.

   Fold fixes into the spec, then validate sources with data owners. Update definitions with the anti-gaming fixes, attach the detection signals as companion tiles, and delete anything still marked (VANITY) that no one defended. Then take every (UNVERIFIED) source to the data owner: does the field exist, is it populated, is its meaning what the card assumes? Their corrections rewrite cards — a metric whose source does not exist is a data-engineering request, not a dashboard tile. Nothing enters the build spec until its source is confirmed.

6. 6.

   Ship the spec as a two-page artifact. Page one: the tree diagram with the guardrail branch visible. Page two: the metric cards with validated sources, owners, gaming notes, and refresh frequencies. This is what the Power BI or Looker developer builds from — and the gaming notes stay in the spec as institutional memory.

Make it yours

• Claude/ChatGPT with your metric standards: pin your org's existing metric dictionary and naming conventions in a Project so generated cards reuse established definitions instead of coining rivals.
• Power BI semantic models: hand the validated metric cards to whoever owns the semantic model; precise definitions and grain map almost one-to-one onto measures, and disputes about "which cycle time" get settled in the model once, not per report.
• Gemini in Sheets for the lightweight version: small teams can keep the tree and cards as a living Sheet — the critique columns sit right beside each metric, visible to everyone measured by it.
• Org scale: run the same prompt pair for each department's objectives and roll the guardrail branches up — cross-department gaming (shipping cost pushed into ops, ops delay pushed into support) only shows up at that level.

Quality check

• Two people would compute the same numberevery definition survived the read-aloud test; "excluding what?" has an answer on every card.
• Every metric changes a decisionanything that survived only because it is easy to measure got deleted.
• The guardrail branch exists and is reported with the treeimprovement metrics without their compensating controls is how "faster" quietly becomes "sloppier".
• Gaming moves are documented per metric, with detection signalsand the fixes made it into the definitions, not a footnote.
• Every source field was validated by a data ownerno (UNVERIFIED) tags remain in the build spec; invented fields are the KPI equivalent of invented process steps.
• Baselines precede targetsany card whose target was set before its baseline was measured is flagged, because that target is a negotiation, not a measurement.