【專案階段】五大階段完整教學｜含交付物清單與工具比較

專案階段（Project Phases）是將專案從構想到完成，依照管理流程劃分為啟動、規劃、執行、監控與控制、結案五個步驟的標準框架。 本文完整解析每個階段的關鍵交付物、Phase Gate 判斷標準、SPI/CPI 監控指標，並附工具比較表與不同規模團隊的實務建議。

專案階段的定義與核心概念

專案階段是專案管理流程中最基礎的結構單位。根據 PMBOK（Project Management Body of Knowledge）標準，一個專案從開始到結束，會經歷五個主要階段：

1. 啟動（Initiation）——確立專案可行性，取得正式授權
2. 規劃（Planning）——建立可執行的專案藍圖
3. 執行（Execution）——將計畫轉化為實際產出
4. 監控與控制（Monitoring & Controlling）——確保專案不偏離目標
5. 結案（Closure）——正式完成專案，沉澱經驗

為什麼需要劃分階段？三個核心原因：

• 降低風險：每個階段結束時設有檢查點（Phase Gate），在投入更多資源前確認方向正確
• 提升透明度：利害關係人可以清楚知道專案目前在哪個階段、預期何時完成
• 便於資源分配：不同階段需要不同的人力與預算配置，劃分階段讓資源調度更精準

這套五大階段框架是目前全球最廣泛採用的標準，無論你管理的是 IT 導入專案、行銷活動還是建設工程，都能以此為骨架進行調整。

專案階段 vs. 專案生命週期：有什麼不同？

這兩個概念經常被混用，但它們的層級不同。簡單來說：專案生命週期是描述專案從誕生到結束的「概念框架」，而專案階段是在這個框架下的「具體執行步驟」。

比較項目	專案生命週期（Project Life Cycle）	專案階段（Project Phases）
本質	概念模型，描述專案的整體演進	具體步驟，定義每個時期該做什麼
層級	上層框架	框架內的組成單位
彈性	可選擇預測型、敏捷型、混合型等模型	在選定的模型下，定義具體的階段內容
交付物	不直接產出文件	每個階段有明確的交付物（如 Project Charter、WBS）
類比	像一本書的「章節架構」	像每一章的「具體內容」

理解這個差異的實務意義在於：當主管問你「這個專案的生命週期是什麼？」他想知道的是整體策略（預測型還是敏捷型）；當他問「現在在哪個階段？」他想知道的是具體進度。

五大專案階段總覽

在深入每個階段之前，先用一張表掌握全貌。這張表可以直接當作你的專案規劃參考：

階段	主要目標	關鍵交付物	建議時間佔比	推薦工具
啟動	確立可行性、取得授權	Project Charter、利害關係人登記表	5-10%	monday.com、Notion
規劃	建立可執行藍圖	專案計畫書、WBS、甘特圖、風險登記表	20-30%	ClickUp、monday.com
執行	將計畫轉化為產出	各項交付物、進度報告、會議記錄	35-45%	monday.com、Notion
監控與控制	確保不偏離目標	進度報告、變更請求記錄、品質檢查清單	與執行同步進行	monday.com、ClickUp
結案	正式完成、沉澱經驗	驗收文件、Lessons Learned Report、歸檔	5-10%	Notion、SignNow

關於 Phase Gate（階段關卡）：每個階段結束時，都需要通過一個正式的檢查點，才能進入下一階段。Phase Gate 的核心問題是：「這個階段的交付物是否完成？是否達到進入下一階段的標準？」

Phase Gate 的判斷通常包含三個要素：

• 交付物完成度：該階段的必要文件是否已產出並獲得核准？
• 品質標準：產出是否符合預期的品質要求？
• 利害關係人共識：關鍵決策者是否同意繼續推進？

不同專案規模的階段彈性也不同。5 人以下的小型專案可以合併啟動與規劃階段，用一份精簡的 Project Charter 涵蓋兩者；20 人以上的大型專案則需要嚴格分階段，每個 Phase Gate 都要有正式的審查會議與簽核流程。

啟動階段（Initiation）：如何定義專案目標與取得授權

