成本管理预计成本全流程：项目经理数据分析与一文讲清

成本管理预计成本全流程：项目经理数据分析与一文讲清

项目做了六成，财务报表显示已花费预算的七成，项目经理却仍按原计划向客户承诺交付，这类偏差往往不是算术错误，而是把“已经花了多少”误当成“最终会花多少”。预计成本管理的关键，不是把历史支出加总，而是基于已完成工作、剩余工作、价格变化和风险暴露，持续回答一个决策问题：按当前情况做下去，项目最终需要多少钱？

一、先讲结论：预计成本不是预算余额，而是对完工结果的滚动判断

1. 先分清三个常被混为一谈的数字

我在拆项目成本报表时，最先检查的不是公式，而是表里的数字究竟代表什么。实际成本、完工预算和完工估算看起来都以金额呈现，但它们回答的是不同问题。把三者混用，后续偏差分析、资源调整和对外沟通就会建立在错误前提上。

• 实际成本（AC）：截至统计时点，已经发生并按照约定口径确认的成本。它回答“目前已经花了多少”。
• 完工预算（BAC）：项目或工作范围获批时对应的计划总成本。它回答“原计划最多按多少成本完成”。
• 完工估算（EAC）：基于当前绩效和剩余工作的重新预测。它回答“照目前的条件，最终大概会花多少”。

预算尚未花完，不代表项目还没有超支风险；实际成本低于预算，也不代表成本表现良好。如果工作进度落后而付款尚未到期，账面支出会显得平稳，但完成同一范围仍然可能需要更多人天、加班费或外部服务费。

2. 把预计成本管理变成一个持续循环

我的判断是，预计成本并不是财务月底才做的一张表，而是一条贯穿立项、执行、变更和收尾的管理链。它要把“范围是什么、计划怎么做、资源多少钱、目前做到了哪里、后面还要做什么”连接起来，形成能追溯、能解释、能触发行动的数据闭环。

1. 明确成本范围、估算边界和统计口径。
2. 拆解工作包，估算资源投入、采购费用和其他直接成本。
3. 建立时间分布与成本基准，明确谁负责更新。
4. 记录实际发生额、已承诺金额与待确认费用。
5. 评估进度和成本绩效，计算完工估算与偏差。
6. 识别风险、变更和未来投入，更新剩余工作预测。
7. 把预测结果转化为决策、责任人和复核日期。

这条链的核心，不是追求某个公式看起来精密，而是确保管理者能从结果追溯到依据。比如预计成本上升了 12 万元，应能回答其中多少来自范围变更、多少来自效率下降、多少来自价格上涨，以及是否已经采取控制措施。

3. 预测必须带着假设，而不是伪装成确定答案

预计成本是基于当前信息的判断，不是对未来的保证。供应商报价可能变化，需求可能调整，团队效率也可能因技术风险发生波动。因此，管理报告应当同时展示估算值、估算时点、关键假设和不确定性，不能只给出一个看似精确到个位数的总金额。

对于早期项目，可以给出区间，例如预计总成本为 185 万至 205 万元，并说明区间来自需求尚未冻结、外部报价未确认等因素。进入执行后，随着范围和实际绩效逐渐清晰，再缩小区间。估算精度应随证据成熟度提升，而不是从第一天就假设自己知道答案。

二、背景与真实场景：为什么“花得少”有时反而是坏消息

1. 成本数据有时间差，付款进度不等于工作进度

项目成本数据通常由多人、多个系统和不同周期汇集。员工工时可能周末后才提交，供应商发票可能在验收后数周才到，采购订单已经承诺但尚未付款，外包费用还可能按里程碑结算。若只看财务系统中的已付款金额，管理者看到的往往是“现金流发生了什么”，而不是“工作实际消耗了什么”。

因此，我会把成本状态至少拆成三层：已确认实际成本、已承诺但未入账的成本、尚未承诺但预计发生的成本。三层相加不能机械地重复计数，但需要彼此勾稽。否则，采购订单已经计入承诺金额，后续发票又被当作新增费用，可能导致成本被重复预测。

2. 一个典型场景：预算花了 70%，工作只完成 60%

假设一个项目的获批预算为 200 万元。统计日实际成本为 140 万元，表面上恰好花了预算的 70%。如果只看预算余额，剩余 60 万元似乎还够用。但项目范围完成度只有 60%，并且成本消耗主要集中在设计返工和核心开发。剩余 40% 的工作还包括集成测试、缺陷修复和上线准备，后几项通常不会因为前期支出偏高而自动减少。

