读书笔记《极简项目管理》管理过程思维导图

思维导图大纲

读书笔记《极简项目管理》管理过程思维导图模板大纲

第二部分 | 极简项目管理过程

032 第2章　启动：师出有名，名正言顺

032 2.1　生命周期模型是项目管理的工具

033 2.1.1　项目生命周期的特征

【观点】

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

【案例】

如果把培养孩子当成一个生命周期来看

037 2.1.2　项目需要阶段化管控

【观点】

项目阶段化管理的好处：

项目在被分成多个阶段后，能更清楚地展现其规律性，人们也更容易把控项目的发展，提高项目成功的可能性。

通过划分阶段对工作按照时间进行分类，也更容易搞清楚每个时期的主要矛盾是什么。

可以减轻痛苦、降低不确定性，从而增强项目经理成功的信心

瀑布式&敏捷式项目管理的区别：

缺图

042 2.1.3　延伸：疯狂的项目之六拍、四没、三边、只谈

【观点】

六拍：拍脑袋、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿

四没：没问题、没关系、没办法、没资源

三边：边设计、边实施、边修改

只谈：项目初期只谈成本、项目中期只谈进度、项目后期只谈质量

045 2.2　定目标：项目始于业务终于业务

【金句】如果你不知道要去哪里，给你张地图也没有用

046 2.2.1　自我欣赏的是艺术，他人接受的才是商品

【案例】更好，和更快有什么区别

这三个工作到底需要多长时间才能完成呢？哪种组合方式更好呢？

048 2.2.2　定义明确的项目目标

SMART法则

050 2.2.3　跳一跳、够得着：基于愿望的目标必将破产

【观点】

基于愿望的目标必将破产，原因是：

目标建立在愿望大大超过能力的基础上，团队成员只能被迫接受。但是，他们不是发自内心地认可这个目标，于是在后续工作中他们不会努力去实现这个目标，而是用行动来证明你们定的目标是错的。

人们对项目团队的目标或交付能力失去信心，于是人们不再把精力投入项目实施中去，转而去设置下一轮的基于愿望的目标

不切实际的高目标，容易滋生消极的组织文化：

（1）“狼来了”和“掩耳盗铃”从此相伴相生。

（2）会干的往往搞不过会说的。

（3）自欺欺人的激励方法。

（4）奖励任劳任怨却惩罚灵活应变。

【点评与反思】这个观点感觉是有问题的

就以福特如果得到的两个目标（“培养出能够跑得更快的马” 和“造出汽车”），后者显然在现有认知下是够不着的，但是如果没有这个目标，就很难产生颠覆性的创新

理论基础就是行动学习的理论

053 2.2.4　能否相信客户的话

【方法】如何分辨客户需求

（1）你想要，拿钱来。客户的期望总是比能交付的要多。区分需要与想要的一个方法是：客户愿意付钱的是其真正需要的，否则就不是。

（2）多关注已知的真实行为。少关注客户说什么，多关注客户的行为。很多时候，客户对自己说的话既没有认真思考，更不用付出代价。

（3）时刻记住项目是一个业务过程。遇到问题以后不要仅仅解决问题的本身，还要去解决问题所在环境。

【案例】：

客户要买一个电钻，是因为他缺一个电钻吗？不是，是因为他想在家里的墙上打一个洞。那客户真的想要一个洞吗？不是，是因为他想在墙上钉一个钉子。那客户真的是想要在墙上钉一个钉子吗？不是，他只是想挂一幅画。而想要挂一幅画，客户只需要一个粘钩就可以了。

【观点】

切忌“鸵鸟心态”：答应与否都不能算错，但明知道客户有这种需要，却不加以明确，让这个问题“悬”着就是一个严重的问题

如确实有问题存在而且躲不掉，假如争吵不可避免，那么早吵也会比晚吵好。一方面，问题在早期解决成本会比较低，另一方面，尽早暴露问题，吵完了大家也就可以安心地做事了。

【观点】

目标和需求是需要确认的

真正想要的并非他们的签字，而是希望他们借此机会认真考虑项目问题

058 2.3　识鬼神：项目是面向人的复杂过程

058 2.3.1　关键是要管理与平衡相关方的期望和利益

【观点】

