【專案延遲】7大原因與三階段應對策略｜含預警指標與工具實作

專案延遲是指專案未能在原定時程內完成全部或部分目標、里程碑或交付物，依嚴重程度可分為三級。 本文完整解析 7 大延遲原因、6 項預警指標與觸發門檻、三階段管理策略（預防→即時應對→事後改善），並附上客戶溝通話術框架與 monday.com 延遲預警設定步驟。

專案延遲是什麼？定義、類型與嚴重程度分級

根據 PMBOK 的定義，專案延遲屬於排程管理中的負面偏差——實際進度落後於基準計畫（Schedule Baseline）。但不是所有延遲都需要拉警報。理解延遲的「類型」和「嚴重程度」，是 PM 做出正確反應的第一步。

三種延遲類型（整體、里程碑、交付物）

延遲類型	定義	典型情境
整體延遲	專案最終交付日超過原定計畫	軟體產品原定 Q3 上線，延至 Q4
里程碑延遲	關鍵階段（設計、測試、上線）未如期完成	UAT 測試原定兩週，實際花了四週
交付物延遲	單一或多個交付物未按時交付，影響後續任務	API 文件延遲交付，導致前端開發無法啟動

這三種類型經常連鎖發生：交付物延遲累積成里程碑延遲，最終演變為整體延遲。PM 的核心任務是在交付物層級就攔截問題，避免向上擴散。

延遲嚴重程度三級分類與對應行動門檻

很多 PM 犯的錯誤是把所有延遲一視同仁——要嘛全部緊張，要嘛全部忽略。實際上，延遲的嚴重程度取決於它是否影響關鍵路徑，以及是否超出預留的緩衝時間。

嚴重等級	判斷條件	對應行動	通報層級
🟢 綠燈	延遲在 Buffer（管理預備時間）內，未影響關鍵路徑	PM 自行調整資源配置，更新排程	團隊內部
🟡 黃燈	延遲已消耗 Buffer 或開始影響關鍵路徑上的任務	啟動快速跟進法或趕工法，召開緊急協調會	PM → 專案發起人
🔴 紅燈	延遲超出可調整範圍，需修改專案基準線或範圍	啟動正式變更控制流程（Change Control）	PM → 變更控制委員會 → 客戶

舉例來說，一個為期六個月的專案，如果某個非關鍵路徑的任務延遲三天，而該路徑有五天的浮時（Float），這就是綠燈——PM 記錄下來、調整排程即可。但如果同一個任務在關鍵路徑上延遲三天，那就是黃燈，需要立即採取校正措施。

專案延遲的 7 大常見原因（含實務情境）

專案延遲很少是單一原因造成的，通常是多個因素交互作用的結果。以下依照根本成因分為三大類，每個原因都附上預防對策，讓你不只「知道為什麼」，還能「提前擋住」。

資源與預估類原因（資源不足、預估錯誤、優先順序混亂）

這類原因的共同特徵是：問題在專案規劃階段就已經埋下。

原因	說明	實務情境	預防對策
資源不足	人力、預算或設備分配不當	製造業案例：某電子代工廠同時接了三條產線的新品導入，工程師被拆分到不同產線，每條線都只有 60% 的人力，結果三條線全部延遲	在規劃階段用工作分解結構估算實際工時，再比對可用資源
預估錯誤	對工時、複雜度或風險評估過於樂觀	軟體開發案例：團隊估算「串接第三方支付 API」只需一週，但實際上光是等對方提供測試環境就花了兩週	採用三點估算法（樂觀＋最可能＋悲觀），並加入歷史數據校正
優先順序混亂	任務排序不當，關鍵工作被延後	行銷活動案例：團隊同時處理品牌重塑和產品上市活動，沒有明確優先順序，結果兩個專案的素材都在截止日前一天才趕工完成，品質大幅下降	使用優先順序矩陣（如 monday.com 的優先順序看板）明確排序

溝通與需求類原因（需求頻繁變更、溝通不良）

這類原因的核心問題是：資訊沒有在對的時間傳遞給對的人。