如果这 140 万元对应的已完成工作价值只有 120 万元，那么项目不仅消耗偏快，完成价值也低于投入。简单估算下，如果当前成本效率持续，完工成本可能接近 233 万元。这个数不是结论，而是提醒项目经理：需要检查剩余工作估算、工作量假设和效率是否具有持续性。

3. 预计成本要同时看“工作价值”和“资金消耗”

仅看已花金额容易被付款节奏误导，仅看百分比完成度又容易受到主观填报影响。成本分析需要将工作成果、计划进度和成本消耗放到同一时间点比较。挣值管理提供了一套常用语言：计划价值（PV）表示计划到该时点应完成工作的预算价值；挣值（EV）表示实际完成工作的预算价值；实际成本（AC）表示完成这些工作实际花费的金额。

在口径一致、工作量可度量的前提下，成本绩效指数 CPI 可按 EV÷AC 计算。若 CPI 小于 1，意味着每投入一元成本所获得的预算价值不足一元；若大于 1，则当前成本效率高于基准。不过，CPI 是绩效信号，不是自动预测器。它是否适合外推，还要看项目阶段、工作类型和剩余任务结构。

三、常见误区：让预测失真的，通常不是公式，而是口径

1. 把“预算减实际”当成剩余成本预测

预算减去实际成本，得到的是尚未消耗的预算额度，不是完成项目所需的成本。若项目已发生效率损失、范围扩大或关键资源涨价，原预算余额可能不足以支撑完工；反过来，如果项目删减了范围且正式批准了变更，简单比较预算与实际也可能夸大节余。

正确做法是先区分“预算余额”和“剩余工作估算”。前者是财务控制视角，后者是交付预测视角。项目经理需要说明剩余工作清单、资源需求、成本单价和风险准备，再将其与实际成本合并形成 EAC。

2. 把“进度落后”直接换算成“成本超支”

进度延迟可能增加成本，也可能暂时不增加成本。例如等待客户决策期间，团队暂停投入，日历时间延长但人工成本没有同步上升；相反，如果为了追回进度而增加夜班、外包或并行测试，成本压力可能快速增加。把进度偏差直接按比例折算为成本偏差，忽略了资源消耗机制。

判断进度影响时，要追问三个问题：延迟是否占用持续计费资源？是否触发加班、加急采购或合同违约费用？是否造成后续工作压缩、返工或跨团队协调成本？只有把因果链说清楚，才能给出可信的成本预测。

3. 把一次性低成本误判为长期效率提升

项目早期常出现成本效率看似很好、后期却快速恶化的情况。原因可能是高价值、低不确定性的工作先完成，剩下的是复杂集成、合规验证和难定位缺陷。若将前期 CPI 直接外推到全项目，预测往往过于乐观。

反过来也成立：初期环境搭建、技术验证和工具采购会集中发生，短期 CPI 偏低并不必然意味着全周期成本失控。外推前应先看工作结构是否可比，而不是只看累计指标是否稳定。

4. 把“未入账”当成“不会发生”

尚未收到发票，不等于服务没有发生；采购审批尚未完成，也不意味着资源没有被口头承诺。只依据财务已入账金额，可能漏掉应计成本、已签订单、已发生未结算服务和必需的后续支出。漏记会让预测看起来平稳，却在后期突然跳升。

但也不能把所有潜在支出全部叠加到基准预测上。已签合同、已发生工时和不确定的风险事件，应分别标识确定程度。对每项待确认费用，记录金额范围、责任人、预计确认时间和是否已包含在其他项目中。

5. 把成本节约等同于价值更高

项目成本目标不是把每一项费用压到最低，而是在范围、质量、时间和风险约束下实现合理投入。少做测试可以短期降低成本，却可能提高缺陷修复和客户索赔支出；砍掉培训可能缩短当前周期，却增加上线后的支持成本。若节约来自工作范围变化，必须同步记录交付影响。

我会把“节约”分成三种：效率改善带来的真实节约、范围削减带来的成本下降、成本转移带来的表面节约。只有第一种能在价值和风险不变的情况下直接视为效率收益；第二种需要说明交付变化，第三种则应追踪成本被转移到了哪个团队、哪个阶段或哪个合同主体。

四、专业判断逻辑：先判断数据能不能比，再决定用什么公式

1. 第一步：统一范围、时间和成本口径

