项目管理实践-技法：提升绩效与改进过程

第1章 决战项目，举起制胜武器

应对环境变化环境

• 主要有3种方法

1. 学习：培训是学习别人经验教训的捷径，培训也越来越受到重视，越来越多的企业大学就是一个明证
2. 创新：学习总是跟在人后面，总是在追随（我称其为“尾随”）。哪怕跟得再近，也无法领先。创新才是实现领先的应对策略
3. 整合：掌握最先进技术的最简单方法，就是将掌握这种技术的人或团队“挖”过来。这就是整合，整合是应对环境变化的第三种方法

非重复性工作决定组织的发展

• 实现组织战略和目标的手段主要依靠两类工作，一类是持续的、重复的工作（运营），另一类是独特的、临时的工作（项目、项目集、项目组合，本书直接简称为项目类工作，其实这三者既有区别又有联系）

非重复性工作是获取高额利润的重要途径

• 正视以前成功的经验和失败的教训，必须避免犯别人曾经的错，避免重蹈覆辙，还必须做好那些非重复性的工作，必须去适应每一个客户的需求，必须将自己变成一个知识型企业，更要快速转变

图1-3　微笑曲线

• 微笑曲线有两个要点

1. 找出附加价值在哪里
2. 关于竞争的形态。

微笑曲线中间是加工制造；左边是研发（Research&Development，R&D），属于全球性的竞争；右边是服务，主要是本土化的竞争 当前，制造产生的利润低，全球制造也已供过于求，但是研发与服务的附加价值高，因此产业未来应朝微笑曲线的两端发展，也就是在左边加强研发创造智慧财产的能力，在右边加强客户导向的服务与营销

项目是某种意义上的非重复性工作

• 项目在本质上是独特的（与此前的任何工作相比）、临时的非重复性工作；要求使用有限的资源、在有限的时间内为特定的干系人完成特定目标而开展工作
• 独特性，使项目管理的应用范围得以广泛扩展

图1-7　项目与运营对企业成长的作用

项目是业绩的来源

• 项目不仅是企业的成长动力，更是每个人特别是管理人员业绩的主要来源

项目是有效整合内外部资源的平台

• 项目管理在运作方式和思维模式上最大限度地利用了内外资源，从根本上改善了管理人员的工作流程，节省了时间，提高了效率

认清项目管理的真正价值

21世纪的社会，一切都是项目，一切也必须将成为项目

IBM、微软、惠普和宝洁等全球化运作的公司，不仅将能够项目化的工作尽量项目化，而且要求公司新入职的大学毕业生一律学习项目管理

项目管理的价值在于沿着正确方向获取正确结果

要取得成功，首先要选择正确的方向，然后再使用正确的方法。选择正确的方向属于战略管理，使用正确的方法属于项目管理；换言之，战略管理在前，项目管理在后

项目管理是组织战略落地的手段

1. 项目管理是一种整合性最强的管理方法
2. 项目管理作为纵向管理过程教我们在可控的风险范围内如何把一件事情从头到尾办得既有效率又有章法

书

1. 比尔·盖茨著作《未来时速：数字神经系统与商务新思维》

第2章 生命周期模型是实施项目的工具

生命周期模型是组织项目的工具

图2-1　项目生命周期中典型的成本和人力投入水平

• 通用的生命周期结构通常具有以下特征

1. 成本与人力投入在开始时较低，在工作执行期间达到最高，并在项目快要结束时迅速回落
2. 干系人的影响力、项目的风险与不确定性在项目开始时最大，并在项目的整个生命周期中随时间推移而递减
3. 在不显著影响成本的前提下，改变项目产品最终特性的能力在项目开始时最大，并随项目进展而减弱。图22表明，变更和纠正错误的代价在项目接近完成时通常会显著

图2-2　生命周期中随时间而变化的变量影响

图2-3　几种生命周期模型的比较

表2-1　几种生命周期模型的比较

知识工具化、工具可视化是核心竞争力

• 对企业项目管理的要求

1. 进入角色快
2. 发现问题快
3. 给出解决方案快
4. 交付项目成果快

• 组织应成立专门的项目管理办公室（ProjectManagementOffice，PMO），负责将项目经验知识化，将知识工具化，并予以培训和应用

