案例_A Checklist：計畫結案清單、正式驗收與經驗教訓
案例_General Public Hospital：TKS、Baseline Review 與功能追加決策
案例_American Shogun：跨專案協作、商業目標與11個月交付
案例_Planet Orbits：跨組織太空計畫、36個月限制與軟性能力
案例_ConSoul Software：Silverbow、雙重排程系統與三方案取捨
| 核心主題 | 主要觀點／概念 | 實務或理論意義 | 重要條件／限制／延伸 |
|---|---|---|---|
| 正式結案 | 確認交付成果、完成條件、顧客驗收、資源釋放、文件歸檔與經驗教訓 | 把工作、責任與知識正式收束，避免留下未完成義務 | 計畫 下各 專案 原則上應先完成關閉 |
| Gate Review | 以 Go／Kill／Hold 或其他決策機制判斷是否進入下一階段 | 在重大範疇、成本與時程變化前重新驗證商業價值 | 需要顧客、使用者與治理者共同提供決策資訊 |
| 跨專案協作 | 計畫 manager 管理跨 專案 的依賴、商業目標與共同里程碑 | 避免各 專案 各自成功卻拖累整體 計畫 | 需要透明資訊、授權、溝通與持續取捨 |
| 大型跨組織計畫 | 規模增加後，組織結構、review、時程約束與 軟性能力 的重要性上升 | 技術成熟不代表 計畫 風險低 | 跨 site／跨組織協作與不合理時程仍可能成為主要風險 |
| 策略取捨與責任 | 品質、顧客滿意度、功能、上市速度與銷售可能互相衝突 | 計畫 manager 必須依 商業策略 做選擇並承擔 責任承擔 | 高階主管可提供資源與治理，但不應替被授權的 計畫 manager 逃避決策 |
第18章同時處理計畫結案流程與計畫實務，原書由1個關鍵事件與4個綜合案例組成。五案從正式 結案、gate review、跨專案協作、跨組織大型 計畫，到 strategy-driven trade-off，形成第二部分的總結。
A Checklist 要求 計畫 manager 確認交付、顧客簽核、資源釋放、經驗教訓、文件歸檔與正式驗收。結案的目的之一，是把成功與失敗原因轉成未來 計畫 的組織知識。
General Public Hospital 的 TKS 已接近 baseline review，卻出現一項可提升使用者體驗、同時造成2個月延誤與10萬美元超支的新功能。Focus group 把實際使用者意見帶進 Go／Kill／Hold 治理決策，說明 計畫 gate 是商業與使用者價值的重新確認點。
American Shogun 以11個月完成跨功能開發，並在上市後達成獲利、市占率與競爭策略目標。計畫 manager 並未管理每項 專案 細節，而是聚焦跨專案依賴、里程碑、商業目標與必要取捨。
Planet Orbits 的技術成熟度相對高，但跨 site collaboration、三個組織的責任界面、review governance，以及未經充分分析就接受的36個月限制，仍形成重大 計畫 risk。原書因此特別強調 leadership 與 軟性能力。
ConSoul Software 的 Silverbow 面臨三個都不完美的方案：晚一個月但保留功能、用高風險方式壓縮時程、或刪功能守住日期。PAC 最終把選擇權交還 計畫 manager，凸顯授權與責任必須一起存在。
計畫 management 的核心不是把 專案 management 放大，而是持續管理跨專案依賴、商業成果、策略一致性、治理邊界與取捨。計畫 是否成功，最終要回到整體 business objectives，而不只是個別 專案 是否準時完成。