|
说道项目管理中的推诿责任的问题，自己现在想想投头大，不是自己项目的锅还要背的情况也是时有发生。自己背锅不说，主要是拖慢项目进度啊。（进度慢了，我啥时候才能拿钱啊） 我们经常会遇见的推诿的场景： 推诿场景一经理，里程碑计划我编好了，需要发送给谁?谁来确定? 经理，质量部的人说项目的质量体系他们不负责写，只负责监督审核，怎么办? 经理，客户打电话投诉，说咱们上个月月度例会的会议纪要没有发给他们，您看怎么处理? 推诿场景二一个完整的项目策划书，在完成了项目背景分析、项目目标界定、项目经理任命、项目团队组建、项目范围分解之后，接下来应该做什么？ 以上一系列的问题，都可以交一个我们都知道的简单项目管理工具来解决，那就是责任分配矩阵! 别看这个管理工具简单，起的作用那是一点都不小。 责任分配矩阵，了解一下责任矩阵（也称RACI）可以简洁明确地显示出项目人员的分工情况。通过责任矩阵,项目的各项工作都能落实到具体的责任人，避免责任不清而出现的无人负责、推诿现象。   责任分配矩阵是针对项目范围WBS分解出来的工作，将工作的责任在组织内进行分配。 什么时候制作责任分配矩阵?只有项目计划具备了两个基本条件后，才能制定责任分配矩阵： 第一个条件：项目的WBS已经编制好了。 第二个条件：涉及到项目中的人员/部门都已经清晰明确了。 这两个条件缺一不可。 具体如何使用，步骤如下：1.确定工作任务和决定事项（做什么） 确认关键性商业流程、功能、决定或活动，进一步分析这些流程与活动，视需要再细分成细项工作。此部分将成为RACI矩阵之最左垂直栏目（橙色部分）。  细化工作项目时应用动词开头描述工作内容，如评价、计划 、书写、记录、 操作、 检测、 准备、收集、批准、 更新、执行 等， 避免列入简单的工作如：“参加会议”等。 2.准备参与者的职责清单 (谁做） 确认需介入的人员、职位或部门，列成RACI矩阵之上端水平栏目（红色部分） 。 3.初步建立RACI 表 建立角色与责任草图。先与少数决策者进行，将RACI排入矩阵图之中间部分。 4.获得反馈，达成协议 召集所有参与人员，召开ARCI会议。说明、沟通、并解决矩阵“草图”中在流程/次流程、活动/次活动、人员/职位角色，及RACI责任分配中的问题与建议，达成共识。 5.表格分析与检查 （1）横向分析（针对某一工作项目做分析） 如果没有R：工作没人做，大家等着要批核、被咨询、被告知、没人把工作当成自己的，除了A外。 如果没有A：没人总其成并负全责。A是有资格限制的，但只要资格相符， A应尽量往更下阶层选任，以适才适任，并权责相符。 如果太多C：真的需要这么多“顾问”吗？顾问咨询也意味着时间流失、成本增加，确实值得吗？ 如果太多I：真有这么多人需要正式、定期告知？应以实际的工作需求性为基准订定，不是因为他是“三朝元老”。 如果太多A：只能有一个A。超过一个A，常属过渡期或特殊例。  （2）纵向分析（针对各个人或部门的责任分配状态做分析） 如果太多R：这个人真能够、也确需要，执行这么多工作吗？这些活动可否进一步拆解或简化，以更利管理？ 如果是满格：这人需要介入这么多活动吗？C可否降为I？ I可否取消？ 如果没A没R：如果这是一个直线而非幕僚职位，应考虑废除或增强这人/职位的功能？ 如果太多A：有适当授权吗？这人是“以天下兴亡为己任”？确需日理万机？有些A可退为C或R，甚至I吗？ 6.建档并公告，投入执行 建档已成共识的RACI矩阵责任图，制定执行职责表的起始时间。复本分送所有参与者及相关支持部门，公告周知，确定所与知悉此事。 7.后续强化追踪 继续在后续会议中沟通、强化RACI责任图解，及当责的责任观。确保ARCI关系的正常运作，鼓励参与人员遵守该有的角色。如有需要，则在过程中重审角色与责任，重建责任图解。 |
|
|