啟動階段的核心任務是回答一個問題：這個專案值得做嗎？ 在這個階段，你需要確立專案的可行性、定義範疇，並取得正式授權。

關鍵交付物：Project Charter

Project Charter（專案章程）是啟動階段最重要的文件，它是專案的「出生證明」。一份完整的 Project Charter 應包含以下 6 個必填欄位：

1. 專案目標：這個專案要達成什麼？用 SMART 原則描述（例如：「在 Q3 結束前上線新版客戶管理系統，將客服回應時間從 24 小時縮短至 4 小時」）
2. 專案範疇：包含什麼、不包含什麼（明確寫出排除項目，避免後續範疇蔓延）
3. 預算估算：初步預算範圍（啟動階段通常是粗估，±30% 的準確度即可）
4. 時程概估：預計開始與結束日期、主要里程碑
5. 利害關係人：專案發起人、核心團隊、受影響的部門
6. 成功標準：如何判斷專案成功？用可量化的指標定義

在 monday.com 上，你可以用「Project Management」模板快速建立專案看板，將上述 6 個欄位設為自訂欄位。我們團隊的做法是在看板最上方建立一個「專案章程」群組，每個欄位對應一個項目，這樣所有利害關係人打開看板就能一目了然。

利害關係人分析：影響力 vs. 關注度矩陣

辨識利害關係人不只是列出名單，更重要的是判斷每個人需要什麼程度的溝通與管理。影響力 vs. 關注度矩陣將利害關係人分為四個象限：

	高關注度	低關注度
高影響力	密切管理（如：專案發起人、直屬主管）→ 定期一對一更新	保持滿意（如：高階主管）→ 定期摘要報告
低影響力	保持知情（如：終端使用者）→ 定期群發更新	最低監控（如：間接相關部門）→ 有重大變更時通知

台灣常見的兩種啟動情境

在台灣職場，專案啟動通常來自兩種情境，處理方式截然不同：

情境一：主管臨時指派
「下週開始做 XX 專案，你負責。」——這是台灣最常見的啟動方式。問題在於目標模糊、範疇不明。這時你的第一步不是開始規劃，而是向上確認：用 30 分鐘和主管對齊 Project Charter 的 6 個欄位，至少確認目標和範疇。

情境二：客戶 RFP（需求建議書）
客戶發來 RFP，你需要在限定時間內回覆提案。這種情境的啟動階段更正式，需要先做可行性評估（技術可行性、資源可行性、財務可行性），再決定是否投標。

啟動階段常見卡關：需求不明確怎麼辦？

需求不明確是啟動階段最常見的卡關點。以下是 5 個必問問題，幫助你在模糊中找到方向：

1. 「這個專案要解決什麼問題？」——不是「要做什麼功能」，而是「要解決什麼痛點」
2. 「成功的樣子是什麼？」——請利害關係人描述專案完成後的理想狀態
3. 「什麼是絕對不能妥協的？」——找出硬性限制（預算上限、法規要求、上線日期）
4. 「誰是最終決策者？」——避免做到一半才發現真正的決策者不同意
5. 「有沒有類似的專案可以參考？」——從過去經驗中找到基準

實務上，你可以用 monday.com 的表單功能建立一份「需求收集表單」，將這 5 個問題設為必填欄位，發送給所有利害關係人填寫。回收後在看板上自動彙整，一眼就能看出哪些需求有共識、哪些有分歧。

規劃階段（Planning）：建立可執行的專案藍圖

規劃階段是五大階段中最容易被低估的一個。很多 PM 急著進入執行，結果因為規劃不足而反覆修改，最終花的時間比好好規劃還多。業界普遍建議規劃階段佔整體專案時間的 20-30%，確保後續執行有足夠的藍圖可依循。

關鍵交付物清單

規劃階段需要產出的文件最多，以下是核心交付物：

• 專案計畫書：整合所有規劃內容的主文件
• WBS（工作分解結構）：將專案目標拆解為可管理的工作包
• 甘特圖：視覺化的時程規劃
• 風險登記表：列出已識別的風險、發生機率、影響程度與應對策略
• 溝通計畫：誰需要什麼資訊、多久更新一次、用什麼管道