第3章 项目是面向人的复杂过程

• 在多数情况下，需求并不来自技术部门，而是来自业务部门

识别并分析项目相关方

图3-1　项目的干系人

表3-1　企业的干系人

• 波特的五力模型（见图32）用于从行业竞争角度对企业的干系人进行分析，5种力量分别是潜在的行业新进入者的竞争力、替代产品的威胁、买主的还价能力、供应商的讨价能力、现有竞争者的竞争能力。五力模型用来确定某一行业的竞争程度，其理论假设是行业的获利能力不是由产品属性或产品的技术含量决定的，而是由行业的市场结构决定的

图3-2　波特的五力模型

关键是要获取干系人的期望与影响

• 项目经理的另一项职责就是平衡干系人的不同利益，并确保项目团队以专业和合作的方式与干系人打交道

很多项目干系人的问题本身并不是技术层面的，一定不要试图仅从技术层面讨论问题

• 项目经理是业务层面的管理者，项目是基于业务导向的

相关方分析实践

• 使用权力—利益方格进行干系人分析，编制干系人登记册并制定干系人管理策略，是项目经理必须掌握的基本技能

表3-2　一个干系人登记册实例

图3-3　某燃气工程干系人的权力—利益方格

项目干系人在干系人登记册与权力—利益方格中的地位可能比较敏感，不宜纳入公开的文件中。项目经理必须保持政治敏感性

• 在任何情况下，时刻保持对干系人地位和态度的关注，以避免意外地发现原有的图表已经出现变化

重要的项目相关方

表3-3　高层管理者的界面

大象是不会和老鼠沟通的

没有永远的立场，只有永远的利益。尝试去探讨“真实动机”，而不是表面的“立场”，而真实动机往往是和利益直接相关的 遇到问题时，自己尽力考虑周全，在处理工作之前，尽可能通过面对面的非正式沟通（如午餐、运动）方式了解自己的直属上级和副总经理对问题的意见

要取得项目成功，不仅需要胜任的项目经理去完成项目管理，更需要胜任的企业高管去对项目进行有效治理

项目相关方管理要有点策略

干系人管理策略用于在整个项目生命周期中提高干系人的支持、降低干系人的负面影响。项目经理需要评估对关键干系人参与项目的程度，对干系人分组并按组别制定管理措施

抓住相关方的要害

• 从相关方管理策略角度看，别人不帮你解决问题，那是因为你的问题与他无关，没有触及他的利益

警惕项目中的『小人物』

• 小人物有两个身份

1. 一个身份是小人，说明职位很低
2. 另一个身份是人物，说明具备了执行的权利。你如果不尊敬他们，不把他们当回事，真把他们当小人，他们就用小人的方式对你；如果你捧捧他们，把他们当人物，他们就会用人物的方式对你了

管理解读

1. 国人只能理，不能管
2. 理，就是看得起

第4章 明确的目标是项目成功的基础

定义明确的项目目标

图4-1　项目管理“如来十掌”

项目目标的挑战

• 作为项目经理，尤其是新技术行业的项目经理，都会遇到“客户逼”“上司压”“牛人顶”的局面
• 时刻铭记项目目标是项目管理很重要的一个思维，项目所有的活动都围绕这个展开，而且项目目标是以业务为导向而非以技术为导向的

1. 技术出身的项目经理会沉迷于技术细节
2. 脾气火爆的项目经理会因为很多不值当的事情大发脾气，把团队搞得乌烟瘴气
3. 小心眼、爱面子的团队成员会因为某个某种技术观点不同而怀恨在心，拉帮结派，不团结

第5章 需求，总有填不完的“坑”

与你的承诺有关的条件可能会被忘记，但你的承诺本身却不会被忘记

需求管理常见问题

表5-1　实施项目需求管理的困难

需求理解不一致

图5-1　秋千的诞生

期望与需求

福特汽车公司创始人亨利·福特说：在汽车时代早期询问客户有何需求，很多人会回答说“要一匹跑得更快的马

• 由于用户基于他们的阅历与认知，他们习惯给自己的需求套到现实可现实的方法或物质中，也就是在项目中人们总是用自己已经见过的东西描述外来还未见过的东西