项目管理者的两个重要职责：管理人的期望；平衡人们的不同利益，并确保项目团队以专业和友好的态度与他们打交道。

061 2.3.2　用权力–利益方格分析和管理相关方

【方法】

编写相关方登记册的步骤如下（缺图）：

（1）收集相关人员的个人资料（姓名、从属单位和职务）。

（2）评估每个人对项目的期望和态度。

（3）确定每个人的权力和利益分值（在规定范围内的分值，如1~10分）。

（4）使用权力–利益方格（见图2-14）分析每个人的影响。

（5）基于每个人在权力–利益方格中的位置，制订管理策略。

062 2.4　组团队：干部是把事做成的关键

062 2.4.1　项目经理的压力是全方位的

【观点】

如果你喜欢一个人，就让他去当项目经理，因为这使他有机会驱动组织变革；如果你恨一个人，也让他去当项目经理，因为十有八九他会被失败的项目“毁”了

065 2.4.2　小心旁观者效应，做好三落实

【观点/方法】

为确保每个人都能承担起自己对组织的责任，必须做好三落实：

任务落实：每个任务都必须有明确的负责人

人员落实：任何一个人，不能让其只享有权利而不承担义务

组织落实：确保组织中的制度、流程、工具、技术协调一致，并有统一的激励措施

066 2.4.3　使用RAM明确每个人的责任

【方法/工具】

责任分配矩阵图（缺图） #方法

068 2.5　发章程：建立项目团队与组织的契约

068 2.5.1　项目章程是项目团队与组织的契约

069 2.5.2　编制项目任务书的重点在于达成共识

项目启动阶段最重要的成果并不是项目任务书本身，而是在编写项目任务书的过程中所获得的洞察力和达成的共识。 #观点

项目任务书的主要内容 #方法

（1）可测量的项目目标和相关的成功标准。

（2）项目的总体要求。

（3）概括性的项目描述。

（4）项目的主要风险。

（5）总体里程碑进度计划。

（6）总体预算。

（7）项目审批要求。

（8）委派的项目经理及其职责和职权。

（9）发起人或其他批准项目任务书的人员的姓名和职权。

074 2.6　开好头：名正言顺地启动项目

重要的节点必须要举行仪式，要引起领导和相关部门的重视，让项目团队更有凝聚力 #观点

074 2.6.1　项目不是在结束时失败，而是在开始时失败、

尽量营造项目的工作氛围，例如张贴项目总体进度图，制作项目的标志图，或者有意识地更换一下项目成员的工位，让他们坐得更近一些。 #方法

可以让每个人想一句话，表达一下自己要如何努力来保证整个团队的绩效。 #方法

当事情真实发生的时候，也就是固定的“程序”触发条件产生时，对方的固有“程序”便会失去原有效用。这在心理学中被称为“免疫效应”。（示范：你可以这样和你的家人沟通：“我知道你听了我的想法之后会感到生气，但是我真的很想要那部越野车！”）#观点

启动阶段必须明确的规则包括：#方法

（1）沟通方式、频率、内容及格式。（2）项目管理者的权力，即项目奖惩权力、人事调度权力和项目方案的决定权力等。（3）甲方责任、需求提供、调研配合和业务指导等。（4）变更处理的流程、文档、权力等。（5）团队合作模式、风格、出勤、考核标准、争议解决等。（6）项目开发方的各个部门的义务及责任。

以上信息不一定都以项目制度的形式公布出来，如果映射到制度上，应该包括 #方法：

（1）项目例会制度。（2）绩效考核制度。（3）汇报制度。（4）文档流程。（5）变更管理制度等。

078 2.6.2　表明正式开始的项目启动会

#观点省略了项目启动会的项目，其过程往往很混乱，很多人对项目的配合不够，协同性很差，项目目标也就无法按计划实现。

#观点如果可能，要大张旗鼓，千万不要像鬼子进村——“悄悄地来，悄悄地走”。

#方法为了完美地启动项目，建议用结构化方法实施项目启动会。

缺图：表2-5　启动会议10问；表2-6　启动会议10个需要注意的细节

082 第3章　规划：运筹帷幄，决胜千里

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

084 3.1.1　事前想清楚，事后不折腾

#案例两个前往南极探险的团队遭遇