WBS 拆解原則

WBS 是規劃階段的骨幹。拆解的核心原則是：每個最底層的工作包（Work Package）不超過 80 小時的工作量。如果超過 80 小時，代表這個工作包還可以再拆。

拆解的層級通常是：

• Level 1：專案名稱
• Level 2：主要交付物或階段
• Level 3：工作包（可分配給個人或小組的具體任務）

風險評估：機率 × 影響矩陣

風險評估不是列出「可能會出問題」就好，而是要量化每個風險的嚴重程度。用機率 × 影響矩陣來分類：

	低影響	中影響	高影響
高機率	中風險：制定應對計畫	高風險：優先處理	極高風險：立即處理
中機率	低風險：持續監控	中風險：制定應對計畫	高風險：優先處理
低機率	極低風險：接受	低風險：持續監控	中風險：制定應對計畫

高風險項目的應對策略通常有四種：迴避（改變計畫消除風險）、轉移（外包或保險）、減緩（降低機率或影響）、接受（準備應急計畫但不主動處理）。

時間緩衝的設定

規劃階段建議在整體時程中加入 20-30% 的時間緩衝。這不是「偷懶的藉口」，而是基於現實的風險管理。在 ClickUp 中，你可以為每個任務設定「樂觀時間」和「悲觀時間」，系統會自動計算出建議的緩衝區間。

具體做法：在 ClickUp 的甘特圖視圖中，為關鍵路徑上的任務各加一個「緩衝任務」（Buffer Task），時長設為原任務的 20%。這樣當某個任務延遲時，緩衝任務會先吸收衝擊，不會立即影響整體時程。

規劃階段最常犯的錯：計畫過於理想化

一個 15 人的軟體開發團隊在規劃新產品上線時，將每個開發任務的時間估算都取「最佳情況」——前端開發 2 週、後端 3 週、測試 1 週，總計 6 週。結果實際執行時，前端因為設計稿三次修改延遲了 1 週，後端因為第三方 API 整合問題多花了 1.5 週，測試發現 12 個 bug 需要額外 0.5 週修復。最終延誤 3 週，超出原計畫 50%。

如果這個團隊在規劃時加入 25% 的緩衝（6 週 × 25% = 1.5 週），並用 ClickUp 的關鍵路徑功能提前識別「後端 API 整合」是最高風險的任務，就能在第一週就啟動備案（例如：平行開發替代方案），而不是等到延遲發生才被動反應。

（推薦試試 ClickUp 的甘特圖模板，免費版就能設定任務依賴關係和關鍵路徑。）

執行階段（Execution）：將計畫轉化為實際產出

執行階段佔整體專案時間的 35-45%，是投入資源最多的階段。這個階段的核心挑戰不是「做不做得出來」，而是「如何在變動中保持方向」。

溝通節奏建議

有效的溝通節奏是執行階段的生命線。以下是經過實務驗證的建議格式：

每日站立會議（Daily Standup）——5-15 分鐘

• 每人回答三個問題：昨天完成什麼？今天要做什麼？有什麼阻礙？
• 不討論解決方案（有阻礙的人會後另約時間處理）

週進度會議（Weekly Status Meeting）——30-60 分鐘

• 整體進度 vs. 計畫的差異
• 本週完成的里程碑
• 下週的重點任務與風險
• 需要決策的事項

在 monday.com 上，你可以用多種視角來追蹤執行進度：看板視圖適合每日站立會議（一眼看到每個任務的狀態）、甘特圖視圖適合週會（檢視整體時程是否偏移）、時間軸視圖適合向高階主管報告（呈現里程碑與關鍵日期）。

需求變更管理流程

執行階段最頭痛的問題之一就是需求變更。沒有變更管理流程的團隊，往往陷入「做了改、改了做」的惡性循環。以下是 4 步驟變更管理流程：

1. 變更申請：任何人提出變更需求，必須填寫變更申請表（包含：變更內容、提出原因、期望效果）
2. 影響評估：PM 評估這個變更對時程、預算、範疇的影響（例如：「新增這個功能需要額外 2 週開發時間和 NT$50,000 預算」）
3. 核准：由專案發起人或變更控制委員會決定是否執行
4. 更新計畫：核准後，更新專案計畫書、甘特圖、預算表，並通知所有相關人員

