Defining OKRs - Best Practices
How effective would you say your team is in defining clear objectives? Maybe you've been part way through a project and still debating exactly what you are trying to achieve? Sometimes you may feel you are clear on goals, but perhaps unsure about how to measure success. If you've suffered from any of these issues, you probably need to improve the way in which you define objectives and the means by which they are measured.
Let's walk through the most important aspects of goal setting, using Objectives and Key Results (OKRs) as our goal setting framework.
The objective statement in an OKR should be succinct so that it can be easily comprehended, communicated and referenced with your team's internal documentation, emails, etc.
The objective must express the intent of the outcomes you're trying to achieve. Clarity of intent helps everyone stay aligned with the purpose of the objective and reduces the likelihood of the objective from being gamed, whether intentional or not.
Over the long term, the outcomes of objectives should be additive. A series of objectives shouldn't result in continual changes of direction for your organisation. To ensure this, objectives should align or "ladder up" to higher level goals and ultimately to company level objectives and mission/vision statements.
Objectives should be aggressive, but realistic. Unachievable objectives can demotivate your team, but they are pointless if too easy to achieve.
Objectives should translate to value for stakeholders but note that not all stakeholders need to be aligned with a given objective. For example, an objective stated in terms of increasing sales may not articulate value to your customers, but your shareholders will likely be very interested.
Objectives should not prescribe execution since this will unnecessarily constrain your team. In the software industry, this is akin to the classic anti pattern of defining requirements that prescribe the implementation.
Objectives should be tangible. Upon completion, it should be obvious to a rational observer whether an objective has been achieved or at least the degree to which it has been achieved.
Each objective should generally have multiple key results to capture various viewpoints. For example, an objective to increase revenue may have two key results such as increasing the number of customers and reducing the rate of churn. When there are multiple key results, they should be as independant as possible to provide a more compete score.
Key results must be measurable and the scoring system should be aspirational. A key result can be deemed measurable if it is based on available and credible data. This may seem obvious, but it is extremely common for many aspects of a system to have insufficient data allowing for measurability in a meaningful manner.
Key results must describe outcomes, not activities. For example, avoid words like "consult", "help", "analyze" and "participate" in key result statements.
The scoring system of each key result should be based on a value between 0 and 1 where sub-ranges can be conceptually thought of as follows:
- Disappointing: 0 to 0.3
- Getting there: 0.4 to 0.6
- Great outcome: 0.7
- Exceeded expectations: 0.8 to 1.0
When defining the scoring system, the same criteria must be applied to the entire range rather than defining separate criteria that are additive. For example, if we were defining a key result to measure the quality of some documentation, we wouldn't want a key result defining a 0.5 result if the API documentation feedback was good and a 0.7 result if the API documentation and user guides feedback were both good. Instead, it is better to have a key result scale that includes feedback from boath types of documentation all the way through and use a weighting system if necessary for different forms of dcumentation. It is also better to state targets in absolute rather than relative terms. For example, "increase Xyz from 25% to 50%" rather than "2x increase of Xyz". Absolute targets are easier to refer to since they don't need qualification such as baseline values.
Don't get off to a bad start for yor next project ever again. When defining your next OKRs, use Roobrick's OKR writing guide. If you use Confluence, use the Roobrick app for Confluence to assess the quality of your OKRs within Confluence.
You may also like some of our other posts...
- Retiring Jira and Confluence apps
- Sharing rubrics and assessments
- How Rubrics Save Time and Effort
- Unified Rubric
- Notes app for monday.com
- Help for the Roobrick app for monday.com
- A Better Way of Working
- Roobrick app for monday.com
- Markdown in Rubrics and Assessments
- Better Decision Making
- Single Point Rubrics Over Analytic Rubrics
- Craft Pack
- Rubrics in Business
- Making Robust Decisions
- Understanding Roobrick