应对日益严重的“范围蔓延”
遭遇“范围蔓延”的项目数量从2014年的43%增加到了2018年的52%，这虽然未必意味着范围管理做得越来越差了，但至少意味着范围管理并未取得应有的发展。也就是说，范围管理的发展是落后于实际需要的。
PMI（项目管理协会）的2018年《职业脉搏调查》报告（以下简称《脉搏》）显示，过去12个月中，高达52%的项目遭遇了“范围蔓延”，比5年之前的43%有明显增加。即便是在高绩效的冠军组织中，也有33%的项目遭遇了“范围蔓延”；更不必说低绩效组织中的69%了。从2014年到2018年，虽然项目的平均进度绩效和成本绩效都是稳中略升，但是“范围蔓延”却是越来越严重。这也是促使PMI在该报告中把“避免范围蔓延”列作项目成功的三大决定因素之一。
项目的范围包括项目范围和产品范围。前者是指必须做什么事情，后者是指必须做出具有什么功能的可交付成果。产品范围决定着项目范围，项目范围服务于产品范围。范围，作为用于定义项目目标的一个重要维度；范围管理，作为项目管理中的一项重要工作；都是PMI在1983年7月的《道德、标准和认证研究报告》中首次正式提出的。从那之后，全球项目管理界开始关注项目的范围及其管理。
2004年， PMI在《项目管理知识体系指南》（ PMBOK 指南）第3版中首次写进了“范围蔓延”这个术语，提醒项目管理工作者不要把对项目工作的“逐渐细化”错误地做成“范围蔓延”。逐渐细化，必须是在范围边界之内进行的，不能超出既定的范围边界；而“范围蔓延”是指未经控制的项目范围或产品范围扩大（突破范围边界），即：未经变更管理流程审批、未考虑范围变化可能对进度、成本和资源的影响的范围扩大。这之后的《PMBOK 指南》各个版本也都有关于防止”范围蔓延”的相关内容。
一方面，项目管理界一直强调要防止“范围蔓延”；另一方面，越来越多的项目实际遭遇了“范围蔓延”。这种不和谐确实出人意料，值得我们深思。
“范围蔓延”成因
遭遇“范围蔓延”的项目数量从2014年的43%增加到了2018年的52%，这虽然未必意味着范围管理做得越来越差了，但至少意味着范围管理并未取得应有的发展。也就是说，范围管理的发展是落后于实际需要的。那么，导致“范围蔓延”的主要原因究竟是什么？
根据《脉搏》报告，项目失败的三大主要原因同时也是“范围蔓延”的主要原因。这三大原因是：组织的工作优先级的变化，项目目标的变化，以及需求收集失误。我们可以对这三大原因作如下解读：
组织的工作优先级的变化。某方面的工作在组织中变得更重要了（即便是暂时变得更重要），就很容易引起人们想当然地去扩大相关项目的范围。例如，因为发生了安全事故，公司决定进行安全整顿，就很容易导致过多过份地开展项目中的安全检查工作。
项目目标的变化。未经严格变更控制的项目目标修改，很可能引发“范围蔓延”。增加产品功能，当然会导致“范围蔓延”。延长项目工期或增加项目预算，则可能导致人们仅仅为填满项目时间段或花掉项目预算而去多做一些不必要的工作。如果缩短工期或削减预算却不相应缩减范围，那也属于“范围蔓延”。
需求收集失误。这包括收集需求的对象不全面或不正确，以及收集需求的方法有问题。例如，只向部门领导收集需求，而没有向将实际使用项目成果的部门员工收集需求；基于自己的需求主观地去推断别人也有同样的需求；只使用少数几种需求收集技术。如果相关方的真实需求没有反映在项目计划中，那在项目执行中就很容易因新需求的提出而发生“范围蔓延”。
在《脉搏》报告中，新技术的不断出现，以及项目复杂性的提高，也是导致“范围蔓延”的重要原因。一方面，由于技术日新月异，一个已提出的需求，可能在被实现之前就会过时。这就使需求更新成为必要。需求更新，如果缺乏严格的管理，就会被错误地做成“范围蔓延”。另一方面，正如《脉搏》中提及的，高度复杂的项目的比例，已经从2013年35%增加到了2018年的41%。越是复杂的项目，范围管理的难度就越大，也就越容易发生“范围蔓延”。
除了《脉搏》报告中指出的上述五个主要原因以外，人们对范围的小幅度变化往往不敏感，以及往往误认为增加工作当然能够提升价值，也是导致“范围蔓延”的主要原因。如果不及时发现并控制小幅度的范围变化，那么一个又一个的小幅度变化就会积累成大的范围变化。如果未经严格评审就增加项目工作，那就会导致“范围蔓延”，就会降低项目的价值。团队可能为讨好客户
而随意增加工作，领导可能出于良好的愿望而随意要求员工增加工作，甲方可能出于单方面的考虑而随意要求乙方增加工作。
防止“范围蔓延”之策
（一）建立规范的项目治理机制
因组织工作优先级变化和项目目标变化而导致的”范围蔓延”，根源通常在高级管理层（项目经理的上级），所以应该通过建立规范的项目治理机制加以预防。项目治理是指高级管理层对项目的高层级的指导、支持、监督和控制，旨在把高管人员对项目的比较随意的“人治”变成比较规范的“法治”，既有利于防止因组织工作优先级的变化（特别是临时的变化）而导致项目的“范围蔓延”，也有利于防止高管人员随意修改项目目标。
越是重要、复杂或大型的项目，就越需要由高管人员牵头建立项目治理委员会（项目领导小组），来充当项目唯一的高层决策机构。项目治理委员会要对项目的管理作出一些原则性的规定。这些规定既是对项目管理团队的束缚，又是对项目管理团队的保护。除了由项目所在组织的高管人员担任治理委员会主任以外，还应该邀请供应商的高级代表和用户的高级代表加入治理委员会。项目经理及其团队必须按项目治理委员会做出的原则性规定对项目进行管理。项目治理委员会必须为项目创造良好的外部环境，排除各种外部干扰；必须确保项目目标的严肃性和完整性，避免对项目目标的随意修改。（二）使用多种技术收集各相关方的需求
因需求收集失误而导致的”范围蔓延”，根源通常在于项目经理及其团队收集需求过于主观和片面。人们很容易因自己有某种需求，就想当然地认为别人也有同样的需求；也很容易只在自己的“舒适区”收集需求，例如，只使用自己熟悉的需求收集技术，只针对较容易打交道的相关方，只针对较明显的需求。
为了尽量全面且客观地收集需求，就应该使用尽可能多的技术去收集尽可能多的相关方的需求。为此，在《PMBOK ®指南》第6版中，专门对收集需求过程列出了多达16个常用技术，并在项目相关方管理知识领域中提醒人们要识别出所有而非只是限定范围内的相关方。除了“专家判断”这个通用的技术以外，对其他15个技术加以分析，可以发现如下逻辑关系：
首先，使用多种技术收集原始需求。这些技术包括文件分析、访谈、问卷调查、观察、头脑风暴、焦点小组、名义小组、引导式研讨会、系统交互图、原型法、标杆对照。
其次，使用亲和图和思维导图来分析和整理原始需求，搞清楚各种需求之间的关系。
最后，使用多标准决策分析技术对全部需求进行排序，选择排序靠前的那些需求去实现。或者，也可以组织相关专家进行投票，选择应该在本项目加以实现的那些需求。
在需求收集阶段，不怕收集来的需求数量多，只怕数量少。 数量多，经过归类、排序和筛选之后，可以把一些无需在本项目上实现的需求放在一边。数量少，就会遗漏一些重要的需求。
（三）使用敏捷方法
新技术不断出现，项目复杂程度不断提高，会导致相关方的需求很容易发生变化。例如，新技术的出现使原有的需求过时，相关方无法在项目开始时就说清楚对复杂项目的需求。需求越是容易变化，越是无法在一开始就明确，就越是要用敏捷方法去开展项目。
所谓的“敏捷”，就是快速应对甚至提前引领变化。敏捷方法，自20世纪90年代在软件开发行业诞生以来，已经得到越来越广泛地应用。面对技术的日新月异和需求的不断变化，就必然需要用敏捷方法去有规则地应变和领变，防止“范围蔓延”等无序的乱变。在敏捷方法中，把整个项目生命周期划分为一个又一个的迭代期，确保项目的需求和范围在单个迭代期中保持不变，并鼓励在下一个迭代期开始时主动对需求和范围进行变更。迭代期可长可短，取决于需求和范围易变的程度。越是易变，迭代期就应该越短。
用敏捷方法，不仅对团队成员的要求很高，而且对客户的要求也很高。项目团队必须是小规模全功能的，即：人数少（如59〜 人）且每个人都是通用的专才（ Generalized Specialist）。客户必须能够频繁且深入地参与项目，即：在每个迭代期开始时表达需求，结束时评审项目团队交付的原型（初级产品）。如果客户不愿意或没时间频繁且深入地参与项目，那么敏捷方法将以失败告终。
（四）尽力克服人性的弱点
人们对小幅度的变化不敏感，以及误认为增加工作能够提升价值，这都与人性的弱点有关。对于突然的较大变化，人们很容易感知到并加以管理；而对于一小点一小点的逐渐变化，人们则很容易麻木不仁，从而无法及时加以管理。等这些小的变化积累成大的变化之后，再加以管理，往往就会错失最好的管理机会。
人的本性是鼓励多做事情的。这就容易让人们忽视“范围是需要严格控制的”，容易误导人们随意增加工作。事实上，随意增加工作，不仅不能提升项目的价值，而且还会降低价值，因为新增的工作会消耗资源，会打乱原定的工作计划。
人们应该通过不断提升自我综合素质，来提高对小幅度变化的敏感性；通过不断学习项目管理知识，来强化自己的范围控制意识。
变化，并不可怕，可怕的是无序的变、失控的变、无价值的变。应该通过有效的管理，尽可能把变化拉入有序、受控和创造商业价值的轨道中。建立规范的项目治理机制，尽量全面且客观地收集需求，敏捷应变甚至领变，以及设法克服人性的弱点，这些都是有助于预防“范围蔓延”，从而有助于项目成功的方法。