虽然说计划没有变化快，但是，没有计划的话，信息化项目就很可能会失控。笔者个人认为，如果CIO在管理信息化项目的时候，没有计划的话，可能比没有目标后果更加的严重。如会导致项目周期的延长，成本的成倍上升，甚至弄得企业乌烟瘴气。故笔者在信息化项目管理中，一直强调必须要有一个合理的计划。

　　笔者如下的三条建议估计能够给大家带来一些启示。

　　建议一：为计划而计划。

　　在开计划会议的时候，最让人头疼的是让项目管理人员坐在一起从零开始商量项目计划。笔者刚开始接触第一个信息化项目，是OA系统。那时，我本来的想法是，自己没有多少的权利，而且也不清楚各个部门的人力安排情况，所以想把这个计划的权利交给各个部门自己。为此笔者就把他们召集起来，希望能够制定出一个各个部门OA系统实施的时间。可是事与愿违，半天讨论下来，都没有结果。大家在计划会议上就知道推皮球，你推来我推去，谁也不原意做第一个吃螃蟹的英雄。

　　所以，笔者认为CIO应该为计划而计划。因为让项目小组成员一起制定一个计划往往是非常困难的，或者说是不可行的。计划会议应该先计划好，否则的话，它会变成一个完全没有组织的会议。这种会议会让项目成员感到你不可信任，让他们疲惫不堪。

　　笔者建议CIO在召开项目计划会议的时候，最好自己先通过对企业各个部门的调研后做一份计划，包括软件选型、合同签订、项目成员的确认、软件培训等等各个环节的时间鱼人员安排。然后再召开计划会议，让大家对这个计划的可行性进行商榷与确认。也就是说，CIO在召开计划会议的时候，不是让大家来制定计划；而是让大家对现有计划进行讨论，若有不同的意见，则可以进行调整。若没有，则就按这个计划为准。

　　当然有一个前提，CIO自己做的项目计划一定要有一定的可执行性。若全部项目组成员都反对你的计划，那么这个计划会议仍然会闹得不可开交。故CIO若有时候觉得对自己的项目计划没有把握的话，还可以在会议之前先跟一些关键部门进行协商，先取得他们的支持。

　　建议二：计划中必须明确列出用户需要达到的结果。

　　在做计划时，可以利用两类语言来描述，分别为过程性语言与结果性语言。如对于一个编码原则制定的需求来说，即可以利用“该怎么怎么编制编码原则”来描述，也可以利用“在什么时候完成编码原则的编制并最终得到研发、质量、采购等部门负责人的认可”。前者是过程性的描述，而后者则主要是结果性的描述。

　　笔者认为，CIO在制定项目的计划，无论是项目的总体计划又或者是总体计划下面的一个明细，都有必要明确定义计划的所要达到的结果，而不是对过程的一个简单描述。项目团队的所有行为都是为了获得一个结果，换句话说，是为了解决一个问题。如果没有清晰的定义一个计划结果，则到后来我们可能会发现，CIO正在为一个错误的问题制定正确的解决方案。这种尴尬的局面CIO要尽量的避免。

　　具体的来说，CIO可以参考以下的几个原则。

　　一是要制定明确的结果。在做计划的时候，每一个小的计划都需要对应一个结果，并且这个结果大家要能够清楚。如对于编码原则，有些用户可能并不清楚，虽然他们可能平时都在用产品编码。故在计划中，CIO有必要通过举例或者其他简单易懂的方式向项目成员阐述编码原则到底是个什么内容。对于这些专业性比较强的名词CIO就必须承担起向大家解释的义务。若项目小组成员都不知道这个结果具体代表什么，那他们就根本无法进行工作。计划建了也是白建。

　　二是对于结果最好也要个评判的标准。因为在计划的制定过程中，往往会指定需要由谁来负责。但是，这个结果达到什么样的程度才是可以让人接受的或者是合格的，往往没有做出定义。这就导致计划执行人以为自己已经圆满的完成了任务；可是把自己的工作成果交给他人进行后续的工作时，才发现这个成果根本就是一个“豆腐渣”工程。所以，笔者认为在计划描述结果的过程中，最好能够定义一些验收标准。如需要几个部门确认等。这会大大提高结果的质量，减少返工事件的发生。

　　三是需要一个计划一个结果。如笔者在制定计划的时候，一个大计划，下面诸多小计划。但是，只有大计划有一个明确的结果，小计划却只是一些过程性的描述。结果呢，后续小计划根本无法追踪。有些还需要自己一一的跟他们解释计划预计需要达到的结果，虽然这个计划已经事先的大了他们的认可。所以笔者以为，在信息化项目实施的时候，CIO不能够把项目小组成员想象的很伟大。此时，CIO应该把自己当作老师或者教练，而把项目组成员当作自己的学生。在给学生出题目（计划）的时候，要同时把答案（结果）告诉他们。如此的话，他们完成后才会自己去检查，若发现错误的话则可以及时的进行更正。而不会到其他环节需要用到他的工作成果的时候，才发现这个成果有问题需要重新来过。

　　总之，笔者认为，计划与结果一定要一对一。这既方便了计划执行人员进行自我核对，也方便了项目管理人员对计划进行追踪。

　　建议三：计划中应该体现风险控制。

　　任何项目都有失败的风险，信息化项目也不例外。CIO在考虑信息化项目计划的时候，一定要时时体现风险管理的理念。只有如此，才能够把信息化项目的风险降低到最低。具体的来说，笔者认为CIO应该做到如下几点。

　　一是计划应该可更新的。若让计划在项目执行的过程中已成不变，这虽然是我们CIO所追求的目标，但是，往往是一项不可能完成的任务。在项目推进过程中，由于人员调整、企业生产周期变化等因素都可能导致项目计划的改变。所以，CIO在考虑信息化项目计划的时候，就不能够太过于死板，而应该可以有所调整。如当需要调整某个环节的完成日期时，则跟他关联的另外几个环节是否需要调整、该调整几天等的等等，这些因素CIO都必须心中有数。最好CIO能够借助一些项目管理工具。如此的话，当某个项目环节调节，CIO凭借这个工具，就可以一目了然的知道哪些环节受到了影响；是否有调整的必要；以及进行一些自动化调节等等。另外，对于完工时间的定义，最好能通过相对日期来定义。如在几天内完成。而不是用绝对时间，如必须在几月几日之前完成。这些措施都可以提高计划的灵活性。让计划在必要的时候，CIO可以迅速作出调整。

　　二是对于一些风险性因素比较大的，最好能够预先备有一个预备计划。如根据笔者的经验，编码原则制定这个计划往往其风险性比较大。因为这个编码原则，往往企业的各个部门都需要用到。俗话说，众口难调。一个编码原则要得到这么多人的认可，同时又要满足系统的需要，往往有点困难。除非这个计划的执行人很具有个人魅力，才能够得到各个部门的认可。否则的话，根据笔者了解，很难得到大家的一致认同。在照顾了某个部门的时候，就会忽视了其他部门的利益。而若要把全部部门的因素都考虑到编码原则中的话，就又会违反了编码原则“简单易与记忆”的基本原则。所以，笔者在考虑这些风险性因素比较高的计划时，往往会有一个备份的方案。如笔者会事先去了解这个行业的编码方案原则，并根据企业以前的不成熟的编码方案，总结出一个相对可行的编码原则。若相关责任人在规定时间内不能够完成这个任务的话，则就采用这个预备的方案。不然的话，他们老是达不成一致方案，那么这个项目周期就很难控制了。每个环节都拖个几天，那么项目很可能就会延期一个月甚至半年。这对于CIO来说，是非常不愿意看到的。