跳转到主要内容

RACI矩阵是定义项目角色和责任的一种简单、有效的方法,提供了一个全面的图表,显示了每一步谁负责、负责、咨询和知情。

在管理和拯救了数十个项目,并帮助其他人这样做之后,我注意到,总是有一个关键的成功因素(CSF)被有效地解决或遗漏/混乱:每个项目参与者和关键利益相关者角色和责任的清晰性。无论任何项目的项目计划多么详细和完整,参与者角色和责任的混淆或遗漏都会导致重大问题。

输入RACI矩阵。我所见过并用于定义和记录项目角色和职责的最简单和最有效的方法是RACI模型。将RACI模型集成到组织的项目生命周期(PLC)中可以产生强大的协同作用,从而增强和改善项目成果。

什么是RACI矩阵?

RACI矩阵是一种责任分配图,它列出了完成项目所涉及的每项任务、里程碑或关键决策,并分配了负责每个行动项目的角色、负责的人员以及需要咨询或通知的人员(如适用)。首字母缩写RACI代表利益相关者在任何项目中可能扮演的四个角色。

在几乎100%的救援工作中,我发现,对参与者的角色和责任没有共同的理解,也没有明确的文件支持。通过采用RACI模型建立这样一个共识几乎总是让一个陷入困境的项目再次前进,并使关键利益相关者能够随时处理需要解决的其他问题。

RACI矩阵规则和角色

RACI模型为描述利益相关者在项目中扮演的角色提供了结构和清晰性。RACI矩阵明确了责任,并确保项目需要完成的所有工作都由专人负责。

利益相关者在任何项目中可能扮演的四个角色包括:

  • 负责人:完成工作的人员或利益相关者。他们必须完成任务或目标或做出决定。几个人可以共同负责。
  • 责任人:作为工程“所有者”的个人或利益相关者。当任务、目标或决定完成时,他或她必须签署或批准。此人必须确保在矩阵中为所有相关活动分配职责。成功要求只有一个人负责,这意味着“责任到此为止”
  • 咨询:在工作完成和签署之前需要提供意见的人或利益相关者。这些人是“圈中”和积极参与者。
  • 知情:需要“了解情况”的人员或利益相关者。他们需要进度或决策的更新,但不需要正式咨询,也不直接参与任务或决策。

如何创建RACI矩阵

创建RACI模型的简单过程包括以下六个步骤:

  1. 确定交付项目所涉及的所有任务,并按完成顺序在图表左侧列出。对于IT项目,通过合并PLC步骤和可交付成果,可以最有效地解决这一问题。(下面的示例对此进行了说明。)
  2. 确定所有项目干系人,并在图表顶部列出他们。
  3. 完成模型的单元,确定每个任务的责任、问责和咨询对象。
  4. 确保每个任务至少有一个利益相关者负责。
  5. 任何任务都不应该有一个以上的利益相关者负责。解决特定任务中存在多个冲突的任何冲突。
  6. 在项目开始时,与利益相关者分享、讨论并同意RACI模型。这包括解决任何冲突或歧义。

RACI矩阵示例

为了简化,假设您的项目可以分为四个独立的任务,由一个应用程序开发团队,以及一个项目主管、项目经理、业务分析师和技术架构师共同承担。

该过程的第一步涉及将项目规划为一个整体。为此,项目经理对手头的工作既负责又负责。为了确定项目的范围和可交付成果,项目经理与项目的执行赞助商和业务分析师就作为项目的一部分要彻底检查的流程进行协商。技术架构师和应用程序开发人员随后被告知项目计划。

在第2步中,业务分析师必须更深入地研究流程,以帮助规划出要彻底检查的业务流程的各个方面。因此,业务分析师负责这项任务,项目主管负责签署这项工作。为了更好地理解当前流程的技术基础,业务分析师将咨询技术架构师。然后,项目经理和应用程序开发人员将被告知项目这一部分得出的结论。

以下是此示例项目的简化RACI模型的示例,其中考虑了前两个步骤:

simplified raci matrix model chart cio

随后的第三和第四项任务涉及塑造新流程,同样由业务分析师负责这项工作,团队中的其他角色在第二步分析旧流程时也承担同样的责任。第四步是由技术架构师接管,设计支持新流程的新架构,由执行发起人签署,并由项目经理负责,项目经理设计了第1步中的范围和交付成果。

RACI矩阵模板

对于那些希望开始使用RACI模型的人,可以在web上免费获得模板。这些通常面向Microsoft Excel或Google Sheets,但也可以用于更专业的软件。以下是几种流行的可能性:

RACI矩阵最佳实践

仅仅创建RACI矩阵是不够的。您必须确保矩阵映射到成功的战略。在这方面,必须解决计划中的冲突和模糊之处。

解决RACI矩阵中的冲突和歧义涉及查看每一行和上下每一列的以下内容:

对各利益相关者的分析:

  • 是否有太多的R:一个利益相关者分配给他们的项目是否太多?
  • 没有空单元格:利益相关者是否需要参与这么多活动?是否可以将“责任”更改为“咨询”,或将“咨询”更改为通知?一、 例如,是否有太多的“厨师在这个厨房”来保持事情的进展?(如果是的话,这对项目管理的文化有何影响?)
  • 认同:每个利益相关者是否完全同意他们在该模型版本中所扮演的角色?达成此类协议后,应将其纳入项目章程和文件中。

每个PLC步骤或可交付成果的分析:

  • 无R:谁在做这一步的工作并完成工作?谁的角色是采取主动?
  • 太多的R:这是不是另一个“厨房里的厨师”太多而无法让事情继续发展的迹象?
  • 没有A:谁负责?PLC的每个步骤必须有一个“A”。一个利益相关者必须对正在发生的事情负责——“责任在这个人身上”。
  • 不止一个答:决策权是否存在混淆?负责的利益相关者对如何开展工作以及如何解决冲突拥有最终发言权。多个A会导致决策过程缓慢且有争议。
  • 填写的每个方框:所有利益相关者真的需要参与吗?让所有利益相关者参与是否有合理的好处,或者这只是涵盖所有基础?
  • 许多C:是否需要定期咨询所有利益相关者,或者如果他们认为需要咨询,是否可以随时通知他们并提出例外情况?循环中的C太多确实会减慢项目的速度。

是否所有真正的利益相关者都包含在该模型中:有时这更是一个挑战,因为这是一个遗漏错误。这通常最好由指导委员会或管理团队解决。

项目管理中的RACI矩阵

正是上述分析,通过使用RACI矩阵很容易实现,提供了模型的真正好处。模型与特定PLC的集成确保了项目的成功。如果没有任何一个组件,项目管理过程的结构问题可能会一直隐藏,直到(甚至在…)它们导致项目陷入困境。花时间和精力为每个重要项目创建定制的PLC/RACI,是为项目成功设计项目管理流程的机会。

本文:https://cioctocdo.com/raci-matrix-your-blueprint-project-success