如何评估项目更改请求

作者：Jane Suchan，PMP

不受控制的变革是项目经理最大的敌人之一。     这就是为什么可靠的变更管理流程可以成为项目经理的最佳朋友。 实施此类流程后，可以在所需的时间线和商定的预算内交付客户要求的内容。 如果没有更改控制，项目范围将成为一个移动目标，并且存在缺少一个或多个项目成功因素的风险。 管理和控制更改的能力（尤其是项目范围变更）是实现目标的关键，也是项目经理的典型绩效指标。 项目更改是不可避免的，你必须准备好在它发生时（而不是如果）处理它。

平衡变革管理和官僚主义

项目经理面临的一个挑战是平衡控制项目更改的需要，同时避免不当的官僚作风。 问题是：临界点在哪里？ 由于每个项目都是唯一的，因此更改控制停止增加值并变成繁琐手续的点因项目而异。

一些利益干系人，甚至项目团队成员可能会认为，实施变更控制是避免可怕的范围蔓延的方法，你不愿意灵活行事，做最适合你的客户和业务的事情。 消除这种看法很重要。 让他们知道，你正在执行的操作正好相反：你正在实施一个高效的过程来一致地评估请求的更改。 如果进行更改被认为是一个好主意，那么你将有流程来在需要时做出响应。

返回页首

项目更改管理计划

为了帮助你快速响应，项目变更管理计划描述了发生偏差时会发生什么情况。 它不是为了防止更改;相反，它的目的是概述一个过程，明确将如何传达变革，如何做出决策，以及项目如何相应地进行调整。

返回页首

实施变更控制

一旦为关键可交付结果（例如业务要求和计划）创建基线，就应立即使更改控制过程生效。 项目团队和利益干系人（以及受项目更改影响的任何其他人）应在实施变更管理计划之前查看并认可该计划。

对项目整体成功影响不大的小更改不应要求与要求或关键路径计划里程碑相同的严格性。 项目更改管理计划必须声明何时需要正式的项目更改请求 (PCR) 。 例如：

• 计划和预算更改的阈值是什么？

• 是否有始终需要更改请求的更改？

• 更改管理过程可以跳过哪些更改？

这里有一个警告：通常是许多小范围的变化造成损害，而不是大，明显的更改。 定义 PCR 条件时，请考虑这一点。 例如，更改管理计划应定义更改请求类别，例如主要类别或次要类别：

• 重大更改    这些应为 记录为 PCR。 主要项目更改：

  • 影响关键路径上的要求或工作项，将重要里程碑或整个项目结束日期延迟一定的时间百分比或工期。 应为每个项目定义重大更改条件。

  • 需要额外的资金 (美元或预算) 百分比。 同样，应为每个项目定义金额。

• 次要更改    这些例行更改不需要 PCR。 次要更改：

  • 不要对计划产生重大影响。 它们不会延长具有项目依赖项的里程碑或任务的完成日期。

  • 没有负面的财务影响。 因此，不会发生项目预算差异。

返回页首

评估更改请求的提示

项目更改管理计划还应包括有关如何评估更改请求的信息。 至关重要的是，这种评估的标准必须在需要之前确定，这样就不会浪费时间达成共识。 设置这些参数将有助于平衡变化与整体业务目标和优势。

下面是评估更改请求时要考虑的一些典型问题：

• 此更改是否会增加或更改业务需求？

• 是否有解决方法，或者此更改是否对项目的整体成功是必需的？

• 这种变化是否需要增加资金？

• 这会延迟项目结束日期吗？

• 尽管此更改可能会对此项目产生负面影响，但它是否会导致重大业务上行，使其值得？

• 现在实施此更改比延迟更有意义吗？ 延迟最终是否会使公司损失更多的钱？

• 是否考虑了所有受影响的利益干系人，他们是否支持这一更改？

• 是否需要考虑合同后果？ 例如，是否由于此更改而无法履行与外部供应商的承诺？

返回页首

审批项目更改请求

定义谁可以批准或不能批准请求的更改也很重要。 通常定义各种权限级别，以便高效处理日常更改，而重大更改则获得所需的管理层关注。

当建议的更改影响项目范围时，应将其视为需要项目发起人批准的业务决策。 当范围不受影响时，项目团队和发起人可能会决定项目经理有权在特定限制内批准更改。 对于某些项目，会定期创建和召开变更控制委员会，以考虑和批准更改请求。 组织中可能有不同的更改控制板，用于处理各种类型的更改请求。 例如，技术更改控制板可能会查看技术问题。

总结批准更改请求指南的一种简单方法如下表，该表基于示例项目：

返回页首

大回报

项目团队总是急于执行项目，有时以有效规划为代价。 走捷径很诱人，并假设你会在去去时弄清楚事情。 在更改发生之前，拥有一个发展良好的变更控制过程，将产生巨大的回报和更好的整体项目结果。 将主观性排除在变更控制之下将使项目团队能够高效、有效地处理波动。 项目团队成员和利益干系人接受的深思熟虑、详细的变更管理计划将节省时间和金钱，而项目经理从未拥有足够的时间。

返回页首