犯错无可避免，失败则不然;你可以弥补错误，但无法弥补失败。这是著名项目管理大师Jerry Madden退休后留下的项目管理至理名言。这也是笔者管理信息化项目的行为准则。作为一个合格的CIO，应该学会为那些高风险的计划或是任务准备应急预案和备选方案。在信息化项目管理中出现的任何问题都可以及时解决，所以CIO的应急方案一定要准备的很充分、很使用。

　　如果CIO做不到这一点，那么CIO就可以换人了。下面可是有很多人在虎视眈眈的盯着你这个位置。CIO如果不能够为项目制订合理的、充分的应急计划，那么CIO很有可能位置不保。

　　那么CIO该如何在制作项目应急计划的时候，该注意些什么呢?笔者对此有以下几个建议，可供大家参考。

　　一、应急计划应该先取得别人的认同

　　如企业实施某个信息化项目，需要对无聊定义编码原则。CIO把这个任务交给了研发部门经理负责，让他们在三天之内制订出一个物料编码原则。此时CIO就需要考虑，如果他们在三天之内交不出成果来，该怎么办呢?此时，笔者认为CIO应该先根据自己以前的工作经验结合公司的实际产品，预先想好一套编码规则。然后先跟总经理或者其他有这方面专业特长的人讨论一下。特别是这套编码规则的应急方案要得到总经等高层管理人员的认同。如果研发部门在三天之内拿出了一套合理的、大家都认可的编码规则，那么CIO准备的这套编码原则也就没有用的。但是如果他们没有在规定时间内提交编码规则，则CIO就可以拿出这个应急的编码原则，要求各个部门按照这个编码原则来执行。这主要是为了保障项目的进度。如果项目因为这个部门没有及时完成相关的工作而耽搁下来的话，对于企业的损失会比较大。

　　为此，应急方案应该预先得到管理者的认同。只有如此，在真的需要启动应急计划的时候，才可以切实的运作起来。如果没有他们的支持，那么这个应急计划即时很合理，但是如果其他员工由于种种原因不买账的话，这个应急计划就如同一纸空文，没有多少实际的价值。故笔者在日常工作中，制定完应急计划后，总会找人去确认这个方案的合理性。然后会找总经理等高层领导进行确认。如可以先做好企业内部联络书，让他们签字画押。然后等到需要遇到这个应急方案的时候，就可以马上拿出来用了。

　　二、应急方案贵在精，而不在多

　　对于应急方案来说，贵在精而不在多。如以上这个编码原则这个方案来说，CIO不用准备多种编码原则。CIO只需要考虑企业的物料性质、产品种类、系统支持等因素，然后设计出一套到两套质量高的编码原则即可。也就是说，CIO不能够以为这个方案只是用来应急的，是否用的到还是另外一回事情。就忽视了应急方案的质量了。

　　首先应急方案精体现在符合企业的实际情况。就拿物料编码规则来说，不同企业物料性质、物料种类、物料数量不同，编码原则也肯定不同。为此CIO在编制编码原则应急方案的时候，可以参考其他公司的编码原则，特别是同行业的编码规则。但是不能够照搬全抄。在编码原则应急方案编制中，要能够结合企业自身的特点。如物料比较多，则可以对产品进行大中小类的划分等等。也就是说，在制定应急计划之前，CIO有必要先去考察一下企业当前的情况。只有了解企业实际情况时，CIO才能够对症下药，制定出合理的应急方案。应急方案绝不是照抄其他企业的方案。

　　其次，应急方案不用太多，一般一个即可。如果CIO实在没有把握的话，那么也可以设置两个应急方案。通常情况下，最多不要超过两个。因为有时候人就比较犯贱。当有的选择的时候，他们就会比较，就会挑三拣四。一会儿说这个不好，一会儿说那个不好。最后可能多个应急方案都会被他们推翻。相反，如果应急方案只有一个的话，他们没有挑了，那么他们就会被动的接受。所以应急方案本来就是为了应急用的，不用给企业员工太多的选择。选择多了，反而用户会犹豫不决。故应急方案贵在于精，而不在于多。CIO在准备应急计划的时候，通常情况下一个已足矣。

　　第三，应急方案应该随着实际情况而变更。当CIO制定好应急方案后，仍然要关注项目的进度。然后随着项目的进度而调整应急计划的内容。如就以这个编码原则为例。CIO在制定编码原则的应急计划之后，并不是说他可以高枕无忧了，反正他们如果按时没有完成任务的话，就可以按照这个应急计划来。就放弃对项目的追踪了。与此相反，CIO应该追踪这个编码原则制定的过程。因为在这个过程中，大家会相互讨论该如何制定编码原则;通过观点的碰撞，用户会提出一些编码原则制订中常见的错误，应该避免的误区等等。CIO通过追踪编码原则制订的过程，也可以了解这些信息。如此的话，CIO就

[1] [2] 下一页