范围变更控制的主要依据包括项目合同文件、进度报告和变更令。

(一)项目合同文件

在总承包项目或施工项目合同中，涉及工作范围描述的是技术规范和图纸。

技术规范(Specifications)规定了提供服务方在履行合同义务期间必须遵守的国家和行业标准、工作范围以及项目业主的其他技术要求。技术规范中单列一章“工作范围(ScopeofWofk)”对需要完成的合同工作做出详细的文字描述。

业主提供的设计图纸，以工程语言描述了需要完成的项目工作，简单而直观。但其缺陷是当一个项目被划分成多个合同时，无法从图纸上区分各个合同的具体内容。即颁发给某一承包商的图纸，图纸上的内容并不一定全部是该承包商必须完成的工作。

由于技术规范和图纸都涉及工作范围，就有可能产生模糊不清或矛盾，此时技术规范优先于图纸(Drawinss)。即当两者发生矛盾时，以技术规范规定的内容为准。

(二)进度报告

进度报告提供了项目范围执行状态的信息。例如，项目的哪些中间成果已经完成，哪些还未完成。进度报告还可以对可能在未来引起不利影响的潜在问题向项目组织发出警示信息。

(三)变更令

形成正式变更令的第一步是提出变更请求，变更请求可能以多种形式发生——口头或书面的，直接或间接的，以及合法的命令或业主的自主决定。变更令可能要求扩大或缩小项目的工作范围。

大部分变更请求是由于下列原因造成的：

(1)由于外界的因素，如政府法规的变化;

(2)在定义项目范围方面的错误或遗漏;

(3)增值变化，如在一个环境治理项目中，利用最新技术能够减少费用，而这种技术在定义项目范围时还未产生。

软件项目范围变更控制

项目范围变更控制要素分析

制约一个项目的条件是项目“三约束条件”——范围、时间、成本。在一个项目中这三个条件是相互影响、相互制约的，而且往往是由于范围变更影响了时间和成本的变更。如果项目一开始确定的范围小，那么它需要完成的时间以及耗费的成本必然也小，反之亦然。很多项目在开始时都会粗略地确定项目的范围、时间以及成本，然而在项目进行到一定阶段之后往往会变成让人感觉到不知道项目什么时候才能真正结束，要使得项目结束到底还需要投入多少人力和物力，整个项目就好像一个无底洞，对项目的最后结束谁的心里也没有底。这种情况的出现对于企业的高层来说，他们是最不希望看到的，然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三约束中范围的影响起到关键作用。

一般来说，在启动软件项目初期，客户就应该提出一个相对确定的项目范围，为项目的实施提供一个牢固的前提和框架，同时也是为后期的项目管理划出一个明晰的 “圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此范围内进行。但是，在实际的操作过程中，这个“圈”的边界有可能会出现模糊、扩大的现象，甚至这些扩大和模糊的部分会给项目带来风险。项目范围（Scope）、时间（Time）、成本（Cost）、质量（Quality）之间的关系模型如图1所示。

如果项目范围即既定的面积S不变，成本C、质量Q、时间T就可以在一个固定的S的边界限制下给出一个约束的关系模型 Cost=f(Quality,Time,Scope)。但是，如果S的值并不固定，就如图1所示出现边界模糊或者向外扩展时， C、Q、T就失去可依赖的边界限制，其之间的约束关系就会变得复杂。因此，我们在对项目范围进行控制时，一是要保证项目初期的S是准确可靠的，尽量减少边界的模糊性；二是要保证项目实施过程中S的稳定，尽量避免扩大化，或是说让扩大化受到合理的控制。

范围项目变更控制流程分析

范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。

一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的，因此变更是不可避免的，关键问题是如何对变更进行有效的控制。项目经理和项目小组必须意识到范围变更本身并没有什么不对，事实上很多时候这会使系统更健壮、更实用。客户通常不能一开始就确定所有需求，而且情况会随时间而变化，如果不能包容变更，那么最终的软件系统可能就达不到应有的价值。但是如果变更失控，后果也非常严重，甚至于导致整个项目的失败。

变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。为执行变更控制，必须建立有效的范围变更流程，它对管好项目至关重要。变更控制流程主要包括四个关键控制点：授权、审核、评估、确认。在变更过程中要跟踪和验证，确保变更被正确执行。范围变更控制流程如图2所示。

提交变更请求：项目的任何涉众均可提交变更请求。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中并放置到变更控制委员会（CCB）复审队列中。

复审变更请求：此活动的作用是复审已提交的变更请求。在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。确认重复或拒绝：如果怀疑某个变更请求为重复的请求或已拒绝的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个 CCB 代表来确认重复或已拒绝的变更请求。如果需要的话，该代表还从提交者处收集更多信息。

更新变更请求：如果评估变更请求时需要更多的信息，或者如果变更请求在流程中的某个时刻遭到拒绝，那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给CCB复审队列，以考虑新的数据。

安排和分配工作：一旦变更请求被置为已打开，项目经理就将根据请求的类型把工作分配给合适的角色，并对项目时间表做必要的更新。

进行变更：指定的角色执行在流程的有关部分中指定的活动集，以进行所请求的变更。 这些活动将包括常规开发流程中所述的所有常规复审活动和单元测试活动。然后，变更请求将标记为已解决。

核实测试工作版本中的变更：指定的角色解决变更后，变更将放置在要分配给测试员的测试队列中，并在产品工作版本中加以核实。

核实发布工作版本中的变更：已确定的变更一旦在产品的测试工作版本中得到了核实，就将变更请求放置在发布队列中，以便在产品的发布工作版本予以核实、生成发布说明等，然后关闭该变更请求。

范围变更控制流程中的每个活动由指定的角色或组织来完成。