原因	說明	實務情境	預防對策
需求頻繁變更	客戶或內部頻繁修改需求，導致範圍蔓延	軟體開發案例：客戶在 UAT 階段突然要求新增報表功能，開發團隊需要回頭修改資料庫結構，導致上線延遲六週	建立正式的變更請求流程，每次變更都需評估對時程與成本的影響
溝通不良	團隊、客戶或供應商間資訊傳遞不清	製造業案例：設計部門修改了零件規格但只更新了內部文件，採購部門仍按舊規格下單，等到組裝階段才發現零件不合，需要重新採購	建立單一資訊來源（Single Source of Truth），所有變更在同一平台同步更新

外部與技術類原因（供應商延誤、技術挑戰）

這類原因的特點是：PM 的控制力最弱，因此預防措施更加重要。

原因	說明	實務情境	預防對策
供應商延誤	關鍵零件或服務由第三方供應，交付不及時	製造業案例：晶片供應商因產能問題延遲交貨三個月，整條產線被迫停擺	在合約中加入延遲罰款條款，並建立備選供應商清單
技術挑戰	遇到預期外的技術難題或整合困難	軟體開發案例：團隊導入新的微服務架構，但在高併發場景下出現效能瓶頸，需要額外兩個 Sprint 進行架構調整	在規劃階段安排技術驗證（Proof of Concept），高風險技術優先處理

理解這些原因後，下一步是建立預警機制——在延遲真正發生之前就偵測到風險信號。在此之前，我們先看看延遲一旦發生，會帶來哪些具體影響。

專案延遲的實際影響：從士氣到法律責任

專案延遲的影響遠不只是「晚幾天交付」這麼簡單。以下六項影響從內部到外部、從短期到長期，幫助你向利害關係人說明「為什麼延遲管理值得投入資源」。

1. 團隊士氣下降

延遲通常意味著加班趕工，而持續加班會形成惡性循環：加班→疲勞導致品質下降→更多返工→更多加班。當這個循環持續數週，資深成員開始考慮離職，新人接手又需要學習時間，進一步拖慢進度。關於如何在高壓專案中維持團隊戰力，可參考我們的團隊管理指南。

2. 客戶信任受損

第一次延遲，客戶可能理解；第二次延遲，客戶開始質疑你的專業能力；第三次延遲，客戶開始尋找替代供應商。在 B2B 領域，一個客戶的流失可能意味著數百萬的年度合約收入。

3. 預算超支

延遲一個月，就多一個月的人力成本、辦公成本和機會成本。根據 104 人力銀行《2024 年薪資調查報告》，台灣軟體工程師平均月薪約 NT$55,000～70,000。以一個 10 人開發團隊、平均月薪 NT$60,000 估算，延遲一個月的直接人力成本就是 NT$600,000，還不包括管理費用和設備折舊。實際專案中，間接成本（如辦公空間、軟體授權、管理層投入的時間）通常會再增加 30%～50%。

4. 企業信譽受損

延遲交付的影響不只限於單一專案。當一家公司連續多個專案未能如期交付，既有客戶的續約意願會下降，潛在客戶在評估供應商時也會將過往交付紀錄納入考量。這對依賴長期合作關係的 B2B 企業尤其致命——失去的不只是一張訂單，而是未來數年的合作機會。

5. 商業機會流失

這是最容易被忽略但影響最大的。一款手機 App 如果錯過了雙十一的上線時機，即使產品品質再好，也無法追回那個銷售高峰。時間窗口一旦關閉，就是永久性的損失。

6. 合約罰款與 SLA 違約

這是台灣 B2B 專案中最直接的財務衝擊。常見的罰款條款結構如下：

• 逾期罰款：每延遲一天，罰合約總金額的 0.1%～0.3%（台灣政府採購法規定上限為合約金額的 20%）
• SLA 違約金：如果是服務型合約，系統可用性低於 99.5% 時，每低 0.1% 罰當月服務費的 5%
• 終止合約權：延遲超過約定天數（通常 30～60 天），客戶有權終止合約並求償

一個 NT$5,000,000 的專案，如果延遲 30 天、罰款率 0.2%/天，罰款金額就是 NT$300,000——這還不包括客戶可能提出的其他損害賠償。

如何判斷專案是否即將延遲？預警指標與觸發門檻

很多 PM 是在延遲已經發生之後才「發現」延遲。真正有效的延遲管理，是在問題還在萌芽階段就偵測到。以下是六個經過實務驗證的預警指標，每個都附上具體的觸發門檻，讓你可以直接套用到自己的專案中。

6 大預警指標與觸發門檻對照表

