(本文是学习笔记,与大家分享)
       本文按照如下的顺序进行:
l定义变更需求
l建立变更控制
l实现项目变更
l 问题处理会议
l推迟项目
              一条你没有走过的路,当你开车在错误的方向上走了20分钟后才发现,你该如何办?IT项目中经常会遇到类似的情形,无论你做过多少的研究,测试过多少次开发过程,计划制定的有多么的细致,仍然没有人能够预测到未来是什么样子的,IT项目经常是由于在开始的时候,由于偶然或者设计的原因出了错误,幸运的话,可能在实现之前发现这个错误,而另外的情况是来自管理层或者是客户需求的变更可能使得项目的实现方向改变,另外的情况是由于项目经理的原因导致了项目方向的变更。
1.         定义变更需求:任何变更,即使是想更好的方向的变更,都伴随着挫折和痛苦。在IT项目管理领域,变更不应该是一个简单的在原来基础上加入的过程。每个IT项目都有项目范围,项目范围陈述了项目应该提交什么和不应该提交什么,项目范围是将来项目做决策的参照,他是完成项目要做的工作,而且是仅需要完成的工作,一旦完成了项目陈述,需要得到需求方的认可,他就可以避免不必要的变更。但是这个在中国不合适。
然而对于IT项目,由于其自然属性必然要导致变更,打补丁,软件新版本,缺陷,安全问题,项目相关人员的新要求都是导致变更的原因。所有的变更请求都应该文档化,而且要评估变更的成本、时间、风险和相关的回归任务,另外,每个请求必须进行文档记录,跟踪实施变更或者拒绝变更。
然而在项目中经常的情况是将这些变更硬性的加入到项目范围中,即使他是最终可交付成果的全新设计,然后项目经理会竭尽全力使得项目计划适应这些新的和改善的要求,这种做法很少凑效,他会使得项目团队成员的士气低落,感到挫折,使得最终达不到要交付的要求,最后使得项目经理失去对项目的控制,当这些变更确实必要的,为了避免以上的情况发生,你必须要有控制变更和实现变更的一套有效地程序。
2.         建立变更控制:变更控制是一个内部管理的过程,项目经理可以一次来阻止任何人(包括管理层)在没有正当理由的情况下变更项目的交付规格和要求,变更控制要求请求者必须要有足够的理由才能提出变更要求,然后再评估提出的变更对项目的各个方面的影响。变更控制系统是项目中的评估、评审、批准变更的一个正式的文档化过程。CSS是如何评审变更的价值,成本、进度影响,风险以及可行性等过程,CSS也是对批准或者拒绝变更进行跟踪、记录的方法。
在一些企业中,变更控制系统包括变更控制委员会(CCB),CCB对申请的变更进行分析,以便于确定变更的影响,并作出决定,管理层和客户可能有成打的理由对项目的可交付成果作出变更,最糟糕的情况是项目可交付成果的接受者有一天突然来到你的办公室,再与你探讨了项目的实现情况之后,突然对你说,哦,对了,你的项目还要如何如何修改,还有另外的一种痛苦情况,就是团队内部要求做出变更,因为有人发现正在实现的技术根本不适合这个项目,选用的技术不能真正的使用交付,新技术与已有的技术冲突,或者是在安装期间就落伍了。在一个缺乏IT员工的组织中,IT人员每周工作60-80个小时是很常见的事情,他们将从事如此多的实现计划和项目开发,同时还要履行日常的职责,以至于让他们跟上项目计划对他们来说在体力上是不可能的,在这种情况下,除了增加新的资源,没有其他的办法,项目在初期的变更比在后期的变更更容易些,这是一个一般性的规则,也就是说,项目越接近结束,变更交付成果越困难,避免这些的最好的方法就是预防,和项目管理的其他方面一样,扎实的前期调研,计划,与项目可能影响的各类用户的深入的了解都是至关重要的,可以使用以下的方法避免以上情况的发生,1,作为调研阶段的一部分,会晤产品的客户,详细执行这一步将会确保最终产品满足目标要求,2.在进入实现阶段以前,要彻底地研究和测试所采用的技术,具备一个仿真工作环境的测试实验室对IT项目是必须的。3.在项目实现前检查所需要的资源,实事求是的检查员工是否有时间和知识 来实现所提议的技术。
l  变更的影响:在项目管理中,总会发生的事情就是项目计划的变更,对项目计划的正式变更而言,无论这个变更是谁的事情,都是一件严肃的事情,不管这些变更在表面上看起来是多么的小,或者是造成的原因是多么的无辜,从项目周期这点上来说,你的项目网络图是紧凑的,难以变更的,在你的PND中,已经标示了关键路径,在不延长工期的情况下没有假如额外的工作的空间,但是工期的延长是不可以接受的,另外,增加额外的可交付成果需要额外的花费,对项目范围的变更可能意味着需要额外的资金,内部的或者外部的,而且你的预算也可能支付不了这些变更,变更意味着额外的软件或者硬件成本,一般来说,如果变更项目的范围,就需要变更额外的资金。开发组的士气可能一落千丈,面对你的团队成员,并告诉他们到目前为止所做的计划,研究和工作的完成都要加入新的标准,这不是一个好消息,处理这样的消息,你需要拿出你的智慧,并且讲究技术。
l项目变更请求,当变更不可避免时,项目经理必须有一套正式的程序,来把这些变更加入到项目中去,这个正式的程序叫做项目变更请求表。变更控制表对来自任何人的向项目经理的变更请求给出了形式化的描述,这个表格可以是电子版的,也可以是纸质的,也可以是电子班的,变更请求者,项目经理甚至CCB如果认为需要进行变更,就提交变更请求表,他要求请求者不仅要描述变更,还要给出理由说米高为什么这些变更是必须得,一旦请求者完成了这个表格,项目经理,项目发起人和其他项目相关人员就可以判定这个变更是否真的必须,或者应该给与拒绝,或者把这个变更推迟到当前项目完成之后再予以实现。
3.         变更影响说明 变更影响说明是项目经理对于项目变更请求表发出人的正式回应,它概述了项目经理对于如何加入变更的建议计划。通常这是一个可行的途径和项目经理愿意实现的折中方案的清单,有些时候,这个变更影响说明可以同其他回应文件一同提交给客户,项目经理可以在变更影响说明中使用7种不同的回应:
u 对不起,建议的变更不能批准,变更不能加入到当前的项目范围内,这些额外增加的要求将会使得项目失控,范围扩大,并且浪费资金,时间和资源。
u 好消息,你所建议的变更可以再当前的时间线,用当前的资源来完成,变更很简单,不需要额外的资源或者时间。
u 你所建议的变更可以使用当前的资源来完成,但是需要延长时间线,变更请求将会花费额外的时间来完成项目,不过当前的资源可以来完成这些额外增加的事情。
u你所建议的变更可以完成,但最后的期限需要向后推迟并且需要额外的资源,基于变更请求,现在的时间线不再现实,而且以当前的项目团队完成这些变更也是不可能的,这些都源于当前的项目团队成员都不具有增加的组件所需要的技术。
u 你所建议的变更可以完成,但可交付成果将以分层的策略来实现,这种反应接受了提议的变更,但根据这个变更做出的可交付成果将优先根据客户需求来发布。
u坏消息,如果不对项目计划做出相当大的变更,建议的变更就不可能实现,对项目建议的变更是如此之大以至于它将使得当前的计划完全作废,要做出这种变更就需要充分的理由。因为这将使得前面所有的艰苦工作,时间和到目前为止投入到项目中的资金完全丢弃。
4.         项目内部的麻烦:对于项目计划的变更,最困难的是来自于项目团队内部,这些变更通常都是由于每个项目中都恒定的一个变量引起的:人为因素。
人为因素是一个可以预测的问题,它通常是那些没能完成他们的分配任务,没能与其他人交流而发现困难和缺点,或者对工作失去兴趣的团队成员引起的,这些大错特错都是领导失误的表现,作为一个项目经理,你必须在项目的实现阶段起到积极的作用,能像消防队员可以嗅到烟味一样发现正在发生的麻烦,你必须充满活力的投入到这些任务中去,从问题的源头解决问题,在它羽翼丰满,能够导致你的项目被推迟之前就把他压制住。在做长期的项目时,每一个人都容易在实现阶段失去激情,一旦一个团队的成员对一个项目失去了激情,他就会失去兴趣,耐心和动力,一旦到了这个点上,再激发他们的动力就比较困难了,一个项目经理应该在团队成员真正失去激情之前就早早的意识到这一点。
IT项目经理经常遇到的问题就是问题的反覆,正如你所了解的那样,IT业内的从业人员在个人成就的阶梯上不断攀登,人员在各个公司之间来来往往,或者在一个公司内部不断升职。当一个队员因为辞职而离开团队,你必须立即采取行动为他找到一个替代者,这不是一个容易的事情,如果幸运的话,可以从公司内部找到一个可以从原来的队员离开的地方开始工作的人员。最有可能的是让一个新队员加入团队,你将面临评估这个新队员的技能并重新安排资源来按进度表完成项目。你也可能没有其他办法,而只好雇佣一个独立的承包商或者咨询人员。