05_專案範疇管理

核心主題	主要觀點／概念	實務或理論意義	重要條件／限制／延伸
範疇定義	以策略目標、戰術目標、里程碑、限制、假設與排除項目界定專案邊界	為估算、時程、WBS 與變更管理建立共同基準	內容需與顧客、管理階層與執行團隊共同確認
工作分解結構（WBS）	把交付成果與工作逐層分解到可管理層級	支援責任分派、估算、時程與控制	分解過細可能侵犯功能部門權責，過粗則難以管理
需求與依賴關係	除了工作清單，也需理解系統能力與彼此依賴	可避免局部工作準時、整體整合卻失敗	高度複雜技術專案可搭配 Project Anatomy 等視覺工具
範疇驗證	規格與需求需在設計、採購與變更時持續確認	降低需求誤解、重工與成本超支	跨組織專案尤其需要需求追溯與正式變更溝通
明確排除	把「不包含什麼」與「包含什麼」同時寫清楚	減少利害關係人自行假設與範疇蔓延	排除項目若改變，必須視為正式範疇變更

本章定位

第5章聚焦專案範疇管理，原書列出4個正式案例。核心問題都是：如何確保專案只做需要做的工作，而且大家對「要交付什麼」有相同理解。

Workshop: Project Definition 顯示，一份有效的專案定義不只寫目標，也要同時列出主要交付成果、里程碑、限制、假設與明確排除內容。它是後續 WBS、估算與時程的共同起點。

Project Lada 案例顯示，WBS 分解深度會直接碰到治理與資源所有權問題。若專案經理把低層工作包也自行規畫，可能與功能經理既有責任衝突；因此 WBS 必須與組織權責、共享資源與優先順序一起設計。

Project Anatomy 把焦點從「工作怎麼分」進一步延伸到「系統能力如何彼此依賴」。對大型技術專案而言，若只靠傳統工作清單，團隊可能看不見整體整合順序；視覺化能力依賴有助於建立共同理解。

Rapid Prototype for Fast Profits 顯示，設備交付失敗表面上發生在測試當天，但真正問題是早期規格沒有持續驗證。當 GE 的設計已變成62英吋時，若需求追溯機制正常，應在設備完成前就發現差異。

範疇管理不是把需求寫進文件就結束，而是持續維持「商業目標—需求—交付成果—WBS—變更」之間的一致性。任何一層改變，都應檢查對其他層造成的影響。