优化或报错有奖项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包含在项目内。
一、管理基础
1、产品范围和项目范围
在项目环境中，“范围”这一术语有两种含义:
产品范围:指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
项目范围:包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。
2、管理新实践
需求管理是项目管理中的重要环节，其目的在于将产品、服务或成果交付给接收方，并确保长期效益。随着全球项目环境的复杂化，项目范围管理趋向于与商业分析师合作。这种合作包括确定问题和商业需求、推荐可行解决方案、管理干系人需求以实现商业和项目目标。项目经理需确保商业分析师的活动纳入项目管理计划，并按预算和时间表完成，从而创造价值。项目经理与商业分析师之间应建立伙伴关系，相互理解彼此在项目目标实现中的角色和职责，以提高项目成功的可能性。
二、项目范围管理过程
1、过程概述
项目范围管理过程包括:
●规划范围管理:为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划。
●收集需求:为了实现项目目标，确定、记录并管理干系人的需要和需求。
●定义范围:制定项目和产品详细描述。
●创建WBS:将项目可交付成果和项目工作分解为较小的、更易于管理的组件。
●确认范围:正式验收已完成的项目可交付成果。
●控制范围:监督项目和产品的范围状态，管理范围基准的变更。
在项目实际进展中，以上各过程会相互交叠和相互作用。表9-1概括了项目范围管理的各个过程。
2、裁剪考虑因素
因为每个项目都是独特的，所以项目经理可能根据需要裁剪项目范围管理过程。裁剪时应考虑的因素包括:
知识和需求管理:项目经理应建立哪些指南?为了在未来项目中重复使用需求，组织是
否拥有正式或非正式的知识和需求管理体系?确认和控制:组织是否有正式或非正式的与确认和控制相关政策、程序和指南?开发方法:组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?需求的稳定性:项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确?治理:组织是否拥有正式或非正式的审计和治理政策、程序和指南?
3、敏捷与适应方法
对于需求变化频繁、风险高、不确定性大的项目，往往无法在项目开始时明确范围，需要逐步明确。敏捷或适应型方法在项目初期缩短定义和协商范围时间，以便后续有更多时间细化范围。经常出现的新需求通常会导致真实业务需求与最初需求有差异。因此，敏捷方法通过构建和审查原型，并通过多次发布版本来明确需求，整个项目期间会不断定义和重新定义范围。
采用敏捷或适应型生命周期的项目面临大量变更，需要持续干系人参与。因此，项目范围会分解为一系列待实现的需求和待执行的工作，并通过多次迭代来开发可交付成果，在每次迭代开始时明确范围。在每次迭代中，团队确定下一次迭代中需要交付的优先级较高的未完成项。
在敏捷或适应型生命周期中，发起人和客户代表持续参与项目，提供反馈，确保产品未完成项反映当前需求。每次迭代都会重复收集需求、定义范围、创建WBS，并进行确认范围和控制范围。
预测型项目使用项目范围说明书、工作分解结构和WBS词典构成项目范围基准，通过正式变更控制程序进行基准变更。在适应型项目中，使用未完成项反映当前需求。确认范围是正式验收已完成的项目可交付成果的过程，需要干系人早期介入，提出质量意见，以便控制质量过程评估绩效并提出变更建议。
三、规划范围管理
规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。规划范围管理过程的数据流向如图9-1所示。
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制订范围管理计划和细化项目范围始于对下列信息的分析:项目章程中的信息、项目管理计划中已批准的子计划、组织过程资产中的历史信息和相关事业环境因素。
1、输入
1）项目章程
项目章程记录项目目的、项目概述、假设条件、制约因素，以及项目想要实现的高层级的需求。
2）项目管理计划
规划范围管理中使用的项目管理计划组件主要包括:
质量管理计划:在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
●项目生命周期描述:定义了项目从开始到完成所经历的一系列阶段。
●开发方法:开发方法定义了项目是采用预测型、适应型还是混合型开发方法。
3）事业环境因素
能够影响规划范围管理过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度和市场条件等。
4）组织过程资产
能够影响规划范围管理过程的组织过程资产主要包括:政策和程序、历史信息和经验教训知识库等。
2、工具与技术
1）专家判断
规划范围管理过程中，应征求具备如下领域相关专业知识或接受过相关培训的个人或小组的意见，涉及的领域包括:以往类似项目;特定行业、学科和应用领域的信息等。
2）数据分析
适用于本过程的数据分析技术是备选方案分析。备选方案分析技术用于评估、收集需求详述项目和产品范围，创造产品，确认范围和控制范围的各种方法。
3）会议
项目团队可参加项目会议来制订范围管理计划。参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员。
3、输出
1）范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划用于指导如下过程和相关工作:①制定项目范围说明书;②根据详细项目范围说明书创建 WBS:③确定如何审批和维护范围基准;④正式验收已完成的项目可交付成果。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
2）需求管理计划
需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。
需求管理计划的主要内容包括:①如何规划、跟踪和报告各种需求活动;②配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限;③需求优先级排序过程;④测量指标及使用这些指标的理由;⑤反映哪些需求属性将被列入跟踪矩阵等。
四、收集需求
收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程。本过程的主要作用是为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。收集需求过程的数据流向如图 9-2所示。
让干系人积极参与需求的探索和分解工作(分解成项目和产品需求)，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目执行开始后对其进行测量。需求将作为后续工作分解结构(WBS)的基础，也将作为成本、进度、质量和采购规划的基础。
1、输入
1）立项管理文件
会影响收集需求过程的立项管理文件是商业论证产生的文件，它描述了为满足业务需要而应该达到的必要、期望及可选标准。
2）项目章程
项目章程记录了项目概述以及将用于制定详细需求的高层级需求
3）项目管理计划
收集需求中使用的项目管理计划组件包括:
●范围管理计划:包含如何定义和制定项目范围的信息。
●需求管理计划:包含如何收集、分析和记录项目需求的信息。
●干系人参与计划:从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。
4）项目文件
可作为收集需求过程输入的项目文件主要包括:
●假设日志:识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件。
●干系人登记册:用于了解哪些干系人能够提供需求方面的信息，及记录于系人对项目的需求和期望。
●经验教训登记册:提供了有效的需求收集技术，尤其针对使用敏捷或适应型产品开发方法的项目。
5）协议
协议会包含项目和产品需求。
6）事业环境因素
会影响收集需求过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度、市场条件等。
7）组织过程资产
会影响收集需求过程的组织过程资产主要包括:政策和程序;包含以往项目信息的历史信息和经验教训知识库等。
2、工具与技术
1）专家判断
在收集需求过程中，应该征求具备以下领域相关专业知识或接受过相关培训的个人或小组的意见，包括：可行性研究与评估、需求获取、需求分析、需求文件、以往类似项目的项目需求、图解技术、引导、冲突管理等。
2）数据收集
可用于收集需求的数据收集技术主要包括：
- 头脑风暴：用于产生和收集项目需求与产品需求的多种创意。
- 访谈：通过直接与相关人员交谈获取信息的方法，可以是正式或非正式的。访谈通常是一对一的谈话，也可以是多对多的。有经验的项目参与者、发起人和其他专家的访谈有助于识别和定义所需产品可交付成果的特征和功能。访谈也可以用于获取机密信息。
- 焦点小组：召集预定的干系人和专家，了解他们对所讨论的产品、服务或成果的期望和态度，由受过训练的主持人引导互动式讨论。
- 问卷调查：设计一系列书面问题，向多个受访者快速收集信息。问卷调查适用于受众多样化、需要快速完成调查、受访者地理位置分散的情况。
- 标杆对照：将实际或计划的产品、过程和实践与其他可比组织的实践进行比较，以便识别最佳实践并形成改进意见。
3）数据分析
用于收集需求的数据分析技术是文件分析。文件分析用于通过审核和评估现有文件来获取需求，可供分析并有助于获取需求的文件包括：协议、商业计划、业务流程或接口文档、业务规则库、市场文献、问题日志、政策和程序、法规文件、建议邀请书、用例等。
4）决策
适用于收集需求的决策技术主要包括：
- 投票：对未来多个行动方案进行评估的决策技术，用于生成、归类和排序产品需求。
- 独裁型决策制定：由一个人负责为整个集体制定决策。
- 多标准决策分析：借助决策矩阵，用系统分析方法建立多种标准，以对众多创意进行评估和排序，如风险水平、不确定性和价值收益等。
5）数据表现
用于收集需求的数据表现技术主要包括：
- 亲和图：对大量创意进行分组的技术，以便进一步审查和分析。
- 思维导图：将从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。
6）人际关系与团队技能
用于收集需求的人际关系与团队技能主要包括：
- 名义小组技术：用于促进头脑风暴的技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
- 观察和交谈：直接察看个人在各自的环境中如何执行工作和实施流程，以了解隐藏的需求。
- 引导：与主题研讨会结合使用，通过研讨会快速定义跨职能需求并协调干系人的需求差异。
7）系统交互图
系统交互图是对产品范围的可视化描绘，可以直观显示业务系统及其与人和其他系统之间的交互方式。
8）原型法
原型法是指在制造预期产品之前先造出该产品的模型，并据此征求早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟，支持渐进明细的理念。
3、输出
1）需求文件
需求文件描述了如何满足项目相关的业务需求。它最初可能只包含高层级的需求，然后随着需求信息的增加逐步细化。只有明确、可跟踪、完整且得到主要干系人认可的需求才能作为基准。需求文件的格式多种多样，可以是简单的按照干系人和优先级分类列出全部需求的文件，也可以是包含内容提要、细节描述和附件等的详细文件。需求通常分为不同的种类，包括：
业务需求：整个组织的高层级需求，包括解决业务问题、抓住业务机会和实施项目的原因。
干系人需求：干系人的具体需求。
解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须具备的特性和功能。解决方案需求分为功能需求和非功能需求。
过渡和就绪需求：描述从“当前状态”过渡到“将来状态”所需的临时能力。
项目需求：项目需要满足的行动、过程或其他条件。
质量需求：确认项目可交付成果的成功完成或其他项目需求的实现的条件或标准。
2）需求跟踪矩阵
需求跟踪矩阵将产品需求与可交付成果连接起来，有助于确保每个需求都具有业务价值。它提供了跟踪需求的方法，并为管理产品范围变更提供了框架。需求跟踪矩阵记录了每个需求的相关属性，如唯一标识、文字描述、所有者来源、优先级别、版本、当前状态和状态日期等。示例如图所示。
五、定义范围
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是描述产品、服务或成果的边界和验收标准。本过程需要在整个项目期间多次反复开展。定义范围过程的数据流向如图9-4所示。
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程需要从需求文件(收集需求过程的输出)中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细项目范围说明书，对项目成功至关重要。 应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息了解的逐渐深入，应该更加详细、具体地定义和描述项目范围。此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。
1、输入
1）项目章程
项目章程中包含对项目的高层级描述、产品特征和审批要求。
2）项目管理计划
定义范围中使用的项目管理计划组件是范围管理计划，其中记录了如何定义、确认和控制项目范围。
3）项目文件
可作为定义范围过程输入的项目文件主要包括:
假设日志:识别了有关产品、项目、环境、干系人以及会影响项目和产品范围的假设条件和制约因素。
需求文件:识别了应纳入范围的需求。
风险登记册:包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。
4）事业环境因素
会影响定义范围过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度、市场条件等。
5）组织过程资产
能够影响定义范围过程的组织过程资产主要包括:用于制定项目范围说明书的政策、程序和模板;以往项目的项目档案:以往阶段或项目的经验教训等。
2、工具与技术
1）专家判断
定义范围过程中，应征求具备类似项目的知识或经验的个人或小组的意见。
2）数据分析
可用于定义范围过程的数据分析技术是备选方案分析。备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。
3）决策
可用于定义范围过程的决策技术是多标准决策分析。多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。
4）人际关系与团队技能
人际关系与团队技能的一个典型示例是引导。在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键干系人，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。
5）产品分析
产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。
每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度产品分析技术主要包括:产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。
3、输出
1）项目范围说明书
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括:项目和产品范围:详细描述了项目的可交付成果;代表项目与相关人员之间就项目范围所达成的共识。为便于管理相关人员的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。项目范围说明书帮助项目团队进行更详细的规划，在执行过程中指导项目团队工作，并为评价变更请求或额外工作是否超过项目边界提供基准。
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括内容有(直接列出或参引其他文件):
产品范围描述:逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特且可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
验收标准:可交付成果通过验收前必须满足的一系列条件。
项目的除外责任:识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关人员的期望及减少范围蔓延。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。
2）项目文件(更新 )
可在定义范围过程更新的项目文件包括:
假设日志:随同本过程识别出更多的假设条件或制约因素，从而更新假设日志。
需求文件:可以通过增加或修改需求而更新需求文件。
需求跟踪矩阵:应随需求文件的更新而更新需求跟踪矩阵。
干系人登记册:如果在定义范围过程中收集到了现有或新的相关方信息，则应记录到干系人登记册中。
六、创建WBS
创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是为所要交付的内容提供架构。它仅开展一次或仅在项目的预定义点开展。创建 WBS 过程的数据流向如图9-5所示。
WBS 是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类以便对工作安排进度，进行估算，开展监督与控制。在“工作分解结构”这个词语中，“工作是指作为活动结果的工作产品或可交付成果，而不是活动本身。
1、输入
1）项目管理计划
创建 WBS中使用的项目管理计划组件是范围管理计划。范围管理计划定义了如何根据项目范围说明书创建 WBS。
2）项目文件
可作为创建 WBS 过程输入的项目文件主要包括:
需求文件:详细描述了各种单一需求如何满足项目的业务需要。
项目范围说明书:描述了需要实施的工作以及不包含在项目中的工作
3）事业环境因素
会影响创建 WBS 过程的事业环境因素包括项目所在行业的 WBS 标准，这些标准可以作为创建 WBS的外部参考资料。
4）组织过程资产
能够影响创建 WBS过程的组织过程资产主要包括:用于创建 WBS的政策、程序和模板:以往项目的项目档案;以往项目的经验教训等。
2、工具与技术
1）专家判断
创建 WBS 过程中，应征求具备类似项目知识或经验的个人或小组的意见。
2）分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度，以实现对项目的高效管理。工作包的详细程度则因项目规模和复杂程度而异。创建 WBS 的方法多种多样，常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS模板。自下而上的方法可用于归并较低层次的组件。
（1)分解活动
要把整个项目工作分解为工作包，通常需要开展如下活动:识别和分析可交付成果及相关工作;②确定 WBS 的结构和编排方法;③自上而下逐层细化分解;④为 WBS 组成部分制定和分配标识编码;⑤核实可交付成果分解的程度是否恰当。
如图 9-6所示，某工作分解结构的一部分，若干分支已经向下分解到工作包层次。
（2）WBS 结构
WBS 的结构可以采用多种形式:
以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层，如图9-7所示。
以主要可交付成果作为分解的第二层，如图9-8所示。
纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后，作为外包工作的一部分，卖方须制定相应的合同WBS。
对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分即可核实的产品、服务或成果。如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事
WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。确认 WBS较低层组件是完成上层相应可交付成果的必要且充分的工作，以此来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层，即可到达工作包的层次，而另一些则须分解更多层。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS中的相应细节。这种技术又称为滚动式规划。
（3）注意事项
在分解过程中，需要注意以下8个方面：
*面向可交付成果：WBS必须以项目的可交付成果为导向，项目的目标是提供产品或服务，WBS中的工作应为提供这些可交付成果服务。有些工作可能需要多次循环，例如软件测试，为了达到里程碑，可能需要多次测试。
*符合项目范围：WBS必须包括为完成项目可交付成果所必需的活动，符合100%原则，即每个下一级元素之和必须完全代表上一级元素。否则，最终的产品或服务可能无法令用户满意。
*底层支持计划和控制：WBS是项目管理计划和项目范围之间的桥梁，底层必须支持项目管理计划，以便管理层监视和控制项目的进度和预算。
*每个WBS元素必须有责任人负责，且仅有一个责任人。WBS和责任人可以通过工作责任矩阵来描述。
*层级控制：WBS的层级应控制在4~6层，若超过6层，则可考虑将大项目分解为子项目。每个层级的元素应分为4~7个新元素，大小相似，避免交叉从属。
*包括项目管理工作：WBS应包括项目管理工作和分包出去的工作，因为管理也是项目的一部分。
*干系人参与：WBS的编制需要所有主要项目干系人的参与，不同干系人可能会有不同的观点，项目经理应组织讨论，制定出大家都能接受的WBS。
*可变性：WBS并非一成不变，完成后仍可能需要修改。如果没有合理的范围控制，仅依靠WBS可能导致后续工作的僵化。
3、输出
1）范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更。它被用作比较的基础，是项目管理计划的组成部分。
*项目范围说明书：包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
*WBS：对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
*工作包：WBS的最低层，带有独特标识号，为成本、进度和资源信息的逐层汇总提供了层级结构。每个工作包是控制账户的一部分，控制账户是管理控制点，在该点上进行范围、预算和进度的整合，并与挣值相比较来测量绩效。每个工作包只与一个控制账户关联。
*规划包：低于控制账户但高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。一个控制账户可以包含一个或多个规划包。
*WBS字典：针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS字典对WBS提供支持，内容包括账户编码标识、工作描述、假设条件和制约因素、负责的组织进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献协议信息等。
2.）项目文件（更新）：在创建WBS过程中更新的项目文件主要包括：
*假设日志：随着创建WBS过程识别出更多假设条件或制约因素而更新。
*需求文件：可以更新需求文件，以反映在创建WBS过程中提出并已被批准的变更。
七、确认范围
确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用：使验收过程具有客观性；通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。确认范围过程应根据需要在整个项目期间定期开展。确认范围过程的数据流向如图9-9所示。
由主要干系人，尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。确认范围过程依据从项目范围管理知识领域的相应过程获得的输出(如需求文件或范围基准)，以及从其他知识领域的执行过程获得的工作绩效数据，对可交付成果的确认和最终验收。
确认范围是项目中至关重要的一环，贯穿项目始终。其步骤主要包括确定确认时间、识别确认投入、确定接受标准和要素、组织确认会议等。通常在确认范围之前，需要进行质量控制工作，例如系统测试，以确保可交付成果的质量满足要求。确认范围的目的是确保可交付成果得到有效验收，与质量控制过程不同，后者更关注可交付成果的质量和正确性。
在范围确认时，项目干系人需要关注六个主要问题：可交付成果的确定性和可确认性、里程碑的明确性、质量标准的清晰性、审核和承诺的表达清晰性、项目范围的全面性和准确性以及项目风险的控制。
各个干系人对项目范围的关注点不同。管理层主要关注项目范围对进度、资金和资源的影响，以确保不超过组织的承受范围。客户则更关注产品范围，确保可交付成果能够满足产品或服务的需求。项目管理人员关注项目制约因素，包括可交付成果的完成情况、时间、资金和资源的充足性以及潜在风险的解决方案。项目团队成员则更关注自身参与的项目范围，确保自己的工作时间和工作内容符合项目要求，如有必要，提出自己的意见和建议。
1、输入
1）项目管理计划
确认范围中使用的项目管理计划组件主要包括:
·范围管理计划:定义了如何正式验收已经完成的可交付成果。
需求管理计划:描述了如何确认项目需求。
范围基准:用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
2）项目文件
可作为确认范围过程输入的项目文件主要包括:
●需求文件:将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。
●需求跟踪矩阵:含有与需求相关的信息，包括如何确认需求。质量报告:该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。经验教训登记册:在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
3）工作绩效数据
工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
4）核实的可交付成果
核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
2、工具与技术
1）检查
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
2）决策
可用于确认范围过程的决策技术是投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论。
3、输出
1）验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
2）变更请求
对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展相应的缺陷补救工作。变更请求应该由实施整体变更控制过程进行审查与处理。
3）工作绩效信息
工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给干系人。
4）项目文件(更新)
可在确认范围过程更新的项目文件主要包括:
●需求文件:记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
●需求跟踪矩阵:根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
●经验教训登记册:更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战的方法，以及良好的可交付成果验收的方法。
八、控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是在整个项目期间保持对范围基准的维护。本过程需要在整个项目期间开展。控制范围过程的数据流向如图 9-10 所示。
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也需要采用控制范围过程来管理这些变更。控制范围过程应该与其他项目管理知识领域的控制过程协调开展。未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。
1、输入
1）项目管理计划
控制范围中使用的项目管理计划组件主要包括:
●范围管理计划:记录了如何控制项目和产品范围。
●需求管理计划:记录了如何管理项目需求。
●变更管理计划:定义了管理项目变更的过程。
配置管理计划:定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
范围基准:用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
绩效测量基准:使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要
进行变更、采取纠正措施或预防措施。
2）项目文件
可作为控制范围过程输入的项目文件主要包括:
需求文件:用于发现任何对商定的项目或产品范围的偏离。需求跟踪矩阵:有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
经验教训登记册:项目早期的经验教训可以运用到后期阶段，以改进范围控制。
3）工作绩效数据
工作绩效数据可能包括收到的变更请求的数量，接受的变更请求的数量或者核实、确认和完成的可交付成果的数量。
4）组织过程资产
能够影响控制范围过程的组织过程资产主要包括:现有的、正式的和非正式的与范围控制相关的政策、程序和指南;可用的监督和报告的方法与模板等。
2、工具与技术
数据分析
可用于控制范围过程的数据分析技术主要包括:
●偏差分析:用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
●趋势分析:旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在
恶化。
确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
3、输出
1）工作绩效信息
控制范围过程产生的工作绩效信息是有关项目和产品范围实施情况(对照范围基准)的相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。
2）变更请求
分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程的审查和处理
3）项目管理计划(更新)
项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理可能需要变更请求的项目管理计划组成部分包括:
●范围管理计划:更新范围管理计划，以反映范围管理方式的变更。
●范围基准:在针对范围、范围说明书、WBS或WBS词典的变更获得批准后，需要对范围基准做出相应的变更。有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供现实可行的依据。
●进度基准:在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效测量提供现实可行的依据。
●成本基准:在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
●绩效测量基准:在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。
4.项目文件(更新)
可在控制范围过程更新的项目文件主要包括:
●需求文件:可以通过增加或修改需求而更新需求文件。
●需求跟踪矩阵:应该随同需求文件的更新而更新需求跟踪矩阵。
●经验教训登记册:更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。
转载本站内容时，请务必注明来自W3xue，违者必究。