图5-2　从用户期望到项目需求

谨防投射效应

• 投射效应是指以己度人，并强加于他人的一种认知障碍。投射效应是一种心理定式的表现，它以评价人自己的心理特征作为认知他人的准备，作为认知他人的标准
• 要做好项目，实施者必须有很好的业务建模能力，快速地给客户展示合理的软件Demo。多年的经验告诉我，对于软件项目，一定要给用户看到“样板房”——软件Demo，才算需求调研结束！

相关方期望与需求的挖掘实践

• 多次发现项目的失败是因为对需求的完整性或成熟性没有记录下来，也未在干系人之间达成一致

需求收集既是科学又是艺术

图5-3　理查德的软件开发

• 在定义项目的商业价值方面应善于使用商业专家，即便是纯技术项目，商业专家的介入常常也是很有价值的
• 技术人员在定义项目需求时常犯以下两种错误：“需求镀金”和“需求过滤”。“
• 需求调研不充分、用户需求描述不完整、不准确，轻则影响项目过程的顺利程度，重则影响应用系统的质量，甚至决定项目的成败

表5-2　需求收集的不同方法

• 怕得罪人或从众的心理，很多人会人云亦云，揣测别人的心理和顺从别人的想法，模糊自己的责任，亦步亦趋，使其做法往往与真实想法相违背，有效地落实责任也就无从谈起

建立需求与措施多维矩阵

• 质量功能展开（QualityFunctionDevelopment，QFD）是将人们的期望转化为明确需求的有效工具

表5-4　工薪阶层购房者需求与开发商组合措施多维矩阵

切忌『鸵鸟心态』

• 不管他愿不愿意签字，你务必逼客户签字。记住：拿不到签字，下一阶段就不能开始
• 真正想要的并非他们的签字，而是逼他们认真考虑项目问题。很多时候你不逼，他们就不会深入考虑和审查项目需求；果真如此，倒霉的最终还是你

请注意一个原则：对事要硬、对人要软！

让客户参与到项目的各个阶段

• 逃避现实的“鸵鸟心态”，是一种不敢面对问题的懦弱行为。其结果只会使问题更趋复杂、更难处理。就像鸵鸟被逼得走投无路时，就把头钻进沙子里
• 多数人不想过早地和客户纠缠一些问题，只是因为怕麻烦
• 项目经理要让客户参与到项目的各个阶段中，需求分析、总体设计、详细设计、编码、测试，要让客户参与到项目的每个阶段，并随时让客户了解和提出自己的真实想法
• 特别是在需求分析和设计阶段，当整理完需求文档和设计文档时，一定要请客户一起参与评估，以避免需求理解不一致，需求范围不确定等问题

要让客户对需求进行确认。当多次与客户确认需求后，尽量让客户签字认可，如不能签字也尽量让客户方领导在正式场合当面确认

1. 可以有效地控制需求
2. 如客户真要加需求时，我们可以因需求变更而提出一定的经济补偿
3. 如果需求变更，项目经理可以凭借着签字在公司内部规避自己的责任
4. 有了客户确认的需求，项目组可以放心地去完成项目，以减少需求变更所带来的影响

• 对于公司和团队，我们要建立完整的服务机制并让用户看到。客户对公司和团队认可了，对后续服务有信心，客户就会允许把部分非核心工作放到将来处理。信任是种力量，让客户信任我们就要始终如一地做好服务

表5-5　×××医院信息管理系统项目需求跟踪矩阵

第6章 成败在项目启动已注定

• 项目可行性研究的重点在于风险评估。建议组织两个专家团队（或两个以上），在背靠背情况下分别研究。基于多个团队分析结果决策，得出的结果也就会相对科学

编制任务书重点在于各相关方达成共识

• 项目任务书作为项目的一个指导性文件，常发挥着类似章程的作用。任务书应该是一个简短文件（理想的是一页），简要说明项目要做什么、如何做和当项目结束时能给企业提供什么样的商业价值

警惕“先干起来”的诱惑，关键在于达成共识

