Those at the top of an organisation, once a degree of size and complexity is reached, can’t know what everyone does and nor should they. Roles become more and more specialised and technical. The beauty of management is you don’t need to do everything. You just need to know that someone “has it” and is delivering. This is a highly uneasy concept for lots of people, especially those who have founded a business or are over controlling. The fear of giving up control or not having complete control can paralyse many people.
The other issue is the time and effort it can take to actually build the processes and activities (or objectives), and then to go through the effort to link all those elements to roles or people. This can be seen as overwhelming and in the “too-hard-to-do” bucket, or in the, “we started it, but didn’t manage to finish it”.
There are some practical tactics that can avoid these common traps.
1) At any level of the business, you can make significant progress just by establishing three core linkages: people, roles and processes. Who are the people, what roles do they fulfil and what do they do
2) Keep it simple – cascade the top 3-levels
3) The Tarzan moment – get across from one ‘tree’ to the next to establish the value
4) Don’t try to get a perfect mind-map in one go. Get it good enough, then improve with time
5) Iterate the process as more detail is added.
I’m going to use processes as the example, but the logic applies equally to objectives. Start with the process you have in mind, e.g. People processes, i.e. all the things that need to happen to recruit, develop, pay, engage, reward, promote, people. Within “People” therefore, there may 7 elements as depicted in the below diagram. We call each element within the hierarchy a “node”.
Each node can be broken down into more detail and it subsequent parts. For example, performance management might have objective setting, Appraisals and Performance Improvement.
This process can continue and continue with further and further detail.
Cascading works by starting at the top and only defining 1-3, but ideally 2, levels below that top. If each node has an average of 5 children, this means creating 31 nodes, which is a very manageable number. In terms of an organisation, that allows you to define the processes and people two down from the chief executive, and to define the top 30 or so activities that the organisation carries out. That’s enough for the organisation to see the value in mapping responsibilities and roles to people.
In terms of making this practical, the idea is to define enough detail to get the ball rolling, and then move down to the next layer to follow the same process.
Let’s exaggerate an example in order to further make the point. There could be a process called “Feed Staff”. Imagine this in the context of a canteen. ’Feed staff’ can be broken down into 5 main areas: Manage the canteen; Buy the food and other required goods and services; Prepare everything; Serve it and Clean. From this, each element can be further detailed. For example, if you took “Prepare”, then this could be broken into “Meat”, “Vegetables” and “Sauces”. These can be further broken down, and then again and again and again.
It is possible to break this down until you reach the point of absurdity. One could imagine, under the process of slice thin fries, could be further broken into, sort potatoes, align them, cut….
It is important to remember what the goal of the exercise is – i.e. to help define what each role is responsible for and what the role is. It isn’t to define exactly how each role should be done into minute by minute blocks. The context is equally important. If it is a tiny canteen with only one person running the whole canteen, the “Feed Staff” would suffice in terms of detail. However, if it is a large operation with hundreds of people, and the level of specialisation goes down to teams responsible for slicing specialised fries (instead of buying them in, this is all clearly theoretical), then perhaps in an extreme example, this would be fine.
Process or Roles? Chicken or Egg?
Process definition should NOT be driven by organisational structure thinking. However, organisational structure can be driven, to a large extent, by process design. Equally, the higher up the process tree, the higher up the organisational tree the accountability for that “node” is likely to be. So running a top-down cascading process supports a top-down approach.
If we continue with the People process to HR team structure example, start with the HRD and his/her direct reports. Define the main elements, i.e. 3-levels down/depth of 3 or circa 31 nodes. Assuming a management team of 7, this means splitting the 31 nodes into 7 or on average defining 4-5 key areas of accountability – (this example is with a fairly large HR team of an organisation with 10,000+ employees who support a large number of divisions).
Once the first tier is done, then break it down to the next level. The HRD might be involved in this still, but it is unlikely to be to the same extent. Imagining a team of 35 people the next level down (average span of control of 5), then this is again another 4-5 key areas per role.
If all the children from a node are allocated to one role, then this is an indication too much detail is being defined. Only keep on going as long as it helps to define who will be doing what – NOT exactly how someone should do “their job”. Using the feed staff example, if one person is responsible for preparing all the food, then stop at “prepare”. It shouldn’t be necessary to detail all the steps of “food preparation”.
If all the children are below a single team or function, then think about letting the person responsible for that area (team or function) define all those subsequent accountabilities. In other words, think about empowering the leader of that area to define how they should organise their team in order to meet the objectives that have to cascaded to them. Again, as Daniel Pink points out, autonomy is one of the main motivators. This doesn’t mean, leave them to it. Help them by coaching or supporting a workshop with the team or helping them think through the process. Micro design isn’t a skill that is the preserve of OD practitioners, HR Business Partners or management consultants. It is a skill that all business leaders should have, as it is, in our view, a core business skill.
A real life example: A number of years ago now, I led the organisational design of a large multinational drinks company in Europe. The scope was their supply chain and non-line workers (non-hourly) with about 1,000 employees within this scope. In doing the design, we detailed about 900 processes and activities for about 300 roles – or an average of 3 “nodes” per role, albeit, some roles where responsible and others supported. So the number of links was in the region of 3,600. One of the activities (nodes) within this 900 list was “Master Data Management”. A few years after the design and implementation of the new organisation, I was requested back to do a short piece to look at the Master Data Management processes and structure. This was a team of circa 10 across Europe and the question was, how many should be in the team and how should it work? What was 1-line/node in the pan-Europe supply chain set of processes and activities quickly become a subsequent 100+ nodes. On reflection, we probably detailed the Master Data Management into too much detail. But the point is, what was one node was in fact a summary of many additional levels of detail. In doing the pan-Europe design, I believe we got the level of detail about right. This didn’t stop a further subsequent detailing to take place when needed a number of years later.
The point is, start easy. Start at a top level – albeit, this does not necessarily mean at the top of the entire organisation, just the top of part of the organisation within the scope. Detail a couple of levels and define the accountabilities from here. Then run this process again and again for the parts that still need to be defined. See this as an iterative and cascading process.
Post Script – what about a bottom-up approach?
The first answer is, yes, this is possible and even has many advantages. The second and more relevant answer is, how?
The way to do this, I believe, is through an Individual Activity Analysis (an IAA). An IAA is an analysis of how much time each person spends on each activity. To get everyone (within scope) to detail what they do and how much time they spend doing it. The best way to do this is through a web survey.
And again, how?
I believe you still have to start with a view of the activities. Begin with a “straw man”, to be built on rather than a blank piece of paper. In an hour or two, with a couple of knowledgeable people, flip charts and post-it notes, a straw man can be thrown together and then structured. Once done, a relevant person can then add new activities that have been missed and provide an estimate of the amount of time. This is a non-trivial exercise. First is the fear, why is this being asked? The second is to work out who should complete the survey and whether or not it should be a sample for roles that have multiple numbers doing them. It could be the manager, assuming they know? It could even be conducted as an audit or through a structured interview process. The point is, the data should be collected in an analysable way and iterated. This way each person completing the analysis can add to the lists of activities that are missing. These can then be structured from this bottom-up into a series of hierarchies. Refer to the IAA section within the process chapter for more detail.
The last way is to use the job descriptions. To take each of the responsibilities from each job description and create a view of the As-Is. The big issue here is that job descriptions are almost never robust. They are used for recruiting purposes and there is rarely enough proper thinking in ensuring the elements are (in their entirety) completely exhaustive. But it can be a good way to get started and/or to build a case for doing the job properly. It can also give or be a reason for doing the exercise in the first place. It is pretty reasonable to want to understand how people spend their time and what they feel they are accountable for. As a last thought, if the bottom-up approach is going to be used, it might be an idea to ask how they think their time should be used? What they should be doing? What they feel is inefficient or inappropriate in what they are currently doing? What would the impact be of taking away a list of barriers or their 1-2 main barriers?
The process we followed with one client, as a first exercise with their HR team:
We did this first, mapping the HR structure using their existing data set and confirmed it with the HR team. There were about 10 changes to the structure of around 80 people.
Set out the processes in a MECE structure. Start from the top and do three levels as a starter. We used a standard set of HR processes as a starting point, which were then adapted by the HR team to be more suitable to their own ways of working.
Understanding responsibilities: mapping Positions to Processes
R: Responsible is the key one
Use this for mapping out who is responsible for what.If you do nothing else, this is the basis for understanding the organisation and people’s responsibilities
S: Support is 2nd most important
This is relevant for mapping out the weight of workload. Someone who is nominated as supporting 20 activities has (crudely) a heavier workload than someone who is supporting only 5 activities As a first rough cut, this is an effective way of understanding the work being allocated to the team
A: Approve. This is the 3rd most important
Vital for understanding and communicating who has the key signoffs in the business. We used OrgVue to teach the HR team how to map their top 3 levels in positions and processes. They started the process in the training room. Continued with print outs to work on paper for a period. Then came back to the OrgVue software to load up their linkages into the datasets and carry out simple analytics on the results. Questions like – who is responsible for the most things? Or the ‘orphans’ question: Are there some people not responsible for anything? Are there some processes which do not have an owner? Or the weight of support question: who is it that we all turn to for support?
Latest posts by Rupert Morrison (see all)
- What’s the Difference Between Target Operating Model and Organisational Design? - October 20, 2017
- RACI, RASIC, or RAPID – throw-out the complexity - October 20, 2017
- Organisation Design vs Organisation Development - October 20, 2017