如何操盘好一个项目？——结合PMP给你讲一讲十大管理

武林 2024-08-19 11:10:10

如果你之前从没有操盘过项目，也没有系统性学习过项目管理方面的知识，那项目管理起来可能就是一头包，不知道项目中会存在哪些问题，也不知道问题原因出在哪里，更不知道如何去快速有效的解决问题。

思来想去，我觉得还是PMP项目管理体系的内容大家有必要做个了解，脑子里面有了这方面的知识体系，做起项目来就会有谱很多。

PMP这套项目管理体系已经出到了第六版，跟新华字典差不多超级厚的一本书，大家肯定没有那个闲情去抱着书啃。

因此，我就尽自己所能，把PMP中的知识内容给它掰碎了，揉开了，磨成粉，泡成汁，让大家喝下去，好消化吸收。

PMP项目管理这本书中的内容，概括起来就是一张图：十五至尊图。

上图中可以看到，5大过程组和10大知识领域包裹着49个项目过程，共同构成了项目管理中所涉及到的超级庞杂的知识体系。

项目管理还真TM复杂，你在做项目过程中出现各种问题，完全可以理解。老外研究了几十年总结出来的知识体系，咱们学来了别人的开发模式，并没有学习别人的管理知识！

接下来，我会结合自己的理解和过往做项目的经验，重点给大家讲下这10大知识领域。

教大家一个记住这10个知识领域的口诀：橙汁蒸饭，够香时，才疯吃。

橙汁：成本管理、质量管理
蒸饭：整合管理、范围管理
够香时：沟通管理、相关方管理、进度管理（时间管理）
才疯吃：采购管理、风险管理、资源管理

一、项目整合管理

1. 项目整合管理过程

一个项目的生命周期会划分为：启动、规划、执行、监控和收尾五个阶段，整合管理工作就是依托于项目的这五个生命周期进行。

启动：任命你来做项目经理，这个项目就是你负责了，接旨谢恩吧！
规划：项目你打算怎么干啊？得整个项目计划出来，搞个项目启动仪式啥的。
执行：搞定项目所需的资源，并且把项目过程中踩过的坑都一一记录下来。
监控：项目的时间、成本、质量都不能出问题，不管用什么办法，都得把风险控制住。
收尾：项目资料都给交给甲方，并把人家培训好、服务好。接着，奏乐、舞起来，庆功、团队解散。

2. 做好整合管理的几点经验

1）目标流程要明晰，交付验收排第一

项目立项之初，就得调研清楚客户的项目目标是什么，别项目做到一半，方向搞错了，那就亏大发了。

对于一个有明确合同约束的项目来说，最重要的目标就是如期、保质顺利交付。项目经理的核心职责，在心里默念：想尽办法“保交付、保验收、保回款”。

项目的流程事先一定得要和甲方讲清楚，特别是项目的需求变更和交付验收的流程，有言在先，就不怕后面扯皮翻脸。

2）管理计划一出手，启动会议必须走

管理计划就算你不写，心里也得有个谱。项目的背景、价值、目标是什么？团队的成员角色和分工是什么？项目的需求范围有哪些？项目的时间节点有哪些？项目的潜在风险有哪些？

能够写出来肯定是最好不过，拿着一张地图去寻宝，总比蒙着脑袋去探路要好。

在项目开始之前，启动会议必须得开一个。把项目的基本情况和团队成员大致讲一遍，保证团队中的所有人都知晓客户的要求和项目的目标、期限、交付质量等。目标一致，方向一致，才能心往一处想，劲往一处使。

3）庆功宴上看刘邦，英雄都是好儿郎

项目顺利交付后，就算不开庆功宴，也得整个总结大会。这个会上作为项目经理该说些什么呢？四个字：推功揽过。

看下刘邦在打败项羽后的庆功宴上说的话：“夫运筹策帷帐之中，决胜于千里之外，吾不如子房。镇国家，抚百姓，给馈饷，不绝粮道，吾不如萧何。连百万之军，战必胜，攻必取，吾不如韩信。”

翻译一下：出谋划策，张良NB！后勤保障，萧何NB！带兵打仗，韩信NB！

