项目计划书.docx

项目计划书.docx

《项目计划书.docx》由会员分享，可在线阅读，更多相关《项目计划书.docx（6页珍藏版）》请在冰豆网上搜索。

项目计划书

-CAL-FENGHAI.-（YICAI）-CompanyOne1-CAL-本页仅作为文档封面，使用请直接删除

项目计划书（总8页）

国内非常多的项目经理对项目的计划和管理都是留于口头上，因为事情太多而没有时间整理一份正式的书面文档，于是很多事情到时找不到相应的责任人，更多要靠项目经理现场的超水平指挥。

　　项目组中的成员在初期时知道自己所做的事情，但随着项目逐步推进，出现各种问题，使之忙于解决问题，忘记了原来的目标和时间点的要求，这种情况在技术人员身上屡屡出现。

最终导致项目失败的原因非常多，归根结底是大家不知道项目的计划、进度、工作的限度和目标。

　　为避免上述不利局面的出现，笔者往往在项目组正式工作时，就拟定书面计划书，和公司领导讨论决定后，群发给项目组成员，让成员都明白项目的计划安排和预估，明白整个项目的进度、重点以及各自任务，包括个人因能力不同而产生的压力，使大家心里有数，不至于临上阵慌了手脚。

在项目进行过程中，如果有偏差或偏离，相互间还可以相互帮助提醒，减少项目失败的风险。

　　书面计划，是项目推进步骤的预安排和风险预见的基础。

有了计划书，申请资源时就有据可依，让领导也明白项目的大致进度以及可能产生的风险，为制定下一阶段的战略决策提供依据。

反过来，领导也会更加支持项目的推进，创造最好的外部条件。

　　计划书分为对客户的外部计划书和对同事、公司领导的内部计划书。

笔者见过不少大公司的正规计划书，只有一种，就是给客户的计划书，没有给同事的计划书，而同事往往是项目成功的核心和关键。

　　这种计划书写得非常详细，都按一个模板修改填充，一般在12页以上，也有多达120页的。

这详细的计划书固然有其优点，不过作为内部计划书，看了半天怕难以把握到重点，反而是没人去认真看。

笔者结合自己多年的经验，谈谈如何制定一份详尽且简单明了而又重点突出的项目内部计划书。

　　一．客户企业情况介绍

　　介绍内容包括公司性质、人员规模、管理体制、公司氛围、对项目的支持程度等等。

最关键的是项目的成败对该公司及相关人员的影响，如果项目失败不单单会导致他们奖金被扣，还会导致他们的职位发生危险，甚至给部门乃至公司造成不良影响，客户对项目的进展就会有非常高的支持度。

只要项目需要，客户就会提供配合，甚至会加班加点陪着测试软硬件。

　　如果项目是客户的总经理作为战略管理引进，目的是提高中高层的管理水平，则一定要找到对项目比较热心的人员特别是中层的配合，到时请他们部门作为试点，逐步向公司集团推广。

这会让项目的验收提前至少一个月。

　　如果是部门级的应用，则一定要将所有的测试做好，保证不出现常规或明显的问题后，再将软件提交客户，保证软件一次满足客户的要求，千万不要造成占用客户过多时间的现象。

　　还有就是，垄断型的国企一般都有好大喜功、要面子、遇到责任推委、明哲保身等现象，针对这些问题罗列处理原则。

重点把握客户的某些情况，对中后期项目的推进会起到不可预估的作用。

二．项目客户情况介绍

　　介绍项目客户参与人员的情况，及其在项目中的地位、职责。

例如电脑部或技术部的负责人是谁，部门经理是谁，谁是项目的负责人，谁是项目业务负责人，谁是实际软件的操作者，谁是协调人和联系人，及其兴趣爱好，至少聊天的话题心里有数。

因为项目推进过程中，和客户的关系处理得好坏直接影响项目的进度及后期验收，“虽然你不是基督徒，但客户是上帝”！

　　在这里，还要了解客户对项目的态度，他们身上是否还负责其他项目，其他项目的规模和他们上司对项目的重视程度。

笔者公司早期的项目只签到了十几万元，而客户同时在运行的项目却是个百万元级的，客户技术部虽然派了两个人配合，但我们知道这两位仁兄的工作重心不在我们这边。

　　于是我们将软件都测试好，将数据导入正常运行觉得没有问题后，再通知技术部的人来看结果。

所以每次我们打电话通知技术部的人时，他们都非常热情，因为他们知道软件基本上没有问题，和他们负责的另一个项目成了鲜明的对比，所以他们在后期项目验收时明显地站在我们软件厂商的立场帮项目验收了。

　　对那种技术或业务水平非常一般、只关注自己的想法、又有权力欲的客户，一定要早先知道，小心不要让其对项目造成恶劣的影响。

笔者一同事在负责一国企大型项目时，就遇到了这样的客户，最后他忍无可忍，指着客户的鼻子骂“你懂什么啊你”。

