Using Archimate to model OKRs for Business Motivation
Following the theme of moulding different modelling languages, methodologies and toolsets together, I want to take a look at how to model OKRs in Archimate.
OKRs do not cascade
Just because the diagram depicts a hierarchy, doesn’t mean that the objectives cascade down the organisational hierarchy. Following the logic in OKRs don’t cascade, I’ve taken the approach of the depicting the hierarchy, rather than how that hierarchy is achieved. In the article, Felipe mentions that objectives should not be cascaded down the organisation. Instead, objectives and key results should be discussed and agreed at each level. The resulting picture is the same either way, but the content of the objectives and key results may be different depending on the route.
Depending on the level of the organisation, many of the components that achieve an Objective will not be Key Results, but instead will be lower level Objectives (e.g. of the next team down in the corporate hierarchy or downstream in case of a flatter hierarchy). The diagram allows both Key Results and Objectives to form part of an Objective.
Modelling Goals and Objectives
Key Results have been modelled as Outcomes. Objectives and Contributing Goals (lower-level Objectives) have been modelled as Goals. In doing so, I’ve allowed for a hierarchy of Objectives to fulfil the concept of Contributing Goals. Had I gone with a model of Objective = Outcome, we would have seen a model of hierarchical outcomes which would not have made as much sense, especially to those having to achieve those outcomes.
From the perspective of Business Architecture, I’m interested in the alignment of actions to the overall vision. I like to see a clean line connecting actions of the workforce to corporate objectives to vision. Many organisations suffer because the objectives are cascaded down rather than agreed at each level. Combining OKRs with a culture of joint-goal setting has a good chance of resolving that core issue.
Notes about the diagram
The content is fabricated; completely artificial. I haven’t populated every single branch, but enough to indicate what could be captured. For those areas that I did populate, I kept to the concept of 3 key results per Objective, of which any of the Key Results can be replaced with Contributing Goals. You can flex that as you wish.
I’ve created a tiny environment in which the OKRs operate, featuring an internal driver for change, an external driver, the assessments for both and the corporate vision and missions.
The interesting concept for me regarding business motivation is that the diagram is agnostic of the organisation structure in that it doesn’t indicate which team or who is responsible for achieving which objectives or key results. I’ve done that on purpose.
If we imagine a typical organisation of 400 people. Each of those named 400 individuals could have Key Results to deliver. Some of those Key Results would contribute to team Objectives. Some of those team Objectives would coalesce to fulfil higher level Objectives and so on. That’s the bottom-up picture.
The top-down picture is that the strategy needs to pervade the organisation and steer the choice of actions and the delivery of those actions. At the top level, the objectives may be independent of who is going to deliver them, but shortly thereafter the key results or contributing goals would have to be assigned. And it’s likely that they’ll be assigned to relevant directors (in the case of stretch targets and keeping the operation running) or delivery teams (in the case of changes). However each of the delivery teams should have a sponsor. It’s that sponsor that’s actually accountable in this case for the delivery of the key result, whereas in many organisations it would be the delivery team.
Overall, OKRs force a concept of personal responsibility or rather, a concept of personal accountability if we follow a RACI model. For the majority of a workforce, the individual is likely to be both accountable and responsible for their key results.
What I haven’t address is the non-aligned use of OKRs, e.g. allowing or encouraging the setting of key results that do not fit with corporate objectives.