PMBOK® 第六版 确认范围

目录

读后感—PMBOK第六版 目录

---

项目中按阶段持续交付可以增强对项目的把控，因为有相关方的验收环节，可以及时发现相关方不满意的问题，这些问题可能是未能达标的需求指标，也可能是相关方的一些新需求。这些问题可以在每个小阶段及时发现并处理。而且分段验收还能拉近与相关方的关系，使他们更愿意分享隐性信息或提供更多支持，有助于项目的顺利推进。

项目中最容易出现争议的一个环节是验收。如果一个项目直到整体结束时才一次性验收，发现的问题可能是致命的。甲方可能会认为项目不达标，而乙方则认为自己已经实现了需求，重新实现的成本将是巨大的。

虽然理论上项目有明确的范围，但在实际生活中，很多需求是难以量化和明确约定的。而且我们所做的不仅仅是一个任务，而是一个产品。有一句话很值得赞同：“成功才是成功之母”，失败的经验或许并没有太多作用，接近成功的失败或许还有一些价值。

一、确认范围的内容

确认范围是获得项目发起人或客户对项目可交付成果正式验收的过程（见图1）。通过项目过程中发起人或客户持续性地验收每个可交付成果，可以保障最终产品、服务或成果获得验收。

本过程将依据项目范围说明书中包含的产品范围说明书和产品验收原则，以及 WBS 词典中提供的项目可交付成果范围，对项目可交付成果的完成情况进行检查，判定工作与可交付成果是否符合要求，并得到由客户签字确认的正式证明文件。

图-1 确认范围：数据流向图

在项目的每个阶段结束前，我们都应该先对可交付成果进行质量控制检查（见图2）。如果质量不满足标准，就要通过变更来获得时间和资源去纠正，直到质量合格。下一步是与客户确认满足客户的要求，这就是确认范围，如果不满足也可以通过变更进行修正，直到客户接受为止。

图-2 确认范围与控制质量

需要注意以下两点：

• 需要对控制质量的过程和确认范围的过程加以区别，前者关注可交付成果是否满足既定的质量要求，而后者关注可交付成果是否满足客户接受的条件。控制质量的过程通常先于确认范围的过程，但二者也可同时进行;
• 确认范围的过程是在项目每个阶段结束时都需要及时执行，而不应该累积到项目结束后。

项目收尾中的 “项目最终验收” 主要指的不是对具体的交付成果进行确认，而是甲乙双方在项目结束时的交接仪式。对具体交付成果的确认属于项目过程中的确认范围。确认范围应该化整为零，分期分批地尽早完成。

二、确认范围

确认范围过程确保项目成果得到正式验收，其输入包括项目管理计划、项目文件、可交付成果、工作绩效数据。该过程使用检查、群体决策技术等工具与技术，输出为验收的可交付成果、变更请求、工作绩效信息和项目文件更新，从而确保可交付成果满足项目要求并得到客户或发起人的确认。

图-3 确认范围：输入、工具与技术和输出

2.1 确认范围：输入

1. 项目管理计划

项目管理计划组件包括（但不限于）：

• 范围管理计划：计划定义了如何正式验收已经完成的可交付成果；
• 需求管理计划：计划描述了如何确认项目需求；
• 范围基准：用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

2. 项目文件

可作为本过程输入的项目文件包括（但不限于）：

• 经验教训登记册：在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果；
• 质量报告：质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容；
• 需求文件：将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施；
• 需求跟踪矩阵：含有与需求相关的信息，包括如何确认需求。

3. 核实的可交付成果

指已经完成，并被控制质量过程检查为正确的可交付成果。

4. 工作绩效数据

可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。

2.2 确认范围：工具与技术

1. 检查

指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。

2. 决策

可用于本过程的决策技术包括（但不限于）投票。当由项目团队和其他相关方进行验收时，使用投票来形成结论。

2.3 确认范围：输出

1. 验收的可交付成果

符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。

2. 工作绩效信息

工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给相关方。

3. 变更请求

对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。

4. 项目文件更新

可在本过程更新的项目文件包括（但不限于）：

经验教训登记册：更新记录所遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法。

需求文件：记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。

需求跟踪矩阵：根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。