在 monday.com 上，你可以建立一個「變更控制板」，每個變更請求是一個項目，欄位包含：申請人、變更描述、影響評估、狀態（待評估/已核准/已拒絕/已執行）。設定自動化規則：當狀態變更為「已核准」時，自動通知所有團隊成員。

執行階段最常見的三個危機與應對

危機一：任務延誤
當某個任務延遲時，不要急著加班趕工。先用 monday.com 的工作負載視圖檢查：是這個人超載了，還是任務本身被低估了？如果是超載，重新排序優先級，將非關鍵路徑的任務延後；如果是低估，調整時程並通知利害關係人。

危機二：資源衝突
多個專案共用同一批人力時，資源衝突幾乎無法避免。在 monday.com 的工作負載視圖中，你可以看到每個人在不同專案中的工時分配。當某人的工時超過 100% 時，系統會以紅色標示，讓你在問題惡化前就能介入調整。

危機三：需求頻繁變更
如果變更頻率高到影響執行效率（例如每週超過 3 個變更請求），這通常代表啟動或規劃階段的需求確認不夠紮實。短期應對：設定「變更凍結期」（例如 Sprint 進行中不接受新變更）；長期改善：在下一個專案的啟動階段投入更多時間做需求確認。

執行階段也會涉及大量文件處理，例如合約簽署、驗收確認等。pdfFiller 可以處理合約與驗收文件的電子填寫與簽署，省去列印、掃描的來回時間。

監控與控制階段（Monitoring & Controlling）：用數據驅動專案決策

監控與控制不是一個獨立的時間段，而是與執行階段同步進行的持續活動。這是台灣 PM 最薄弱的環節——很多人只靠「感覺」判斷專案是否正常，而不是靠數據。

具體監控指標：SPI 與 CPI

兩個最核心的監控指標是 SPI（進度績效指標）和 CPI（成本績效指標），這兩個指標源自實獲值管理（Earned Value Management, EVM）方法論：

SPI（Schedule Performance Index）= EV ÷ PV

• EV（Earned Value，實獲值）：截至目前，已完成工作的計畫價值
• PV（Planned Value，計畫值）：截至目前，計畫應完成工作的價值
• SPI > 1.0：進度超前 ✅
• SPI 0.9-1.0：進度正常 ✅
• SPI < 0.9：進度落後，需要警示 ⚠️

CPI（Cost Performance Index）= EV ÷ AC

• EV（Earned Value，實獲值）：截至目前，已完成工作的計畫價值
• AC（Actual Cost，實際成本）：截至目前，實際花費的成本
• CPI > 1.0：低於預算（花得比預期少）✅
• CPI 0.8-1.0：成本正常 ✅
• CPI < 0.8：成本超支，需立即處理 🚨

舉例：一個預算 NT$1,000,000 的專案，執行到第 8 週（計畫總工期 16 週）時，PV = NT$500,000（計畫應完成的工作價值）。如果實際完成了 NT$450,000 的工作量（EV = NT$450,000），SPI = 450,000 ÷ 500,000 = 0.9，代表進度稍微落後。同時已花費 NT$550,000（AC = NT$550,000），CPI = 450,000 ÷ 550,000 = 0.82，代表成本超支，需要立即檢視原因。

在 monday.com 儀表板設定監控 Widget

在 monday.com 的儀表板中，建議加入以下 5 個 Widget，讓你一打開就能掌握專案健康度：

1. 任務完成率圓餅圖：已完成 / 進行中 / 未開始的任務比例
2. 時程偏差長條圖：每個工作包的計畫完成日 vs. 實際完成日
3. 資源負載熱力圖：每個團隊成員的工時分配（紅色 = 超載）
4. 風險狀態追蹤表：高風險項目的當前狀態與應對進度
5. 里程碑時間軸：關鍵里程碑的預計日期與實際達成日期

監控頻率建議

