Strategy deployment.
Translating strategy into objectives people can act on. KPI architecture and OKR cycles, cascaded from board level intent to a frontline measure, with the review rhythm that keeps them live rather than filed.
The problem this solves.
Strategy is rarely the weak point. Most organisations have thought carefully about where they intend to go, and can describe it well. The difficulty appears one or two layers down, where the strategy has to become something a superintendent can act on this month.
Three patterns recur. The strategy is communicated but never translated, so people agree with it and then continue exactly as before. Measures proliferate until a site is reporting forty numbers, none of which anyone treats as decisive. Or a framework is adopted, OKRs being the current favourite, and becomes a quarterly form filling exercise disconnected from how the business is actually run.
Underneath all three is a missing line of sight. If a person cannot see how the number they are held to connects upward to a corporate objective, and cannot move that number through their own decisions, they will manage the measure instead of meeting it.
KPI architecture.
A KPI set is an architecture, not a list. Built properly it has a defensible structure: each measure traces upward to an objective and downward to something a specific person influences. Where that trace breaks, you have a number being reported for its own sake.
Three tests do most of the work. Can the person accountable for this measure actually move it, or are they being held to something outside their control? Is it leading or lagging, and do you have enough leading measures to intervene before the lagging ones confirm the damage? And is it defined precisely enough that two people would calculate it the same way from the same data?
The third test fails far more often than people expect, and everything built on top of it inherits the problem. So a good deal of this work is just writing down what each measure means, where the data comes from, and who owns it.
Cutting the count matters too. A dozen measures a site acts on will beat forty it reports and ignores.
OKRs, and when they earn their place.
OKRs and KPIs answer different questions, and they work best together. KPIs tell you whether the business is running as it should. They are steady state, continuously monitored, and largely stable from quarter to quarter. OKRs describe what you intend to change over a set period, and by design they should not survive unchanged.
Used well, an OKR cycle gives an organisation a small number of genuinely important objectives per quarter, each with measurable key results, reviewed and scored honestly at the end of the period. Used badly, it becomes a parallel reporting system that consumes management attention and changes nothing.
The difference is almost entirely in the review discipline. Objectives that are set and never scored teach the organisation that the exercise is decorative. Scoring below target has to be safe, or every objective will be written conservatively enough to guarantee success, which defeats the purpose.
For most industrial businesses the honest answer is that the KPI architecture needs sorting first. Layer OKRs onto a measurement base you do not trust and you will get more confusion, not less.
How the work runs.
- Clarify the objectives. Establish what the strategy actually requires of the operation, stated plainly enough to be measured.
- Build the cascade. Trace each corporate objective down through the layers to a measure someone can influence, and remove anything that does not connect.
- Define the measures. Calculation, data source, frequency, owner and target for each, written down and agreed.
- Set the review rhythm. Who reviews what, at what cadence, and what decision each review is expected to produce.
- Run the first cycle together. The first quarter is where frameworks either take hold or quietly lapse, so I stay involved through it.
- Score and reset. Honest assessment at the end of the cycle, including what the scoring reveals about how the objectives were written.
This work sits very close to operating model design. A cascade with no review rhythm to carry it is just a document, and that rhythm belongs inside the management operating system, not alongside it.
Is this the right fit?
Usually yes, if
- The strategy is sound but has not changed what happens day to day
- Reporting has grown without anyone removing measures
- People are held to numbers they cannot meaningfully influence
- An OKR rollout has become an administrative exercise
- Two parts of the business calculate the same measure differently
Probably not, if
- The strategy itself is unresolved, which is a different piece of work
- There is no willingness to remove existing measures or reports
- Measures are used primarily for individual performance management
- The underlying operational data is not yet reliable enough to measure from
Start a conversation.
The first conversation costs nothing and usually takes half an hour. Tell me what is not working and I will tell you honestly whether it is something I can help with.