项⽬范围管理

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

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

需求⼀直是项⽬管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收⽅，以便⻓期测量、监控、实现并维持收益。

商业分析师，该⻆⾊的职责还应包括需求管理相关的活动，项⽬经理则负责确保这些活动列⼊项⽬管理计划，并且在预算内按时完成，同时能够创造价值。

项⽬经理与商业分析师之间应该是伙伴式合作关系。

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

收集需求：为了实现项⽬⽬标，确定、记录并管理⼲系⼈的需要和需求。

定义范围：制定项⽬和产品详细描述。

创建WBS：将项⽬可交付成果和项⽬⼯作分解为较⼩的、更易于管理的组件。

确认范围：正式验收⼰完成的项⽬可交付成果。

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

裁剪时应考虑的因素包括：

知识和需求管理、确认和控制：开发⽅法：需求的稳定性：治理：

对于需求不断变化、⻛险⼤或不确定性⾼的项⽬，在项⽬开始时通常⽆法明确项⽬的范围， ⽽需要在项⽬期间逐渐明确。

敏捷或适应型⽅法在项⽬早期缩短定义和协商范围的时间， 为后续细化范围、明确范围争取更多的时间。

敏捷⽅法有⽬的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项⽬期间被定义和再定义。

采⽤敏捷或适应型⽣命周期，旨在应对⼤量变更，需要⼲系⼈持续参与项⽬。

在预测型项⽬中，经过批准的项⽬范围说明书、⼯作分解结构（WBS）和相应的 WBS 词典构成项⽬范围基准。只有通过正式变更控制程序，才能进⾏基准变更。在开展确认范围、控制范围及其他控制过程时，基准被⽤作⽐较的基础。⽽采⽤适应型⽣命周期的项⽬，则使⽤末完成项（包括产品需求和⽤户故事）反映当前需求。

规划范围管理是为了记录如何定义、确认和控制项⽬范围及产品范围，⽽创建范围管理计 划的过程。本过程的主要作⽤是在整个项⽬期间对如何管理范围提供指南和⽅向。本过程仅开展⼀次或仅在项⽬的预定义点开展。

范围管理计划是项⽬或项⽬集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项⽬范围

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

项⽬⽣命周期描述：定义了项⽬从开始到完成所经历的⼀系列阶段。

开发⽅法：开发⽅法定义了项⽬是采⽤预测型、适应型还是混合型开发⽅法。

备选⽅案分析。⽤于评估、收集需求，详述项⽬和产品范围，创造产品，确认范围和控制范围的各种⽅法。

范围管理计划是项⽬管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项⽬范围。

范围管理计划⽤于指导如下过程和相关⼯作：

①制定项⽬范围说明书；

②根据详细项⽬范围说明书创建 WBS；

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

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

范围管理计划可以是正式或⾮正式的，⾮常详细或⾼度概括的。

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

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

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

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

③需求优先级排序过程；

④测量指标及使⽤这些指标的理由；

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

收集需求是为实现⽬标⽽确定，记录并管理⼲系⼈的需要和需求的过程。本过程的主要作⽤是为定义产品范围和项⽬范围奠定基础。仅开展⼀次或仅在项⽬的预定义点开展

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

⽴项管理⽂件是商业论证产⽣的⽂件，描述了为满⾜业务需要⽽ 应该达到的必要、期望及可选标准。

项⽬章程⾼层级需求。

范围管理计划：需求管理计划：⼲系⼈参与计划：

假设⽇志：⼲系⼈登记册：经验教训登记册：

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

头脑⻛暴：是⼀种⽤来产⽣和收集对项⽬需求与产品需求的多种创意的技术。

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

焦点⼩组：是召集预定的⼲系⼈和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由⼀位受过训练的主持⼈引导⼤家进⾏互动式讨论。焦点⼩组往往⽐“⼀对⼀”的访谈更热烈。

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

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

⽂件分析指审核和评估任何相关的⽂件信息。在此过程中，⽂件分析⽤于通过分析现有⽂件，识别与需求相关的信息来获取需求

决策技术主要包括：

投票：是⼀种为达成某种期望结果，⽽对未来多个⾏动⽅案进⾏评估的决策技术和过程。本技术⽤于⽣成、归类和排序产品需求。

独裁型决策制定：采⽤这种⽅法，将由⼀个⼈负责为整个集体制定决策。

多标准决策分析：该技术借助决策矩阵，⽤系统分析⽅法建⽴诸如⻛险⽔平、不确定性和价值收益等多种标准，以对众多创意进⾏评估和排序。

亲和图：⽤来对⼤量创意进⾏分组的技术，以便进⼀步审查和分析。

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