• 短期專案（3 個月以內）：每週監控一次，每週五下午花 30 分鐘更新儀表板數據
• 長期專案（6 個月以上）：每兩週監控一次，搭配雙週進度報告
• 高風險專案（不論長短）：每日監控關鍵路徑任務的進度

發現專案偏軌時的 5 步驟處理流程

1. 識別偏差：透過 SPI/CPI 或儀表板發現異常數據
2. 分析根因：是人力不足？需求變更？技術障礙？還是估算錯誤？
3. 評估影響：這個偏差會影響最終交付日期嗎？會超出預算多少？
4. 提出調整方案：至少準備兩個方案（例如：方案 A 加人趕工、方案 B 縮減範疇），各附上時程與成本影響
5. 更新計畫並通知利害關係人：選定方案後，更新所有相關文件，並在 24 小時內通知所有利害關係人

結案階段（Closure）：知識沉澱才是長期價值

結案不只是「東西交出去就好」。一個好的結案階段，能讓團隊在下一個專案少走大量的彎路。

關鍵交付物

• 驗收文件：客戶或發起人正式簽署確認專案交付物符合要求
• Lessons Learned Report：記錄專案中的成功經驗與失敗教訓
• 資源釋放通知：正式通知相關部門，團隊成員可以回歸原單位或投入新專案
• 專案歸檔：所有文件、會議記錄、決策紀錄歸檔至知識庫

專案回顧會議（Retrospective）建議議程

一場有效的回顧會議建議控制在 60 分鐘內，議程如下：

議程項目	時間	說明
What went well（做得好的）	15 分鐘	每人列出 2-3 個成功經驗
What didn’t go well（做得不好的）	15 分鐘	每人列出 2-3 個問題，不指責個人
What to improve（可以改善的）	15 分鐘	針對問題提出具體改善建議
Action items（行動項目）	15 分鐘	將改善建議轉化為可執行的行動，指定負責人與期限

Lessons Learned Report 的建議結構

在 Notion 中建立 Lessons Learned Report，建議包含以下 6 個必填欄位：

1. 專案基本資訊：名稱、期間、團隊規模、預算
2. 目標達成度：原始目標 vs. 實際成果的對比
3. 成功因素：哪些做法值得在未來專案中複製？
4. 失敗教訓：哪些問題發生了？根因是什麼？
5. 流程改善建議：針對五大階段各提出 1-2 個改善點
6. 工具與技術建議：哪些工具好用？哪些需要更換？

將這些報告統一存放在 Notion 的知識庫中，按專案類型分類（IT 專案、行銷專案、產品開發專案），讓未來的 PM 可以快速搜尋參考。

驗收文件的簽署可以用 SignNow 處理，線上完成電子簽署，省去紙本來回的時間。對於想在結案後提升團隊能力的 PM，Coursera 上有豐富的專案管理課程，例如 PMP 備考課程或敏捷管理認證，適合在專案間的空檔安排團隊進修。

結案常被忽略的事：資源釋放與團隊表彰

資源釋放不只是口頭說「專案結束了」。正式的資源釋放流程包含：

• 通知人資部門更新人員配置
• 將專案相關的系統權限回收或轉移
• 確認所有外包合約已結案付款
• 歸還借用的設備或場地

團隊表彰則是最容易被忽略但影響深遠的環節。一封感謝信、一次團隊聚餐，甚至只是在全公司會議上公開肯定團隊的貢獻，都能讓成員在下一個專案中更有動力。正式的結案表彰不只是「好人好事」，它傳遞的訊號是：這個專案的努力被組織看見了，這對團隊士氣和留任率都有正面影響。

實務案例：中型科技公司的新產品開發專案

以下用一個虛構但貼近台灣實務的案例，示範五大階段如何串聯運作。

背景：一家 80 人的中型科技公司決定開發新版客戶管理系統（CRM），專案團隊 12 人，預算 NT$3,000,000，預計工期 6 個月。

啟動階段：PM 用 monday.com 建立專案看板，在最上方的「專案章程」群組填入 6 個必填欄位。專案目標設定為「在 Q3 結束前上線新版 CRM，將客服回應時間從 24 小時縮短至 4 小時」。利害關係人分析後，將業務副總歸類為「高影響力 × 高關注度」（密切管理），IT 部門主管歸類為「高影響力 × 低關注度」（保持滿意）。Phase Gate 判斷：Project Charter 經專案發起人（營運長）簽核後，正式進入規劃階段。