你看，刘邦一个小小的泗水亭亭长，为什么能操盘下“一统天下”的项目，不是他自己多有能耐，而是他善于把功劳分给大家。

二、项目范围管理

1. 项目范围管理过程

项目范围管理主要包括这么六个过程：规划范围管理、收集需求、定义范围、创建WBS、确认范围、控制范围。

规划范围管理：做后续的范围相关事项的一个标准依据（西方人的一套，干啥都得先有个标准）。
收集需求：和客户的关键干系人翻来覆去的沟通，把需求搞定清清楚楚。
定义范围：大致就是罗列功能清单、写需求说明书。
创建WBS：给项目做任务分解。
确认范围：找客户确定要做的需求点，是不是做成这样子就可以，别到时候耍赖皮。
控制范围：过程中客户有新需求，你得想办法控制住，避免需求泛滥，项目烂尾。

2. 做好范围管理的几点经验

1）项目每个干系人，各种需求要确认

项目干系人即和项目相关的人员，包括：客户（使用者、决策者）、承建方（总包方）、供应商、项目组成员、公司领导等。

对于客户提出的需求，不仅要和实际使用产品的人员做沟通确认，关键还得得到客户的上层领导最终确定。G端项目绝大部分的需求变更都是来自于领导，基层使用人员没有什么话语权。

当然，一个项目还需要考虑到公司领导的需求。比如，公司领导希望从项目中抽离出产品的通用功能模块，希望借此项目机会完成某项新技术的开发积累。

2）范围时间与成果，只有要求可不妥

G端客户对于项目的完成时间总是惊人的一致：越快越好；对于项目功能的开发需求：越多越好。

这个时候必须要拿出你作为项目经理的专业性，告知项目管理的工作流程，告知项目开发的成本核算，告知功能需求的潜在风险。

有些产品经理在和客户沟通的过程中，总是不好意思去开口这种可能会薄客户情面的话，总想着自己要不答应会不会显得不好讲话，给客户留下不好的印象。做习惯了好人，要做丑人确实有点难为人。

教你一个说服自己开口的理由：“反正以后你也不一定会和客户有交集，这都是公司要求这么说的，客户有意见也不会针对你。”

3）分完工作定做法，要谁负责谁计划

项目任务分解完成后，不是会上把任务布置下去了就完事。你想，后续任务完成的情况如何，过程中有什么问题，是否能得到自己想要的结果，这些事项你不掌控清楚，项目出问题背锅的一定是你。

所以，项目任务分解下去之后，就得要求项目成员明确任务所要达成的结果目标，给出完成任务的时间计划，敲定任务执行的工作方法。

最好的执行就是，在需求评审会上，敲定项目组成员的任务、目标、计划。会上没有提出来的，后续没有完成，你就可以名正言顺的拉出来批斗。

4）需求变更走流程，做与不做往上呈

“有变更，走流程”这是PMP培训老师常挂在嘴上说的最多的一句话，同时也说明在项目管理中最常见的问题就是：需求变更。

遇到客户提出的变更需求，反正你是只管记上一笔，做不做都不当场答应。统一回复客户：“需要上报领导定夺，做不做都会让销售给您说。”

需求变更按照PMP的理论需要通过项目管理办公室进行评估，我们可以简单点发邮件给项目相关方，把需求变更带来的影响、增加的成本、存在的风险、需要的资源等事项说清楚就可以，接下来大家邮件讨论，领导定夺后“奉命执行”。

三、项目进度管理

1. 项目进度管理过程

项目进度管理主要包括这么六个过程：规划进度管理、定义活动、排列活动顺序、估算活动持续时间、制定进度计划、控制进度。

规划进度管理：就是做其他进度事项的一个说明书，不做也罢。
定义活动：要完成这个项目有哪些具体的活动事项。
排列活动顺序：给项目活动排个优先级。
估算活动持续时间：算下每个活动需要花多少天。
制定进度计划：根据活动事项、时间、优先级做出一个进度计划表。
控制进度：控制好各项活动都在你的进度计划之内。

2. 做好进度管理的几点经验

1）制定项目进度表，甘特图表得用到

定义出项目要做的所有活动事项，估算下每个活动大概需要花费的时间，这样就得出了一个时间进度网络图。