名义⼩组技术：是⽤于促进头脑⻛暴的⼀种技术，通过投票排列最有⽤的创意，以便进⼀步开展头脑⻛暴或优先排序

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

引导：引导与主题研讨会结合使⽤，把主要⼲系⼈召集在⼀起定义产品需求。研讨会可⽤于快速定义跨职能需求并协调⼲系⼈的需求差异。群体互动。有助于参与者之间建⽴信任、改进关系、改善沟通，从⽽有利于⼲系⼈达成一致意⻅。

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

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。

故事板是⼀种原型技术，通过⼀系列的图像或图⽰来展⽰顺序或导航路径。故事板⽤于各种⾏业的各种项⽬中，如电影、⼴告、教学设计以及敏捷和其他软件开发项⽬。在软件开发中， 故事板使⽤实体模型来展⽰⽹页、屏幕或其他⽤户界⾯的导航路径。

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

需求的类别⼀般包括：

（1）业务需求：整个组织的⾼层级需要，例如，解决业务问题或抓住业务机会，以及实施项⽬的原因。

（2）⼲系⼈需求：⼲系⼈的需要。

(3）解决⽅案需求：为满⾜业务需求和⼲系⼈需求，产品、服务或成果必须具备的特性、 功能和特征。

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

②⾮功能需求：是对功能需求的 补充，是产品正常运⾏所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务⽔平、可⽀持性、保留或清除等

（4）过渡和就绪需求：如数据转换和培训需求。从“当前状态”过渡到 “将来状态”所需的临时能⼒。

(5）项⽬需求：项⽬需要满⾜的⾏动、过程或其他条件，⾥程碑⽇期、合同责任、制

约因素等。

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

需求跟踪矩阵是把产品需求从其来源连接到能满⾜需求的可交付成果的⼀种表格。把每个需求与业务⽬标或项⽬⽬标联系起来，有助于确保每个需求都具有业务价值。提供了在整个项⽬⽣命周期中跟踪需求的⼀种⽅法，有助于确保需求⽂件中 被批准的每项需求在项⽬结束的时候都能实现并交付。

跟踪需求的内容包括：

①业务需要、机会、⽬的和⽬标；

②项⽬⽬标；

③项⽬范围和 WBS 可交付成果；

④产品设计；

⑤产品开发；

⑥测试策略和测试场景；

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

需求踪矩阵中记录的典型属性包括唯⼀标识、需求的⽂字描述、收录该需求的理由、所有者、 来源、优先级别、版本、当前状态和状态⽇期。稳定性、复杂性和验收标准

定义范围是制定项⽬和产品详细描述的过程。本过程的主要作⽤是描述产品、服务或成果的边界和验收标准。在整个项⽬期间多次反复开展

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

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

范围管理计划

假设⽇志：

需求⽂件：识别了应纳⼊范围的需求。

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

备选⽅案分析。可⽤于评估实现项⽬章程中所述的需求和⽬标的各种⽅法。

多标准决策分析是⼀种借助决策矩阵来使⽤系统分析⽅法的技术，⽬的是建⽴诸如需求、进度、预算和资源等多种标准来完善项⽬和产品范围。

引导技能协调具有不同期望或不同专业知识的关键⼲系⼈，使他们就项⽬可交付成果以及项⽬和产品边界达成跨职能的共识。

产品分析可⽤于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的⽤途、特征及其他⽅⾯。⽤以把⾼层级的产品或服务描述转变为有意义的可交付成果。⾸先获取⾼层级的需求，然后将其细化到最终产品设计所需的详细程度。 

产品分析技术主要包括：产品分解、需求分析、系统分析、系统⼯程、价值分析、价值⼯程等

项⽬范围说明书是对项⽬范围、主要可交付成果、假设条件和制约因素的描述。项⽬和产品范围；代表项⽬⼲系⼈之间就项⽬范围所达成的共识。为便于管理⼲系⼈的期望，可明确指出哪些⼯作不属于本项⽬范围。

详细的项⽬范围说明书包括内容有

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

可交付成果：必须产出的任何独特并可核实的产品、成果或服务能⼒，可交付成果也包括各种辅助成果，如项⽬管理报告和⽂件

验收标准：可交付成果通过验收前必须满⾜的⼀系列条件。

项⽬的除外责任：明确说明哪些内容不属于项⽬范围，有助于管理⼲系⼈的期望及减少范围蔓延。

假设⽇志：需求⽂件：需求跟踪矩阵：⼲系⼈登记册：

创建⼯作分解结构（WBS）是把项⽬可交付成果和项⽬⼯作分解成较⼩、更易于管理的组件的过程。本过程的主要作⽤是为所要交付的内容提供架构。它仅开展⼀次或仅在项⽬的预定义点开展。

WBS 是对项⽬团队为实现项⽬⽬标，创建所需可交付成果⽽需要实施的全部⼯作范围的层级分解。WBS 组织并定义了项⽬的总范围，代表着经批准的当前项⽬范围说明书中所规定的⼯作。 WBS 最低层的组成部分称为⼯作包，其中包括计划的⼯作。⼯作包对相关活动进⾏归类，以便对⼯作安排进度，进⾏估算，开展监督与控制。在“⼯作分解结构”这个词语中，“⼯作”是指作为活动结果的⼯作产品或可交付成果，⽽不是活动本⾝。

范围管理计划。

需求⽂件：项⽬范围说明书：

分解是⼀种把项⽬范围和项⽬可交付成果逐步划分为更⼩、更便于管理的组成部分的技术。 ⼯作包是 WBS 最低层的⼯作，可对其成本和持续时间进⾏估算和管理。

创建 WBS 的⽅法多种多样，⾃上⽽下的⽅法、使⽤组织特定的指南和使⽤ WBS 模板。

要把整个项⽬⼯作分解为⼯作包，通常需要开展如下活动：

①识别和分析可交付成果及相 关⼯作；

②确定 WBS 的结构和编排⽅法；

③⾃上⽽下逐层细化分解；

④为 WBS 组成部分制定和分配标识编码；

⑤核实可交付成果分解的程度是否恰当。

WBS 的结构可以采⽤多种形式：

项⽬⽣命周期的各阶段分解的第⼆层，把产品和项⽬可交付成果放在第三层

主要可交付成果作为分解的第⼆层

纳⼊由项⽬团队以外的组织开发的各种较低层次组件（如外包⼯作）。随后，作为外包⼯作的⼀部分，卖⽅须制定相应的合同WBS。

对 WBS 较⾼层组件进⾏分解，把每个可交付成果或组件分解为最基本的组成部分， 即可核实的产品、服务或成果。如果采⽤敏捷或适应型⽅法，可以将⻓篇故事分解成⽤户故事。WBS 可以采⽤提纲式、组织结构图或能说明层级结构。

不同的可交付成果可以分解到不同的层次。⼯作分解得越细致，对⼯作的规划、管理和控制就越有⼒。但是，过细的分解会造成管理努⼒的⽆效耗费、资源使⽤效率低下、⼯作实施效率降低，同时造成 WBS 各层级的数据汇总困难

滚动式规划：在未来远期才完成的可交付成果或组件，当前可能⽆法分解。项⽬管理团队因⽽通常需要等待对该可交付成果或组成部分达成⼀致意见，才能够制定出 WBS 中的相应细节。

在分解的过程中，应该注意以下8个⽅⾯。

WBS必须是⾯向可交付成果的：项⽬的⽬标是提供产品或服务，WBS中的各项⼯作是为提供可交付的成果服务的。

WBS必须符合项⽬的范围：WBS必须包括也仅包括为了完成项⽬的可交付成果的活 动。100%原则（包含原则）认为，在WBS中，所有下⼀级的元素之和必须100%代表上⼀级的元素。

WBS的底层应该⽀持计划和控制：WBS是项⽬管理计划和项⽬范围之间的桥梁，WBS 的底层不但要⽀持项⽬管理计划，⽽且要让管理层能够监视和控制项⽬的进度和预算。 WBS中的元素必须有⼈负责，⽽且只有⼀个⼈负责；WBS和责任⼈可以使⽤⼯作责任矩阵来描述

WBS应控制在4~6层：如果项⽬规模⽐较⼤，以⾄于WBS要超过6层，此时，可以使⽤项⽬分解结构将⼤项⽬分解成⼦项⽬，然后针对⼦项⽬来做WBS。（每个级别的WBS将上⼀级的⼀个元素分为4~7个新元素，同⼀级元素的⼤⼩应该相似。⼀个⼯作单元只能从属于某个上层单元，避免交叉从属。

WBS应包括项⽬管理⼯作（因为管理是项⽬具体⼯作的⼀部分），也要包括分包出去的⼯作。

WBS的编制需要所有（主要）项⽬⼲系⼈的参与

WBS并⾮是⼀成不变的：在完成了WBS之后的⼯作中，仍然有可能需要对WBS进⾏修改。

范围基准是经过批准的范围说明书、WBS 和相应的WBS 词典，只有通过正式的变更控制程序才能进⾏变更，它被⽤作⽐较的基础。范围基准是项⽬管理计划的组成部分。

1)项⽬范围说明书

项⽬范围、主要可交付成果、假设条件和制约因素的描述。

2) WBS

