A significant challenge for any large business improvement program is how to enlist the senior stakeholder community into the change program and keep them engaged. Senior stakeholders can be relied on to show an interest in the change program when it starts, but their interest will often fade as “business as usual” issues dominate the day-to-day operations.

Then, as the business improvement program progresses, the change team becomes mired in the detail and withdraws into their own world. They spend their time looking at data, completing risk reviews, agreeing the way forward, mapping processes, and preparing papers that will describe the desired outcome. The longer this goes on, the more introspective the change program becomes and the less the senior stakeholders are engaged by the change program.

The seasoned change agent knows that change is not sustainable without tangible support from senior stakeholders, and that getting the senior managers to change their daily routines, habits, and behaviours is very difficult. And it becomes more impossible the longer their behaviour is left unchallenged. The reason it goes unchallenged is that the change team believes that until they have worked through the detail, they don’t have anything meaningful to say, and they don’t want to waste the senior managers’ time.

The problem is that the senior managers run the company, not the change program. It is important that they stay engaged. But if the change agent is going to engage the senior managers, then they need to be able to frame the conversation and have an agenda.

When it comes to change, there is no better agenda than talking to managers about what they are or aren’t accountable for. If you can’t get a manager to agree on their own accountability, then you can be sure that the outcomes of the business improvement program will be less than optimal.

There are many models that support a conversation on accountability. The most common is the R.A.C.I. (RACI) model. It is a simple model, but the practical application of this model is beset with problems, the biggest of which is the question of what the acronym actually stands for.

The generally accepted definition is that it refers to: Responsible, Accountable, Contributor (or Consulted), and Informed.

This definition is misleading. The “A” cannot stand for Accountable as all four dimensions have accountability. A manager is accountable for being informed or contributing. It is not the job of the change agent or process performer to inform management. It’s management’s job to ensure that they are informed. The business holds them accountable to be informed. How can you manage if you are uninformed?

In the same sense, managers are accountable for approving a process outcome. This means they need to know what the outcome should be, what control points they should have considered, and what delegations of authority might apply. If the manager plays an active role in the process, then they are accountable for being responsible for doing their part of the process properly.

In terms of a business improvement program, when the change team approaches a manager designated as a Contributor for comment, that manager is accountable for making time and providing a well-thought-out contribution to the discussion.

Apart from the confusion arising from the fact that all four variables have accountability, there is a second misunderstanding about the RACI model, namely that it only applies within a business process.

Consider the graphic below. When RACI is applied within a process then it can be argued that the Supervisor approves the process outcomes, Role 1 is responsible for Steps 1 and 2, Role 2 contributes to Step 1 and Role 3 is informed by Role 2.

While it is acceptable to use the RACI model within a business process, it is equally acceptable to apply it to, or on, a business process. The difference between the two applications is significant and it makes a material difference in how each term is defined.

When applied to a process, RACI is used to define the architectural elements of the process rather than the transactional accountabilities within a process.

Consider the following scenario.

The managing director walks out of his office after losing a major tender. He turns to the sales director and asks, “Who designed the tender process? Who in their right mind thought that process would be suitable for us to win a tender?”

What he has not asked is, “Who filled in the tender response form? Who participated in the tender process?” Doing that would be to question the transactional aspects of the process. Rather his focus is on determining who the architect of the process was. Who designed the process, who approved it, and who can he hold accountable to ensure the process weakness is resolved and that the next tender is more successful?

Applying RACI on the process changes the definition of the terms as follows.

Responsible – accountable for designing the process.

Contribute – accountable for working with the Responsible person to design a process that was fit for purpose.

Informed – accountable for understanding how the new process works and how it impacts the informed manager’s work environment.

Approve – accountable for signing off that the process is fit for purpose. That when it is followed, it will deliver optimal outcomes. This role owns that process.

In essence, the managing director is asking his team, “To what extent did you apply yourselves as senior managers to ensuring the process your staff were following, was fit for purpose?”

Using these definitions of RACI means that the supervisor (who was previously the Approver) now may become an informed party only and the manager’s manager will approve the process.

The supervisor’s manager is more likely to be Responsible as the architect of the process. While the manager is Responsible for designing the process, it does not mean that they will necessarily do the work. Possibly they will delegate it back to the supervisor, but in this case, delegating the task does not equal delegating the accountability.

