作者：Ray Sheen
不像「流程」由同一群人重複執行同一活動，專案常涉及獨特活動（例如使用新技術、蓋新建築、寫新軟體），由可能首次合作的成員執行。因此身為專案領導者，你必須主動監控進度，判斷現有計畫是否真能讓團隊接近目標。
五個基本步驟#
監控與控制專案，可循以下五步：
1. 追蹤專案活動#
定期與成員碰面，確認任務正在執行、品質達標。同地團隊可在會議中完成；分散式團隊則需另尋方法。
作者經驗：先和關鍵小群開工作會議（例如三地工程師為某客戶提案做電話 live meeting，三小時內定稿），再用較大會議或 e-mail 把其他人迴圈進來。
Buddy Checks（夥伴檢查）#
當有人完成一個活動，找另一位成員快速看一眼結果——這不是深度技術審查，而是確認沒漏掉什麼或誤解需求。
例：負責「新系統訓練計畫」的成員，由負責人快速確認所有需要訓練的部門都已涵蓋。
理想的 buddy 是會用到該活動結果的人。例如醫療器材公司新產品開發中，作者請法規部門檢視設計文件與測試資料，標出未來提交監管時會缺的資訊。
沒有適合的 buddy 時，自己做也行，但要表明這不是績效評估——只是同事互相看顧。
2. 收集績效資料#
少數公司有自動產出報表的專案管理系統，可用則用。但更重要的是短脈衝會議（pulse meetings）：
- 限時 10 分鐘
- 只討論自上次以後啟動或完成的任務
- 目的：快速感知狀態，不是動手解問題
- 發現問題 → 另外與相關人員開工作會議解決
節奏（pulse rate）依情境調整：
- 一般週例會即可
- 危機模式時加快——作者曾遇新廠房供電在啟用前 3 天故障，改成每 3 小時 pulse 一次
3. 分析績效，看計畫是否仍成立#
活動很少照計畫精準發生：可能更快、更慢、超支或省錢。
偏離計畫只有在會危及目標時才是問題。
範例：某次工程師在 pulse meeting 報告新模具會延遲兩週。但模具不在關鍵路徑上、且該段時程有近六週緩衝——團隊不需特別行動。
反之若延遲會危及重要目標，作者就會召集相關成員開會找方案。
此時前期用心規劃的回報就出現了：
- 知道關鍵路徑 → 能判別哪些議題該觸發時程變更
- 早期識別過的風險 → 容易辨識新問題是否威脅成功
- 詳細的工時與成本估算（並標註不確定性）→ 能分辨「小事 vs. 重大潛在問題」
當計畫真的需修正，可能要：延後完工、動用預算備援、刪除部分交付物、甚至取消專案。
範例：某軟體開發專案的初版 bug 過多。作者快速檢查後發現開發者參考了過時版本的需求文件——該模組得重排程，整體延一個月，但這樣的調整顯然必須做。
4. 向利害關係人回報#
有些 PM 與成員把利害關係人 review 視為浪費時間——錯誤觀念。妥善管理的 review 反而推動專案前進。
三種 review，皆需記錄與分發行動項，並把會議紀錄存入專案檔案：
管理 review#
目的是管理風險，不是追日常活動。利害關係人在意能否達成商業目標。
- 通常月例
- 常會一次審視多個專案，看整體 portfolio 能否帶來預期績效、找出系統性弱點
反例：作者曾參加一場 review，PM 花了近 30 分鐘解釋技術設計，讓利害關係人厭煩又挫折——他應該用 5 分鐘說：「進度準時、技術分析有進展、無新風險」。
專案儀表板（dashboard） 是好工具：
- 用紅黃綠呈現各活動狀態（stoplight chart）
- 拆成時程、成本、績效等構面
- 用顏色前先和大家對齊「紅黃綠各代表什麼」（例如：未完成的任務都標紅嗎？還是部分綠——因為完工計畫已批准且進行中？）
報告壞消息時，務必用「對專案目標的風險」框架表達：
- 「某任務延遲，可能讓團隊無法準時達成 X 目標」
- 「資源短缺會讓某活動的嚴謹度下降，進而影響交付品質」
- 同時提供應對選項與各選項的風險——讓利害關係人選他們願承擔的風險
Tollgate review（階段審查）#
又稱 stage-gate / phase-gate review。這是「決策會議」，不是狀態會議：
- 適用於分階段規劃與執行的專案
- 團隊匯報前一階段成果並提出下一階段計畫
- 利害關係人評估計畫、選項、風險，再決定批准、改向、或取消
- 若批准進入下階段，同時撥下所需資源（含經費）
技術 review（peer review）#
由獨立專家團隊（內外部顧問、監管機關代表等）做深入分析，確認團隊以正確、完整、達標的方式完成工作。
此時利害關係人可能會「蓋章」，標誌一個階段成功完成，可進入下一個 tollgate review 申請進入新階段。
5. 管理對計畫的變更#
重大變更#
向利害關係人提案時，列出採納與「維持原計畫」各自的成本與風險。
例：某國防承包商被空軍要求改良武器系統元件性能。空軍依含成本、風險、時程的提案選定方案後，承包商同步更新設計文件、製造流程、供應商合約、專案時程、預算——讓轉換盡可能無縫。
大幅修訂應記錄在變更日誌（change log）（含理由），並把新版計畫送給成員，說明影響他們的部分。
微小變更#
執行應變計畫或細化原本只做高層次規劃的部分時，會自然冒出小調整。
這些通常不必經利害關係人批准，由團隊自行管理即可——除非變更直接影響利害關係人或其部門。
一條總原則：目標優先#
「達成目標」勝過一切——別執著於遵守原計畫。
作者經驗：幾乎每個專案計畫都會在某時刻需要修訂，特別是新產品/新系統開發——早期學到的東西會改變後期任務的形貌。
如果改變方向能讓你更接近目標，別怕改。
Ray Sheen 教授並顧問專案與流程管理，逾 25 年在國防、產品開發、製造、IT 等領域帶領專案的經驗，並曾在 GE Electrical Distribution 業務部執掌專案管理辦公室。