3）⼯作包

WBS 的最低层是带有独特标识号的⼯作包。账户编码。每个⼯作包都是控制账户的⼀部分，⽽控制账户则是⼀个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相⽐较来测量绩效。控制账户包含两个或更多⼯作包，每个⼯作包只与⼀个控制账户关联。

4）规划包

规划包是⼀种低于控制账户⽽⾼于⼯作包的⼯作分解结构组件，⼯作内容已知，但详细的进度活动未知，⼀个控制账户可以包含⼀个或多个规划包。

5）WBS 字典

WBS字典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的⽂件。 WBS 字典对 WBS 提供⽀持

WBS字典中的内容⼀般包括：账户编码标识、⼯作描述、假设条件和制约因素、负责的组织、 进度⾥程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考⽂献、协议信息等。

假设⽇志：需求⽂件：

确认范围是正式验收已完成的项⽬可交付成果的过程。

本过程的主要作⽤：

①使验收过程具有客观性；

②通过确认每个可交付成果来提⾼最终产品、服务或成果获得验收的可能性

根据需要在整个项⽬期间定期开展

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

确认范围应该贯穿项⽬的始终。

确认范围的⼀般步骤包括：

①确定需要进⾏范围确认的时间；

②识别范围确认需要哪些投⼊；

③确定范围正式被接受的标准和要素；

