How to Build a KPI Framework Before You Build a Single Dashboard
- Matt Lazarus
- Jul 27
- 5 min read
The dashboard project was approved, the consultants engaged, the first demo delivered - and then finance asked why the revenue figure differed from their pack. Sales had a third number. The project that was meant to end the arguments had industrialised them.
The cause is sequencing. Dashboards built before definitions inherit every unresolved disagreement in the business and render it in high resolution. The fix is a KPI framework - the unglamorous thinking that should precede any tooling, and almost never does.
Here is how to build one, including the workshop you can run without a consultant in the room.
Key Takeaways
Undefined metrics are the upstream cause of every "whose number is right" argument your dashboards will inherit.
Definitions live in the edge cases - timing, exclusions and intercompany rules, not the headline formula.
The metric dictionary becomes the semantic model - settled once in writing, encoded once as certified measures.
Why Do Dashboards Built First Always Inherit the Arguments?
Because a dashboard does not create truth - it renders whatever definitions it was given, and if every department gave it a different one, the dashboard publishes the disagreement. The three-different-numbers problem is never a tooling fault; it is an unsettled definition wearing a chart.
The pattern is predictable: each team's "revenue" embeds its own timing (booked versus invoiced versus paid), its own exclusions (returns, intercompany, one-offs) and its own hierarchy (which products roll up where). Each is internally consistent and collectively contradictory. Build dashboards on top and you have automated the contradiction.
What Is an Outcome-Driver-Measure Tree?
A tree that starts from a business outcome, branches into the drivers that move it, and ends in the measures that track each driver - forcing every KPI to justify its existence by its connection to something the business is trying to achieve. It is the antidote to the metric wish-list, where every stakeholder nominates favourites and the dashboard becomes a museum.
Worked briefly: the outcome "grow profitable revenue" branches into drivers - win more of the right customers, expand existing accounts, hold margin - and each driver resolves into two or three measures (qualified pipeline by segment, net revenue retention, margin by product family). Anything that cannot find a branch does not make the dashboard. The tree typically prunes a forty-metric wish-list to twelve that matter, and the pruning is the value.
Where Do Definitions Actually Live?
In the edge cases. The headline formula is never the disagreement - everyone agrees revenue is money for goods sold. The disagreements live in timing (recognised when?), exclusions (do returns, rebates and intercompany count?), scope (which entities, which currencies, at what rate?) and hierarchy (where does that hybrid product roll up?). A definition that has not settled its edge cases is a slogan.
The metric dictionary captures each settled definition as a governed artefact: name, business owner, formula in words, the edge-case rulings, the source of truth, and the refresh cadence. One page per metric, signed by the owner. This document outlives every dashboard built on it - and when a definition must change, it changes here first, once, with a version history.
How Do You Run the Definition Workshop?
Two sessions, the right people, and a facilitator with the authority to force rulings. Session one walks the outcome tree and prunes the wish-list; session two settles the edge cases metric by metric, with finance, the business owner and whoever runs the source system in the room - because all three hold a piece of every disagreement.
The agenda that works:
Before: circulate the current state - the same three metrics calculated by each department, differences highlighted. Nothing motivates settlement like seeing the spread.
Session one (90 minutes): agree the outcomes, build the tree, prune to the metrics that earn a branch.
Session two (two hours): for each surviving metric, rule on timing, exclusions, scope and hierarchy. Disagreements get decided in the room or assigned to a named owner with a date - never deferred to "the build phase".
After: the dictionary circulates for sign-off. Silence past the deadline is consent.
How Do Definitions Become Working Dashboards?
Each dictionary entry is encoded once as a certified measure in a shared semantic model - and every report from then on uses the measure rather than re-implementing the logic. This is the step that makes the framework permanent: definitions enforced by architecture rather than memos.
The discipline in practice: one governed model per domain carrying the certified measures, reports built on top of it rather than on raw extracts, and the dictionary's edge-case rulings implemented in the measure logic where they can never be accidentally omitted. When the business later asks a new question, the answer is assembled from settled parts. This is the foundation that makes business intelligence consulting engagements compound rather than sprawl - and it is why the best dashboard development projects spend their first fortnight in workshops, not in Power BI.
What Does This Buy Beyond Ending the Arguments?
Speed, trust and a foundation for whatever comes next. New reports assemble in days because the hard thinking is done; meetings debate decisions instead of relitigating data; and every future capability that reads your numbers - self-service analytics, natural-language query, AI features - inherits one settled truth instead of three competing ones.
The framework also survives personnel change, which the verbal-tradition alternative never does. When the analyst who knew the rules resigns, the rules remain - owned, written and encoded.
Who Should Own the KPI Dictionary?
A named business owner per domain, with a single technical steward across the estate. Finance owns the financial definitions because finance answers for them at board level; operations owns operational measures for the same reason. The BI steward owns the translation - making sure the agreed words become exactly one DAX measure, reused everywhere, rather than five lookalikes.
The model fails in predictable ways when ownership is fudged. Dictionaries owned by IT drift from how the business actually argues about performance. Dictionaries owned by committees update at the speed of committees. And dictionaries owned by nobody are archaeology within a year - accurate about the organisation that wrote them, silent about the one that exists now.
Keep change control proportionate: a definition change needs the domain owner's sign-off and a dated note, not a governance board. The dictionary's value is that it is current and believed - one page that everyone trusts beats forty pages that nobody has opened since the workshop.
Publish the dictionary where the arguments happen, not where documents go to rest. A definition surfaced inside the dashboard itself - a tooltip on the measure, an info page in the app - settles the meeting-room dispute in the meeting; the same definition in a SharePoint folder settles nothing, because nobody leaves a board meeting to go and find it.
Think First, Then Build
The KPI framework costs two workshops and a document. Skipping it costs a rebuilt dashboard project, six months of numbers arguments and the credibility of whatever gets built. The sequencing is the entire lesson: definitions, then model, then dashboards - because the tool can only ever render the thinking it was given.
Run the workshops before the build. The dashboard project that follows will be the quietest one your business has ever commissioned.
