Responsibility assignment matrix

<h2 id="key-responsibility-roles-in-the-raci-model">Key responsibility roles in the RACI model</h2>
<h3>Role distinction</h3>
There is a distinction between a role and individually identified people: a role is a descriptor of an associated set of tasks; may be performed by many people; and one person can perform many roles. For example, an organization may have ten people who can perform the role of project manager, although traditionally each project only has one project manager at any one time; and a person who is able to perform the role of project manager may also be able to perform the role of business analyst and tester.

R = Responsible (also recommender)
Those who complete the task.<a class="footnote-ref" id="fnref:8" href="#fn:8">8</a> There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required. (See also RASCI below for separately identifying those who participate in a supporting role.)
A = Accountable (also approver or final approving authority)
The one ultimately answerable for the correct and thorough completion of the deliverable or task, the one who ensures the prerequisites of the task are met and who delegates the work to those responsible.<a class="footnote-ref" id="fnref:9" href="#fn:9">9</a> In other words, an accountable must sign off (approve) work that responsible provides. There must be only one accountable specified for each task or deliverable.<a class="footnote-ref" id="fnref:10" href="#fn:10">10</a>
C = Consulted (sometimes consultant or counsel)
Those whose opinions are sought, typically <a href="/facts/Subject-matter_expert/3kx3sVID">subject-matter experts</a>, and with whom there is two-way communication.<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a>
I = Informed (also informee)
Those who are kept up-to-date on progress, often only on completion of the task or deliverable, and with whom there is just one-way communication.<a class="footnote-ref" id="fnref:12" href="#fn:12">12</a>
Very often the role that is accountable for a task or deliverable may also be responsible for completing it (indicated on the matrix by the task or deliverable having a role accountable for it, but no role responsible for its completion, i.e. it is implied). Outside of this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of this technique in clarifying the participation of each role on each task.

<h2 id="assigning-people-to-facilities">Assigning people to facilities</h2>
The matrix is typically created with a vertical axis (left-hand column) of tasks (from a <a href="/facts/Work_breakdown_structure/JNyogLTk">work breakdown structure</a>) or deliverables (from a <a href="/facts/Product_breakdown_structure/eDVmW323">product breakdown structure</a>), and a horizontal axis (top row) of roles (from an <a href="/facts/Organizational_chart/0nwopF1f">organizational chart</a>).

Example of a responsibility assignment (or RACI) matrix<table><tbody><tr><th>Code</th><th>Name</th><th>Project sponsor</th><th>Business analyst</th><th>Project manager</th><th>Technical architect</th><th>Applications development</th></tr><tr><td>Stage A</td><td>Manage sales</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Stage B</td><td>Assess job</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Stage C</td><td>Initiate project</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>- C04</td><td>Security governance (draft)</td><td>C</td><td>C</td><td>A</td><td>I</td><td>I</td></tr><tr><td>- C10</td><td>Functional requirements</td><td>A</td><td>R</td><td>I</td><td>C</td><td>I</td></tr><tr><td>- C11</td><td>Business acceptance criteria</td><td>A</td><td>R</td><td>I</td><td>C</td><td>I</td></tr><tr><td>Stage D</td><td>Design solution</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
Another example from the maintenance and reliability community:

Maintenance crew KPI RACI chart<table><tbody><tr><th>Tasks</th><th>Maintenance supervisors</th><th>Maintenance analyst</th><th>Maintenance planner</th><th>Maintenance technician</th><th>Maintenance support</th><th>Rel specialist</th><th>CMMS project engineer</th></tr><tr><td>Inputting failure data</td><td>A</td><td>C</td><td>I</td><td>R</td><td></td><td>C</td><td>C</td></tr><tr><td>Work order completion</td><td>R</td><td>C</td><td>C</td><td>C</td><td>A</td><td>I</td><td>I</td></tr><tr><td>Work order closeout</td><td>C</td><td>R</td><td>C</td><td></td><td>I</td><td>I</td><td>A</td></tr><tr><td>QA of failure data input</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td><td>C</td><td>A</td></tr><tr><td>Analyze failure reports</td><td>C</td><td>C</td><td>I</td><td>C</td><td>A</td><td>R</td><td>I</td></tr><tr><td>Maintenance strategy adjustments</td><td>C</td><td>I</td><td>I</td><td>C</td><td>A</td><td>R</td><td>R</td></tr><tr><td>Implementing new strategies</td><td>R</td><td>I</td><td>R</td><td>C</td><td>A</td><td>I</td><td>I</td></tr></tbody></table>
<h2 id="alternatives">Alternatives</h2>
There are a number of alternatives to the RACI participation types:

