專案監控是在專案執行過程中，持續追蹤進度、成本、品質等關鍵指標，並根據數據分析結果即時調整計畫的管理活動。 本文完整教學 5 步驟標準流程、EVM 實際計算範例、12 項 KPI 健康值對照表，附 6 大工具比較與 3 個產業導入案例。
專案監控是什麼？定義與核心概念
專案監控的定義
專案監控（Project Monitoring）是指在專案執行期間，系統化地收集、分析與報告專案績效數據，並將實際成果與基準計畫進行比對，以便在偏差擴大前採取矯正行動。簡單來說，監控就是讓專案經理「隨時知道專案走到哪裡、偏了多少、該怎麼修正」。
它不是一次性的檢查，而是貫穿整個專案生命週期的持續活動——從第一個任務開始執行的那一天，到專案正式收尾為止。
監控（Monitoring）、監督（Supervision）、控制（Control）三者差異
這三個詞在中文語境中經常混用，但在專案管理領域有明確區分：
| 項目 | 監控（Monitoring） | 監督（Supervision） | 控制（Control） |
|---|---|---|---|
| 焦點 | 數據與指標 | 人員行為與紀律 | 計畫調整與矯正 |
| 核心動作 | 追蹤、收集、分析 | 觀察、指導、糾正 | 調整、變更、矯正 |
| 主要產出 | 績效報告、偏差分析 | 行為回饋、績效評估 | 變更請求、矯正行動 |
| 對象 | 進度、成本、品質等指標 | 團隊成員的工作方式 | 專案計畫與基準線 |
| 時機 | 持續進行 | 日常管理 | 偏差發生時 |
實務上，監控與專案控制是一體兩面：監控負責「發現問題」，控制負責「解決問題」。PMBOK 將兩者合併為「監視與控制流程群組」（Monitoring & Controlling Process Group），正是因為它們密不可分。
專案監控在 PMBOK 流程群組中的位置
在 PMBOK 的五大流程群組中，監視與控制是唯一橫跨整個專案生命週期的流程群組。它不像啟動、規劃、執行、收尾那樣有明確的起止點，而是從專案啟動後就持續運作，直到收尾完成。
具體來說，監視與控制流程群組包含以下子流程：
- 監控專案工作：整體績效追蹤
- 整合變更控制：審核與管理變更請求
- 確認範疇 / 控制範疇：確保交付物符合需求
- 控制時程：追蹤進度偏差
- 控制成本：追蹤預算執行
- 控制品質：驗證交付物品質
- 監控風險：追蹤已識別風險、識別新風險
這些子流程的輸入來自規劃階段的基準線（範疇基準、時程基準、成本基準），輸出則回饋到執行階段進行調整。這就是為什麼專案管理流程不是線性的——監控讓整個流程形成閉環。
三種監控方法：遠端、面對面、協同
根據團隊的工作型態，專案監控可以採用不同的執行方法，各有適用情境與限制：
| 監控方法 | 適用情境 | 優點 | 缺點 |
|---|---|---|---|
| 遠端監控 | 分散式團隊、跨國專案 | 不受地點限制、可透過工具即時追蹤 | 溝通延遲、難以察覺非語言訊號 |
| 面對面監控 | 同地點團隊、高風險階段 | 溝通效率高、問題能當場釐清 | 需要所有人同時在場、耗時 |
| 協同監控 | 混合工作模式、跨部門專案 | 結合遠端與面對面優點、彈性高 | 需要明確的溝通規範、工具整合要求高 |
實務上，多數團隊會混合使用：日常透過工具進行遠端監控，關鍵里程碑或問題升級時安排面對面會議，形成協同監控模式。選擇哪種方法不是重點，重點是確保監控的頻率和深度符合專案需求。
為什麼專案監控至關重要？
即時發現問題，避免小偏差變成大災難。 一個 IT 軟體開發專案，如果測試階段落後 3 天沒被發現，到了整合測試時可能變成 2 週的延誤——因為後續任務都有依賴關係。每週監控一次進度，就能在 3 天偏差時介入，而不是等到 2 週後才驚覺。
數據驅動決策，取代「感覺還好」的主觀判斷。 製造業的新產品開發專案中，PM 問團隊「進度如何？」得到的回答通常是「差不多」。但當你用 SPI（進度績效指數）算出 0.85，團隊就能清楚看到「我們落後了 15%」，討論的焦點從「有沒有問題」轉移到「怎麼解決問題」。
提升交付率，降低專案失敗風險。 根據 PMI 的 Pulse of the Profession 報告，有成熟監控機制的組織，專案如期交付率比沒有的高出 28%。對行銷活動專案來說，活動日期不能延後——錯過檔期就等於失敗。
增強利害關係人信心，減少不必要的干預。 當你能在每週例會上拿出清晰的進度報告，客戶和高層的焦慮感會大幅降低。反之，如果他們問「現在進度如何？」你只能回答「我確認一下」，信任就會一點一點流失。
未做監控的典型代價有多大？ 假設一個為期 6 個月、預算 NT$600 萬的專案，進度延誤 2 週意味著：額外人力成本約 NT$30-50 萬（以 10 人團隊計算）、可能的違約罰款、團隊士氣下降導致的連鎖效應。而建立基本的監控機制，每週只需要 PM 投入 2-3 小時。這筆帳怎麼算都划算。
我們團隊在管理自己的內容專案時，就是用 monday.com 的儀表板即時追蹤每週的產出進度。PM 設定了一條自動化規則：任務延遲超過 2 天自動通知負責人和 PM。這個設定在過去半年觸發了超過 20 次，每次都讓問題在擴大前被處理——以前要到週會才發現，現在當天就能介入。
專案監控標準流程：5 個步驟
這 5 個步驟對應 PDCA 循環中的 Check（檢查）與 Act（行動）階段——監控活動本質上就是「檢查實際績效是否符合計畫」（Check），並在發現偏差時「採取矯正行動」（Act）。這個對應關係也與 PMBOK 的監視與控制流程群組完全吻合。不論你的專案規模大小，這個框架都適用——差別只在執行的深度和頻率。
步驟一：設定監控指標
監控的第一步不是「開始追蹤」，而是先定義「追蹤什麼」。沒有明確指標的監控，就像沒有目的地的導航——你會收集一堆數據，但不知道該看哪裡。
指標設定應遵循 SMART 原則：
- Specific（具體）：不是「追蹤進度」，而是「追蹤 SPI 值」
- Measurable（可衡量）：SPI 目標值 ≥ 0.9
- Achievable（可達成）：基於歷史數據設定合理門檻
- Relevant（相關）：指標必須與專案目標直接相關
- Time-bound（有時限）：每週五下午 5 點前更新數據
一個中型專案追蹤 3-5 個核心指標就夠了。優先選擇 SPI（進度）、CPI（成本）、缺陷率（品質）這三個最關鍵的指標，等團隊熟悉監控節奏後再逐步擴充。
步驟二：數據收集
數據收集的頻率取決於專案規模和風險程度：
| 團隊規模 | 建議頻率 | 收集方式 |
|---|---|---|
| 5 人以下 | 每週一次 | 週一早上 15 分鐘站會 + 工具自動更新 |
| 5-20 人 | 每週一次書面 + 每日站會 | 每日 15 分鐘站會 + 每週五書面報告 |
| 20 人以上 | 每日站會 + 每週書面 + 每月正式報告 | 分組站會 + 週報 + 月度績效報告 |
常見錯誤：只收集「完成/未完成」的二元數據。 這種數據無法告訴你「還差多少」。更好的做法是收集完成百分比、已投入工時、剩餘工時估算，這樣才能計算 EVM 指標。
在 monday.com 上，你可以設定每個任務的「進度」欄位，團隊成員直接更新百分比，儀表板會自動彙總——不需要 PM 手動整理 Excel。
步驟三：數據分析
收集到數據後，關鍵是進行差異分析（Variance Analysis）：將實際績效與基準計畫比對，找出偏差的大小、方向和原因。
最常用的分析方法是 EVM（實獲值管理），我們會在下一個章節詳細說明計算方式。這裡先掌握分析的核心邏輯：
- 計算偏差：實際值 vs. 計畫值的差距（例如 SPI = 0.85，代表進度落後 15%）
- 判斷嚴重程度：對照預設的健康值門檻（SPI < 0.9 進入警示區）
- 追溯根因：偏差來自哪個任務？是資源不足、需求變更、還是估算錯誤？
- 預測趨勢：如果不介入，最終會偏差多少？
常見錯誤：僅收集數據但未分析。 很多團隊每週都在更新進度表，但從來沒有人坐下來看「這些數字代表什麼」。數據本身沒有價值，分析後的洞察才有。
步驟四：監控報告與溝通
監控報告是將分析結果轉化為行動的橋樑。一份有效的監控報告應包含以下欄位：
| 報告欄位 | 內容說明 | 範例 |
|---|---|---|
| 報告日期 | 本次報告涵蓋的時間範圍 | 第 8 週（3/17-3/21） |
| 整體狀態 | 紅/黃/綠燈號 | 🟡 黃燈（需關注） |
| 進度摘要 | SPI 值 + 一句話說明 | SPI = 0.88，落後 12%，主因：UI 設計延遲 |
| 成本摘要 | CPI 值 + 一句話說明 | CPI = 0.95，輕微超支 5% |
| 本週完成 | 已完成的關鍵任務 | 完成後端 API 開發（3/5 模組） |
| 下週計畫 | 預計完成的任務 | 完成剩餘 2 個 API 模組 + 開始前端整合 |
| 風險與議題 | 需要關注或升級的項目 | 第三方 API 回應時間過長，可能影響整合測試 |
| 矯正行動 | 已採取或建議的行動 | 增派 1 名前端工程師支援 UI 設計 |
（推薦試試 ClickUp 的專案狀態報告模板，內建上述欄位結構，填入數據就能自動產出格式化報告。）
步驟五：調整與矯正行動
分析出偏差後，PM 需要判斷：這個問題我能自己處理，還是需要升級？
可自行調整的情況：
- 偏差在 10% 以內
- 不影響關鍵路徑
- 可透過重新分配現有資源解決
- 例如：將非關鍵任務延後一週，把人力調到落後的任務上
需要升級的情況：
- 偏差超過 15%
- 影響關鍵路徑或里程碑
- 需要額外預算或人力
- 需要變更專案範疇
- 例如：SPI 持續低於 0.8 超過兩週，需要向專案發起人報告並請求增加資源
常見錯誤：發現問題後只記錄不行動。 監控的價值在於「及時矯正」，如果每次報告都寫「進度落後」但沒有對應的矯正行動，監控就流於形式。每個偏差都應該有一個對應的行動項目、負責人和完成期限。
專案監控三大面向：進度、成本、品質（含風險）
進度監控
進度監控是最基本也最常被執行的監控面向。核心工具是甘特圖和 EVM 進度指標。
甘特圖監控的三個關鍵設定：
- 基準線（Baseline）：在專案計畫核定後，儲存一份「原始計畫」作為比對基準。沒有基準線，你就無法判斷「現在是超前還是落後」。
- 實際完成標記：每個任務除了計畫的開始/結束日期，還要標記實際的開始/結束日期。兩者的差距就是進度偏差。
- 關鍵路徑識別：標示出關鍵路徑上的任務——這些任務的任何延遲都會直接導致專案延期。監控時優先關注關鍵路徑。
在 monday.com 的甘特圖中，你可以一鍵設定基準線，系統會自動用灰色線條顯示原始計畫，彩色線條顯示實際進度，偏差一目了然。
S Curve 進度追蹤方法：
S 曲線是另一個強大的進度視覺化工具。它以時間為 X 軸、累計完成量（或累計成本）為 Y 軸，畫出計畫值（PV）和實獲值（EV）兩條曲線。當 EV 曲線低於 PV 曲線，代表進度落後；兩條曲線的垂直距離越大，落後越嚴重。更詳細的 S 曲線製作方法，可以參考我們的 S Curve 專題教學。
EVM 進度指標：SPI 計算範例
SPI（Schedule Performance Index，進度績效指數）= EV ÷ PV
假設一個為期 6 個月的軟體開發專案，到了第 3 個月底：
- PV（計畫值）= NT$150 萬（按計畫應完成的工作價值）
- EV（實獲值）= NT$120 萬（實際完成的工作價值）
- SPI = 120 ÷ 150 = 0.80
SPI = 0.80 代表：每投入 1 元的計畫時間，只完成了 0.8 元的工作。換句話說，進度落後 20%。如果不介入，這個專案很可能無法如期交付。
成本監控
成本監控確保專案不會超出預算，核心工具同樣是 EVM。
EVM 成本指標：CPI 計算範例
CPI（Cost Performance Index，成本績效指數）= EV ÷ AC
延續上面的例子，到了第 3 個月底：
- EV（實獲值）= NT$120 萬
- AC（實際成本）= NT$130 萬（實際花費的金額）
- CPI = 120 ÷ 130 = 0.92
CPI = 0.92 代表：每花 1 元，只產出了 0.92 元的價值。成本超支約 8%。
成本預測公式：EAC = BAC ÷ CPI
如果這個專案的總預算（BAC）是 NT$300 萬：
- EAC（完工估算）= 300 ÷ 0.92 = NT$326 萬
- 預計超支 NT$26 萬
這個數字讓 PM 可以提前向管理層報告：「按照目前的成本效率，我們預計會超支 NT$26 萬，建議採取以下矯正措施⋯⋯」
建築工程每月 EVM 檢視案例：
某營造公司執行一棟商辦大樓的結構工程，總預算 NT$8,000 萬，工期 18 個月。到了第 6 個月的月度 EVM 檢視：
- PV = NT$2,800 萬（計畫完成 35%）
- EV = NT$2,400 萬（實際完成 30%）
- AC = NT$2,600 萬（實際花費）
- SPI = 2,400 ÷ 2,800 = 0.86（進度落後 14%）
- CPI = 2,400 ÷ 2,600 = 0.92（超支 8%）
- EAC = 8,000 ÷ 0.92 = NT$8,696 萬（預計超支 NT$696 萬）
PM 在月度報告中提出矯正方案：增加一組鋼筋綁紮班底（加速進度），同時與供應商重新議價鋼材（控制成本）。兩個月後，SPI 回升至 0.94，CPI 回升至 0.97。
品質監控
品質監控確保專案交付物符合預定標準，而不是等到最後才發現問題。
定期檢查與測試的頻率建議：
| 專案類型 | 檢查頻率 | 檢查方式 |
|---|---|---|
| 軟體開發 | 每個 Sprint 結束（通常 2 週） | Sprint Review + 自動化測試報告 |
| 製造業 | 每批次抽驗 + 每週品質會議 | 抽樣檢驗 + SPC 統計製程管制 |
| 行銷活動 | 每個里程碑 | 內容審核 + A/B 測試結果檢視 |
| 建築工程 | 每個工序完成時 | 現場查驗 + 材料試驗報告 |
缺陷率 KPI 設定範例：
- 軟體開發：每千行程式碼的缺陷數（Defect Density）≤ 5
- 製造業：批次不良率 ≤ 2%
- 行銷內容：客戶修改次數 ≤ 2 次/件
常見錯誤：僅在收尾階段檢查品質。 這是最昂貴的錯誤之一。軟體開發中，在編碼階段發現的 bug 修復成本是 1x，到了整合測試階段是 10x，到了上線後是 100x。品質監控必須從第一個交付物產出就開始。
風險監控
風險監控是 PMBOK 監視與控制流程群組中的重要子流程，但在實務中經常被忽略。它的核心是：持續追蹤已識別的風險、識別新風險、評估風險應對策略的有效性。
風險登錄表的定期更新頻率：
- 高風險專案（如新技術導入、跨國專案）：每週更新
- 中風險專案（如一般 IT 開發、產品改版）：每兩週更新
- 低風險專案（如例行性維護、小型行銷活動）：每月更新
風險觸發指標（Risk Trigger）的設定方式：
每個已識別的風險都應該設定一個「觸發指標」——當這個指標出現時，代表風險即將發生或已經發生。
例如：
- 風險：關鍵供應商交貨延遲
- 觸發指標：供應商連續兩次未在約定日期回覆確認信
- 應對行動：啟動備選供應商聯繫流程
更完整的專案風險管理方法論，包含風險識別、評估與應對策略，可以參考我們的專題文章。
專案監控 KPI 與指標設定
知道「要監控什麼」之後，下一個問題是：「指標的數字要多少才算健康？」以下是按面向分類的 KPI 清單，每個指標都附上健康值參考範圍。
進度類 KPI
| KPI 名稱 | 計算方式 | 🟢 正常 | 🟡 警示 | 🔴 需立即介入 |
|---|---|---|---|---|
| SPI（進度績效指數） | EV ÷ PV | ≥ 0.95 | 0.85-0.94 | < 0.85 |
| 里程碑達成率 | 已達成里程碑 ÷ 應達成里程碑 × 100% | ≥ 90% | 70-89% | < 70% |
| 任務準時完成率 | 準時完成任務數 ÷ 總任務數 × 100% | ≥ 85% | 70-84% | < 70% |
成本類 KPI
| KPI 名稱 | 計算方式 | 🟢 正常 | 🟡 警示 | 🔴 需立即介入 |
|---|---|---|---|---|
| CPI（成本績效指數） | EV ÷ AC | ≥ 0.95 | 0.85-0.94 | < 0.85 |
| 預算使用率 | AC ÷ BAC × 100%（對照進度百分比） | 與進度同步 | 超前進度 5-10% | 超前進度 > 10% |
| 成本偏差（CV） | EV – AC | ≥ 0 | -5% ~ 0 | < -5% |
品質類 KPI
| KPI 名稱 | 計算方式 | 🟢 正常 | 🟡 警示 | 🔴 需立即介入 |
|---|---|---|---|---|
| 缺陷率 | 缺陷數 ÷ 交付物數量 | ≤ 2% | 2-5% | > 5% |
| 客戶滿意度 | 問卷平均分（1-5 分） | ≥ 4.0 | 3.0-3.9 | < 3.0 |
| 返工率 | 需返工任務數 ÷ 總任務數 × 100% | ≤ 5% | 5-10% | > 10% |
實務建議： 不要一開始就追蹤所有 12 個 KPI。建議先從 SPI、CPI、任務準時完成率這三個開始，等團隊熟悉監控節奏後，再逐步加入品質和風險指標。你可以用 monday.com 的儀表板建立一個「專案健康度看板」，把這三個核心 KPI 用數字小工具（Number Widget）呈現，每次打開就能一眼看到紅黃綠燈號。
專案監控工具比較與推薦
選對工具可以讓監控效率提升數倍。以下是六款主流專案管理軟體的監控功能比較，價格以新台幣計算。
| 項目 | monday.com | ClickUp | Notion | Asana | Jira | MS Project |
|---|---|---|---|---|---|---|
| 核心監控功能 | 儀表板、甘特圖、自動化提醒、工作負載視圖 | 儀表板、甘特圖、時間追蹤、自訂欄位 | 時間軸視圖、資料庫、公式欄位 | 時間軸、里程碑、工作負載 | 燃盡圖、Sprint 報告、看板 | 甘特圖、EVM、關鍵路徑、資源平衡 |
| 免費方案 | ✅ 最多 2 人 | ✅ 功能完整 | ✅ 個人使用 | ✅ 最多 10 人 | ✅ 最多 10 人 | ❌ 無免費版 |
| 付費起價 | 約 NT$270/人/月 | 約 NT$220/人/月 | 約 NT$260/人/月 | 約 NT$330/人/月 | 約 NT$250/人/月 | 約 NT$300/人/月 |
| 最適團隊規模 | 5-200 人 | 5-100 人 | 1-15 人 | 5-50 人 | 5-500 人（軟體團隊） | 10-500 人（工程團隊） |
| 最適專案類型 | 各類型，特別適合跨部門協作 | 複雜專案、技術團隊 | 知識型、內容型專案 | 行銷、營運專案 | 軟體開發（Scrum/Kanban） | 大型工程、建築、製造 |
| 自動化提醒 | ✅ 強大（無程式碼） | ✅ 強大 | ⚠️ 需搭配第三方 | ✅ 基本 | ✅ 需設定規則 | ⚠️ 有限 |
| 開始使用 | 免費試用 → | 免費試用 → | 免費試用 → | 免費試用 → | 免費試用 → | 需購買授權 |
文件流程與郵件監控工具
除了上述專案管理平台，某些專案類型還需要搭配文件流程或郵件管理工具：
- pdfFiller：適合需要大量電子簽核的專案（如合約審批、採購流程），可追蹤文件簽署進度，確保簽核流程不卡關。
- SignNow：專注合約與文件的電子簽署與流程追蹤，適合需要監控合約簽回狀態的專案（如工程發包、供應商管理）。
- Sanebox：郵件智慧分類與追蹤工具，適合郵件密集型專案（如客戶服務專案、多供應商協調），可自動標記未回覆的重要郵件，避免溝通遺漏。
不同規模團隊的工具推薦邏輯
5 人以下小型團隊：先用免費工具建立習慣
如果你的團隊剛開始接觸系統化的專案監控，不需要一開始就投入付費工具。Notion 免費版的資料庫功能可以建立基本的任務追蹤表，搭配公式欄位計算完成率。或者用 ClickUp 免費版，它的免費方案功能相當完整，包含甘特圖和基本的儀表板。
限制： Notion 缺乏自動化提醒，需要 PM 手動追蹤；ClickUp 免費版的儀表板只能建立有限數量。
5-20 人中型團隊：monday.com 是我們的首選
這個規模的團隊最需要的是：跨部門可視化、自動化提醒、以及不需要技術背景就能上手的介面。monday.com 在這三點上都表現出色。我們自己的團隊就是用它管理日常工作——從內容排程到跨部門協作，儀表板讓每個人都能看到整體進度，自動化規則幫 PM 省下大量追蹤時間。
付費方案約 NT$270/人/月起，以 10 人團隊計算，每月 NT$2,700 的投入，換來的是每週省下 PM 3-5 小時的手動追蹤時間。
技術團隊跑 Scrum：ClickUp 或 Jira
如果你的團隊以軟體開發為主，跑 Scrum 或 Kanban，ClickUp 的 Sprint 管理和時間追蹤功能會更貼合需求。Jira 則是大型軟體團隊的業界標準，特別適合需要與 DevOps 工具鏈整合的場景。
20 人以上大型團隊：monday.com 企業版或 MS Project
大型專案需要更精細的權限控制、跨專案資源管理和進階報表。monday.com 企業版提供企業級安全性和專屬客戶經理；MS Project 則適合需要 EVM 原生支援和關鍵路徑法（CPM）計算的大型工程專案。
Excel 甘特圖監控：預算有限的替代方案
如果團隊預算有限或只有 5 人以下，用 Excel 建立甘特圖進行基本的進度監控也是可行的方案。Excel 專案管理的優勢是零成本、團隊都會用；限制是缺乏自動化、多人協作困難、數據容易出錯。
Excel 甘特圖監控的基本做法：
- 建立任務清單，包含：任務名稱、負責人、計畫開始/結束日期、實際開始/結束日期、完成百分比
- 用條件格式化產生甘特圖條狀圖
- 加入 SPI 計算欄位（=實際完成價值/計畫完成價值）
- 每週更新一次數據
更完整的 Excel 進度表製作教學和模板結構，可以參考我們的專案進度表專題頁面。
何時該從 Excel 升級到專業工具？ 當你發現以下任一情況時：
- 團隊超過 5 人，Excel 檔案經常版本衝突
- PM 每週花超過 2 小時手動整理數據
- 需要自動化提醒功能（Excel 做不到）
- 需要即時的儀表板視覺化（Excel 需要手動更新圖表）
實務案例：三種產業的監控導入經驗
IT 軟體開發專案（A 公司，10 人團隊）
背景： A 公司是一家台北的軟體公司，正在開發一套 B2B SaaS 產品，團隊 10 人（3 後端、3 前端、2 QA、1 UI/UX、1 PM），預計 4 個月交付 MVP。
問題： 前兩個月只在每月底開一次進度會議。到了第 2 個月底，PM 才發現測試進度嚴重落後——QA 團隊反映「後端 API 一直在改，我們測完又要重測」。實際上，進度已經落後 3 週，但因為沒有量化指標，團隊一直覺得「差不多趕得上」。
導入方案：
- 工具：ClickUp（團隊已有技術背景，適合高度自訂）
- 監控頻率：每日 15 分鐘站會 + 每週五 30 分鐘 Sprint Review
- 指標：SPI、每週缺陷發現數、任務準時完成率
- 關鍵操作：PM 在 ClickUp 中將每個功能模組拆解為 3-5 個子任務，設定任務依賴關係，讓後端完成後自動通知 QA 開始測試
- 導入時程：約 2 週（第 1 週建立看板和流程，第 2 週團隊適應）
成果： 導入後第一週就發現 3 個被遺漏的任務依賴關係。透過每日站會，後端和 QA 的溝通頻率從「有問題才說」變成「每天同步」。最終如期交付 MVP，缺陷率較前一個專案降低 30%。
製造業新產品開發專案（20 人團隊）
背景： 一家台中的精密零件製造商，正在開發一款新型散熱模組，團隊 20 人（含研發、模具、品管、採購），預算 NT$1,200 萬，工期 8 個月。
問題： 到了第 3 個月，成本已超支 15%（主要是模具修改費用），進度落後 3 週（供應商交貨延遲）。但因為只有採購部門知道成本數字、研發部門知道進度數字，PM 無法看到全貌。
導入方案：
- 工具：monday.com（跨部門協作需求高，介面直覺）
- 監控頻率：每週一次跨部門進度會議 + 每月 EVM 成本檢視
- 指標：SPI、CPI、模具修改次數、供應商準時交貨率
- 導入時程：約 1 個月（第 1-2 週建立看板，第 3-4 週各部門數據上線）
PM 在 monday.com 上建立了一個「專案健康度儀表板」，將進度、成本、品質三個面向的 KPI 集中呈現。每週一早上，所有部門主管打開儀表板就能看到紅黃綠燈號——不需要等到會議才知道狀況。
成果： 2 個月後，SPI 從 0.82 回升至 0.95，CPI 從 0.87 回升至 0.93。最終專案延期 1 週（而非原本預估的 5 週），節省約 10% 預算。
行銷活動專案（5 人小型團隊）
背景： 一家高雄的數位行銷公司，5 人團隊同時管理 3-4 個客戶的行銷活動。任務分散在 Email、LINE 群組和個人筆記中，沒有集中的任務追蹤系統。
問題： 任務準時完成率只有 60%。不是因為團隊不努力，而是因為沒有人知道「現在最緊急的是哪個任務」。經常發生 A 客戶的素材做完了但忘記上傳、B 客戶的廣告文案改了三版但沒人通知設計師。
導入方案：
- 工具：Notion 免費版（預算有限，5 人以下免費夠用）
- 監控頻率：每週一早上 20 分鐘進度同步
- 指標：任務準時完成率、每週完成任務數
- 導入時程：3 天（第 1 天建立模板，第 2-3 天團隊熟悉操作）
成果： 導入 1 個月後，任務準時完成率從 60% 提升至 85%。最大的改變不是工具本身，而是「所有任務都在同一個地方」——團隊成員打開 Notion 就知道今天該做什麼、哪些任務快到期。
後續升級： 3 個月後，團隊接了更多客戶，Notion 的手動追蹤開始不夠用（缺乏自動化提醒）。他們升級到 monday.com 基本方案，用自動化規則處理「任務到期前 2 天自動提醒」，PM 每週省下約 1.5 小時的手動追蹤時間。
結論
專案監控不是額外的行政負擔，而是讓專案「可控」的核心機制。
本文核心重點回顧：
- 監控 ≠ 監督：監控聚焦數據與指標，是系統化的管理活動；監督聚焦人員行為，兩者互補但不可混淆
- 5 步驟流程：設定指標 → 收集數據 → 分析偏差 → 報告溝通 → 矯正行動，對應 PDCA 的 Check 與 Act
- 四大面向缺一不可：進度（SPI）、成本（CPI）、品質（缺陷率）、風險（觸發指標），不要只看進度忽略其他
- KPI 要有健康值門檻：SPI/CPI ≥ 0.95 綠燈、0.85-0.94 黃燈、< 0.85 紅燈，讓團隊對「好不好」有共識
- 工具選擇看團隊規模：5 人以下用 Notion/Excel，5-20 人用 monday.com，技術團隊用 ClickUp/Jira
你的下一步行動：
如果你目前完全沒有監控機制，今天就可以做的第一步：在你慣用的工具（Excel、Notion 或 monday.com）中建立一個任務看板，把目前進行中的任務填入，設定每個任務的截止日期和負責人，再加入「任務完成率」和「逾期任務數」兩個追蹤欄位。
如果你已經有基本的進度追蹤，下一步是導入 EVM 指標。在你的進度表中加入 PV、EV、AC 三個欄位，每週計算一次 SPI 和 CPI，你會發現專案的「健康狀況」突然變得清晰可見。
想進一步提升專案管理的系統化能力，可以考慮 Coursera 上的 Google 專案管理證照課程，課程涵蓋完整的監控方法論與實務練習，包含 EVM、風險監控等本文提到的核心技能。
專案監控常見問答（FAQ）
專案監控與專案監督有何不同？
專案監控聚焦於數據收集與指標分析（如 SPI、CPI），屬於系統化管理；專案監督偏向人員行為與工作紀律的管理。監控告訴你「專案偏了多少」，監督確保「團隊按規範執行」。
專案監控應該多久做一次？
依專案規模而定：5 人以下小型專案每週一次即可；5-20 人中型專案建議每日站會加每週書面報告；20 人以上大型專案需要每日站會、每週書面報告加每月正式績效報告。高風險階段（如整合測試、上線前）應加密監控頻率。
小型團隊沒有預算，如何做好專案監控？
用 Excel 建立基本的任務追蹤表，包含任務名稱、負責人、計畫與實際日期、完成百分比，每週更新一次。或使用 Notion、ClickUp 的免費方案，功能足以支撐 5 人以下團隊的基本監控需求。關鍵不是工具多高級，而是「有沒有固定的監控節奏」。
EVM 適合所有專案嗎？
EVM 最適合有明確範疇、可量化工作量的專案（如軟體開發、工程建設、製造業）。對於探索性高、範疇不確定的專案（如早期研發、創意發想），EVM 的效果有限。替代方法包括：燃盡圖（適合敏捷專案）、里程碑追蹤法（適合簡單專案）、OKR 進度追蹤（適合目標導向專案）。
監控結果顯示進度落後，第一步應該做什麼？
三步驟行動框架：第一步，確認落後的根因——是單一任務延遲還是系統性問題？檢查關鍵路徑上的任務。第二步，評估影響範圍——落後是否會影響里程碑或最終交付日期？用 EAC 公式預測最終完工時間。第三步，制定矯正方案——如果偏差在 10% 以內，嘗試重新分配資源或調整任務優先順序；超過 15% 則需要升級給專案發起人，討論是否需要增加資源或調整範疇。
