变更控制——牵一发而动全身

　　项目的不确定性因素导致了项目的推动过程不会像计划的那样顺利，随着工作的深入，那些不确定因素逐渐变得明确且和当初的预测不一致的时候，就会导致项目变更，项目的变更是不可避免的。一般来说，项目的目标是项目所有活动的最终判断准则，变更的发生可能会引起项目目标变化，所以，变更控制是所有项目管理者要高度关注的问题，变更往往会牵一发而动全身，搞不好会一招不慎，全盘皆输，所以大家对变更的普遍态度是慎之又慎。

　　从变更产生的来源来看，变更的因素可以分为两类：内部因素和外部因素。内部因素是指项目的实施过程中，对实施的状态对比计划，发现产生了偏差，从而导致变更项目计划。外部因素则是指客户对项目目标本身发生了变化，从而引起计划的变更。

　　为了对项目变更进行有效控制，应由项目实施组织，项目管理班子或两者共同建立变更控制系统。变更控制系统就是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其它书面文件，责任追踪和变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。

　　变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。

　　项目变更就是影响项目整体和贯穿整个项目过程的变更。项目变更控制的目的有三个：

　　(1)查明项目进行过程中发生的变化是否构成变更，

　　(2)对造成变更的因素施加影响，

　　(3)当变更实际出现时，设法处理之。

　　项目变更控制就是协调贯穿整个项目过程的变更。例如，可交付成果的技术要求说明书发生的变更，若影响到项目范围，进而影响到费用、进度、质量、风险或其它方面，则该变更就是项目变更，应当通过范围变更控制系统处理。

　　项目变更控制的依据是项目计划、进展报告和变更请求。项目班子成员或项目干系人的变更请求可能会以多种形式提出。但除非特殊情况，只有书面提出者，才能受理。

　　项目变更控制的工具就是上面提到的变更控制系统。项目变更控制的结果应当有项目计划的更新、采取将项目未来预期进展控制在项目计划范围内的纠正行动和吸取的教训变。

　　基线与变更申请

　　1.基线

　　信息系统的项目管理者对基线的概念并不陌生。基线是软件配置管理的一个重要概念，是已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。

　　根据定义的生命周期模型和项目特征来定义基线。在开发周期，基线的建立时间是不同的，可能会受到不同变更权威的控制。计划期间，项目应按如下所述建立基线，用以维护对配置项的完整性的适当控制。每个基线必须记录在配置管理计划中，包含：基线名称、基线内容、在生命周期的什么时候建立、谁有对基线更改的批准权。

　　当基线形成后，要在项目组内部进行发布。基线的作用是把各阶段工作的划分更加明确化,以便于检验和肯定阶段成果，需求基线则是项目的需求完整定义下来，形成完整的规格。后续变更的基准就是在基线的基础上进行。

　　2.变更申请

　　项目变更的申请可能有不同的来源——可能来自一个潜在的用户，系统分析员，测试人员，或软件供应商。项目管理者都应该建立起一套变更请求(Change Request，简称变更请求)的表格，变更请求表格形式必需与软件配置管理计划保持一致，有些变更管理工具也提供一些一般的电子表格形式，项目中还应该有项目变更控制委员会来负责受理变更请求，包括赋予变更请求一个唯一的跟踪编号和分类号，并实际执行变更流程。

　　变更评审

　　1.变更控制委员会(CCB)

　　负责项目都成立一个专门的变更控制机构——变更控制委员会(Change Control Board)，经常被简称为CCB。一般来说，变更控制委员会是一个项目主要的管理机构组织，CCB最小应该由下面几部分组成：高层经理、项目经理(技术负责人)、配置管理负责人、质量保证负责人、测试负责人。

　　变更控制委员会负责评估那些被提交上来的变更请求，针对这些变更的目的、要求和影响来决策：

　　·同意实施一项变更请求，并且在会议上安排相关的变更实施责任人，和相关联的协作组织;

　　·拒绝某一项变更请求，并给出拒绝的理由。

　　制定项目的启动计划时就要建立项目的CCB，它是在项目初期建立的，将确定的CCB人选记录到配置管理计划中，并发通知给项目组和相关组。当正式基线建立或变更时，要召开CCB会议，并进行会议记录，会后形成《CCB会议纪要》。

　　2.变更评审

　　CCB收到了变更请求后，会有专门的人员先做一个初步的分析，主要是评估变更的来源，变更的理由，变更产生的影响，变更的代价。某些变更会在这个阶段做出一个初步的处理，例如：

　　·描述不清楚地变更请求，会被要求提出者重新补充信息;

　　·删除那些明显错误的变更请求;

　　·一些简单且影响小的变更可以直接分配人员处理;

　　接下来，变更请求会被提交到变更控制委员会进行评审。

　　信息系统项目管理的一个重要方面是对变更申请进行充分的分析评估，这涉及它对系统性能，接口，可用性，成本，进度，合同的影响程度，还应对它对软件产品的安全性，可靠性，可维护性，可移植性及效率的影响程度的评估。项目管理人员将变更请求分派到配置控制小组进行这类评估。在有些情况下，变更请求在被分析前先经过某些小组进行预审，这可以节省一些不大可能被通过的变更请求的评估开销。

　　变更控制委员会评审一般会是以会议的形式进行，有关各方都会参加。可以是定期召开，也可以针对某一项重要的变更临时召集。评估将产生一个报告，其中包括对变更的描述，受影响的配置项及相关文档，以及所要求的资源情况等。下表是一个典型的变更评审检查表。

　　变更分派

　　将评审通过的变更申请分配到各个项目实施小组完成，项目管理者根据变更请求分析报告评估一个变更请求的必要性和代价。

　　符合要求的变更请求发回项目管理者执行下一步的流程：被批准的变更请求发到相应的开发团队或实施团队。

　　项目变更通知通常是一份比较正式的文档，需要业主、承包方、建立方多方面签字。通知到各个和变更有关的部门或项目干系人。

　　变更实施

　　获得通过的变更请求可以直接作为变更授权表，由此派发不同工作小组变更任务单，有时还包括制定对相应修改指导文件。

　　各个小组会根据变革任务单和变更修改指导文件具体变更，并形成必要的记录。

　　变更验证

　　末了，还要对变更实施的结果进行验证，判断变更实际带来的偏差以及对项目其他方面的影响。变更请求实现和测试完成后，项目管理人员将对这个过程进行记录并在更改跟踪数据库中存档。

　　项目变更的控制是一个动态过程，它始于项目的变化，而终于项目变更的验证。在这一过程中，拥有充分的信息、掌握第一手资料是做出合理变更的前提条件，这就需要记录整个变更过程，而记录本身就是项目变更控制的主要内容。