預警指標	觸發門檻（建議值）	立即行動
關鍵任務進度落後	任一關鍵路徑任務延遲超過原定工期的 10%	召開該任務負責人 1-on-1，釐清阻礙因素
里程碑多次調整	同一里程碑被調整 2 次以上	重新評估該階段的排程管理基準線
溝通頻繁出現誤解	單週內因資訊落差導致返工超過 2 次	檢視溝通管道與文件同步機制
需求變更頻率異常	變更請求數量超過規劃階段預估的 150%	與客戶召開範圍確認會議，凍結非必要變更
缺陷數量持續上升	連續兩個 Sprint 的缺陷數量成長超過 20%	安排技術債清理 Sprint，暫停新功能開發
團隊工時明顯超時	團隊平均週工時超過 50 小時，持續兩週以上	評估是否需要增加人力或縮減範圍

在 monday.com 中，你可以用自動化規則設定這些門檻：例如「當任務狀態停留在『進行中』超過 X 天，自動發送通知給 PM 和該任務負責人」。這比每天手動檢查每個任務的狀態高效得多。

另一個量化延遲程度的方法是使用 S 曲線（S-Curve）。S 曲線將計畫進度與實際進度繪製在同一張圖上，當兩條曲線的差距持續擴大，就是明確的延遲信號。搭配實獲值管理（EVM）中的進度績效指數（SPI），當 SPI < 1.0 時代表進度落後，SPI < 0.8 時則需要立即啟動校正措施。

用關鍵路徑判斷哪些延遲真正危險

不是所有任務延遲都需要緊張。理解關鍵路徑（Critical Path）和浮時（Float）的概念，能幫你把精力集中在真正重要的地方。

關鍵路徑是專案中最長的任務鏈——這條路徑上的任何一個任務延遲，都會直接導致專案整體延遲。

浮時（Float / Slack） 是非關鍵路徑上的任務可以延遲的最大天數，而不影響專案完成日期。

實務判斷原則：

• 如果延遲的任務在關鍵路徑上 → 立即行動（黃燈或紅燈）
• 如果延遲的任務不在關鍵路徑上，且延遲天數 < 該任務的浮時 → 記錄並監控（綠燈）
• 如果延遲的任務不在關鍵路徑上，但延遲天數 ≥ 該任務的浮時 → 該任務已變成新的關鍵路徑，需要立即處理

這就是為什麼 PM 需要持續更新排程——因為關鍵路徑會隨著專案進展而改變。一個原本有五天浮時的任務，如果前置任務延遲了三天，它的浮時就只剩兩天了。

專案延遲管理三階段：預防 → 即時應對 → 事後改善

延遲管理不是「延遲發生後才開始」的工作。完整的延遲管理涵蓋三個階段，每個階段都有具體的步驟和常見的失敗原因。這個框架整合了專案管理流程中的監控與控制知識領域。

延遲前——預防機制建立（風險登錄表、基準線設定、緩衝時間規劃）

預防是成本最低的延遲管理手段。以下三個機制缺一不可：

1. 風險登錄表（Risk Register）

風險管理的核心工具。每個已識別的風險都需要記錄以下欄位：

• 風險描述（具體到可以行動的程度）
• 發生機率（高/中/低）
• 影響程度（高/中/低）
• 風險負責人（不是 PM 一個人扛所有風險）
• 應對策略（迴避/轉移/減輕/接受）
• 觸發條件（什麼情況下啟動應對計畫）

更新頻率：至少每兩週檢視一次，Sprint Review 時同步更新。

2. 排程基準線（Schedule Baseline）

基準線是你判斷「是否延遲」的參考標準。沒有基準線，就沒有延遲的概念——因為你不知道「原本應該在哪裡」。在 monday.com 的甘特圖中，你可以設定基準線並即時比對實際進度。

3. 緩衝時間規劃

在關鍵路徑的末端加入專案緩衝（Project Buffer），在非關鍵路徑匯入關鍵路徑的節點加入匯入緩衝（Feeding Buffer）。一般建議緩衝時間為該路徑總工期的 10%～20%。

常見失敗：「只建表不更新」——很多團隊在專案啟動時認真做了風險登錄表，但之後就再也沒打開過。風險登錄表不是一次性文件，它是活的管理工具。如果你的風險登錄表上次更新日期是三個月前，它已經失去了預警功能。

延遲中——即時校正技術（快速跟進法 vs 趕工法）

