Measurement and operating cadence
A measurement system is a decision system. This path starts from the decisions the business needs to make, keeps the measure set small and time-ordered, and runs reviews that end in decisions rather than status reports.
6 steps · 7 cited sources · free during beta
Which measures should we run the operation on, and how should we review them?
The path, step by step
-
Start from decisions, not dashboards
List the recurring decisions the operation needs to make and who makes them. For each, name the measure that would change the decision and the cadence at which it needs to arrive.
Why it worksPerformance measurement systems fail when they are built as reporting catalogues. Measures earn their place by improving a decision, and different decisions need different cadences.
EvidenceNeely (1999) · Kaplan & Norton (1992)
CheckpointA decision-to-measure map, with an owner and cadence for each decision.
Common failureAdding every available metric to a dashboard and calling it visibility.
-
Choose a small balanced set with owners
Select a handful of measures across financial, customer, process and capability outcomes. Give each a definition, a baseline, a target and one owner.
Why it worksThe balanced scorecard links measures across perspectives so that one dimension is not optimised at the expense of another. A small set with owners is easier to govern than a comprehensive catalogue.
EvidenceKaplan & Norton (1992) · Neely (1999)
CheckpointA one-page scorecard with definitions, baselines, targets and named owners.
Common failureMeasuring twelve things and owning none of them.
-
Co-design the measures with the people using them
Build definitions and data collection with the teams who will use them. Test the measure for a cycle and change it if it drives the wrong behaviour.
Why it worksMeasurement systems are more likely to be used when they are developed with local knowledge, made transparent and treated as enabling rather than imposed. A measure people do not trust becomes a reporting obligation.
EvidenceNeely (1999) · Kaplan & Norton (1992)
CheckpointDefinitions agreed with the teams, and one revision made after the first test cycle.
Common failureHanding down a metric dictionary and expecting it to shape behaviour.
-
Review time-ordered data in a short cadence
Run a short, frequent review of the few measures that change weekly. Plot them over time, annotate interventions, and discuss the trend rather than a single snapshot.
Why it worksRun charts and short frontline huddles support coordination and learning from variation. The point of the cadence is to catch a signal early enough to act, not to read out last month's numbers.
EvidencePerla et al. (2011) · Pimentel et al. (2021)
CheckpointA weekly chart with annotations, and a short review that starts from the trend.
Common failureHolding a monthly meeting to review annual data.
-
Run the review as a decision forum
Use a fixed agenda: what changed, what it means, what we will decide, who owns it and when. Separate information sharing from decision-making, and record the decision.
Why it worksDecision quality depends on framing, alternatives and follow-through. A meeting that only reports status consumes attention without improving the decision.
EvidenceSimon (1955) · Eisenhardt (1989) · Snowden & Boone (2007)
CheckpointA decision log with owner, date and the measure that will show whether it worked.
Common failureEnding the meeting with 'let's keep an eye on it' and no owner.
-
Audit for gaming and retire dead measures
Check whether the measure is being hit by improving the number rather than the outcome. Retire measures that no longer inform a decision.
Why it worksMeasures distort behaviour when they become targets without a check on how they are achieved. A periodic audit keeps the measurement system honest and small.
EvidenceNeely (1999) · Kaplan & Norton (1992)
CheckpointOne gaming check per critical measure, and a retired-measure list.
Common failureKeeping a measure because it is in the historical report, long after anyone uses it.
The evidence base
Each step above cites hand-selected research. These are the studies behind the path.
- Neely (1999) — The Performance Measurement Revolution: Why Now and What Next?
- Kaplan & Norton (1992) — The Balanced Scorecard: Measures That Drive Performance
- Perla et al. (2011) — The run chart: A simple analytical tool for learning from variation in healthcare processes
- Pimentel et al. (2021) — Huddles and their effectiveness at the frontlines of clinical care: A scoping review
- Simon (1955) — A Behavioral Model of Rational Choice
- Eisenhardt (1989) — Making Fast Strategic Decisions in High-Velocity Environments
- Snowden & Boone (2007) — A Leader's Framework for Decision Making
More from the library
Further reading from Portolan's research library, matched by subject. These papers are not proof that any step works; check each checkpoint against your own operation.
- Melnyk et al. (2004) — Metrics and performance measurement in operations management: dealing with the metrics maze
- Neely et al. (2000) — Performance measurement system design: developing and testing a process‐based approach
- Neely (2005) — The evolution of performance measurement research
- Neely et al. (1995) — Performance measurement system design
- Koufteros et al. (2014) — The effect of performance measurement systems on firm performance: A cross‐sectional and a longitudinal study
- Bourne et al. (2000) — Designing, implementing and updating performance measurement systems
- Kaplan (2001) — Strategic Performance Measurement and Management in Nonprofit Organizations
- Bititci et al. (2000) — Dynamics of performance measurement systems
- Bititci et al. (1997) — Integrated performance measurement systems: a development guide
- Hudson et al. (2001) — Theory and practice in SME performance measurement systems
Guides for this path
Other playbooks
- Demand forecasting — How should we forecast demand so that plans, staffing and stock follow reality?
- Capacity, flow and scheduling — Where is work waiting, what is the real constraint, and how should we release and staff work?
- Quality assurance and process control — How do we define quality, stabilise the process and hold the gain?
- Inventory and replenishment — How much stock should we hold, where, and what should trigger a replenishment?
- Supply chain and supplier resilience — Where is the network exposed, and which capability or buffer actually reduces the exposure?
- Service operations and customer experience — Where does the customer experience break, and what should we change in the service system?
- Maintenance and asset reliability — Which assets matter, how do they fail, and which maintenance tasks are actually justified?
- Continuous improvement and change adoption — How do we make improvement routine, and how do we get a change to stick?
- Incident response and on-call — How should we handle incidents and on-call so the service recovers quickly without burning out the team?