What is a RACI Chart

Keeping everyone aware of the part they play

It is no secret that if everyone knows what is expected of them and what tasks they are expected to be involved with, in some capacity, any project will run much better. Without this clarity, the only thing you are left with, as the Project Owner or Project Manager, is confusion and people blaming others for lack of action.

One way of achieving clarity is a RACI chart (pronounced Ray-See). This document needs to be agreed right at the beginning of the project or process and subsequently signed off by all the major contributors. This will prevent the constant stream of ‘My team doesn’t do this’ or ‘that person is overstepping their responsibility’ with the project descending into chaos.

What is a RACI?

A RACI chart is a project document that lays out all the roles and responsibilities tracked against all the tasks and deliverables. Although fixed and agreed at the beginning, it also needs to be a dynamic document that can flex with personnel movements and scope changes.

It should not be confused with other frameworks such as RAPID (Recommend, Agree, Perform, Input, Decide) and DACI (Driver, Approver, Contributor, Informed) as these are focussed more on decision making rather than the management of the Project.

What does RACI Stand for?

Although widely adapted by individual organisations, RACI is an acronym for Responsible, Accountable, Consulted and Informed. There are many variations such as including S for Supportive, and each has its own merits, but the general baseline is just RACI. This is then used to create a matrix of roles against tasks and deliverables which will help team members and others understand what is expected of them.

Responsible

This defines who in the team actually carries out the work or ensures that their team does. In a RACI chart there could be more than one role defined as ‘Responsible’, but this does not happen often.

Accountable

This is a single role who delegates work and approves any deliverables before they can be signed off as completed. It is quite possible that this role is shared with ‘Responsible’ on a RACI chart, but it is vital that all tasks have an accountable person. Depending on the task, it is likely that this is not always the Project Manager.

Consulted

This person will be part of the review process or provide input to the development process due to their Subject Matter Expertise in a particular field. An example would be an Engineer providing context on IT equipment use from an Industrial Control perspective.

Informed

This is normally a stakeholder, member of the Leadership or someone with Approval responsibility, who wants and/or needs information/data about the Project. Having this informed person/role will ensure internal transparency and management of accurate project timelines.

RACI Chart blog image

When to use a RACI

Now that the different parts of the term have been explained, it is equally important to understand when it is appropriate to use a RACI framework. Normally a RACI would be established and agreed at the start of the project. This will set clear expectations and allow all involved to understand the communication process.

Another time when a RACI chart provides clarity is when it is used in a complex project with multiple teams and team members. This reduces the risk of overlapping responsibilities and assumptions of accountability by others. This is also the case when restructuring occurs as it provides stability around role responsibilities and can be used as part of onboarding new project team members.

One final use for a RACI chart is during project reviews and/or stage gate approval meetings. The chart will ensure that responsibilities and accountabilities are maintained (especially if the new phase brings in new staff). This also allows for review of those accountabilities/responsibilities and reassignment, if necessary, i.e. on scope change.

Pros and Cons

As with any documentation there are many benefits and limitations including (but not limited to): 

  • Clarity in roles and responsibilities which can help minimise misunderstanding, overlap and tasks not being carried out.
  • Allows for centralised communication of project related information.
  • There is a danger that teams may rely too heavily of the RACI which could lead to missing out vital communication and PM tasks.
  • Helps to clarify task involvement but does not provide guidance on how the task is performed which could lead to inconsistencies.
  • As a final ‘other’ use for a RACI chart is to assign accountabilities and Responsibilities in artifacts such as an Incident Response Playbook which remove any confusions regarding carrying the vital tasks due the time-critical response processes.

With all these in mind, there is a real need to keep the chart simple and easy to use. Be mindful of the fact that the chart may be used by staff whose first language is not the business language. All RACI charts should be regularly reviewed and updated as the Project flexes; and stored in a central document repository where it can be accessed by all. Staff should always be notified of any major changes so that they are not making decisions relying on an outdated version of the document.

Building a RACI Chart

The key factor to the creation of any RACI chart is to accurately reflect the tasks and the roles within the work.

  1. Identify Tasks – sounds easy! Outline the key tasks but then properly analyse this so any residual sub-tasks can be documented too.
  2. Discuss and identify the key roles – For this stage it is useful to utilise a template otherwise people will submit whatever they feel! This should include what the staff member feels is their role as well as exploring what others feel that person’s role is – they may not agree!
  3. Draft the RACI – once completed in draft format, socialise. There is always a danger that this rapidly becomes a ‘turf war’ as people will get very protective of what they feel they should do and shouldn’t. This part of the exercise needs strong facilitation and guidance.
  4. Analyse any gaps – No matter how well it all goes, there is going to be a few gaps that were not obvious at the start. Ensure that a single role doesn’t receive too much and, where possible, spread the workload in a logical way. Try and limit the number of ‘Rs’ as it could create confusion and, in the same way, limit the ‘Cs’ and it will allow for conflicting opinions which will need to be managed.

Summary

To summarise, the following points will help reduce the pain:

  • Keep it simple! – The chart needs to useable so keep it straightforward and make sure everyone understands what it is and how to use it (bearing in mind some staff may have a different first language!!)
  • Make sure you include the team – By utilising all the team, they will feel engaged and understand how flexible the document is. This will help with communication across the project.
  • Keep it up to date – Regularly review and update the chart to keep paces with staff changes and project phases. This may also involve regular liaison with other teams e.g. HR to verify that roles are current. Schedule reviews/updates at every project stage gate.
  • Follow the Change Management process – All changes should be documented, approved and communicated.
  • Be Consistent – Make sure all your charts, roles and tasks are kept consistent. This will necessitate the creation of clear guidelines for creation and use that needs to be followed by all. This will also include consistent storage mechanisms with appropriate access controls (especially important for contractor/third party access)

Author: Tim Harwood, Siker CEO