How to use RACI charts to define service desk roles and responsibilities
Using a management tool called RACI charting can help IT managers simplify the daunting task of clarifying the roles and responsibilities of the service desk.
One of the most difficult challenges facing the service desk is identifying who has the skills and knowledge needed to resolve an incident. Another equally daunting challenge is knowing who has the decision-making authority to effect change in the runtime environment -- for example, server IPL. In many organizations, this can vary from day to day and shift to shift, especially if the service desk is distributed or virtual.
Typical service desks that follow one of the popular information technology service management (ITSM) frameworks, like Information Technology Infrastructure Library (ITIL), are required to use a standard incident management process. Creating and continually improving the incident management process requires that service desk managers identify who is responsible for specific actions and decisions. One way to simplify this process is to use a management tool called RACI charting.
RACI charts, which date back to the 1950s, were originally called linear responsibility charting or LRC. This type of charting is used to pin down who does what and who is responsible for certain activities. The method was conceived by Dutch consultant Ernst Hijams and developed by Canadian consulting firm Leethan, Simpson, Ltd.
RACI charts are widely used by project managers and accounting auditors. The Project Management Institute refers to RACI charts as a responsibility assignment matrix, but COBIT 4.1 uses the acronym RACI.
Table 1: Some RACI definitions
| Role | Role Code | Definition |
|---|---|---|
| Responsible | R | This role conducts the actual work/owns the problem. There can be multiple R's. |
| Accountable | ||
| A | This role approves the completed work and is held fully accountable for it. There should be only one A. | |
| Consulted | C | This role has the information and/or capability to complete the work. Two-way communication (typically between R and C). |
| Informed | I | This role is to be informed of progress and results. One-way communication (typically from R to A). |
| Supportive | S | This role provides additional resources to conduct the work or plays a supportive role in implementation. |
| Verifies | V | This role checks the work to ensure that it meets all defined criteria and standards. |
| Signs | S | This role signs off on the completed work. |
There are several variations of RACI, including:
- ARCI which is RACI in a different order.
- RACI-VS or VARISC which expands RACI by adding verifies those who check the criteria, and Sign off, those you approve the decision.
- CAIRO or RACIO which is RACI reordered with the addition of O for "out – of –the- loop".
- RASCI which subdivides the Responsibility role into Responsibility, those who are responsible, and Support, those who help the responsible role execute the action.
So how can a Windows IT manager use RACI? Start by laying out the chart. Identify the roles across the top, and list the activities down the side. Next, assign one of the RACI role codes at the intersection of the role and the activity. The finished chart identifies who does what in the process and who is really responsible for the specific activity and its outcomes.
Figure 1: RACI example
| Incident Management/Process Roles / Activities/Within Process | Incident Process Owner | Incident Manager | Tier 1 Support | Tier 2 Support |
| Process Planning | A | R | I | I |
| Training | A | R | I | I |
| 1.0 Incident Detection and Recording | Not applicable | A | R/I | I |
| 2.0 Classification and Initial Support | Not applicable | A | R | C/I |
Once the responsbilities for the specific actions and decisions are identified, the smoother the process will flow, especially if you use a software tool such as Microsoft's Service Desk.
For users, the service desk is the most important ITSM function. The service desk is the single point of contact for users, and it owns all incidents through their lifecycle. To help manage incidents, some service desks that follow ITSM frameworks establish three lines of support:
- First-line support: This is typically a call taker equipped with a knowledge base to identify known errors and workarounds. Microsoft's Service Desk software supports the handling of incidents and service requests.
- Second-line support: This includes experts from the knowledge silos -- for example, technical management, application management and IT operations management. Depending on the maturity of the information and communication technology (ICT) function's ITSM program, they may be part of the service desk or a resource that first-line support reaches out to for assistance. In mature ICT functions, second-line support is focused on root cause analysis and spends very little time at the service desk.
- Third-line support: This is made up of vendors that the organization has contractual arrangements with, including hardware and software companies like Microsoft and IBM.
Remember, the goal of incident management is to restore service as quickly as possible to minimize business impact. This requires the incident management process to flow smoothly and deliver results. RACI is a management tool that takes the guesswork out of who does what. When users are calling, speed and results are essential.
More on RACI charting:
For a real-world example of RACI or ARCI charting, visit the state of North Carolina's Office of Information Technology Services Operational Excellence Program Web site. Each ITSM process description contains an ARCI chart.
Stuart D. Galup is an associate professor of computer information systems at Florida Atlantic University. He is a Certified Computing Professional and ITIL Service Manager. He has held a number of senior information technology positions and holds a U.S. patent. Galup has written more than 45 academic publications and two books.
