项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包含在项目内。

9.1管理基础272

9.1.1产品范围和项目范围272

在项目环境中，“范围”这一术语有两种含义:

产品范围:指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

项目范围:包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。

9.1.2管理新实践272

需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益。随着全球项目环境变得日益复杂，项目范围管理的新趋势和新兴实践更加注重与商业分析师一起合作，以便:确定问题并识别商业需要;识别并推荐能够满足需要的可行解决方案;收集、记录并管理干系人需求满足商业和项目目标;推动项目集或项目产品、服务或最终成果成功应用。

如果项目已配备商业分析师，该角色的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责，项目成功的可能性会更大。

9.2项目范围管理过程272

9.2.1过程概述272

项目范围管理过程包括:

规划范围管理:为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划。

收集需求:为了实现项目目标，确定、记录并管理干系人的需要和需求。

定义范围:制定项目和产品详细描述。

创建WBS:将项目可交付成果和项目工作分解为较小的、更易于管理的组件。

确认范围:正式验收已完成的项目可交付成果。

控制范围:监督项目和产品的范围状态，管理范围基准的变更。

在项目实际进展中，以上各过程会相互交叠和相互作用。表9-1概括了项目范围管理的各个过程。

表9-1项目 范围管理过程过程输入工具与技术输出规划范围管理● 项目章程 ● 项目管理计划 ● 事业环境因素 ● 组织过程资产● 专家判断 ● 数据分析 ● 会议● 范围管理计划 ● 需求管理计划收集需求● 立项管理文件 ● 项目章程 ● 项目管理计划 ● 项目文件 ● 协议 ● 事业环境因素 ● 组织过程资产● 专家判断 ● 数据收集 ● 数据分析 ● 决策 ● 数据表现 ● 人际关系与团队技能 ● 系统交互图 ● 原型法● 需求文件 ● 需求跟踪矩阵定义范围● 项目章程 ● 项目管理计划 ● 项目文件 ● 事业环境因素 ● 组织过程资产● 专家判断 ● 数据分析 ● 决策 ● 人际关系与团队技能 ● 产品分析● 项目范围说明书 ● 项目文件(更新)创建WBS● 项目管理计划 ● 项目文件 ● 事业环境因素 ● 组织过程资产● 专家判断 ● 分解● 范围基准 ● 项目文件(更新)确认范围● 项目管理计划 ● 项目文件 ● 工作绩效数据 ● 核实的可交付成果● 检查 ● 决策● 验收的可交付成果 ● 变更请求 ● 工作绩效信息 ● 项目文件(更新)控制范围● 项目管理计划 ● 项目文件 ● 工作绩效数据 ● 组织过程资产数据分析● 工作绩效信息 ● 变更请求 ● 项目管理计划(更新) ● 项目文件(更新)

9.2.2裁剪考虑因素274

因为每个项目都是独特的，所以项目经理可能根据需要裁剪项目范围管理过程。裁剪时应考虑的因素包括:

知识和需求管理:项目经理应建立哪些指南?为了在未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系?

确认和控制:组织是否有正式或非正式的与确认和控制相关政策、程序和指南?

开发方法:组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?

需求的稳定性:项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确?

治理:组织是否拥有正式或非正式的审计和治理政策、程序和指南?

9.2.3敏捷与适应方法274

对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义。

采用敏捷或适应型生命周期，旨在应对大量变更，需要干系人持续参与项目。因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完成项)，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。在一个迭代开始时，团队将努力确定产品未完成项中，哪些优先级高的未完成项需要在下一次迭代中交付。在每次迭代中，都会重复开展三个过程:

①收集需求;

②定义范围;

③创建WBS。

在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，并对迭代交付的可交付成果提供反馈意见，确保产品未完成项真实地反映了他们的当前需求。在每次迭代中，都会重复开展两个过程:①确认范围;②控制范围。

在预测型项目中，经过批准的项目范围说明书、工作分解结构(WBS)和相应的WBS词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完成项(包括产品需求和用户故事)反映当前需求。