當延遲已經發生或即將發生（黃燈狀態），PM 有兩種標準的時程壓縮技術可以選擇：

快速跟進法（Fast Tracking）

將原本依序執行的任務改為並行執行。例如：原本是「設計完成 → 開發」，改為「設計完成 80% 時就開始開發」。

• 優點：不增加成本
• 風險：並行任務之間可能產生返工（例如設計後來改了，已開發的部分需要重做）
• 適用條件：任務之間有部分可以獨立進行的工作

趕工法（Crashing）

投入額外資源來加速關鍵路徑上的任務。例如：增加開發人員、外包部分工作、購買更快的設備。

• 優點：不增加風險（任務順序不變）
• 風險：增加成本，且有邊際遞減效應（人多不一定更快）
• 適用條件：有額外預算，且任務可以被拆分給更多人

決策框架：什麼情況選哪種方法？

決策條件	選擇快速跟進法	選擇趕工法
預算狀況	預算緊張，無法增加資源	有額外預算可動用
任務相依性	任務之間有可並行的部分	任務必須嚴格依序執行
返工風險容忍度	團隊能承受部分返工	品質要求高，不能冒返工風險
時程壓力	需要壓縮的天數較少（< 20%）	需要大幅壓縮時程

常見失敗：「加班就能補回進度」——這是最普遍的誤區。Brooks 法則指出：「在一個已經延遲的軟體專案中增加人力，只會讓它更延遲。」因為新成員需要學習時間，現有成員需要花時間帶人，溝通成本也會增加。加班同樣如此——短期衝刺有效，但持續超過兩週，生產力就會開始下降。

延遲中——如何向客戶與老闆溝通延遲

這是台灣 PM 最頭痛的場景。很多 PM 選擇「再撐一下看看」，結果等到延遲已經無法挽回時才通報，反而讓情況更糟。

溝通時機原則：發現風險就通報，不要等確認後。

理由很簡單：如果你在發現風險時就通報，你還有時間和利害關係人一起想解法；如果你等到延遲已成事實才通報，對方只能接受壞消息，而且會質疑「你為什麼不早說」。

溝通話術框架：SICRA 五步法

1. S — Situation（現況）：「目前 XX 模組的開發進度落後原定計畫 5 個工作天。」
2. I — Impact（影響）：「如果不採取措施，預計整體上線日期會延後 7～10 天，影響到 XX 行銷活動的配合時程。」
3. C — Cause（原因）：「主要原因是第三方 API 的技術文件有誤，我們花了額外時間除錯。」
4. R — Recovery（補救方案）：「我們已準備兩個方案：方案 A 是增加一名後端工程師，預計可追回 4 天；方案 B 是先上線核心功能，XX 模組延後一週上線。」
5. A — Ask（請求支援）：「需要您協助決定採用哪個方案，以及是否能協調行銷團隊調整活動時程。」

實際話術範例（向客戶）：

「王總您好，跟您更新一下專案進度。目前後端整合測試發現了一個技術問題，預計需要額外 5 個工作天來解決。我們已經安排了兩位資深工程師專門處理，目標是將影響控制在 3 天以內。我想跟您確認：原定的上線日期是否有 3 天的彈性空間？如果沒有，我們可以先上線核心功能，其餘功能在下一個版本補上。」

常見失敗：「只報壞消息不帶解法」——如果你只說「專案要延遲了」，對方的第一反應一定是焦慮和不信任。但如果你說「專案遇到了 XX 問題，我已經準備了兩個解法，需要您幫忙做決定」，對方會覺得你是在掌控局面，只是需要支援。這個差別決定了客戶對你的信任程度。好的主管領導力也體現在危機溝通的品質上。

延遲後——根本原因分析與流程優化

延遲結束後（無論是追回進度還是接受延遲），最重要的工作是確保同樣的問題不會在下一個專案重演。

5 Whys 在延遲 RCA 中的應用步驟：

以「專案延遲兩週」為例：

1. Why 1：為什麼專案延遲兩週？→ 因為 UAT 測試階段發現了 47 個嚴重缺陷，需要額外時間修復。
2. Why 2：為什麼 UAT 階段才發現這麼多缺陷？→ 因為開發階段的單元測試覆蓋率只有 30%。
3. Why 3：為什麼單元測試覆蓋率這麼低？→ 因為團隊為了趕進度，跳過了測試撰寫。
4. Why 4：為什麼團隊會跳過測試？→ 因為排程中沒有預留測試撰寫的時間。
5. Why 5：為什麼排程中沒有預留測試時間？→ 因為估算時只計算了「開發」工時，沒有把「測試撰寫」作為獨立任務。

