你如何检测项目的“偏离”(drift)，并采取哪些措施来纠正方向?
《剑桥词典》将“drift”定义为“缓慢移动，尤其是受外界力量影响，方向不受控制”，对于CIO和项目经理来说，这正是关键所在：项目可能会在你未察觉的情况下偏离方向，因为偏离是逐渐发生的，尽管是持续的，但如果你不及时纠正方向，就会有很大的风险失去对项目的控制。
哪些外部因素会导致IT项目偏离方向?最常见的包括：
• 供应商方面的变化，如推出新的软件版本，必须将其纳入项目，这会延长项目时间线，并需要额外的用户培训。
• 业务利益相关者对项目初始需求列表的改变，如果纳入这些改变，将延长项目时间线。
• 一系列看似无害的项目功能增强“微调”，但累积起来会影响时间线或交付成果。
• 影响项目的业务变化。
由于大多数这些变化来自IT部门之外，CIO和项目经理可能对其直接控制有限，但IT领导者可以采取一些措施来应对项目偏离，以限制其对项目的负面影响，或者如果负面影响不可避免，则以建设性的方式应对。
以下是IT和项目领导者可以用来重回正轨的三个关键策略。
尽早阻止项目功能增强需求的不断累积
项目经理和CIO有时会未能注意到或干预首个项目功能增强需求，从而引发“功能增强需求的不断累积”。
这种偏离可能开始时看似无害——例如，用户请求在屏幕上添加一个简单按钮以实现简单功能——但随着用户推动更多和更大的增强需求，未进行重大修订的项目的进度和交付成果将受到不利影响。
一旦出现功能增强需求，CIO和项目负责人应立即推动召开会议，讨论这些增强需求及其对项目的影响。当管理层和业务用户早期就了解到功能增强对项目进度和交付成果的影响时，大家可以共同决定是否应“冻结”项目功能增强，直到项目在初始阶段交付，或者是否应纳入请求的功能增强，并据此重新制定项目进度和交付成果的时间表。
始终重新谈判
重新谈判项目进度和交付成果与早期与利益相关者就项目功能增强进行会议是相辅相成的，因为接受重大的新功能增强将延长项目进度，并可能导致预算超支。
业务经理知道这一点，但他们也希望从项目中获得尽可能多的功能，因此，他们会安排员工“试运行”项目并提供反馈，如“这很好，但我真的希望还能看到这个功能”或“不，我们不能使用这个，我们还需要为系统XYZ构建一个接口”。
这些请求通常在IT期望仅获得关于次要系统错误的反馈时出现，但业务用户并不总是这样看。相反，他们将质量保证(QA)视为“系统接受”测试——即他们是否会接受这个项目，或者它是否不足以满足他们的需求?
在我早期的IT职业生涯中，我亲眼目睹了这一场景。我们正在构建一个订单录入系统，用户不断改变主意，坚持要求更多的功能增强，该项目充满了功能增强，以至于几乎无法知道何时能完成。CIO和项目经理没有召开会议重新谈判项目进度，而是试图吸收所有这些变化而不改变项目交付日期。项目未能按时完成，最终被取消，项目经理和CIO都失去了工作。
底线是：当项目功能增强影响项目承诺时，始终重新谈判。话虽如此，我遇到过许多CIO，他们非常犹豫召开重新谈判会议，不要成为他们中的一员。
对项目发起人提出更高要求
2023年，麦肯锡的研究显示，53%的项目未能按时交付，而在失败的项目中，13%的失败是由于目标不明确和缺乏焦点，另外9%的失败则是由于需求变化和技术复杂性。
值得称赞的是IT部门，因为这些数字反映出项目执行情况与过去相比有了整体改善，但在管理项目偏离原始需求方面仍有改进空间。
首先，项目需求应始终在需求文档中详细列出，即使你正在使用敏捷作为软件开发方法，项目需求基准文档可以向用户和IT部门说明项目何时偏离，以便项目可以修订或停止。
其次，CIO和项目经理应定期与用户召开会议，以便所有人都能监控项目进度，并发现项目偏离何时开始，然后，如果项目需要改革或重新谈判，所有利益相关者都能参与并提出方案并作出承诺。