規劃階段：團隊花了 5 週（約佔總工期 20%）完成規劃。WBS 拆解為 4 個 Level 2 交付物（前端開發、後端開發、資料遷移、測試部署），再細分為 18 個工作包，每個不超過 80 小時。風險登記表識別出「第三方 API 整合」為高風險項目（高機率 × 高影響），應對策略為「減緩」——提前 2 週開始 API 技術驗證。甘特圖在 ClickUp 上建立，關鍵路徑為「後端開發 → API 整合 → 整合測試 → 部署」，並在每個關鍵路徑任務後加入 20% 的緩衝任務。Phase Gate 判斷：專案計畫書經指導委員會審查通過，確認預算與時程可行。

執行階段：團隊採用混合式方法——整體框架依五大階段推進，但開發工作以 2 週為一個 Sprint 迭代。每日 10 分鐘站立會議在 monday.com 看板視圖前進行，每兩週一次 Sprint 審查。第 3 個 Sprint 時，業務副總提出新增「客戶自助查詢」功能的變更請求。PM 啟動 4 步驟變更管理流程：評估影響為「增加 3 週開發時間、NT$350,000 預算」，提交變更控制委員會審議，最終核准執行並更新甘特圖。

監控與控制階段：PM 每兩週在 monday.com 儀表板更新 SPI 與 CPI。第 12 週時，SPI 降至 0.88（低於 0.9 警示線），根因分析發現是資料遷移的工作量被低估。PM 提出兩個調整方案：方案 A 增派 2 名工程師（成本增加 NT$200,000，時程不變）、方案 B 縮減資料遷移範圍至核心客戶資料（成本不變，但部分歷史資料延後處理）。指導委員會選擇方案 B，PM 在 24 小時內更新計畫並通知所有利害關係人。調整後 SPI 回升至 0.95，CPI 維持在 0.91。

結案階段：系統上線後，PM 在 Notion 建立 Lessons Learned Report，記錄三個關鍵教訓：（1）資料遷移的工作量估算應加入 30% 以上緩衝；（2）第三方 API 提前驗證的策略有效，值得複製；（3）變更管理流程成功控制了範疇蔓延，但變更評估時間可從 5 天壓縮至 3 天。回顧會議中，團隊將這三點轉化為具體 Action Items，指定負責人與期限，存入 Notion 知識庫供未來專案參考。最後，PM 發出資源釋放通知，並在月會上公開表彰團隊貢獻。

傳統瀑布式 vs. 敏捷式：專案階段如何調整？

五大階段是基於傳統瀑布式（Waterfall）方法論的框架，但在敏捷（Agile）和混合式（Hybrid）方法論下，階段的執行方式會有顯著差異。

三種方法論的階段差異

瀑布式（Waterfall）：五大階段線性執行，前一個階段完成後才進入下一個。適合需求明確、變更少的專案，例如建設工程、法規遵循專案、政府標案。

敏捷式（Agile）：啟動和結案階段保留，但規劃、執行、監控在每個 Sprint（通常 2-4 週）中反覆循環。適合需求不確定、需要快速迭代的軟體開發專案。

混合式（Hybrid）：結合兩者優點，在整體框架上採用瀑布式的階段劃分，但在執行階段內部採用敏捷式的迭代。這是台灣製造業、服務業、數位轉型專案最常見的做法。

比較項目	瀑布式	敏捷式	混合式
階段執行方式	線性、依序	啟動/結案線性，中間三階段每個 Sprint 循環	整體線性，執行階段內部迭代
適用情境	需求明確、變更少	需求不確定、需快速迭代	部分需求明確、部分需探索
優點	可預測性高、文件完整	彈性高、快速回應變化	兼顧可預測性與彈性
缺點	變更成本高、回應慢	文件較少、需要高度自律	管理複雜度較高
推薦工具	monday.com（甘特圖 + 時間軸）	ClickUp（Sprint + 看板）	monday.com（多視圖切換）