阿蒙森团队率先到达南极点之后，又顺利地返回了原来的基地。而斯科特团队没有获得荣誉，更糟糕的是，他们返回的路上天气非常恶劣，不断地有人掉队，最后没有一个人生还。斯科特团队不但没有完成首先到达南极点的目标，而且全军覆没，这已经是生与死的区别了。

一个是有计划的（物资准备充足、风险预估等），另一个是随心所欲的

#观点布利斯定理：用较多的时间为一次工作做计划，做这项工作所用的总时间就会减少（不可能完全按照计划进行，但是计划会为你提供做事的优先顺序，这样会事半功倍）

085 3.1.2　魔鬼藏在细节中

#案例南极探险案例补充：阿蒙森团队对午餐的特别安排（省去了生火做饭的时间和能源浪费）

#观点管理项目是个复杂的过程，计划充当着这个过程的地图。该地图必须足够详细，使项目经理能据此决定下一步做什么，进而保证工作在规定时间、预算、范围内能保质保量地完成。

087 3.1.3　“如来十掌”为制订计划提供了抓手

#案例张斌带领团队为客户进行无线通信基站的建设，他们的项目需要于三天后在野外施工。天气预报显示，三天后暴风雨将至，而张斌的团队并没有防雨设备。现在该怎么办？

#方法通过“如来十掌”为制订计划提供了抓手

（1）“如来十掌”的第一个问题：做什么（范围、需求）

（2）“如来十掌”的第二个问题：什么时候做（时间、进度）

（3）“如来十掌”的第三个问题：花多大的代价做（成本、费用）。

（4）“如来十掌”的第四个问题：做到什么程度（质量）可以接受。

（5）“如来十掌”的第五个问题：需要什么资源（团队、采购或外包）。

090 3.2　拆任务：没有WBS就没有项目管理

091 3.2.1　隐性工作显性化，显性工作结构化，结构工作标准化

#观点 WBS及其词典是组织的重要无形资产。在同一企业中，尽管所有项目各不相同，但有许多项目在较高层次上是相似的。如果能够花费些精力去编制涵盖这些同类型项目的标准WBS，那么这样的WBS就成了企业的一种无形资产。

#方法 4种常见的WBS类型（没有最佳方法，合适的就是最好的。建议在项目启动时每种方法都要考虑一下，从中选择一个可以清晰定义项目工作的方法来分解项目。）

（1）按组成分解

（2）按功能用途分解

（3）按生命周期分解

（4）按地域/组织分解

#方法 WBS的展示方法

树形层次结构更适用于向高层管理者汇报工作或沟通

而表格形式更适合项目团队成员自己使用，因为可以在表格右侧增加更多细节备注，这有利于团队协作，但看起来更复杂。

098 3.2.2　心法：创建有价值的WBS

#方法如何创建WBS

拿到一个项目后，对于一个具体的目标可以从两个视角考量：“怎么完成”和“交付什么”

当选择了一个视角后，下一步又可以分别从这两个视角进一步分解，直到满足“易于管理”和“足够详细”两条标准为止（WBS的最底层组件一定是“交付什么”，即都是具体的交付成果。）

#方法如何判断WBS的好坏

（1）MECE法则：相互独立，完全穷尽

（2）信息透明原则：指可以估算工作包的工作量以及完成工作包所需的时间、成本和验收标准。

（3）80小时原则：单个工作包的完成时间不应超过80个小时

（4）独立责任原则：单个工作包只分配给一个单独的人

（5）滚动式规划原则：近细远粗，近多远少

（6）不同层次原则。不同可交付成果可以分解到不同的层次

（7）一个上级原则。每个下一级组件有且只有一个上级组件

#工具判断WBS好坏的检查表

缺图：判断WBS好坏的检查表

106 3.2.3　WBS是有效项目管理的基础

#观点 WBS被认为是现代项目管理的重要基石： WBS首先解决的就是项目中“做正确的事”的问题，只有明确了“做正确的事”，“正确地做事”才有基础

#方法看见即降服：看见即降伏的原理对项目管理极有价值，利用这个原理，通过可视化、透明化工具对项目过程进行管控。在项目过程中，让项目所有相关人员一起来创建WBS，并在WBS中使用不同色块标明每个工作包的状态，还可以把各项工作的责任人标明，同时给出各项工作包的时间计划。

