变更分析（二）：关于落地的四个三角形

  关于变更的分析，前段时间已经分享过，今天我们来聊聊，一旦确认了变更，为了保障变更能有效“落地”、顺利交付，作为项目经理应该做的事情。

前文链接：关于变更的基础分析

从变更需求提出到确认落地执行，可以分为达成共识、过程合规、落地执行三个过程。

一、达成共识

作为超出原项目计划的“异常点”，变更从作为“一个想法”到逐步落地执行，需要又双叒叕的与所有重要相关方在以下关键维度达成共识：

1.思维意识层面

对于就要实施的变更，项目各相关方对变更的理解、描述、问题、风险、落地所需的资源以及感受上应达成基本的共识，或者至少不存在严重的逻辑冲突。比如，一个变更，如果项目经理已经判定为会带来很多新程序上的问题，那客户至少态度上也要接受这种“复杂性”，在后续的频繁互动中保持一个愿意配合的态度。再比如，面对一个对项目影响相对复杂的变更，也许这次并没有按照乙方的需求给到足够的“支付条件”，作为客户或者用户也应该感知到“偏差”，能够认识到这份变更的隐性或者潜在成本。

2.流程手续层面

我们不以变更的“大”“小”来判断变更的复杂性。不管是什么类型的变更，只要是必须完成的内容，建议一定按照合规手续来执行。不仅爱情中需要仪式感，项目管理中更是这样，规范是需要被执行的，而并非只是束之高阁的一种参考。变更，需要按步骤、按逻辑走流程，并留下关键相关方的签字确认手续。此时需要注意，如果项目中有监理这个角色，监理必须、甚至要牵头执行变更工作。

3.资源分配方面

由于变更的本质是个“新需求”（跟随业务发展变化的、或者原设计中被隐藏的、潜在的），要满足新的需求落地，则必然要“损害”到原计划中需求执行的过程，而且如果新需求与原需求强相关，甚至会将原计划全部打乱，纳入新需求重新梳理后再次输出新的落地实施计划。这个过程项目经理应该积极与项目各相关方尽早地达成共识。

如果从谈判角度来看，项目经理（乙方）已经答应了客户（甲方）一个新的条件（新需求），则乙方也应针对项目实际情况为团队或者项目隐性或显性的争取一些新的“权利”，或者减少一些“任务”或者要求。举个很简单的例子，新的需求发生了，需要调派资源对需求进行评估、确认、工期估算甚至原型设计，不管甲方是否付费，前期的工作主要由项目经理通过安排执行，必然会对原项目进度或质量产生影响。关于此方面，项目经理应保持敏锐的思维，通过谈判的方式争取到更多有利资源。

二、过程合规

变更过程的关键要素是合规。只有符合制度规范、管理办法、政策要求（个别国家级别项目），才能保证变更真实、有效。合规的变更至少包含以下三方面：

1.必须有评审

“变更落地”不仅是一个任务和状态，更是项目重要相关方关于项目未来的一个决策。对于决策，是否合理、合规，就需要有组织来进行评审，通过团队智慧进行决策，因为除了要共同作出“决定”外，还要共同面对跟随决定而来的风险和问题。鉴于并非所有组织都有CCB，所以不限于具体决策组织名称，只要能真实保留决策过程即可（会议纪要、评审表、详细附件等）。

2.必须有材料

同上一条描述，变更落地必须要求材料。材料可以详实记录变更评审过程，帮助不了解情况的相关方快速掌握变更的背景，也方便执行过程中的任何问题可以得到很好的回溯。在项目档案管理（文档管理）中，变更评审材料也是非常重要的内容。此外，在项目交付乃至终验后，变更材料也将再次被单独审计，以保障变更有效、合规。

3.必须有签字

变更材料必须有签字，这一点的重要性不言而喻，但其实痛苦的过程其实是来源于获得签字的过程，毕竟很少有人愿意主动“担责（背锅）”。获得变更材料签字包括但不限于以下途径：①在变更相关的制度规范-变更执行流程中增加“负责人”签字确认（审批）这一活动，并在前期获得其他相关方的认可或支持；②在设计相关活动时，将“签字”人员设定为项目管理的具体角色，并在职责分工中进行强调说明；③发挥“软磨硬泡”的谈判技巧，借助其他外部资源（监理等）获得关键签名。

三、落地执行

通过评审且材料合规有效的变更，则将进入到具体的执行环节。而此时，对于项目团队成员来说，可能变更才刚刚开始。变更的落地执行必须要完成三方面工作，即：技术能落地（能交付）、管理要合规（被认可）、财务需有效（能回款）。

1.技术落地方面

全：材料全、签字全

再次检查变更涉及的材料，是否有遗漏（文档管理过程中经常“后知后觉”，很多材料都是临时补齐），没有获得签字的，必须在关键节点到来前完成签字。

准：更新基准、落实标准

对于符合影响项目关键交付的变更，①纳入新的变更点，统一更新并发布出项目基准；②在制度规范以及管理办法中增加变更涉及的模块，并发布推广。

2.管理合规方面

人：确定负责人、更新干系人

新的需求必须要关联产生新的任务，要想变更得以被顺利执行，新的任务必须与原任务分配方式相同，明确具体负责人员。同时，新的需求是否涉及新的干系人，也需项目团队成员仔细评估。

文：更新过程文件、补充交付文档

对于新需求，过程文件需要逐步补充更新。同时，对于交付清单来说，变更的内容也应补充，或者单独提交一份（包括但不限于，需求规格说明书、数据结构设计说明书、测试三件套、用户手册等），具体依据项目实际情况确定。

3.财务有效方面

财：签订协议、回款付款

对于涉及总金额变动的变更，需要与客户在变更执行前签订（并加盖公章）补充协议，保障手续合理、合规。同时，对于产生新的金额变动，在财务（如需外采或外包），也应相应进行回款或付款工作的跟进。关于项目财务方面，还需注意新变更部分的税费是否与原模块一致，具体需与公司财务人员详细沟通，以免引起财产损失（例如，原项目软件开发已经申请0税费，新变更是否也能申请、如不能的替代方案如何等等）

审：金额审查、过程审查

不管是规模较大的项目，还是较小的项目，变更都是重点审计内容，只是深入与广度的差异。审计主要从两个方面，①是金额方面，一般要求比变更部分不超过总金额10%（具体依据实际要求确定），②是过程手续方面，是否准确、有效、合规。

为了帮助大家更好理解，具体模型设计如下：

今天的文章有点长，这也侧面说明，不管多“小”的变更，都会对项目产生影响，背后所隐藏的工作，只会不少于我们评估的那部分。不管你喜不喜欢变更，总之，谨慎点是没错的。

如果你喜欢本文，可点击“在看”，并评论，我们共同探讨，未完待续~

最后，祝愿平安喜乐，端午安康~