The two scenarios, in the process versus on the process, illustrate that depending on how RACI is applied, it will deliver very different levels of management accountability and they could be at opposite ends of the management spectrum. Supervisor versus manager’s manager. Using the single term “Approve” for both situations is going to confuse the organisation and it raises the question: does the organisation want its processes approved by supervisors? It is reasonable to expect that this would not be the case.

The complexity between the two applications of RACI is increased when you consider that it is common for process flows to be modelled against roles and not positions. One position can play many roles. So when RACI is used in a process, it does not necessarily give accountability to a specific position. Rather, any position that happens be performing that role in that instance of the process becomes accountable. The burden this places on the organisation is significant. Just consider the training needs. Then there is the problem of process flows with process steps straddling the lines of responsibility or swim lanes and the issue of mixing roles and positions in process flows. These issues make defining accountability in the process level very confusing.

When RACI is applied on the process, it is applied to positions not roles thereby mitigating the above issue.

The difficulty of working with RACI is exponentially increased when applied to a matrix management organisation. Simplistically, matrix organisations can be broken down into service functions such as Human Resources, IT, Quality, Safety, Health, and Environment, Legal, and Finance, and the do work functions such as Operations, Work Winning, Logistics, Maintenance and Repair, and Customer Service. The service function will define the processes for the do work functions to use. A good example is the Quality, Safety, Health, and Environment function.

The processes defined by the Quality, Safety, Health, and Environment function are used on the shop floor by the do work teams. This means that the quality function is accountable for defining and approving quality management processes that will be used by a completely different function. The RACI model just doesn’t cater for this level of sophistication. When you try and use it across the multiple silos of a matrix organisation it quickly becomes apparent that it just does not have enough variables to account for the organisational complexity and what is required is a different model for defining management accountability.

The best alternate model I have seen is the Linear Responsibility Matrix (LRM) methodology by Anthony Walker.

It is not my intention to repeat Anthony Walker’s methodology here. What follows is my own interpretation of his methodology.I claim no rights to the methodology and I acknowledge Mr. Walker’s ownership of the underlying intellectual property.

My interpretation of the LRM recognises ten functions with accountability. The original methodology had eleven.

1. Responsible
   • Accountable for defining the process flow and associated artefacts.

2. Approve

1. • Accountable for signing off the process flow and associated artefacts.

3. Contribute

1. • Accountable for working with the Responsible person and helping design the process.

4. Informed

1. • Accountable for being informed on how the process works and the requirements of any artefacts associated with the process.

5. General Oversight

1. • Accountable for ensuring the process architecture is appropriate and fit for purpose.

6. Direct Oversight

1. • Accountable for guiding the Responsible person.

7. Recommendation

1. • Accountable for reviewing the process and ensuring it is fit for purpose. Once satisfied, this role endorses the process for final approval by the approver.

8. Monitor

1. • Accountable for ensuring each instance of the process works as designed in the day-to-day environment.

9. Maintenance

1. • Accountable for ensuring the process is being used as designed. It is quality control.

10. Boundary

1. • Accountable for addressing areas of overlap in scope.

 

The word “process” in these definitions refers to the process appropriate to the level of management. At the senior level, it is the various value chains: Budget to Report, Contract to Cash, Procure to Pay, Hire to Retire etc. At the lower levels, the process is the transactional flow of a specific sequence of work. For senior management, the word “process” in the definitions can be substituted with specific items such as Policy or broader concepts such as the Governance Model for the organisation or a function.

This methodology is particularly powerful when working with matrix management organisations and the single biggest point to embrace is that the LRM is always on the process. It is never in the process.

In a matrix model, when it comes to defining the operating model for the service functions, the ten accountabilities can be loosely split between the service functions and the do work functions. On a per instance basis, this allocation could change.

What this means is that the change program cannot work with each function in isolation of the other functions and importantly, the other functions do not have leeway to say, “Not my job.” Rather the change agent should be establishing cross-functional teams based on the above separation of accountability to drive the change program and ensure the organisation gets a result that is sustainable and agreed.

Having ten functions with accountability gives the change agent a much wider scope for discussing the accountability of each and why senior management have no option but to become further involved in the business improvement program. You will note the first four functions with accountability largely correspond to RACI when RACI is applied on the process.

A senior manager would readily admit that when it comes to their function, the buck stops with them, but when pushed, it is often the case that these managers cannot easily describe what they are actually accountable for.

The ambiguity is because the names of functional areas (e.g. Quality, Safety, Health, and Environment) do not include verbs. Without a verb, defining the deliverable becomes very difficult. And if you can’t describe the verb at the parent level, then defining the verb for the children and grandchildren levels becomes very difficult.