#方法 WBS实现任务墙

缺图

#点评和思考团队内部的WBS配合表

109 3.3　排计划：绘制项目作战线路图

109 3.3.1　让进度估算走向科学

114 3.3.2　关键路径法：进度计划与网络技术

121 3.3.3　案例：路易十四的地牢

124 3.4　算投入：项目管理是一项平衡的艺术

125 3.4.1　核心在于花多少钱对应完成多少工作量

#观点将预算与实际完成工作量做比较，表明了项目的进度状况；将实际成本与实际完成工作量做比较，表明了项目的成本花费状况。将实际花费与预算比较，只能得出花钱速度的快慢，对项目并无实际价值。

#案例 T公司为某项目A制订了4个月的实施计划，第二个月月底的财务数据如表3-10所示。T公司财务部经理黄兴拿到该项目的数据，向公司总经理高静汇报：该项目运行得不错——费用节约了！

分析缺图图3-36　第一个月工作情况的三种可能情景

129 3.4.2　抓住项目预算的关键

131 3.5　估风险：不信邪就会中邪

132 3.5.1　优秀的管理者不是善于冒险，而是善于控制风险

#观点优秀的管理者不是善于冒险，而是善于控制风险

133 3.5.2　风险管理在国内的困境

#观点风险管理的悖论：如果风险管理很好，风险就不会发生，可是风险不发生怎么证明是因为风险管理得好呢？

135 3.5.3　分析风险的概率和影响

#方法做好对已知风险的管理，在识别后，我们需要以下数据进行风险分析。

（1）风险事件发生的概率。（2）风险真的发生后，可能产生的后果的范围与影响。（3）每个结果的可能性。

#方法通常首先查询风险的影响评级（见表3-13），然后查询概率影响矩阵（见表3-14）来评估每个风险的重要性和所需的关注优先级。

缺图：表3-13　风险影响评级[插图] 表3-14　概率影响矩阵

139 第4章　执行：依计而行，行必结果

140 4.1　无关人品，系统使然

140 4.1.1　系统的意志

#观点系统的意志决定了粒子做事情的阻力系数，按系统的意志做事是阻力最小的方式

#观点元素会继承系统的意志 2.符合系统意志的元素获益最大

142 4.1.2　结构决定行为

#案例狱警实验是心理学史上最著名、最有争议性的实验之一，曾经多次被改编成电影。狱警实验告诉我们：角色变了，人也跟着改变。

145 4.1.3　花瓶之碎，谁之过

#观点被误解的蝴蝶效应。人们心目中蝴蝶效应的一个形象写照：从小到大的一堆柱子排在一起，推倒最小的一根柱子就会产生连锁反应，最终把右侧的花瓶砸碎。谁谁砸碎了花瓶？是整个系统和结构

#观点总之，如果把一堆炸药放在一起，只要一个火星就能引起爆炸，那如果真的爆炸了，也不应该埋怨那个火星，而应该反思为什么炸药这么危险的东西不好好管理。火星总会来的，小骨牌总要倒下，蝴蝶总要振动翅膀。应该怪罪的是设计系统结构的人，而不是系统中的元素。

#观点把系统结构搞好了，我们就可以安心专注于正常的工作。

148 4.2　建组织：结构决定行为

148 4.2.1　职能型组织

#观点有趣的（职能型组织中常见的问题）

·高层感觉中层能力不行、素质不够，就替中层思考。

·中层感觉基层能力不行、素质不够，就替基层思考。

·基层没事干，也感觉高层领导能力不行，就替高层思考。

152 4.2.2　矩阵型组织

154 4.2.3　项目型组织

#观点项目性组织的缺点

它对企业的资源利用程度不够。项目资源被各项目组独占，当项目需要这些资源的时候固然能及时获得，但当项目不需要这些资源时却很难从项目组释放。

当项目遇到技术难题需要调用组织更多力量时，这种形式也颇为不便。

155 4.2.4　组织结构应与组织发展阶段相适应

#观点无数实践证明，成功的企业从诞生、职能化、规范化到逐步引入项目化，有着类似的历程和发展阶段，这个过程没有捷径。

158 4.3　带队伍：建设和维护高绩效团队

158 4.3.1　选择合适的团队成员

159 4.3.2　项目团队的组织方式

