七、确认范围
1. 关于确认范围
- 确认范围是正式验收已完成的项目可交付成果的过程。
- 确认范围使验收过程具有客观性，同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
- 确认范围需要根据需要在整个项目期间定期开展。
- 参与人员 -> 所做工作 - > 确认时机
1.1 确认范围的参与人员
- 项目范围的主要参与者是客户和发起人，由项目经理协助：
- 项目经理与客户或发起人一起审查可交付成果；
- 确保可交付成果已圆满完成；
- 获得客户或发起人对可交付成果的正式验收。
1.2 确认范围的时机
- 应贯穿于整个项目生命周期中，建议越早越好。
- 最晚要在项目快结束或每个阶段末进行。
- 假如把所有可交付成果的验收都放在收尾阶段去做，则一旦出现问题时，不能正常收尾的风险极大。
1.3 确认范围所做的工作
- 由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收，依据如下：
- 项目范围管理知识领域的个规划过程获得的输出（如需求文件或范围基准）。
- 从其它知识领域的各执行过程获得工作绩效数据。
2. ITTO
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 1. 项目管理计划 - 范围管理计划 - 需求管理计划 - 范围基准 2. 项目文件 - 经验教训登记册 - 质量报告 - 需求文件 - 需求跟踪矩阵 3. 核实的可交付成果 4. 工作绩效数据 |
1. 检查 2. 决策 - 投票 |
1. 验收的可交付成果 2. 工作绩效信息 3. 变更请求 4. 项目文件更新 - 经验教训登记册 - 需求文件 - 需求跟踪矩阵 |
3. 输入
3.1 项目管理计划
- 范围管理计划：范围管理计划定义了如何正式验收已经完成的可交付成果。
- 需求管理计划：需求管理计划描述了如何确认项目需求。
- 范围基准：用范围基准与实际结果比较，以决定是否有必要执行变更，采取纠正措施或预防措施。
3.2 项目文件
- 经验教训登记册：在项目早期获得的经验教训可以运营到后期阶段，以提高验收的效率与效果。
- 质量报告：质量报告的内容可以包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。
- 需求文件：将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。
- 需求跟踪矩阵：需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。
3.3 核实的可交付成果
- 核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
3.4 工作绩效数据
- 工作绩效数据可能包括符合需求的程度，不一致的数量，不一致得严重性或在某时间段内开展确认的次数。
4. 工具与技术
4.1 检查
- 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
- 通常由客户发起。
4.2 决策
- 当项目团队和其他相关方进行验收时，使用投票来形成结论。
5. 输出
5.1 验收的可交付成果
- 符合验收标准的可交付成果应该由客户或发起人正式签字批准。
- 应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收，这些文件将提交给结束项目或阶段过程。
- 如果项目验收通过：将通过验收的可交付成果正式记录在文件中，并作为依据，继续进入项目或阶段收尾过程。
- 如果项目验收未通过：记录并附上未通过的理由，然后继续进行整体变更控制过程处理。
5.2 工作绩效信息
- 工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给相关方。
5.3 变更请求
- 对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。
- 可能需要针对这些可交付成果提出变更请求，开展缺陷补救、变更请求应该由试试整体变更控制过程进行审查和处理。
5.4 项目文件更新
- 经验教训登记册：更新经验教训登记册，以记录所遇到的挑战，本应如何避免该挑战，以及良好的可交付成果验收方法。
- 需求文件：记录实际验收结果，更新需求文件。
- 需求跟踪矩阵：根据验收结果更新需求跟踪矩阵。
网友评论