As part of our campaign to get organisations to document their ITIL®/IT Service Management processes we are focusing this blog on the RACI matrix. I’ll explain why it’s important to consider this aspect when undertaking process design.
A RACI matrix is a key part of your overall process documentation, and on an activity by activity basis it maps on to the process stakeholder roles, helping to clearly define when a particular role should be involved at each activity within the process.
Firstly, What Does RACI Stand For?
For effective and efficient Service Management, it’s essential to establish clear definitions of accountability and responsibility within your IT Service Management processes.
To help with this task the ‘RACI model or ‘authority matrix’ is often used within organisations to define the roles and responsibilities in relation to processes and activities. The RACI matrix provides a compact, concise, easy method of tracking in relation to who does what in each process and it enables decisions to be made with pace and confidence.
RACI is an acronym for the four main roles:
Responsible - The person or people responsible for correct execution – for getting the job done
Accountable - The person who has ownership of quality and the end result. Only one person can be accountable for each task
Consulted - The people who are consulted and whose opinions are sought. They have involvement through input of knowledge and information
Informed - The people who are kept up to date on progress. They receive information about process execution and quality.
When using RACI, there is only one person accountable for an activity for a defined scope of applicability. Several people may be responsible for executing parts of the activity. In this model, accountable means end-to-end accountability for the process. Accountability should ideally remain (but not always), with the same person for all activities of a process.
Director Service Management
Service Level Manager
The RACI chart above shows the structure and benefits of RACI modelling. The rows represent a number of required activities and the columns identify the people who make the decisions, carry out the activities or provide input.
Whether RACI or some other tool or model is used, the important thing is to not just leave the assignment of responsibilities to chance or leave it to the last minute to decide. For example, if there is a transfer of a service from one service provider to another, RACI models should be designed in the service design lifecycle stage, and tested and deployed in service transition. In service operation, people assigned to specific roles will perform the activities in the RACI matrix.
The Rules Of RACI
When designing a service or a process, it is important that all the roles are clearly defined. A trademark of high-performing organisations is the ability to make the right decisions quickly and execute them effectively. Whether the decision involves a strategic choice or a critical operation, being clear on who has input, who decides and who takes action will enable the organisation to move forward rapidly and with confidence.
A key characteristic of a process is that all related activities need not necessarily be limited to one specific organisational unit. Service asset and configuration management process activities, for example, can be conducted in departments such as computer operations, system programming, application management, network management, systems development and even non-IT departments such as procurement, warehouse or accounting.
Since services, processes and their component activities run through an entire organization, the individual activities should be clearly mapped to well-defined roles. The roles and activities are coordinated by process managers.
Once detailed procedures and work instructions have been developed, an organization must map the defined roles and the activities of the process to its existing staff. Clear definitions of accountability and responsibility are critical success factors (CSFs) for any improvement activity. Without this, roles and responsibilities within the new process can be confusing, and individuals will revert to ‘the way we’ve always done it’ before the new procedures were put in place.
To help with this task the RACI model or ‘authority matrix’ is often used within organisations to define the roles and responsibilities in relation to processes and activities. The RACI model provides a compact, concise, easy method of tracking who does what in each process and it enables decisions to be made with pace and confidence.
How To Create A RACI Matrix
To build a RACI chart, the following steps should be followed:
1. Identify the individual processes activities (using SIPOC – ‘see our SIPOC Blog’)
2. Identify and define the roles within the process
3. Conduct meetings with stakeholders and assign the RACI codes
4. Identify any gaps or overlaps – for example, where there are multiple As or no Rs (see analysis below)
5. Distribute the chart and incorporate feedback
6. Ensure that the allocations are being followed.
Analysis of a RACI chart to identify weaknesses or areas for improvement should include considering both the role and activity perspectives.
Potential problems with the RACI model:
Having more than one person accountable for a process means that in practice no one is accountable
Delegation of responsibility or accountability without necessary authority
Focus on matching processes and activities with departments will lead to confusion as the focus should be on roles.
Incorrect division/combination of functions; conflicting agendas or goals
Combination of responsibility for closely related processes, such as incident management and problem management or service asset and configuration management, change management and release and deployment management. Combining responsibilities can in some cases reduce the checks and balances that support good governance or could overload some staff members performing a combined role.
Once developed you should validate your RACI matrix by applying role and activity analysis as described below…
Role analysis involves looking at the roles in the RACI matrix and asking:
Are there too many As: Are duties segregated properly? Should someone else be accountable for some of these activities? Is this causing a bottleneck in some areas that will delay decisions?
Are there too many Rs: Is this too much for one role or function?
No empty spaces: Does this role need to be involved in so many tasks?
Also, does the type or degree of participation fit this role’s qualifications?
Activity analysis involves considering:
Is there more than more than one A per row?: only one role can be accountable
Are there no As?: at least one A must be assigned to each activity row
Is there more than one R per row?: all too often too many roles being defined as responsible often means that no one takes responsibility. Responsibility may be shared, but only if roles are clear
Are there no Rs?: at least one role must be responsible.
Are there too many Cs?: Is there a requirement to consult with so many roles? What are the benefits and can the extra time be justified?
Why are there no Cs and Is?: Are the communication channels open to enable people and departments to talk to each other and keep each other up to date?
It’s important to understand the distinction between a formal function such as the Service Desk or Technical Management within an organisation and the process roles that the individuals in that function are expected to carry out, such as Service Desk Manager or Service Desk Analyst.
Staff within a formal function may fulfil more than one specific service management role and carry out activities relating to more than one process. For example, an individual with the job title of ‘network administrator’ is responsible for carrying out incident management as well as capacity management activities. Although the network administrator may report to a different functional line manager, they are also responsible for carrying out activities for the service desk function and capacity management process owners.
Developing an authority matrix can sometimes feel like a tedious and time-consuming exercise but it is a crucially important one. The authority matrix clarifies to all involved which activities they are expected to fulfil, as well as identifying any gaps in service delivery and responsibilities. It is especially helpful in clarifying the staffing model necessary for improvement.
Going Beyond Just RACI…
Some organisations use the RACI definitions, but switch the order to Accountable, Responsible, Consulted and Informed or ARCI, but the meanings and usage remain unaltered, although ARCI does sound ruder…
Occasionally an expanded version of RACI is used, called RASCI, where the ‘S’ represents ‘Supports’ or ‘Supportive’. This role provides additional resources to conduct the work, or plays a supportive role in implementation, for example. This could be beneficial for IT service implementation.
Another variation of RACI is RACI-VS, with two further roles as follows:
Verifies - The person or group that checks whether the acceptance criteria have been met
Signs Off - The person who approves the V decision and authorizes the product handover. This could be the ‘A’ person.
The choice is yours… RACI, ARCI, RASCI or RACI-VS…
When applying the RACI model to a process, typically only one person should hold end-to-end accountability for the process, typically this is the process owner. Similarly, there is only one person accountable for any individual activity, although several people may be responsible for executing parts of the activity.
The RACI matrix below shows the structure and power of RACI modelling. The rows represent a number of required activities and the columns identify the people who make the decisions, carry out the activities or provide input.
An Example RACI Matrix (Based On Part Of A Change Process)
Release And Deployment Manager
IT Management Board
Business Executive Board
Activity within procedure:
Determine level of risk:
Level 5 – standard change
Level 4 – low-risk change
Change manager authorization
Level 3 – affects only local or service groups
RFC to CAB for assessment
Level 2 – affects multiple services or organizational divisions
RFC to IT management board for assessment
Level 1 – high-cost/high-risk change
RFC to business executive board for assessment
Yes – go to 2.1
No – go to 3.1
CAB members estimate impact and resources, confirm priority, schedule changes
Not authorized – go to 3.1
Authorized – go to 3.2
RFC rejected and closed
(initiator informed with a brief explanation of why it was rejected)
Change is scheduled for action through release and deployment
Key: R = responsible; A = accountable; C = consulted; I = informed; RFC = request for change; CAB = change advisory board; ECAB = emergency change advisory board
What Else Can We Use The RACI Matrix For?
The RACI (authority matrix) can help with two major activities that are often overlooked or hard to identify.
One use is that all the ‘Rs’ on an RACI matrix typically represent potential OLA opportunities. Where OLAs are Operational Level Agreements between internal teams of an organisation. They are regularly overlooked but are vital to ensuring that SLAs (Service Level Agreements) can be met.
The second activity is that of identifying roles that must be kept informed ‘I’. This helps us to expose communication and workflow paths. This can be very helpful when developing communications plans and help define the communication procedures within CSI activities.
This article is based on ‘Best Practice’ guidance as documented in the AXELOS core ITIL® guidance books and other sources.
ITIL® is a registered trade mark of AXELOS limited, used under permission of AXELOS Limited. All rights reserved.