在台灣，純粹的瀑布式或純粹的敏捷式都比較少見。大多數團隊採用的是混合式——用瀑布式的框架向上管理（主管和客戶看得懂五大階段的進度報告），用敏捷式的方法向下執行（團隊內部跑 Sprint 快速迭代）。如果你的團隊正在從傳統瀑布式轉型，建議先從「執行階段內部導入 Sprint」開始，不需要一次全面改變。

各階段推薦工具比較

以下是根據不同專案階段需求整理的工具比較表。每個工具都有其最擅長的場景，選對工具比選貴的工具更重要。

monday.com：全流程首選

適用階段：啟動、執行、監控與控制（全流程覆蓋）

優點：

• 介面直覺，非技術背景的團隊成員也能快速上手
• 多視圖切換（看板、甘特圖、時間軸、工作負載）覆蓋所有階段需求
• 自動化規則強大——例如設定「任務延遲超過 2 天自動通知負責人和 PM」這類規則，可以讓問題在週會前就被發現，不需要等到進度回報時才知道有延遲
• 儀表板功能讓監控階段的數據視覺化變得簡單
• 免費方案不需要信用卡，最多 2 人使用

限制：

• 免費方案功能有限，3 人以上團隊需要付費（請參考 monday.com 官網最新定價）
• 甘特圖的任務依賴關係設定不如 ClickUp 細緻
• 進階報表功能需要 Pro 方案以上

適合情境：5-50 人的跨部門團隊，需要一個所有人都能用的協作平台。如果你只想試一個工具，從 monday.com 開始。

ClickUp：技術團隊的深度選擇

適用階段：規劃、監控與控制（特別擅長複雜規劃）

優點：

• 甘特圖的任務依賴關係和關鍵路徑功能是同類工具中最完整的
• Sprint 管理功能原生支援，適合跑 Scrum 的技術團隊
• 免費方案功能豐富，個人使用幾乎不受限
• 多維度報表適合需要深度數據分析的 PM

限制：

• 功能太多，學習曲線較陡——新手可能需要 1-2 週才能上手
• 介面對非技術背景的使用者不夠友善
• 行動版 App 體驗不如桌面版流暢

適合情境：5-15 人的技術團隊，跑 Scrum 或需要精細的排程管理。

Notion：知識管理與輕量協作

適用階段：啟動（Project Charter）、結案（知識庫）

優點：

• 頁面結構極度彈性，可以自由設計 Project Charter、Lessons Learned Report 等文件模板
• 知識庫功能強大，適合長期累積專案經驗
• 免費方案對個人使用者幾乎無限制
• 與其他工具整合度高

限制：

• 不是專業的專案管理工具——缺少甘特圖、關鍵路徑、資源負載等功能
• 任務管理功能較基礎，不適合複雜的多人協作
• 沒有原生的自動化規則

適合情境：5 人以下的小團隊或個人 PM，用來管理文件和知識庫，搭配 monday.com 或 ClickUp 使用效果最佳。

工具比較總表

比較項目	monday.com	ClickUp	Notion	pdfFiller	SignNow
最適用階段	全流程	規劃、監控	啟動、結案	執行（文件處理）	結案（驗收簽署）
核心功能	多視圖、自動化、儀表板	甘特圖、Sprint、報表	知識庫、文件模板	PDF 填寫與簽署	電子簽名
免費方案	2 人以下免費	個人免費	個人免費	有限免費試用	有限免費試用
付費方案	查看最新定價 →	查看最新定價 →	查看最新定價 →	查看最新定價 →	查看最新定價 →
適合團隊規模	5-50 人	5-15 人	1-5 人	不限	不限

你是哪種團隊？

• 5 人以下、剛開始接觸專案管理 → 先用 Notion 免費版建立基本框架
• 5-15 人跨部門協作 → monday.com（我們的首選，介面直覺、全流程覆蓋）
• 技術團隊跑 Scrum → ClickUp（Sprint 管理和甘特圖功能最強）
• 15 人以上的大型專案 → monday.com 企業方案（需詢價，支援進階權限管理和企業級安全）