<h3>PARIS</h3>
This is an early version<a class="footnote-ref" id="fnref:13" href="#fn:13">13</a> of a responsibility assignment matrix, with the roles defined as:
Participant

Accountable

Review required

Input required

Sign-off required
<h3>PACSI</h3>
This is a version very useful to organizations where the output of activities under the accountability of a single person/function can be reviewed and vetoed by multiple stakeholders, due to the collaborative nature of the culture.
Perform

The person/function carrying out the activity.
Accountable

The person/function ultimately answerable for the correct and thorough completion of the deliverable or task, and often the one who delegates the work to the performer.
Control
The person/function reviewing the result of the activity. They have a right of veto; their advice is binding.
Suggest

The person/function consulted to give advice based upon recognized expertise. The advice is non-binding.
Informed

The person/function who must be informed of the result of the activity.
<h3>RASIC or RASCI</h3>
This is an expanded version<a class="footnote-ref" id="fnref:14" href="#fn:14">14</a> of the standard RACI, less frequently known as RASCI,<a class="footnote-ref" id="fnref:15" href="#fn:15">15</a> breaking the responsible participation into:
Responsible

Those responsible for the task, who ensure that it is done as per the approver
Support
Resources allocated to responsible. Unlike consulted, who may provide input to the task, support helps complete the task.
<h3>RASI</h3>
This is an alternative version<a class="footnote-ref" id="fnref:16" href="#fn:16">16</a> of the standard RACI, foregoing the consulted participation and replacing it with:
Support
Resources which play a supporting role in implementation.
<h3>RACI + F</h3>
This is an expanded version of the standard RACI, with an additional participation type: Facilitate. This variation was introduced by Christophe Le Coent in 2012.<a class="footnote-ref" id="fnref:17" href="#fn:17">17</a> Coent argued that the facilitator or coach role is important in agile software development environments and should therefore be explicitly included in the RAM.<a class="footnote-ref" id="fnref:18" href="#fn:18">18</a> The use of RAM in Agile environments is considered contentious because some practitioners believe that everyone working in an agile team should be jointly responsible and accountable.<a class="footnote-ref" id="fnref:19" href="#fn:19">19</a>
Facilitates
Facilitate activities during a Scrum project.
<h3>RACIQ</h3>
This is an expanded version of the standard RACI, with an additional participation type:
Quality review
Those who check whether the product meets the quality requirements.
<h3>RACI-VS</h3>
This is an expanded version<a class="footnote-ref" id="fnref:20" href="#fn:20">20</a> of the standard RACI, with two additional participation types:
Verifier
Those who check whether the product breakdown structure product meets the acceptance testing acceptance criteria set forth in the <a href="/facts/Product_description/sbB9d5VM">product description</a>.
Signatory

