為什麼專案需要主動監控#

專案不同於常規流程：

• 流程：同一群人重複做同一件事
• 專案：常涉及獨特活動（新技術、新建築、新軟體），由可能首次合作的人共同完成

身為專案領導人，必須主動監控進度，才能確認計畫真的把團隊帶向目標。

監控與控制專案的五個基本步驟：

一、追蹤專案活動#

與團隊成員定期同步#

• 透過會議檢查任務是否完成、品質是否達標
• 在分散式團隊中，全員會議難安排——可改開「個別／小組工作會議」處理特定主題
• 案例：跨三地的工程師原本要協助寫客戶提案，作者用 3 小時的「即時電話會議」一次定稿，比起寄草稿、收回饋、整合，省下幾週時間
• 工作會議結束後，再透過大型會議或 email 把其餘團隊納入

Buddy Checks（同事互核）#

• 任務完成時請另一位團隊成員看一下結果
• 這不是深度技術分析，只是快速檢查是否遺漏或誤解需求
• 例：訓練計畫由另一位成員確認所有需要訓練的部門都包含在內
• 理想做法：請任務的「下游使用者」做互核——例如為某醫療器材開發新產品時，由法規部門檢視設計文件與測試資料，提早抓出未來法規送審的缺漏
• 若沒有相關人選，主管自己做也行——但要明說這不是績效評估，只是團隊互助

二、蒐集績效資料#

用 Pulse Meeting 即時掌握脈動#

• 有 PMIS（專案管理資訊系統）就用，但仍要透過短會抓績效
• 限時 10 分鐘
• 只談「上次會議後新開始或完成的任務」
• 目標是「快速感知狀態」，不是「捲起袖子解決問題」
• 發現問題或風險，另約小型工作會議處理

Pulse 頻率隨情境調整#

• 一般專案：每週一次
• 危機模式：節奏加速。案例：作者管理過的某新廠在啟用前 3 天電源系統故障，原本要 2–3 個月處理的事必須 3 天內搞定，因此每 3 小時 pulse 一次

三、分析績效，判斷計畫是否仍成立#

偏差不一定是問題#

• 任務鮮少照預期進行——可能延期、提前；可能超支、低於預算
• 偏離計畫只要不威脅專案目標就不是問題
• 案例：某模具延後 2 週，但因不在關鍵路徑（critical path）上，且該段排程有 6 週緩衝（slack），不必特別處置

良好規劃此時付出報酬#

• 知道關鍵路徑 → 能判斷哪些議題該觸發排程修改
• 預先辨識的風險 → 能判斷哪些卡點是真正威脅
• 每個活動的工時與成本估算 + 已標記不確定性 → 能分辨「不大不小的偏差」與「暗示更深層問題的偏差」

計畫需要修訂時#

可能要做的調整：

• 延後完成日期
• 動用預算儲備
• 從專案範疇移除部分交付項目
• 甚至取消專案

案例：某軟體第一版錯誤過多，作者先回頭檢查需求文件，發現開發者在用過時的版本。重排該模組的開發、整體延後一個月——但這個改動明顯必要。

四、向利害關係人回報進度#

三種審查與紀錄#

• 管理審查（management review）
• 關卡審查（tollgate review，也稱 stage-gate / phase-gate）
• 技術審查（technical review，又稱 peer review）

三種審查都要記錄行動項目並存檔備查。

管理審查#

• 目的是「管理風險」
• 利害關係人會同時看多個專案，評估整個組合是否能達成業績、是否有系統性弱點
• 通常每月一次
• 重點原則：利害關係人關心的是業務目標，不是團隊每日活動

反例：作者旁聽過一場審查，專案領導人花了將近 30 分鐘介紹技術方案——只把利害關係人弄得無聊與煩躁。應該用 5 分鐘說：專案如期、技術分析有進度、沒有新增風險。

用儀表板（dashboard）摘要#

• 把專案目標拆成排程、成本、績效等元件
• 用「紅／黃／綠」三色 stoplight chart 呈現
• 多數公司有標準模板，讓資深主管能快速評估多個專案
• 重要：每個顏色的意義必須事先講清楚——例如所有未完成任務都標紅嗎？還是有些可以是綠色（因為完成計畫已核准且進行中）？

報告壞消息的方式#

永遠把壞消息包裝成「對專案目標的風險」。

• 例：說明特定任務的延遲將如何讓團隊無法準時達成目標
• 例：資源短缺將降低活動的嚴謹度，因而降低交付品質
• 提出問題時也提出回應選項，並討論每種解法的風險
• 由利害關係人決定組織願意承擔哪些風險

關卡審查（tollgate review）#

• 是「決策會議」，不是狀態檢查
• 用於分階段執行的專案
• 團隊摘要前一階段成果、提出下一階段計畫
• 利害關係人評估後決定：核准、調整方向、或取消
• 若核准進入下一階段，同步給予所需資源（含預算）

技術審查（technical review）#

• 由獨立專家小組（內外部顧問、法規代表）做深度分析
• 確認工作正確、完整、符合品質標準
• 利害關係人可在此給予「通過印章」，讓團隊接著進行下一階段的關卡審查

五、管理計畫變更#

重大變更#

提案重大變更時，要清楚列出：

• 採用變更的成本與風險
• 維持原計畫的成本與風險

案例：某國防承包商被空軍要求改善某武器系統元件，空軍從一組「成本／風險／時程」選項中挑了一個。承包商接著同步更新設計文件、製造流程、供應商合約、專案排程與預算，讓轉換盡量無縫。

重大變更要記在專案紀錄的「變更日誌」（change log）中，包含理由。然後用平常的規劃流程修訂計畫，並把與成員相關的變動清楚說明。

微幅變更#

• 通常出現在實作備援計畫（contingency plan）或執行原本只規劃在高層次的部分時
• 團隊可自行處理，不需利害關係人核准——除非變更會直接影響利害關係人或其部門

結語：目標壓過一切#

監控專案時別把心力放在「忠於原計畫」。幾乎每個專案計畫都會在某個時點需要修訂——尤其是新產品或新系統，早期學到的會反過來決定後期任務該長什麼樣。

• 該換路時就換路
• 別怕修改，只要它能把你帶到目標