#观点项目团队的组织方式有很多种，但基本上可以归为外科手术式、交响乐队式、爵士乐队式和足球队式四种。最适合的就是最好的

1.外科手术式项目团队（所有人都围绕着主刀医生，主刀医生就是整个团队的核心。）

2.交响乐队式项目团队（在演奏过程中，指挥其实是一个精神领袖，团队成员都全情投入，陶醉在美妙的乐曲中。）

3.爵士乐队式项目团队（有一个灵魂人物，但是不脱产，所有人都参与演奏）

4.足球队式项目团队（有明确的分工，但是不规定在何时、由谁、在何位置、做什么，一切要随时进行调整）

164 4.3.3　顺利走过团队的生命期

168 4.4　善协调：项目管理是一个极具挑战性的工作

169 4.4.1　项目与部门间的冲突

174 4.4.2　项目间的冲突：“牛人”争夺战

178 4.4.3　影响项目的治理与人际因素

184 第5章　监控：审时度势，沉着应变

184 5.1　采数据：用数据而不是用感觉管理项目

186 5.1.1　用直方图展示和理解数据

190 5.1.2　用散点图寻找数据之间的关系

192 5.1.3　用帕累托图定位需要关注的重点

195 5.1.4　用控制图实现过程管控

208 5.2　控质量：质量是要命的事

210 5.2.1　项目质量管理的尴尬

#观点五中质量管理的水平

靠客户逼

靠检查控

靠过程保

靠设计防

靠文化治

212 5.2.2　项目需要什么样的质量管理部

#观点 QA 和测试的区别：QA的重点在于流程度量和过程改进，而不仅仅是问题测试

#观点名副其实的QA小组或QA经理具备以下特质。（QA工作对人的要求非常高，熟悉质量体系仅仅是基本条件，更需要很高的综合素质、业务能力和项目经验）

（1）有权有钱，能够对团队成员提供必要的培训。

（2）有权处理客户的投诉，推动客户投诉的处理。

（3）有能力制订过程改进计划，并根据过程改进计划进行组织结构调整、人员配置以实施过程改进。

（4）有能力、有权力通过多个项目来度量过程改进是否有效。

#观点合格的QA的三种角色

警察：及时发现和报告项目中的问题

教师：对项目成员进行过程和规范的培训以及在过程中进行指导等

医生：QA人员可以承担收集、统计、分析度量数据的工作，对项目过程进行诊断，帮助分析原因，开处方

215 5.2.3　决心比技巧更重要

#观点项目复盘中常常看到“加强过程管控，要求团队成员自检、互检，严格按程序要求实施，加强培训”等，1次、2次、5次、10次……有时连自己都麻木了，不是吗？——能做什么呢？就是坚持一贯的原则了。

218 5.3　勤监控：让项目走在正轨上

219 5.3.1　过程控制方法论

#方法解决问题的万能公式（行动之前要计划，计划之前要分析，分析之前要信息）

缺图

221 5.3.2　项目监督控制最佳实践

#观点很多的加班现象都是项目管理不当造成的

#方法 5分钟站立会议（5 minutes stand-up meeting）

是实践中项目管控的好办法。会议时，项目团队成员在固定时间（如每天上午8:30—8:35）、固定地点，每天站着围在一起，轮流主持、相互通报，每人回答以下3个问题。（1）昨天我做了什么？（2）现在我遇到了什么困难？（3）今天我计划做什么？5分钟站立会议既可以推动项目进展、跟踪项目问题，往往也可以提升团队对项目的责任感，起到团队建设的作用。

224 5.3.3　要想避免混乱，必须在沟通上下功夫

225 5.4　管变更：让变更可管理、可控制

225 5.4.1　唯一不变的就是变化

228 5.4.2　让变更受控

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

第一步，当有人提出变更时，首先要评估信息的准确性，确认项目变更事实。

第二步，提供变更申请的书面记录。

第三步，分析变更对范围、进度、成本、质量等诸方面的影响。

第四步，沟通变更影响，确认是否取消变更。

第五步，针对变更请求，提出相应解决方案。

第六步，查阅审批权限，选择合适人员对变更进行审批。

第七步，召开变更控制会议，批准或否决变更。

第八步，根据对变更请求的审批状态，与相关人员进行沟通。