根本原因：工時估算方法有缺陷——沒有將測試撰寫納入標準估算項目。

轉化為下個專案的 Checklist：

• ✅ 估算工時時，每個開發任務必須包含「單元測試撰寫」子任務
• ✅ 單元測試覆蓋率門檻設為 70%，低於此標準不得進入整合測試
• ✅ 每個 Sprint 的 Definition of Done 必須包含「測試通過」

將這些結論記錄在組織的知識庫中（例如 Notion 的知識庫），讓未來的專案團隊可以直接參考，避免重複踩坑。

專案管理工具如何降低延遲風險（含操作說明）

前面談的所有預防機制、預警指標和校正技術，都需要工具來落地執行。手動用 Excel 追蹤十幾個任務的進度、每天逐一檢查是否有延遲——這在小專案還行，但當任務數超過 50 個、團隊超過 5 人時，手動追蹤就會成為延遲的原因之一。

三大工具比較（monday.com / ClickUp / Notion）含 NT$ 定價

比較項目	monday.com	ClickUp	Notion
延遲預警功能	✅ 自動化規則＋儀表板警示	✅ 自訂欄位＋自動化	⚠️ 需手動設定提醒
甘特圖（含基準線）	✅ 內建，支援基準線比對	✅ 內建，支援依賴關係	⚠️ 需用時間軸視圖替代
關鍵路徑顯示	✅ 甘特圖自動標示	✅ 甘特圖自動標示	❌ 不支援
自動化規則	✅ 無程式碼，拖拉設定	✅ 功能強大但學習曲線較高	⚠️ 基礎自動化
適合團隊規模	5～200 人	5～100 人	1～15 人
NT$ 月費（每人）	免費方案可用 / 付費約 NT$270 起	免費方案可用 / 付費約 NT$220 起	免費方案可用 / 付費約 NT$260 起
開始使用	免費試用 →	免費試用 →	免費試用 →

你是哪種團隊？

• 5 人以下、剛開始接觸專案管理：先用 Notion 免費版建立基本的任務追蹤
• 5～15 人跨部門協作：monday.com 是我們的首選——自動化預警設定最直覺，不需要技術背景就能上手
• 技術團隊跑 Scrum：ClickUp 的 Sprint 管理和自訂欄位更靈活
• 15 人以上的大型專案：monday.com 企業方案，支援跨專案資源管理和進階報表

monday.com 延遲預警設定 3 步驟實作

以下是在 monday.com 中設定延遲預警的具體操作方式，10 分鐘就能完成：

步驟一：設定排程基準線

在甘特圖視圖中，當專案計畫確認後，點擊「設定基準線」。這會儲存當前的排程快照，之後所有的進度變化都會與這個基準線比對。你可以一眼看出哪些任務超前、哪些落後。

步驟二：建立自動提醒規則

進入「自動化」設定，建立以下規則：

• 規則 1：「當任務的『截止日期』距今 ≤ 2 天，且狀態仍為『進行中』→ 通知任務負責人和 PM」
• 規則 2：「當任務狀態變更為『卡住』→ 立即通知 PM 和該任務的上游負責人」
• 規則 3：「當任務的『實際完成日』超過『計畫完成日』→ 自動將該任務標記為『延遲』並通知專案發起人」

這三條規則覆蓋了「即將延遲」「遇到阻礙」「已經延遲」三種情境。自動化規則的核心價值在於：問題發生的當下就觸發通知，不需要等到下次週會才被發現，大幅縮短了從「問題出現」到「PM 知道」的時間差。

步驟三：配置儀表板警示

建立一個「延遲監控儀表板」，包含以下 Widget：

• 延遲任務清單：篩選所有狀態為「延遲」或「卡住」的任務
• 進度 vs 基準線圖表：用圖表 Widget 顯示計畫進度與實際進度的差異
• 團隊工時統計：監控是否有成員持續超時工作

（推薦試試 monday.com 的免費方案，不需要信用卡就能開始設定。）

下一步：選擇適合你團隊的工具