分析前要确认所有数字描述的是同一范围、同一统计截止日和同一成本口径。一个表中使用含税采购价，另一个表使用不含税预算；一个把内部工时计入成本，另一个只计现金支出；一个按自然月归集，另一个按里程碑确认，这些差异都会制造假偏差。

建议在项目成本台账中明确以下字段：成本类别、所属工作包、预算版本、发生期间、含税口径、内部或外部资源、实际金额、承诺金额、预测金额、数据来源、录入责任人和最近更新时间。对重大项目，还应保留汇率、折旧、资本化或费用化等相关处理规则。

2. 第二步：把工作拆到能够估算和追责的层级

成本计划如果只分成“研发、测试、管理”三大类，实际偏差很难追到可行动的原因。过度细化到每个小时、每个螺丝，也会增加维护成本，甚至让团队花更多时间填表而非交付。我的经验判断是：拆解层级应足以支持负责人、成本类型和工作成果之间的对应关系。

对一个软件交付项目，成本结构可以拆成需求分析、架构与设计、开发、测试与修复、部署、培训和项目管理；对设备建设项目，则可以拆成设计、材料、加工、运输、安装、调试和验收。拆解的目标不是让所有项目都使用同一模板，而是让高金额、高不确定性或高风险工作单独可见。

3. 第三步：建立成本基准，并把管理储备与应急储备分开

成本基准是经批准、用于比较绩效的时间分布预算；它不应随着实际发生额自动改变。若每次发现超支就把基准提高，成本偏差会被抹平，团队也无法判断绩效是否恶化。对于已批准的范围变更，应保留原基准和变更后的基准版本，让历史比较仍然可追溯。

风险准备也需要清楚区分。针对已识别风险设置的应急储备通常服务于具体风险响应；管理储备用于范围内但尚未具体识别的未知不确定性，并按组织授权进行管理。储备不是可以任意挪用的“余额”，项目经理应记录触发条件、批准角色、使用金额和剩余额度。

4. 第四步：判断哪种 EAC 计算方式适用

EAC 不止一种算法，选择哪一种取决于成本偏差的原因和未来工作是否可比。常见方法如下，公式中的字母应使用同一统计口径。

• 假设原计划仍然有效：EAC＝AC＋（BAC－EV）。适用于偏差属于一次性事件，且剩余工作预计按原预算完成的情况。
• 假设当前成本效率持续：EAC＝BAC÷CPI。适用于当前工作绩效具有代表性、剩余工作结构相近的情况。
• 同时考虑成本与进度影响：EAC＝AC＋（BAC－EV）÷（CPI×SPI）。适用于进度与成本偏差都会影响剩余成本，且两类指数都有解释意义的情况。
• 自下而上重新估算：EAC＝AC＋ETC。ETC 是剩余工作估算，适用于范围或工作方法发生显著变化、历史效率已不具代表性的情况。

公式只是把假设变成数字。假设错误，计算再精确也会得到错误答案。若前期成本超支源自一次性的设备故障，而剩余工作已经恢复正常，直接用累计 CPI 外推可能过度悲观；如果需求持续增加，仍按原计划估算剩余工作又会过度乐观。

因此，我会同时保留一个基于绩效趋势的模型和一个基于剩余工作清单的模型，再解释两者差异。两种结果差距较大时，不急着选较好看的数字，而是回到假设：哪些工作发生了变化？成本效率是否可持续？风险发生概率和影响是否已更新？

5. 第五步：将风险和不确定性单独呈现

把所有风险都塞进 EAC 的单一数字，会让管理者看不出预测的稳定程度。比较实用的做法是保留基准预测、风险调整预测和压力情景。基准预测反映当前最可能的执行方案；风险调整预测纳入已经识别且经过评估的风险；压力情景则用于回答关键变量恶化时成本会到什么水平。

风险金额可以用概率与影响的粗略乘积做初筛，但不能把这个乘积误当成精确的最终成本。比如供应商报价上涨的概率和潜在金额可形成一个期望风险值，但若多个风险相互关联，或风险影响存在区间，应通过情景分析或定量模拟来表达，而不是简单相加。

6. 第六步：让预测和行动绑定

一个没有责任人和复核时间的预测，只是一条信息。每次成本分析结束时，我会要求团队明确：预测变化多少、主要原因是什么、是否需要申请变更或储备、接下来由谁采取什么动作、何时验证效果。行动不一定是削减预算，也可能是冻结非必要需求、优化采购批次、调整资源组合或更改实施顺序。