需要合理预留出一些时间，包括一些极端情况及不可预见的因素。如：疫情原因导致的某项采购物品供货时间可能会加长；节假日前后团队成员可能会申请休假。

做项目进度计划表，用甘特图应该算是“国际惯例”了。甘特图的绘制工具有很多，陈龙之前有推荐过一个“亿图”还不错。

2）项目工期怎么出，关键路径算清楚

关键路径法，是时间管理中很实用的一种方法，简要说下其原理：为每个最小活动任务计算工期，定义出最早开始和结束日期，最晚开始和结束日期，按照活动的关系形成顺序的网络逻辑图，然后找到最长的路径，这个路径就是关键路径。

找到项目活动链条中用时最长的关键路径，也就找到了项目所需的工期。

比如：有一个功能需要开发，预估产品经理需要花2天时间，UI设计需要花1天，前端开发需要花3天，后端开发需要花5天，测试需要花2天。这个功能开发预计需要多少天？

答案是：10天。（前端和后端开发两者之间可以并行，但后端所需的时间更长，因此这个活动的关键路径可以简单计算成：产品经理时间+UI设计时间+后端开发时间+测试时间）

3）定期检查里程碑，成员问题需面对

项目管理中非常重要的就是合理设置阶段性的里程碑，根据里程碑来灵活控制项目的进度和节奏。

比如，计划项目在一个月后完成xxx功能模块的开发，如果在一个月之后发现这个里程碑没有达成，那么就得及时分析原因，调整后面的进度计划。要不去做阶段性的里程碑检查，等到项目最后阶段发现完成不了，那个时候就已经是“黄花菜都凉了”——晚了。

大部分情况下里程碑没有完成，都是人的问题。可以通过里程碑节点反向追溯到哪个环节出了问题，也就可以分析出该环节中的哪个人了问题。当项目成员中出现低绩效的情况，一定要及时沟通解决。这也就要求项目经理不仅要关注事，还得关注人。

四、项目成本管理

1. 项目成本管理过程

项目成本管理主要包括这么四个过程：规划成本管理、估算成本、制定预算、控制成本。

规划成本管理：给后续的成本结构、估算、预算之类的事项定一个标准，如：多少钱一人月。
成本估算：大致计算下项目成本。
成本预算：准确计算各项目活动的成本。
成本控制：尽量让项目成本不要超出预算。

2. 做好成本管理的几点经验

1）成本估算与预算，应急管理必须算

做项目成本的计算，最关键的一点就是如何算的合理。除了我们常见的人工成本、采购成本、商务成本之外，还有两个部分也需要纳入计算：应急储备和管理储备。

这两个PMP中的专有名词，我简单解释一下你就明白了。

应急储备：用来应对“已知”的风险可能带来的成本增加。比如：xxx地方有疫情，人员出差回来之后就需要隔离，这一隔离就会带来一些附加的成本。
管理储备：用来应对“未知”的风险可能带来的成本增加。就是项目过程中还有哪些风险你现在也不知道，识别分析不出来，那就拿出一部分预算来做储备。

2）控制成本的关键，直接成本中求变

成本的类型有很多种，包括：可变成本、固定成本、直接成本、间接成本、机会成本、沉没成本。你要是不考PMP，也不用知道这些都是啥概念。但直接成本这个你得知道，我们相对可以控制的成本就只有这个。

直接成本：直接可以归属于项目工作的成本，如：人员工资、差旅费、物料采购费、设备使用费等。

也就是说，如何控制住项目成本，能做好这么几点就可以当“大爷”了。

提升团队成员工作效率，用尽可能少的人做尽可能多的事，控制人力成本。
减少出差频次，降低不必要的商务费用，降低差旅成本。
设备能借用或租用就不要买，和采购厂家隔三差五要优惠，减少采购成本。

五、项目质量管理

1. 项目质量管理过程

项目质量管理主要包括这么三个过程：规划质量管理、管理质量、控制质量。

规划质量管理：和前面说的一样，给质量定标准。
管理质量：管理的是质量输出的结果。
控制质量：控制的是质量产生的过程。

（管理质量和控制质量，PMP考试中很多人容易混淆，必考题。）

