导图社区 《项目管理精华》
- 133
- 2
- 0
- 举报
《项目管理精华》
项目管理要点合集，如果你对项目管理一无所知，只是出于兴趣拿起这本书，想看看自己是否适合做项目管理——欢迎阅读本书！我建议你从头开始，逐章阅读，从基础学起，学习项目管理的理念，培养项目管理思维。接着再从头到尾读一遍，重点看看最后一章，先用学到的理论管理小项目，积累一定经验。然后，不断吸取经验教训，把项目越做越好！
编辑于2023-09-13 22:08:59 广东
- 《华为项目管理法》读书笔记思维导图
这是一篇关于《华为项目管理法》读书笔记思维导图，包含项目团队建设、项目质量控制、项目团队激励等。
- 《小型项目管理》
项目管理经验总结精华，从实战经验的角度给出很多优秀的Tips。 任何项目都可以被视为你长期职业道路上的进身之阶。没有任何项目是无关紧要、优先级别过低，或者与你切身利益无关的。
- 《项目管理精华》
项目管理要点合集，如果你对项目管理一无所知，只是出于兴趣拿起这本书，想看看自己是否适合做项目管理——欢迎阅读本书！我建议你从头开始，逐章阅读，从基础学起，学习项目管理的理念，培养项目管理思维。接着再从头到尾读一遍，重点看看最后一章，先用学到的理论管理小项目，积累一定经验。然后，不断吸取经验教训，把项目越做越好！
《项目管理精华》
社区模板帮助中心，点此进入>>
- 《华为项目管理法》读书笔记思维导图
这是一篇关于《华为项目管理法》读书笔记思维导图，包含项目团队建设、项目质量控制、项目团队激励等。
- 《小型项目管理》
项目管理经验总结精华，从实战经验的角度给出很多优秀的Tips。 任何项目都可以被视为你长期职业道路上的进身之阶。没有任何项目是无关紧要、优先级别过低，或者与你切身利益无关的。
- 《项目管理精华》
项目管理要点合集，如果你对项目管理一无所知，只是出于兴趣拿起这本书，想看看自己是否适合做项目管理——欢迎阅读本书！我建议你从头开始，逐章阅读，从基础学起，学习项目管理的理念，培养项目管理思维。接着再从头到尾读一遍，重点看看最后一章，先用学到的理论管理小项目，积累一定经验。然后，不断吸取经验教训，把项目越做越好！
- 相似推荐
- 大纲
第1章 成功管理项目涉及众多因素
如何使用本书
如果你对项目管理一无所知，只是出于兴趣拿起这本书，想看看自己是否适合做项目管理——欢迎阅读本书！我建议你从头开始，逐章阅读，从基础学起，学习项目管理的理念，培养项目管理思维。接着再从头到尾读一遍，重点看看最后一章，先用学到的理论管理小项目，积累一定经验。然后，不断吸取经验教训，把项目越做越好！
如果你突然要负责一个项目，又感觉无从下手——欢迎阅读本书！很多人都有过这样的经历。本书的内容很实用，可以指导你、帮助你。觉得在哪个方面吃力，你就可以直接跳到相关章节来救急。当然，项目管理受众多因素影响，项目出现了问题，基本上不会是单个因素的问题。所以，我建议你花些时间把这本书的其他部分也翻一翻，你会更有全局观，你的整体水平也会提高。
如果你已经是一位经验丰富的项目经理——欢迎阅读本书！或许你一直想提高自己的管理技巧和能力，或许你不想只会使用工具，也不想只懂那些流行一时的观点，而是想学习历久弥新的理念，那读这本书就对了，这本书中的内容能够经得起时间的考验。所以，不管你正在用什么管理工具，本书提出的原则都可以指导你提高效率。或许书中的不少内容你已经了然于心了，不过你可能能从书中找到自己没有考虑到的地方，或许你可以根据本书的框架，形成系统思维，不断改进完善项目管理
第2章 当项目经理的帽子突然戴到你的头上，你需要掌握哪些技能
什么是项目
对于项目经理精辟且实用的定义：他们是超级英雄
一方面，他们要收集数据、制订计划、跟踪活动进展、研究是否同意变更，并消除相关影响等。
他们能够看见各种活动之间的创新性联系，仿佛是一瞬间，他们就可以制订出针对性的解决计划；他们会用X光般敏锐的目光审查项目需求，巩固验收标准的薄弱之处，找出团队必须解决的问题；他们安排活动进度，与各部门互动，鼓舞组织成员士气，保证团队高效、顺利运转，如同高速前进的火车头一般，以惊人的能量向前发展。让我说得再清楚一些，项目经理负责安排、管理上面提到的所有事情，引领项目获得成功。
自我盘点：我是否具备成为项目经理的特质
第3章 项目经理在组织中的定位，项目管理办公室的职能
如果设有项目管理办公室
不同的项目管理办公室会有不同职能，但一般来说，项目管理办公室需要负责：
● 定义项目管理流程；
● 制定政策；
● 列出具体步骤。
也极有可能为你提供：
● 项目所需的管理控制规范；
● 组织使用的标准工具；
● 信息报送方法；
● 模板、清单等。
支持型项目管理办公室
支持型项目管理办公室仅提供支持。他们会为你提供模板、指南、信息以及培训，给你查询历史数据库的权限。通常情况下，你可以使用归档的所有文件。在项目一开始，他们可能会派人提供咨询服务，但只是出谋划策，并不会控制你的项目，也不为项目负责。如果你必须遵守某些行业准则、规章、条例或法律，支持型项目管理办公室极有可能会准备好相关信息，方便你使用。
此外，支持型项目管理办公室可能还会提供大量历史项目的相关信息。你的项目虽然独一无二，以往的项目或许与你的项目有相似之处，其他人是如何处理类似问题的？能不能把他们的成功经验用到自己的项目里？如果可以，直接照搬就可以！如果你正在考虑用某种方法解决问题，却发现之前有人用过类似的方法，却以失败告终，那你可以提前考虑换一种方法。
支持型项目管理办公室不会控制你，只会为你提供支持。如果项目管理办公室是这种类型，你在管理项目方面完全具有自主决定权。
控制型项目管理办公室
控制型项目管理办公室除了像支持型项目管理办公室一样，提供各种支持材料，还会控制项目的方方面面。如果项目必须遵守某些行业准则、规章、条例或法律，控制型项目管理办公室通常会列一张单子，你则需要向其证明项目符合以上种种要求。这种情况下，办公室极有可能会向你提供一些表格，让你按照固定的流程和方法进行汇报。此外，控制型项目管理办公室还要管下面的事情：
● 工具；
● 方法；
● 模板；
● 软件、数据库等资源；
● 开会要求；
● 汇报要求；
● 你必须采用的治理框架；
● 其他方面。
虽然控制型项目管理办公室会控制你应该做什么（也可能会列出“几不准”，比如，“不准直接与供应商联系，必须由采购部门与供应商联系”等 ），但他们通常不会插手项目管理细节。形式、框架、管理方式、总体安排、流程、治理结构、汇报方式等与项目管理相关的事务，都在他们的掌控之中。但是，项目任务、运作方式、执行项目、成果交付，这些都是你的责任！
指导型项目管理办公室
指导型项目管理办公室通常在公司内独立存在，其主管与公司其他部门的“一把手”级别一样，下面管着一些项目经理。公司每次启动项目，就会指定其中一位项目经理全权负责。从组织结构来看，他们是管理者，负责整个项目。
这种结构有诸多优势，能够确保：
● 整个组织可以通用并不断完善某种方法；
● 整个组织形成标准的术语和沟通方法；
● 使用可重复、可预测的流程；
● 使用通用的工具。
如果没有项目管理办公室，怎么办呢
如果你的组织中没有设立项目管理办公室，那么本应该由他们解决的问题，就需要由你亲自处理了。项目管理办公室本应明确项目经理的职能，毕竟任何项目的实施都离不开组织。因此，项目经理能否发挥其职能、项目运行是否良好，与完成项目目标同样重要。
有些关乎组织的问题，本应由项目管理办公室解决，但现在必须由你亲自处理。它包括：
● 以前有什么失败的教训？
● 组织有什么成功的经验？
● 组织的哪些政策和程序与你的项目相关？
● 你将如何与组织里的其他机构对接，它们又将如何与你对接？
● 你将如何与管理团队联系？
● 你将如何树立权威？如何维护权威（此外，你没有哪些权力）？
第4章 项目治理
为了帮你厘清思路，我们先来看看一些最常见的项目治理问题。
● 治理团队如何指导你应对各种规定、惯例和其他细节。
● 治理团队在组织中的定位，贵项目在组织中的定位。
● 治理团队的职能。
● 治理团队的组织模式（比如，治理团队中应包括哪些成员）。
● 与治理团队合作时的注意事项
项目治理团队的定位与职能
治理团队的定位
治理团队的职能
监 督
项目治理团队最基本的职能是监督，他们负责整个项目最基础的监督。虽然治理团队由组织内的高级管理者组成，但他们并不是超人，他们只能通过听取汇报来了解项目的进度！他们的职责，在于听取项目经理的汇报，了解项目进度。治理团队感兴趣的内容一般包括：项目进度、项目存在的问题、项目面临的挑战、项目绩效等。
指 导
成立治理团队，就是为了指导项目走向成功。一定要记住：治理团队关注的是项目，而不是作为项目经理的你！卓有成效的治理团队可能比项目经理更有远见，更有见识，想要成功，就要多听听这些远见卓识。
治理团队在决策方面也可以提供指导。有时候，治理团队可能会就如何解决问题给项目经理提出反馈意见。有时，由治理团队直接解决问题效果可能更好。比如：
● 定义项目范围：在第5章，我们会指出，项目治理团队要发挥的一个关键作用，就是确定、批准项目的范围。
● 确定预算、审批费用，确定时间表。
● 项目验收：在许多组织中，在项目结束时，治理团队要负责验收项目，并负责结束项目。
● 批准（或拒绝）项目变更申请。
● 治理团队要监督、管理组织在项目中投入的资源。
整 合
我们在前文中提到，所谓向上整合，就是将项目置于组织的整体战略规划、综合规划以及项目规划中。为了保证项目成功，可能还会涉及跨组织整合的问题。
项目往往会横跨多个部门，甚至会横跨多个公司（例如，涉及从其他公司购买原料，向其他公司交付产品等）。在这种情况下，如何安排活动、调配人员，收集、使用、传播、汇报信息，都是项目治理团队的重要任务。举个例子来说，假设你需要寻求其他部门的帮助，那这个部门的员工可能要加入治理团队中。你需要弄清楚，他们参与到什么程度较为合适。协调不同部门、不同组织是项目治理团队的重要职能。
控 制
在这里，我们使用“控制”一词，意思是确保项目遵守相关的规划、政策、法规等（比如，遵守成文和不成文的组织内部规定，遵守其他法规、规定、习俗等）。项目该如何证明遵守了这些规定？该如何客观记录？
在这种情况下，治理团队应负责建立项目控制流程，并进行适当的审查，以确保项目合规合法。
治理团队的形式
要保证加入团队的人员符合以下关键条件：
1. 他们要有代表性，要有发言权。如果他们还要和别人请示，那这样的团队效率不会高。
2. 他们能代表所在部门，能够拍板。
3. 他们加入团队是为了使项目成功。
常见的角色
● 项目赞助人：他们往往负责项目预算，从本质上来说，没有他们的钱，没有预算，项目根本做不下去。
● 实际上，项目赞助人通常是项目的倡导者。不过，有的组织规模大，结构复杂，可能会由一个人提供项目资金，由另外一个人推广该项目的优势。在这种情况下，这个项目倡导者是项目理念、精神的象征，可以激励整个治理团队。
● 项目管理办公室代表是否参与，取决于项目管理办公室在组织中的定位。
● 关键利益相关者：通常，所有相关部门、服务机构或组织都会派代表加入治理团队。如果想从其他部门调用人手，那么治理团队里有这个部门的人，调动起来就很顺利。
● 客户代表：可能是客户本人。有时候不适合让客户本人参加会议，有时候客户是市场（“虚拟”的客户），这种情况下，客户代表是能够代表客户需求的某个人。审批项目范围、需求、变更订单，这些都是项目治理团队的重要职能，所以，如果没有人站在客户的角度，想客户之所想，那么团队就很难起到作用。许多不错的项目以失败收场，正是由于他们忘记了客户的需求。
● 项目经理（当然，也就是你）。
RACI思维
RACI代表四种角色，即责任人（Responsible）、负责人（Accountable）、被咨询人（Consulted）和被通知人（Informed）。它是责任分配矩阵（RAM）的一种类型，这个矩阵有许多不同的类型/体系。
简而言之，这个模型把项目相关的活动与关键参与者联系起来，评估每个人在活动中所起到的作用。
● 他们对此项工作负责。他们可以将工作委派给其他人，但他们必须确保有人把工作做完。
● 负责人：他们负责以合适的方式百分百完成任务。我个人认为，这一角色负责管理、监督任务。
● 被咨询人：你可以向他们咨询，获得更多信息，助力任务的执行。
● 被通知人：他们不会亲自参与活动，但如果不及时通知他们项目的进展，后期可能会出现问题。
治理团队运营方面的注意事项
● 明确成功团队的定义；
● 召开有效、高效的会议；
● 建立团队关系以及良好的工作关系；
● 掌握演讲和沟通技巧。
项目管理铁三角
在项目的持续时间、时间表或进度中，项目范围从根本上决定了资源（即预算和成本）的使用（在本书中，我们把“范围”当作“质量”的同义词）。传统的项目经理把时间/成本/范围，或进度/预算/质量，或把其中几项混合起来，作为项目管理铁三角。
项目管理取得成功的关键因素是：
● 项目的预算/资源/支持；
● 项目的进度/时间表/交付日期；
● 项目的范围/质量/功能。
第5章 项目范围：定义、管理、调整项目的范围，避免范围蔓延
定义项目范围
◎ 假设条件
● 哪些资源可用（人力、材料、设施）？
● 财务方面是否存在假设（现金流、支付方式）？
● 供应商方面的假设（交货、信贷条款
● 将要使用的方法。
● 可用的技术（软件、平台、网络接入、计算机
● 架构和设计方面的考虑。
● 公差。
● 终端用户。
● 地理位置。
● 物质条件。
● 环境因素。
◎ 要 求
充 分
乍一看，好像挺容易，但是“充分”究竟是什么意思呢？这就要用试金石来检验。也就是说，如果把文档交给本领域的专业人士，他们能够理解这个项目的计划（不会产生疑问）。如果文档描述让人看不明白，那么文档的描述就不够充分。暗含的意思是，找一个具有相关知识、目光敏锐的人检查文档，听听他们的反馈意见。
完 整
“完整”这个词看起来简单，但你根本不知道“完整”这个概念做起来有多麻烦。“完整”就意味着一切都包含在内。如果要求里没有提及，那我们就不做。你可能经常会听到这样的话，“在我们这个行业，做了X，你就得把Y也一并做了。那你就得在假设条件里明确提出来！”（关于这一点，请参阅“限制、例外和不包括的事项”部分。）
为了确保需求提得很完整，你可能需要把需求细分一下。例如，同一个项目可能会有系统需求、整体需求、用户需求、维护需求等。按照不同的需求类型将文档分为不同章节，可有效确保需求的完整性。
准 确
把项目需求想象成一个镖靶。等你把需求都写入文档后，是不是所有任务都瞄准了靶心（而不是其他位置）？如果答案是肯定的，那么项目需求就很准确。如果发现项目有几个目标，那就要明确一下，是有意如此设计吗？如果不是有意这样设计，那就需要进行调整。如果是有意为之，就一定要明白，项目设置的“目标”越多，项目就越复杂，成功的可能性就越小。
明 确
在阅读文档时，每个人都会受阅历的影响。常言道，在人生不同阶段阅读莎士比亚的作品，每次都会得到不同的感悟。需求文档不应该像莎士比亚的作品。我们希望每个人，不管他们是谁，也不管他们在什么时候阅读需求文件，都能有同样的理解。如果不同的人对文档的解读不同，那就说明需求提得不够明确。找几个目光敏锐的人来审查需求文档。遵循下面的经典写作原则，可以让需求更明确。
● 一句话只表达一个意思。
● 避免使用过于笼统的语言，如适当的、一般来说、但不限于。
● 避免使用无法验证的词汇，如好、小、大、安全、对用户友好的、简单的。
● 避免使用笼统的条件，比如“必要时”
◎ 可交付成果
项目可交付的成果几乎可以是任何东西。学者们将其称为小部件。小部件是假设的生产单位。小部件可以是有形的东西、产品、服务或期望的结果。小部件是个通用术语，可用以指生产的任何东西、产品和服务。要确定项目范围，明确小部件是什么是关键。
工作分解结构（WBS）
如果一个项目的范围是由可交付的成果或小部件定义的，那么小部件也可以由其组件来定义。这些组件可以进一步分解，并由其组成部分来定义。你可以想象，这个过程可以不断重复，直到我们达到支持小部件创建的活动——类似于你的项目进度所需的粒度细节级别（参见第8章）。这种把一个问题不断分解的方法叫做层次结构分解，进而引向一种常见的项目管理工具——工作分解结构（WBS）。
如果你在拆某件东西的时候，还准备把这件东西再组装起来，那就不能丢任何东西。在进行层次结构分解时也是一样。当你拆解小部件的时候，每拆解一次，新拆出来的所有东西必须能够把上一层级构建出来。所以，在拆解小部件的时候千万不能丢掉任何东西。
◎ 验收标准
项目验收标准明确了项目应该做到什么程度。
在第7章中，我们将探讨不同的生命周期模型。在一些模型中，验收标准是开展某些活动的直接动力。可能项目的不同活动要达到不同的验收标准，可能项目总体要达到一整套验收标准。无论如何，这些验收标准都是项目范围文档的关键内容。
制定的验收标准越具体、越客观、可衡量度越高，就越好操作。要避免使用那些“听起来不错”但无法验证的术语。例如，如果说我们希望交付的产品对用户友好，谁能反对这一点呢？但“用户友好”是什么意思呢？一个人认为是对用户友好，另一个人可能会认为是浪费、是麻烦。验收标准中常见的“问题词汇”，除了“用户友好”，还有灵活、简单、充分、安全、充足、必要时、快速、小、大（花点时间想想还有哪些词听起来不错，但实际上意义模糊，可以有不同的解释。把这些词补充到列表里）。所以，在制定验收标准时，说得越精确、越清楚越好。
进度和预算
对客户来说，交付期限、重要阶段、关键日期通常是项目范围的决定性组成部分。如果错过了这些日期，那么就超出了范围。成本/预算也是如此，在企业中，成本超支和预算超支绝对不在考虑范围之内。
在现实中，在确定项目范围、项目需求和验收标准之前，至少要确定项目进度草案。这是因为，你至少要能够向客户证明，团队能够在成本估算/项目预算内按进度推进。如果达不到客户的标准，客户就接受不了这个项目，那么这个项目注定是失败之举。为了达到客户对时间和成本的要求，你可能需要调整项目范围文档的其他内容。在敲定验收标准和范围文档之前，先要就这些内容达成一致。这就意味着，虽然进度和成本/预算是独立的概念，但实际上，经常会在规定项目范围的文本中体现各关键时间点以及对成本的限制，在验收标准中通常也会涵盖在内。
争取支持
如果没有得到充分的理解和支持，那么范围文档编写得再漂亮也没有用。文字优雅、结构紧凑等表面文章都无关紧要，最重要的是交流沟通是否有效。范围文档的沟通作用是双向的。首先，项目范围文档要向客户传达出项目预期达到什么效果。其次，范围文档要向将要从事这项工作的人们传达，他们必须做什么才能实现项目的预期目标。在这里，上一章中讨论过的治理团队就派上了用场。在编撰范围文档时，要和治理团队合作（因为他们是项目执行人员的管理层代表
变更控制
作为项目经理，必须检视变更对项目的整体影响，例如对项目范围、进度、成本、人员等的影响。在教科书里通常建议，除非满足以下标准，否则绝不允许对项目进行变更。
● 变更以书面形式正式提出。
● 治理团队已经进行审查。
● 项目经理已经进行评估。
● 所有相关方均了解变更将对项目产生的影响。
● 变更请求上有正式签字，已被正式接受。
◎ “变更发起人”——捣乱鬼
变更要通过正式的流程，这种流程可以对变更产生威慑力。通常来说，变更会产生很高的成本，如果事先没有仔细评估，可能会有意想不到的后果，最终可能会毁掉项目。由于这种变化，在试图变更项目的人和项目的守门人（通常是像你一样的项目经理）之间会产生冲突。如果“变更发起人”不想按流程办事，那他们就会变成我们所说的“捣乱鬼”。
◎ 项目范围蔓延管理
项目范围蔓延有许多表现形式。
● 有时候，项目的某个组成部分会出现某些“附加的东西”，本身似乎无可非议，但这些东西加起来就超出了原本确定的项目范围。
● 项目在某些环节发现了一些有趣的东西，这些多出来的工作可以安排在这个项目名下，但并不在这个项目的范围之内。
● 有些人发现，只需稍微多付出一点，项目就可以轻轻松松有所得，受这种“快餐”的诱惑，项目很容易超越原有的范围。
● 我们急于赶进度，所以就没有纠结于那个要求，转而走了这条捷径……是的，范围蔓延是双向的。我们通常谈到的都是，超出项目范围之外。然而，我们也有“理由”不按要求偷工减料。通常，大的灾难的发生都可以追溯到一个个小小的借口，不断叠加，最终就会不遵守安全要求或规定，最后灾难不可避免地发生了。
第6章 项目质量计划
满足客户的需求
◎ 什么时候越多反而越不好呢
和普通大众的想法不同，越多并不总是越好，越多只会让事情变得更糟！如果你提供的服务超出了客户的要求，有时候你可能做对了，就会讨客户高兴。但有时候，做得太过反而会引起不满。虽然有时候越多越好，但是如果你想让项目超出客户的要求，你可能会给项目惹下麻烦。
狄克逊、弗里曼和托曼的研究（2010）发现，“取悦”顾客无助于提高忠诚度。相反，为客户服务时，能够快速而轻松地帮助顾客解决问题可以提高客户的忠诚度。对此我的解读是：好钢要用在刀刃上，要一针见血！花心思取悦客户，还不如花心思把事情做好。
◎ 谁是我的客户
在制订质量计划时，你必须知道自己的客户是谁。只有这样，你才能知道自己必须满足什么要求。我建议把治理团队当成你的客户。
治理团队要综合考虑客户需求和其他因素，例如战略计划、整体目标和运营普遍存在的问题等。管理层的目标与用户的目标可能并不相同。管理层可以跳出用户需求的限制，从公司发展的角度去看待问题。管理团队有责任研究客户，收集客户需求信息，并根据公司发展目标，在不同因素间取得平衡。
因此，无论你如何剖析，你的客户永远都是治理团队。请记住，你之所以选他们进入治理团队，是因为他们贡献不菲，具有深刻的洞察力。如第4章所述，治理团队中会有“客户”/终端用户代表。绕过治理团队直接收集终端用户的需求或许可以实现一些目标，但是如果平衡不好与管理理念和目标之间的关系，这样做会让项目陷入不同程度的失败。
◎ 控制：如何衡量/确认已经满足需求
好的质量控制计划中要包含控制标准，证明需求已经得到满足，或者需求正在得到满足。好的控制标准必须客观，即，不管由谁来控制质量，结果都是一样的。有人认为，控制标准必须可量化（意味着控制度量产生一个数字）：这种观点是有价值的，因为数字容易处理、操作和分析。
控制的关键是首先确定需要度量什么。有时你无法度量你想要控制或验证的东西，但你可以度量代用品，例如在汽车保险示例中，事故率（一个客观数字）代表着你的驾驶质量（一个主观判断）。
◎ 可追溯性/ 需求追溯矩阵
好的项目质量计划具有可追溯性。正如在第5章中提到的，可追溯性意味着，每个需求都可以追溯到可以满足此需求的某个或某些活动。这表明，你有满足此需求的行动计划。此外，这还意味着，可以把控制或验收标准（以前提到的）与其评估的需求联系起来——表明你可以对照需求来验收交付的项目成果。在质量计划中，追溯部分通常称为需求追溯矩阵，或RTM。
需求、活动、控制/验收测试之间的联系通常可以用矩阵来表示（下面将详细介绍）。这个矩阵不仅要说明活动实现了所有需求，而且说明项目已经通过控制/验收测试，证明项目满足所有需求（这就是我们将项目质量计划纳入范围文件的原因，我们希望客户在控制/验收测试上签字，确认项目已满足需求）。需求追溯矩阵有以下几个关键点。
● 所有需求都由一系列活动来实现（即没有孤立的需求
● 所有活动都是为了满足项目的某个需求（也就是说，没有孤立的活动
● 所有需求在项目成果交付前，都要通过控制或测试。
小错误造就大成功（原型设计）
我们最宝贵的教训有很多时候来自我们的错误。然而，如果错误大规模发生，它们可能是毁灭性的、不可挽回的。假设我们能找到一种方法，让我们的错误在小范围内发生，并把学到的教训应用到大范围内，那么我们的成功将是巨大的！
有这种情况，这叫作原型设计。
威廉·爱德华兹·戴明给我们带来的一个质量工具是戴明循环——有时被称为缩写：PDCA（计划、做、检查、行动/分析）。在第7章中，我们将着眼于基于此思想的整个生命周期模型，称为快速原型生命周期。无论你是否使用生命周期模型，在每个项目中都会有一些地方没有被完全理解。
一个好的项目质量计划会查看项目中可能出现的误解、错误或简单的断开会导致问题的地方：项目的高风险部分。如果在这一部分出了差错，影响可能是毁灭性的。在回顾这些领域时，你可以询问原型设计来避免出现此类问题，换句话说，制订一个包括原型设计的质量计划，这样你就可以犯小错误，但能获得更大的成功！
第7章 项目生命周期模型
经典的瀑布模型
也就是预测法，所谓的瀑布式项目计划生命周期模型可能是最古老、最自然的项目计划形式。
◎ 为什么叫瀑布模型
首先用方框表示项目的不同步骤，从页面左上角开始，到右下角的最后一个活动结束，按照顺序排列。然后用箭头把方框连接起来。项目画出来可能类似于图7.1。
如果一个项目具有以下特征：
● 你能够充分、彻底、准确地收集需求（已达到共识的需求
● 你完全清楚完成项目需要什么样的知识，而且能够获得这些知识；
● 该项目会修建实实在在的东西。
那么你可以按照以下步骤管理项目：
1. 收集全部需求，让相关方就需求达成一致。
2. 画出设计图纸，制订施工计划。
3. 施工/实现设计方案。
4. 验证/确认没有差错。
5. 维护/交付产品。
◎ 假设一
你能够充分、彻底、准确地收集需求，并且让所有人就需求达成一致意见。
瀑布模型的关键在于项目伊始就有合适的需求。何为合适？对于瀑布式生命周期来说，就是需求的提出要基于类似的经验。项目经理根据以往类似的经验，或者基于项目信息，细化需求文档，明确项目内容。如果你没有类似的经验，没有这些基准信息，那么你的预测就没有根据，你也没有进行预测。例如，如果你打算在城市里盖一座房子，而贵公司已经建造过很多类似的房子，那么，应该很容易明确需求。但是，如果你想在月球上修一座房子，你可能一开始提不出特别合适的需求。瀑布模型就不适合这样的项目。
◎ 假设二
项目经理知识渊博，足以完成项目。
应用该模型，则要求公司熟悉项目所有要素。贵组织必须熟悉此类型的项目。如果以前没有人做过类似的项目，那么你就没有提项目预算、计划和资源的经验。如果是这样，瀑布型模型的用处就不大。相反，如果这个项目和之前的100个项目都类似（或者说，如果这个项目的所有要素在其他类似项目中出现过，而且项目经理对此很熟悉），那么贵组织对项目的熟悉度就足以保证项目顺利结束。在这种情况下，就可以用此生命周期模型制订相当准确的计划。
V模型
V模型类似于瀑布模型，但是我们的“瀑布”是折叠的，在项目的最后阶段和初始阶段之间有明确的联系。
V模型的一个经典特性是，每个开发活动都与测试活动有明确的联系，测试活动可以衡量开发活动的成功程度，每一步都是成对的——一个活动/任务，以及对该活动/任务的测试。对于使用V模型的项目经理来说，定义这些测试和相关的标准是计划阶段的关键部分。
快速原型模型
螺旋模型和RAD模型
。将PDCA与原型设计的思想融合，你就可以重新派生项目管理的螺旋和RAD生命周期模型。
● 0步骤：0是观察当前情况。定义项目目标的初始版本。这个项目的动机是什么？我们称这个步骤为0（0）是因为我们在开始之前做了这个。
● 步骤1：P代表“计划”。在这一步中，我们分析和识别我们的项目可能面临的风险。从科学的角度来看，我们问：我们需要学习什么才能使我们的项目成功？我们制订了一个学习这些信息的计划，其中可能包括建立一个原型。原型可能没有完全发挥作用。它只需要演示正在研究的组件，这样我们就可以回答手边的问题。
● 步骤2：D代表“做”。这里我们做计划。我们更倾向于小规模地做这个计划。我们也可以把D看作是开发（或制造
）原型的工具，以解决我们在步骤1中提出的问题。
● 步骤3：C是“检查”原型的性能。进行我们的原型所体现的实验，或者换句话说，收集第2步产生的数据和反馈。
● 步骤4：A是“分析”收集到的数据。调整我们对这个项目成功必须完成的任务的理解，增加我们对需求的理解。
● 步骤5（1b）：有了这些精练的见解，我们回到步骤1。这一次我们将其称为步骤1b。在这里，我们分析和识别我们的项目可能面临的风险，基于我们从之前的原型实验中学到的。从这个角度出发，我们细化了关键问题，并制订了一个新的计划。
● 步骤6 （2b）：开发新原型。
● 步骤7（3b）：检查新原型的性能，收集反馈。
● 步骤8（4b）：分析、调整、增加我们的需求。并继续。
第8章 规划项目一—进度管理（时间管理）
项目经理最具有代表性的职能是活动规划和进度管理，也就是该做什么，该什么时候做。有以下五个核心职能：
● 项目经理必须明确要完成哪些任务才能实现目标。
● 有些活动必须具备先决条件，有些活动后续还要有相关活动。根据依存关系确定活动的顺序很重要。
● 估计活动需要的时间。
● 制作进度表（有些人会认为在确定活动顺序的时候就要明确进度。稍后我们将讨论二者之间的细微差别
● 项目经理必须管理进度。
活动是指什么
● 每个活动都要有输入，输入源可以是需求文档，也可以是前面各个流程的输出。总之要有输入源。
● 每个活动都要使用资源。事情不可能凭空发生。活动必须要有人力，必须要使用或消耗资源（在第9章和第12章，我们将详加讨论
● 活动必须按照一定的标准开展。活动必须符合某种规范，或者必须受到一定的限制。如果没有标准、规范或限制，那么活动就没有实质性的意义——因为怎么做都行。如果怎么做都行，那就不要在上面浪费时间。如果一件事不值得做好（即达到标准），那可能根本不值得去做。
● 有了输入，有了资源，有了标准，接下来要有方法和流程，这样才便于操作。没有方法或流程，何来活动可言？
● 最后，活动必须有输出或结果，而且必须以某种方式进行应用。几年前，我专门在定义中添加了输出“被使用”这最后一点。这点听起来可能很容易理解，但是我碰到过很多项目，其他的标准都符合，就是输出没有进行应用。如果在制订项目计划时（或者在接管一个项目时），发现某活动没有输出，或者输出没有得到应用，那么你可能马上就有机会节省开支了！这样的活动取消掉，不会对项目产生任何负面影响，因为它的输出没有得到应用。
为活动排序
现在我们必须将摘要活动排序。我们要按照单一活动的管理方式来管理摘要活动——摘要活动可能和其他摘要活动有先后，也可能有依赖关系。
预估活动开展时间
◎ 计划谬误——人们往往会低估
一般来说，项目规划很大程度上依赖于直觉判断和有根据的猜测。“大致估计”这个术语（通常也指估计值）是指在没有足够信息的情况下进行估计。在现实生活中，通常要在信息不完善的情况下推进项目计划。我们都会估计，有一定的道理。那么，专业知识和经验难道就不重要吗？
每个人都记得估计比较准的时候，而会刻意忘记或下意识地减少他们估计不太准的时候。通过科学跟踪，卡尼曼和特沃斯基发现，在进行项目规划时，专家的估计并不比普通人准多少。其他研究人员验证了他们的这个研究结果。此外，这项研究还表明，征求更多人的意见并不会得到更准确的答案——咨询再多的人也无法弥补这个缺陷。这是为什么呢？
大多数人讨厌的偏见是系统地将时间和资源需求最小化。人们倾向于认为可以花更少的时间和资源就能完成某项任务。有些人认为这是由于人们有不切实际的幻想，但卡尼曼和特沃斯基发现，即使人们会因低估而受到惩罚，但他们仍然会低估某些关键细节（这就说明人们有这样的倾向并不是因为他们有不切实际的幻想）。如果人人都会低估，那么即使让再多专家、再多有经验的人士估计，估计结果仍然低于实际。
设定基本规则
在组建治理团队时（参见第4章），必须制定一些规则来规范项目估算。也就是说，要知道大家都会觉得估算太高（持续时间太长，资源消耗太多，成本好像太高）。如果在过程中出现了错误，我们就要修正这些过程错误，而不能只调整结果。如果过程无误，那我们就要接受结果，不能强求，非要让项目达到想要的结果。
小模块和定期检查
大多是开周例会。如果是每周开例会，那么项目经理管理的最短活动原子保持在2周左右比较合理（整个活动持续3周到4周可能更合适）。当人们对超过4周至6周的活动估算时，我发现卡尼曼和特沃斯基提出的计划谬误效应会表现得非常明显——因为一项活动涉及的内容越多，记住所有内容就越难。所以，如果有人说他们要花6周或更长时间做某件事的时候，我会试着把这件事分解成有意义的“原子”，每个原子持续2周、3周或4周的时间。然后，通过整合摘要活动，我们对耗时更长的活动做出估计。
使用真实的数据
只要可能，参考历史数据来估计当前的活动。在理想状况下，根据历史数据，你可以知道类似的活动实际耗费了多长时间，要注意哪些问题。请注意：如果活动原子的历史数据超过了4周到6周，那很可能有问题。
和真正执行任务的团队确认
估计好活动时间后，要和实际执行任务的人员确认。最好让他们接受估值，并在同意书上签字。
让相关人员签字有两个作用：
1. 在签字前，他们会确认估值是否准确。
2. 一旦他们签字同意，他们就更有可能把估值变为现实。
◎ 估算工期的结束语
时间是这样计算出来的：
● 征求活动原子负责人（他们要确保活动按时完成
）的意见，让他们估计一个可能性最大的工时，一个最坏情况下的工时。让他们签字确认这两个工时。
● 然后，根据他们过去预测的实现情况，根据“折算因子”算出可能性最大的工时和最坏情况下的工时。
● 根据历史数据，算出折算后的可能性最大的工时的平均值。然后算出平均值和可能性最大的工时估值的差，加到最坏情况下的工时的估值上。
● 这样我们就算出了可能性最大的工时（MLT）和最坏情况下的最长工时（WCT）。
安排活动进度
◎ 避免单线执行
真正的项目是个极其复杂的网络，里面涉及大量活动，相互依存，相互关联。等我们探讨项目细节的时候，第7章中理想化的生命周期将会进化和成长以适应现实。
我们要考虑两个问题。一是如果我们按顺序推进活动的开展，那么项目工期过长。二是单线执行流程中的各个流程都是潜在的故障点。基于此（以及其他原因），我们要加强规划，争取能够同时推进各项活动。这样，项目耗时更短，效率更高，也更有弹性。就算项目的某个环节出了问题，我们可以弥补那个环节的问题，同时还不会影响项目整体交付时间。
◎ 关键路径
在制作进度表时，项目经理会使用关键路径，这是人为提出的概念。为了理解项目经理对关键路径的定义和论述，我们首先需要理解两个术语：“浮动”和“自由浮动”。
管理进度
◎ 项目管理工具
总的来说，这本书主要强调管理原则，不太讲管理技术。管理原则的持续时间长，而技术的持续时间较短。然而，可以应用当代管理技术来支撑管理原则。进度管理工具就可以发挥这样的作用。要迎接项目进度管理的挑战，项目经理肯定需要使用相关的工具。
◎ 可视化和常见软件特性
不同项目经理可能有不同的需求和偏好，但我认为，项目规划软件必须具有以下基本功能。
● 甘特图功能：甘特图是经典的横道图，表示时间轴上的活动。通过甘特图，可以看到项目某些部分的情况。同时，还可以把多个活动整合为一个摘要活动。使用甘特图，可以很清楚地看出哪些活动可以同时开展，哪里存在浮动，等等。现在的项目经理沟通的时候会谈到这些内容。
● 显示相互之间的关系：能够显示活动之间的依赖关系、关联和联系（即哪些活动是前提，哪些活动是后续）。一般来说，通过软件，可以用箭头把甘特图的条形图连接起来，以此显示不同活动之间的关系。
● 关键路径规划：软件必须能够把关键路径标识出来。真正的好软件还能够重新规划关键路径，管理关键路径。
● 自动更新：更改某个活动（如更改开始日期、持续时间、依赖关系等）后，软件可以自动计算出对整体计划的影响。
现代项目规划工具还有一些有用的功能：
● 能够分配、管理活动所需资源。基于此，现代项目规划工具大多可以确定资源荷载。如果资源被“超额预定”，那么软件会用不同方式展示出来。项目规划工具可以均衡荷载，调度资源，实现资源的合理利用。
● 展示与任务分解结构（WBS）的关系。好的项目管理软件可以明确展示任务分解结构→活动→资源分配之间的关系。全面了解活动全部信息以及人员的需求，是项目成功的关键（更多内容见第9章
◎ 跟踪进度，更新进度，重新规划
跟踪进度、更新进度、重新规划，是现代软件工具的优势所在。真正优秀的项目计划软件可以整合组织内的其他信息。具体信息包括：
● 允许其他部门提交摘要活动的详细计划；
● 时间报告工具，允许人们根据项目计划安排自己的时间；
● 进度报告，允许人们报告活动进展情况。
第9章 项目人员配备计划
制订人员配备计划时，项目经理须考虑以下事项：
● 项目需要哪种类型的人员？必须具备何种技能？人员具备相应能力吗？
◇ 商品型：几乎每个人都可以胜任，该类型是可替代的“商品”。
◇ 技术型：人员的能力或经验影响其生产效率。
◇ 知识型：人员拥有某方面的思维能力或知识。
◇ 专家型：要求是某方面的专家。
● 资源配置如何影响任务完成的时间——更多人会加快完成任务吗？
● 分配资源的管理需要什么条件？
● 是否有特殊的资源（只有某个人才能做这项工作吗）？
● 是否有资源计划备案？（如何管理疾病、伤残以及人员流动率？）
● 资源的负荷极限是什么？人员是否负荷过重或不足？
人员配备
大部分公司利用以下四种典型的人力资源进行人员配备：
1. 内部人员：该类人员已经在公司工作。公司中的某个人负责对该类人员进行监管。根据需要，这类人员经常由管理部门分配并参与项目。
2. 客户提供的人员：这类人员来自客户的公司，并由客户的公司负责管理。该类人员可以按需为某些项目活动提供帮助。（若客户招聘人员或把活动外包给第三方，我们依然可以依靠这类客户，因为管理这个过程的是我们的客户。
3. 雇佣人员：公司会雇用人员参与项目。雇用后，内部人员（以上的类型1）将负责管理这类人员。通常公司招聘人员时，人力资源部门将处理许多行政细节。但如果通过第三方招聘人才，采购部门或采购与人力资源部门共同管理招聘过程。
4. 高端或专业人员：假如公司将高端人才搜寻工作委托给第三方，项目活动结束前，需要考虑谁将提供并管理这类人员。（通常由某个人管理这些关系，可以是采购部门、人力资源部门的人员，或两个部门的人员，或一个专办员。）有时，此类第三方是专家或“真实顾问”的形式。
◎ 关系管理
但从概念来讲，各类都有自身的缺点。
● 内部人员：你需要处理公司内部行政事务以及组织权衡工作。
● 客户提供的人员：管理客户同时还要处理很多由此而来的其他问题。
● 雇佣人员：人员获得、试用、正式工作的时间需要考虑（可以将此设计到项目中去）。雇用后，你不得不与管理他们的人打交道。
● 高级或专业人员：这类人员具有特殊性，难以获得，需求特殊。将部分工作单元交给第三方，需要你明确可交付成果、对成果的要求，以及其他参数。这就像一个大项目中的迷你项目。
管理不同类型的劳动力已有很多著述，将不在此赘述，强调以下几点。
● 培养你的治理团队并为其配备人员，以便它代表整个组织的经验。
● 注意到这些问题。
● 与你的治理团队一起建立你的项目团队，同时留意不同类型的劳动力的各种状态。借助他们的经验，做有益于组织的事情。
◎ 备份计划
要解决的最简单的问题也许是你逃避的问题。你需要记住，永远去欣赏项目中的同事，欣赏他们生而为人的事实。在你的人员配备计划中，考虑这个问题：如果有人退出，事先没有任何征兆，如何保障项目进行下去？我们有可以在任何时间了解工人实时工作状态的“记录计划”吗？别人可以通过工作记录，让工作得以延续吗？是否有人得到他们的指导、训练？又或者组织内有人可以替代他们吗？
备案人员是否：
● 十分熟练；
● 较为熟练（一般对项目和工作较为熟悉，随时可以上手）；
● 不熟练（有人手，但上手需要时间）。
定义人员需求：技能跟踪
岗位人员配备时，项目经理常常找不到称职的人选。一般有两个原因。
第一，招聘的主管真正的意思是，按照他的工资标准，找不到合适人选。
第二，找不到“合适人选”，是因为招聘经理没有准确定义何为“合适”。大多数人都是“合适”的人。招聘经理真正的意思可能是他们需要能实际干活的人。要雇人，招聘经理必须首先清楚工作的具体要求。
时间和人员工作量
人力资源管理
当你将人力资源分配给各种活动，计划便形成了，你将需要管理这些人力资源需要考虑建立基础设施的重要性，能够具备以下功能：
● 与项目人员沟通；
● 支持项目人员的组织身份；
● 支持人员编排；
● 支持项目重点人员。
第10章 设计与配置管理
谁将负责配置管理
项目经理无论在某个领域有多丰富的经验，都不要认为自己了解配置变化的影响（无论变化多么微小，尤其在涉及关键特征时）。一旦涉及关键特征，一定让设计团队或设计工程师参与其中。
正式定义配置管理
为了达到我们的目的，产品（项目的输出）“配置”的定义需包含以下内容：产品的组件如何安排或设置，组件之间如何组合来满足要求，还包括组件组合的过程以及所用的资源。
◎ 用于更改事物的配置管理
假设我们已经形成了产品部件的第二个版本（版本2.0），第一个版本（版本1.0）和第二个版本目的都是一致的，但2.0版本更可靠、简单、成本低、运行快。
2.0版本实现关键特征的方式与1.0版本不同。当你使用不同版本的产品部件、订购零件或在不同环境中使用产品部件时，你如何知道产品部件的哪些组件适用于当前的问题？订购哪个零件？哪种环境条件适合这个版本？完善的配置管理系统能够通过产品版本溯源，寻找相关“配置产物”（决定产品部件配置的内容），帮助你回答这些问题。
◎ 变化影响的配置管理
另一方面，当对复杂的产品进行修改时，重要的是要知道该改变将带来哪些关联影响。产品组件若发生变化，如何跟踪变化给产品特征带来的影响？或者，假如项目要求发生改变，如何发现所有需要更改的事项以适应新的要求？完善的配置管理系统能够帮助你了解不同因素之间的相互作用，实现更改，而不会无意间在产品独有的配置网络中造成可怕的后果。
以这些要求为目标，知道我们需要做什么，知道如何管理行动的影响，我们才能开发配置管理系统。
配置管理和项目要求
配置管理所要管理的是项目输出的元素以及这些元素的相互作用和结合方式，有时也管理最终产品形成中元素组合的过程。定义的最后一部分内容至关重要，因为在某些行业，过程即产品。
设计跟踪矩阵
◎ 设计的关键特点是什么
◎ 现有系统、隐含要求和基准设计
获取配置和使用它的支持系统
第11章 成本规划和成本管理
人们对项目活动和相关费用支出的态度，我认为构成了成本规划和管理好坏的关键因素。当然，态度好，但不使用好的数据和系统，结果也会不好。项目经理采用了正确的态度、方法和理念，将有以下好处：
1. 最大化利用手头上的工具；
2. 需要的数据可能过期或不匹配需求时，能够敏锐发现问题；
3. 即使存在差距，也能够创建自己的工具和系统；
4. 挖掘数据，找出提升信息质量的方法。
相反，假如采用了错误的态度、方法和理念，再好的系统也无济于事。好的项目经理并不能造就好的系统，但是，好的项目经理可以利用好现有的工具和系统。需要时，项目经理能够利用这些资源缩小关键的差距
成果和资金管理的倾向
图中矩阵展示了两个变量的关系：资金的类型（自己的资金、他人的资金OPM），资金用途（个人用途、其他用途）。
◎ 使用我的资金与关注自身利益
公司老板或老板代表对项目管理的期望可能是“我的钱我关心”。钱是他们的，所以他们十分关心公司所有业务的成败，包括你的项目。他们要求精确的支出计划，即使不能做到，也要给出合理的预测。他们要求对成本进行密切的监督。假如支出超出了预算，和你的个人生活一样，他们希望作出调整，好让整个项目开支不超预算。
我们要在项目管理中引入这种理念是希望项目中的每个人都把项目的钱当成自己的钱，希望每个人都有内在驱动力保障项目的成功。
◎ 关注自身利益与使用别人的资金
要让人们的视角从第二维度的思维转变成第一维度的思维。各人有各自的绝招，但你要找到属于自己的方法。如果项目低于预算完成，我会给人一些奖励。比如，将省下来的50%发给他们，虽然有时金额较大，但毕竟我也省了很多成本，为何不这样做呢？如果项目超支，要进行惩罚。达到了预算，减少顾问的小时工资，等等。这样做的目的是让人们的态度和行为转变成第一维度的态度和行为。做到这一点，成本管理就会变得更好。
◎ 使用我的资金与关注别人利益
人们一般不会故意忽略别人的需求。在生活中，事先针对重要的事宜进行沟通将会十分重要。同样的道理，你也要跟你的客户和团队进行充分沟通，要搞清楚以下方面。
● 哪些特征或部件十分重要，且是他们期望的。忽视这些要求，产品注定失败。
● 他们青睐哪些事宜、特征或部件。忽视这些要求，产品不一定失败，但也不会成功。
● 哪些内容是他们希望拥有的，或有了更好。但是如果造成项目严重延期或增加很大成本，不如去掉这些内容。
● “多余”或“奖励”元素：我们想要拥有，但却没有必要。如果时间充裕，不增加成本（或增加一点成本），你还想给产品增加亮点，那么就将这些元素考虑进来。
◎ 使用别人的资金与关注别人利益
假如你将项目的部分工作委托给其他部门、供应商或团体，会有哪些变数？若被委托方用你的经费而对结果不负责任，问题将难以避免。你要做的是，将他们的利益与项目结果绑定在一起，与相关花费绑定在一起。有很多技巧可以将第二维度和第三维度的思想转变为第一维度的思想，利用这些技巧的组合是有帮助的。项目质量低，工期延误，成本超支，都是第四维度常常遭遇的问题。
◎ 成本规划和成本管理的态度：总结
假如项目完全是你的，也是由你制订所有支出计划，每一笔支出都经过你，结果自然是好的。然而，还有一种少见的情况。你问别人要他们所负责项目部分的支出计划，然后将每个部分整合在一起形成项目总体预算。当项目开始执行，其他人的项目造成了超支以及超支责任，他们的行为结果最终汇聚到你的项目预算中来。这时，他们的问题变成了你的问题。
正在做的事与将要花的钱之间的联系，决定了支出计划的准确和详细程度，也决定了成本管理的水平。理想的结果（在现有工具条件下
）是让每个人都认为花的是自己的钱，思考的是自己的事。同时，他们会在现有工具条件下，努力监督并检查各项支出。假如他们认为在花别人的钱，或做的不是自己的事，结果可想而知。
如何让人以第一维度的想法参与项目，方法有很多，但是没有一种是万能的，能适用于所有情况。你需要找到最适合本项目人员和供应商的方法。为了制订最佳的成本计划，成功管理项目成本，要确保团队的动力和投入与项目保持第一维度的关系。
当前数据、历史数据以及估算价格、合同价格
制订项目成本计划时，需要很多不同人员提供支出信息，要提出的问题如下：
● 是否使用了当前数据？
● 是否考虑了历史数据？
● 对方提供的价格是估算价格还是合同价格？
◎ 当前数据
制订成本计划时要确保数据是当前的，或与支出发生的时间匹配。在成本计划中，我遇到的典型问题是使用旧数据。我相信没人故意这么做，但是问题还是悄悄出现了。最后看到成本超支，每个人都会大吃一惊。总之，要确保你使用的数据是当前的。
◎ 历史数据
历史数据对价格信息管理十分重要。我们将在第12章如何管理供应链部分详细讨论。假如原来供应商的初始报价是10元/单位，但是交付时总价变成了12元/单位，因此在未来制订支出计划时，供应商的报价需要额外增加20%。
◎ 估算价格或合同价格
估算与报价（我称之为“估算价格与合同价格”）。问题的关键在于在某些领域中，“报价”这个说法已经失去其严格的意义（其他领域“报价”依然是报价）。换言之，报价或合同价格就应该是固定的，不能改变。不管怎么命名，若事情是有待确定，容易变化，等等，那么这件事只是一个大概。对于我们讨论的内容，这就不是报价或合同价格。
估算价格存在变化的提醒信息包括：
● 估算价格没有考虑到最终交付产品成本降低的可能性；
● 没有标注价格浮动上限或考虑最坏的情况；
● 估算价格存在误差，却没有提供解释；
● 没有进行重新评估的标准（例如，当这种问题出现，我们需要重新对事情进行评估）。
项目计划费用、要素费用以及组织费用
每个组织都有适合自己使用的会计工具和方法。项目管理办公室、管理团队以及治理团队都有惯例和经验，希望你遵守。你要与项目管理办公室加强联系，让管理和治理团队参与进来。了解他们对你的要求，包括：
● 考虑哪些成本，如何分类，成本的详细程度；
● 如何表示并考虑估算费用、合同费用以及费用的变化；
● 编制、展示成本计划使用的工具。
◎ 成本计划工具
很多项目计划工具可以帮助你为项目活动安排人员，能够记录劳务费用。你也可以借助计划工具为任务或摘要任务分配成本。借助网络工具或云工具，可以让你的团队成员替你填入这些数据。确定了项目计划中每个条目的详细费用，使用工具进行管理，就会产生计划的费用。要学会使用计划工具，并充分利用。
◎ 材料清单（BOM）
有了项目成本，也可能产生要素成本。在进行某项设计时，一开始你的团队可能考虑不到所有的要素。由于缺乏具体的信息，你会让团队估算费用。设计团队根据指导，合理计算，拿出相对准确的估算费用。然而，估算就是估算，不能当作实际费用。让他们提供估值的变化范围（最高值与最低值）。密切监督要素的成本变化，适当作出调整。
◎ 组织费用
除了项目计划费用和要素费用，还有组织费用（常称之为日常费用）。每个组织都有自己的习惯或惯例，由此产生的费用叫作组织费用。组织费用有时分摊到团队的工资中（已经支付），有时单独列出，或两种情况都有。项目是否给公司律师付费？当进行产品生产时，组织如何认定设施使用费、办公场地使用费、桌椅及其他项目使用费？组织费用类型还有很多，组织会产生一些每个项目必须要缴纳的传统费用，也有各自的记账惯例。你的项目不能忽视这些费用。
第12章 项目的供应链方案
垂直整合的提示
如果你的公司进行了垂直整合，这意味着所有的供应商都是来自公司内部（均为公司的一部分）。运行良好、管理良好的垂直整合运营可以大大简化原材料的采购程序。假如一切都来自公司内部，对某些手续的要求就可以放宽。例如当公司的一个部门向另一个部门采购材料时，可能不需要律师，但是从外部采购材料，律师就必不可少。同理，我们可以优化供应链的特征和运营，可以开发出高质量的、对整体业务最有利的运营模式。
并不是每家公司都能做成垂直整合。一些做得不好的公司，出现了以下问题：
1. （由于很多原因）整体管理架构变得头重脚轻。
2. 某些部门牺牲其他部门的利益，追求自身利益最大化。
3. 内部管理层对内部供应商过度自信。
● 指望内部供应商知道我们需要什么以及何时需要，即使我们没有明确告诉对方。
● 指望内部供应商随叫随到，认为这是他们应该做的。
● 对内部供应商的要求高于对外部供应商的要求。
4. 内部供应商认为，他们的内部客户必须接受他们提供的东西，因为他们别无选择。
● 成为某种东西的唯一提供者，理所应当的问题就出现了。
● 正如内部管理层对待内部供应商缺乏应有的态度，内部供应商也会参与度不高，进而造成质量低下、缺乏时间观念和成本超支。
采取平衡的策略
为了解决业务垂直整合管理中的问题，一些公司选择外部公司作为供应商，为其活动、任务、运营、分析等提供支持，而以前只允许内部参与。在某种意义上，这样倒逼公司要划清业务界限。采用外部供应商时，要清楚地描述需要什么、何时需要等问题。采用外部供应商的费用是明确的。因此，公司也就更加尊重外部供应商的时间安排。这就要求公司自我管理要更加严格。选择外部供应商是行之有效的，但是当有人不顾质量而仅仅唯成本至上时——其危害不言自明。
如何制订供应链计划
我们把供应链计划的制订分为四个阶段。第一个阶段，我们把每个活动或任务拿出来单独考虑，但是要谨记一点：这个活动要做的事情，其他每个活动也必须完成。第二个阶段，是与一般供应商进行合作。第三个阶段，为了提高供应商提供信息的准确性，要考虑供应商的以往表现。最后一个阶段，要形成项目供应链计划，然后监督执行情况。
◎ 一项单独活动
在项目进程规划的章节里，我们讨论了活动的五个特点：有投入，资源消耗，按照标准执行，遵循方法，有产出。这里，我们重点讨论资源消耗的特点。
资源可以是如下：
● 物料、原材料、不可或缺的组件；
● 生产设施；
● 特殊设备；
● 工具；
● 除了人力资源，公司所需、用来执行项目计划任务的其他材料。
牢记计划谬误
人们往往会忽略完成一项任务必备的条件，任务执行中，往往对能获得的条件进行猜测。这就是计划谬误，在第8章中我们讨论过这个问题。解决计划谬误，必须找到任务负责人，询问他们在执行任务时需要哪些东西，前提是你的公司之前完成过此类任务。
◎ 与供应商合作
假如活动的物资来自外部供应商（或外部其他部门），你要让外部供应商（或外部其他部门）把物资的生产和运送当成项目做。同理，你要把项目中的系列任务拿出来，一并委托给其他部门或供应商，最后他们的输出变成了项目任务所需的输入（物资或资源）。本质上，你可以将活动物资的获取过程视为一个小型项目。
明确要求
这里要讲的重点是，外部供应商（如果他们够聪明）会尽可能明确地描述事情。他们会记录为你做的工作，还让你在上面签字。如果对外部供应商的要求发生变化，这时你需要让团队对变更设置限制条件，因为每次发生变更，通常会导致供应商价格的上升、交付延迟等问题。并严格要求变更的范围。若采用外部供应商，他们不接受任何变更，除非经过项目变更控制程序审批。要向他们明确变更的范围，这样的优点是：首先，可以减小范围蔓延的可能性；其次，由于变更经过了变更控制程序的审核，你可以容忍成本增加或项目延期，这样你的项目也不会因为这些问题而遭受处罚。
由此我们可以看出，在采用外部供应商时，第一时间就把项目要求以及相关细节弄清楚至关重要。对于供应商而言，不管是内部的还是外部的，首先向他们明确项目要求永远是最重要的。
◎ 考虑过去的表现
◎ 考虑过去的表现
财务规划师认为过去的表现并不能保证未来的成功。这是对的，因为没有人能够为未来作保证。但是一个人过去的行为确实与未来的行为有很大的联系。处理别人给你的信息时，你可以先搁置起来，看是否存在个人偏见。卡尼曼和特沃斯基将这个过程称为“去偏见”。
人们通常无法意识到自己的偏见。他们会固执地认为给你提供的信息是准确无误的，他们尽了最大努力。当然，你也可以做到更好，发现偏见。
改善信息准确性的方法之一，是根据别人的历史表现，“忽略”（或调整）别人给你的信息。
◎ 制订并监督你的供应链计划
我习惯列出项目计划中不同供应链环节的关键步骤，尽管有时会让工作量加倍。具体如下：
● 何时物料下单？
● 何时开始供应需求工作？
● 哪些提前期是重要的？
● 供应商何时完成自己的工作？
● 计划中何处会产生自由浮动？
第13章 项目执行周密的计划：跟踪、更新、汇报和验收
到此为止，你已经做了很多工作：
● 你正在做的工作，超越了普通人的个人能力。借助工具、流程、团队，你承担了一项个人无法完成的任务。
● 你已经明确了自己以及项目对公司的作用。
● 你已经组建了具有咨询功能的治理团队，帮助你成功完成项目。
● 你已经确定了项目的规模、要求、交付产品以及验收标准，已经制订了保障项目质量的计划，并得到了其他部门的授权和支持。
● 你已经找到了项目不同阶段最适合的生命周期。甚至在不同的阶段，你采用了不同的生命周期。你制订了执行计划，确保各项工作按时完成。
● 你制订了人员配备计划，为各项活动配备了合格的人员。
● 你制订了计划，明确了项目设计、制造或生产的产品最重要的组件和特征。关键特征包括产品的形式、适应、功能、款式（或设计的关键流程）以及设计的基础（项目产品设计的基础）。你已经确定了控制这些配置问题的计划或方法，同时，你还建立了变更流程，设计了变更审查，确保项目提出变更时，可以确定关键特征是否受到影响。
● 你已经将项目的成本责任落实到人。大家提供的成本数据看起来不错，他们都承诺会帮你管好项目，让成本控制在预算之内。
● 你已经确定各种物料和资源的获取方法，并且能够确保按时按需供应。
理想状态下，你已经将所有情况考虑在内，计划很周全，很完美，团队只需照此执行即可。当然，理想与现实总是有差距。
周密的计划
在现实中，事情不可能分毫不差，毫无例外。世间万物皆有变数。实施项目计划时，你需要为项目活动、产品和性能标准设置能够承受的变化区间。即使这样做，仍然存在虽然项目各个部分都在可接受的范围之内（在能够承受的变化区间内），但项目整体效果不在可接受范围内的情况。
可接受的误差总是朝一个方向累积，这种现象叫做偏差。在项目实施过程中，偏差的后果非常严重。每个误差看起来都可以接受，不需要矫正。但是，随着偏差的不断累积，项目整体运行情况可能就像上面的诊所一样，严重滞后于计划，或严重超支，或质量低下。当你觉察到出现这样的问题时，就有必要重新评估项目，或者重新制订项目计划，或者与任务执行者一起调整项目。
项目监督与重新规划
我们面对的问题不仅仅限于自然变数和潜在的偏差。每个项目都会出现无法预知的问题，总有意外会发生。这时就要靠项目经理想办法，让项目回到正轨上来。因此，项目经理必须对照项目计划、预算、质量目标和验收标准检查执行情况，提前解决潜在问题，将问题扼杀在萌芽状态。所以，一定要熟悉相关工具，利用工具做好项目监督和追踪。
在重新做计划时，首先是不要偏离基准线，其次是要清楚必须重新做计划的根本原因是什么。在第14章，我们将探讨项目评估，其中，基准线、重新做规划的根本原因以及实际情况是重点内容。在项目执行过程中，对这三个方面进行评估，有助于项目聚焦既定目标，减少项目范围蔓延。在比较时，一定要参考基准线。这样你才知道事情偏离了多远，你才能决定是否需要采取一定的控制措施。
接下来，就是要让治理团队随时了解项目进展情况、存在的问题以及计划的变更。尽管所有变更都要走变更控制程序，但仍然要让治理团队了解项目的执行情况（我们将在下文详细讨论如何向上级汇报）。
最后，在确定项目需求时，交付的产品和验收标准也就确定了。当项目进展到后期，就必须确保项目可以交付符合验收标准的产品。
两种监督方式
◎ 以人为本
◎ 分析法
项目经理通常还可以使用分析法来跟进任务进展情况。应用分析法，就是计算各项任务消耗的时间，与分配的时间进行对比，然后把任务耗时和进度情况与已经完成的任务进行比较。
这种跟进方法大多可以通过网络工具或云平台的工具自动实现，这些工具可以把汇报时间和团队的投入整合到大的项目计划中。即使没有使用网络工具或云平台工具进行项目计划，通常也可以手动输入这类数据。
让每个人掌握最新动态
我们从任务执行人那里获取信息，跟踪最新动态，同时，我们还要让团队成员随时了解任务的整体进展情况。如果要对计划进行调整，如果能够提前预警，告知团队人员计划调整的原因，那么团队的工作成效更佳。
关于“充分预警”，需要补充的是：要想象项目任务都有个“调整期”。在任务执行前需要准备，在项目结束后也需要调整。人们不会一下子就进入做事的状态。在做事情之前，我们先要认真考虑，先从思想上进入状态。任务完成后，我们也不能立刻从做事的状态里走出来。在开始进行下一个任务前，我们会经历“缓冲再调整”的阶段。有些项目经理在做计划时就已经把“调整期”考虑进去。有些任务开始前要进行特别准备，有个“调整期”就显得尤为重要。有些项目经理不会把“调整期”单独列出来，却只把“调整期”作为公司的惯例。不管设不设“调整期”，如果在过渡阶段推迟任务（在新任务开始后调整更糟），可能达不到预期效果。所以要尽量避免在“过渡期”推迟项目。
另外，要避免计划调整。团队成员看到项目日程后，将会根据项目计划来安排自己的生活，比如假期、其他工作等。而调整计划会无意之中给别人的生活带来意想不到的负面影响。尽管项目经理不是故意为之，但这些负面影响迟早会引火烧身（比如，团队士气低落、心怀不满、不尊重你等）。如果确实有调整计划的必要，要征得攸关方的同意。一定要让团队中的每个人清楚项目的进展情况，以便根据工作需要安排个人事宜。
要牢记，人是工作的主体。他们是为了完成任务，而不是为了向项目经理提交报告。如果应用奈奎斯特定理后，发现你每天得检查一次，而实际上又没有发生什么重要的事情，那么你就做得过了。有些敏捷项目要求每日跟进，不过仅限于敏捷项目而已。不过，在这样的情况下，还是不要盲从。咨询一下团队领导，把检查事宜好好规划一下，既能让大家把工作做好，又能让你清楚计划的执行情况。这就是“以人为本”的方法，因为这种方法基于人和人之间的接触，基于承认人在项目中的作用。
调整计划会产生连锁反应，将影响人员配备、资源分配、供应链等计划，也可能影响预算。调整计划时，其他相关方面也要适时调整。
向上汇报的频率、目的、流程和展示风格
◎ 汇报的频率
向上级汇报的道理与奈奎斯特定理相反。我们要从获取的数据中提取有用的信息（可以称之为信号），然后总结起来，把相关的结论和需求向上级汇报。因此，汇报性会议要少一些，汇报的信息必须很重要。
提前把报告交给治理团队审阅。这样，可以提高会议效率，在会上解决实质性的问题，如汇报有用的信息，寻求实质性的帮助，进行协调等。可以问问治理团队希望多久汇报一次。按照他们的要求汇报，总不会犯错。
◎ 汇报的目的
治理团队通常关注以下几个问题：
● 计划有没有延期？
● 项目支出是不是控制在计划范围内？
● 是否还有其他潜在问题？
在向上级汇报时要回答以上问题，并根据治理团队的要求提供相关内容。问问他们是否需要在汇报中增加其他内容。如果贵组织设有项目管理办公室，他们应该会提供汇报模板。
◎ 汇报的流程
关于如何有效组织会议，有很多指导性资料。你可以选一种，仔细研究，提高组织会议的能力。在向治理团队汇报时，至少要包含以下基本内容：
● 要明确会议目标。若目标不明确，坚决不要开会。
● 提前公布会议议程，里面写明会议目标。把汇报会议当成一个小型项目。会议目标相当于项目的范围或需求，会议议程相当于项目计划。会议的预期目标达到了，那会议就成功了。提前把会议内容发给与会者，可以让与会者提前做好准备。确保相关人员参会。
● 会议期间，要维持会议流程和秩序。根据参会者人数，合理控制会议的时间。
● 把会议的决定、任务、责任人等内容记录下来。会议结束后立即报送各位参会者，请他们修改确认。如果会议记录有错误，需要立即更正。公开发布的会议纪要不仅可以指导以后的活动，还可以给项目相关人员提供实践指导。
◎ 展示风格
汇报应该是商务风格，必须高效。这就要求汇报一开始就要阐明自己的分析结果和观点，并立刻说明自己的需求。在会议开始前，最好把汇报内容发给参会者审阅。如果所有参会者提前都同意你的请求，就没有必要进行过多讨论，那么会议可能几分钟就结束了。会议提前结束，没人会不高兴！
项目验收
项目收尾是整个项目中最难的部分。在项目快结束时，所有工作成果必须验收通过，这样项目才能真正结束。
项目范围文档要精准、清晰、可测量、客观，这样的文档将成为我们的得力助手。如果在项目开始前就把文档写好，让团队所有的工作都围绕验收标准展开，那对于顺利验收，我们胸有成竹。我们只需要客观呈现验收结果和数据，说明项目已经达到验收条件即可。在验收报告上签字应该是走走形式而已。
各个公司都有独特的项目验收规范、手续和惯例。与治理团队加强合作，共同安排好项目结项会议、验收汇报会，组织好产品交付等相关活动。根据实际情况，以合适的方式结束项目。
第14章 项目评估、总结吸取经验教训、改进未来项目
像航空公司一样检查项目
现代航空业保障飞行安全的其中四点可以直接用于改进项目：检查清单，团队合作，注重系统和流程改进（而不是惩罚雇员），在问题发生前就发现并解决问题。
我认为，这四点——检查清单，团队合作，系统和流程改进（而不是惩罚雇员），在问题发生前解决问题——具有开创性的意义，能让个人超越自我，吸取先辈和同辈的智慧。
项目评估适合放在哪个阶段
项目评估大多数放在项目结束时，不过项目评估需要的信息大多在项目实施过程中就收集齐了。此外，还可能需要趁着熟悉，对项目的某个部分、某项活动或某个任务验收审查。
◎ 项目评估需要多长时间
这就涉及一个更大的话题——“组织裕度”。一个组织应该空出多少时间（好像是没有效率的时间）来促进创新，加强学习呢？对此大家可能给出不同的答案。但是可以肯定的是，我们需要在项目结束时预留一点时间，用于项目收尾、相应文档撰写以及结果文件归档，以方便日后查找、使用。请求在项目结束后进行评估，就要与组织对组织裕度的理解挂钩，因为尽管我上面讲了那么多，并非所有组织都觉得项目评估有用。
至于首次评估的时长，我喜欢预留项目周期的5%（四舍五入）。例如，项目周期为50周，5%即2.5周，四舍五入就是3周，在项目结束时预留3周时间进行项目后评估。首次评估之后可能会引起其他“连锁反应”。但一定要搞清楚，首次评估的目的是找到问题，而不需要解决问题。根据评估结果，可能还需要单独处理、解决问题，并进行收尾。发现的问题有难有易，所以有些问题能快速得到解决，而有些问题就需要花大力气，这就是将分析问题和解决问题分开的原因。
◎ 常见的评估目标
我们可以这样陈述：
● 哪个环节出了问题？为什么？
● 哪些方法取得了良好的效果，并可以用于其他项目？
● 找出在时间、成本、供应商的要求、分组等方面，实际情况和计划是否存在显著差异。存在差异的原因是什么？哪些合作方很可靠，实现了预期目标？
● 还可以采取哪些办法处理问题？
● 如何修改现有的表单、清单、模板、标准、工具或流程，以备未来之需？
● 组织调整会有用吗？组织的建议有所帮助吗？
项目管理办公室有专门的清单和指南，但是如果没有，我们可以根据项目经验，参考以上内容制定所需的评估流程。
项目经理往往已经掌握了评估所需的大部分数据。不过，项目各环节都离不开团队的共同努力。项目经理的观点可能与其他人的观点截然不同。所以，要安排时间，听取团队成员，尤其是进展不太顺利的项目负责人的意见和建议。
偶然成功的项目经理与必然成功的项目经理
对于新上任的项目经理而言，如果一个项目取得圆满成功，那恐怕再糟糕不过了。请听我解释。我们当然都希望项目成功，但是如果过于圆满，我们可能并不清楚项目为什么会成功。接下来，你将被委以更大的项目，项目越做越大，最终接到超级项目。最终，不可避免的问题还是发生了。因为你没有通过解决一个个小问题锻炼出处理问题的能力，所以此时你根本不具备处理重大问题的能力。
相反，对于新上任的项目经理而言，最好是历经各种困难的磨炼，比如小事故，轻微的冒犯，让人为难的监督，让人会心一笑的混乱（虽然混乱看起来更糟糕），以及其他不顺利等种种考验。在处理这些问题的过程中，可以提高你处理问题的能力，你会变得更有远见，而且还会使用并优化各种清单（表格、模板等）、方法、工具，这些东西对于未来承担项目具有重要价值。