学会动态“迭代式”项目计划管理

项目计划管理本来就应该是动态的。

在项目管理知识体系当中，计划过程是一个非常重要的过程，项目计划对项目的执行有着直接的指导作用，是项目管理工作中的重要基线。

在早期传统的项目管理实践中，对于项目计划都是高度重视的，预测、评估项目中各种需要的资源和活动，直至项目收尾时的全过程，都要清晰的计划出来。在后续项目执行与控制过程中，对项目计划也是非常敬畏的，以项目计划为依据，努力使项目的执行与项目计划相符，尽可能保证项目能够按照计划执行。虽然也允许项目计划的变更，但通常情况下都尽可能不动用这一手段，认为计划的变更，就意味着计划制定考虑不周，或者是在计划执行中管理上存在着缺陷

项目计划中所有对未来的安排都是基于假设，哪怕是有100%的信心。随着整体项目环境的不确定性的加大，项目计划中所假设的各种条件越发变得不稳定，在项目实际执行过程中很可能发生或大或小比较大的变化，导致原有项目计划必须要相应的做出调整。这是不可回避的现实。因此，也时常能够听到项目计划无用的说法，因为反正以后也是不确定的，现在做了计划以后也要发生变化的。

上面两种观点，都是对项目计划管理的片面理解。

我们打个比方，制定计划后只能遵照计划执行的方式，我们把它比作传统的火炮，经过一番计算后瞄准目标就相当于制定出了计划，并假设在计算中已经把各种影响因素都已经考虑在内，一旦发射就无需人为改变。而现代带有制导能力的火炮，也需要预先设计好基本的轨迹，发射后可以根据出现的偏差及时进行调整，不断进行校正，从而保证最终命中目标。在这种情况下，即使目标发生了移动，也能通过及时调整炮弹的轨迹而跟踪目标的变化。

因此，面对变化的外部环境，并非不需要制定计划，而是在所制定计划的基础上，加强后续的计划跟踪管理，根据条件变化及时修正计划。计划管理的动态性特点更加明显。如果项目因素与计划时的假设相符，那么就是按原计划执行，如果发生较大偏差，就修改项目计划，再按照新的计划执行。

这一点在PMBOK中早已说的非常清楚：

　　图中从控制过程返回到计划过程的箭头是有着深刻含义的。在项目的控制过程中发现偏差需要修改计划时，要重新回到计划过程调整计划，再按照新的计划进入执行过程。这是一个典型的反馈控制系统，理论上已经满足了对计划进行动态管理的要求，关键还是要看实践中如何运用。

当然，在项目实际与计划发生偏差时，到底是通过执行过程调整偏差使实际重新与计划相符(比如加班赶进度)，还是需要回到计划过程对项目计划进行调整，这要看具体实际情况而定。

面对变化越来越频繁的这一趋势，实践中项目计划的管理思路也确实需要与之相适应，也可以采用“迭代”的方式来管理项目计划。比如可以按照WBS，把其中具备条件、相对稳定的分支内容先展开制定详细计划，其他不大明确的先有个粗略的计划，以后有条件时再逐步细化，在软件开发项目中，就经常会针对需求的不同部分安排不同的开发进度;或者先制定粗略的总体里程碑计划，再逐个阶段制定项目的详细计划，一个阶段完成后，根据实际情况再制定下一阶段的计划，这种方式在探索创新中会经常使用。

实践中最容易出现的问题，一种就是机械的、静态的制定计划和执行计划，不能根据情况及时调整计划，另一种就是当发生变化需要改变计划时，没有能够回到计划过程去调整计划，而是“随机应变”的直接在执行过程做出调整，结果导致失去了可以作为基线的项目计划，从而失去了对项目目标的整体把握。后一种问题往往会被所谓的“创新”、“试错”所掩盖。

对项目计划的动态管理，并不是对PMBOK中计划管理要求的突破，反而更加体现了PMBOK的知识经验的价值。我们应该更加深刻理解计划管理的原理和要求，能够根据复杂多变的情况灵活运用。

要做到“敏捷”，首先要努力成为项目管理的高手。