2. 做好质量管理的几点经验

1）实施控制与检查，收集数据算偏差

任何决策都不能凭主观的概念和假设，必须以事实为依据，用数据来说话，建立在量化分析的基础上，这样既容易服众，也不容易做出错误的决定。

过程中就需要明确规定收集绩效数据的渠道、种类、时间和职责，确保数据信息的精准可靠，再用正确的方法进行统计分析，最后将结果传递给需要决策的人。

比如，对于研发人员工作进度的评估，完全可以通过考勤打卡记录来分析。如果哪个人要是和你说任务太重完不成，结果每天都是准点下班，这TN的不是老油条是啥？

2）变更需求要来袭，做好记录与分析

项目中需求变更是一定会发生的，提前有这个心理准备遇事就不会慌。

客户提出的变更需求，你可以做到如下几点：

了解需求变更的背景，是对已交付的功能不满提出新的需求，还是因为业务或政策调整带来的需求变更？
如果是前者，严格来讲不算是需求蔓延，可能是自己需求设计的不到位，对现有的功能进行优化调整就是。也可以通过培训指导用户正确使用，或者优化交互体验来提升用户对功能的接受度。
如果是后者，则需要从业务的流程做出调整，这种情况就属于需求变更了——“有变更，走流程”。
纯属于项目范围之外的新增需求，就可以和客户一起探讨是否有二期建设的可能性，做好新增需求的记录，发邮件告知销售，让销售抓紧时间找客户出业绩。

3）测试时间往高估，前紧后松少赶路

花在项目测试上的时间应该与项目规模和复杂程度相匹配。

大多数测试都是在项目开发完成之后才介入，因此，测试人员经常会陷入一种困境，如果开发人员落后于他们的项目进度，那么测试人员就需要加班来赶进度。谁叫他们是最后一个环节呢！

所以，一方面可以要求测试人员提前介入测试，完成一个模块就做一个部分的测试。另一方面，在项目进度计划设定的时候得前紧后松，前面把任务压的重一点，事情排的紧一点，后续就算有部分任务不能按时完成，那也会有时间进行调整。

尽可能要避免赶工，这种在短时间内逼着大家做出来的东西，大概率要出问题。并且，后续做问题修复的时间可能比正常完成这个项目的开发时间都要更长。

4）质量问题一出现，人人有责无幸免

项目启动会上就得说清楚，项目质量出现问题不仅仅是测试人员的职责，而是项目团队所有成员的责任，有难同当嘛，一个都别想跑。

团队的每个成员都以主人翁的心态去工作，都有出了问题也要挨板子的意识，一定程度上就可以避免前面的人挖坑，后面人往里跳的情况。

质量问题无小事，但凡出现质量问题就得借此加强内部的培训，让大家把不断提高工作质量变成一种自觉的行为。

六、项目资源管理

1. 项目资源管理过程

项目资源管理主要包括这么六个过程：规划资源管理、估算活动资源、获取资源、建设团队、管理团队、控制资源。

规划资源管理：规划下做这个项目需要什么资源、多少资源以及如何得到这些资源。
估算活动资源：盘算下做这个项目需要多少人，多少钱，多少东西。
获取资源：想办法搞定项目所需的人、财、物。
建设团队：把自己变成“气氛组”，搞好团队氛围，让大家开开心心的把活干了。
管理团队：解决项目过程中团队遇到的问题，不仅要让大家把活干了，还得干的漂亮。
控制资源：手头的资源得合理使用，别钱花了事没办成，“败家玩意”要不得。

2. 做好资源管理的几点经验

1）资源需求要汇总，评估分配看权重

一个项目确定立项，就需要大致评估下，在项目交付期限内，预计需要多少产品、UI、前端、后端、测试、运维等研发资源。如果公司内部资源不够，那就得考虑请外援或把部分功能分包出去，再或者直接采购第三方成熟的应用。

研发都是成组搭配：一个前端搭配一个后端进行任务开发。如果项目过程中，发现某个组经常加班，而其他研发组却抢点吃饭、准时下班、掐表打卡，那就得考虑下是不是研发资源分配的不合理。

