如何编制项目实施计划1

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

    做工作要有计划，谁也不会否认这句话的正确性，但在实施过程中，很多人尽管天天做计划，但并不清楚计划到底是怎样帮助自己更加有效地开展工作的。
    实施工作如果缺乏计划，将直接导致如下恶果：
    工作目标不明确。
    不同类型的工作混乱交叉。
    做事不分轻重缓急。
    不能合理分配时间。
    对项目而言没有计划往往导致延期。
    在编制计划过程中存在很多常见的误区，笔者下文将结合计划编制的基本要求，深入分析造成误区的原因并提出解决对策。
    第一节计划必须是合作双方充分沟通的产物
    很多人计划写得非常细致，也非常全面，但执行时并不理想。很重要一个原因是整个计划是个人经验、心血的结晶，不是合作双方沟通的产物。
    计划是大家对后续工作安排和分工的一种共识，一个人把工作安排得再好，没有其他人发自内心的认同，除制订计划的人以外，其他人又怎会按照计划执行呢?
    按照绝大多数单位部门的管理章程，实施过程是不能没有计划的，很多时候项目经理只是按照制度的要求写个计划，然后照惯例发给用户，至于实际上是否按照计划做，都不去管它，全然不沟通。存在为计划而计划的情况，甚至有的项目经理以为计划只是用于让用户去感知软件公司做事规范性。
    有的用户对计划非常重视，项目经理费尽心机把计划写出来，然后提交给用户审核。用户同意就按计划去做，不同意再去调整，直到用户满意为止。这也是一种形式的沟通，但这种形式的沟通也存在一个很严重的问题，长期这样沟通下去，用户会逐步变成一个计划审核者，忘记了自己还是项目参与者的身份。如果可能的话，项目经理还是应该请用户一起合作编制工作计划。
    没有和用户充分沟通的计划往往是一种独轮车计划，整个计划不断描述软件公司在这个阶段做什么工作，那个阶段做什么工作，需要用户干什么则没有描述，好像我们是很乐于把用户变成一种对立的监工身份。做计划的时候要随时考虑有没有让用户参与进来，项目经理要敢于让他们参与项目，并且知道安排怎样的工作给他们做。
    计划中没有提及用户的配合，有时候用户还会觉得很奇怪：那让我们在每个阶段配合做什么工作呢?还要怎样做呢?会不会达到质量要求呢?出于这种担心，用户反而主动让软件公司把计划解说清楚，这在实际实过程中实在是一件可笑的事情。计划应能指导用户如何配合实施，而不是一个对软件公司进度的单向约束。
    第二节计划要体现出对项目实施工作的策划
    有的项目经理编制计划的过程就是参考软件公司内部的管理要求，借鉴一个历史模板加以修改的过程。甚至有不做计划，以为凭借自己的经验到现场一定就可以搞定。尽管机械地复制历史模版可以让项目经理快速炮制出大量格式规范、内容丰富的实施计划，但是并没有技术含量，对实际工作也帮助甚微。
    有的项目经理会义正辞严地辩称， “这个世界其实计划不如变化快，整个项目实施过程就是踩着西瓜皮，走到哪里滑到哪里的过程，反正努力把它往前推动，尽心尽力就好。”有些计划一看就没有体现策划的过程，把软件公司业务方法顺序当作项目过程分解依据，千篇一律。事实上所有的人都承认项目和项目不一样，不存在简单复制的关系，那么计划怎么可以理所当然地套用现成文件呢?
    这些敷衍做法在实际工作中是大量存在的。我们可以总结出这类工作方法的一个共同的特性，那就是不做计划、消极地应付工作，处于受用户摆布的地位；而项目经理做计划的目的则是希望通过计划去有意识地支配工作，使自己处于主动的地位，并能提高工作效率。
    好的计划有一个特征，就是目标定义非常清晰，并且完成目标有清晰的业务里程碑划分。
    项目实施计划不能成为实际工作流水账，必须有明确的里程碑。有了里程碑，项目才有努力控制的管理方向，一旦达到了一个里程碑项目就不可能倒退反复，只能在这个里程碑上继续前进。整个项目实施计划要依据解决方案确定目标，确定的目标要能够清晰地体现出在多长时间内，整个项目团队要完成哪些工作。
    在目标定义清楚的情况下，项目经理要充分考虑达到项目目标的策略，评估哪种策略是现实实践中较合理的，在就该策略和用户充分沟通后，将项目总目标划分为各个里程碑目标。每个里程碑目标必须依据用户的业务划分，实现某部分业务，达到可以正常运行的目的可以算做是一个里程碑。
    设定里程碑容易出现两个问题，第一是把行动当作目标，第二是把完成重要关键事件和里程碑具体含义等同。例如有人把业务调研的完成看做是一个里程碑，其实业务调研是双方项目组为形成统一的项目需求而采取的行动，一旦项目需求真正被认可和确实了，这就是项目中一个非常重要的事件，一旦这个事件产生，原则上就不允许轻易变化和调整，而且也不存在倒退，我们剩下的工作就是努力去做到这个目标。业务调研是达到这个里程碑(了解并确认用户基本需求)的一种有力手段，本身是否完成不应该是里程碑。
    对经验特别丰富的项目经理来说，不经过完整的业务调研也可以帮助用户快速确立项目目标，或者有的客户自身信息化建设水平很高，业务边界在项目选型之前已经清晰定义，我们只需要合理加以实现，这个时候业务调研主要目的是为了有效完成客户化配置。
    此外业务调研很难界定结束的标志，在一个项目过程中随时要保持业务再调研的意识，把一种长期动态存在的行为定义为一个不可倒退的节点是比较不妥当的。
    所以将业务调研报告的提交定义为里程碑，实质上是把项目中的某项策略下要执行的关键行动当作目标来定义，其实该工作完成与否对项目质量很重要，但对用户而言不会获得真正意义上的收获。像这种把行动当作目标是很容易在编制计划时发生的行为。
