Context
I have an interesting engagement with a client that is trying to adopt OKRs as an alignment and coordination tool. This particular organisation is a large corporate in a heavily regulated environment. I’m working with functional areas within their traditional risk averse IT organisation. Their historical response to their environment has been to favour command and control strategies.
The scenario that triggered this post
An organisational unit had two in flight projects (both delivering production releases reasonably regularly). One had all the hallmarks of a well run project – including a prediction that they’d deliver all their requirements on time. The other project had several challenges and was predicted to finish fairly late and over budget. Both projects were funded as preferred options on their respective OKRs. The well run project was having no appreciable effect on its OKR. In contrast, the “late” project was already having a positive effect on their OKR. Which project do you imagine was stopped?
The Ideological Conflict
The challenge stems from the nature of OKRs. More precisely, what they’re inherently there to manage. OKRs emerged at Intel as a way of better managing discovery-type work. Work where the precise nature of what was going to be produced would be hard to predict, but the desired effects on their market could be articulated. This articulation came in the form of outcomes – the changes in behaviour of their market. In order to track whether or not progress was being made (as opposed to effort being spent), the Key Results construct were used to articulate the visible signs of their market responding “favourably”.
An Objective would be “Establish the 8086 as the most popular 16-bit microcomputer solution.”. The Key Results for the same objective would be “Win 2,000 designs for Intel in the next 18 months.”
And now to the challenge. It’s essentially a misalignment between corporate culture and the nature of “what is important in OKRs”.
Organisations with a strong “PMO core” typically value the predictability of projects. They like “green projects” running “on time and on budget”. Nothing wrong with that, predictability is a side effect of having your uncertainty and risks under control. And what organisation would turn their noses up at that?
OKRs change the focus on what is important. The construct has three basic levels. The two important ones are in the name – Objectives and Key Results.
Key Results define a measurable way of detecting a desired outcome. It’s the observable effects. What Key Results don’t do however, is define how you achieve that outcome. That’s the third level – the options that you identify and the decision on which option you take. These options are definitions of output.
These outputs themselves don’t matter. Only the effects (or lack of) they have.
The idea is that if an option isn’t having the desired effect moving the needle on your Key Result, then you pivot. The sooner you pivot, the less you waste. Successful execution of a project (green / on-time / on-budget) has no real bearing on whether or not it’s the right thing to do.
Unless your organisation changes the internal model of what is valuable from output delivery to outcome realisation, then the delivery management function (e.g. PMO) will continue to focus on output delivery optimisation instead of output effectiveness.
Amateur Coach 