④确定范围确认会议的组织步骤；

⑤组织范围确认会议。

在确认范围前，项⽬团队需要先进⾏质量控制⼯作，以确保确认⼯作的顺利完成。

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

项⽬⼲系⼈进⾏范围确认时，⼀般需要检查以下6个⽅⾯的问题：

可交付成果是否是确定的、可确认的。

每个可交付成果是否有明确的⾥程碑，⾥程碑是否有明确的、可辦别的事件，例如，客户的书⾯认可等。

是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，⽽且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。

审核和承诺是否有清晰的表达：项⽬发起⼈必须正式同意项⽬的边界，项⽬完成的产品或者服务，以及项⽬相关的可交付成果。项⽬团队必须清楚地了解可交付成果是什么。 所有的这些表达必须清晰，并取得⼀致的同意。

项⽬范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。

项⽬范围的风险是否太⾼：管理层是否能够降低风险发⽣时对项⽬的影响。

每个⼈对项⽬范围所关注的⽅⾯是不同的：

管理层项⽬范围：是指范围对项⽬的进度、资⾦和资源的影响，这些因素是否超过了组织承受范围，是否在投⼊产出上具有合理性。

客户产品范围：关⼼项⽬的可交付成果是否⾜够完成产品或服务。在项⽬中，客户往往有在当前版本中加⼊所有功能和特征的意愿，这对于项⽬来说是⼀种潜在的风险，会给组织和客户带来危害和损失。

项⽬管理⼈员项⽬制约因素：项⽬可交付成果是否⾜够和必须完成，时间、资⾦和资源是否⾜够，主要的潜在风险和预备解决的⽅法。

项⽬团队成员项⽬范围中⾃⼰参与的元素和负责的元素：通过定义范围中的时 间检查⾃⼰的⼯作时间是否⾜够，⾃⼰在项⽬范围中是否有多项⼯作，⽽这些⼯作是否有冲突的地⽅。

范围管理计划：需求管理计划：范围基准：

需求⽂件：需求跟踪矩阵：质量报告：经验教训登记册：

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

检查是指开展测量、审查与确认等活动，来判断⼯作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。

投票，当由项⽬团队和其他⼲系⼈进⾏验收时，使⽤投票来形成结论。

符合验收标准的可交付成果应该由客户或发起⼈正式签字批准。应该从客户或发起⼈那⾥获得正式⽂件，证明⼲系⼈对项⽬可交付成果的正式验收

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

需求⽂件：需求跟踪矩阵：经验教训登记册：

控制范围是监督项⽬和产品的范围状态，管理范围基准变更的过程。

本过程的主要作⽤是在整个项⽬期间保持对范围基准的维护。在整个项⽬期间开展

控制项⽬范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进⾏处理。在变更实际发⽣时，也需要采⽤控制范围过程来管理这些变更。控制范围过程应该与其他项⽬管理知识领域的控制过程协调开展。未经控制的产品或项⽬范围的扩⼤（未对时间、成本和资源做相应调整）被称为范围蔓延。

范围管理计划：需求管理计划：变更管理计划：配置管理计划：范围基准：绩效测量基准：

需求⽂件：需求跟踪矩阵：经验教训登记册：

偏差分析：⽤于将基准与实际结果进⾏⽐较，以确定偏差是否处于临界值区间内或是否 有必要采取纠正或预防措施。

趋势分析：旨在审查项⽬绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项⽬范围控制的重要⼯作。

范围管理计划：范围基准：进度基准：成本基准：绩效测量基准：

需求⽂件：需求跟踪矩阵：经验教训登记册：