“Well, if you do that, then what do I do?”

I am not suggesting that the names of functional areas are rewritten to include verbs. Rather, for the purpose of defining management accountability, the verb is inferred. By agreeing the verb, you can agree the deliverable, and only then can you agree the management accountabilities.

For the function Quality, Safety, Health, and Environment consider the difference between the following two verb/deliverable combinations:

It is accepted that the verb/deliverable combinations are not necessarily mutually exclusive and there is natural overlap between them. The verb sets up the focus for the function and will directly impact the way the function sees its role in the organisation and the culture that is established within the function.

The table can now be extended to bring in management accountability. Note how the accountability changes depending on the deliverable being sought.

When the verb is to monitor the Quality, Safety, Health, and Environment function, then the Quality, Safety, Health, and Environment manager cannot approve the deliverable as this would be a conflict of interest. In this case, using the reporting lines in the organisation chart above, only the CEO can approve that the Quality, Safety, Health, and Environment governance model is working effectively. At the senior levels, the do work manager will be watching proceedings to ensure the Quality, Safety, Health, and Environment governance model does not become an unnecessarily large administrative burden on the day-to-day operations of the business.

But if the verb was to deliver Quality, Safety, Health, and Environment, then the Quality, Safety, Health, and Environment manager could approve that the function was working as designed. This is because the deliverable has an operational focus and the senior Quality, Safety, Health, and Environment manager is expected to be the approver. It’s part of the description of the position. The responsibility for delivering Quality, Safety, Health, and Environment on a day-to-day basis moves to the operations function as this is where the work actually happens.

If the verb was transform, then it is unlikely that the CEO would have the authority to approve the new operating model. This is where the LRM methodology really comes alive, as it brings in positions that sit outside the obvious reporting lines and the function accountability table needs to extend to allow for the additional account abilities.

For transform, the Board is now accountable for approving the new operating model for Quality, Safety, Health, and Environment. The CEO can only recommend the new model up for approval, but they will not do so unless they know the senior team has been consulted on the design of the new model.

For deliver, the quality manager is accountable for maintaining the integrity of the Quality processes within the organisation. The senior do work manager is responsible for ensuring the do work function are using the Quality, Safety, Health, and Environment processes across the entire organisation and, in this example, the country manager is accountable for monitoring that the Quality, Safety, Health, and Environment processes are being followed on a daily basis.

For monitor, the CEO is unlikely to approve the governance model unless it is recommended to him for approval by the legal counsel and the country manager. Recommending it for approval implies that they have reviewed it in detail and consider it fit for purpose.

The LRM model is also useful for defining accountabilities within a function.

The following uses the Quality, Safety, Health, and Environment structure referred to above. It has four levels.

The table illustrates how the accountability for Approve and Responsible changes as you move to the lower levels in the organisation.

Each organisational level requires a verb and a deliverable and there should be a natural relationship of deliverable between the organisational levels. It is implied that the accountability of other relevant positions will be included as required.

It is important that Responsible is not delegated below manager level and accountability for Approval is held at the level of manager’s manager or higher.

Organisational level 4 is typically the transactional level in an organisation. This is the level where the business process is operationalised. This requires the supervisor to monitor the process to ensure it is working as defined and correct it as required when the process deviates from design. Maintenance by comparison would be carried out by a representative of the function that designed the process. For example, Quality or Safety.

It is not necessary to recognise all ten accountabilities for each function or process as it will make the model overly complex and confusing. Rather, it is easier to work with the implied hierarchy between the accountabilities and use the dominant accountability. For example, there is no need to state that a manager who is recommending a process for approval is also informed. It stands to reason that they would not recommend something they were not informed on. The same applies for consulted and recommend. It is highly unlikely a manager would be asked to recommend a model they had not been consulted on, in the definition phase.

When defining which positions require to be informed, the “less is more” principle is relevant. Sure, everybody needs to know about changes, but these changes will be rolled out through the organisation structure. All that is required is to define which managers must be formally informed of the changes.

What these management accountability models achieve is to cause the business to change itself.

Without this level of accountability, the responsibility for the success of the change program will, in practice, fall back to the change team, allowing management to point fingers and attribute blame for failure. There is no doubt that change will take longer to achieve when management are correctly held to account, but equally, there is no doubt that the benefits will be sustainable and owned by management when they are forced to be actively involved throughout the change journey.