数字化项目管理中经常碰到的问题是需求变更，它也是导致项目延期的主要原因之一。有的时候，项目的甲乙双方往往因为过多的需求变更而争吵或剑拔弩张，严重的还导致项目中途一拍两散，给甲乙双方都造成巨大的损失。毕竟，甲方认为需求变更是避免不了的，而过多的需求变更也将给乙方带来额外的工作量，进而导致项目交付成本大幅增加(除非甲方愿意承担额外的交付成本)。

如何管理和避免数字化项目交付过程中过多的需求变更呢?有的人说要有严格的需求变更管理流程，或者将需求变更进行管控升级，以约束甲方人员随意地提出自己的项目需求。这还是治标不治本的办法。

项目交付过程中之所以会有需求变更，根本原因是项目之初的项目需求没有识别准、识别全。现实点说，大多数乙方在交付数字化项目时主要是被动地响应甲方的需求，或者用自己的软件产品功能针对性地去引导甲方的需求。

可以肯定地说，通过上述方式得到的需求大都是片面的。原因很简单，如果由甲方人员提需求，甲方人员提的需求大多是碎片化的，或者是想到什么说什么(没说出来的不代表就不是或没有)，有些需求甚至是想当然或过于理想化。乙方根据自己的产品功能针对性地引导甲方需求，所引导出来的需求往往也是片面的，因为它必然会受制于产品功能，而现实中不太可能存在一个能够满足行业内各种企业业务需求的软件产品。因此，通过上述方法获得的业务需求，大都是片面的、不系统的，有的甚至是伪需求，自然就难以避免项目后期的需求变更。

标杆分析或最佳实践，有助于准确、全面地引导、挖掘和识别甲方的项目需求。但很可惜的是，不是任何情形或任何乙方企业都能找到与甲方业务完全匹配的最佳实践。在这种情况下，在一定的方法论和业务参考模型或业务框架指导下业务需求分析就是一种可选办法。换句话说，业务需求分析或业务咨询应该在一定的方法论、业务框架或业务模型的指导下来进行。

业务框架或业务模型是甲方企业所处的行业业务模式的抽象化、概念化、结构化、系统化描述。在业务框架或业务模型的指导下，甲乙双方可以一起进行需求共创，共创出甲方的未来蓝图或业务的理想姿态。共创过程中，甲乙双方需要做的就是根据甲方的业务特点，向业务框架或业务模型中不断地添枝加叶，不断地完善细节。而且，因为框架或模型的系统性和业务逻辑自洽性，可以避免需求遗漏或想当然。

方法论一般指的是结构化、流程化的做事方法。方法论以过程模型的形式，把一件事情从开始到完成的全过程划分为若干阶段，每个阶段设置里程碑控制点(质量门)，并明确各阶段交付物和交付物模板，而最终交付物就是甲方想要的项目成果。

在方法论、业务框架或业务模型指导下进行业务需求的收集和分析，可以充分地识别甲方的项目需求，检验甲方项目需求的业务合理性。只要甲方的项目需求在项目之初就识别准了、识别全了，就可以最大限度地避免项目后期不必要的需求变更，从而确保项目保质、按期交付。