国内非常多的项目经理对项目的计划和管理都是留于口头上，因为事情太多而没有时间整理一份正式的书面文档，于是很多事情到时找不到相应的责任人，更多要靠项目经理现场的超水平指挥。
项目组中的成员在初期时知道自己所做的事情，但随着项目逐步推进，出现各种问题，使之忙于解决问题，忘记了原来的目标和时间点的要求，这种情况在技术人员身上屡屡出现。最终导致项目失败的原因非常多，归根结底是大家不知道项目的计划、进度、工作的限度和目标。
为避免上述不利局面的出现，笔者往往在项目组正式工作时，就拟定书面计划书，和公司领导讨论决定后，群发给项目组成员，让成员都明白项目的计划安排和预估，明白整个项目的进度、重点以及各自任务，包括个人因能力不同而产生的压力，使大家心里有数，不至于临上阵慌了手脚。在项目进行过程中，如果有偏差或偏离，相互间还可以相互帮助提醒，减少项目失败的风险。
书面计划，是项目推进步骤的预安排和风险预见的基础。有了计划书，申请资源时就有据可依，让领导也明白项目的大致进度以及可能产生的风险，为制定下一阶段的战略决策提供依据。反过来，领导也会更加支持项目的推进，创造最好的外部条件。
计划书分为对客户的外部计划书和对同事、公司领导的内部计划书。笔者见过不少大公司的正规计划书，只有一种，就是给客户的计划书，没有给同事的计划书，而同事往往是项目成功的核心和关键。
这种计划书写得非常详细，都按一个模板修改填充，一般在12页以上，也有多达120页的。这详细的计划书固然有其优点，不过作为内部计划书，看了半天怕难以把握到重点，反而是没人去认真看。笔者结合自己多年的经验，谈谈如何制定一份详尽且简单明了而又重点突出的项目内部计划书。
一．客户企业情况介绍
介绍内容包括公司性质、人员规模、管理体制、公司氛围、对项目的支持程度等等。最关键的是项目的成败对该公司及相关人员的影响，如果项目失败不单单会导致他们奖金被扣，还会导致他们的职位发生危险，甚至给部门乃至公司造成不良影响，客户对项目的进展就会有非常高的支持度。只要项目需要，客户就会提供配合，甚至会加班加点陪着测试软硬件。
如果项目是客户的总经理作为战略管理引进，目的是提高中高层的管理水平，则一定要找到对项目比较热心的人员特别是中层的配合，到时请他们部门作为试点，逐步向公司集团推广。这会让项目的验收提前至少一个月。
如果是部门级的应用，则一定要将所有的测试做好，保证不出现常规或明显的问题后，再将软件提交客户，保证软件一次满足客户的要求，千万不要造成占用客户过多时间的现象。
还有就是，垄断型的国企一般都有好大喜功、要面子、遇到责任推委、明哲保身等现象，针对这些问题罗列处理原则。重点把握客户的某些情况，对中后期项目的推进会起到不可预估的作用。
二．项目客户情况介绍
介绍项目客户参与人员的情况，及其在项目中的地位、职责。例如电脑部或技术部的负责人是谁，部门经理是谁，谁是项目的负责人，谁是项目业务负责人，谁是实际软件的操作者，谁是协调人和联系人，及其兴趣爱好，至少聊天的话题心里有数。因为项目推进过程中，和客户的关系处理得好坏直接影响项目的进度及后期验收，“虽然你不是基督徒，但客户是上帝”！
在这里，还要了解客户对项目的态度，他们身上是否还负责其他项目，其他项目的规模和他们上司对项目的重视程度。笔者公司早期的项目只签到了十几万元，而客户同时在运行的项目却是个百万元级的，客户技术部虽然派了两个人配合，但我们知道这两位仁兄的工作重心不在我们这边。
于是我们将软件都测试好，将数据导入正常运行觉得没有问题后，再通知技术部的人来看结果。所以每次我们打电话通知技术部的人时，他们都非常热情，因为他们知道软件基本上没有问题，和他们负责的另一个项目成了鲜明的对比，所以他们在后期项目验收时明显地站在我们软件厂商的立场帮项目验收了。
对那种技术或业务水平非常一般、只关注自己的想法、又有权力欲的客户，一定要早先知道，小心不要让其对项目造成恶劣的影响。笔者一同事在负责一国企大型项目时，就遇到了这样的客户，最后他忍无可忍，指着客户的鼻子骂“你懂什么啊你”。
虽然客户的上司心里有数，但场面上还是会维护自己的同事，而我们软件厂商虽然更明白且心里支持，但最后还是我们的总经理打电话向客户陪不是。事情结束了，后期那客户对项目的态度就变得很差了。得不偿失。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
