Build an Operations Metrics Dashboard

Proof required

Submit a KPI specification document covering: metric name, definition, calculation method, data source location, data owner, target value or benchmark, and refresh cadence for each of the five to ten KPIs.

What gets checked

• Every KPI has a confirmed accessible data source — not 'this data probably exists somewhere'
• The KPI set includes at least one leading indicator and one lagging indicator
• KPIs are traceable to a stated strategic goal, not convenience metrics that are easy to collect

Common mistakes

• Selecting KPIs based on available data rather than strategic importance — measuring what is easy, not what matters
• Skipping data source confirmation and discovering mid-build that data is inaccessible or incomplete

Resources

What a verifier looks for

• Ask the candidate to open the data source live and show that the KPI data is actually there
• Challenge the leading/lagging balance: 'which of these can you act on before the outcome occurs?'
• Check that at least one KPI has a defined target value or benchmark, not just a measurement
• Probe the calculation method for one KPI: ask for the exact formula and what happens when a data field is null

You'll sign in first, then come straight back here.

Proof required

Submit: a link to the live dashboard or an exported PDF of all dashboard pages; a validation log showing spot-check results for each KPI (ten rows checked per KPI, source versus dashboard value), and a discrepancy log documenting any mismatches and their resolution.

What gets checked

• Every KPI on the dashboard matches the source data in the validation log — no unresolved discrepancies
• Dashboard handles null or missing data without breaking or silently showing wrong values
• At least one KPI includes a target line or benchmark so viewers can see performance relative to expectation

Common mistakes

• Shipping without validation — dashboards that look correct often have silent calculation errors discovered only under scrutiny
• Building the dashboard in a tool the team cannot access or maintain without the builder present

Resources

What a verifier looks for

• Ask the candidate to walk through one KPI calculation live — from the raw data source to the dashboard number
• Check the validation log: were ten rows actually checked, or were only clean-looking rows selected?
• Try filtering the dashboard by an edge-case date range or segment — does it handle gracefully?
• Ask who else on the team can update the dashboard when the builder is unavailable

You'll sign in first, then come straight back here.

Proof required

Submit: a recording or written summary of the review meeting (attendees, insight presented, questions asked); a written decision record naming the specific metric that drove the decision, the decision made, the owner, and the expected outcome; and a screenshot of the relevant dashboard state at the time of the decision.

What gets checked

• The decision is specific and actionable — 'investigate why return rate is 12% in Region B' passes; 'improve operations' fails
• The decision is traced to a specific metric visible on the dashboard, not a general impression
• The review was with a genuine process owner, not the dashboard builder presenting to themselves

Common mistakes

• Presenting the dashboard without drawing a specific insight — showing numbers is not the same as telling the business something it didn't know
• Documenting a trivial decision ('we noted this for future reference') that required no analysis

Resources

What a verifier looks for

• Ask the candidate to identify the single most surprising thing the dashboard revealed — not the most expected
• Check the decision record: is the tracing between metric and decision explicit and specific?
• Ask who the process owner was and confirm they attended the review meeting
• Probe whether the decision was actually acted on — or whether it remains 'noted for future reference'

You'll sign in first, then come straight back here.