• 项目启动阶段最重要的成果并不是项目任务书本身，而是在编写任务书的过程中所获得的洞察力和达成的共识
• 一旦任务书完成，就将被提交给管理层批准。批准过程不应形式化，绝不是草率的，而应该是一个缜密的决策过程

1. 高级管理层
2. 客户
3. 职能经理
4. 项目经理
5. 核心项目团队成员

• 项目任务书包含以下内容

1. 可测量的项目目标和相关的成功标准
2. 项目的总体要求
3. 概括性的项目描述
4. 项目的主要风险
5. 总体里程碑进度计划
6. 总体预算
7. 项目审批要求
8. 委派的项目经理及其职责和职权
9. 发起人或其他批准项目任务书的人员的姓名和职权

表6-1　财税库行横向联网系统研发项目的任务书

与客户工哪起人讨论项目约束

• 关键驱动因素过多，意味着没有人知道成功的条件是什么。关键驱动因素过多，意味着组织中没人愿意去判断孰轻孰重。应该让管理层决定项目的关键驱动因素，如果这不可行，那项目经理就做好项目痛苦的准备吧
• 在关键驱动因素确认这件事上，项目经理需要“强势”一些，用各种可能的办法“逼迫”客户/发起人把问题考虑清楚。只要你是为了把项目做好，一般情况下，他们是会理解的

名正言顺地启动项目

任何项目的开始阶段都为项目结果埋下了伏笔，名正言顺地正式启动项目极为关键，项目启动仪式（如启动会）要尽可能正式化，如果可能，更要大张旗鼓地进行，这大有裨益

• 启动阶段的一个重要作用是找到项目的节奏，让项目的干系人和项目团队成员感受到项目的脉搏

明规则

• 先说出对方实际中会遇到的情况，尤其是那些不愉快的情况，同时说出他们在这些不愉快的情况下可能要做出的心理反应，而改变对方的固有“程序”。当事情真实发生的时候，也就是固定的“程序”触发条件产生时，对方的固有“程序”便会失去原有效用。心理学中这叫“免疫效应
• 没有规则在前，后面全是坑，吃亏的是你自己！
• 在项目正式启动之前，将项目的干系人召集到一起举行一次启动会议是十分必要的。笔者认为项目启动会应尽量开，如果可能，更要大张旗鼓地开，千万不要像鬼子进村——“悄悄地来、悄悄地走

表6-2　启动会议10个问题

表6-3　启动会议10个需要注意的细节

第7章 项目应该被计划管着

管理项目是个复杂的过程，计划充当着这个过程的地图。该地图必须足够详细以便决定下一步做什么，同时也必须足够简单以使人们不会迷失在细枝末节中

切实执行务实的计划是成功的基础

• 通过计划的制订与工作的分解会逐步暴露项目目标的可行性

阿蒙森团队的成功经验，最后可以总结成一句话：不管环境好坏，照计划实施 最重要的因素是探险的准备如何，你必须要预见可能出现的困难，遇到了该如何处理或者如何避免。然后，按照计划执行

计划，计划，再计划，这是项目管理的最佳实践！

• 做项目管理的专业人士一般都必须知道如何编制项目计划，并且很多人能熟练地使用MicrosoftOfficeProject工具，知道80小时法则、WBS和关键路径的概念
• 因为只要不要求立即完成，任何人都可以做任意多的工作，而不会关心做的工作有没有用，跟项目成果有没有关系

理解计划的价值，不做哥伦布派

• 最后期限往前提：把长期的项目划分多个里程碑，每个里程碑进行正式评审；把任务分解到每天，日事日清
• 痛苦曲线（见图74）和难度曲线（见图75）告诉我们：制订项目计划的确是痛苦且困难的（需要明确项目需求、进度、预算、质量、资源、风险等），但会减少你在项目后期的痛苦和困难

图7-4　项目生命周期中痛苦指数曲线

图7-5　项目生命周期中难度曲线

计划是花费最少影响最大的工作

• 变化并不可怕，重要的是让变更处于受控状态

项目管理本质就是管理变化，计划的第一规则就是“随时准备重新做计划

基于愿望的计划必将破产

领导不应该直接管人管事，而应该管计划；项目不应该被领导管着，而应该被计划管着；员工不应该按领导的指示做事，而应该按计划的安排做事

