專案里程碑（Milestone）是專案管理中標示關鍵節點的零工時檢查點，代表階段性成果的完成或重要決策的確認。 本文完整教學 5 步驟設定框架、3 大產業實務範例、Excel 里程碑圖製作法，以及延誤處理 SOP，附工具比較表幫你選對追蹤方式。
專案里程碑是什麼？（Milestone 定義與核心概念）
PMBOK 定義與 Milestone 英文原意
Milestone 這個詞源自羅馬帝國時期——羅馬人在道路旁每隔一英里（Roman mile）就豎立一塊石碑（stone），標記旅人已走了多遠、距離目的地還有多遠。這個概念被引入專案管理後，意義幾乎一模一樣：告訴團隊和利害關係人「我們走到哪裡了」。
根據 PMBOK（Project Management Body of Knowledge）的定義，里程碑是「專案中具有重要意義的事件或時間點，通常持續時間為零」。這個「零工時」的特性是理解里程碑最關鍵的一點——它不是一項需要執行的工作，而是一組工作完成後的「確認標記」。
在實務溝通中，你會常看到 M1、M2、M3 這樣的縮寫，代表 Milestone 1、Milestone 2、Milestone 3。例如專案章程中可能寫著「M3: UAT 完成」，意思是第三個里程碑是使用者驗收測試完成。這種縮寫在跨國團隊或英文文件中非常普遍，也常出現在甘特圖上以菱形符號（◆）標示。
里程碑 vs. 任務 vs. 交付物 vs. 甘特圖（四概念比較）
很多 PM 新手會把里程碑和任務搞混，或者不確定里程碑跟交付物的差別。以下用一張表格釐清這四個核心概念：
| 概念 | 定義 | 有無工時 | 範例 | 在甘特圖中的呈現 |
|---|---|---|---|---|
| 任務（Task） | 具體需要執行的工作項目 | ✅ 有（如 3 天、8 小時） | 撰寫測試計畫 | 橫條（bar） |
| 交付物（Deliverable） | 專案過程中產出的具體成果 | ✅ 有（需要工時才能產出） | 測試報告、UI 設計稿 | 通常不單獨顯示 |
| 里程碑（Milestone） | 標示專案關鍵節點的檢查點 | ❌ 無（持續時間為零） | UAT 測試完成、需求凍結 | 菱形符號（◆） |
| 甘特圖（Gantt Chart） | 視覺化排程工具 | — 本身是工具，不是事件 | 整個專案的時間軸視圖 | 就是甘特圖本身 |
簡單記：任務是「做什麼」，交付物是「產出什麼」，里程碑是「什麼時候確認完成了」，而甘特圖是「把這些全部畫出來」的工具。
里程碑在專案管理甘特圖中通常以菱形符號呈現，而不是像任務那樣用橫條表示。這是因為里程碑沒有持續時間，它只是時間軸上的一個「點」。
為什麼里程碑對專案管理至關重要？
讓利害關係人一眼看懂專案進度
想像你是 PM，老闆問你「專案進度怎麼樣了？」如果你打開一張有 200 條任務的甘特圖，老闆大概看三秒就失去耐心。但如果你拿出一份只有 5-8 個節點的里程碑狀態報告，老闆 30 秒就能掌握全局。
這就是里程碑最直接的價值：把複雜的專案進度壓縮成高階主管能消化的資訊密度。
以下是一份實用的里程碑狀態報告範本，你可以直接套用在週報或月報中：
| 里程碑名稱 | 預定日期 | 實際日期 | 狀態 | 備註 |
|---|---|---|---|---|
| M1 需求確認 | 3/15 | 3/14 | 🟢 已完成 | 提前 1 天完成 |
| M2 設計審查 | 4/10 | 4/10 | 🟢 已完成 | — |
| M3 原型完成 | 5/20 | — | 🟡 進行中 | 前端延遲 2 天，預計 5/22 完成 |
| M4 UAT 測試 | 6/15 | — | ⚪ 未開始 | 受 M3 影響，可能延至 6/17 |
| M5 正式上線 | 7/01 | — | ⚪ 未開始 | 待評估 M3 延誤影響 |
（推薦試試 monday.com 的免費方案，它的 Dashboard 功能可以自動生成這種里程碑狀態視圖，不需要每週手動更新表格。免費方案不需要信用卡。）
及早發現風險的預警機制
里程碑延誤不只是「那個節點晚了」這麼簡單，它代表的是後續所有相依任務的連鎖反應。
舉個具體的例子：假設一個軟體開發專案中，「需求確認」里程碑原定 3 月 15 日完成，但實際延誤了 1 週到 3 月 22 日。這 1 週的延誤會怎麼擴散？
- 設計階段：原本 3/16 開始，現在要等到 3/23，延誤 7 天
- 前端開發：依賴設計稿，原本 4/1 開始，現在至少延到 4/8，延誤 7 天
- 後端開發：部分 API 依賴需求規格，延誤約 3-5 天
- 整合測試：前後端都延誤，測試開始時間延後約 10 天
- 最終上線：原定 7/1，現在可能要到 7/10 以後
一個里程碑延誤 1 週，最終交付日期可能位移 10 天甚至更多。這就是為什麼里程碑是風險預警的核心機制——它讓你在問題還小的時候就看到信號，而不是等到最後才發現「來不及了」。
在專案管理流程的監控階段，里程碑就是你最重要的健康指標。
跨部門協作的共同語言
在一個跨部門專案中，RD 講的是 Sprint、業務講的是客戶交付日、設計講的是設計稿版本、老闆講的是「什麼時候能上線」。每個人用自己的語言描述進度，溝通效率極低。
里程碑提供了一個所有人都能理解的共同框架。當你說「M3 原型完成」，RD 知道這代表前端框架要搭好、業務知道這代表可以開始安排客戶 demo、設計知道這代表設計稿要定版。同一個里程碑，不同角色各自知道自己該做什麼。
5 步驟設定有效的專案里程碑
步驟 1｜用三個問題判斷是否值得設為里程碑
不是每個重要事件都該設為里程碑。設太多里程碑，等於沒有里程碑——當所有東西都是「重要節點」，就沒有東西是重要的了。
用以下三個問題快速判斷：
問題一：這個事件是否代表不可逆的階段轉換？
例如「需求凍結」就是典型的不可逆轉換——凍結後再改需求，就要走變更流程。但「完成第一版草稿」通常不是，因為草稿本來就會反覆修改。
問題二：是否需要利害關係人正式確認或簽核？
如果這個節點需要客戶簽字、主管核准、或跨部門會議確認，那它幾乎一定是里程碑。
問題三：若此節點延誤，是否會影響後續兩個以上的任務？
如果一個事件延誤只影響緊接著的下一個任務，它可能只是普通任務。但如果延誤會造成多條任務線的連鎖反應，那它就是里程碑。
判斷結果：
- 三題都是「是」→ 必設里程碑
- 兩題是「是」→ 建議設為里程碑
- 一題以下 → 可能只是普通任務，不需要設為里程碑
步驟 2｜用 SMART 原則撰寫里程碑描述
模糊的里程碑描述是專案失控的溫床。看看這兩種寫法的差異：
- ❌ 模糊寫法：「完成測試」
- ✅ SMART 原則寫法：「6/30 前完成 UAT 測試，涵蓋 50 個測試案例，通過率達 95% 以上，並取得客戶書面確認信」
第一種寫法，團隊可能會爭論「什麼叫完成？跑了 10 個 case 算不算？」第二種寫法，完成標準一目了然，沒有灰色地帶。
撰寫里程碑描述時，確保包含：
- Specific（具體）：明確說明要完成什麼
- Measurable（可衡量）：有數字或可驗證的標準
- Achievable（可達成）：考慮團隊產能和資源
- Relevant（相關）：與專案目標直接相關
- Time-bound（有時限）：明確的完成日期
步驟 3｜根據專案規模決定里程碑數量
里程碑數量沒有絕對標準，但以下是根據專案規模的實務建議：
| 專案規模 | 時程 | 建議里程碑數量 | 頻率建議 |
|---|---|---|---|
| 小型專案 | 3 個月以內 | 3-5 個 | 每 2-3 週 1 個 |
| 中型專案 | 3-12 個月 | 6-10 個 | 每月至少 1 個 |
| 大型專案 | 12 個月以上 | 依階段設置 | 搭配 WBS 對應 |
大型專案的里程碑建議與 WBS（工作分解結構）對應。WBS 的第二層級通常就是里程碑的候選節點——每個工作包（Work Package）完成時，就是一個潛在的里程碑。
常見錯誤提醒： 如果你的里程碑超過 15 個，很可能是把任務誤設為里程碑了。回頭用步驟 1 的三個問題重新篩選一次。
步驟 4｜指定負責人與完成標準
里程碑本身不分配工時，但它必須有一個「里程碑負責人」（Milestone Owner）。這個人不是負責「做完所有事」，而是負責「確認所有前置任務都完成了，並正式宣告里程碑達成」。
每個里程碑的完成標準應該包含：
- 需要哪些文件或交付物？（例：測試報告、設計稿 v3.0）
- 需要誰的簽核或確認？（例：客戶代表書面確認、技術主管 code review 通過）
- 有哪些前置條件？（例：所有 P1 bug 已修復、效能測試通過基準值）
常見錯誤提醒： 里程碑沒有指定負責人，是專案推諉的溫床。當里程碑延誤時，如果沒有明確的 owner，你會聽到「我以為是他負責的」這種話。
步驟 5｜建立動態調整機制
里程碑不是刻在石頭上的——但調整必須有正式流程，不能隨便改。
調整三步驟：
- 評估影響範圍：這個里程碑延後，會影響哪些後續里程碑和任務？最終交付日期會位移多少？
- 與利害關係人溝通：內部先對齊（PM、RD Lead、QA Lead），再對外報告（客戶、主管）。永遠不要讓客戶從別的管道得知里程碑調整。
- 更新計畫並留下變更記錄：在專案規劃文件中記錄：原始日期、調整後日期、調整原因、影響評估。這些記錄在專案結案時會成為重要的經驗學習素材。
三大產業實務案例
軟體開發專案（8 個里程碑完整範例）
以下是一個中型軟體開發專案（約 6 個月）的完整里程碑設定，這也是我們團隊在 monday.com 上實際追蹤類似專案時使用的結構：
| 里程碑 | 預估時程（週） | 負責角色 | 完成標準 |
|---|---|---|---|
| M1 需求確認 | 第 2 週 | PM | 需求規格書經客戶書面簽核 |
| M2 架構設計審查 | 第 4 週 | Tech Lead | 架構文件通過技術委員會審查 |
| M3 前端原型完成 | 第 8 週 | 前端 Lead | 可互動原型完成，客戶確認 UI 流程 |
| M4 後端 API 完成 | 第 10 週 | 後端 Lead | 所有 API endpoint 通過單元測試 |
| M5 整合測試通過 | 第 14 週 | QA Lead | 整合測試通過率 ≥ 95%，無 P1 bug |
| M6 UAT 完成 | 第 18 週 | PM | 客戶完成驗收測試並書面確認 |
| M7 正式上線 | 第 20 週 | DevOps Lead | 系統部署至正式環境，監控正常 |
| M8 上線後穩定運行 | 第 24 週 | PM | 上線 30 天內無重大事故，SLA 達標 |
注意 M8「上線後穩定運行」——很多團隊忽略這個里程碑，以為上線就結束了。但對客戶來說，系統穩定運行才是真正的「完成」。
行銷活動專案（5 個里程碑範例）
行銷專案的里程碑有一個特殊性：外部媒體截止日是硬性里程碑，完全不可調整。 電視廣告的素材交付日、雜誌的截稿日、KOL 的發文排程——這些都是外部決定的，你只能往前推算內部時程。
| 里程碑 | 預估時程 | 負責角色 | 完成標準 |
|---|---|---|---|
| M1 活動方案核准 | 第 1 週 | 行銷經理 | 方案經行銷總監核准，預算確認 |
| M2 素材製作完成 | 第 4 週 | 創意總監 | 所有視覺素材、文案定稿 |
| M3 媒體採購確認 | 第 5 週 | 媒體採購 | 媒體版位確認，合約簽署完成 |
| M4 活動上線 | 第 6 週 | 行銷經理 | 所有通路同步上線，監控數據正常 |
| M5 成效報告提交 | 第 10 週 | 數據分析師 | 完整成效報告含 KPI 達成率分析 |
建設工程專案（6 個里程碑範例）
工程專案的里程碑通常與法規驗收節點綁定，這意味著它們不僅是內部管理工具，更是法律要求。未通過驗收就進入下一階段，可能面臨罰款甚至停工。
| 里程碑 | 預估時程 | 負責角色 | 完成標準 |
|---|---|---|---|
| M1 設計圖核准 | 第 4 週 | 建築師 | 設計圖通過主管機關審查 |
| M2 開工 | 第 6 週 | 工地主任 | 取得開工許可，正式動工 |
| M3 基礎工程驗收 | 第 16 週 | 結構技師 | 基礎工程通過第三方檢驗 |
| M4 主體結構驗收 | 第 30 週 | 結構技師 | 主體結構通過政府驗收 |
| M5 內裝完工 | 第 42 週 | 室內設計師 | 內裝工程完成，通過消防檢查 |
| M6 竣工驗收 | 第 48 週 | 專案經理 | 取得使用執照，正式交屋 |
里程碑延誤怎麼辦？4 步驟處理 SOP
里程碑延誤是每個 PM 都會遇到的情況。關鍵不是「永遠不延誤」，而是「延誤時能快速、有系統地處理」。以下是一套可以直接套用的 4 步驟 SOP。
步驟 1：延誤確認
建議設定一個明確的觸發門檻：里程碑超過預定日期 2 個工作天，即啟動延誤處理 SOP。
為什麼是 2 天而不是當天？因為有些里程碑可能因為簽核流程的時間差而延遲 1 天，這屬於正常範圍。但超過 2 天，通常代表有實質性的問題需要處理。
步驟 2：影響評估
列出所有受影響的後續任務和里程碑，估算最終交付日期的位移量。具體做法：
- 打開排程管理工具，找出所有依賴延誤里程碑的任務
- 計算每條任務線的延誤天數（注意：不是所有任務都會等比例延誤）
- 找出最長的延誤路徑（關鍵路徑），這就是最終交付日期的位移量
步驟 3：溝通策略
原則：內部先對齊，再對外報告。 永遠不要讓客戶或主管從別的管道得知延誤。
以下是一份簡短的延誤通知郵件範本：
主旨：[專案名稱] M3 里程碑延誤通知與調整方案
各位好，
M3「原型完成」里程碑原定 5/20 完成，目前預計延至 5/27（延誤 5 個工作天）。
延誤原因： 前端框架升級遇到相容性問題，需額外 3 天修復 + 2 天回歸測試。
影響評估： M4 UAT 預計從 6/15 延至 6/20，最終上線日期從 7/1 延至 7/5。
調整方案： 建議增加 1 名前端工程師支援，可將最終延誤壓縮至 2 天。
請確認是否同意此調整方案，我將於明日下午 3 點前更新專案計畫。
步驟 4：計畫調整
延誤發生後，你通常有三種選項：
- 壓縮後續任務工期：加班或簡化流程（風險：品質可能下降）
- 增加資源：投入更多人力或預算（風險：溝通成本增加）
- 調整最終交付日：與客戶協商延後（風險：客戶信任度下降）
實務上，最常見的做法是三種混合使用——壓縮一部分、增加一點資源、最終交付日小幅延後。
具體情境：UAT 里程碑延誤 2 週的處理範例
假設你負責的軟體開發專案，M6 UAT 里程碑原定 6/15 完成，但到了 6/17（超過 2 天門檻），客戶才完成 30% 的測試案例，預估還需要 2 週才能完成。
48 小時內的處理流程：
- 第 1-4 小時：確認延誤原因（客戶端測試人力不足？測試環境有問題？bug 太多導致測試中斷？）
- 第 4-8 小時：完成影響評估，計算最終上線日期位移量
- 第 8-24 小時：內部對齊調整方案（與 RD Lead、QA Lead 討論是否能平行處理 bug 修復和測試）
- 第 24-48 小時：與客戶正式溝通，提出調整方案並取得確認，更新專案計畫
敏捷專案中的里程碑應用
如果你的團隊跑 Scrum 或其他敏捷框架，你可能會想：「敏捷不是強調彈性和迭代嗎？里程碑這種固定節點不是跟敏捷精神矛盾嗎？」
答案是：不矛盾，但用法不同。
在敏捷環境中，里程碑的角色不是管理每個 Sprint 的進度（那是 Sprint Review 的工作），而是標記對外部利害關係人有意義的節點。具體來說：
里程碑 vs. Sprint Review 的差異：
| 項目 | Sprint Review | 里程碑（Release Milestone） |
|---|---|---|
| 頻率 | 每個 Sprint（通常 2 週） | 每個 Release（通常 4-8 週） |
| 對象 | 內部團隊 + Product Owner | 外部客戶 + 高階主管 |
| 目的 | 檢視 Sprint 成果、調整 Backlog | 確認可交付版本、取得正式驗收 |
| 彈性 | 高（Backlog 可隨時調整） | 中（Release 日期通常有外部承諾） |
實務建議： 用「Release Milestone」對應外部利害關係人的期待，用 Sprint 管理內部開發節奏。例如：
- Sprint 1-3 → M1: Alpha 版本完成（內部測試可用）
- Sprint 4-6 → M2: Beta 版本發布（客戶可開始 UAT）
- Sprint 7-8 → M3: 正式版本上線（GA Release）
這樣做的好處是：團隊內部保持敏捷的彈性，但對外仍有清楚的里程碑承諾。在專案管理流程中，這種混合模式越來越常見。
如果你的團隊需要在敏捷框架中管理里程碑，ClickUp 的 Sprint 功能可以同時設定 Sprint 和 Milestone，在 Gantt 視圖中一目了然。
如何用工具設置與追蹤里程碑
Excel 里程碑甘特圖製作（3 步驟）
Excel 是很多 PM 的起點，尤其是團隊 5 人以下、不需要即時協作、預算有限的情況。以下是用 Excel 製作里程碑甘特圖的完整步驟：
步驟 1：建立基礎資料表
在 Excel 中建立以下欄位：
| 里程碑名稱 | 開始日期 | 結束日期 | 持續天數 | 狀態 | 負責人 |
|---|---|---|---|---|---|
| M1 需求確認 | 3/1 | 3/15 | 0 | 已完成 | PM |
| M2 設計審查 | 3/16 | 4/10 | 0 | 已完成 | Tech Lead |
| M3 原型完成 | 4/11 | 5/20 | 0 | 進行中 | 前端 Lead |
注意「持續天數」欄位填 0——因為里程碑本身沒有工時。但你需要「開始日期」和「結束日期」來定位它在時間軸上的位置（結束日期就是里程碑的目標日期）。
步驟 2：插入橫條圖並調整為甘特圖格式
- 選取資料範圍 → 插入 → 橫條圖（堆疊橫條圖）
- 將「開始日期」設為第一組資料（用來定位起始點）
- 將第一組資料的填滿色設為「無填滿」（讓它變透明）
- 調整 X 軸為日期格式，Y 軸為里程碑名稱
- 反轉 Y 軸順序（讓 M1 在最上面）
步驟 3：用菱形符號標記里程碑節點
這是讓你的 Excel 專案里程碑圖看起來專業的關鍵：
- 在圖表中，對里程碑的資料點按右鍵 → 「資料數列格式」
- 將標記選項改為「內建」→ 選擇菱形（◆）
- 調整大小為 12-15pt，填滿色設為深藍或紅色
- 或者直接在儲存格中輸入菱形符號：插入 → 符號 → 搜尋「Diamond」→ 選擇 ◆（U+25C6）
Excel 適合的場景： 團隊 5 人以下、專案時程 3 個月以內、不需要多人即時協作、預算有限。但當專案規模擴大，Excel 的限制會很明顯——沒有自動提醒、沒有即時協作、版本管理困難。這時候就需要考慮專案管理工具了。
monday.com 里程碑設定
monday.com 是我們團隊實際使用的專案管理工具，里程碑設定的操作路徑非常直覺：
- 建立專案看板 → 切換到 Timeline 視圖
- 新增一個 item，在 Timeline 欄位中將開始日期和結束日期設為同一天
- 系統會自動將該 item 顯示為菱形里程碑標記
- 設定自動化規則：里程碑到期前 3 天自動通知負責人
monday.com 的一個殺手級功能是 Dashboard——你可以建立一個專門的里程碑儀表板，把多個專案的里程碑狀態集中顯示。我們的 PM 每週一早上打開這個 Dashboard，30 秒就能掌握所有專案的里程碑健康狀態。
適合場景： 10 人以上跨部門團隊、需要利害關係人即時查看進度、多專案同時管理。
費用： Standard 方案約 NT$ 450/人/月起。免費方案不需要信用卡，最多 2 人使用。
ClickUp 里程碑設定
ClickUp 的里程碑設定同樣簡單，而且免費方案就能使用基本功能：
- 開啟任務 → 右上角選單 → 點選「Mark as Milestone」
- 任務會自動變成菱形標記，在 Gantt 視圖中顯示
- 搭配 ClickUp 的里程碑功能，可以設定依賴關係和自動通知
ClickUp 的優勢在於高度自訂——你可以為里程碑建立自訂欄位（如「完成標準」「簽核人」），並設定自動化工作流程。
適合場景： 需要高度自訂工作流程的技術團隊，尤其是跑 Scrum 的軟體開發團隊。
費用： 免費方案可用基本里程碑功能；Unlimited 方案約 NT$ 300/人/月。
工具選擇建議表
| 工具 | 適合團隊規模 | 月費（NT$/人） | 里程碑功能亮點 |
|---|---|---|---|
| Excel | 1-5 人 | 免費（或 Microsoft 365 約 NT$ 170 起） | 完全自訂，但無即時協作 |
| monday.com | 5-50+ 人 | 免費方案 / Standard 約 NT$ 450 起 | Dashboard 集中管理、自動化通知、利害關係人視圖 |
| ClickUp | 3-30 人 | 免費方案 / Unlimited 約 NT$ 300 起 | 高度自訂、Sprint 整合、免費方案功能豐富 |
| Google Sheets | 1-5 人 | 免費 | 簡易協作，但功能有限 |
你是哪種團隊？
- 5 人以下、剛開始接觸專案管理 → 先用 Excel 或 Google Sheets，熟悉里程碑概念
- 5-15 人跨部門協作 → monday.com（我們的首選，Dashboard 功能對跨部門溝通特別有用）
- 技術團隊跑 Scrum → ClickUp（Sprint + Milestone 整合最好）
- 15 人以上的大型專案 → monday.com 企業方案（支援多專案組合管理）
結論
專案里程碑看起來只是時間軸上的幾個點，但它是讓專案從「一團混亂」變成「有節奏推進」的關鍵機制。回顧本文重點：
- 里程碑是零工時的檢查點，不是任務。用三個問題（不可逆轉換？需要簽核？影響多條任務線？）判斷是否該設為里程碑
- 根據專案規模決定數量：小型 3-5 個、中型 6-10 個、大型依 WBS 對應。超過 15 個通常代表設太多了
- 每個里程碑都要有負責人和 SMART 完成標準，模糊的里程碑等於沒有里程碑
- 延誤不可怕，沒有處理 SOP 才可怕：2 天門檻觸發 → 影響評估 → 內部對齊再對外溝通 → 更新計畫
- 敏捷團隊用 Release Milestone 對外，用 Sprint 管內部，兩者不衝突
下一步行動： 打開 monday.com，用 Timeline 視圖建立你目前專案的里程碑。先從最重要的 3-5 個開始，為每個里程碑填入負責人和完成標準。整個過程不到 10 分鐘，但你會立刻感受到專案進度變得清晰可控。
專案里程碑常見問題（FAQ）
里程碑可以調整嗎？
可以，但必須有正式流程。里程碑調整不是 PM 自己改個日期就好——你需要評估影響範圍、與利害關係人溝通、並在專案計畫中留下變更記錄（原始日期、調整後日期、原因、影響）。詳細的調整流程可參考本文「步驟 5：建立動態調整機制」。
里程碑在敏捷專案中如何應用？
敏捷專案中，里程碑的角色是標記 Release 節點，而不是管理每個 Sprint。建議用「Release Milestone」對應外部利害關係人的期待（如 Alpha 版本、Beta 版本、GA Release），用 Sprint Review 管理內部開發節奏。兩者搭配使用，既保持敏捷彈性，又有清楚的對外承諾。
里程碑適合所有專案嗎？
大多數專案都適合設置里程碑，尤其是跨部門、時程超過 1 個月、或需要定期向利害關係人報告的專案。但如果是極短期專案（例如 2 週內的小型任務），里程碑可能過於繁重。這種情況下，用一份簡單的專案進度追蹤表搭配每日站會就足夠了。
如何向主管報告里程碑進度？
最有效的方式是使用本文「讓利害關係人一眼看懂專案進度」段落中的里程碑狀態報告表格（里程碑名稱、預定日期、實際日期、狀態燈號、備註）。如果你使用 monday.com，可以直接用 Dashboard 自動生成這份報告，不需要每週手動更新。
里程碑未如期完成怎麼辦？
啟動 4 步驟延誤處理 SOP：①超過預定日期 2 個工作天即確認延誤 → ②評估對後續任務和最終交付日的影響 → ③內部先對齊再對外溝通（附延誤通知郵件範本）→ ④從壓縮工期、增加資源、調整交付日三種選項中選擇最適方案。完整流程和情境範例請參考本文「里程碑延誤怎麼辦」段落。
Project milestone 中文怎麼說？
Project milestone 的中文翻譯是「專案里程碑」，也有人簡稱「里程碑」。在台灣的專案管理實務中，「里程碑」是最常用的說法。英文縮寫常見 M1、M2、M3（Milestone 1、2、3），在甘特圖和時間軸上以菱形符號（◆）標示。PMBOK 的官方定義是「專案中具有重要意義的事件或時間點，通常持續時間為零」。