案例
    项目经理小李在一份项目计划中把召开启动大会作为一个里程碑事件，但有人说召开启动大会只是个形式，形式主义的I作列为里程碑合理吗?
点评
    有的项目经理把项目启动大会看做是一个里程碑。如果我们把筹备项目启动大会的真实目的看做是取得高管支持，配置合理且有力的项目团队和项目管理制度当作是核心目标的话，在很多项目中启动大会召开后不见得完成了这个目标。所以有人感觉启动大会是一个形式主义的产物。将一个形式主义的工作当作里程碑，从管理上看是否合理?如果认为是不合理的，为什么不设定一个更合理的里程碑?
    笔者以为很多时候把项目团队成立和项目供应链管理制度确认作为项目较开始的里程碑标志更合理，项目启动大会可能只是标志这个里程碑完成的一个关键事件，但未必是达到这个不可逆转的里程碑事件的必要事件。
    里程碑事件应该是证明项目达到某个不可逆转的阶段，而不是表面上非常风光的事件。里程碑就是要结合项目寻找那些在业务上一旦进入该节点就不太可能导致项目退步的事件。
    根据对里程碑的这个理解我们就很清楚所谓软件的功能得到验证，软件配置完成这些活动都很难是真正的里程碑，在项目中协同软件通过验证和项目进入实际运行状态之间还有很长的路要走，把项目上线列为里程碑对团队目标完成更有指导和鞭策意义。
    这是需要项目经理根据对项目的把握去进行精心策划的地方，正是做计划的关键之处，也能充分体现一个项目经理能力和经验的地方，而且可以断定不同的项目计划绝对不会完全一样。
    当然所有的这些里程碑是项目经理打好腹稿，全力和用户沟通达成一致的结果，较终形成文字确认的内容并不复杂。此外软件企业项目经理还要记住一点，对同一项目，里程碑是内外有别的，但可以尽量统一考虑，尽量合并为一致。例如给用户的计划里可能某部分业务上线是一个里程碑，但对内可能是支持该业务的一项功能开发必须在约定时间完成才是里程碑。
    较后一个忠告：在一个项目中里程碑不用太多，更不能描述得太复杂，较好用一句所有人都能很快理解的话来描述里程碑。
    第三节划分计划的层次和衔接关系
    以上谈到的需要建立里程碑的计划，实际上是一种全局性计划，全局性计划不涉及太多阶段的细节工作。
一个项目的实施计划还需要细化和分解成各个阶段的子计划，每个阶段子计划还要逐次分解为不同活动的现场和非现场工作计划。
    若仔细研究起来，现在有些电子商务项目的工作计划其实是不同突发事件驱动的，和全局的实施计划失去有机的联系，这种里程碑计划对项目导向和控制作用就不明显、不清楚。
    有的人把一个全局实施计划都精确到天，对不明白的用户可能觉得写得非常周到，但全局计划过于精确就没有了控制的价值，因为变动因素太多，能够精确控制活动的计划往往只体现在周期不长的现场阶段工作计划中，但每次现场阶段工作计划应该可以看出隶属哪个里程碑阶段，完成后对里程碑起到怎样的促进作用，这样一层