作者：Loren Gary
放任錯誤的變更，專案會偏軌、超支、錯過關鍵死線；但拒絕對的變更，又可能錯失重大機會。專案經理的兩難就在此。
解決之道：把專案邊界畫清楚，並能快速估算任何變更或滑動造成的影響。
規劃階段：讓邊界長硬#
許多專案在「沒有充分定義參數」的情況下就上路了。Dave Moffatt（哈佛商學院資深營運顧問，40 年專案管理經驗）認為急躁是罪魁禍首。在規劃階段做以下幾件事：
區分目的（Purpose）與範疇（Scope）#
佛州專案顧問 Alex Walton 的定義：
- 目的（Purpose）：專案要為組織提供的整體效益
- 範疇（Scope）：團隊能控制、且承諾交付的具體要素或產品屬性
例：某玩具公司的目的可能是「推出新電子遊戲，讓年節銷售提升 40%」。但團隊得知道：要做哪些功能、預算多少。範疇陳述（scope statement）就是用幾句話講清楚「團隊將如何達成成功，以及將以什麼標準被評估」。
範疇要徵詢關鍵利害關係人意見，把他們的期望與專案實際軌跡對齊。
從整體（Aggregate）規劃#
光定義單一專案的範疇還不夠。哈佛商學院教授 Steven Wheelwright 主張：
組織也需要做整體專案規劃（aggregate project planning）——擬定一份策略，鋪陳後續專案的型態與節奏。
這對產品開發特別關鍵：
- 若沒有未來專案的時程表
- 一位有新點子的工程師可能擔心他的點子永遠沒機會做
- 於是想方設法把點子塞進目前正在開發的產品——不論成本與時程影響
分析過去專案也是有用的補充。研究公司過去幾個內部 IT 專案，看出共同模式，能幫你更早預備未來幾年類似專案的麻煩點。
訂定遊戲規則#
要降低範疇蔓延，就必須在重大變動發生前強制觸發明確的討論與批准：
- 設立變更管制委員會（change control board）
- 任務：蒐集變更對時程、預算、範疇的影響資訊；投票；遞交發起人簽署的變更申請
- 適合 IT 等高度結構化的環境，跨單位（業務、行銷、物流）由各單位資深主管組成
- 規模：少於 100 萬美元、12 個月以內的小專案不必設正式委員會，由專案經理視需要諮詢關鍵利害關係人即可
- 設定額外工作的觸發門檻
- 顧問 Michele Reed 建議：「任何變更若超過該項目原始成本或工時的 5%，就應觸發正式範疇變更申請。」
- 限制新功能數量
- 為特定規模的專案訂定「最多幾個主要 / 次要新功能」的指引
- 強迫團隊只挑出對客戶當下最重要的少數功能
執行階段：拆小、優先、先求穩#
到執行階段，把工作拆成小組件、短時程，並從不確定性與變異最低的任務開始做。
例：軟體團隊要做一個含四項新功能的產品，第四項市場是否買單還不確定。團隊先做有把握的前三項，第四項則延後上市，等收到更多客戶輸入再確認其關鍵性。
定期系統原型測試#
Wheelwright 的建議：不要等所有子專案完成才檢查整體會不會成功。採用定期系統原型測試（periodic system prototyping）：在執行階段每隔一段時間，把所有子專案串起來做一次系統測試，確認子專案如預期匯流。
真實案例：HBS 麥克阿瑟廳的房間決策#
哈佛商學院為高階主管教育學員（部分課程長達八週）建造住宿用的 McArthur Hall。施工中提出範疇變更：希望規劃 10 間房給學員的客人短期入住。
兩個方案的取捨：
- 方案 A：把現有 10 間學員房改成客房 → 長期會減少可註冊學員數，侵蝕長期收入
- 方案 B：另外加蓋 10 間客房 → 即時成本上升，但可在數年內由維持現有學員房數所產生的收入流回收
透過嚴謹的 ROI 分析，發起人選了方案 B，找到處理新增請求的最佳路徑。
評估每一個範疇變更時要問的問題#
當變更請求進來時：
- 動機（Purpose）：市場條件改變了嗎？是否要加速上市？是否需要符合計畫後採用的新業界標準？原方案技術行不通了嗎？
- 影響（Impact）：變更會如何影響範疇陳述、專案計畫、可用資源、總成本、時程？
- 代價（Cost of inaction）：如果不做這個變更會發生什麼？
Moffatt 提醒：在這些討論中，代表終端使用者的人意見份量應該最重。
專案經理若是變更的倡議者#
若變更是你（專案經理）主動提的，你必須準備一份經費計畫：
- 若 add-on 帶來的未來收入無法支應其成本
- 就要從專案其他地方找出可以省下的錢
- 聚焦於未來 30 到 90 天內你能直接控制的項目
Loren Gary 曾任《Harvard Management Update》主編。 改寫自：Harvard Management Update（product #U0501C），January 2005