We've been having some discussion this week on organisation design governance. By this we mean how do we get oversight of all the different organisation design work going on in our large organisation? We want this in order to have confidence that the various design work is all headed in the same direction. It is all too easy to design within silos not taking into account that design in one part of the organisation could have unintended consequences in another part.
I've also had a mini-lesson this week in agile methodology, specifically about user stories. A user story is 'part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.'
User stories are a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a type of user, I want some goal so that some reason.
That set me thinking about applying the concept of personas to developing the organisation design governance we're after: can we apply the concept of user stories to help us get to appropriate governance? I think purists in one of the many tribes of agile (or indeed of persona development) would have a view, but in the way of daily back-to-back meetings I didn't get a chance to find one of them to ask. Since I'm more of the pragmatic than purist bent I asked myself and replied that it's worth a go.
One of the first questions seems to be around who is the 'user' of the product/service, and who is the 'customer' of it. I'm not totally clear on the distinction. I think a user is the person who actually uses it and the customer is the person who buys it for the user. Apparently you need to develop a persona (*see para below) for each as they have different wants. (Forget that Steve Jobs didn't believe people know what they want.) Then you choose a primary persona for whom to design the product or service – or in our case, governance . I still need to learn how you make that choice but that must be in lesson two.
*Oh – but I've just discovered that there's a difference between a 'user description' and a 'persona'. So apologies for all who have read so far and are clear a) that the two nouns mean completely different things and are therefore irritated by my ignorance or b) that they have no idea that the two nouns are not synonymous and are enjoying the read. (You can see I am an agile beginner although tomorrow I am putting myself down for the agile awareness course – I hope it tackles 'user description' v 'personas').
However, I think I'm on reasonably safe ground if I say that for all five user titles listed below I have specific individuals in mind with whom I have had many conversations so they may fulfil the 'persona' definition – though I yet I haven't systematically or in a detailed way researched their want. Take it that they are part way between a 'user description' and a 'persona' for the rest of this piece, and I'll continue to use the terms synonymously.
Now I need to identify the user of organisation design governance. It seems that the persona must also be a single individual. It's not good enough to develop a persona for the split personality of the 'leadership team' (considered as one unit). For organisation design governance users might be:
- Organisational CEO: I want all organisation design work to be clearly aligned to deliver the goals of the business strategy so that I don't have to keep reminding people we are one organisation and not a bunch of autonomous units.
- Chief HR person: I want to feel confident that organisation designs pay close attention to the people elements so that so that we have the right people in the right place at the right time doing the right things.
- Chief auditor: I want to be convinced that each organisation design piece of work is effectively controlled and monitored so that I can identify any financial or other risks associated with it.
- Business owner of design project: I want my organisation design to be quick, efficient, affordable and deliver the intended benefits so that I can get on with running the business successfully.
- Organisation design consultant: I want information on all organisation design work to be available so that business leaders and other consultants can learn from each other's experience and the methodology can be continuously improved.
It's necessary to identify the primary user/customer in order to get a sufficiently focused product/servce. Identifying the customers of organisation design governance is not so straightforward. Who is buying it for the users? In this case the person 'buying' the governance could be the Board of the organisation but it could also be the CEO, but he/she is also a user of it. Additionally the governance process is usually being developed by the organisation design consultants who are also users of it. So there does seem to be a degree of split personality in these personas, or at least, as in real life, they play different roles. There's a helpful presentation on how to manage this complexity of handling a user who has multiple roles from Jeff Patton of Agile Product Design.
Noticeable about the persona/user types that I've skimmed through is that no-where have I seen a grumpy, negative one who firmly states what he/she doesn't want – on the lines of 'I don't want to spend time on non-value add governance stuff so (onerous) that I feel ready to throw in the towel.' (Explanation of that phrase here). Or 'I don't want hordes of people coming around poking their noses into the way I run my business so that I feel I've lost all accountability and choice.'
So I'll fill in the gap here. I think it's safe to say that what no user (or persona) wants is governance that is onerous, tightly controlling, and requires checklists, RAG ratings, audits, and other forms of assessment. We already have those 'up the Wazoo' as the saying goes. If you're not familiar with that phrase you can look it up here. (Meaning 2 in the entry). We want appropriate organisastion design governance – but we're not yet quite sure what that is.
However, we have an outline to discuss with each of our presumed users. (It is August's tool for the month). One way of developing the governance approach is the agile way of 'test and learn' through developing minimal viable product. But that's a topic to come.
Meanwhile – who do you think are the users of organisation design governance and how would you identify/choose your primary one? Let me know.
Naomi Stanford 