“迭代式”项目计划管理

项目计划管理应该是动态的

在项目管理知识系统中，计划过程是一个非常重要的过程. 项目计划对项目的实施具有直接的指导作用，是项目管理的重要基准.

在早期的传统项目管理实践中，项目计划被高度重视，并且对项目中所有必需的资源和活动进行了预测和评估，并且必须明确计划直到项目结束的整个过程. 在后续的项目执行和控制过程中，项目计划也非常出色，基于项目计划，力争使项目的实施与项目计划相一致，尽可能确保项目可以执行根据计划. 尽管也允许更改项目计划，但在正常情况下，尽量不要使用此方法. 人们认为，计划的变更意味着计划没有得到充分考虑，或者计划的管理存在缺陷.

即使有100％的置信度，项目计划中所有未来的安排都基于假设. 随着整个项目环境不确定性的增加，项目计划中假设的各种条件变得越来越不稳定，在实际实施项目期间可能会出现大小变化，从而导致原始项目的计划必须进行相应调整. . 这是不可避免的现实. 因此，人们经常听到该项目计划是无用的，因为无论如何，它在将来将是不确定的，并且在计划制定后将会改变.

以上两种观点是对项目计划管理的单方面理解.

我们做个比喻. 制定计划后迭代的开发计划，我们只能遵循执行计划的方式. 我们把它比作传统的大炮. 经过一些计算，针对目标等同于制定计划，并假设我们已经计算出各种影响因素，并且一旦启动就无需进行人工更改. 在指导下的现代火炮还需要预先设计基本弹道，发射后可以根据偏差及时调整，并进行连续修正以确保击中最终目标. 在这种情况下，即使目标移动，它也可以通过及时调整壳体的轨迹来跟踪目标的变化.

因此，面对不断变化的外部环境，没有必要制定计划，而是在计划的基础上，加强后续计划跟踪管理，并根据变化及时修改计划在条件上. 计划管理的动态特征更加明显. 如果项目因素与计划中的假设相符，则根据原始计划执行. 如果发生较大偏差，则修改项目计划，然后根据新计划执行.

这一点在PMBOK中已经很清楚了:

图中从控制过程回到计划过程的箭头具有深远的意义. 当在项目的控制过程中发现偏差并且需要修改计划时，有必要返回计划过程以调整计划，然后根据新计划进入执行过程. 这是典型的反馈控制系统. 从理论上讲，它已经满足了对计划进行动态管理的要求. 密钥取决于实际使用方式.

当然，当实际项目与计划之间存在偏差时，是否通过实施过程来调整与计划之间的实际偏差以调整与计划的偏差（例如加班和进度），或者是否需要回到计划过程以调整项目计划，具体取决于具体情况.

面对这种越来越频繁的变更趋势，实际上确实需要对项目计划的管理思想进行调整，并且还可以以“迭代”方式管理项目计划. 例如，根据WBS，可以首先开发合格且相对稳定的分支机构内容以制定详细计划. 其他不太清楚的计划则首先有一个粗略的计划，然后在有条件时逐渐完善. 在软件开发项目中，通常会针对需求的不同部分安排不同的开发计划. 否则将先制定一个粗略的总体里程碑计划，然后逐步制定该项目的详细计划. 一阶段完成后，将根据实际情况制定下一阶段计划. 它经常用于探索和创新.

在实践中最容易出现问题的迭代的开发计划，是机械的，静态的计划和执行计划，不能根据情况及时调整计划，另一个是当变更需要变更计划时，未能返回规划过程在“随机响应”的执行过程中调整计划，但直接进行调整，结果是失去了可以用作基准的项目计划，因此对项目目标的总体掌握丢失. 后一个问题通常被所谓的“创新”和“试错”所掩盖.

项目计划的动态管理并不是PMBOK计划管理要求的突破，而是更多地反映了PMBOK知识和经验的价值. 我们应该对计划管理的原则和要求有更深入的了解，并能够根据复杂多变的情况灵活地使用它.

要“敏捷”，我们必须首先努力成为项目管理的大师.

元宵节快乐

此问题的编辑器|颜白兰

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-219324-1.html