在上一篇《项目管理的十大领域和五大过程》中，对项目管理的整体做了一个介绍，本篇继续。对五大过程的启动和规划做进一步分解。
启动过程组：好的开始是成功的一半
在《项目管理知识体系指南》书中，启动过程组的目的是：协调相关方期望与项目目的，告知相关方项目范围和目标，并商讨他们对项目及相关阶段的参与将如何有助实现其期望。
启动过程组只有两个分支，其一是「制定项目章程」，其二是「识别相关方」。
「制定项目章程」环节没什么多说的，主要是确立项目的正式地位，并展示组织对项目的承诺。
「识别相关方」对应到具体的项目中，更多针对的是「干系人分析」。在不同的项目中，干系人的核心诉求和期望不同，如何让不同的干系人更好地参与到项目中，是对项目经理初始的考验。
可以说，项目管理就是以客户/市场的需求为中心，使用适当的方法，不断解决干系人之间存在的各种分歧，从而实现项目的目标。项目经理，需要持续频繁地投入到干系人管理中，以推动干系人的满意度，直至项目取得成功。
曾经看到过一句话很好地概括了这个过程：项目管理就是去西天取经，途中会遇到各种想吃唐僧肉的人，于是干系人都成了你的资源，随时随地都能用，比如孙悟空一会儿请观音菩萨，一会上天请太上老君，总会有一款神仙，可以制服想吃唐僧肉的妖怪。干系人分析就是要对这些神仙好好管理，每个神仙有什么核心诉求，要非常清楚，管理好预期。
网上有很多干系人分类的方法，比如：四象限法，将干系人从利益到影响分为四个象限，然后再分类对待；还有一种DISC性格模型法，根据干系人不同的性格特点，采取不同的沟通方式。
结合我自己的项目经验来说，我习惯采用的方法来自之前分析产品的一套方法，可以简称为「上下左右」。“上下”是指上下游，在产品分析中“左右”是指不同的竞品，在项目管理中“左右”对应不同的职能。
在拿到一个项目后，我会先分析下项目从哪里来（上），到哪里去（下），以及在这个过程中，关键角色都是谁，他们的核心诉求和期望分别是什么。比如一个硬件或软件开发项目，其上游主要有发起人，在《项目管理知识体系指南》中称之为 Sponsor（项目资助人），项目发起人定义组织对项目的需求。而下游则是项目完成后交付给谁，比如有客户、公司的技术或维护人员等。
“左右”对应不同的职能，一个项目大多数是跨团队合作。项目的执行靠项目组成员，但在矩阵式的架构中，项目组的一些人来自不同的职能组，职能经理是资源池的所有者，职能经理手下的人可能会参与很多个项目，这就需要我们提前和他们沟通好。我的上一个项目就是没有协调好测试组长，导致产品测试的周期延后了一周。
规划过程组：凡事预则立不预则废
规划过程组包括明确项目全部范围、定义和优化目标，并为实现目标制定行动方案的一组过程。本过程组的主要作用是，确定成功完成项目或阶段的行动方案。
规划过程组涉及项目管理的十大领域，可以说贯穿始终。
但实际上和产品规划一样，在项目管理的起始阶段，要给出准确的时间点是非常困难的。在我这么多年的项目实践中，印象中很少有能如期完成的项目（一些小的项目除外）。特别是硬件开发项目，更是因为项目链条上的各种意外，比如：客户需求理解不到位导致的返工、人员能力、质量达不到要求、风险评估缺失、采购物料不及时、管理失误等，基本上都是延期完成，最长的有延期一年多才完成的。
很显然，产品开发过程中的项目管理并非易事，所以才更显得项目管理的重要性。而在规划过程中，需要项目经理从全局的视角出发，去推进项目整体目标的落地，优化各个角色的协同过程。
在计划的过程中，以下几个环节比较关键。
1、WBS 工作分解要具体
在项目计划阶段，项目经理一般使用Project或等价工具对项目进行分解。
创建 WBS 的过程，就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。在我的项目开发过程中，这一部分做得并不是很好，大部分时候就是定出大的节点，比如：什么时候完成设计定型、什么时候完成小批量试流、什么时候生产定型。
但WBS工作分解真正的意义在于将手头上的事情真正拆解开，明确到底分成多少块工作内容，涉及哪些角色和环节的工作项，一般建议要将工作项拆解到 3-5 个工作日以内，每项任务都对应到个人。
这个要求对项目经理的考验很大，拿我自己来说，基本上没有这么详细地拆解过。在这个过程中，一是比较考验项目经理的专业技能，二是组织沟通能力。
很多时候，项目经理并非什么都懂，我一般采取的做法是让工程师自己将工作拆解并给出时间。但这种方式最大的一个问题是：有的工程师很乐观，而另外一部分工程师则比较悲观，所以让他们预估出的时间一般偏差都比较大。这样做还有一个比较大的问题就是：这样细化或倒推出来的时间，可能和项目要求的目标时间偏差较大。
2、要有关键路径
解决上面问题的一个方法，可能是识别依赖并画出关键路径。这需要项目经理从目标的角度对资源进行统筹思考。
举一个例子，公司要求在8月底完成一款产品的研发上市，围绕这个目标，项目经理在制定计划的过程中一定要识别出关键路径，也就是项目计划中耗时最长的那条路径。比如：可能是某一个技术攻关，或者某一个核心器件的采购，关键路径的工期决定了整个项目的工期。
明确了关键路径后，就需要识别关键路径上的风险，并将其作为最高优先级应对。如果是技术攻关，那就需要组织足够的人力以及可行的多套方案；如果是核心器件采购，那就需要协调采购和不同供应商，提前准备好对应物料。
此外，在项目分解过程中，有一些依赖，就是某项工作完成后才能进行下一项工作，如果前面的工期延后了，可能会导致牵一发而动全身，所以在此阶段，项目经理对项目涉及到的其他合作环节，还需要进行全面地规划和安排，为各个阶段设定合理的里程碑节点。
3、明确的完成指标
一个项目从开始到结束，会经历需求、立项、开发、测试、正式发布，如果是硬件，还会有小批量试流、生产定型等环节。在计划的每一个节点，都应该有明确的完成指标。比如需求经过了评审并一致通过，每一个功能项都经过了讨论并达成一致，设计评审指标及确认，测试后能正常发布的标准和要求等。
项目管理过程中，最担心的事情是前期为了赶进度，忽略或者省略了关键环节，结果到产品快成型时才提出一大堆问题。无论是软件还是硬件，再经过一轮回滚，项目延期基本上是注定的事。
4、渐进明细
在《项目管理知识体系指南》书中，作者提到： 随着收集和掌握更多的项目信息或特性，项目很可能需要进一步规划。项目生命周期中发生的重大变更，可能引发重新开展一个或多个规划过程，甚至一个或全部两个启动过程。这种对项目管理计划的持续精细化叫作“渐进明细”，表明项目规划和文件编制是迭代或持续开展的活动。
在整个项目周期中，变更随时会可能会出现，正如前面所说：项目计划很难给出明确的时间节点。即使是大的里程碑节点，可能也会经常发生变化。所以计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整。
我的项目经历中，这一点也做得不是很好。不好的地方在于项目调整后，没有将信息完全同步到团队和关联人。其实有变化是很正常的，但每一次的调整，一定要让项目中的每个人都知道有了调整以及调整的依据，接下来的计划等，信息同步很重要。
以上就是我对项目管理五大过程组的启动和规划的一些认识和体会。
联系客服
