项目计划修订（上）

（本文是学习笔记，与你们分享）

       本文按照以下的顺序进行：

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业内的从业人员在我的成就的阶梯上不断攀登，人员在各个公司之间来来每每，或者在一个公司内部不断升职。当一个队员由于辞职而离开团队，你必须当即采起行动为他找到一个替代者，这不是一个容易的事情，若是幸运的话，能够从公司内部找到一个能够从原来的队员离开的地方开始工做的人员。最有可能的是让一个新队员加入团队，你将面临评估这个新队员的技能并从新安排资源来按进度表完成项目。你也可能没有其余办法，而只好雇佣一个独立的承包商或者咨询人员。