资源分配遵从的原则也很简单：重要的功能，厉害点的负责；次要的功能，能力弱的上。发现项目组有闲得蛋疼的人员，赶紧考虑重新分配资源。

2）如果实在搞不定，发起爸爸使点劲

要是项目进行到一半，发现按照这个进度下去铁定得延期交付，这个时候不是立马找领导加人要资源。可以先从项目组的内部做工作，常见的就是三招：加班、串行改并行、重新分组。

加班：这招自然是不用说，是个人都会用。
串行改并行：这个啥意思呢？高中物理的电路图中有“串联”和“并联”两种连接方式，就是把一前一后改成并排行动。
重新分组：这个好理解，把能干一点能力强一点的分配到进度落后的组里去，定点“扶贫”。

要是上面三招用下来还是不行，有个“卡脖子”的问题，就是把“刀架脖子上”研发人员也搞不定。怎么办？不能干坐着等死，也不能把项目组成员逼死，只能找领导要资源去。当然事先你得是把能想到的办法，能用上的招式都用上了，领导最反感的就是遇到点问题就找过来，自己的脑子好像生锈了根本就不会开动。老板又不是请你来发现问题的，是需要你来解决问题的。

需要注意的是，公司有这么多领导，这个项目是哪个领导发起的，原则上资源申请就得要到他那里。

七、项目沟通管理

1. 项目沟通管理过程

项目沟通管理主要包括这么三个过程：规划沟通管理、管理沟通、监督沟通。

规划沟通管理：规划好信息要在内外部之间咋个传递，咋个流动，定个调子。
管理沟通：确保大家沟通没有障碍，说的人清楚自己在说什么，听的人可以听得懂他要表达什么。
监督沟通：监督大家有没有按照你规定的方式传递信息，别想私下绕过规定，最后扯皮。

2. 做好沟通管理的几点经验

1）信息流畅事轻松，推诿扯皮难调通

项目管理过程中绝大部分的问题都是沟通出了问题，这个“沟通”不单指“嘴对嘴”说话，而是包括会议、电话、微信、邮箱、文档等各种信息传递的方式。

每个人在过往的工作经验或生活经历中都有自己熟悉和习惯的沟通方式，比如，销售特别喜欢打电话而不愿意发信息；再比如，有些测试人员特别喜欢走到你面前来嘴对嘴说，才能把问题说出来而不是发个微信。

要解决大家沟通方式不一致的问题，你就得事先立好规矩。比如，能打电话说清楚的就不要面对面沟通，能发信息说清楚的就不要打电话，能截图说清楚的就不要发文字。还有，涉及到材料的传递必须要走邮件，不能发微信。涉及到事项安排的必须有文字，不能只是口头说……..这些就是“沟通的规矩”。

定好“规矩”，就是为了实现信息可以精准的传递，就算降低了一些效率，也好过后续出现问题相互推诿扯皮。

2）项目各种干系人，职权利益大小分

职能经理：主要包括研发部门、交付部门、销售部门等需要提供资源配合的部门，最好是可以做到“令其满意”，再不济不要得罪，要不后续项目要资源就难办了。
发起人（客户、公司领导）：需要做好“重点管理”，定时做项目进展的汇报，让他们清楚项目的情况，争取项目上最大的支持。
外部支持人员：一般就是供应商、生态伙伴之类的，不影响项目的情况下，不需要花什么时间精力在这些人上面。
项目组成员：要做到随时告知同步项目的信息，大家保持理解上的一致，才能齐心协力把项目做好。

八、项目风险管理

1. 项目风险管理过程

项目风险管理主要包括这么七个过程：规划风险管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对、监督风险。

规划风险管理：定义清楚啥是风险，怎么去搞定这个风险之类的内容。
识别风险：搞清楚项目风险是什么，别见到一个问题就说是风险，把大家给整怕了。
实施定性风险分析：风险太多了，顾不过来，得排个序，抓大放小。
实施定量风险分析：用老外发明的各种方法准确计算出来风险到底有多大。
规划风险应对：针对不同等级的风险得采取不同的方式，规避、减轻、转移还是接受。
实施风险应对：根据规划好的风险应对，照单执行就是了。
监督风险：一只眼睛盯紧已经找到的“老风险”，一只眼睛不断去搜寻发现“新风险”。

