Once again, I’m using Archi (or ArchimateTool) with the Archimate modelling language.
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.
The model I’ve been using in the previous articles has grown to become relative complex (complex for a online article, not for a typical business architecture model) while trying to describe a common situation in most organisations. I’m going to show it all in one diagram in this article and show different perspectives on the diagram.
In the first article, I introduced the standards and the tools that are in scope of this series of articles. To recap, the chosen tools/standards/methods are:
Archimate – The open source enterprise architecture modelling standard
In this article, I’ll show the whole diagram so far and the achieving different perspectives on that model
What we’ll cover:
The model covering all elements that have been discussed so far
The use of viewpoints
What we won’t cover
The current to future organisation model
Do not consider this article to contain the definitive method for documenting the combination of MSP, Business Motivation with Archimate.
I’m more confident about the parts of the model described in articles 1, 2 and 3, than I am in this. Mainly the right-hand side of the model doesn’t feel fully integrated. That’s instinct at the moment, but I’ll look to evaluate further.
The Whole Model
The model starts with the external drivers, influencing corporate ambition. There’s an example of an assessment. Archimate implies that a influencer does nothing to an organisation without an assessment. I’m not keen on that thought. Events will happen to your organisation whether or not you assess them. I can see where they’re coming from, i.e. the internal organisation will not respond to the external influence without an assessment, but it feels odd at the moment.
We then descend the left-hand side of the model through the goals being set, then into corporate governance (probably including portfolios in larger organisations), the MSP Mandate and Brief.
Further down we see the goals related to the MSP Vision, the MSP Outcomes and the Requirements.
On the right-hand side, there’s the assessment mentioned earlier. Below that there’s a gap while we’re in corporate governance on the left-hand side. Then we see the MSP Blueprint. And it starts to become more convoluted at that stage, especially if we include the descriptions of the future state, as you may expect in a Blueprint.
In the previous article regarding blueprints and missions, I highlighted that many programmes cannot have a Blueprint with a future state defined at the start. These are the programmes that are created with the specific purpose of designing the future. Having been involved with many of these, it that’s type of programme that I chose to portray, plus it takes us out of the comfort zone of works-in-theory to a zone of how-does-this-work-in-reality?
The final part is a collection of the 3 work packages. There would usually be more, but their inclusion is more to show how they’d relate to the rest of the model.
I set out to see how Business Motivation Model and MSP could be modelled using Archimate. It’s common to see the use enterprise architecture tools focus on the current state or a future state, but without easily assisting with the navigation from one state to the other, especially regarding what needs to be involved in change programmes.
There is another part of the model, on a different diagram, that I’m going to discuss in a following article. It concerns that change, from documenting the current state to showing the delivery of the business capabilities in the future state.
In hindsight, I’d like to include the plateau artifact in the main model. That would be a better solution and would replace the To-Be organisation units currently included.
Part of what I wanted to achieve was to be able to see track the response to an influence all the way from the work package and it’s change on organisational units, policies, etc up through the programme governance to the executive. And also track the reverse.
Looking at the model, we can see that you can navigate from the top to the bottom. Nothing is isolated or standing on its own. However, not all of the relationships are that useful or required to be able to connect the top to the bottom.
For instance, look at the Corporate Archimate diagram above. You’ll notice the dotted lines with arrowheads, e.g. between Changes in Legislation and Assess Impact of Legislation. That’s because that relationship is “influences”. It hasn’t defaulted to the standard of “associates with”. Archimate allows a default “associated with” for any artifacts, but it’s not always that useful and implies that you’re deviating from the purposes of the model. The straight line relationship between Forthcoming Demographic Change and Increase Market share is a good example of that “associated with” relationship. Fine if you know what you’re doing.
In our case, I’d already mentioned I’d take a bit of short-cut and only included one assessment. The point here, is that to use Archimate properly, we have to go from Influencer through Assessment to Goal. Even if an assessment is just the CEO or MD thinking it through for a few minutes, it’s still an Assessment.
Looking further down the model, we see that the goal defined in the corporate vision do not relate directly to those defined in the programme vision. They should. In fact, that’s the alignment that I’m most interested in. Instead, during the development of this model, I connected them through the MSP Mandate and Brief. Since Archi is a repository-based system, it’d be easy enough to connect them. Unfortunately for us in the model, the mandate and the brief are only connected with a the default “associated with” relationship.
So my next step is to ensure that all relationships are worth documenting by trying to avoid the default “associated with” relationship where possible.
To assist with that, I’ve been looking at different perspectives within the same diagram. Archi implements these as Viewpoints. So far, we’ve been using the default “All” viewpoint.
The first viewpoint we’re going to look at is Motivation. Using this viewpoint, we’d expect to see only the artifacts and relationships that relate to motivation, and we’d hope that this viewpoint aligns with Business Motivation Model.
As we can see, all Deliverables are now greyed out (those relating the Mandate, Brief, Mission and Blueprint). Also greyed-out are the organisational units, business capabilities, capability changes and the work packages. From a BMM perspective, all that makes sense. It also highlights the need to connect the corporate goals with the programme goals directly, separate to the programme mandate and brief.
Goal Realization Viewpoint
I also used the Goal Realization viewpoint which overlaps with the Motivation viewpoint. In addition, it greys-out stakeholders and influencers. My intention here isn’t to find the perfect viewpoint. It can’t exist since it depends on the purpose and the audience. I was intending to see what the tool can do to assist in achieving a more logical model, consistent with the underlying Archimate language.
That quest for the logical consistency and use of the model/tool segues nicely to the validation tool. I had wanted this to point towards missing relationships or where the default relationship is used. I wanted pointers to making it a better model and I’d accept better being defined in terms of adherence to the Archimate language. More ideal, would be the ability to receive pointers to a better model based on a selectable standard, e.g. Business Motivation Model, Enterprise Business Motivation Model, etc. I had in mind the way that code editors, e.g. Sublime, can provide syntax checking based on various languages.
However, the validation in Archi is simpler than that.
There is the useful highlight of duplicate artifacts and unused artifacts. Then there is the list of artifacts that do not belong in that particular viewpoint. That’s useful if you only ever want to depict a model that conforms to a single viewpoint. It’s not as useful when you’re attempting to depict a model that crosses viewpoints, such as the mix of MSP, BMM and Archimate we’ve seen in this model.
I’m going to add in the relationships between the corporate goals and the programme goals. The aim is to see a clear line from top to bottom when using the Motivation viewpoint. That’s a starting position.
I’m going to replace the future organisation units in this model with a plateau
At the moment, it would be wise to view the diagrams and model included in these articles as a draft. They are open to discussion and subject to change.
In this article, I’m going to introduce the corporate element of the BMM.
What we’ll cover
Corporate vision as opposed to MSP vision
Drivers and influencers
What we won’t cover
Risk governance, etc
Anything that isn’t related to business motivation. Archimate and Archi are capable of modelling more than just business motivation, but my scope is purely the intersection of Business Motivation, Archimate and MSP.
In the previous article, I mentioned that starting with the Programme creates some issues when integrating the chosen standards, methods and models. However it’s proven useful by highlighting the differences in levels of the models and their relative contexts within organisations.
For this article, I want to take a simplified (indeed, a very simplified view) of corporate decision making. It’s stripped-down so that we focus on how it affects Business Motivation and the use of MSP.
The external start
Our starting point is the set of Drivers that are influencing our change.
I’ve used the Archimate Driver to depict:
These can be external or internal, but the initial set that propel an organisation to change have always appeared to be external to me. These could be forthcoming legislation, changing demographics, changing technology, market dominance by a competitor, etc.
In addition, how the organisation reacts to these drivers can also be drivers, but start with the external ones first. Even in the startup domain, that external driver could be market-driven based on the market’s need for saving time and/or effort with a particular task.
I’ve only chosen to model the one set of external drivers. It would be a simple task to add in internal drivers and their relationship to the external drivers.
All of those drivers need analysing, but not all are formally analysed. In some cases, the executive will simply decide on a route forwards. In other cases, more care is required or the driver is complex and so, an assessment of that driver will be required. Typically these are performed to prepare for the advent of new legislation, e.g. The Care Act, GDPR or Brexit.
The fabricated example I’ve chosen is based on an organisation responding to changing market conditions, choosing its place in the market, and facing a potentially different market under Brexit-type changes. I’ve assumed that the executive have decided how they’ll handle the market competitor changes, but will require an assessment of the Brexit-type change. It’s rarely that simple and in fact, a goal of increasing market would appear to be naive on its own. However I’m not intending to model every facet of the organisation.
Assessments could take some time, could take a significant amount of planning and be programmes or projects in their own right. I’ve chosen not to model that part of the concept here. Programmes to execute assessments would follow the same concepts as the programmes that we’re detailing here anyway.
MSP Programme Mandate
Once the corporate goals have been set, we’d see the initiation of implementation activities. This is the early stage with the rough outlining of programmes to deliver those goals. Larger sets of goals and cross-directorate changes could indicate a higher level such as portfolios. I’m sticking with programmes for this example since Portfolios would predominantly be more of the same modelling but with a few more levels between corporate and programme.
We’ll start with the mandate which can range in detail from a rough email to a more thought-out document. This is the command to start preparing the programme.
In the diagram above, I’ve used a grey frame for the MSP Programme Mandate. This is purely visual as an aid to understand how the artefacts relate to MSP.
Inside that frame, I’ve used two Archimate Deliverables for the Programme Mandate. In doing so, I’ve assumed that the mandate is actually a document, even if it’s an email. I’d expect the Programme Sponsor or SRO to have written that mandate. However, in reality, often the SRO is assigned after the programme has been further defined, so add in a stakeholder artefact for the CFO or whoever wrote the mandate as appropriate. The mandate allows a programme manager to prepare the programme.
The first deliverable following the mandate is the Programme Brief which should flesh out the ideas in the mandate. Again, I’ve used a visual frame for the Briefs and use the Archimate Deliverable for the MSP Brief documents.
I’ve assumed a simplistic approach of one programme per corporate goal, again, not terribly realistic but doing it this way allows us to concentrate on what artefacts are required. We’re concentrating on the chain from corporate vision through to
The brief normally includes benefits, costs, timescales and risks. I usually think of this as the Business Case, so it has to include all the information necessary for a board to approve funding and permission to proceed. Depending on how you follow MSP, it may or may not include a vision. Although it’s difficult to see how it’s possible to progress beyond the brief if it doesn’t include a vision. The confusion sometimes arises since visions, especially complex, can be developed in parallel to the brief and delivered to the same board.
For the purposes here, the Brief and the Vision are separate documents, but there’s nothing to say that the Vision can’t be part of the Brief. There is no flow in this particular Archimate view, just a representation of what artefacts relate to other artefacts. The way that I’ve documented the relationships, the Vision would have to be part of the Brief in order to reference the Benefits. A potential confusion is that I haven’t placed the grey frame for the Brief around the Vision as well. Bear in mind that frame is purely a visual aid and doesn’t record hierarchy or boundary, but instead may indicate it visually.
I’ve used the Archimate Goal to represent
This was first covered in the previous article and is included here to set the context. Now we can see where we originally started (i.e. with the Programme), then started again at the top of the organisation and worked our way down to meet the Programme.
Similar to the concept of whether the vision is part of the brief or not, the placement below MSP Programme Brief does not include that they are defined later. Rather that they are separate artefacts that can be discussed separate to the Brief.
Another artefact within the Brief is the definition of how the programme will be delivered, e.g. timescales and resources required. That will show in the next article.
Also in the next article in the series, I’ll cover the Blueprint and the other elements that have been cut from the right-hand side of the diagrams so far.
I spend a lot of time around programmes that are managed with Managing Successful Programmes. I’m either in a separate architecture function, advising on changes, or sometimes in the trenches of the programmes themselves.
There’s often a disconnect between the tools and the techniques being used, especially when different team members are coming from different backgrounds with different experiences.
I’m always concerned about the why. Why does a programme exist? Why is it doing what it’s doing in the way that it’s doing it? Often that boils down to asking what problems are we trying to solve, but sometimes it’s more complex than that.
I’ve been a fan of the Business Motivation Model (BMM) for a few years and have used it successfully with clients, especially to highlight the gaps between expected benefits and portfolio/programme activities.
So I’ve been looking at a more concrete intersection of MSP and BMM and I’ve chosen Archi (based on the Archimate language) to record and display that intersection.
In common with most of the standards managed by OMG, it’s evolving on a regular basis with the current version at 1.3.
Managing Successful Programmes (MSP)
MSP originated from UK central government under the OGC, the same group that brought you Prince2. It’s now managed by Axelos who also provide more management frameworks, such as MoV, MoP and MoR (Value, Portfolio and Risk respectively).
It’s a well-respected framework and well-adopted within many larger organisations in the UK. However, like a number of standards and frameworks, there can be some confusion as to what is required at each stage. For instance, try discussing with fellow programme managers the level of benefits definition required at the brief and vision stage, or whether the vision forms part of the brief, etc. I’m going to keep clear of those discussions as much as I can within this article, so that may mean that I simplify some of the cases.
MSP has a clear route of expected documents in the early stages of a programme:
In parallel, I would expect to see benefits being managed accordingly. With those documents listed above, the task is about defining the benefits that are to be expected and a rough idea of how they will be achieved.
Archimate is an open-source modelling standard with Archi being an open-source software for working with that standard. Archimate the standard is managed by the Open Group and is designed not to be a replacement but, instead to work with your existing standards.
I wanted to use Archi, Archimate, Business Motivation Model and MSP and see how they fitted together. I had a larger aim of wondering if a combined model would assist me in explaining to my clients why uncovering the business motivation matters and that it’s so easy to lose track when you’re in the midst of large organisation-wide programme changes.
The concept of merging standards and tools isn’t new, in fact my first professional role was to map the supplier’s tool (Oracle Designer) and method to the corporate methodology (Fujitsu Macroscope).
So I’m approaching this, not with any apprehension of difficulty, but instead from a perspective of being concerned about the level of compromise necessary to integrate the tools, standards and methods.
I’d come across several articles mapping out the Business Motivation Model and Archimate, with varying degrees of success. The main issue is the granularity of goals and how that doesn’t really help with the difference between board-level goals and local, more project level goals. In a way, that may be an advantage. The best was this article at bizzdesign.com
The other issue I’m finding is that it’s not clear what’s before the fact and what’s after the fact, plus whether they relate directly or support each other. To explain, let’s consider a Benefit. I’d expect that Benefit to be defined early on in the life of a programme.
Then I’d expect to see an Outcome that relates to that Benefit. At least one Outcome, possibly more.
Firstly, the Outcome is something that happens as a result of the programme’s activities. The Expected Benefit is what’s defined early on and is realised through the Outcome(s). For me, the Outcome is the Realised Benefit.
That may seem a little awkward, but the implications become clear when you look at the Business Motivation Model and the inherent differences between Means and End. Both Benefits and Outcomes would be modelled under End. Both of them are statements about the end result. Benefits are stated before change occurs, outcomes are stated once change has occurred.
Bearing that in mind, MSP Benefits are mapped to:
Goals in Archimate and
Objectives in BMM
MSP Outcomes are mapped to:
Outcomes in Archimate and
Potential Impact (not shown) in BMM
I’ve inserted part of the Archi model below. You’ll notice the 2 grey boxes for Goals and the green box for Outcomes. These are purely visual from Archi’s perspective; providing no information in the repository about relations to elements. I’ve included them to give an indication of how the mapping could work. We see the Archimate Goals as BMM Vision and MSP Vision. That vision will incorporate content, e.g. Benefits and plans which I’ll cover more in a later article.
The starting line?
Starting with benefits and goals got me so far with the integration I wanted to achieve, but did highlight some of the issues:
Different terminology between the standards (that’s to be expected)
Different places in the organisation context (MSP’s place compared to BMM’s place)
Some of the relationships don’t seem that clear in Archimate (without every relationship resolving to the default “associated to”, but I’ll cover this in a later article)
That second issue of different places is fundamental. While MSP, BMM and Archimate cover similar ideas of drivers, goals, benefits and outcomes, the roles that those artefacts play in the organisation in each standard or method are different.
The clue is in the title, MSP is design to manage programmes, whereas BMM and Archimate cover organisation-wide and even enterprise-wide concepts. So MSP is necessarily starting part-way down the corporate structure. True, it’s near the top of structure, but there will be drivers, goals and decisions made above MSP, sometimes in MoP (Management of Portfolios).
While drivers and goals can be mapped, the main issue has been that the Business Motivation Model is an organisation-wide concept, very top down (at least initially), whereas programmes usually start one or two levels down from the executive board.
I’ll address this, with more Archi examples in the next article in this series.