项目管理之项目沟通和任务分解

标签：纠正   功能需求   决定   分解   需求   负责人   理解   相关   crm   

功能需求即最终用户和利害攸关者要求产品所拥有的明显的日常需求。

项目阶段是两个主要项目里程碑之间的时间段。组织在实施项目时，通常会将每个项目分解为几个阶段，以便更好地管理和控制。

而任务则是交派的工作，是项目经理按照项目进行的需求进行分解，将任务分派给不同的人员，并确定每个任务的起止时间，根据任务的完成情况再进行时间和内容调整，并将时间报给客户
关键词：沟通、利害攸关者、项目阶段 项目任务分解

案例一：
XXX方案确认，阶段任务目标时间2020.3.20，最后确认签字，到2020.3.27日完成，延期一周。前期完成情况都比较好，直到截止日那天，还是觉得任务已经完成，大家都已经确认，缺少了个别人员的签字也只是因为“人不在现场的原因，没法落实”而已。结果到了第二周，拿着方案去给关键人员(销售、财务部门负责人)落实签字时，才被告知，对方案还有疑惑。之后又经过了一周的时间，进行解读、调整、沟通确认的工作循环，才完成了确认，导致阶段完成延期一周(本可以避免的)。
项目心得：
原因分析：

1. 盲目乐观
   ? 阶段前期的工作进展比较喜人，有了过于乐观的预期，提前放松了
   ? 只听取超级用户单方面的确认反馈，没有再深入跟踪
   ? 忽略了事情的复杂度，错误评估了客户对于细节的重视程度(细节指 我们预设的非重要项，我们更关注和系统相关的，却忽视了非系统相关点的一些细节说明)
2. 舒服了过程，只会痛苦了结果
   方案确认时，因为超级用户沟通较多比较熟，更易攻克，所以先攻克了；与之相对应的部门负责人，却因为时间难约以及说服起来更难，所以把任务更多的下放给了超级用户去执行。最后的结果，部门负责人还是需要我们自己重新再去攻克，却白白浪费了不少时间。
   项目解读：
3. ”超级用户”和“部门负责人”都是方案的利害攸关者，项目沟通时要确保事件的利害关联方的都要触达。
4. 如果“不在现场”的这部分人可以采用事先邮件”书面沟通“，之后再”口头沟通“的方式，可能遇到的问题和阻力会减半。

5. 如果甲方已经和项目经理沟通过的这部分人，在企业内部对方案能启用”上行沟通“，主动汇报的沟通方式，项目经理的工作也会顺畅很多。

   案例二
   xxx项目，根据合同条款，以“方案确认”作为节点的付款有两笔：Sage X3+CRM实施款的20%，以及PDA实施款的30%。业务方案确认后，在商务进行开票确认时，对方项目经理，却坚持只能先开Sage X3+CRM实施款部分，PDA实施款部分还不行，理由是PDA的方案还没确认。可事先沟通过程中，特意说明了，开发部门的需求&方案，不作为业务方案确认内容，只是以共识确认稿的形式，作为项目过程文档。最后也因此，导致PDA实施款部分开票时间延后一周。

项目心得：
原因分析：
沟通还欠充分

在重要的事情上，特别是涉及双方利益冲突(像付款节点这类，一方付钱，一方收钱；一方希望赶紧落实，另一方要慎重对待)的事情上，相关人员的想法一定要沟通清楚，这次事情的处理上，也因为双方认知上的差异，导致了最后的开票确认延期。
分享的点：

1. 阶段是用来管理的，任务才是用来跟踪的
   项目阶段，是结合<实施方法论>的，是跟里程碑挂钩的，是可以用来考核的；工作任务，才是系统建设的每一块砖，才是用来执行的。所以一个项目的整体计划以及管理考核，必然是和阶段联系起来的，而真正的计划执行，必然是通过任务分配下去的(双周计划)。
   XXX的项目中，不论是需求调研，还是方案设计阶段，进入阶段后，会进行任务的拆解，且都有任务的执行情况及结果的跟踪。
   在任务的拆解过程中，个人觉得需要注意以下几点：
   ? 任务是可以分层级的，最后都会和我们的一级任务----阶段关联的，分层过程中，任务的拆解是相对充分的，也就是所有的子级任务完成，可以等同于父级任务完成的。
   ? 拆解出来的任务，是可以跟踪和关闭的(如果是会循环反复的工作，不应设为任务，如没有明确目标的现场支持工作。这类工作应该尽量减少)
   ? 定期会对主要的任务(通过双周计划邮件、周例会等方式)，特别是是甲方的任务，进行说明及跟踪
   ? 任务要有结果，要可控，是需要明确这些点的：责任人(最好是一个，多个则法不责众)、计划时间、任务要求、完成标准、确认人。
   ? 任务下达后，责任人必须是明确如何去做的(很多时候，任务没有及时完成，不是执行人不配合，而是不知道如何去做，特别是甲方的任务，必要的讨论和辅导，有明确的可
   操作方式输出后，再去跟踪)。
   ? 任务的确认，是非常重要的，ERP实施过程中，很多时候，做的人觉得“已完成”并不是真正的完成。
   ? 最后的任务分摊后，应该是全名参与的(很多时候，甲方的关键用户，会觉得自己是项目的参与者，我们需要让他们有足够的任务，才能让他们觉得他们是建设者)，让他们有负责的任务，才会让他们觉得自己在项目中有更多的责任，而不仅仅只是配合。
   例：XXX业务方案确认阶段，在这个阶段中，拆解了：业务方案编辑(乙方)、业务方案初次解读(乙方解读、甲方参与)、超级用户方案理解&反馈(甲方)、业务方案调整&二次解读(乙方、甲方参与)、业务方案部门内宣贯(乙方、甲方支持)、超级用户确认(乙方)、部门负责人确认(乙方) 等任务，并在周计划中说明，接下去，主要任务是哪些。

项目解读：

1. 项目每个阶段都是以一个或一个以上工作成果的完成为标志。一个项目阶段的结束通常以对关键工作成果和项目实施情况的回顾为标志，从而决定该项目是否进入下一阶段，并尽可能以较小代价查明和纠正错误。本案例中“方案确认“是一个里程碑阶段，它是否结束或者说能否进入下一阶段，是以关键工作成果《业务方案》的签字确认为标志，
   大家的分歧点在于《业务方案》的内容范围，事先也沟通过，也许是口头方式，如果对这个标志性关键文案的沟通结果能以书面沟通（需要经过文字整理，和其他沟通方式相比，产生理解偏差的可能性会更少）的方式确认，可能会减少这种理解误差。
2. 项目任务的分解
   工作分解结构(简称WBS)跟因数分解是一个原理，可以参考这个路径“项目—阶段—任务—(子任务)—工作单元(活动) “。工作分解结构以可交付成果为导向。
   “方案确认“这个阶段在做任务分解时
   • 如果一级任务下还有具体的工作和日常活动，则需要增加”方案范围确认“一个环节。
   • 如果一级任务颗粒度很精细，则可以考虑直接增加“方案范围确认”这一任务

1项目任务分解
另外任务的分解要遵循如下原则：分层分级、责任到人、可操作、有时间范围（2周原则，便于控制和检查）、团队协作（甲乙双方都是参与者，也是关键事件的决策者）

项目管理之项目沟通和任务分解

标签：纠正   功能需求   决定   分解   需求   负责人   理解   相关   crm   

原文地址：https://blog.51cto.com/14647823/2492237