行动项的目标也要可衡量。例如“加强成本控制”无法复核，而“在下次迭代前完成高风险接口联调，将预计返工人天从 24 人天压到 12 人天，并在周五复核”更具操作性。前者是态度，后者才是管理闭环。

五、具体案例：用一组模拟数据演示从偏差识别到完工预测

1. 案例边界与数据口径

以下案例是用于说明分析方法的情景模拟，不代表任何企业的真实项目数据或行业平均水平。假设某企业实施一个包含需求梳理、开发、集成测试和上线支持的软件项目，获批完工预算 BAC 为 200 万元。统计时点是项目计划执行 60% 的节点，成本均按含内部人力和外部服务费的统一口径计算。

截至统计日，计划价值 PV 为 120 万元，实际完成工作的预算价值 EV 为 110 万元，实际成本 AC 为 130 万元。团队已确认的采购承诺为 18 万元，部分发票尚未入账；为了避免重复计算，分析时要先确认这 18 万元对应的服务是否已经包含在 AC 内。

这组数字意味着当前有成本和进度双重偏差，但还不能据此断言最终一定超支 50 万元以上。项目经理要检查低效率来自什么：需求变更导致返工、技术方案复杂度估计不足、资源单价超预算，还是采购和成本确认口径错位。不同原因对应的后续预测方法和纠偏动作完全不同。

2. 先算两个快速情景，再解释为什么不能只选一个

若假设当前累计 CPI 会持续到项目完工，EAC 可粗略估为 BAC÷CPI，即 200÷0.85，约为 236 万元。这个结果提示了显著超支风险，但它把剩余工作当作与已完成工作同样低效。假如前期低效率主要来自一次性的架构返工，这个外推可能偏悲观。

若改用自下而上估算，团队重新拆解剩余工作：剩余开发 27 万元、测试与缺陷修复 22 万元、上线准备 8 万元、仍需使用的外部服务 11 万元，合计 ETC 为 68 万元。EAC 就是 AC＋ETC，即 198 万元。但这仍需检查待入账承诺是否被重复计入，且要判断 68 万元是否含风险缓冲。

两种算法得出约 236 万元和 198 万元，差异达到 38 万元。这个差距不是需要隐藏的“不好看数据”，而是管理上最有价值的线索：当前的效率表现、未来工作结构和估算假设没有对齐。项目经理应将差异拆分到工作包，而不是在报告里简单取平均数。

3. 追到工作包，找出预测差异的来源

再假设团队复核后发现，开发工作包前期发生 12 万元架构返工，测试工作包尚有较多未验证的高风险接口，外部测试资源单价比基准高 8%。架构返工已经关闭，后续开发方案相对稳定；但接口测试的不确定性仍然存在。此时，不应将所有历史成本低效一概外推，也不能因为返工已关闭就忽略测试风险。

更合理的处理方式是把一次性返工从趋势判断中单独识别，将稳定工作包按当前较新的效率估算，将高风险接口测试采用范围估算，并把外部资源价格变化列为明确的成本驱动因素。若组织允许，报告可以呈现一个基准 EAC、一个含风险情景的 EAC 区间，并标注区间触发条件。

例如，团队可以将 198 万元作为当前工作计划下的基准预测，将 208 万元作为高风险接口测试返工或外部资源追加发生时的风险情景。这不是把 10 万元无条件算进基准，而是让决策者知道风险的量级和触发逻辑。若风险可以通过提前联调降低，就应把测试安排、负责人和复核节点同步纳入计划。

4. 从报表转成管理动作

本案例的第一项动作不是“要求所有部门压缩成本”，而是开展一轮成本驱动因素复核。项目经理需要对照工作包预算与实际，识别返工、价格差异、资源等待和范围变化分别贡献了多少偏差，并检查每笔采购承诺是否已计入成本预测。

第二项动作是把剩余工作估算做到可验证。负责人应列出工作量、资源类型、预计费率、工作假设和风险项。对于开发和测试等相互依赖的工作，不能由各负责人孤立估算后简单相加，因为集成顺序、环境等待和返工会影响总工期及总成本。

第三项动作是设定短周期复核门槛。例如，对高风险接口测试，每周记录已验证接口数、缺陷密度、修复人天和外部资源使用量。当关键指标偏离假设时，及时更新 ETC，而不是等到季度末才解释为什么成本突然上升。

第四项动作是向决策者展示可选方案及其代价。若采用更充分的接口测试，成本可能提高，但上线风险下降；若压缩测试，当前预算预测会降低，却可能增加上线后的修复和支持成本。成本决策必须连同交付结果和风险一起比较。

