3.变化可控制

　　变化是计划的敌人，可惜的是，对项目来说，计划与变化就像一个硬币的正反两面，缺一不可。如何将这矛盾的两者和谐地统一到一起是项目计划必须解决的问题。

　　在这方面，项目计划需要考虑以下几点：

　　首先，搭建稳定的项目架构，架构稳定了，在项目实施过程中由于变化造成的损失就会小很多。很多变化是由于客户对项目的需求发生了变化而引起的，遗憾的是，我们一般不能期望客户一下子将需求定义清楚，更合理的做法是，我们认可对需求的变化是客户的权利，建立实现项目需求的稳定的项目技术框架、基线(baseline)等则是我们的义务。在严格的稳定架构基础上的有限自由度是控制项目需求变化的基本原则。要做到这一点，需要和客户谈判，要让客户乃至必要的其他利益相关方参与项目计划的制定，至少让他们参与计划的评审。我们给客户的任何承诺都是有条件的，但是，客户一般只会记住我们的承诺，而将条件忘得一干二净。从这个意义上看，项目的成果不是干出来的，而是和利益相关方谈判得来的。

　　其次，项目计划需要考虑刚性和弹性的结合问题，要尽量做到以刚性换弹性。由于项目中存在诸多不确定性，一个没有弹性的计划是无效的。 “牵一发而动全身”是对项目变更的写照，对项目来说，很受一些人称道的“弹性工作制”一般不能适用，因为一个人工作时间的弹性会引起其他资源的连锁反应。与部门工作不同，项目资源都是临时性的，它(他)们在不同时间段将被使用于不同的项目，一个资源计划的变更会引起一个或多个项目的震荡。项目计划的刚性与弹性的结合方式有以下几种：资源到位的时间允许有弹性，但是资源被占用的时间则是刚性的；非关键资源的到位时间是弹性的，关键资源的到位时间则是刚性的；一般活动的变更控制是弹性的，关键活动的变更控制则是刚性的。项目计划中的刚性和弹性的辩证关系是十分值得研究的课题，以色列管理顾问E.M. Goldratt提出了一种叫做“关键链”的方法值得借鉴，有兴趣的读者可以查找相关资料1。

　　最后，借助配置管理提高项目变更的管理力度。通过变更控制委员会(Change Control Board, CCB)来对项目变更进行评审是众所周知的，但是，配置管理(Configuration Management)这个词似乎还只是在软件开发项目等少数领域为人所知。配置管理的一个重要目的在于当项目某个局部发生变更时，能够迅速将这种变更传递到关联的各方，使它们同步变更，以尽量减少项目各部分的冲突。既然变更在所难免，因此，项目计划中也必须包含配置管理的计划，仅仅依靠评价、审批等方式来控制变更是不够的。

　　4.问题可预见

　　项目实施过程中会出现很多问题，“只要可能出错就一定会出错”、“当你觉得一切进展顺利时，某个问题已经发生了”、“当你解决一个问题时，将会产生一个更难解决的问题”等都是对项目问题的经验之谈。问题虽然在项目实施过程中才暴露出来，根源却在项目计划上，不能预见问题的项目计划不仅是无效的，而且是有害的，因为它会带来实施过程中大量资源、时间的浪费，这些损失有可能是永远无法弥补的。

　　首先，要系统地识别项目风险。“不战而屈人之兵，善之善者也。”同样，避免问题的发生是解决问题的最高境界。但是，我们永远不能做到预知一切，我们能做的是尽量使风险发生时我们不至于感到意外。在项目计划中要有系统的风险识别、分析、处置和监控方法，要有明确的责任人；要预留必要的资源，以免风险发生时措施成了一句空话;要清晰定义风险的触发机制。

　　其次，要能够追溯问题发生的原因。即使我们已经进行了风险分析，也难保不会有问题的发生，所以，在项目计划中就需要有问题发生了该怎么查找原因的流程和方法，以保证同样的问题不要重复出现。

　　最后，包含改进工作的方法。这种方法的要点是：重视系统与重视人并重。要有能够反映PDCA(计划—执行—检查—修正)循环的方式方法，要有沟通机制、会议计划等。这一点在我以前的专栏文章中已讲过很多，这里需要再次强调的是：沟通永无止境。

　　5.业绩可评价

　　项目是以成果为导向的，项目是否取得成功需要评价，利益相关方是否尽到了对项目的责任、是否兑现了对项目的承诺需要评价，管理方法是否有效同样需要评价。几乎所有的项目结束后都会评价，但是，只有很少的项目在计划中就明确说明了将如何评价，项目评价一般作为单独的文件提供。评价方式是个指挥棒，因为人们会持有“你先告诉我你怎么评价我，我再告诉你我怎么做”的态度。那种“法医式”的、事后评判的方式是不行的，它们只会带来借口，就像斯科特·亚当斯所描述的那样：“在现实中，(业绩评定)就像在后院发现一只死松鼠，最好的办法就是用棍子挑起来扔到别家的屋顶上。接着，你的邻居再将其往别处扔。最后，没有人不高兴，不高兴的只是那只死松鼠。”2有效的项目计划需要使项目利益相关方知道何时、由谁、如何评价他们对项目的贡献，如何评估项目业绩和利益相关方的贡献是项目计划的一部分，而不是独立的管理文件。

　　首先，项目计划中需要包含如何评价项目团队的业绩。注意，这里说的是“团队业绩”。关于团队，似乎人人都明白它的含义。然而，所有的团队都面临一个共同的问题：如何让团队成员共同承担责任。其实，我们永远也不能奢望人们能够自觉地共同承担责任，我们能够做的是评估和保持适当的压力、提供适当的方法，“迫使”团队成员意识到只有暂时忘记个人的利益才能实现项目目标，也才能对他们自身带来利益。如何提供这些方法、如何衡量这些压力是否适当等都需要在项目计划中注明。

　　其次，包含对项目其他利益相关方业绩的评价方式。特别是对企业职能部门的业绩评价方式要与项目团队、项目成果的评价方式相呼应，并通过这些评价来体现职能部门的价值。

　　最后，包含对团队、团队成员、职能部门乃至外部利益相关方的利益分配方式。评价、建议、推荐等权利也是一种利益。经过清晰定义的项目经理、职能经理、外部利益相关方等的评价、建议、推荐权同样对他们是有效的激励。

　　当然，项目计划中还包含很多内容，但是，以上5个方面是容易被忽视的。大多数的项目计划呈现的状态是：上下级之间在讨价还价、拍脑袋与拍肩膀的基础上产生一个“精确”的项目时间线。项目时间线会转化为一个复杂的图表挂在会议室里，好让人们很容易地视而不见，直到某些外部的因素决定实际的完工日期。这种计划尽管包含了目标、工期、成本、质量、采购等项目计划元素，但它们更多的是启动了“六拍运动”，而不能产生项目成果。希望本文提出的5个方面能够对大家判断项目计划的有效性有所裨益。

[1]   [2]