專案計劃是一份系統性文件，明確規劃專案的目標、範圍、時程、資源、預算、風險與溝通方式，作為專案執行與監控的核心依據。 本文完整教學 5 大核心要素、7 步驟制定流程，含 WBS 拆解範例、風險矩陣、甘特圖製作方法與 5 款工具比較表。
專案計劃是什麼
專案計劃不只是「要做什麼」的任務清單，而是一份回答「如何做、誰來做、什麼時候做、遇到問題怎麼辦」的全方位藍圖。它涵蓋目標設定、範圍界定、任務分解、時程排定、資源配置、預算編列、風險應對與溝通機制，讓整個團隊在同一份文件上對齊方向。
在實務上，「專案計劃」和「專案計劃書」經常被混用，但兩者有細微差異：專案計劃指的是規劃的過程與思維框架；專案計劃書則是這個過程的書面產出。你可以把計劃想成動詞（planning），計劃書想成名詞（plan document）。
一個關鍵觀念：專案計劃是一份活文件（living document）。它不是專案啟動前寫完就鎖進抽屜的東西，而是隨著專案進展持續更新的參考基準。當需求變動、資源調整或風險發生時，計劃必須同步修正，否則就會變成與現實脫節的「殭屍文件」。
另一個常見誤解是把專案計劃等同於專案管理。事實上，計劃只是管理的一個階段——管理還包含啟動、執行、監控與收尾。計劃做得再好，沒有後續的執行追蹤與調整機制，專案一樣會失控。
為什麼專案計劃至關重要
某科技公司在開發新產品時，因為沒有事先明確定義專案範圍，開發過程中需求變動超過 30 次，團隊反覆修改設計與程式碼，最終專案延誤 3 個月、預算超支 40%。後來團隊導入完整的專案計劃流程——包含需求確認會議、範圍凍結機制與風險預警——第二版產品成功在預定時間內上市，開發週期縮短了 35%。
這個案例反映的不是個案，而是多數專案失敗的共同模式。一份完善的專案計劃帶來三個核心效益：
對齊目標與共識。 當團隊成員、主管、客戶對「這個專案要達成什麼」有不同想像時，衝突就會在執行階段爆發。計劃書白紙黑字寫下目標與範圍，讓所有利害關係人在啟動前就達成一致。這比事後爭論「當初說好的不是這樣」有效得多。
預防風險與資源浪費。 提前辨識潛在風險並規劃應對策略，比事後救火的成本低十倍以上。同樣地，預先盤點資源與預算，能避免「做到一半才發現人不夠、錢不夠」的窘境。好的策略規劃從來不是浪費時間，而是在為執行階段省時間。
提供可追蹤的執行基準。 沒有計劃，你無法衡量「進度是否落後」——因為根本沒有基準線可以比較。設定里程碑與時程後，團隊才能在每週檢視時快速判斷：我們在軌道上嗎？哪裡需要調整？
以下說明一份完整的專案計劃應包含哪些核心要素。
專案計劃的 5 大核心要素
1. 專案範圍與目標設定
目標設定是整份計劃的地基。模糊的目標會導致團隊各自解讀、各做各的。建議採用 SMART 原則來設定目標：具體（Specific）、可衡量（Measurable）、可達成（Achievable）、相關性（Relevant）、有時限（Time-bound）。
舉例來說，「提升客戶滿意度」是模糊目標；「在 Q3 結束前將 NPS 分數從 45 提升至 60」才是 SMART 目標。後者讓團隊知道要做到什麼程度、什麼時候要完成。
範圍界定同樣關鍵。你需要明確列出「IN scope」（專案要做的事）和「OUT of scope」（專案不做的事）。以一個行銷活動專案為例：
| 類別 | 項目 |
|---|---|
| IN scope | 社群廣告投放、KOL 合作洽談、活動頁面設計、數據追蹤報告 |
| OUT of scope | 官網全站改版、CRM 系統串接、線下實體活動場地租借 |
這張表看起來簡單，卻能在專案執行中省下無數爭論。當有人提出「順便把官網也改一下吧」，你可以直接指著範圍說明書回應：「這不在本次專案範圍內，需要另開專案評估。」
常見錯誤：範圍蔓延（Scope Creep）。 這是專案殺手排行榜的常客。三個早期警訊：(1) 利害關係人頻繁提出「小小的追加需求」；(2) 團隊開始做計劃書上沒有的任務；(3) 專案時程不斷往後推但沒有人正式提出變更申請。應對方式是建立正式的變更管理流程——任何範圍變更都必須經過評估、核准、記錄，而不是口頭答應就開始做。
範圍說明書（Scope Statement）應包含以下 5 個欄位：專案目標、交付物清單、IN/OUT scope 界定、驗收標準、假設條件與限制。
2. 任務分解（WBS）與時程規劃
有了明確的範圍後，下一步是把大目標拆解成可執行的小任務。這就是 WBS（Work Breakdown Structure，工作分解結構）的核心功能。
WBS 通常採用三層拆解。以「產品上市專案」為例：
- 第一層（專案）： 新產品上市
- 第二層（階段）： 市場調研 → 產品開發 → 行銷推廣 → 上市執行
- 第三層（任務）： 以「行銷推廣」為例，拆解為：撰寫產品文案、設計視覺素材、投放社群廣告、聯繫媒體曝光、製作產品影片
拆到第三層時，每個任務應該是一個人在一到兩週內可以完成的工作單元。如果一個任務需要超過兩週，通常代表它還可以再往下拆。
任務拆解完成後，接著用甘特圖排定時程。甘特圖製作分三步驟：
- 列出任務清單與負責人： 把 WBS 第三層的所有任務列成清單，指定每個任務的負責人。
- 設定起迄日期： 根據任務的工作量與可用資源，估算每個任務的開始與結束日期。
- 標記任務依賴關係： 哪些任務必須等前一個完成才能開始（完成-開始關係）？哪些可以同步進行？這一步決定了專案的關鍵路徑。
在工具選擇上，不同規模的團隊適合不同方案：
- Excel / Google Sheets： 適合 5 人以下的小型專案。用條件格式設定色塊模擬甘特圖，優點是零成本、上手快，缺點是無法自動計算依賴關係，手動維護容易出錯。
- Microsoft Project： 台灣企業最常用的專案管理軟體（Office Project），內建甘特圖、資源平衡、關鍵路徑計算等功能。適合有複雜任務依賴關係的中大型專案。Plan 1 方案約 NT$330/月，但沒有免費方案。如果你搜尋「Microsoft Project 教學」，會發現它的學習曲線較陡，建議搭配官方手冊或線上課程入門。
- monday.com 或 ClickUp： 適合需要跨部門協作的團隊。甘特圖只是其中一個視圖，還能搭配看板、時間軸、儀表板等多種檢視方式。
里程碑設定原則： 每 2-4 週至少設定一個里程碑。里程碑不是任務，而是「某個階段性成果已完成」的檢查點。例如「需求文件簽核完成」「Beta 版本交付測試」。沒有里程碑的專案就像沒有路標的公路——你不知道自己走了多遠。
常見錯誤： 只列任務不排時程，或排了時程卻沒考慮任務依賴關係。結果就是三個任務同時需要同一個設計師，資源衝突到處爆發。
3. 資源與預算規劃
資源規劃的第一步是盤點。一份完整的資源盤點清單應涵蓋四大類：
- 人力資源： 每個角色需要投入多少工時？是全職還是兼職參與？例如「UI 設計師 0.5 FTE，為期 8 週」。
- 設備與環境： 測試伺服器、會議室、專用硬體等。
- 軟體授權： 專案管理工具、設計軟體、雲端服務等月費或年費。
- 外包費用： 委外翻譯、外部顧問、第三方測試等。
預算編列有兩種主要方式：
由下而上估算（Bottom-up）： 從 WBS 最底層的每個任務逐一估算成本，再加總得出總預算。精確度高，但耗時較長，適合需要嚴格成本控管的專案。
類比估算（Analogous）： 參考過去類似專案的實際花費，按比例調整。速度快，但精確度取決於歷史資料的品質。適合專案初期、細節尚未確定時的粗估。
實務上，建議設立 10% 預備金（Contingency Reserve）。大型建設專案因為材料價格波動大，預備金甚至可能需要提高到 15-20%。這筆錢不是「多出來的預算」，而是應對不確定性的保險。
常見錯誤： 未預留緩衝預算，導致任何一個小意外都直接衝擊專案底線。另一個常見問題是人力資源重複分配——同一個人同時被分配到三個專案，每個專案都以為他是全職投入，結果每個專案都延誤。
成本控管建議： 設立預警閾值。例如：當某個任務的實際支出超過預算 15% 時，自動觸發檢討會議。在 monday.com 的自動化功能中，你可以設定當預算欄位超過特定數值時自動通知 PM 和財務負責人，不需要人工盯著試算表。
4. 風險管理計劃
風險管理不是「想到什麼寫什麼」，而是需要系統性的辨識方法。兩個最實用的做法：
腦力激盪法： 召集核心團隊成員，用 20-30 分鐘列出所有可能出錯的事情。不要在這個階段評判「這個風險不太可能發生」——先求數量，再求品質。
歷史專案回顧： 翻出過去類似專案的結案報告，看看當時遇到了哪些問題。歷史不一定會重演，但它會押韻。
辨識完風險後，用風險矩陣（Risk Matrix）進行分類。這是一個 2×2 的四象限分類：
- 高機率 × 高影響（紅色區）： 必須立即制定應變計劃，指定專人負責監控。例如：關鍵供應商可能斷貨。
- 高機率 × 低影響（黃色區）： 制定簡單的應對措施即可。例如：會議室臨時被佔用。
- 低機率 × 高影響（黃色區）： 準備備案但不需要每天監控。例如：核心工程師離職。
- 低機率 × 低影響（綠色區）： 記錄即可，不需要投入太多資源。
以 IT 系統導入專案為例，常見的 5 項風險：
| 風險項目 | 發生機率 | 影響程度 | 應對策略 |
|---|---|---|---|
| 使用者抗拒新系統 | 高 | 高 | 提前舉辦教育訓練、指定各部門種子使用者 |
| 資料遷移過程中遺失資料 | 中 | 高 | 遷移前完整備份、分批遷移並逐批驗證 |
| 第三方 API 串接延遲 | 中 | 中 | 預留 2 週緩衝時間、準備替代方案 |
| 測試環境與正式環境差異 | 低 | 高 | 建立與正式環境一致的測試環境 |
| 專案預算追加審批延遲 | 低 | 中 | 提前與財務部門溝通審批流程 |
常見錯誤： 第一，只辨識風險不制定應變計劃——風險清單變成一份「擔心清單」，沒有任何行動方案。第二，風險清單做完後從未更新——專案進行到第三個月，當初辨識的風險有些已經消失，新的風險卻沒有被加進來。建議每次里程碑檢討時同步更新風險登錄表。
5. 溝通與利害關係人管理
再好的計劃，如果團隊不知道、利害關係人不認同，就等於沒有計劃。溝通管理是讓計劃「活起來」的關鍵。
第一步是做利害關係人分析。用「影響力 vs 關注度」矩陣來分類：
- 高影響力 × 高關注度： 密切管理（例如：專案發起人、主要客戶）→ 每週一對一更新
- 高影響力 × 低關注度： 保持滿意（例如：高階主管）→ 每月摘要報告
- 低影響力 × 高關注度： 保持知情（例如：終端使用者代表）→ 每雙週進度通知
- 低影響力 × 低關注度： 監控即可（例如：其他部門同事）→ 有重大變更時通知
接著建立溝通計劃。一份實用的溝通計劃表應包含：
| 溝通對象 | 頻率 | 方式 | 負責人 | 資訊內容 |
|---|---|---|---|---|
| 專案發起人 | 每週 | 一對一會議 | PM | 進度摘要、風險更新、決策需求 |
| 核心團隊 | 每日 | 站立會議（15 分鐘） | Scrum Master / PM | 昨日完成、今日計劃、阻礙 |
| 跨部門利害關係人 | 每雙週 | 進度報告 email | PM | 里程碑達成狀況、預算使用率 |
| 客戶 | 每月 | 正式簡報 | PM + 業務 | 交付物展示、下階段規劃 |
在跨部門專案中，定期週會搭配會議紀錄發送是基本功。但關鍵不在於「開了多少會」，而在於「每次會議是否產出決策」。建議每份會議紀錄都包含三個欄位：決議事項、負責人、完成期限。
常見錯誤： 只對上溝通忽略執行層——PM 每週向主管報告進度，但第一線執行人員不清楚整體方向與變更。另一個問題是會議過多但無決策產出——團隊花大量時間開會，卻沒有人拍板，問題一直懸而未決。如果一場會議結束時沒有任何 action item，這場會議就不該開。
如何制定專案計劃：7 步驟完整教學
步驟 1：確認專案目標與範圍
前置條件： 取得專案發起人（Sponsor）的正式授權，確認預算上限與時間限制。沒有授權就開始規劃，等於在沙灘上蓋房子。
操作說明： 進行利害關係人訪談，這是整個計劃流程中最容易被跳過、卻最不該被跳過的步驟。訪談時必問的 5 個問題：
- 這個專案成功的定義是什麼？（釐清目標）
- 哪些事情絕對不能做？（釐清範圍邊界）
- 你最擔心什麼風險？（提前辨識風險）
- 你期望多久收到一次進度更新？（建立溝通預期）
- 如果只能選一個最重要的交付物，你會選什麼？（確認優先順序）
輸出產出： 專案章程（Project Charter）或範圍說明書。專案章程是一份 1-2 頁的摘要文件，包含專案目的、主要交付物、時間與預算限制、關鍵利害關係人。它不需要很長，但必須經過發起人簽核。
常見錯誤： 跳過利害關係人訪談，PM 自己假設目標後直接開始排程。結果做到一半才發現主管想要的跟你規劃的完全不同。
步驟 2：任務分解與排程
前置條件： 範圍已確認並取得簽核、核心團隊成員已確定。
操作說明： 先用 WBS 進行三層拆解（專案 → 階段 → 任務），再用甘特圖排定時程，最後確認每個任務的負責人。
這個步驟建議邀請核心團隊成員一起參與，而不是 PM 一個人閉門造車。原因很簡單：負責執行的人最清楚一個任務需要多少時間。PM 估計「設計一張海報需要 2 天」，但設計師可能告訴你「加上修改至少要 5 天」。
工具建議： 5 人以下的小型專案，用 Google Sheets 建立簡易甘特圖就夠了。如果團隊超過 10 人或有複雜的任務依賴關係，建議使用 monday.com 的甘特圖視圖——拖拉任務就能自動調整依賴關係，比手動更新試算表省力得多。（推薦試試 monday.com 的免費方案，不需要信用卡，我們團隊實際使用後排程效率提升明顯。）
輸出產出： 任務清單（含負責人、起迄日期、依賴關係）。
步驟 3：資源與預算規劃
前置條件： 任務清單已完成。
操作說明： 逐任務估算所需的人力工時與費用。例如：「UI 設計：設計師 40 小時 × NT$800/小時 = NT$32,000」。把所有任務的成本加總後，再加上 10% 預備金，就是你的專案總預算。
如果團隊成員同時參與多個專案，務必在這個步驟確認每個人的可用工時。一個常見的做法是用資源分配表，標示每個人在每週的投入百分比。
輸出產出： 資源分配表、預算明細表。
步驟 4：風險辨識與應對規劃
前置條件： 任務清單與預算草案已完成（因為很多風險來自時程壓力與預算限制）。
操作說明： 召集團隊進行 30 分鐘的腦力激盪，列出所有可能出錯的事情。接著把每個風險填入風險矩陣，評估發生機率與影響程度。針對落在紅色區（高機率 × 高影響）的風險，必須指定負責人並制定具體的應變計劃。
輸出產出： 風險登錄表（Risk Register），包含風險描述、機率、影響、應對策略、負責人、更新日期。
步驟 5：建立溝通與協作機制
操作說明： 根據利害關係人分析的結果，確認每個對象的回報頻率與方式。選定團隊的協作工具（例如用 monday.com 追蹤任務、用 Slack 即時溝通、用 Google Meet 開週會）。最重要的是設計問題升級流程：當執行層遇到無法自行解決的阻礙時，應該在多少時間內升級給誰？
輸出產出： 溝通計劃表（含對象、頻率、方式、負責人、資訊內容）。
步驟 6：書面化並取得共識
操作說明： 把前五個步驟的所有產出彙整成一份完整的專案計劃書。計劃書的格式可以參考專案報告的架構，但重點不在格式多漂亮，而在內容是否完整且可執行。
完成後，召開啟動會議（Kick-off Meeting）。這場會議的目的不是「念一遍計劃書」，而是確認每個人都理解自己的角色、任務與時程，並且有機會提出疑問。如果你需要啟動會議的議程範本，可以參考 Notion 的 Kick-off 會議模板。
常見錯誤： 計劃書只有 PM 看過，團隊成員從未參與確認。結果執行時才發現某個任務的時程根本不合理，但已經來不及調整。
步驟 7：執行中持續監控與調整
操作說明： 專案啟動後，每週或每雙週檢視計劃與實際的落差。常用的追蹤方式包括：
- 完成百分比： 每個任務目前完成了多少？與預定進度相比是超前還是落後？
- 燃盡圖（Burndown Chart）： 特別適合敏捷專案，顯示剩餘工作量隨時間遞減的趨勢。如果曲線高於理想線，代表進度落後。
- 掙值管理（EVM）： 進階做法，同時追蹤時程與成本的偏差。
某金融業專案團隊在導入系統時，每兩週召開一次計劃檢討會議。在第三次檢討中，他們發現資料遷移的速度比預期快 20%，於是將省下的時間重新分配給使用者教育訓練。最終系統提前兩週上線，使用者滿意度也高於預期。這就是「活文件」的價值——計劃不是用來限制你的，而是用來幫你做更好的決策。
常見錯誤： 計劃書做完後從未更新，成為「殭屍文件」。三個月後回頭看，計劃書上的時程、預算、風險清單全部與現實脫節，形同虛設。
傳統瀑布式 vs 敏捷式專案計劃的差異
上述 7 步驟是以傳統瀑布式（Waterfall）專案管理為基礎的做法——先完成完整規劃，再依序執行。但如果你的團隊採用敏捷（Agile）方法論，計劃的制定方式會有顯著不同。
傳統瀑布式： 在專案啟動階段就完成詳細的全程規劃，包含完整的 WBS、甘特圖與預算。適合需求明確、變動性低的專案，例如建築工程、法規遵循專案。
敏捷式： 只做高層級的 Roadmap 規劃，細節留給每個 Sprint（通常 2-4 週）的 Sprint Planning 來決定。適合需求會持續演化的專案，例如軟體開發、產品迭代。
| 比較項目 | 瀑布式計劃 | 敏捷式計劃 |
|---|---|---|
| 規劃時機 | 專案初期一次完成 | 每個 Sprint 迭代規劃 |
| 計劃細節度 | 高（完整 WBS + 甘特圖） | 高層級 Roadmap + Sprint Backlog |
| 變更管理 | 正式變更流程 | 每個 Sprint 自然調整 |
| 適合情境 | 需求明確、法規嚴格 | 需求演化、快速迭代 |
| 風險應對 | 前期辨識、全程監控 | 每個 Sprint 回顧並調整 |
實務上，很多團隊會混合使用。例如：用瀑布式做整體時程與預算規劃，但在執行階段採用 Sprint 迭代。這種混合模式在台灣企業中非常常見，尤其是 IT 部門需要配合公司年度預算制度的情境。
如果你的團隊正在考慮從傳統轉向敏捷，建議先從一個小型專案試行，累積經驗後再逐步擴大。設定 OKR 作為目標管理框架，能讓敏捷團隊在保持彈性的同時不失方向感。
專案計劃工具比較與選擇指南
5 款主流工具功能與價格比較
| 工具 | 適合規模 | 核心功能 | 月費（NT$） | 免費方案 |
|---|---|---|---|---|
| monday.com | 中大型團隊（5-200人） | 甘特圖、看板、自動化、時間追蹤、儀表板 | 基本方案約 NT$450/人/月 | ✅ 有（最多 2 人） |
| ClickUp | 多專案並行團隊 | 甘特圖、看板、目標追蹤、文件協作、白板 | 付費約 NT$250/人/月 | ✅ 有（功能完整） |
| Microsoft Project | 大型/複雜專案 | 甘特圖、關鍵路徑、資源平衡、成本控制 | Plan 1 約 NT$330/月 | ❌ 無 |
| Notion | 小型團隊/個人 | 資料庫、知識管理、模板自訂、時間軸 | 付費約 NT$270/人/月 | ✅ 有（個人免費） |
| Google Sheets / Excel | 初學者/小型專案 | 自訂表格、公式計算、基本圖表 | 免費（Google）/ 含 Microsoft 365 | ✅ |
如何根據專案規模選擇工具
選工具不需要糾結太久，問自己三個問題就能快速判斷：
問題 1：團隊人數超過 10 人嗎？
如果是，你需要專用的專案管理工具。Google Sheets 在 10 人以上的協作場景中會變得混亂——誰改了什麼、什麼時候改的，很難追蹤。
問題 2：有複雜的任務依賴關係嗎？（超過 20 個任務互相牽制）
如果是，考慮 Microsoft Project。它的關鍵路徑計算與資源平衡功能是其他工具難以匹敵的。但如果你的團隊更重視協作體驗而非排程精密度，monday.com 的甘特圖加上自動化規則也能處理大部分依賴關係。
問題 3：預算有限且專案週期短（3 個月以內）？
如果是，先用 Google Sheets 或 ClickUp 免費方案。不需要為了一個短期專案購買昂貴的軟體授權。
專案管理工具比較
選擇 2-4 個工具，即時對比功能與價格
我們團隊實際使用 monday.com 管理日常專案已經超過一年。最讓我們驚豔的是自動化功能——PM 設定了一條規則：「任務延遲超過 2 天，自動通知負責人和 PM」。這個設定在 6 個月內觸發了 23 次，每次都讓問題在擴大前被處理。以前這些延遲要等到週會才會被發現，往往已經影響到下游任務。
如果你的團隊跑 Scrum，ClickUp 的 Sprint 管理功能值得一試。它內建 Sprint 點數追蹤、燃盡圖和 Sprint 回顧模板，對技術團隊來說非常順手。
結論
專案計劃不是一份做完就束之高閣的文件，而是團隊執行的引擎。掌握以下重點，你就能制定出真正有用的計劃：
- 目標明確： 用 SMART 原則設定可衡量的目標，用 IN/OUT scope 表格界定範圍邊界，從源頭杜絕範圍蔓延
- 分工清晰： 透過 WBS 三層拆解把大目標變成可執行的小任務，用甘特圖排定時程與依賴關係，每個任務都有明確的負責人與截止日期
- 風險可控： 用風險矩陣分類並制定應對策略，設立預算預警閾值，讓問題在擴大前被攔截
- 溝通到位： 根據利害關係人分析建立溝通計劃，確保每場會議都有決策產出
- 持續調整： 每 2-4 週檢視計劃與實際落差，讓計劃書始終是「活文件」而非「殭屍文件」
下一步行動：打開 monday.com，用「專案管理」模板建立新看板，填入你的專案目標、任務清單與里程碑。免費方案不需要信用卡，10 分鐘就能建好你的第一個專案框架。把這篇文章的方法論付諸實踐，從今天開始讓計劃成為團隊高效前進的助力。
如果你需要更完整的書面格式參考，可以進一步閱讀企劃書的撰寫教學。
專案計劃常見問題 FAQ
專案計劃書應該包含哪些內容？
一份完整的專案計劃書應包含：專案章程（目的與授權）、範圍說明書（IN/OUT scope）、WBS 與甘特圖（任務分解與時程）、資源分配表與預算明細、風險登錄表、溝通計劃表。小型專案可以精簡為 3-5 頁，大型專案則可能需要 20 頁以上。
專案計劃與專案管理有何不同？
專案計劃是專案管理的一部分，聚焦於規劃階段，產出目標、時程、資源、風險等文件。專案管理則涵蓋啟動、規劃、執行、監控、收尾五大流程群組。計劃是管理的基礎，但不等於管理的全部。
如何用 Microsoft Project 製作專案計劃？
在 Microsoft Project 中，先建立任務清單並設定 WBS 層級，接著為每個任務指定工期與資源，再透過「前置任務」欄位設定依賴關係。軟體會自動產生甘特圖與關鍵路徑。Plan 1 方案約 NT$330/月，適合需要嚴謹排程管理的中大型專案。
小型專案需要正式的專案計劃嗎？
需要，但細緻度可以大幅簡化。3-5 人的小型專案，一份 1-2 頁的計劃摘要（含目標、任務清單、時程、負責人）就足夠。重點不在文件多厚，而在團隊是否對目標與分工有共識。用 Google Sheets 或 Notion 就能輕鬆管理。
專案計劃何時需要調整？
當以下情況發生時應立即檢視並調整：專案目標或範圍變更、關鍵資源異動（例如核心成員離職）、預算超支超過預警閾值、外部環境重大變化（例如法規修改）、里程碑檢討發現進度嚴重偏差。建議至少每 2-4 週進行一次計劃檢討。
如何避免專案計劃僵化？
三個做法：第一，在計劃中預留 10-15% 的時間與預算緩衝；第二，建立正式但輕量的變更管理流程，讓調整有據可循而非隨意更改；第三，每次里程碑檢討時同步更新計劃書，確保文件反映最新狀態。鼓勵團隊成員主動提出調整建議，而非被動等待 PM 發現問題。
敏捷專案的計劃方式與傳統有何不同？
傳統瀑布式在專案初期完成詳細全程規劃；敏捷式只做高層級 Roadmap，細節留給每個 Sprint（2-4 週）的 Sprint Planning 決定。敏捷計劃強調「剛好足夠」的前期規劃與持續調整，適合需求會演化的軟體開發或產品迭代專案。兩者可以混合使用。