六、不同情况下的行动建议：预测要跟着项目阶段和不确定性走

1. 立项早期：用区间估算，先讲清不确定性

需求尚未稳定、方案仍在比较时，精确到个位数的预算只会制造虚假确定感。此阶段更适合采用类比估算、参数估算和专家判断相结合的方式，标明估算依据、范围假设和置信程度。高不确定性工作应单列，不能用一个看似精确的总金额把风险包起来。

行动上应优先补齐工作范围、核心资源假设、价格依据和关键风险。若采购报价尚未确认，可同时保留低、中、高三种情景；若人力投入只按总人天估算，应进一步验证关键技能的实际费率、资源可用性和日历周期。

2. 计划阶段：建立可追溯的基准和资源曲线

进入计划阶段后，成本估算应与工作分解结构、进度计划和资源计划相互对应。预算不仅要有总额，还要有成本类别、工作包负责人、时间分布、采购节点和成本发生条件。这样才能回答某个月份资金需求为何上升、哪个工作包可能造成峰值，以及延期会不会延长外部资源租用周期。

在审批前，安排一次“估算挑战会”往往比增加表格更有价值。邀请技术、交付、采购和财务负责人检查最乐观假设、重复计量、遗漏项和费率差异。会议应聚焦高金额、高不确定性和关键路径工作，而不是平均分配审查时间。

3. 执行阶段：按风险和数据延迟确定更新频率

成本更新频率不必机械统一。成本波动小、数据更新慢的项目，每月滚动可能足够；采购额高、外部资源按天计费或需求快速变化的项目，应提高到每周或关键里程碑更新。提高频率也会增加整理成本，因此应优先更新会改变决策的成本驱动因素，而不是为了“实时”展示尚未验证的数据。

每次更新要保持统计截止日期一致。若工时数据截至周五、采购数据截至月末、进度数据截至上周二，把三者直接拼在一起，可能产生不属于真实业务的偏差。无法同步时，应清楚标出各数据源的截止日和预计补录时间。

4. 变更频繁：把范围成本和基准变更分开管理

需求或交付范围变化时，应先估算变更的增量成本、工期和风险，再走授权流程。批准后更新基准版本，但保留变更前的原始基准。这样既能反映当前批准的目标，也能追溯成本上升是执行偏差还是范围扩张造成。

如果频繁发生小变更，可以建立轻量级变更台账，记录提出者、范围描述、估算影响、决策日期和关联工作包。没有明确批准人的口头承诺，不应默默写入基准；否则团队会在执行中不断吸收新范围，最后却被要求对原预算负责。

5. 收尾阶段：把最终成本与估算偏差复盘

项目收尾时，除了结清实际成本，还要比较早期估算、基准版本和最终成本之间的差异。复盘的重点不是追究某个估算者“算错了多少”，而是辨别差异来自范围成熟度、资源费率、生产率、风险事件、数据延迟还是管理决策。

建议保留可复用的估算参数，例如不同类型工作包的实际人天范围、外包单价变化、测试返工比例、采购交期和风险准备使用情况。只有口径相近的项目才适合横向比较；若项目范围、质量要求或资源条件差异很大，不能直接用历史平均值替代本项目分析。

七、工具、报表与团队协作：自动化解决汇总，不替代判断

1. 先定义数据责任，再谈系统能力

项目成本数据可能分散在财务系统、采购流程、工时记录、合同台账和项目计划中。是否需要整合，取决于数据量、更新频率和跨团队协作复杂度。无论使用电子表格、财务系统还是某项目管理工具，都必须明确谁提供什么数据、何时更新、采用什么口径、谁负责核验。

工具可以帮助汇总不同来源的数据、提醒逾期更新、保存基准版本和显示趋势，但不能判断一次成本上升属于范围变更还是低效率，也不能替项目经理判断历史 CPI 是否适合外推。若数据口径未统一，把更多数据接到一起，只会更快地生成一份看起来完整、实际上互相矛盾的报告。

2. 一个可执行的成本台账字段框架

成本台账不需要一开始就做得复杂，但至少要能支持复核与追踪。以下字段适用于多数项目的基础分析，组织可以根据财务规定、合同形式和项目类型增删。

3. 用异常规则提升可见性，而不是设置一堆没人看的预警

预警阈值应对应管理动作。比如成本偏差超过基准的 5%，不应只触发一封通知，而应要求负责人解释偏差原因；关键采购报价上涨超过合同假设，可能需要重新评估方案；连续两个更新周期 ETC 增加，则应提交风险和资源复核。阈值可以按项目规模、成本波动特征和治理要求设定，不宜照搬统一百分比。