　　虽然客户的上司心里有数，但场面上还是会维护自己的同事，而我们软件厂商虽然更明白且心里支持，但最后还是我们的总经理打电话向客户陪不是。

事情结束了，后期那客户对项目的态度就变得很差了。

得不偿失。

　　三．项目情况介绍

　　介绍项目的情况，如项目金额、项目模块、软件体系，包括项目要上几个模块、客户最关心的模块是哪几个、公司现有软件的功能、哪些模块和客户的出入较大、哪些模块需求相符、哪些模块要重新开发、项目选哪几个模块作为突破口等等。

在项目进行过程中，常会遇到客户需求变更的情况，这要求项目经理预先有了解和预估。

　　这样公司的领导也就明白客户观注的重点是什么，而我们的难点又是什么，项目大致的进度是什么样的。

因为作为一个公司的领导，关心的是这项目需要投入多少人力、财力，什么时候项目结束，给公司会带来多少利润。

至于技术点或是细节问题，领导很少会关心。

　　在对自己软件熟知的基础上，自然更要知道客户关心的是什么，不然投入整个公司的资源，花三四个月开发一个客户不认可的东西出来，再推翻重来，岂不是耽搁公司的发展前景。

四．项目工作量预估和问题分析（这是最难的工作）

　　这个问题直接决定项目周期的长短和人员的投入及调配，也是项目经理最难定的一个量，需要在实践中不断积累经验。

一般是按调研后的需求分析说明书来确定工作量，根据各个模块的难度和开发量决定投入的人手和时间，预估项目中的问题难点，包括技术瓶颈、负载压力等。

很多问题的发现和预估则靠多年的工作经验。

　　这方面内容是项目经理争取优势资源配置的重要依据，所以有些技术难点不防有限度地夸大一些，但牛皮不能吹破了，不然以后领导对你的印象就是夸大其辞。

　　笔者有一次向领导申请公司牛人来负责软件中的权限设计，将话说过头了，结果领导听后反驳了一把。

日后笔者再向这位领导申请资源时，领导遇到自己不懂的技术，总会去问问其他同事后再答复笔者，而不是之前那样，笔者提什么要求都当场一口答应。

让笔者花了半年以上的时间才重新建回了信任关系。

　　项目工作量的预估要在熟知需求的基础上，没有太多经验的项目经理一定要多读几次需求说明书，明了客户的需求重点和关心的结果，有经验的项目经理都会关注需求说明书，更何况是经验不多的项目经理了。

对需求说明书中有疑问的、有岐义的一定要标注出来，和相关人员讨论清楚，甚至和客户谈清楚需求点，以防出现方向性错误。

　　五．项目工作计划（这是最核心的工作）

　　本项目的工作计划，包括资源的申请、人员的搭配、团队的组建、开发进度的安排，计划分期的重点，如第一期大约到什么时间，主要完成的任务是什么，需要投入什么样的人，各自负责什么。

　　注意时间点的把握，如果项目实际进度和计划的时间出入较大，项目后期将非常被动。

笔者提供一些参考数字：

一个半月以内的一般多报一个星期，三个月内的一般多报两个星期，半年以内的一般多报一个月，一年以内的一般多报一个半月到两个月，为项目预留出足够的时间。

　　在国内，软件厂商签约时都处于劣势地位，明知道时间很紧，为能顺利签下合同，也不会向客户提出因对需求理解不准而导致的项目时间推延，就怕客户认为我们不专业而丢单。

项目经理如果不能在规定时间内完成任务，项目如果因为一个不可控的风险导致项目时间不足乃至失败，则项目经理的压力就非常大。

所以安排工作计划，要预留出时间以备处理意外事件。

　　六．项目推进计划

　　这部分是写客户现场的推进计划，包括什么时候提交什么东西给客户，现场工作的重点是什么，需要客户怎样配合等。

还有项目的验收思想和验收时的问题及注意点，比如采取整体验收还是分期验收，还是分模块验收或分批验收，验收时要找谁，需要哪些人配合，验收时应注意什么问题、如何避免等。

有了上面的分析后，制定执行计划就水到渠成了。

所以大公司往往将高薪发放有发现问题、分析解决问题的人才，对编程人员的薪水往往差一档次了。

　　这部分计划可以扩充和细化后提交客户，让客户也明白什么时候我们的软件会开发到什么程度，什么时候需要他们什么样的配合，不至于项目组进场打乱他们日常的工作安排。

客户有了这样的计划书后，都会提前安排自己的工作，到时对项目的配合力度更强。

　　笔者的计划书一般就写两页多一点，最多不超过5页，把握重点难点，又对客户进行较详细的初步分析。

不论是和公司的领导谈项目的进度安排，还是和同事及项目组成员布置具体任务，大家心里都有数，知道下一步要做什么。

这样项目只要不发生大的意外和方向性的错误，一般都会处于笔者的预期和控制范围内，项目失败的风险尽可能地降到了最低。