Those who approve the verify decision and authorize the product hand-off. The signatory should be the party being accountable for its success.
<h3>CAIRO</h3>
This is an expanded version<a class="footnote-ref" id="fnref:21" href="#fn:21">21</a> of the standard RACI, also known as RACIO<a class="footnote-ref" id="fnref:22" href="#fn:22">22</a> with one additional participation type.
Out of the loop (or omitted)
Designating individuals or groups who are specifically not part of the task. Specifying that a resource does not participate can be as beneficial to a task's completion as specifying those who do participate.
<h3>DACI</h3>
Another version that has been used to centralize decision making, and clarify who can re-open discussions.<a class="footnote-ref" id="fnref:23" href="#fn:23">23</a>
Driver
A single driver of overall project like the person steering a car.
Approver
One or more approvers who make most project decisions, and are responsible if it fails.
Contributors
Are the worker-bees who are responsible for deliverables; and with whom there is two-way communication.
Informed
Those who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.
<h3>RAPID</h3>
A tool to clarify decision making roles, is RAPID, which was created by and is a registered trademark of <a href="/facts/Bain_%2526_Company/JCyGatFz">Bain & Company</a>. The scope of this tool is too narrow to be useful for assigning responsibilities in processes (despite many of the same letters in the acronym).
Recommend
The recommend role typically involves 80 percent of the work in a decision. The recommender gathers relevant input and proposes a course of action—sometimes alternative courses, complete with pros and cons so that the decision maker's choices are as clear, simple and timely as possible.
Agree
The agree role represents a formal approval of a recommendation. The 'A' and the 'R' should work together to come to a mutually satisfactory proposal to bring forward to the decider. But not all decisions will need an agree role, as this is typically reserved for those situations where some form of regulatory or compliance sign-off is required.
Perform
The perform role defines who is accountable for executing or implementing the decision once it is made. Best-practice companies typically define P's and gather input from them early in the process.
Input
The input role provides relevant information and facts so that the recommender and decider can assess all the relevant facts to make the right decision. However, the 'I' role is strictly advisory. Recommenders should consider all input, but they don't have to reflect every point of view in the final recommendation.
Decide
The decide role is for the single person who ultimately is accountable for making the final decision, committing the group to action and ensuring the decision gets implemented.
<h3>RATSI</h3>
Another tool used in organization design or roles analysis.
Responsibility
Identify who is in charge of making sure the work is done.
Authority
Identify who has final decision power on the work.
Task
Identify who actually does the work.
Support
Identify who is involved to provide support to the work.
Informed
Identify who is informed that the work has been done (or will be started)
<h3>DRASCI</h3>
A variant of RASCI developed by three Whitehall theorists (Kane, Jackson, Gilbert). This scheme is adapted for use in matrix management environments, and differs only from RASCI in having an additional role of Driver and a narrower definition of Support:
Driver
An individual or party that assists those who are responsible for delivering a task by both producing supporting collateral and setting timescales for delivery in line with the overarching aim of the individual or party who is accountable for the overall accomplishment of the objective. The distinction between driver and support lies in that the former reinforces and clarifies the parameters of the task on behalf of those who are accountable, while the latter refers to those who help those who are responsible in reaching a given goal.
<h3>PDQA</h3>
A version developed at U Tokyo and MIT for model-based project management. The PDQA set of roles corresponds to demand for capabilities of teams. Roles include those for work on scope, handling of dependencies as coordination, and exception handling through error detection and decisions across a project organization. PDQA is used in agent-based modeling to simulate the supply of these capabilities by teams in projects.<a class="footnote-ref" id="fnref:24" href="#fn:24">24</a>
Primary
Provides skill-based effort within capacity to complete scope and also manages dependencies through coordination.
Decision
Handles any decision, including scope acceptable and exception handling decisions leading to rework. (Does not generation nominal scope).
Quality
Reviews scope as it progresses to detect poor quality and escalates to decision-maker as so. (Does not general nominal scope).
Assist
Provides skill-based effort with the capacity to complete scope, in assistance to the primary. (Does not manage dependencies through coordination).
<h3>DCI</h3>
A minimal set of decision-making categories used in organisation design or roles analysis.
Decision maker
Individuals who make the decision and is accountable for its impact on the business.
Consulted
Individuals accountable for providing guidance based on functional expertise and experience, highlighting issues and raising alternatives to support the Decision Maker.
Informed
Impacted stakeholders are notified after the decision has been made and who will need to support the execution of the decision.
<h3>RASCEIO</h3>
To be used when working on governance, risk, compliance (GRC) and outsourcing matters: 

Responsible

Accountable

Support

Consult

Execute
Third parties contracted to execute activities in accordance with a service level agreement
Inform

Overview
Key GRC roles, such as risk owner, policy owner - where accountability is devolved, but a role is needed to oversee whether accountabilities all fit together
<h3>LACTI</h3>
Lead, Accountable, Consult, Tasked, Informed

<h2 id="variations">Variations</h2>

There are also a number of variations to the meaning of RACI participation types:

