PMBOK是官方出品的项目管理知识体系,核心内容概括为“十五矩阵”,即十大知识领域,五大过程组,覆盖了一个项目从策划到收尾的全过程,并告诉在每个过程中需要做哪些管理。当然实际执行过程中肯定会有所裁剪和“变通”,下面简单回顾自己的一个项目在推进过程中是如何与“PMBOK接轨”的。
- 项目启动(立项)
- 项目目标是和合作方开发一套实时仿真系统(类似于HiL设备),然后应用于客户的电控标定活动。
- 可行性分析主要是商业和技术方面,也都OK。
- 初步分析主要相关方状态,其中发起人是公司领导层,积极支持;终端用户是应用部门,持谨慎态度;客户期待较高(注意客户不等于用户)。
- 口头任命我为项目经理,筹备立项材料,参与商务合同校核。
- 立项申请通过批准后(正式任命项目经理),开始详细规划项目的内容。
- 项目规划
- 项目范围,一部分体现在合作方的合同里(主体开发部分),另一部分来自于和客户会议商定的信息。
- 项目需求,在实际开发中是整合合作方、用户、客户的信息输入,从模糊到清晰,从笼统到细节,逐步完善。
- 项目进度,依据合作方的建议、自身条件评估、客户期望期限确定节点,再细分成具体活动计划。
- 项目成本,由人力、外协、固定资产折损、差旅、管理成本汇总得到。
- 项目资源,人员方面,依据项目需求设计团队框架,根据职能拟定成员需求,对于意向人员先初定下来后面争取,其余的由职能部门推荐再确定;设备方面,缺少的部分提交采购申请,现有但使用上和其他项目可能有冲突的部分列出需求时间段。
- 项目风险,初步分析有技术风险、资源风险。
- 项目质量,由于是新研发项目,没有历史经验,除了合同上的要求,项目初期没有能力做具体的规划。
- 项目采购,根据开发需求资源缺少的部分,提交申请给采购部门,约定采购内容、时间要求、供方建议。
- 项目沟通,在启动会材料中提议,讨论通过后在会议纪要中确定。包括合作方沟通、内部团队沟通、向客户定期反馈。
- 以上一切规划均汇总成项目启动材料,于kick-off meeting向大家展示,讨论收集意见,形成会议纪要会后分发跟踪整改。实际先后开了两次启动会,一次是和合作方(主要相关方参加),一次是内部(所有相关方参加)。
- 启动会结束,项目正式按照进度计划开始执行。
- 项目执行
- 执行就是按照项目规划的做,分配任务给相关人员,提供好活动开展的条件,然后不断跟踪推进,组织关键节点评审,协调内外部冲突,是项目管理的最重要的部分。但通常也是问题爆发的集中点,常说的PM背锅填坑主要就在这个阶段,当然必须要及时实施风险应对,遇魔杀魔,遇佛杀佛。
- 开始的一段时间,进展比较顺,信心也足。资源保障充足,定期开会,合作方的报告写得也漂亮,邮件回复也及时,可能启动会开过不久,大家都还有新鲜感,时间长了逐步就开始爆坑了。
- 首先是人员问题,因为项目涉及部门较多,并且又是第一次开发,发起人为了加强大家的重视,安排了好几个大佬坐镇参与,常见弊端是大佬们没空顾着这个在他们看来不紧急的项目,而我这个新PM显然也不可能调动得了,好的结果就是大佬再让小弟干,当然这个直接向发起人反馈比较容易达成。不过由于人手实在紧张,小弟们也没法专注这个项目,导致的结果就是承担某职责的人员隔段时间就换一波。我的对策就是持续向发起人告警,陈述风险,强行定了个大佬来指导把关;其次就是自己顶上去,拉几个项目少的应届生培养(没办法的办法)。好在团队架构中的其他部分相对比较稳定,而且人员配合程度较好,整体进度不至于拖后太多。
- 然后是设备资源冲突,由于需要密集使用一段时间的公共资源(而且本项目还有个特点是该资源中途不能更换,即不能用其他的来代替,必须要始终用同一个,为了保证结果一致性),虽然项目启动时各方领导达成了一致意见,但是毕竟情况是不断变化的,当其他更高优先级的项目要用该资源,甚至是客户给出了强硬要求,还是不得不让。这直接的影响是延后了进度,还增加了技术风险。间接地导致了后面的返工,成本也增加了。对策也就是持续向上反馈,不停发声,陈述风险,和其他项目争夺资源。
- 接下来是合作方甩锅,前两个问题导致没能符合合作方之前提出的工作输入,进度也延后了,给合作方延迟交付以及交付质量与目标存在偏差提供了很好的理由。这个从客观上说对方有点理,但作为PM不能轻易服输啊,软硬兼施,让合作方给出具体偏差,调整计划继续,另一方面向重要相关方、向客户反馈,尽量统一预期。
- 以上风险应对的背后离不开大量的沟通管理,公司内部在部门内需要跟进进展、组织讨论,跨部门需要协调资源、解决问题,对管理层需要主动汇报项目状态;与合作方需要定期对接子任务进度和技术状态,确认问题探讨难点,并验收交付物;对客户需要组织沟通会、展示会,反馈项目阶段性成果。过程中经历大量的写邮件、写会议纪要、写周报月报、上会汇报、一对一/一对多/多对多交流,体会到书面和口头的沟通同样重要。还有一点,由于合作方来自法国,需要用英文,还要考虑时差,增加了沟通的复杂性。但老外有个特点就是能细则细,会上尽量把问题讨论透,会后写的邮件和书面材料也都清晰完整,并且他们应该能够很好利用历史邮件和笔记搜索,以至于在后面的讨论中能很快拿出一两年前的细节过程,这些都挺值得学习。所以我在自己做笔记的同时也基于Confluence建立了项目的“经验登记册”,供项目成员自行去添加和查阅。
- 资源管理方面,资源的获取上面已经说了,对于资源使用,设备主要是确认配置参数、定期检查测量一致性、最大化提升使用效率。对于团队人员,由于地域和时间的差异,绝大部分情况只能远程沟通,属于半虚拟团队,因此在项目沟通邮件、会议纪要的编写上要求自己不厌其烦,尽量把信息传递清楚,并注重大家的反馈情况(恰好自己也有点强迫症)。当然也有几次,大家是聚到一起现场开会的(包括合作方),这时候就抓住大家互信互通的机会,连续几天把会议都安排满,全天吃喝都在一起,这样互相之间再也不只是一个影音的印象了,对项目推进很有意义。整个团队根据所处地域不同大体分成4部分,3个来自公司不同部门,1个来自合作方,每部分都有个负责人,我这边也就直管我所在的一个部分,也跟其他部分负责人包括成员紧密沟通,紧急起来自己要把几个部分的事情串起来推进,回邮件到一两点也是有的,尤其是配合合作方的调试,(为了弥补时差)不得不连续一段时间带着小伙伴加班整(估计国内很多PM遇到过,其实没管理好不值得宣扬)。最后再说下团队的震荡期,不同于刚开始出于礼貌的和气,工作一段时间后,部分人磨合得不好的问题也开始出现了,甚至年轻人说话比较直,气氛一度很尴尬,这种情况下常用的冲突管理办法(“合作/解决问题”>“缓和/包容”>“强迫/命令”,其他两个一般慎用):私下向多方了解原委,基本都是源于误解,然后在正式会议上对双方做出积极评价,暗示合作重要性并后面注意引导,如果实在是合不来则考虑调整任务分配。当然也有互相不信任/不认可的情况存在,这时候从分析原理出发,把问题摊开谈,明确支持合理的一方,纠正另一方,给出实施决策。
- 执行采购,这方面没有特别的,因为项目中需求的工具设备也比较小众,可选品牌都不到3家,所以没有需要招标写RFQ之类的,仅给采购部门提交申请,他们自行选择合适的代理商采购,PM能做的也就是跟踪采购进度,将采购成本添加到实际成本中,并验收采购到的物品。相对麻烦的是都是进口件,清关需要帮忙提供一些信息。
- 相关方管理,随着项目推进,依据“权力-利益”方格及参与度逐步识别出的几类相关方有:权力高强利益相关(高层发起人,领导型/支持型;需要出资源的部门领导,抵制型;客户,中立型),权力高弱利益相关(非直接相关部门的领导,中立型/抵制型),权力低强利益相关(合作方、需要具体干活的项目成员,支持型),权力低弱利益相关(采购、财务等非技术部门同事,中立型)。对此的管理措施有:注重积累项目数据、信息持续给予相关方正向反馈,增加他们对项目的信心(发起人,客户,其他高层);强调项目长远收益,提前通过demo展示项目可能带来的效益,积极引导非支持型相关方了解,让他们知道出力是有好处的(出资源部门、非相关部门领导);对投入实践的相关方给与适当激励,描绘远景,让他们保持兴趣和动力(项目成员);对有合同约束的强调惩罚条款的法律效力,促使尽量保证零滞后高质量的交付(合作方);对关系不大的相关方提供必要的信息,保证他们能够支撑项目工作开展(财务、采购部门同事)。
- 执行就是按照项目规划的做,分配任务给相关人员,提供好活动开展的条件,然后不断跟踪推进,组织关键节点评审,协调内外部冲突,是项目管理的最重要的部分。但通常也是问题爆发的集中点,常说的PM背锅填坑主要就在这个阶段,当然必须要及时实施风险应对,遇魔杀魔,遇佛杀佛。
- 项目监控
- 按PMBOK项目全程都需要监控,实际项目操作上启动会开得比较早,所以项目启动和规划这两个过程组也较短就结束了,导致监控过程对应的活动大多发生在执行过程阶段,并且大多也和执行合并了。
- 规划阶段制定的计划比较粗,执行过程中也会发现和实际存在冲突的情况,变更在所难免。变更类型无非是常见的几种:范围、进度、成本。就是因为这个项目开发的产品比较新且小众,范围变更主要是来自于发起人以及……我,发起人见多识广,不时会有好的idea想实现,而我是考虑增加产品可用性及维护性,都是为了以后无论在开发效率还是推广效果上能够更有优势。用户和客户因为不太懂细节反而没有提太多变更,反正对标他们原有的工作环境和方式,不要有太多需要重新适应就好。进度前面也说了一部分原因,成本肯定也是跟着上去了(好在超了成本基准,但没有用完管理储备)。发生变更了就也是准备材料提交项目变更申请,上总经会由高层们(相当于变更控制委员会)决议后处理。有时几项会关联发生变更(比如范围影响进度再影响成本),则一起提交变更申请。
- 控制进度,直管团队这边的事情遇到紧急情况就直接开会处理,和其他3个团队除日常跟进外1周开一次例会,听取进展汇报,过任务项,调整任务安排赶工等等。
- 控制成本,工具采购费用无法控制,可控制的就是人工以及对设备资源占用产生的成本,这些和进度控制是一体的,综合考虑。
- 控制质量,调研用户使用习惯及接受度,在后期让部分用户提前体验;依据合同做内部预验收;对合作方交付的数据在本地再做运行核对,注意结果一致性;对出现的问题以及预估风险及时记录到Confluence上,分配责任人进行解决及问题状态维护。
- 项目收尾
- 根据合同和合作方一起验收产品开发完成后的技术指标,向客户展示结果,提交终验收申请。
- 客户完成验收后,跟进合同条款的履行情况(如付款)。
- 编制结项总结报告,提交项目监督委员会,审核通过后归档,项目结束。
- 整理Confluence上的问题和经验记录和过程产出,形成组织资产,如产品开发手册、专项开发工具、专利和软著等。
- 感谢团队付出并“解散团队”(还会有售后技术支持工作,因此并不是真正解散团队)
- 其他
- 对于PMBOK中另一个篇幅比较多的“ITTO”,即“输入-工具和技术-输出”,实际运用到的只有一小部分,比如头脑风暴、专家判断、标杆对照、访谈、质量成本、挣值分析、自制或外购分析、风险概率和影响评估、自下而上估算、知识管理、激励、谈判、培训、虚拟团队等。技术和方法不在于会的多,在于把好的学会,会的用好。
- 由于项目课题比较新颖且小众,市面上应用案例寥寥无几,所以在开发过程中不少相关方持观望甚至怀疑态度,为了改善项目环境,联合发起人组织了多次内部专题会议进行分享,根据产品不同阶段的成熟度情况,列出相关内容分享,邀请大部分相关方参加,使他们全方位认识我们开发过程和产品效果,提高兴趣和信心,给项目获得进一步支持确实起到一定作用。
- 过程中也跟进销售部门挖掘外部潜在客户,比如邀请对方来开发现场参观体验,参加外部论坛进行宣讲等。
- 交付完第一套产品后,客户又订了第二套,由于前面积累的经验,在后续开发上进度明显加快,问题也大幅降低,同时也培养了团队能力(包括候选PM,即我的接班人)。而给公司自用产品开发的项目也完成立项准备阶段,等待启动。
- 当然由于第一次管理项目,不足和遗憾也很多,比如个人业务经验不够,几个影响质量的关键因素没有及时把控好;前期对风险敏感度较低;表达不够精要简练;团队管理技能还需要打磨;对外部市场交流和交付经验也偏少,需要锻炼产品思维。
*感受总结就是:迭代成长。