Don't Confuse the Project with the Result
If I had my say, we wouldn’t call the methodology OKR — but OKP for "Objectives, Key Results, and Projects"
One of my executive coaching clients asked for guidance some time back on how to keep her company’s OKR (Objectives & Key Results) initiative from going stale.
Our work together began with an OKR engagement and grew from there. But back when we started together, I foreshadowed it normally takes a company two to three years to dial in the way OKRs ought to be working for them.
Her company, now in its fourth year, is dealing with basic challenges that come along with these types of strategic initiatives. (The OKR methodology is in the family of strategy execution methodologies, including Traction, 4DX, and so on, which all have similar implementation patterns.)
At its simplest, the OKR framework has a team specify what Objectives they’re going after (typically, thematic or qualitative) and Key Results that "cash out" those Objectives (typically, measurable or quantitative).
For instance, for my other company PF, it might look like this:
Objective: Launch and get traction with the Momentum app
Key Results:
Get 10,000 customers within the first year of launch
Achieve a 33% active customer referral rate
Get cost-per-acquisition to $20 or less
Simply put, if we achieved those three Key Results, we’d know we had achieved that Objective.
Yet what often happens during an OKR initiative is that teams almost immediately start to replace real Key Results with projects. Something like "Launch a website" slides in as a Key Result, and once that one’s in, more projects start creeping in.
If I had my say, we wouldn’t call the methodology OKR — we’d call it OKP for "Objectives, Key Results, and Projects" so that we more clearly differentiate between key results and the projects that achieve those key results.
Why does it matter that a team conflates key results and projects? Because when we confuse results and projects, three visible patterns emerge:
Teams tend to put bigger projects on the board because they’re primed by the time horizon of the objective. If the time horizon of the objective is one year, teams choose year-sized projects.
Teams often lose sight of how those projects are actually pushing the objective forward. In the example for PF, "launching a website" may make no significant difference whatsoever if the website’s not doing real work for us. It could simply be another of the gazillions of websites that actually work against us or something we put up and don’t use. In our case, the point of a website would be to drive customer acquisition; it’s a project that drives that key result.
Teams get litigious about projects. This is a consequence of 1 and 2. If we only get a few big projects, we have to choose well. If we’re not clear on how the projects will drive our objective forward, we tend to champion projects we want to do for other reasons, or because we think it will keep us safe.
Switching to OKPs can help avoid a lot of those traps while encouraging teams to adopt a more generative cadence for choosing projects. It also avoids over-adjusting projects masquerading as key results.
For instance, if your Objective and Key Results are on a one-year horizon, it’s easier for teams to keep those fixed to the year (as they ideally would be) but still pick month-sized projects that help them learn what best creates those key results. During their monthly OKP refresh, it’s "Where are we related to those Objectives and Key Results + how are our projects getting us there?" vs. the more time-consuming "Should we choose different Key Results?"
I’ll leave you with a sportsball analogy: Objectives tell you what game you’re playing, Key Results tell you what counts as points, and Projects are the plays you run to get those points.
This article was originally published on Productive Flourishing.