【案例正文】
我2007年9月接手了一个已经开发接近尾声的项目，项目也不大，前期需求、开发、测试做的也比较好、比较规范，接手的时候感觉问题不大。项目前期的整个过程也和客户进行了详细的讨论和分析确认，但在我们安排实施人员现场实施的过程中，客户在业务流程环节却有着许多细微的变化。
<br>
<br>刚开始第一次实施时，客户针对演示讲解后的系统进行了讨论和分析，同时提出了许多变更的细节，问题到不大，系统修改后很快进行了第二次实施，第二次客户又对系统提出的改进的需求，也是一些细节的内容，导致第二次实施后又回去修改系统，接着第三次，整个过程导致我们实施人员很恼火，说是需求变更吧，也不完全是，有些细节的东西是无法一次性满足客户的……，直到2008年5月，这个小项目才算达到试运行，从第一次拿到客户现场的系统和最后一次试运行的系统的功能的对比来看，系统功能需求的确发生了很大的变化，但是从第一次和第二次的功能比较来看，只是一些细节性的变化。
<br>
<br>对于这些细节性的变更，应该如何处理和控制？

分析1：其实像案例中描述的系统，需求方面已经不存在很大的问题，所以才会导致"细微的变动"。
这些细节上的变化，也许仅仅是一些用户习惯等等，而提出变更请求的用户，也未必能代表其他用户的意见，需要让他们内部先充分讨论，让用户领导确认，明确成本，避免往复修改。
再者，用户和客户的概念也是不一样的，只要不是客户，用户提到，可以再做做工作嘛~~~~~

分析2：可能的原因：
1、需求调研分析不到位。客户不会无缘无故变动，要么是之前没有做到位，要么就是政策发生了变化，目前来看应该是前者；
2、没有变更流程。任何的变更都应该有流程，没有规矩不成方圆，我相信客户也应该能理解；
3、实施时，同客户交流的不到位。特别是一些细节的问题，交流时尽量全面；
处理方法：
1、建立需求变更流程，变更单表明修改内容，工作量大小，双方签字确认（对于当前这个项目，多次变更后就可以把这个单子拿出来同客户交流，情况好的话可以拿到一些补偿，情况差的也能体现实施方的辛苦工作）；
2、需求交流，尽量能讨论的仔细一些，避免以后现在的情况；
3、在项目开始时就确定关于变更的处理方法，如是项目内做，还是项目外做，允许项目内变更多少工作量等等。

分析3：1、找对合适的人去做需求调研，如有必要需要设计出原形。
2、合同中定义好项目范围、变更流程及变更费用的计算。
3、可以从另一个方面考虑，用户的新的想法及思路通过整合说不定会给我们系统的不断完善带来很大的帮助。

分析4：、在项目实施之前，尽可能的了解客户的业务和实际的需求，要对客户的业务尽量的熟悉，很多时候客户想要的和实际需要的东西是不一致的，搞不清楚，客户就容易变更，毕竟客户是上帝，乙方不可能很强硬的对抗甲方的。
2、在客户描述不清楚实际需求的时候，做好陪着着做一个原型，让客户结合原型再修改，这样可以在修改后一次到位
3、在项目启动的时候，要给客户讲解一下项目管理方面的知识，比如讲一下项目管理三角形，让客户了解范围、进度、费用之间的关系，客户理解之后也会知道项目的变更会对项目造成影响。
4、项目的变更要走流程，哪怕是一个小的变更，要不容易养成客户随意变更的坏毛病

分析5：. 既然前面的环节比较规范，那么可以从已经确定的变更需求中发现，新的变更是否在受控范围，如果是新需求则走需求变更流程
2 需求变更流程：提交新需求，完成提交，CCB控制委员会影响分析完成评估 ，评估结果为接纳或拒绝，如果接纳则实施变更还要进行验证，如果拒绝则给出正确的影响分析理由， 这些都必须有一个成文的流程和规矩，实际上就是让新需求走受控的过程。
3 建立变更控制系统
合理的变更控制系统，减少盲目的变更，降低变更的随意性，
很多需求会谁客户的理解和时间发生变化，如果没有变更正式的书面确认过程和有效的控制系统来规避相关事件，则项目范围和当初会大相径庭。
4 偏差分析
5 重新规划
总得说来，就是正式化 书面化变更流程，并及时更新项目范围，进行影响分析和偏差分析，使之处于受控状态，而不是失控状态