第九步，指导与执行变更相关工作，跟踪变更执行状态。

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

#观点谨慎对待第一次：

如你顶不住压力同意了变更，这在事实上会给客户一个信号：变更是可以被接受的，只要对项目团队施压就行。

#方法利用框架效应（面临收益时人们会小心翼翼，选择风险规避；面临损失时人们甘愿冒风险，选择倾向风险偏好，以损失为导向进行沟通往往更有效。总之，忠告不如警告！）

#案例有点玄乎不太好理解总体就是说，要把不变更的收益、变更的损失清晰的对比出来

243 第6章　收尾：慎终如始，好戏杀青

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

244 6.1.1　收尾好才是真的好

#方法项目收尾工作的维度

缺图

248 6.1.2　提高成功的概率

249 6.1.3　编写项目收尾报告

#方法项目收尾工作应该包含的内容

第一部分，描述原项目（招标时）的基本方面，即范围、进度、成本、质量等。

第二部分，说明在范围、进度、成本、质量等方面与原计划的偏差。

第三部分，分析项目生命周期中的客户关系。

第四部分，总结风险管理，提供项目过程中发生的主要威胁和机会的列表，并说明是如何应对的，以及应对的实际结果。

第五部分，经验教训，包含事情的经过和采取的措施，并指出这些经验教训的受益者会有哪些。

250 6.2　过验收：项目不能做成烂尾楼

250 6.2.1　理解客户“真实的”问题是顺利验收的关键

251 6.2.2　验收后的工作

252 6.3　得总结：最大的浪费是经验教训的浪费

254 6.3.1　从无知之错到无能之错

#方法内部专利制度

参考专利制度，我们在实践中设计了一套行之有效的经验教训管理方法——内部专利。文档被其他人查阅一次就付一次费用给撰写人；同时，如果总结的方法被使用后，的确防范了问题的再次发生，由此降低的成本也给撰写人分成。在我所供职的研究院，有人撰写了非常有价值的文档，因为被人查阅的次数多、对问题解决的贡献大，仅此一项就拿到了不菲的现金奖励。

255 6.3.2　经验教训的悲剧

#案例 “二战”期间，盟军对德国本土展开空袭。盟军飞机遭到了德国地面防空炮火的猛烈攻击，大量飞机被击伤、击落，损失惨重。为降低飞机被击落的概率，有必要对机身的关键部位进行相应的加固。工作人员在对参战返回的飞机做了全面的检查后发现，几乎所有飞机的机腹部分都弹痕累累，而机翼却几乎没有被炮火击中的痕迹。军方决定对飞机的机腹部分进行加固，以此应对敌方密集的枪弹。哥伦比亚大学的统计学教授亚伯拉罕·沃德（Abraham Wald）却给出完全不同的建议：真正需要加固的是机翼，而不是机腹！

263 6.3.3　避免吃二遍苦、受二茬罪

#方法以项目后评估为契机，用结构化方法确保经验教训总结的有效性

缺图建议使用图6-3所示的结构化过程保证经验教训总结的质量。

#方法使用递增式方法管理文档

准备一份包含所有最终文档的提纲，并将此提纲放在每个团队成员的工作任务书里。然后，在项目过程中，当每一项关键任务完成时，都要求相应团队成员提供与任务相关的几句、几段或几页文档，然后将这些片段插入提纲内适当的位置。我把这种方法称为“递增式文档”。“递增式文档”操作起来相对不那么“痛苦”，为最终文档的完成提供了好方法。

265 6.4　去归档：让经验教训真发挥作用

266 6.4.1　让经验教训发挥作用不是一件容易的事

268 6.4.2　扎紧无能之错的篱笆

#方法如何做好经验/教训管理工作？

1.建立内部专利制度。采用正向激励，让提供经验教训的人拿到实实在在的好处。这是最关键的措施。

（1）追加案例前查重。在新项目实施和相关评审环节，项目团队必须提交经验教训检查表，确保案例库中的经验教训及其应对措施得以落实。

（2）将经验教训使用作为质量控制（quality control，QC）的检查项。作为项目质量工作的一项内容，QC部门将按照经验教训总结表对方案进行检查。

2.优化现有案例库

（1）案例库瘦身。

（2）简化案例描述。

（3）对案例按逻辑分类。