<h3>RACI (alternative scheme)</h3>
There is an alternative coding, less widely published but used by some practitioners and process mapping software, which modifies the application of the R and A codes of the original scheme. The overall methodology remains the same but this alternative avoids potential confusion of the terms accountable and responsible, which may be understood by management professionals but not always so clearly differentiated by others:
Responsible
Those responsible for the performance of the task. There should be exactly one person with this assignment for each task.
Assists
Those who assist in the completion of the task
Consulted
Those whose opinions are sought; and with whom there is two-way communication.
Informed
Those who are kept up-to-date on progress; and with whom there is one-way communication.
<h3>ARCI (decisions)</h3>
This alternative is focused only on documenting who has the authority to make which decisions. This can work across all sized workgroups.
Accountable
Authorized to approve an answer to the decision.
Responsible
Responsible to recommend an answer to the decision.
Consulted
Those whose opinions are sought, and with whom there is two-way communication.
Informed
Those who are informed after the decision is made, and with whom there is one-way communication.
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Diffusion_of_responsibility/yu9yQkjw">Diffusion of responsibility</a></li></ul>
<h2 id="citations">Citations</h2>

<ul><li>Project Management Institute (2021). A guide to the project management body of knowledge (PMBOK guide). Project Management Institute (7th ed.). Newtown Square, PA. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-1-62825-664-2.{{cite book}}: CS1 maint: location missing publisher (link)</li></ul>
<h2 id="external-links">External links</h2>
<ul><li><a href="https://web.archive.org/web/20100829170031/http://www.pmhut.com/?s=%22The+RACI%2FARCI+Matrix+for+Structuring+Roles+in+Project+Management%22">Comprehensive Series on RACI</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">"9.1.2.1 Organization Charts and Position Descriptions". A Guide to the Project Management Body of Knowledge (PMBOK Guide) (5th ed.). Project Management Institute. 2013. p. 262. ISBN 978-1-935589-67-9. <a href="978-1-935589-67-9" target="_blank">978-1-935589-67-9</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Jacka, Mike; Keller, Paulette (2009). Business Process Mapping: Improving Customer Satisfaction. John Wiley and Sons. p. 257. ISBN 978-0-470-44458-0. <a href="978-0-470-44458-0" target="_blank">978-0-470-44458-0</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">Blokdijk, Gerard (2008). The Service Level Agreement SLA Guide - SLA Book, Templates for Service Level Management and Service Level Agreement Forms. Fast and Easy Way to Write Your SLA. Lulu. p. 81. ISBN 978-1-921523-62-5. <a href="978-1-921523-62-5" target="_blank">978-1-921523-62-5</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">Project Management Institute 2021, §4.6.6 Focus on Value. - Project Management Institute (2021). A guide to the project management body of knowledge (PMBOK guide). Project Management Institute (7th ed.). Newtown Square, PA. ISBN 978-1-62825-664-2. <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">Cleland, David; Ireland, Lewis (2006). Project management: strategic design and implementation. McGraw-Hill Professional. p. 234. ISBN 0-07-147160-X. <a href="0-07-147160-X" target="_blank">0-07-147160-X</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Project Management Institute 2021, §4.6.6 Focus on Value. - Project Management Institute (2021). A guide to the project management body of knowledge (PMBOK guide). Project Management Institute (7th ed.). Newtown Square, PA. ISBN 978-1-62825-664-2. <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">Brennan, Kevin (2009). A Guide to the Business Analysis Body of Knowledge (BABOK Guide). International Institute of Business Analysis. p. 29. ISBN 978-0-9811292-1-1. <a href="978-0-9811292-1-1" target="_blank">978-0-9811292-1-1</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">Smith, Michael L.; Erwin, James. "Role & Responsibility Charting (RACI)" (PDF). Project Management Institute California Inland Empire Chapter. p. 5. Archived from the original on 16 September 2022. Retrieved 18 May 2023. <a href="https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf" target="_blank">https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">Smith, Michael L.; Erwin, James. "Role & Responsibility Charting (RACI)" (PDF). Project Management Institute California Inland Empire Chapter. p. 5. Archived from the original on 16 September 2022. Retrieved 18 May 2023. <a href="https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf" target="_blank">https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">Tiziana Margaria: Leveraging Applications of Formal Methods, Verification, and Validation: 4th International Symposium on Leveraging Applications Proceedings, Part 1, Springer, 2010, p. 492 <a href="/wiki/Tiziana_Margaria" target="_blank">/wiki/Tiziana_Margaria</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">Smith, Michael L.; Erwin, James. "Role & Responsibility Charting (RACI)" (PDF). Project Management Institute California Inland Empire Chapter. p. 5. Archived from the original on 16 September 2022. Retrieved 18 May 2023. <a href="https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf" target="_blank">https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
<li id="fn:12">Smith, Michael L.; Erwin, James. "Role & Responsibility Charting (RACI)" (PDF). Project Management Institute California Inland Empire Chapter. p. 5. Archived from the original on 16 September 2022. Retrieved 18 May 2023. <a href="https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf" target="_blank">https://pmicie.org/files/22/PM-Toolkit/85/racirweb31.pdf</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></li>
<li id="fn:13">A Guide to the Project Management Body of Knowledge. Project Management Institute. 2000. p. 111. ISBN 1-880410-22-2. <a href="1-880410-22-2" target="_blank">1-880410-22-2</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></li>
<li id="fn:14">Hightower, Rose (2008). Internal controls policies and procedures. John Wiley & Sons. p. 83. ISBN 978-0-470-28717-0. <a href="978-0-470-28717-0" target="_blank">978-0-470-28717-0</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></li>
<li id="fn:15">Baker, Dean (2009). Multi-Company Project Management: Maximizing Business Results Through Strategic Collaboration. J Ross. p. 58. ISBN 978-1-60427-035-8. <a href="978-1-60427-035-8" target="_blank">978-1-60427-035-8</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></li>
<li id="fn:16">Mikes, Joe; Denton, Tara (2011). Training Speeds Continuous Improvement. Life Cycle Engineering. <a href="https://www.lce.com/Training-Speeds-Continuous-Improvement-1271.html" target="_blank">https://www.lce.com/Training-Speeds-Continuous-Improvement-1271.html</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></li>
<li id="fn:17">"The RACI+F Matrix - Scrum Alliance". www.scrumalliance.org. Archived from the original on 16 October 2017. Retrieved 10 August 2022. <a href="https://web.archive.org/web/20171016061719/https://www.scrumalliance.org/community/articles/2012/june/the-raci-f-matrix" target="_blank">https://web.archive.org/web/20171016061719/https://www.scrumalliance.org/community/articles/2012/june/the-raci-f-matrix</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></li>
<li id="fn:18">"The RACI+F Matrix - Scrum Alliance". www.scrumalliance.org. Archived from the original on 16 October 2017. Retrieved 10 August 2022. <a href="https://web.archive.org/web/20171016061719/https://www.scrumalliance.org/community/articles/2012/june/the-raci-f-matrix" target="_blank">https://web.archive.org/web/20171016061719/https://www.scrumalliance.org/community/articles/2012/june/the-raci-f-matrix</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></li>
<li id="fn:19">"RACI Matrix | Definition and Example | How to". <a href="https://www.hotpmo.com/management-models/raci-matrix-definition-and-example-how-to/" target="_blank">https://www.hotpmo.com/management-models/raci-matrix-definition-and-example-how-to/</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></li>
<li id="fn:20">Blokdijk, Gerard (2008). The Service Level Agreement SLA Guide - SLA Book, Templates for Service Level Management and Service Level Agreement Forms. Fast and Easy Way to Write Your SLA. Lulu. p. 81. ISBN 978-1-921523-62-5. <a href="978-1-921523-62-5" target="_blank">978-1-921523-62-5</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></li>
<li id="fn:21">Bolman, Lee (2008). Reframing organizations: artistry, choice, and leadership. John Wiley & Sons. p. 112. ISBN 978-0-7879-8799-2. <a href="978-0-7879-8799-2" target="_blank">978-0-7879-8799-2</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></li>
<li id="fn:22">Dickstein, Dennis (2008). No Excuses: A Business Process Approach to Managing Operational Risk. John Wiley & Sons. ISBN 978-0-470-48110-3. <a href="978-0-470-48110-3" target="_blank">978-0-470-48110-3</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></li>
<li id="fn:23">Kendrick, Tom (2006). Results without authority: controlling a project when the team doesn't report to you. AMACOM Books, division of the American Management Association. p. 106. ISBN 0-8144-7343-1. <a href="0-8144-7343-1" target="_blank">0-8144-7343-1</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></li>
<li id="fn:24">Moser, B. R.; Wood, R. T. (2015). "Design of Complex Programs as Sociotechnical Systems". Concurrent Engineering in the 21st Century. Springer. pp. 197–220. doi:10.1007/978-3-319-13776-6_8. ISBN 978-3-319-13775-9. <a href="978-3-319-13775-9" target="_blank">978-3-319-13775-9</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></li>
</ol>

Responsibility assignment matrix open-in-new

Responsibility assignment matrix