★ FEATURED ARTICLE 干过集成项目的人都有一个共同的痛老板或甲方问“这个项目现在到底怎么样”你要是只回答“还在推进”“进度正常”对方心里大概率是不信的你也知道自己是在含糊。真正能把话说清楚的状态应该是什么样的是你能直接甩出一句话——“按计划这个月该干完 50 万的活实际干完了 40 万花了 48 万进度落后两成成本超了八个点照这个势头走完全程要 120 万超预算 20 万”。这句话背后的那套算法就是挣值管理。PV、EV、AC、SV、CV、SPI、CPI 这七个字母是系统集成项目管理工程师这类资格认证里的必考内容也是实际项目里最能救命的一套度量工具。它的价值不在于考试拿分而在于把“进度”和“成本”这两件平时各说各话的事情塞进同一个坐标系里做比较。这篇内容适合三类人看正在准备这类资格认证、被公式绕晕的同行刚接手集成项目、想知道怎么向管理层汇报的 PM以及做了几年项目、一直在用感觉判断进度、想换一套硬指标的技术负责人。下面我不打算按教材顺序念公式而是按我自己在项目里用它的顺序把这套东西拆开讲清楚。1. 挣值管理到底解决什么问题——先把思路拆开1.1 传统“看两张报表”为什么会失灵绝大多数团队汇报项目状态时手里其实有两张互不相干的表。一张是进度表写着“需求调研完成 100%开发完成 60%联调未开始”另一张是财务表写着“累计支出 48 万预算 100 万剩余 52 万”。这两张表单独看都没毛病问题出在它们没法互相验证。开发完成 60% 是按什么口径算的是代码行数、功能点数还是负责人拍脑袋估的累计支出 48 万对应的到底是哪些活干完了没人说得清。于是就会出现一种特别典型的场面财务说钱还剩一半多别慌技术负责人说活才干了一小半得加人。两边都没撒谎但拼在一起就是矛盾的。更麻烦的是这种矛盾往往要到项目后期才爆出来——等你发现钱花完了活还没干完能做的只剩下砍范围或者申请追加预算主动权已经完全丢了。挣值管理干的第一件事就是把这两张表强行焊在一起。它要求你把所有的“活”都折算成钱形成一个统一的度量单位。干完了多少活就等于“挣”到了多少钱。这个转换看起来只是个换算实际上是整个方法的地基。1.2 三个基准量PV、EV、AC 各自站在什么位置理解挣值管理先要理解三个量分别代表三种完全不同的视角很多人算错就是因为把它们混成一锅。PVPlanned Value计划值站在“计划”的视角。它回答的问题是截至今天这个检查点按原定基线我们本来应该完成多少价值的工作注意关键词是“截至今天”PV 是一个累计量不是本月量。项目总预算叫 BAC完工预算如果工期 10 个月、预算平均分布那第 5 个月末的 PV 就是 50% 的 BAC。EVEarned Value挣值站在“实际完成”的视角。它回答截至今天我们真正完成了多少价值的工作这个“价值”不是市场售价而是这些工作在原预算里值多少钱。换句话说EV 是把“完工百分比”乘上对应工作的预算得来的。它是整套方法里最主观、最容易注水的一个数后面我会专门讲怎么防注水。ACActual Cost实际成本站在“花钱”的视角。它回答截至今天为了完成这些工作我们实际花掉了多少钱注意 AC 只统计已经发生的支出不统计承诺但未支付的。三个量摆在一起就有了两两比较的可能EV 和 PV 比看的是进度EV 和 AC 比看的是成本。这里有个容易被忽略的细节——两次比较的基准都是 EV。为什么不是 PV 和 AC 直接比因为 PV 和 AC 之间没有任何业务含义一个说“该干多少”一个说“花了多少”比出来的数字解释不了任何事情。只有 EV 这个“实际干成的量”同时出现在两个式子里比较才有意义。1.3 为什么非要用“钱”做统一度量单位这是新人最常问的问题为什么不能直接用“完成的功能点数量”或者“代码行数”来衡量进度非要用钱这么俗的东西原因很实际。一个集成项目里工作内容的异质性太强了。机房改造花了 20 万需求调研花了 5 万两者的工作性质、耗时、人力投入完全不可比。你说“机房改造完成了 60%需求调研完成了 100%”这两个百分比没法相加也没法判断整体到了哪一步。但如果把它们都折算成预算金额机房改造的 60% 就是 12 万需求调研的 100% 就是 5 万加起来 17 万这就成了一个可以比较、可以累加、可以和总预算 100 万对照的数字。钱是这个项目里唯一的“通用语言”。它把不同专业、不同工种、不同阶段的活翻译成了同一个维度上的刻度。这就是为什么挣值管理一定要基于成本基线来算而不是基于工作量。理解了这一层后面所有公式其实都是自然推论。注意用钱做统一度量单位有个前提——预算分解必须细到可以对应到具体可交付成果。如果预算只是一坨总数EV 根本算不出来。这也是为什么 WBS 分解质量直接决定挣值管理能不能用。2. 七个核心指标逐个拆解与计算口径2.1 PV看着最简单其实最容易埋雷PV 的计算公式本身没什么可说的PV 计划完工比例 × 该部分工作的预算。真正的问题在于“计划”这两个字。很多项目的进度计划是用甘特图画出来的横道图上标着每个任务的起止日期但从来没有把预算金额分配到时间轴上。这种情况下你根本算不出某个检查点的 PV因为计划里只有“什么时候做什么”没有“什么时候该值多少钱”。正确做法是做成本基线把每个 WBS 工作包的预算按计划工期分摊到每个月。分摊方式可以是平均分摊也可以按计划投入的人力和资源曲线分摊。分摊完之后每个月的 PV 就是这个月所有工作包应完成金额之和累计起来就是截至该月的 PV。这里有个实操细节值得说PV 一旦基线确定就不应该随便改。除非发生了正式的范围变更并且走了变更流程重新审批基线否则即使项目实际延期了PV 也还是按原来的计划算。很多人一延期就把计划往后推PV 跟着改结果 SPI 永远等于 1指标彻底失效——这是自己骗自己。2.2 EV整套方法的命门也是最容易注水的地方EV 完工百分比 × 该工作的预算BAC 部分。公式一行就写完了但它决定了整套方法的可信度。问题出在“完工百分比”怎么定。我见过太多团队在这里做手脚开发任务计划 20 天干了 15 天负责人报“完成了 75%”。这个 75% 是怎么来的按时间投入估的。这就完全跑偏了——投入了 75% 的时间不代表产出了 75% 的价值。可能在最后 25% 的调试上还要再花一倍时间。更靠谱的做法是把任务拆到足够小然后用明确的度量规则。行业里常见的几种度量规则适用场景优点风险0/100 法工期短、颗粒度细的任务最保守不会虚高长期任务在完工前一直为 0SPI 会很难看50/50 法两周以内的短任务简单报量快任务刚开始就记 50%中期虚高20/80 法中等长度任务比 50/50 保守一些仍是近似百分比完工法长周期、可量化产出的任务反映真实进展主观性最强需要证据支撑里程碑法有明确交付节点的任务与合同付款挂钩客观节点之间无数据我个人的偏好是能拆细就拆细拆到两周以内然后用 0/100 法。虽然完工前 EV 是 0 会让中期报表难看但它的好处是绝对不会骗人。实在拆不开的长任务就用里程碑法把任务切成几个有实物交付的节点每个节点对应一个预算比例比如需求确认 20%、设计评审 30%、编码完成 30%、测试通过 20%节点没过就不给钱。实操心得报 EV 的时候必须附带证据。代码任务看提交记录和评审记录硬件任务看到货单和验收单文档任务看评审签字。没有证据的百分比一律按 0 处理。这条规矩一开始会得罪人但坚持两个月之后报量数据会干净得让你惊讶。2.3 AC口径不统一全盘皆输AC 看起来是三个量里最客观的——花了多少钱账上有数。但实际上集成项目的 AC 是最容易出岔子的。第一个坑是内部人力成本算不算。很多公司只把对外支付的采购款、外包费计入 AC自己员工的人力成本不进项目账。这样做出来的 CPI 会严重失真项目用了大量内部人力这些成本没进 ACCPI 看起来永远是大于 1 的“优秀”。如果公司实行内部人力结算按人天单价内部计价那就必须把这块计入 AC否则指标没有任何意义。第二个坑是时间切面不一致。AC 必须和 EV 在同一个时间点截取。比如每月 25 日盘点那 EV 报的是截至 25 日的完工量AC 也必须是截至 25 日的支出。但实际情况是分包商的发票往往滞后一个月才到采购款可能预付了 30%这些时间差都会让 AC 失真。处理办法是计提发票没到但服务已经发生的按合同金额估算入账让 AC 尽量贴近“已发生的成本”而不是“已付款的金额”。第三个坑是口径混用。预算里含不含税含不含差旅人力单价用的是成本价还是对外报价这些必须在项目启动时写进核算规则里全项目统一执行。我见过一个项目PV 用的是不含税预算AC 用的是含税实付结果 CPI 莫名其妙地一直低于 1查了半个月才发现是税的问题。2.4 SV 与 CV两个绝对偏差差值的业务含义比数字本身重要有了三个基准量两个偏差就很好算了SV进度偏差 EV − PVCV成本偏差 EV − ACSV 大于 0 表示进度提前小于 0 表示落后CV 大于 0 表示成本节约小于 0 表示超支。注意这两个式子里被减数都是 EV减数分别是 PV 和 AC。这个顺序千万别记反考试里挂在这上面的不在少数。但实际工作中光看正负号远远不够。偏差的大小要和项目规模对照着看。一个 1000 万的项目SV −10 万看起来是个大数字实际上只落后了 1%可能只是统计口径误差。而一个 100 万的项目SV −10 万就是落后 10%需要立刻干预。所以偏差值更适合用来做趋势跟踪这周的 SV 是 −5 万上周是 −3 万上上周是 −1 万——恶化速度比绝对值更值得警惕。还有一个常被忽略的点SV 是负的不代表所有工作包都落后。汇总层的 SV 会把各种情况平均掉。有的包超前进度有的包严重落后加总起来可能只是轻微负值看起来很安全实际上风险最大的那个包已经在悬崖边上了。所以 SV 和 CV 一定要拆到 WBS 工作包层级去看汇总数字只能用来向上汇报不能用来做决策。2.5 SPI 与 CPI为什么指数比差值更好用SPI进度绩效指数 EV ÷ PVCPI成本绩效指数 EV ÷ AC这两个指数的好处是归一化。SV −10 万你得知道项目总预算是多少才能判断严重程度而 SPI 0.8直接告诉你“只干了计划的八成”跟项目规模无关横向比较也很方便——A 项目 SPI 0.95B 项目 SPI 0.7谁的进度风险大一眼就看出来。判断标准很简单大于 1 是好事等于 1 是符合计划小于 1 是出问题。但这里有几个陷阱必须提醒。第一个陷阱SPI 和 CPI 在项目极早期不稳定。项目开工第一个月PV 可能只有总预算的 5%EV 稍微有点统计误差SPI 就能从 0.6 跳到 1.2。这时候拿它去做判断纯属自己吓自己。我的建议是项目前 20% 的工期里指数只做参考主要看趋势进入中期20%~80%后指数才具备预测价值。第二个陷阱项目末期指数会自然回归 1。因为 EV 越来越接近 BAC而 PV 在项目结束时也等于 BAC所以 SPI 必然趋近 1同时如果成本已经花得差不多CPI 也会趋近 1。有些团队到了项目末期看到指数“好转”就以为管理见效了其实是数学规律。真正该关心的是项目中期指数最低的那个点那才是真实水平。第三个陷阱指数不能简单平均。多个项目或者多个工作包的 SPI不能取算术平均。假设一个包 SPI 2严重超前另一个包 SPI 0.5严重落后算术平均是 1.25看起来一片大好实际上汇总后的 EV/PV 可能远小于 1。正确做法是先把 EV、PV 分别加总再相除。2.6 一张表把七个指标串起来为了不让公式散落在脑子里我习惯用下面这张表做速查指标全称公式大于 1 / 大于 0小于 1 / 小于 0PV计划值计划完工比例 × BAC——EV挣值实际完工比例 × BAC——AC实际成本实际发生支出累计——SV进度偏差EV − PV进度提前进度落后CV成本偏差EV − AC成本节约成本超支SPI进度绩效指数EV ÷ PV快于计划慢于计划CPI成本绩效指数EV ÷ AC低于预算高于预算记住一个口诀EV 永远是分子或被减数。七个指标里有六个都用到了 EV它是整套体系的轴心。至于 AC 只出现在成本相关的三个式子里PV 只出现在进度相关的三个式子里记住这个归类就不会乱。3. 从七个指标延伸到预测EAC、ETC、VAC、TCPI3.1 为什么光看偏差不够必须做预测SV −10 万这个信息告诉你的只是“现在已经落后了”。但老板真正想知道的不是这个而是“照这样下去最后会怎么样还来不来得及要花多少钱”挣值管理真正值钱的地方就是从已发生的偏差推导完工预测。这部分在教材里往往被压缩成几个公式实际用起来才是核心。3.2 BAC 与 EAC两个“总预算”的区别BAC完工预算是项目启动时批准的原始总预算是 PV 曲线的终点也是固定不动的基准。EAC完工估算是“按目前情况推测项目最终要花多少钱”。它是一个动态量每次盘点都该重算一次。EAC 的算法不止一种选哪种取决于你对“当前偏差会不会持续”的判断这个判断是整个预测环节的关键第一种假设剩余工作将按原预算效率完成非典型偏差EAC AC (BAC − EV)这个算法的含义是已经花掉的钱就是花掉了但剩下的活还能按原计划效率干完。适用的场景是——当前的偏差是一次性的、已经纠正的、不会再发生的。比如某批次设备因为临时调货多花了钱后续不会再出现这种情况用这个算法合理。第二种假设剩余工作将按当前效率继续典型偏差EAC BAC ÷ CPI这个算法的含义是你现在的成本效率水平会一直保持下去。这是最常用、也最保守的一种算法。为什么因为项目的成本效率通常有惯性——如果团队效率、供应商价格、管理方式没变那效率大概率也不会突然变好。管理层最喜欢用第一种算法自我安慰但从业者心里要清楚没有实质改进动作的情况下第二种更接近现实。第三种进度和成本同时影响EAC AC (BAC − EV) ÷ (CPI × SPI)这个算法考虑到一个现实进度落后往往会推高成本加班、赶工、资源价格上浮两者是联动的。当项目既超支又延期时这个算法给出的数字最悲观通常也最接近真相。第四种自下而上重新估算把剩余工作重新拆一遍让每个负责人报 ETC然后 EAC AC ETC。这个最准但最费时。一般用在项目已经严重偏离、前三种算法都不太可信的时候。实操心得汇报的时候不要只给一个 EAC 数字要给三种算法的结果和你的判断。比如“最乐观 108 万按当前效率 120 万考虑进度成本联动 138 万我倾向按 120 万报风险敞口”。给出区间和倾向性判断比给一个精确的假数字更有说服力。3.3 ETC 与 VAC剩余工作与最终差额ETC完工尚需估算 EAC − AC意思是“从现在到结束还需要再花多少钱”。这个数对现金流管理特别关键——很多项目 EAC 算得很漂亮但没算 ETC结果中途现金流断了。VAC完工偏差 BAC − EAC意思是“最终会超支还是节约”。VAC 为正说明有结余为负说明会超支。这个数直接决定了你要不要提前申请预算调整。我一般会在项目中期就把 VAC 报给财务让他们心里有数而不是等到超支发生了才去解释。3.4 TCPI给团队一个现实的“体检报告”TCPI完工尚需绩效指数是我个人觉得最有价值、但教材讲得最少的一个指标。基于 BAC 的算法TCPI (BAC − EV) ÷ (BAC − AC)它的含义是在剩余预算内完成剩余工作未来的成本效率必须达到多少。举个例子BAC 100 万EV 40 万AC 48 万。现在剩余工作价值 60 万剩余预算只有 52 万TCPI 60 ÷ 52 ≈ 1.15。意思是接下来每一块钱的支出必须干出 1.15 块钱的活才能不超总预算。而现在实际的 CPI 只有 0.83。一个 0.83 的效率要突然跳到 1.15中间差了将近 40%。这个差距意味着什么意味着如果不做实质改变缩范围、换供应商、优化方案按原预算完工基本不可能。TCPI 就是用来戳破幻想的那个指标。判断标准TCPI 大于 1 且明显高于当前 CPI说明按原预算完工已不现实必须启动变更或缩范围TCPI 小于等于 1说明还有机会但需要维持甚至提升效率。如果已经决定追加预算到 EAC那就用基于 EAC 的算法TCPI (BAC − EV) ÷ (EAC − AC)用来判断追加后的预算是否现实。4. 完整算例一个集成项目走到第五个月4.1 场景设定与 WBS 分解光讲公式没感觉走一遍完整数据。假设一个系统集成项目总预算 BAC 100 万计划工期 10 个月。WBS 拆成五个工作包预算分配如下工作包预算万元计划周期1.1 硬件采购与到货30第 1~2 月1.2 机房与网络改造24第 1~3 月1.3 应用系统开发26第 2~7 月1.4 集成联调12第 7~9 月1.5 培训与验收8第 9~10 月合计100—现在是第 5 个月末做一次挣值盘点。4.2 逐项计算与汇总各工作包的数据单位万元工作包PVEVACSVCVSPICPI1.1 硬件采购3030330−31.000.911.2 机房改造1067−4−10.600.861.3 应用开发846.5−4−2.50.500.621.4 集成联调201.5−2−1.5001.5 培训验收00000——汇总504048−10−80.800.833几个数字的来源说明一下。1.2 机房改造计划第 3 个月完工到第 5 个月末 PV 应该是全额 24 万不对——这里要看基线怎么排的。如果第 3 个月就该完工那到 5 月末 PV 应当是 24。但上表写的是 10说明这个包的基线在变更后被调整过或者原本就计划分批交付。为了演示清晰这里假设 1.2 的实际基线是在第 1~5 月分摊 20 万另外 4 万留给后续扩容所以 5 月末 PV 10 万。这类“预算分配到时间轴”的细节必须在基线里写清楚否则 PV 会算得五花八门。汇总层的结果PV 50EV 40AC 48于是 SV −10CV −8SPI 0.80CPI ≈ 0.833。4.3 结果解读拆开看才知道问题在哪如果只看汇总结论是“进度落后 20%成本超支 8 万”然后呢没法下手。拆到工作包层级故事就清楚了。硬件采购SV 0进度完全达标CV −3超支 3 万。这个超支大概率是价格因素汇率、临时调货、加急运费属于一次性偏差后续不会持续。处理方式是和采购确认超支原因如果是市场因素走变更流程调整这个包的预算别让它一直拖着整个项目的 CPI。机房改造SPI 0.60是全项目进度最差的包之一。这个包通常是外包给施工方的进度落后八成是施工方人力不足或者现场条件不具备。CV −1 说明还小有超支属于“又慢又费钱”必须立刻约谈施工方看是加人还是调整工序。应用开发SPI 0.50CPI 0.62这是全项目最危险的地方。开发进度只到计划的一半成本却已经花了计划的八成。这个组合说明什么说明投入的人力不少但产出效率极低——可能是需求反复变更、技术方案卡壳、或者团队能力不匹配。这里必须做根因分析光加人没用加了人只会让 CPI 更难看。集成联调PV 2EV 0AC 1.5。活还没开始干钱先花了 1.5 万。这通常是测试环境搭建、联调准备的前置投入。本身不算异常但要盯住——如果第 7 个月联调正式开始时这 1.5 万没有被合理归集EV 会算不准。有了这个拆解行动清单就出来了硬件走变更调预算机房约谈施工方开发做根因分析并考虑缩范围或换方案联调盯紧前置投入的归集。这比“进度落后、成本超支”这种汇报有用一百倍。4.4 预测走到终点会是什么样按三种算法算 EAC非典型偏差EAC 48 (100 − 40) 108 万典型偏差EAC 100 ÷ 0.833 ≈ 120 万进度成本联动EAC 48 60 ÷ (0.833 × 0.80) 48 90 138 万ETC按典型偏差 120 − 48 72 万也就是剩下 5 个月还要再花 72 万平均每月 14.4 万而前 5 个月平均每月只花了 9.6 万。这个现金流缺口必须提前跟财务打招呼。VAC 100 − 120 −20 万超支 20 万。TCPI (100 − 40) ÷ (100 − 48) 60 ÷ 52 ≈ 1.154。当前 CPI 是 0.833要跳到 1.154提升幅度 38%。这个数字摆出来任何有经验的 PM 都会承认按原预算完工不现实必须动范围或者动预算。5. 落地实施怎么让这套东西在项目里真正跑起来5.1 度量规则要先定不能边干边议挣值管理落地失败的头号原因不是公式算错而是度量规则没定清楚导致每个人报的 EV 口径不一样。项目启动会上就应该把这几件事定下来每个 WBS 工作包用哪种度量方法0/100、里程碑法还是百分比法百分比法需要什么证据支撑谁有权确认完工比例盘点周期是周还是月。这些规则一旦定下来写进项目管理计划全项目统一执行中途不轻易改。我见过一个项目开发组按功能点报进度测试组按用例执行率报进度实施组按人天报进度三套口径汇总出来的 EV谁也解释不了。返工重定规则花了整整两周等于白白损失了半个月的进度。5.2 数据采集的节奏和责任人挣值盘点是件体力活必须固定节奏、固定责任人否则很容易变成“想起来才算一次”。我一般这样安排每周五下午各工作包负责人提交本周完工量和证据每周一上午项目经理汇总 EV财务或项目助理同步 AC每月末做一次完整盘点出正式报告。周度盘点只算总量不做详细分析月度盘点才拆到工作包层级做偏差分析。AC 的采集要特别注意同步。财务的账期和项目的盘点周期往往对不上解决办法是让项目助理维护一份“项目支出台账”把已付款、已发生未付款、已承诺未发生三类分开记录每周更新。月末盘点时AC 取“已付款 已发生未付款”已承诺未发生的单独列示作为风险提示。注意不要让一个人同时负责报 EV 和审 EV。自己报自己审注水是必然的。至少要有一道交叉验证——技术负责人报量项目经理审核关键节点还要有第三方质量或 PMO抽查。5.3 和变更控制的联动这是最容易被忽略的一环挣值管理有一套隐含假设PV 的基线是稳定的。但集成项目的范围变更太频繁了如果变更了却不更新基线PV 就会失真。举个典型场景客户临时追加了一个子系统工作量增加 15 万团队加班干完了。这时候如果基线没更新PV 还是原来的 100 万EV 却因为多干了活变成了 115 万假设全部完成SPI 显示 1.15一片大好。但实际上团队是被迫增加了工作量成本也相应上升AC 可能到了 125 万CPI 是 0.92。真实的绩效是超支的报表上却看不出问题。正确做法是每一次批准的范围变更都要同步更新 BAC、PV 曲线和成本基线并且留下版本记录。变更后的新基线要重新发布给所有干系人让大家对着同一个版本算指标。没有这一步挣值管理就是空中楼阁。6. 常见问题与排查实录6.1 EV 虚高的四种典型表现EV 注水是这套方法最大的敌人而且往往不是故意的是认知偏差。我总结了几种高频表现第一种把投入当产出。任务计划 20 天干了 15 天报 75%。这是最常见的错误本质是把“花了多少时间”等同于“完成了多少价值”。识别方法很简单看有没有可验证的中间交付物。没有交付物一律不认。第二种把“快完成了”当成“完成了”。开发任务报 90%然后这个 90% 保持了三周不动。这种情况说明最后 10% 的难度被严重低估实际可能只完成了 70%。识别方法跟踪 EV 的增长曲线如果某个包的 EV 长期停滞在某个百分比就要怀疑。第三种末位冲刺式补报。前几周 EV 几乎不动最后一周突然从 30% 跳到 100%。如果交付物确实完整那没问题如果是为了赶盘点节点硬报的就是注水。识别方法抽查交付物的完成质量。第四种把准备工作算进完成度。环境搭好了、文档框架写好了就报 30%。准备工作确实是工作但它在总预算里的占比通常很小不该占那么大权重。6.2 常见问题速查表现象可能原因排查方向处理建议SPI 长期等于 1纹丝不动PV 基线随实际进度同步调整了查基线变更记录冻结基线只走正式变更流程CPI 一直大于 1好得不真实内部人力成本未计入 AC核对成本核算范围补齐内部结算口径汇总层指标正常个别包严重异常汇总平均掩盖了局部问题拆到 WBS 包层级看建立包级预警阈值EV 增长呈阶梯状跳变采用里程碑法但节点设置过少检查度量规则增加中间节点项目末期 SPI/CPI 突然变好EV 接近 BAC 的自然回归看中期最低点别用末期数据评价管理效果EAC 每次算出来都不一样且波动大选用的算法不固定统一算法选择规则明确什么情况下用哪种算法现金流中断但 EAC 显示正常只算了 EAC没算 ETC补算 ETC 并按月分解做现金流预测表6.3 几个踩过的坑都是真金白银换的坑一指标好看就放松了现场管理。有个项目中期 SPI 一直维持在 1.05 左右管理层很放心结果第 8 个月联调阶段突然崩盘原因是前面几个包都是按“代码写完”报的完成实际联调时发现接口对不上返工量巨大。教训是EV 的度量必须包含“可集成”这个标准写完不等于完成通过联调才算。集成类项目的度量规则一定要把集成验证纳入完工定义。坑二把 SPI 当成真实进度。SPI 是用成本口径算的进度它衡量的是“值多少钱的活干完了”不是“关键路径走到哪了”。一个项目可能 SPI 1.1但关键路径上的某个设备到货延迟了两周整体交付照样延期。所以 SPI 必须和关键路径分析结合看两者不一致时以关键路径为准。坑三多个项目简单汇总。同时管三个项目各自 SPI 是 0.9、1.2、0.7取平均 0.93 汇报这个数字没有任何意义。因为三个项目的预算规模不同权重不同。正确做法是按预算加权或者干脆分别汇报。汇总指标只在你需要向上给一个总数时用做决策必须回到单个项目。坑四忘了挣值管理不衡量质量和范围。EV 报 100%但交付物质量不合格返工成本会全部落在后续阶段这时候 EV 是完全失真的。所以在挣值盘点的同时必须同步看质量指标缺陷密度、一次通过率和范围指标变更数量、需求覆盖率。三张表一起看才能形成完整判断。最后分享一个我在实际项目里养成的习惯每次月度盘点除了算指标我都会单独写一段“这个月最让我不安的一个数字”。有时候是某个包的 CPI 掉到了 0.6有时候是 TCPI 跳到了 1.3有时候是 AC 里突然出现一笔说不清来源的支出。这段话不写进正式报告只留给自己看用来对抗“报表一片祥和”的自我麻痹。做了几年下来真正出问题的项目往往在指标还很漂亮的时候就已经在那段话里露出苗头了。
阅读完成 · 觉得有帮助？
