PMBOK项目管理实践

PMBOK是官方出品的项目管理知识体系，核心内容概括为“十五矩阵”，即十大知识领域，五大过程组，覆盖了一个项目从策划到收尾的全过程，并告诉在每个过程中需要做哪些管理。当然实际执行过程中肯定会有所裁剪和“变通”，下面简单回顾自己的一个项目在推进过程中是如何与“PMBOK接轨”的。

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

PMBOK项目管理实践相关推荐

PMBOK（项目管理实践指南）绝不是PMP考试的指定教材，看完你就知道
PMP认证考试不是考PMBOK指南吗? PMI关于PMP考试参考清单的介绍以上,PMBOK(项目管理实践指南)绝不是PMP考试的指定教材.PMI综合全世界管理者和从业者反馈,以满足当今行业.组织和 ...
PMBOK项目管理九大知识领域和五大流程 --美国IT项目管理硕士笔记(二)
PMBOK 项目管理九大知识领域和五大流程 PMI Project Management Institute.PMI 是世界上最大的非盈利机构,是项目管理领域的领导者.PMI制定项目管理行业标准,带 ...
荐书丨互联网项目管理实践精粹
点击上方"程序人生",选择"置顶公众号" 第一时间关注程序猿(媛)身边的故事从搜狐到新浪再到京东十余年实践经验总结而成的PMBOK 理念原则.思路方法.技术工 ...
项目管理实践之版本控制工具SVN在Windows平台下的平台搭建
通过<项目管理实践之版本控制工具SVN>我们知道,在windows平台下,如果直接使用Subversion,那么在Windows 系统上,要想让它随系统启动,就要封装SVN Server为 ...
软件项目管理实践经验谈
软件项目成功的要素--软件项目管理实践经验谈 2005.08.29 来自:<程序员> 王晓毅曾经有个笑话,说三个软件高级人材等待上帝安排工作,一个说自己擅长抽象思维,上帝说那就做系统 ...
ONES X 深圳农村商业银行 | 数字化项目管理实践
深圳农村商业银行成立于2005年12月,是继北京上海之后,我国第三家在副省级以上城市成立的地方性股份制农村商业银行.目前,深圳农商银行在深圳地区设立2家分行.27家一级支行,布局218家营业网点,网点 ...
华为敏捷项目管理实践分享
当前,企业面对的商业环境瞬息万变,移动.社交.物联网.云计算.大数据.AI等蓬勃发展.新技术突飞猛进的同时,新业务形态越来越复杂.需求变化越来越快.软件规模越来越大.交付周期越来越短.开发和维护成本越 ...
项目管理实践【五】自动编译和发布网站【Using Visual Studio with Source Control System to build and publish website autom
在上一篇教程项目管理实践[三]每日构建[Daily Build Using CruiseControl.NET and MSBuild] 中,我们讲解了如何使用CCNET+MSBuild来自动编译项目 ...
项目管理实践教程二、源代码控制
在上一篇文章项目管理实践教程一.工欲善其事,必先利其器发布后,根据大家的回复,我需要向大家说明几个问题: 1.为什么要用VisualSVN Server,而不用Subversion? 回答: 因为 ...

PMBOK项目管理实践

PMBOK项目管理实践相关推荐

最新文章

热门文章