咨询公司Kepner Tregoe的技术实践负责人Andrew Vermes说，范围蠕动是任何项目经理生活的祸根，而且在某种程度上是不可避免的。
范围蠕变可以从一开始就避免，但如果你不能，我们将继续讨论可以管理的方法。这是一套实践技术，不能替代你在项目管理知识体系（PMBoK）、项目能力成熟度模型、PRINCE2或其他地方可以找到的大量理论和知识。
企业延长或改变IT项目的需求有很好的理由：世界在发展，新的数据安全威胁被发现，客户的外部需求在变化，技术的进步使不可能或无望的昂贵变得实际可行。改变需求的坏理由可以总结为 "我们一开始就没有好好考虑过"。
你可以在每个项目或子项目上使用以下想法来避免或管理很大一部分的范围蠕变。
- 评估你正在尝试的工作过程。
- 让利益相关者深入参与规划。
- 5 whys – Get behind the stated requirement;
- 不断地管理风险和机会。
- 保持假设的可见性。
评估过程
为了紧紧抓住最终的范围，你必须让利益相关者参与到流程审查工作中。这样，他们会指出当前流程的缺陷，以及 "真正的 "流程与部门操作手册有很大出入的地方。以后发现意外情况，将导致不受欢迎的改变。
如果你要修改一个现有的功能，让一些用户来讲解他们的工作。便签是记录这些步骤的一个很好的方法。确保他们向你展示，而不是描述他们认为正在发生的事情。对于一个新的过程，他们可以带领你完成他们想象中的过程。
一旦你捕捉到了它，让他们在执行真正的任务时进行尝试。如果有必要的话，在纸上画几个粗略的屏幕，让用户组看看它们的工作效果如何。将差距记录下来，并继续玩下去，直到你觉得有一定程度的信心，认为这个过程做了它应该做的。
留白 "是最近经常使用的一个流行语。这个词最早是由Alan Brache和Geary Rummler在90年代提出的，指的是观察到任何组织中的许多重要工作都是在 "官方 "流程步骤之外完成的，而且不考虑组织的等级制度。如果不是这样，我们的许多公司可能会倒闭。
一种方法是试图把所有的东西都强行塞进流程框里。从项目经理的角度来看，这也表明我们必须照顾到流程步骤之间的接口。从一个步骤到下一个步骤的箭头上实际发生了什么？人们在做什么，以增加流程中没有显示的价值？
让利益相关者深入参与项目规划
让用户/利益相关者群体更深入地参与项目范围的开发。典型的做法是，业务和系统分析员提出问题，起草需求，然后与利益相关者一起审查。这样做的风险是众所周知的；用户提供一个考虑不周的愿望清单，然后在整个开发周期中不断地增加它，改变他们的想法。
一个典型的项目范围将定义五个要素：什么、为什么、如何、何时和多少。对项目要做什么的定义--被称为项目说明--是至关重要的，它需要简明扼要地描述最终产品，使用户群体清楚地知道他们将得到什么，而生产者（我们）则要做出什么。
在这个阶段创造正确的文字--或图片是极其重要的。让利益相关者群体参与到工作分解结构中来也是非常有用的。虽然让他们参与细枝末节的工作可能会适得其反，但让他们在那里帮助制定主要的可交付成果，可以让他们了解要建立什么，以及如何建立，并作为一个有用的现实检查。
项目目标（我们为什么要这样做？）本身就经常是范围蠕变的来源，特别是如果我们签署了一套项目本身无法交付的结果。
你可以用一个简单的技巧来进行现实检查，并在要求后面加上五个为什么。五个 "为什么 "起源于日本的丰田公司，目的是揭示问题的原因。这个想法是，通过连续问五次 "为什么"，你可以提高你的知识水平，通过了解企业试图解决的问题的根源来找到一个解决方案。
问题是什么？
我们无法及时安装新的服务器容量。
为什么？
对每个机架的机器数量有限制
为什么？
产生的热量很高
为什么？
使用旧设计的机器
为什么？
因为上一代产品提供了高稳定性
这个简短的例子显示，我们的挑战是保持历史上的稳定性，但我们需要找到一种快速增加容量的方法。这也有助于将重点从为服务器群寻找更多的空间转移到（也许）试图找出能够提供相同的正常运行时间而产生更少热量的机器。
并非所有的情况都是5个为什么就足够了。KT提倡所谓的 "空问"--换句话说，重复问题直到你确定你已经用尽了可用的信息或想法。
五个 "为什么 "对于了解所提出的要求的背后也很有用。
我们需要将我们的CRM数据库与监管报告系统连接起来
为什么？
在处理新的客户要求时，我们需要对可报告的投诉有可见性
为什么？
我们希望确保技术建议是适当的
当然，为了避免听起来像只鹦鹉，你会改变措辞："是什么导致你有这种需求？""这对你有什么帮助？
管理发生的事情
风险管理是每一个项目管理的权威，包括项目管理知识体系所倡导的，但在现实生活中，风险日志往往集中在有形的、明显的风险上，如 "服务器故障 "或 "建筑物着火"，而未能足够深入地探索具体的项目挑战。在管理范围时，关键是要关注机会和风险，并以同样的方式对待所有可能偏离范围的情况。
我们应该达到的目标是不断地了解我们周围的变化可能影响或加强我们的项目。对于管理范围来说，最应该关注的风险/机会类别是商业环境，以及组织内外可能导致我们改变对需求的想法的事件。
每周与利益相关者举行问题/风险/机会会议。不切实际？不--尤其是当你使用一个简单的框架，并将会议或电话控制在30分钟之内时。关键问题始终是。
你认为有哪些问题与这个项目有关系？
以何种方式？
这些问题目前（实际）的影响是什么，如果有的话？
潜在（未来）的影响是什么？
列出具体的风险、可能的原因和潜在的行动
列出具体的机会、可能的原因、潜在的行动
选择哪些风险和机会 -
- 暂时不考虑
- 密切关注
- 采取行动，为
保持假设的可见性
任何项目都是建立在许多假设之上的。这些假设可能是关于内部和外部市场、工资率、可用技术、监管限制、产品和服务的利润率，甚至是企业的性质。如果有任何假设发生重大变化，项目范围就有可能需要修改。一个早期预警系统可以帮助我们更好地管理干扰。
在极端情况下，假设的重大变化将意味着项目必须关闭。我们越快意识到这一点越好，以减少资源的浪费。在前面的技术支持团队的例子中，一个关键的假设--合格的员工是可用的，而且很便宜--在当时是真实的，但现在就不那么真实了。而且，情况可能变化得很快，令人恐惧。
这个想法的清单并不详尽，但这是你和你的项目团队可以快速做的六件事，而且几乎没有额外的努力。
管理范围首先是要注意小事。如果我们选择倾听和看到，事情正在变化的线索就在我们周围。