不能记录下来的诺言，等于什么也没说；签字就意味着牵制

有效计划建议

1. 应该对计划制订过程本身进行计划，否则，它会变成一个毫无章法的过程，使组织疲于应付
2. 计划执行者应该参与计划制订工作。这样可以提高执行者的主人翁意识，同时也往往起到团队建设的作用
3. 计划制订的第一规则是随时准备重新做计划

第9章 频繁变更是项目管理的严峻挑战

如果你允许项目范围发生变化，那么它变化的速度将超过你的想象

糟糕的范围控制是项目管理第一大失误

项目变更在所难免

图9-1　一个NB项目的上线过程

• 变化并不是造成项目痛苦的原因，造成痛苦的原因是你没有从根本上认识变化对于项目的意义，也就不能掌握应对变化的方法，这才是造成痛苦的原因

发生变更不是问题，问题是许多变更处于“非管理状态

• 明确的变更管理程序，其主要内容是识别并管理项目内外引起超出或缩小项目范围的所有因素。它包括3个主要过程

1. 对引起工作范围变更的因素进行识别
2. 确认确实需要发生变更，并施加影响以保证变更是有益的
3. 管理那些实际发生的变更

• 范围变更会影响整个项目计划编制阶段的各种文件，要对诸如WBS和项目进度等的文件重新评价、更新，考虑范围变更所带来的影响

项目生命周期中变更控制

• 在项目生命周期中变更处理的原则如下

1. 项目早期的变更：原则上倾向于接受（我称为“让怎么干就怎么干”），当然必须遵守变更控制程序
2. 项目中期：要通过分析变更的影响，原则上尽可能与干系人沟通取消变更（我称为“要变更先谈谈”）
3. 项目后期：变更代价太大，原则上尽可能不变更：遇到大的变更时可以考虑启动一个新的项目，遇到小的变更也要到售后服务时再做。当务之急，必须获得验收，收尾项目

站在实施方（乙方）的角度：项目过程就是“绑架客户上咱们贼船的过程”。当然，如果站在委托方（甲方）的角度：项目过程就是“逐步移交主动权的过程

图9-2　变更管理的“九阴真经

• 第一步，当客户提出变更时，首先要评估信息的准确性，确认项目变更事实。定义问题比解决问题难
• 第二步，提供变更申请的书面记录。原则上讲，谁提出变更就应由谁提供书面申请。不得不面对的一个现实是，在一个不成熟的商业环境中，我们的客户一般都位于相对强势的位置——不愿意甚至不提供书面申请！那么我们来写好了
• 第三步，分析变更对范围、进度、成本、质量等诸方面的影响。当项目资源（费用）不足时，消减范围而不是降低质量。请注意，对项目范围（需求）的不满是暂时的，糟糕质量的影响将是持久的
• 第四步，与相关干系人沟通变更影响，确认是否取消变更。“我本来就不想做，只是我不能说！
• 第五步，针对变更请求，提出相应解决方案。最佳的方式应该是给出变更的至少3种解决方案。你应该这样汇报：“最好，这样做（上策）；如果不行，就这样做（中策）；实在不行，还可以这样做（下策）
• 第六步，查阅变更控制系统中对审批权限的规定，选择合适的干系人对变更进行审批
• 第七步，召开CCB，批准或否决变更
• 第八步，根据对变更请求的审批状态，与项目的相关干系人进行沟通
• 第九步，执行变更、跟踪变更执行状态

表9-1　变更审批结果的沟通

• 在变更执行过程中，要注意将变更执行结果及时通告相关干系人，同时使用需求跟踪矩阵实时跟踪

对变更的管控是项目管理者水平的体现

• 变更不可避免，处理不当常会导致冲突

语言在出口之前你是它的主人，但是语言出口之后你就成了它的奴隶！

不管产品特性多么耀眼，过一段时间人们就会将其视为正常的功能。这就是人性！

• 在做项目的过程中，不要追求多，而要追求少而精，反正无论做多少需求，客户都总是觉得不够的

为了避免客户造成的范围蔓延，记住这一条原则是十分有用的：“决不让步，除非交换

