That CSF is clarity around the roles and responsibilities for each project participant and key stakeholder. No matter how detailed and complete a project plan may be for any project, confusion or omission of participant roles and responsibilities will cause major problems.
This is the first assessment I conduct when addressing a project rescue. In almost 100 percent of these rescue efforts, I have found that there is no shared understanding of participant roles and responsibilities, nor is there explicit documentation to support it. Establishing such a consensus almost always gets a stuck project moving again, and enables the key stakeholders to readily deal with the other issues that require resolution.
The simplest and most effective approach I've seen and used to define and document project roles and responsibilities is the RACI model. Integrating the RACI model into an organization's Project Life Cycle (PLC) creates a powerful synergy that enhances and improves project outcomes.
[]
The RACI model brings structure and clarity to describing the roles that stakeholders play within a project. It is a matrix to clarify responsibilities and ensure that everything the project needs done is assigned a "doer."
To apply the RACI model, you list every task, milestone or key decision, then clarify who is Responsible, who is Accountable, and where appropriate, who needs to be Consulted or Informed. The acronym RACI stands for the four roles that stakeholders might play in any project:
People or stakeholders who are the "doers" of the work. They must complete the task or objective or make the decision. Several people can be jointly Responsible.
Person or stakeholder who is the "owner" of the work. He or she must sign off or approve when the task, objective or decision is complete. This person must make sure that responsibilities are assigned in the matrix for all related activities. Success requires that there is only one person Accountable, which means that "the buck stops there."
People or stakeholders who need to give input before the work can be done and signed-off on. These people are "in the loop" and active participants.
People or stakeholders who need to be kept "in the picture." They need updates on progress or decisions, but they do not need to be formally consulted, nor do they contribute directly to the task or decision.
The simple process for creating a RACI model includes the following six steps:
1. Identify all the tasks involved in delivering the project and list them on the left-hand side of the chart in completion order. For IT projects, this is most effectively addressed by incorporating the PLC steps and deliverables. (This is illustrated in the detailed example below, after the simplified version immediately below.)
2. Identify all the project stakeholders and list them along the top of the chart.
3. Complete the cells of the model identifying who has responsibility, accountability and who will be consulted and informed for each task.
4. Ensure every task has at least one stakeholder Responsible for it.
5. No tasks should have more than one stakeholder Accountable. Resolve any conflicts where there is more than one for a particular task.
6. Share, discuss and agree the RACI model with your stakeholders at the start of the project. This includes resolving any conflicts or ambiguities.
Resolving conflicts and ambiguities involves looking across each row and up and down each column for the following:
Analysis for each stakeholder:
Does one stakeholder have too much of the project assigned to them?
Does the stakeholder need to be involved in so many of the activities? Can Responsible be changed to Consulted, or Consulted changed to Informed? I.e., are there too many "cooks in this kitchen" to keep things moving? (And if so, what does that say about the culture within which this project is being managed?)
Does each stakeholder totally agree with the role that they are specified to play in this version of the model? When such agreement is achieved, that should be included in the project's charter and documentation.
Analysis for each PLC step or deliverable:
Who is doing the work in this step and getting things done? Whose role is it to take the initiative?
Is this another sign of too many "cooks in this kitchen" to keep things moving?
Who is Accountable? There must be one 'A' for every step of the PLC. One stakeholder must be Accountable for the thing happening -- "the buck stops" with this person.
Is there confusion on decision rights? Stakeholders with accountability have the final say on how the work should be done and how conflicts are resolved. Multiple A's invite slow and contentious decision-making.
Do all the stakeholders really need to be involved? Are there justifiable benefits in involving all the stakeholders, or is this just covering all the bases?
Do all the stakeholders need to be routinely Consulted, or can they be kept Informed and raise exceptional circumstances if they feel they need to be Consulted? Too many C's in the loop really slows down the project.
Sometimes this is more of a challenge to ensure, as it's an error of omission. This is often best addressed by a steering committee or management team.
It is the above analyses, which are readily enabled by the use of the RACI model, that deliver the real benefit of the model. It is the integration of the model with a specific PLC that ensures that the project is structured for success. Without either component, problems with the structure of the project management process may remain hidden until (or even while...) they cause the project to bog down. Making the time and effort to create a customized PCL/RACI for each significant project is an opportunity to design your project management process for project success.
Here's a much more detailed example of a PLC with RACI model. This is specific to one company's IT PLC and key stakeholder groups. As such, you would need to replace their PLC along the left-hand vertical axis with your own PLC. You would also need to replace their stakeholder groups or functions along the top horizontal axis with your own stakeholders. Please note that this version also specifies project documentation artifacts that support each step of the PLC.
Bob Kantor is an IT management coach and consultant, specializing in improving IT leadership effectiveness. He welcomes your comments and suggestions. Reach him at KantorConsultingGroup.com
Follow everything from CIO.com on Twitter @CIOonline, on , and on .