9.7 确认范围

文集：《信息系统项目管理师第四版攻略》

---

本节概要

确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用：

1. 使验收过程具有客观性；
2. 通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。

确认范围过程应根据需要在整个项目期间定期开展。

确认范围过程的数据流向图

由主要干系人，尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。确认范围过程依据从项目范围管理知识领域的相应过程获得的输出(如需求文件或范围基准)，以及从其他知识领域的执行过程获得的工作绩效数据，对可交付成果的确认和最终验收。

确认范围的步骤

确认范围应该贯穿项目的始终。如果是在项目的各个阶段对项目的范围进行确认工作，则还要考虑如何通过项目协调来降低项目范围改变的频率，以保证项目范围的改变是有效率和适时的。确认范围的一般步骤包括：

1. 确定需要进行范围确认的时间；
2. 识别范围确认需要哪些投入；
3. 确定范围正式被接受的标准和要素；
4. 确定范围确认会议的组织步骤；
5. 组织范围确认会议。

确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。

需要检查的问题

项目干系人进行范围确认时，一般需要检查以下 6 个方面的问题：

1. 可交付成果是否是确定的、可确认的。
2. 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
3. 是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。
4. 审核和承诺是否有清晰的表达：项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。
5. 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
6. 项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响。

干系人关注点的不同

确认范围主要是项目干系人（例如，客户、发起人等）对项目的范围进行确认和接受的工作，每个人对项目范围所关注的方面是不同的：

• 管理层主要关注项目范围：是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。在确认范围工作进行之后，管理层可能会取消该项目，可能是因为项目范围太大，造成对时间、资金和资源的占有远远大于管理层的预计或者组织的承受能力。
• 客户主要关注产品范围：关心项目的可交付成果是否足够完成产品或服务。
• 项目管理人员主要关注项目制约因素：关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
• 项目团队成员主要关注项目范围中自己参与的元素和负责的元素：通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作是否有冲突的地方。

输入

项目管理计划

确认范围中使用的项目管理计划组件主要包括：

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

项目文件

可作为确认范围过程输入的项目文件主要包括：

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

工作绩效数据

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

核实的可交付成果

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

工具与技术

1. 检查
   检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
2. 决策
   可用于确认范围过程的决策技术是投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论。

输出

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

2. 变更请求
   对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展相应的缺陷补救工作。变更请求应该由实施整体变更控制过程进行审查与处理。

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

4. 项目文件（更新）
   可在确认范围过程更新的项目文件主要包括：

   • 需求文件：记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
   • 需求跟踪矩阵：根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
   • 经验教训登记册：更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战的方法，以及良好的可交付成果验收的方法。

---