“九阴真经”人为地增加了变更的摩擦系数，让变更变得困难，客观上降低了变更的频率

• 系统变量设计在技术实现上常表现为一个配置文件或者是数据库里的一个表格。在前端，用户可以通过界面自行修改；在后端，技术人员可以根据需要改变配置文件使系统在不修改代码的情况下适应客户需求变更

甲方清楚，只要对乙方施压，乙方就会妥协。客户喜欢需求变更是因为你喜欢接受客户的变更请求！ 关键是你要“较真第一次”。能否用一个正式的理由拒绝第一次对需求变更管控至关重要。需要说明的是，这个正式的理由必须是在项目开始前就制定好的规矩。一个临时搬出来规定往往会被视为一种强词夺理，极可能会激怒对方

利用框架效应

• 面临收益时人们会小心翼翼，选择风险规避；面临损失时人们甘愿冒风险，选择倾向风险偏好
• 框架效应（FramingEffects），通过不同的描述方式，改变人的心理参照点，从而会影响人的选择

为化解该角度导致的矛盾，项目管理者可以利用框架效应来重述这个问题：“如果不进行变更，我们可以在规定时间内得到一个稳定的可运转系统；如果进行变更，我们有很大的概率不能按时得到这个系统，而且质量也无法保证。不如让我们先把已经确定可以实现的功能实现了，之后再来尝试增加新的功能

第10章 走出项目进度管控的尴尬

找出项目进度的节奏感

定义项目活动的一些主要原则如下

1. 0.5％～2％原则。每项活动的时间长度应该近似在整个项目长度的0.5％～2％。如果一个项目的时长为1年，那么每个活动的时长最好为1天到1周
2. 80小时原则。与创建WBS时的80小时原则相同。每个活动的时长不宜超过80小时（如果工作安排为8小时/天，为2周），超过80小时的计划安排是不可控的
3. 250活动原则。如果活动数目太多（超过250个），那么应该将项目划分为几个子项目，并为每个子项目开发各自的进度计划
4. 关键活动原则。持续时间虽短，但在工作范围内的关键活动，也应包含在活动清单中。如一个3年期的项目中，一个时长为2天的关键设计检查活动是极其重要的，也应包含在活动清单中

定义项目活动和里程碑

• 任何进度计划的制订都要从为工作顺利完成而定义关键的里程碑。关键的里程碑可以定义为项目生命周期中的主要事件，可能也包括诸如项目原型制作、新阶段的开始、状态检查、测试或者初次装运等

图10-1　组织项目管理的成熟度水平

眼睛盯住细节的，是工程师；眼睛盯住结果的，是老板；眼睛盯住过程的，是项目经理

• 加快进度的常用方法是把正常情况下按顺序执行的活动或阶段改为并行，这就是并行工程，又被称为快速跟进
• 必须要对企业内部的决策机制、管理流程非常熟悉，对各种表面的、潜在的影响决策的因素了如指掌，否则你是很难获取项目成功的

搞好项目=搞好人脉+搞好关系+搞好工作；先搞人脉，再搞关系，最后才是搞工作

5分钟站立会议既可以推动项目进展、跟踪项目问题，也往往可以提升团队对项目的责任感，起到团队建设的作用

表10-7　一个行动跟踪计划的实例

• 分配活动责任时，切忌留下无人负责的“灰色区域

第12章 用过程确保质量

人们总是没有时间把事情做对，却总是有时间返工

QA与测试人员的关键区别在于：QA团队人员能够进行过程改进

• 一个合格的QA在项目中会扮演3种角色：警察、教师、医生。QA典型的职责包括过程指导、过程评审、产品审计、过程改进、过程度量

1. 作为警察的角色，QA以业务流程为依据，需要及时发现和报告项目中的问题
2. 作为教师的角色，QA辅助项目经理制订项目计划，包括根据质量体系中的标准过程裁剪以得到项目定义的过程
3. 作为医生的角色，QA可以承担收集、统计、分析度量数据的工作，对项目过程进行诊断，帮助分析原因，开处方

