洞察 / 企业增长
项目范围蔓延：成交后守住项目收益
提案已经批准，项目开始交付。随后，客户希望多增加一项产出、再来一轮审核，并对原简报作一点小调整。每项请求听起来都合理，但累积起来，可能让原本商业上可行的项目变成团队超负荷、结果却不理想的工作。
对于服务企业，项目范围蔓延应成为每周商务讨论的一部分。目标是有意识地作出变更，并共同了解这些变更需要什么。
判断请求之前，先定义工作
从团队真正能使用的交付基线开始：约定成果、交付物、假设、客户提供的资料、审核轮次和验收标准。如果交付团队说不清完成意味着什么，再长的提案也难以发挥作用。
销售向交付团队移交时，询问三个问题：客户购买了什么？客户必须提供什么？哪些决策尚未解决？
在项目工作空间中记录答案，也要写入销售沟通中的承诺，避免交付团队在制作中途才发现。
区分纠正与新增
并非每次修改都是范围蔓延。修复未达到约定要求的产出，与增加一项新要求，是不同的事情。
使用简单分类：
- 纠正： 工作未达到约定简报或验收标准。
- 澄清： 对存在歧义的请求形成共同理解。
- 变更： 增加或修改交付物、受众、流程或要求。
澄清需要重视。反复出现歧义，可能说明简报流程薄弱。不要自动把澄清视为免费工作，也不要自动视为收费新增项。
PMI 在 1996 年关于范围变更管理的文章中，阐述了共同认可的基线、变更记录和清晰沟通的价值。这些是长期适用的管理原则，并非新趋势的证据。
为每项变更建立决策记录
有效的变更流程可以放在一页纸内。记录请求、目的、需要它的人，以及不做会产生的影响；随后评估对投入、产能、依赖关系、交付日期和费用的影响。
计入容易忽视的工作：协调、测试、额外审批和其他产出的更新。新增一种演示格式，也可能需要新的质量检查和不同的审批顺序。
为请求指定负责人和决策日期。等待商务决策的工作应保持可见，不要悄悄消失在某个人的任务清单里。
提供能够保留核心成果的选择
回答不必只是拒绝。可以提出可行方案：
- 用新增项替换另一项计划工作。
- 延长时间表以容纳额外工作。
- 增加产能并调整费用。
- 将请求推迟到后续阶段。
- 明确作为商业决定，由企业承担该工作。
用清楚的语言说明每种方案的影响。取舍越具体，客户越容易决定，例如：“可以加入这场额外工作坊，最终建议将在下一周交付。”
开始额外工作之前先达成一致，并更新共享计划。交付团队和客户应依据同一个决定开展工作。
让变更预算可见
变更预算是为预期不确定性设置的内部计划余量，可以覆盖少量额外投入或明确的预备资源。应按项目确定，没有普遍适用的百分比。
记录哪些工作消耗了余量。缓冲不应掩盖简报、估算或审批中的重复问题。
假设示例： 某服务项目收费 USD 12,000，计划交付成本为 USD 8,000。额外请求需要 USD 1,000 的交付成本。如果费用不变且其他条件均不变，扣除这些交付成本后的余额，将从 USD 4,000 降至 USD 3,000。
企业仍可能选择自行承担。重点是让这一选择与产能、客户价值一起清楚呈现。这些数字仅说明扣除其他间接费用之前的项目贡献，并非预测。
每周检查销售与交付的衔接
商务负责人和交付负责人每周进行简短复盘，查看尚未关闭的变更、等待同意的决定、计划外工时及即将需要的客户资料。
解决三件事：谁与客户讨论各项请求，等待期间团队可以推进什么，以及计划是否仍符合约定工作。
项目结束时，复盘原因。如果额外审核轮次反复出现，应改进提案和审批流程；如果客户资料延迟，应明确依赖关系；如果销售承诺超出交付假设，应修复移交流程。
这将业务增长与转型连接到日常交付决策：工作如何进入企业、谁负责取舍，以及新增收入是否带来值得承担的工作。
从一个正在执行的项目开始
选择一个经常出现新增请求的项目，对照约定基线和当前任务，识别尚未解决的变更，并引入一页式决策记录。
与 Zendral 沟通，检查企业卖出的内容与团队实际交付之间的差距。带来一个项目及其近期变更，让讨论从具体运营问题开始。