結論

掌握專案五大階段不是理論練習，而是讓你的每一個專案都能有系統地推進、有數據地監控、有經驗地累積。以下是本文的核心重點：

• 啟動階段用 Project Charter 的 6 個必填欄位確立方向，用利害關係人矩陣決定溝通策略
• 規劃階段投入 20-30% 的專案時間，WBS 拆到每個工作包不超過 80 小時，並加入 20-30% 時間緩衝
• 執行階段建立每日站立 + 週會的溝通節奏，用 4 步驟變更管理流程控制需求蔓延
• 監控階段用 SPI 和 CPI 兩個指標量化專案健康度，SPI < 0.9 或 CPI < 0.8 就要立即介入
• 結案階段不只是交付，Lessons Learned Report 和團隊表彰才是長期價值所在

你的下一步：打開 monday.com，用「Project Management」模板建立新看板，在最上方新增一個「專案章程」群組，填入目標、範疇、預算、時程、利害關係人、成功標準這 6 個欄位。10 分鐘就能建好你的第一個專案框架，免費方案不需要信用卡。

專案階段常見問題（FAQ）

專案五大階段一定要按順序執行嗎？

不一定。五大階段的順序是理想框架，但實務上需要根據專案規模和方法論調整。5 人以下的小型專案可以合併啟動與規劃階段，用一份精簡的 Project Charter 涵蓋兩者的內容。敏捷式專案則保留啟動和結案的線性順序，但規劃、執行、監控三個階段在每個 Sprint 中反覆循環。關鍵原則是：無論怎麼調整，每個階段的核心交付物不能省略，只是可以簡化格式。

專案階段和專案生命週期有什麼差別？

專案生命週期是描述專案從誕生到結束的「概念框架」，它定義的是專案整體的演進模式（預測型、敏捷型、混合型等）。專案階段則是在這個框架下的「具體執行步驟」，每個階段有明確的目標、任務和交付物。簡單來說，生命週期是「地圖」，階段是「路線」。你可以參考我們的專案生命週期專文了解更多。

如何判斷可以進入下一個專案階段？

透過 Phase Gate（階段關卡）機制。每個階段結束時，需要檢查三件事：該階段的交付物是否完成並通過審查？產出是否符合預期的品質標準？關鍵利害關係人是否同意繼續推進？小型專案的 Phase Gate 可以是一封確認信或一次 15 分鐘的對齊會議；大型專案則需要正式的審查會議，由專案發起人或指導委員會簽核後才能進入下一階段。

小型專案（5 人以下）需要走完所有階段嗎？

需要走完，但可以大幅簡化。小型專案的啟動階段可以是一頁 A4 的 Project Charter（不需要寫 20 頁的專案章程）；規劃階段可以用一張簡單的任務清單取代完整的 WBS 和甘特圖；監控可以靠每日 5 分鐘的口頭更新而非正式的儀表板。重點是每個階段的「思考過程」不能省——你仍然需要想清楚目標、計畫、風險和經驗教訓，只是記錄的格式可以簡化。

專案監控階段最重要的指標是什麼？

SPI（進度績效指標）和 CPI（成本績效指標）是最核心的兩個指標。SPI 衡量的是「做了多少」vs.「計畫做多少」，CPI 衡量的是「花了多少」vs.「應該花多少」。如果你只能看一個指標，選 SPI——因為時程延誤通常會連帶造成成本超支，但成本超支不一定代表時程有問題。在 monday.com 的儀表板中，你可以用數字 Widget 即時顯示這兩個指標，設定當 SPI < 0.9 時自動發送警示通知。

結案階段最常被忽略的事情是什麼？

Lessons Learned Report 和資源釋放。大多數團隊在交付完成後就急著投入下一個專案，跳過了經驗沉澱的步驟。結果同樣的錯誤在下一個專案中重演。建議在專案結束後的一週內召開回顧會議，用「What went well / What didn’t / What to improve / Action items」的結構記錄經驗，並存入 Notion 知識庫。資源釋放也常被忽略——如果不正式通知人資和相關部門，團隊成員可能同時被兩個專案佔用，導致新專案的資源規劃失準。