• 管理项目质量就如减肥，决心比技巧更重要
• 当某个数据点超出控制界限，或连续7个点落在均值上方或下方时，就认为过程已经失控
• 控制图最常用来追踪批量生产中的重复性活动，但也可用来监测成本与进度偏差、产量、范围、变更频率或其他管理工作成果，以便帮助确定项目管理过程是否受控

员工的绩效绝大部分是由系统决定的，只有极少部分由个人努力决定

第13章 让风险管理成为一种习惯

图13-1　项目过程充满风险

• 项目风险管理的失败很多时候来自于我们对风险的感知不足
• 不发生点“事儿”我们无法证明风险管理的价值，可是发生了点“事儿”就证明我们风险管理失败了！这是一个死循环
• 风险分解结构（Risk Breakdown Structure，RBS）有助于项目团队在识别风险的过程中发现有可能引起风险的多种原因。不同的RBS适用于不同类型的项目。需要根据项目的特点和以往项目的经验、教训对项目风险进行分类，并明确风险分类依据，以体现不同的风险来源

图13-3　风险分解结构（RBS）示例

• 项目风险识别方法

1. 文档审查
2. 专家判断
3. 德尔菲技术
4. 头脑风暴
5. 假设分析
6. 项目生命周期分析

管理绝不是高大上的工作；管理有时看起来很傻、很琐碎，但却是实在的！请记住：永远不要摆“花架子”！

第14章 提升价值的项目收尾

经验是最坏的老师。它经常先考试，然后再给出指导

做好项目收尾，不留后遗症

• 项目是临时性的，但项目成果却往往是长期的。项目收尾必须做好，不留后遗症，以免造成长期的不利影响
• 作为项目经理必须在开始新项目之前，请发起人和所有干系人验收项目、接收项目成果并确认本项目已经圆满完成
• 项目文件存档，这样可以为未来类似项目的定义和规划提供必要的信息
• 通过庆祝所取得的成就，认可并奖励团队成员做出的贡献，来加强成员间的关系
• 开展项目后评价，把良好做法标准化，并改进不足，为后续项目改进提升做积累

表14-1　项目收尾工作的维度

表14-2　项目终止任务清单

客户的不满意绝大部分跟遗漏实施操作要求有关联

• 准备一份包含所有最终文档的提纲，并将此提纲包括在每个团队成员的工作任务书里。然后，在项目过程中，当每一项关键任务完成时，项目经理都要求相应团队成员提供与任务相关的几句、几段或几页文档，然后将这些片段插入提纲内适当的位置。我把这种方法定义为“递增式文档

文档是体现项目经理价值的重要方式

作为项目经理，激励和感谢是加强其自身影响力的最好方法 尽可能当面表示感谢。对于远程团队成员，至少要亲自打个电话。要找出每个人的一个特别之处予以评论，使感谢更生动有力

• 作为项目经理，你还有一个任务：安排某种活动来庆祝项目结束。如果项目非常成功，并且你已获准举办聚会或带团队外出聚餐，那就应该按团队喜欢的方式去组织。如果你没有经费支持，至少要举行一个小型聚会，愉快地结束项目

项目收尾报告至少应该包含以下部分

1. 描述原项目（招标时）的基本方面，即范围、时间安排、成本和收入
2. 专门说明在范围变更、时间安排和成本等方面与原内容的偏差
3. 专门用于项目生命周期中客户关系发展分析
4. 总结风险管理，从而提供项目过程中发生的主要威胁和机会的列表，以及如何应对（积极或消极）的，应对的实际结果
5. 经验教训列表，包含做过的事情、基本原理、采取的预防措施和（或）纠正措施
6. 项目管理团队个别成员对项目提出的具体反馈信息

代后记 成为专家是我认真思考后的选择

职业发展上，我们有两条路：

1. 专家：成为专家的机会几乎是无限的
2. 领袖：意味着沿着领导的阶梯向上攀登，这非一般人可以达到的，我想我是没有这个机会更没有这个能力的

企业和社会也会越来越由专家驱动，就如今天的欧美

成为专家也得具备3个方面的条件

1. 系统做过，有所感悟
2. 系统学过，有所研究
3. 系统提高，有所总结

学，不一定得读万卷书，关键是精读几本好书；做，不一定要干多少年，关键是边做边思考，总结提炼