确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的干系人正式签字批准。因此，干系人需要在规划阶段早期介入(有时需要在启动阶段就介入)，对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。

9.3规划范围管理275

规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。规划范围管理过程的数据流向如图9-1所示。

范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制订范围管理计划和细化项目范围始于对下列信息的分析:项目章程中的信息、项目管理计划中已批准的子计划、组织过程资产中的历史信息和相关事业环境因素。

9.3.1输入275

项目章程

项目章程记录项目目的、项目概述、假设条件、制约因素，以及项目想要实现的高层级的需求。

项目管理计划

规划范围管理中使用的项目管理计划组件主要包括:

质量管理计划:在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。

项目生命周期描述:定义了项目从开始到完成所经历的一系列阶段。

开发方法:开发方法定义了项目是采用预测型、适应型还是混合型开发方法。

事业环境因素

能够影响规划范围管理过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度和市场条件等。

组织过程资产

能够影响规划范围管理过程的组织过程资产主要包括:政策和程序、历史信息和经验教训知识库等。

9.3.2工具与技术276

专家判断

规划范围管理过程中，应征求具备如下领域相关专业知识或接受过相关培训的个人或小组的意见，涉及的领域包括:

以往类似项目;

特定行业、学科和应用领域的信息等。

数据分析

适用于本过程的数据分析技术是备选方案分析。备选方案分析技术用于评估、收集需求，详述项目和产品范围，创造产品，确认范围和控制范围的各种方法。

会议

项目团队可参加项目会议来制订范围管理计划。参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员。

9.3.3输出276

范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划用于指导如下过程和相关工作:

①制定项目范围说明书;

②根据详细项目范围说明书创建WBS;

③确定如何审批和维护范围基准;

④正式验收已完成的项目可交付成果。

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

需求管理计划

需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。

需求管理计划的主要内容包括:

①如何规划、跟踪和报告各种需求活动;

②配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限;

③需求优先级排序过程;

④测量指标及使用这些指标的理由;

⑤反映哪些需求属性将被列入跟踪矩阵等。

9.4收集需求276

收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程。本过程的主要作用是为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。收集需求过程的数据流向如图9-2所示。

让干系人积极参与需求的探索和分解工作(分解成项目和产品需求)，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目执行开始后对其进行测量。需求将作为后续工作分解结构(WBS)的基础，也将作为成本、进度、质量和采购规划的基础。

9.4.1输入277

立项管理文件

会影响收集需求过程的立项管理文件是商业论证产生的文件，它描述了为满足业务需要而应该达到的必要、期望及可选标准。

项目章程

项目章程记录了项目概述以及将用于制定详细需求的高层级需求。

项目管理计划

收集需求中使用的项目管理计划组件包括:

范围管理计划:包含如何定义和制定项目范围的信息。

需求管理计划:包含如何收集、分析和记录项目需求的信息。

干系人参与计划:从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。

项目文件

可作为收集需求过程输入的项目文件主要包括:

假设日志:识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件。

干系人登记册:用于了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望。

经验教训登记册: 提供了有效的需求收集技术，尤其针对使用敏捷或适应型产品开发方法的项目。

协议

协议会包含项目和产品需求。

事业环境因素

会影响收集需求过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度、市场条件等。

组织过程资产

会影响收集需求过程的组织过程资产主要包括:政策和程序;包含以往项目信息的历史信息和经验教训知识库等。

9.4.2工具与技术278

专家判断

收集需求过程中，应征求具备如下领域相关专业知识或接受过相关培训的个人或小组的意见，涉及的领域包括:

可行性研究与评估;

需求获取;

需求分析;

需求文件;

以往类似项目的项目需求;

图解技术;

引导;

冲突管理等。

数据收集

可用于收集需求过程的数据收集技术主要包括:

头脑风暴:是一种用来产生和收集对项目需求与产品需求的多种创意的技术。

访谈:是通过与干系人直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可包括多个访谈者或多个被访者。访谈有经验项目参与者、发起人和其他高管及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。

焦点小组:是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。

问卷调查:是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。

标杆对照:将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。

数据分析