2. 做好风险管理的几点经验

1）重大事项关键点，评估问题与风险

项目的重大事项有哪些呢？主要包括：项目需求的确认，项目合同的确认，项目交付的确认。

为此，你就要评估分析，这几个关键点上可能会存在哪些问题与风险。只要这几个环节不出问题，项目也就会进展的超级顺利。

项目需求的确认：为了减少交付后返工的情况，面对强势的甲方我们通常会需要将设计稿和甲方确认后再投入开发，把风险前移稀释掉。
项目合同的确认：对于项目中付款方式，特别是质保金、违约金要多留心，尽量站在公司的角度去降低这块的费用。其次，就是项目功能清单，得附在合同最后，并且要甲方盖章确认。最后，项目交付周期一定的比估算的时间要长，万一项目不能按预估的时间交付，还有一个缓冲期，别遇到较真的客户，硬要逮着你不能按时交付的问题就麻烦了。
项目交付的确认：相关的交付验收材料给到客户，让客户能够签字盖章确认，就算完事了。最好是有一个验收确认单，目前公司财务有要求，没有这个单子销售也拿不到提成。

2）遇到问题别慌张，过往项目找药方

项目中最常遇到的问题就是：客户需求变更了，客户要求提前上线了，客户对接人换了。

项目做多了，心态也就平和了，遇到问题也不至于一惊一咋，要死要活找领导释压。

写《产品经理宝典》其实就是在总结做产品、做项目的工作经验，每做完一个项目，都应该总结出项目经验，沉淀到知识库，才能算是项目完全收尾。

当遇到项目问题的时候，就可以从过往的项目中找一找有没有别人的实践解决办法，这个世界上绝大部分问题都是相同的，历史总是在不断的重复，问题也是在不同人之间往返。

3）报告状况还不够，预测趋势看苗头

项目中很多时候出现问题，只是已经暴露出来的冰山一角，肯定还有很多问题隐藏在海平面以下的没有暴露出来。

所以，做问题汇报的时候，不仅要就已经发现的问题给出解决方案，还得就可能发现的问题提供预案，这才是一个NB的项目经理。

有人说，那我预判不到，发现不了潜在的问题，怎么办？也没有什么办法，就是经验不够，多做项目多练级，经验上去了自然就可以。如果大家喜欢打羽毛球的话，打多了，就很容易对来球的落点有个预判，并且可以就自己回球的落点也有个判断，这就是经验。

4）风险应对有成效，项目管理才可靠

PMP项目管理中，风险应对的方式主要包括这么几种：风险规避、风险减轻、风险转移、风险接受。

风险规避：知道这么干会有风险，那就尽量避开不那么干。比如，知道那里有疫情还派人去现场对接开发，这不就是往风险的枪口上撞了，要规避当然是不派人去现场，换成线上或改期。
风险减轻：降低风险的发生频率，减轻风险发生的后果。比如，这个功能比较复杂，采用的新技术不够成熟稳定，那么就得考虑通过延长测试时间或增加测试人员，来降低功能的bug率。或者部分使用新技术，核心还是采用老技术，减少对新技术不了解不熟悉带来的风险性。
风险转移：就是把可能存在风险的情况转移给第三方，让别人去承担。这个比较好理解，比如有些企业承接的一些项目，其实都是中标的国企分包出来的，国企这样做就是把项目风险转移到了承接具体开发项目的企业。
风险接受：不是说直接躺平，而是我们判断有些风险发生的概率比较小，产生的后果比较轻，那就不用去采取什么应对措施。比如，有个研发人员项目期间有事要请假一天，可能会带来项目延期一天的风险，但这个概率不大，后面让他加加班进度就可以补回来，这个风险就不需要去向上汇报增加资源或不批准请假了。

九、项目采购管理

1. 项目采购管理过程

项目采购管理主要包括这么几个过程：规划采购、实施采购、控制采购

规划采购：规划要买哪些东西，找谁买，怎么个买法。
实施采购：一手交钱，一手交货，中间来回拉扯讲讲价。
控制采购：是不是按照合同买的，有没有案按流程签收。

2. 做好采购管理的几点经验

1）采购过程要公平，亲疏无别说的清

