Moving Beyond RACI in ITIL v3

ITIL v3 promotes the use of a convention call RACI to document the roles and responsibilities in the operation of a process. While the convention is effective, a deeper understanding of RACI and some ideas on how to more fully document it can optimize its usefulness.

Anyone exposed to ITIL v3 has come across something called RACI. It is one of the tools that v3 recommends for making sure that a process will be effective in practice. Unfortunately, the manuals don’t go into enough detail about how to get the most out of it and the documentation begs as many questions as it answers. The purpose of these articles is to fill in some of the blanks.

RACI is an acronym. The four letters represent the four different types of involvement a person or role might be engaged in for activities within the execution of a process. These four types of involvement are: Responsible, Accountable, Consulted and Informed.

Using RACI properly can go a long way to help ensure your organization fully understands and buys into a process. And that the organization is able to effectively operate that process. RACI involves drawing up a grid of all the activities in the execution of the process against all the roles that have a part to play in execution of the process and then recording what, if anything, goes on at each intersection.

Just to confuse the issue (and that is something that v3 can be very good at), the books also talk about two other variations of RACI that can be used to document the roles and responsibilities involved in the design and management of processes and services. These are described in the Design volume. Let’s leave those aside and concentrate on the operational aspects of processes.

Operational RACI

In documenting the way you want a process to operate, you would want to specify, for every activity, which roles do what. That is, which role or roles are responsible for the execution of an activity, which role is accountable for the activity, which (if any) roles have to be consulted, and which, (if any) roles have to be informed.

The convention for “Informed” and “Consulted” is that there may be any number of roles carrying “C” or “I” involvement for any activity, including none at all.

The “I” attached to any role for an activity simply means that role needs to be made aware either that the activity has started or is completed. There may be a number of reasons for this. One obvious one is if the start or completion of this activity is a trigger for another role to execute another activity or perhaps in another process.

You should be clear of course in the documentation of the activity whether this notification should occur at the start or end of the activity. To avoid any confusion and needless messages it is wise to agree with this other role why they should be informed; whether being informed is conditional on some decision point in the activity; and what they will do with this information. Formally record all of this in the process documentation.

You don’t want to throw “I”s in needlessly. If the convention you follow is that the roles with any other type of involvement for that activity will be notified of their involvement and the nature of their involvement, then it is not necessary to add an extra “I” in, as well.

(The workflow engine of your process management tool or task scheduling tool should be capable of executing all non-conditional notifications automatically. And if a notification is conditional on some decision within the activity, the tool may be able to handle that as well or you may document the necessity for the person executing the activity to make that notification.)