如果你目前還在用 Excel 或 Google Sheets 追蹤專案進度，最大的風險不是「功能不夠」，而是「沒有自動預警」。當你管理 3 個以上的專案、50 個以上的任務時，手動追蹤幾乎不可能及時發現所有延遲信號。

選擇工具時，優先考慮以下三個功能：

1. 自動化預警——能根據你設定的門檻自動通知相關人員
2. 甘特圖基準線——能比對計畫與實際進度的差異
3. 儀表板——能一眼看出整個專案的健康狀態

如果你不確定從哪裡開始，建議先用 monday.com 的專案管理模板建立一個看板，把現有專案的任務搬進去，設定好截止日期和自動提醒。光是這一步，就能讓你的延遲偵測能力大幅提升。更多專案管理工具的比較與選擇建議，可參考我們的完整評測指南。

結論

專案延遲是每個 PM 都會遇到的挑戰，但有系統的管理方法能讓你從「被動救火」轉變為「主動預防」。以下是本文的核心重點：

• 延遲分三級嚴重度：綠燈（Buffer 內可吸收）、黃燈（影響關鍵路徑）、紅燈（需正式變更控制），不同等級對應不同行動門檻
• 7 大延遲原因歸為三類：資源與預估類、溝通與需求類、外部與技術類——每類都有對應的預防對策
• 6 項預警指標搭配具體觸發門檻，讓你在延遲發生前就偵測到風險信號
• 兩種時程壓縮技術：快速跟進法（不加成本但有返工風險）和趕工法（加成本但不加風險），根據預算和任務特性選擇
• SICRA 溝通框架：現況→影響→原因→補救方案→請求支援，帶著解法報壞消息

你的下一步行動：打開 monday.com，用專案管理模板建立一個新看板，設定三條自動化預警規則（即將到期提醒、卡住通知、延遲標記）。免費方案不需要信用卡，10 分鐘就能完成設定。這一個小動作，就能讓你的延遲偵測能力從「週會才發現」提升到「即時通知」。

專案延遲常見問題 FAQ

專案延遲多少天才算嚴重？

沒有絕對的天數標準，關鍵在於延遲是否影響關鍵路徑。如果延遲的任務不在關鍵路徑上，且延遲天數小於該任務的浮時（Float），影響可控。但如果延遲發生在關鍵路徑上，即使只有一天，也會直接推遲專案完成日期。建議以「是否消耗完 Buffer」和「是否影響關鍵路徑」作為判斷基準，而非單純看天數。

快速跟進法和趕工法可以同時使用嗎？

可以，但要謹慎。同時使用意味著你既增加了成本（趕工），又增加了返工風險（快速跟進）。通常建議先嘗試單一方法，評估效果後再決定是否疊加。如果兩種方法都無法將延遲控制在可接受範圍內，就需要啟動正式的變更控制流程，重新協商專案範圍或時程。

客戶要求不能延遲，但技術上確實做不到，怎麼辦？

這時候需要用數據說話，而不是用感覺。先用甘特圖和關鍵路徑分析，明確計算出「在現有資源下，最快能完成的日期」。然後向客戶提出選項：（1）增加資源（客戶追加預算）；（2）縮減範圍（先上線核心功能）；（3）接受新的時程。讓客戶在這三個選項中做決定，而不是讓 PM 獨自承擔不可能的承諾。關於如何在這類場景中有效管理利害關係人期望，可參考我們的時間管理指南。

小型專案（3～5 人）也需要這麼完整的延遲管理機制嗎？

不需要全部照搬，但核心原則不變。小型專案至少需要：（1）明確的排程基準線（知道「原本計畫什麼時候完成」）；（2）每週一次的進度檢查（不需要正式會議，站立會議即可）；（3）一條自動化預警規則（任務即將到期時通知負責人）。這三件事花不到 30 分鐘就能設定好，卻能避免大部分的延遲意外。

如何避免「每個專案都延遲」的組織性問題？

如果延遲是組織性的（不是個別專案的問題），根本原因通常在於：（1）組織習慣性低估工時（樂觀偏誤）；（2）資源長期過度分配（每個人同時做太多專案）；（3）沒有從過去的延遲中學習（缺乏 RCA 機制）。解決方法是建立組織級的「歷史工時資料庫」，用過去專案的實際數據來校正未來的估算，並嚴格限制每人同時參與的專案數量（建議不超過 2～3 個）。