Posts from the ‘Accountability’ Category
In this podcast interview we discuss how the Requisite Organization approach can be applied to address complex role/reporting issues. Paul Tremlett is a consultant with CORE International in Canada.
Before listening to the podcast, it may be helpful to take a look at the brief cases that I wrote last week and that we use as a starting point for the discussion.
Some of the things that we touch on are:
- Requisite Organization (RO) as a broader management system
- The combination of fundamental principles and situational judgment
- The importance of diagnostics in the organization design process
- Why it is necessary to do a full costing of a proposed structural model
- Why there are no “dotted lines” in an organization designed according to RO principles
- Why asking “who should report to whom” may not be the right question if you want to resolve role/reporting issues!
If you want more information about the Requisite Organization approach, take a look at the website of the Global Organization Design Society.
Podcast: Play in new window | Download
I am not asking about how many pages or slides you need to show the “boxology” – that is, who reports to whom – which usually requires only one page. What I am thinking about is the number of pages you need to explain:
- Who delivers what to whom
- Who collaborates with whom
- Who lends resources to whom
- Who decides what
A real example – drawn from an internal document – is shown below. This is an attempt to clarify the roles in a major UK bank. My first impression was that it seemed like a rather good example of how one could clarify the roles of an organization. When there is confusion with regards to roles and responsibilities, managers and employees usually welcome efforts that can help clarify who is responsible for various decisions and tasks. A matrix like this may be a good pedagogical tool.
But when examining the document a bit more closely, I noted that the matrix contains no less than 245 cells (5x7x7) as the responsibilities (“Approach”, “Inform”, “Advice”, etc. along the top) depend not only on the particular phase in the sales process but also on the channel and product. The accompanying Word document explaining the logic of the chart shown above runs to more than 60 pages. And we are still only talking about one of the issues mentioned above – who decides what. I assume that it would require several hundred pages to fully describe the organizational model of this bank.
One may wonder whether employees are able to internalize and enact a model that is this complex. If nothing else, it is hard to communicate a model that have a lot of contingencies and exceptions to a general rule (“Unit X is normally responsible for customer contact, but if it is a segment B client requesting service 1 for Region 2, then Y is responsible, and if it is a segment C client requesting service 2 in Region 3, then Z is responsible, except when the client already has a relationship with X…”).
In my experience, a better approach is to start by looking at the overall organizational model and consider whether it can be simplified. Are goals in conflict? Are there overlapping unit mandates? Does the formal structure match the work processes? Do we know who’s the internal client, and who’s the internal supplier? If the overall model is clear, logical, and simple, there’s usually less of a need for detailed specification at lower levels.
I am not suggesting that one should practice “simplification by ignorance”. Complexity will not go away by refusing to describe it (for example, by only presenting a new organization design by means of an organization chart showing reporting lines, leaving out other important aspects, and asking employees to find their way through the maze one has created.) If it really takes 60 pages to describe roles and responsibilities in your organization, that is the number of pages you should use. But if you have a choice between two models, one that can be explained in 10 pages and one that requires 60, select the former.
In most large organizations, there will from time to time be a need to clarify roles and accountabilities. In many cases, this happens in a dialogue between the individual employee and his or her manager. But a more concerted effort may be needed when there’s a lack of clarity with regard to two or more roles at the interfaces between units. Typically, the most significant issues tend to arise:
-
Between different business areas or units
-
Between the headquarters and local units /subsidiaries
-
Between internal service providers (e.g., IT, Operations) and the business areas or units
When there’s ambiguity about roles or overlapping decision rights, it usually results in slow decision making and /or frequent escalation of issues to higher level management.
In such cases, it can be useful to create a process where the managers concerned develop a shared understanding of how roles, accountabilities, and decision rights are to be allocated.
There are a number of simple tools that can be used for this purpose. The most well-known is the RACI framework (Responsible, Accountable, Communicated, Informed), Another variant, more focused on decisions rather than processes, was proposed in an HBR article*. It’s called RAPID (Recommend, Agree, (Provide) Input, Decide, and Perform). The result from a workshop where this framework is used may look something like the list below. In this particular example, one has selected three critical decisions areas to consider. It has been decided that the VP of Engineering is the formal decision maker when it comes to manufacturing specifications, that the VP Operations decides when it comes to capacity allocation (although VP Engineering must agree), and that the regional presidents in the company decide with regard to product pricing (but based on recommendations from Marketing).
In many cases, applying such a framework should help clarify roles and accountabilities that have become diffuse over time.
At the same time, my experience is that these frameworks are rather simple and provide little guidance in terms of resolving more complex role conflicts. After all, they are really only tables or list – the idea is that by specifying roles in more detail, you achieve clarity.
For some roles at the interfaces between units, it’s often difficult for the managers who hold such roles to remove any role conflicts themselves – authority or decision rights will need to be re-allocated in order to resolve the issues; and that can only be done by involving higher level management. More serious role conflicts at lower levels of the organization may also be caused by complexity of the overall organization design or a more general lack of clarity about the purpose and mandate of different units in the company.
In these cases one may have to take a step back and consider what the overall mandate of the units concerned are. For example, if there are questions related to the autonomy of subsidiaries related to the headquarters, one should consider what the governance philosophy of the company is, and how management views the role of the HQ in relation to local units. If there are issues related to the interface between IT and the business units, one needs to consider whether IT is supposed to be an internal supplier, or whether IT is expected to act with more authority (for example, in order to implement common standards and reduce costs).
The specification of roles in the format indicated above sometimes becomes an almost trivial exercise when such fundamental issues have been resolved. For example, if the key purpose is to have global consistency, it becomes obvious that manufacturing standards should be set centrally rather than locally. If IT is supposed to be an internal supplier, it is clear that IT cannot dictate what IT services the rest of the company are supposed to consume but that it must listen to its customers – the business units.
***
Overlaps and gaps with regard to roles is one of several examples of complexity in large organizations. I have written a textbook on how to simplify complex organizations where I provide in-depth analysis of these issues. You can download a chapter from the book for free here:
http://www.scribd.com/fullscreen/55347862?access_key=key-2jw7613x6tf4a67rvpfx
I acknowledge helpful suggestions from Carlos Henao who I discussed these issues with recently.
*Rogers, P. & Blenko, M. (2006). Who has the D? Harvard Business Review, January,1-8.
