IT和軟體專案的EVM
將實獲值管理應用於IT和軟體專案，比將其應用於建築專案更具挑戰性，也更加微妙。軟體工作是抽象的，需求可能在專案中期發生變化，並且衡量一個功能的“完成百分比”本質上是主觀的。然而，只要進行適當的調整，EVM就能為IT專案組合管理以及向非技術利害關係人傳達預算和時程狀態提供巨大的價值。
核心挑戰：衡量軟體專案中的實獲值
在建築專案中，你可以衡量物理進度（澆築了多少立方公尺，鋪設了多少公尺）。而在軟體專案中，你衡量的是不可見的工作。以下是三種最常見的方法：
1. 故事點 (敏捷EVM)
在Scrum或看板環境中，團隊使用故事點 (Story Points) 來估算工作量。你可以在此基礎上建立EVM：
- BAC = 總故事點數 × 每個故事點的平均成本
- PV = 計劃在目前衝刺 (Sprint) 完成的故事點數
- EV = 實際完成的故事點數 × 每個故事點的平均成本
- AC = 該期間的實際團隊成本（薪資、基礎設施、許可證等）
這種方法僅在故事符合團隊的“完成定義 (Definition of Done)”時才記為已完成——這可以防止“完成90%”的陷阱。
2. 基於里程碑的EVM (瀑布模型)
對於瀑布式或階段關卡式專案，為里程碑分配預算權重（例如，需求=15%，設計=20%，開發=40%，測試=20%，部署=5%）。只有當每個里程碑完全完成並被驗收時，才計入實獲值。
3. 加權工作包法
將軟體分解為功能模組（認證、報告、API、使用者介面）。估算每個模組的成本和工期。在模組級別追蹤完成情況。這最傳統的EVM方法，適用於固定價格的IT合約。
實際案例：軟體開發專案
一個客製化CRM開發專案：BAC = $400,000，共8個衝刺（16週）。在第4個衝刺（第8週）時：
- 總故事點數：800。每個故事點的平均成本：$500。
- 計劃到第4個衝刺完成的故事點：400。PV = 400 × $500 = $200,000
- 實際完成的故事點：320。EV = 320 × $500 = $160,000
- 實際成本（團隊薪資+基礎設施）：AC = $195,000
CPI = EV ÷ AC = 160,000 ÷ 195,000 = 0.821（成本超支18%）
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800（時程落後20%）
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800（時程落後20%）
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
EVM與敏捷：常見的反對意見
| 反對意見 | 回應 |
|---|---|
| “敏捷沒有固定的範圍” | EVM可以處理帶有優先級的待辦清單——BAC代表商定的發布範圍，而不是整個產品待辦清單 |
| “每個衝刺的需求都在變” | 使用變更控制流程。核准的範圍變更會更新BAC。計劃外的變更需要調查偏差。 |
| “故事點速度 (Velocity) 更有用” | 速度對團隊很有幫助；而EVM則提供了發起人和高管所需的財務視角。 |
| “我們不提前進行估算” | EVM需要一個基準。如果估算尺度一致，即使是相對估算的故事也能構成基準。 |
給IT專案經理的實用建議
- 在衝刺前設定BAC，而不是之後：基準必須穩定，EVM才有意義。
- 對於進行中的故事，只計算0%或100%：避免計算部分進度；這會誇大EV並掩蓋時程風險。
- 每週追蹤CPI趨勢：軟體專案進展迅速。每月的EVM報告可能發現問題太晚。
- 將基礎設施/維運與開發的BAC分開：基礎設施成本有不同的成本驅動因素，應單獨追蹤。
- 在計畫 (Program) 級別使用EVM：如果你有多個敏捷團隊，請在計畫級別彙總他們的EV/AC資料，以便向高管報告。