变更控制流程

第一步，变更申请者提出变更，并提交变更申请单（CR），在CR里详细描述变更内容，并写明变更的理由。大家需要注意的有三点，第一点，申请者通常在提交变更之前分析自己变更的内容以支持变更的理由。但是，这里的“分析”不是我们整体变更控制里的“综合分析”。毕竟，对任何一位变更提出者来说，都会期望变更是对自己有利的，因此，他的分析并不是基于整体来分析的。如果我们按照申请者分析的结果作为依据来审批变更请求，这恰恰规避了整体变更控制流程。第二点，很多时候，变更的提出者未必会按照变更控制流程主动提出变更，那么作为项目团队成员就要根据提出者的要求填写变更申请单，并征求变更提出者的意见以后作为正式的CR进行提交。第三点，变更请求是提交给项目管理团队，而不是直接提交给审批者，更不能直接提交给CCB。

第二步，项目经理或项目管理团队根据正式的CR召集相关干系人对变更请求进行综合分析。分析变更对项目的综合影响，并对变更的实施提出建议。本步骤的"分析"才是整体变更控制的分析过程，也是项目团队需要关注的工作。

第三步，项目团队将CR连同综合分析的结果和实施建议根据变更管理计划提交给相应的干系人进行审批。项目的变更管理计划里定义了变更的批准层次及干系人在变更管理过程的角色和职责，项目团队应该根据变更管理计划获得相关干系人对变更的审批。审批人员或者团队可以基于项目的整体要求批准变更，也可以否决变更。如果变更被否决了，申请者可能还要提交更多信息以支持再次获得审批。不管是批准还是否决，都应该在变更日志中对状态进行记录。

第四步，如果变更请求得到批准，则需要将被批准的变更请求更新到相关的文件或计划里，以反应更新内容，同时也保证相关干系人参照同一版本的项目计划或文件来执行项目工作。

第五步，通知受变更影响的干系人，并按照计划执行批准的变更。

第六步，对被批准执行的变更求情实施情况进行跟踪。

工具/材料：电脑。

第一步，打开电脑进入桌面，找到文件打开。

第二步，打开后进入此电脑选择需要进行设置的文件夹。

第三步，找到需要修改的文件鼠标右键属性进入。

第四步，d出界面点击安全-编辑进入设置。

第五步，进入后把完全控制勾选即可。

按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。

进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。

(1)项目启动阶段的变更预防

对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候千万不能手软，这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。相对于需求来说，什么WBS、风险管理、计划进度都是次要的，只要需求做好了就会一帆风顺。

(2)项目实施阶段的需求变更

成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点：

需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。

需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。

精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。

注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。

(3)项目收尾阶段的总结

能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。

事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。

---