若阈值过低，团队会被大量误报淹没；阈值过高，等问题浮出水面时已没有调整空间。建议先用历史数据回看：按不同阈值触发时，哪些预警最终导致了决策？哪些只是统计噪声？然后调整规则，并明确每种预警需要谁在多长时间内完成判断。

八、不同情况下的取舍：速度、精度、控制力度不能同时无限提高

1. 快速估算还是精细估算

快速估算的优点是响应快，适合立项筛选、方案比较和早期预算讨论；缺点是依赖粗粒度假设，准确度受专家经验和历史数据质量影响。精细估算能提高可追溯性，但需要更多负责人投入，也可能因为过度拆分而增加维护负担。

我的取舍原则是：先对高金额、高不确定性、高风险工作精细化，再对低影响部分保持合理粒度。如果某项工作即使估算误差 20% 也不会改变决策，花大量时间把误差压到 2% 未必值得；如果一项采购合同可能决定项目是否超预算，就应优先核实价格和数量。

2. 公式外推还是自下而上估算

公式外推适合数据质量较好、工作结构相对稳定的项目，更新快、容易比较；它的短板是历史绩效可能不代表未来，阶段差异和一次性事件会污染预测。自下而上估算更适合范围或方案变化显著的情况，但需要业务负责人投入，并可能受到乐观偏差影响。

因此，两者不必非此即彼。对于稳定部分，可用绩效趋势预测；对于变更部分，按新方案自下而上估算；对于高风险部分，额外给出情景区间。汇总时要检查口径和重复计入，不能把某工作包既按 CPI 外推一次，又把相同 ETC 再加一次。

3. 增加控制还是保留团队灵活性

严格审批和频繁审查能降低未经授权的支出，但流程过重会拖慢采购和交付，也可能让团队把精力放在证明“没有超预算”而非识别风险。授权过宽则提高费用失控和事后补审批的概率。适当的控制力度应与金额、风险、不可逆性和组织监管要求匹配。

可按金额和风险设置分级机制：日常、小额、已在基准内的支出由工作负责人处理；超阈值、跨工作包调拨、超出已批范围或涉及合同变更的事项，升级审批。审批不应只判断“有没有钱”，还要判断该支出是否必要、是否存在替代方案，以及它会带来什么交付结果。

4. 单一预测值还是区间预测

单一预测值便于预算管理和决策，但容易让人忽略不确定性；区间预测能表达风险，却可能让执行团队误以为“反正有空间”。对成熟项目，可以将单一基准预测作为主要经营数字，同时展示区间和风险触发条件；对早期项目，应优先表达区间，避免过早承诺精确数值。

无论采用哪种方式，都要统一“预测”与“授权”的含义。预计成本超过预算，不自动等于项目已经获得追加预算；预计成本低于预算，也不意味着余额可随意挪用。预测描述未来判断，预算描述授权边界，两者相关但不能互相替代。

九、结尾：把成本预测做成可检验的判断，而不是月底的解释

1. 独特观点：预测质量取决于能否说清楚“为什么会变”

很多成本报表的问题，不在于缺少指标，而在于数字缺少来历。一个看似准确的 EAC，如果无法解释工作范围、绩效趋势、采购承诺和风险假设，就无法支持决策；一个略有区间的预测，如果能指出哪些变量推动成本变化、哪些证据尚未确认，反而更适合管理。

成本管理预计成本的核心能力，不是把历史外推得更复杂，而是区分什么已经发生、什么已经承诺、什么尚未发生，以及哪些假设可能改变未来。当预测发生变化，团队应当把变化归因到范围、效率、价格、进度或风险，而不是只更新一个总数。

2. 下一步可以从一张预测表开始

如果你正在管理项目，下一次成本例会可以先做五件事：统一统计截止日和成本口径；核对实际成本与采购承诺是否重复；按工作包更新剩余工作估算；对比至少一种趋势预测和一种自下而上预测；记录预测变化的原因、行动责任人和下次复核时间。

如果项目范围仍不稳定，就先表达区间和假设，不要过早承诺一个虚假精确的数。如果项目已经发生持续偏差，就拆解工作包，检查绩效是否可外推。如果关键风险尚未关闭，就把风险情景和触发条件单独呈现。这样，预计成本才不只是告诉团队“可能会超”，而是能够回答“为什么、会超多少、能做什么、何时再判断”。