一些的项目计划，在执行的过程被抛弃了，它们看不到项目完工的一天，项目经理和项目成员也因此怀疑项目计划的价值。

现代项目管理流派很多，据说已经超过30多种，被应用在IT项目管理中的耳熟能祥的有：国际项目管理协会IPMA的ICB知识体系（对应IPMP认证），美国项目管理协会PMI的PMBOK知识体系（对应PMP认证），以及PMI在2003年发布的OPM3模型，英国OGC的PRINCE2方法论，另外，涉及项目管理领域的其他流派有，ISO10006项目管理质量指南，美国梅伦大学SEI的CMMI中的项目管理域，还有就是我们的国家标准那一套，等等。我们简直处于标准的海洋！可怕的问题是，我们都还不太会游泳。今天，讨论一下在软件项目管理中，项目管理的问题之一------项目计划的问题。

1.项目经理的计划之惑。

（1）“计划”之数量庞大。PMBOK要求有9类管理计划，分别是：大的项目管理计划，从属的有范围管理计划、进度管理计划、成本管理计划、质量管理计划、人员管理计划、沟通管理计划、风险管理计划、采购管理计划。CMMI相关要求的管理计划有：项目计划、项目集成管理计划、风险管理计划、评审计划、沟通计划、人力资源计划、资源计划、质量保证计划、度量计划，另外跟工程相关的有配置管理计划、验证与测试计划、需求管理计划等。加起来也有10几个。把它们合并同类项之后，也有差不多10个计划。搞清楚这些计划之间的输入输出关系、影响关系、变更关系，以及如何把握计划的粒度和层次，如何选择制定计划的工具，如何获得计划的一致理解等等，这些问题对一个年轻的项目经理或者刚刚从技术岗位转岗到项目经理的新人来说，无疑是非常头痛的事情。

（2）“计划”之闭门造车。很多情况下，项目经理把工作任务分解等同于项目计划，认为项目任务分下去了，计划也就完成了。于是，他们很快地根据生命周期模型分解出工作包，然后安排了时间顺序。项目计划就算完成了。这样做有太多的假设：你假设了你一个人就了解了项目该做的全部工作，忽略了项目组成员可能提出来的技术风险需要的准备工作，而这个工作恰恰在关键路径上。你假设了测试部门可以按时委派一组测试团队到你的项目组，忽略了资源竞争和冲突常常发生。你假设了每个工作包的工作量评估的八九不离十，而忽略你的主观性。你假设了你对团队的绝对的领导，而忽略了你的资深设计人员暗流涌动地跳槽计划。你假设了上级会无条件地支持你，而忽略了上级也有上级的难处。你假设了计划模板告诉了你应该做的所有的事情，忽略了计划模板也许对你的项目不太适用。你还假设了一切事情都会顺利进行，等等。你的最大的假设就是：项目计划是你一个人的事情。这当然导致闭门造车。这样造出来的计划看上去特别的“完美”，但它一定是缺乏“免疫力”的，经不起项目的风吹雨打。

（3）“计划”之计划。许多项目经理同时认为，计划就是写计划文档。其实，计划文档不过是计划过程的产出。我们不能直接冲着结果去。一个有项目干系人参与、项目团队成员协作的项目计划过程是值得我们去执行的。项目经理也要为这个过程计划计划。

（4）“计划”之成本和效率。如果计划过程需要时间、需要不同的人参与，那么，是不是计划的成本太高了？一些项目经理有这样的想法。看看吧，如果你的项目规模不小、周期不短，好好地计划计划是非常值得的，不用猴急。有两句古语你明白就是了：磨刀不误砍材工。凡是预则立，不预则废。

2.如何让计划“活”起来。

（1）“孕育”是决定计划“先天能力”的关键。

一个计划在出来之前，好好地研究研究，不断地考量考量，看看历史项目的执行记录，找找类似项目的可取之处，有助于杜绝别人的错误在你这里重演。项目启动之前后，项目经理要关注各路项目干系人的期望是否已经了解清楚了。如果哪个干系人没发现，如果他的期望被遗漏，项目的目标一定不能圆满完成。项目经理要关注影响项目成功的几个关键因素。如果这些关键因素没找到，项目的计划一定无法涵盖与此相匹配的工作包（比如：对关键开发人员缺失的忽视，导致招募工作计划被遗漏）。项目经理要关注客户对需求的明确程度，不明确的需求可能蕴藏着返工风险或者项目范围失控风险。如此等等。通过这些反复地质疑，不断地识别出来各种可能的不确定因素，孕育出宏观的对策，使得项目的计划不仅满足基本管理的要求，更重要的是满足这个特定项目的特殊要求。