大家一般不太涉及到和供应商之间打交道，但也有可能在设备选型，供应商选择上有一定的话语权，毕竟采购人员还是照着你提供的清单去询价、去执行采购而已。

这个过程中如果是自己认识的熟人或亲戚的货源，建议大家还是不要推荐，谁叫你不是老板，这么做出了问题还得你背锅。

比较有可能的一种情况是，供应商承诺你一些回扣，这很考验人性。也很好处理，不要为了一些蝇头小利断送了自己的大好前程，走错一步可能就回不了头了。

建议大家多去看看党十八大之后的一些反腐的宣传片，我就很喜欢看，大部分进去的贪官都会说的一句话就是“以前从来睡不到一个好觉，进去之后终于可以睡个安稳觉了。”良心上的折磨，最让人痛苦难过。

2）如果资源不太够，提前计划要采购

项目过程中不可避免会遇到需要增加资源的情况，特别是一些集成项目，可能需要增补一些零配件。这里要明确一下，这个事情就是项目经理的事情，不是销售的事情，也不是交付的事情，更不是采购的事情。

这种事项也好办，说明设备的用途，直接发起采购就好了。只是在时间点上要尽可能提前点。因为有可能，你采购回来的东西发现还是满足不了需求，得换购，这一来一回项目时间可能就耽误了。

注意，如果有采购增减项，必须得给客户做确认，要不后续项目验收得出问题。

十、项目相关方管理

1. 项目相关方管理过程

项目相关方管理主要包括这么四个过程：识别相关方、规划相关方参与、管理相关方、监督相关方。

识别相关方：搞清楚都有哪些人和这个项目有关系，挨着一点边的都算。
规划相关方参与：想办法让项目相关的人都积极参与进来，别到时候有事叫不动。
管理相关方：让支持你的人多多的，反对你的人少少的。
监督相关方：盯着大家是不是规规矩矩在做事，别背着你私下搞猫腻。

2. 做好相关方管理的几点经验

1）客户领导干系人，做好识别与确认

G端项目的干系人种类往往比较多，包括：客户内部的干系人、中标方、生态伙伴、供应商以及项目组成员和公司领导。

客户内部的干系人：可以根据组织架构、业务条线、职级岗位来识别和划分。
中标方：直接中标该项目的公司。
生态伙伴：我们公司产品的代理人，可能是中标方，也可能不是。
供应商：我们研发生产的产品，涉及到的软硬件供应商。通过第三方软件公司提供技术服务资源来保障我们的产品功能开发上线，这个软件公司也属于我们的供应商。
项目组成员：直接参与到这个项目中开发的产品经理、UI设计师、研发工程师、测试工程师、运维工程师、实施工程师、销售人员。
公司领导：涉及到销售、售前、产品、研发、交付、售后等部门的直接领导，如果项目较大，公司老板也得算上。
公司内部的人员都好确认，主要是甲方和第三方需要明确具体的项目对接人。

项目相关方的人员信息需要在《项目干系人》表格中进行记录，一方面便于自己管理好相关方人员的事项，另一方面也是项目材料归档保存的一种需要。

2）不同客户要分层，沟通事项得区分

对于客户部门的干系人，比较好做划分，一般就是三层：决策领导层、经办层、执行层。

决策领导层：往往是单位一把手（检察长）或分管副检察长，最终决定是否要为这个项目买单的人。他们关注的更多的是项目能否给他带来政绩，而不太关心产品具体的使用问题。因此，在做项目方案设计的时候，往往需要将大屏、各项数据统计结果的展示作为领导关注的模块做重点介绍。
经办层：一般都是某个业务部门或信息技术部门的处长/主任，他们负责和各厂家打交道，往往也可以左右一个项目的最终中标。他们关注的更多是项目是否能有利于他们的工作出成绩，有没有什么潜在风险。因此，他们最关心的还是产品的安全性和稳定性。
执行层：作为产品的实际使用人，大部分是基层科员。他们关注的是产品会不会增加工作量，会不会操作比较麻烦。因此，要主动服务好并且培训好他们，教会他们如何使用产品，如何反馈问题，并在后续的服务过程中配合他们做好产品的迭代升级。