[说明]
2012年3月，系统集成商PB公司的员工老李刚出任项目经理，就承接了S省综合性星火大学的一个大中型软件项目。上任时公司分管领导刘总再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，星火大学频繁的需求变更带来很多额外工作。项目经理老李动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，星火大学相关工作人员不再向老李申请变更，而是直接找项目团队的程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快老李就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，星火大学该项目分管领导陈副校长已经明确表示“失去了耐心”。
而这还只是噩梦的开始。一名程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了3天的时间解决了该问题，但陈副校长却表示“无法容忍这种低下的项目管理水平”。由于担心系统中还隐含着其他类似的错误，陈副校长对项目的质量也疑虑重重。
随后发生的事情让项目经理老李更加为难：星火大学另一名高层领导马副校长与陈副校长对整个项目界面风格的看法不一致，并为此发生了激烈争执。老李知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终陈副校长决定调整所有界面，老李只好立刻动员大家抓紧时间修改。可后来当听说因修改界面风格而造成了项目两周的延误后，马副校长与陈副校长却非常一致、气愤地质问老李：“为什么你不早点告诉我们要延期早知这样才不会让你改呢”这一切都让老李感觉到很沮丧与苦恼。老李陷入了沉思……
[问题1]
结合你的项目管理经验，从整体变更管理的角度分析产生上述问题的可能原因，并给出相应的整改措施(或建议)。
参考答案：①没有明确的授权。建议：事先明确建议方有权提出变更申请的人员和实施方有权受理变更的人员，并有效地控制双方人数。
②对变更没有进行必要的审核。建议：并不是所有的变更都要修改，也不是所有变更都要立刻修改。审核的目的是为了决定是否需要修改和什么时候修改。例如，对于界面风格问题，可以先规划一下修改的时间待到以后进行优化；对于核心模块的修改，则应严格审核把关，否则会引起全局问题。
③对变更的影响没有评估。建议：应该事先评估一下变更的代价及其对项目的影响，并让客户了解变更的后果，与客户一起做出相应的决策。
④没有让客户确认是否接受变更的代价。建议：在评估代价并且与客户讨论的过程中，请客户一起作判断决策。
解析：
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。IT项目中引起变更的因素有两个：①是来自外部的变更要求，如客户要求修改工作范围和需求等；②是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大(特别是到项目的后期)。
变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起；另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。
对于本案例所描述的信息可以看到各种变更失控的现象和造成的后果，项目经理老李主要犯了以下几个错误(包含但不限于)：
①没有明确的授权。事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好处在于：可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际项目管理经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。
②对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。例如，案例中提到的界面风格问题，可以先暂缓修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。
③对变更的影响没有评估。变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起作判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道承建方为变更付出的代价，对项目团队的辛苦便难以体会。案例中客户刚开始对老李加班处理变更相当满意，但只是对工作态度满意，后期当变更引发一系列问题时客户并没有感谢老李的苦劳。
④没有让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请客户一起作判断：“我可以修改，但您能接受后果吗”案例中如果项目经理老李评估了修改界面的工作量并请客户确认，则有以下3种可能结果：A．客户预先接受延期这一后果，也就不会再质问老李了：B．如果客户认为代价太大，则老李就不必修改了；C．如果认为可以缩短延期时间，则老李至少争取到了与客户协商的机会，让客户知道为此项目组需要付出加班的代价，吃个“明亏”。