（2）“优生”是计划可行性的保障。

       当项目经理通过前期对项目环境和项目特点的宏观了解之后，这个时候，就可以开始制定项目计划了。前面说过，项目经理不能抱着闭门造车的想法开始项目计划的制定。一定要遵从项目计划的方法论，安排好制定计划的工作序列、人员参与、技术工具、输出成果等环节。（特别是集结大家的智慧，让计划也流淌着大家的心血，这样的话，执行起来，大家的抗拒心理也就没有了。底层的计划尤其如此。）

    首先把项目生命周期模型和产品生命周期模型的复合起来，建立项目的过程模型。确定最高层次的项目阶段和里程碑。一般来讲，层次越高的计划稳定性越好、指导性越强、生命力也最持久。

    第二步，根据项目的特点，对拟使用给项目的计划进行裁剪与合并，确定计划的优先级和重要性区别。项目经理不可能在所有的工作上平均分配管理精力，必须区分重点和非重点领域，从而对应重点性不同的计划。比如说：项目不涉及外购构件或设备，那么裁减掉采购计划。项目的团队是从上一个项目整体继承过来的，并且两个项目技术领域一致，那么人力资源计划就可以非重点考虑。等等。这样下来，计划的数量就会较少，不同计划的工作量也会所有区别。

    第三步，关键团队成员一起识别项目的任务以及任务间的关系，建立高层的WBS，并把关键任务包含进去。这是一个关键的步骤，决定着计划的可执行性和稳定性。如果WBS分解太细，那么执行起来日历的变动可能性就越大，导致计划与执行不一致，失去指导性。如果太粗，项目跟踪起来风险就大。取得平衡很重要，慢慢在实践中体会吧。

    接下来，进行成本和进度估计。这里边有很多方法论、技术和工具的应用。专业地做好这一步工作，确保资源到任务的分配是合适的。

   最后，为项目假设和风险准备足够的管理预留，并确保需要的时候可以得到。管理预留的价值是为那些无法确定工作量的特殊任务给它的执行者提供“意外”的资源和时间。比如：某个技术预研，并不知道该花多少时间。另一个价值是在里程碑处，或者其他任何你认为需要的时间的河任务上，提供时间缓冲和处理应急的机会。

   这一系列规范的、充分参与的工作之后，一定带来一个“优生”的计划。

（3）把“计划”放到项目中去“锻炼”。

    许多计划经不起项目的执行，一执行就出问题。其实问题没那么复杂。首先不要做这样的计划：“12日结束需求分析，13日开始系统设计，...15日结束详细设计，16日开始编码实现。”这样的计划没有阶段间的管理预留，一旦前面出问题，可能会引起连锁反应，导致项目计划失去意义，影响大家对计划的信任。如果很不幸你做了这样的计划，那我告诉你怎么办。在执行过程中提前赶工，给后面挤出管理缓冲时间。我常常看到当项目延时了，项目经理痛苦的调整项目的Schedule，工作量很大。为什么？还是没有管理预留。这就是把计划做得太“死”，结果导致计划本身不能适应变化。项目经理要不断地评估计划的可行性，发现计划的不足，修正计划的缺陷，确保计划的适度宽松。

（4）让“计划”适应“变化”。

    既然项目的变化是一个普遍现象，那么怎么应对呢？如何使得你的计划适应它的变化呢？如何处理突发事件对项目计划的影响呢？新的风险，新的变更，新的缺陷，等等这些问题在你不留意的时候，它总会出现。怎么办呢？如果管理预留已经黔驴技穷了，那么，有两个方法可以处理。一是，不要把自己的团队变成外部事件的应激响应者。外部一有请求或刺激，你就马上做出反应，这是不对的。项目经理要明确地知道，自己才是项目的指挥棒，不是外部的客户或者某种权力。这是权利和义务均等的原则。赋予你义务的同时，你也要拥有相应的权利。比如：决定权。对于那些新的需求要敢于拒绝和延期。对于变更，要在不影响任务执行和不造成集体返工的前提下，有限接受，小范围调整进度。如果变更影响很大，那么必然导致计划的变更。这就是第二个方法：提出计划变更。计划变更一般都基于项目外部环境的大的变化和新的重大缺陷或风险的发现，所以，这是不可预知的，应该向上级提出新的资源、工期和成本请求。变更后的计划就可以继续指导新的工作了，就可以适应新的变化了。

   最后，强调一点，管理成本存在一些不可预知的成本，这些要不断地通过项目实践获得经验值。