可用于收集需求过程的数据分析技术是文件分析。文件分析指审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求，可供分析并有助于获取需求的文件包括:

协议;

商业计划;

业务流程或接口文档;

业务规则库;

现行流程;

市场文献;

问题日志;

政策和程序、法规文件，如法律、准则、法令等;

建议邀请书;

用例等。

决策

适用于收集需求过程的决策技术主要包括:

投票:是一种为达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过程。本技术用于生成、归类和排序产品需求。

独裁型决策制定:采用这种方法，将由一个人负责为整个集体制定决策。

多标准决策分析:该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。

数据表现

可用于收集需求过程的数据表现技术主要包括:

亲和图:用来对大量创意进行分组的技术，以便进一步审查和分析。

思维导图:把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。

人际关系与团队技能

可用于收集需求过程的人际关系与团队技能主要包括:

名义小组技术:是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式，由四个步骤组成:

①向集体提出一个问题或难题，每个人在沉思后写出自己的想法;

②主持人在活动挂图上记录所有人的想法;

③集体讨论各个想法，直到全体成员达成一个明确的共识;

④个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。

观察和交谈:是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作细节。观察也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

引导:引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成-致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。

系统交互图

系统交互图是对产品范围的可视化描绘，可以直观显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式。

原型法

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

9.4.3输出280

需求文件

需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。前者是干系人的需要，后者是指如何实现这些干系人需要的方案。把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求的类别一般包括:

(1)业务需求:整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。

(2)干系人需求:干系人的需要。

(3)解决方案需求:为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求:

①功能需求:描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互;

②非功能需求:是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。

(4)过渡和就绪需求:如数据转换和培训需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力。

(5)项目需求:项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。

(6)质量需求:用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等。

需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。跟踪需求的内容包括:

①业务需要、机会、目的和目标;

②项目目标;

③项目范围和WBS可交付成果;

④产品设计;

⑤产品开发;

⑥测试策略和测试场景;

⑦高层级需求到详细需求等。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。需求跟踪矩阵示例如图9-3所示。

9.5定义范围282

定义范围是制定项目和产品详细描述的过程。本过程的主要作用是描述产品、服务或成果的边界和验收标准。本过程需要在整个项目期间多次反复开展。定义范围过程的数据流向如图9-4所示。

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

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息了解的逐渐深入，应该更加详细、具体地定义和描述项目范围。此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。

9.5.1输入282

项目章程

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

项目管理计划

定义范围中使用的项目管理计划组件是范围管理计划，其中记录了如何定义、确认和控制项目范围。

项目文件

可作为定义范围过程输入的项目文件主要包括:

假设日志:识别了有关产品、项目、环境、干系人以及会影响项目和产品范围的假设条件和制约因素。

需求文件:识别了应纳入范围的需求。

风险登记册:包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。

事业环境因素

会影响定义范围过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度、市场条件等。

组织过程资产

能够影响定义范围过程的组织过程资产主要包括:用于制定项目范围说明书的政策、程序和模板;以往项目的项目档案;以往阶段或项目的经验教训等。

9.5.2工具与技术283

专家判断

定义范围过程中，应征求具备类似项目的知识或经验的个人或小组的意见。

数据分析

可用于定义范围过程的数据分析技术是备选方案分析。备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。

决策

可用于定义范围过程的决策技术是多标准决策分析。多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。

人际关系与团队技能

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

产品分析

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

每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术主要包括:产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。

9.5.3输出283

项目范围说明书

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

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

产品范围描述:逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。

可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。

验收标准:可交付成果通过验收前必须满足的一系列条件。

项目的除外责任:识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。

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

项目文件(更新)

可在定义范围过程更新的项目文件包括:

假设日志:随同本过程识别出更多的假设条件或制约因素，从而更新假设日志。

需求文件:可以通过增加或修改需求而更新需求文件。

需求跟踪矩阵:应该随同需求文件的更新而更新需求跟踪矩阵。

干系人登记册:如果在定义范围过程中收集到了现有或新干系人的更多信息，则记录到干系人登记册中。