PMBOK® 第六版控制范围

读后感—PMBOK第六版目录

结果固然重要，过程同样不可或缺。过程不仅是通往预期成果的途径，也是个人和团队能力提升与经验积累的关键阶段。过程中的每一步都是学习和成长的机会，每一次尝试都能激发创新，而公正透明的流程更增强了结果的可信度。

在项目中，很多时候是因为对过程的疏忽，导致项目难以进行时才收到反馈，这时候就会面临各种问题，比如团队成员少做了工作、按照自己的想法编写了功能、未经变更流程就接受了客户需求等。这些问题不仅增加了项目风险，也可能导致资源浪费和进度延误。

一、控制范围的内容

控制范围是监督项目和产品的范围状态，并管理范围基准变更的过程，其主要作用是在整个项目期间维护范围基准（见图1），需要在整个项目期间持续开展。

确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程处理。在变更实际发生时，也要采用控制范围过程来管理这些变更，并与其他控制过程协调开展。由于变更不可避免，因此每个项目都必须强制实施某种形式的变更控制。

图-1 控制范围：数据流向图

1.1 范围蔓延

范围蔓延（Scope Creeping）是一个项目管理中常见的挑战，它指的是项目或产品的范围在未经正式控制和相应资源调整的情况下逐渐扩大。这种扩大可能源于多种因素，但主要分为两类：狭义的范围蔓延（也称为“范围爬行”）和由项目团队主动引起的“镀金”。

狭义的范围蔓延特指在客户的要求下，项目范围发生了扩大，但这种扩大并未遵循正常的范围变更控制程序。这通常发生在客户不断提出新的需求或修改现有需求，而项目团队未能有效管理这些变更，导致项目范围逐渐失控。范围爬行往往让项目团队陷入被动，因为每一次小的变更都可能累积成大的问题，最终影响项目的进度、成本和质量。

相比之下，“镀金”则是由项目团队主动发起的范围扩大。它表现为团队在定义的工作范围之外，出于好意或追求完美的心理，主动增加了额外的工作。这些工作可能包括应用新技术、新方法或新标准，以期望交付超出客户期望的成果。然而，如果没有经过正式的范围控制程序，这种“镀金”行为同样会导致范围蔓延，因为额外的工作会消耗时间、成本和资源，进而影响项目的整体计划。

镀金和范围爬行的共同之处在于，它们都没有经过整体变更控制程序就导致了项目范围的变化。为了有效管理范围蔓延，项目团队需要建立明确的范围变更控制流程，确保所有变更都经过评估、批准和相应的资源调整。同时，团队还需要与客户保持密切的沟通，确保双方对项目范围有清晰的认识和共识。

1.2 确认范围和控制范围的区别

确认范围关注的是单个或一组可交付成果的验收情况，而控制范围则更侧重于整个项目范围的管理和控制，确保项目范围在整个项目生命周期中保持一致，并管理范围变更（见表1）。

区别点	确认范围	控制范围
定义	对项目可交付成果进行正式验收的过程，以确保其满足既定的验收标准和干系人的期望。	确保项目范围在整个项目生命周期中保持一致，管理并控制项目范围的变更。
目标	验证项目可交付成果是否符合项目范围说明书和干系人的要求，并获得干系人的正式验收。	维护项目范围基准，管理范围变更，确保所有变更都按照既定的变更管理流程进行处理。
关注点	单个或一组可交付成果的验收情况。	整个项目范围的变化和稳定性。
执行时机	通常在项目执行阶段，当可交付成果完成时进行。	贯穿整个项目生命周期，特别是项目执行阶段。
实施主体	客户或发起人	项目经理
关键活动	提交可交付成果给干系人进行审查；收集干系人的反馈；根据反馈进行必要的调整；获得干系人的正式验收。	监控项目范围的变化；评估变更请求；与干系人沟通变更的影响；批准或拒绝变更请求；调整项目计划以反映批准的变更。
主要输出	验收的可交付成果、工作绩效信息、更新后的项目文件（如经验教训登记册、需求文件、需求跟踪矩阵等）。	变更请求、工作绩效信息、更新后的项目文件（如项目管理计划、范围基准等）。

表-1 确认范围和控制范围的区别

二、控制范围

控制范围过程中，输入包括项目管理计划、项目文件、工作绩效数据。工具与技术有数据分析。输出有工作绩效信息、变更请求、项目管理计划更新、项目文件更新（见图2）。

图-2 控制范围：输入、工具与技术和输出

2.1 控制范围：输入

项目管理计划

项目管理计划组件包括（但不限于）：

范围管理计划：记录了如何控制项目和产品范围
需求管理计划：成本管理计划记录了如何管理项目需求
变更管理计划：定义了管理项目变更的过程
配置管理计划：定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程
范围基准：用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施
绩效测量基准：使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施

项目文件

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

经验教训登记册：在项目早期获得的经验教训可在后期用于改进范围控制
需求文件用于发现对商定的项目或产品范围的偏离
需求跟踪矩阵：有助于探查任何变更或对范围基准的偏离对项目目标的影响，还可提供受控需求的状态

工作绩效数据

工作绩效数据可能包括收到的变更请求数量、接受的变更请求数量，或是已核实、确认和完成的可交付成果数量。

组织过程资产

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

现有的、正式和非正式的，与范围控制相关的政策、程序和指南
可用的监督和报告的方法与模板

2.2 控制范围：工具与技术

数据分析

可用于控制范围过程的数据分析技术包括（但不限于）：

偏差分析：将项目实际执行结果与项目基准对比以识别范围、成本、进度偏差并评估其可接受性，超出临界值需采取纠正或预防措施，关注偏差大小、性质和原因以便采取针对性措施
趋势分析：审查项目绩效随时间变化，通过收集分析不同时间点绩效数据识别绩效改善或恶化，恶化时采取预防性措施，改善时调整项目计划，有助于预测未来绩效。

确定偏离范围基准的原因和程度至关重要，有助于项目团队了解偏差根源，采取纠正或预防措施，纠正措施消除或减少当前偏差，预防措施防止未来类似偏差。

2.3 控制范围：输出

工作绩效信息

本过程产出的工作绩效信息综合反映了项目和产品范围实施状态，与范围基准相对照，涵盖以下方面：变更请求的分类、已识别的范围偏差及其成因、这些偏差对项目进度和成本的具体影响，以及对未来范围绩效的预测分析。

变更请求

分析项目绩效后，可能会提出针对范围基准、进度基准或项目管理计划其他组成部分的变更请求。这些变更请求需要经过实施整体变更控制过程的审查和处理。

项目管理计划更新

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括（但不限于）：

范围管理计划：可以更新范围管理计划，以反映范围管理方式的变更
范围基准：在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后，需要对范围基准做出相应的变更。有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供现实可行的依据
进度基准：在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效测量提供现实可行的依据
成本基准：在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据
绩效测量基准：在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据