《PMBOK指南第六版》第5章 项目范围管理 ——> 5.3 定义范围

第5章 项目范围管理 ——> 5.3 定义范围

　　定义范围 是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。

　　由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以 定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要。

　　应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

5.3.1、定义范围：输入

5.3.1.1、项目章程

见 4.1.3.1 节。项目章程中包含对项目的高层级描述、产品特征和审批要求。

5.3.1.2、项目管理计划

见 4.2.3.1 节。项目管理计划组件包括（但不限于）范围管理计划（见 5.1.3.1 节），其中记录了如何定义、确认和控制项目范围。

5.3.1.3 项目文件

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

假设日志。

通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。 假设日志识别了有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。

需求文件。

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。 需求文件识别了应纳入范围的需求。

风险登记册。

风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、规划风险应对、实施风险应对和监督风险等过程的开展，这些过程的结果也要记进风险登记册。取决于具体的项目变量（如规模和复杂性），风险登记册可能包含有限或广泛的风险信息。 风险登记册包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。 　　 当完成识别风险过程时，风险登记册的内容可能包括（但不限于）：

• 已识别风险的清单。 在风险登记册中，每项单个项目风险都被赋予一个独特的标识号。要以所需的详细程度对已识别风险进行描述，确保明确理解。可以使用结构化的风险描述，来把风险本身与风险原因及风险影响区分开来。

• 潜在风险责任人。 如果已在识别风险过程中识别出潜在的风险责任人，就要把该责任人记录到风险登记册中。随后将由实施定性风险分析过程进行确认。

• 潜在风险应对措施清单。 如果已在识别风险过程中识别出某种潜在的风险应对措施，就要把它记录到风险登记册中。随后将由规划风险应对过程进行确认。

5.3.1.4 事业环境因素

会影响定义范围过程的事业环境因素包括（但不限于）：

• 组织文化；
• 基础设施；
• 人事管理制度；
• 市场条件。

5.3.1.5 组织过程资产

能够影响定义范围过程的组织过程资产包括（但不限于）：

• 用于制定项目范围说明书的政策、程序和模板；
• 以往项目的项目档案；
• 以往阶段或项目的经验教训。

5.3.2、定义范围：工具与技术

5.3.2.1 专家判断

见 4.1.2.1 节。应征求具备类似项目的知识或经验的个人或小组的意见。

5.3.2.2 数据分析

可用于本过程的数据分析技术包括（但不限于）备选方案分析。备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。

5.3.2.3 决策

　　见 5.1.2.2 节。可用于本过程的决策技术包括（但不限于）多标准决策分析。如 8.1.2.4 节所述，多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。

5.3.2.4 人际关系与团队技能

　　见 4.1.2.3 节。人际关系与团队技能的一个示例是引导。在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。

5.3.2.5 产品分析

　　产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。

　　每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术包括（但不限于）：

• • 产品分解；
  • 需求分析；
  • 系统分析；
  • 系统工程；
  • 价值分析；
  • 价值工程。

5.3.3、定义范围：输出

5.3.3.1、项目范围说明书

　　项目范围说明书 是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变更请求或额外工作是否超过项目边界提供基准。

　　项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：

• • 产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
  • 可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
  • 验收标准。可交付成果通过验收前必须满足的一系列条件。
  • 项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。

　　虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。表5-1 显示了这两个文件的一些关键内容。

5.3.3.2、项目文件更新

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

• 假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
• 需求文件。见 5.2.3.1 节。可以通过增加或修改需求而更新需求文件。
• 需求跟踪矩阵。见 5.2.3.2 节。应该随同需求文件的更新而更新需求跟踪矩阵。
• 相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。
  相关方登记册是识别相关方过程的主要输出。它记录关于已识别相关方的信息，包括（但不限于）：
• • • • 身份信息。姓名、组织职位、地点、联系方式，以及在项目中扮演的角色。
      • 评估信息。主要需求、期望、影响项目成果的潜力，以及相关方最能影响或冲击的项目生命周期阶段。
      • 相关方分类。用内部或外部，作用、影响、权力或利益，上级、下级、外围或横向，或者项目经理选择的其他分类模型，进行分类的结果。