PMP十大知識領域在第一個「整合管理」之後即是「範疇管理」。
「範疇Scope」比時程、品質、資源等都先介紹，就是因為它是管理專案最優先需釐清的重點。

何時應該定義範疇(Scope)

專案之中的範疇(Scope)意指將交付的產品、服務或結果設定界線範圍。

從前輩手上接到一個測試任務，是要測試整個系統，還是只需要測試其中一部分功能？
即將開始執行一個專案，專案是增修案還是維運案？增修的話需要訪談和開發多少程式？
針對專案整體目標或是專案之下的分解工作(WBS)，只要疑惑需要執行的任務範圍，就應該立刻提出討論並定義「範疇」。
「範疇」一般在專案初期即會將界定完成，避免專案執行過程中不斷發散衍生新需求。
如果一位PM無法清楚知道專案「範疇」為何，代表專案偏離目標的可能性很高，相對專案失敗的機率會很高。
而以接收任務端來思考的話，如果PM前輩或跨部門同仁轉交了任務給你，必須先弄清楚「要投入執行什麼(Input)和產出什麼成果(Output)」，避免職責範圍不清或缺乏共識導致白做工。

定義範疇的方法

一、依契約規範

與客戶簽訂的契約，一定會有最低要求的履約標的，即是專案範疇的基礎。
「資訊系統合約」常見需要注意釐清的「範疇」含括下列項目：
1.系統開發？系統維護？或是兩者都有？
2.開發或維護的時間限制？
3.除了系統軟體，是否還有硬體項目？
4.收付款項規範？例如需繳交保證金、採購等。
5.交付文件？
6.定期召開會議？
7.客服(專線)電話、Email、Line@等服務？
8.有無保固服務？保固服務項目為何？
上述項目也是「專案章程」、「專案工作計畫書」中可能涵蓋的內容。

二、需求凍結

若契約提到會增修新需求，可能會有「需求蒐集」的過程。
進行需求訪談時須確保多方有共識，無論是會議紀錄、附件參考等，皆需最後彙整製作成「需求溯源矩陣(Requirements Traceability Matrix)」也有人稱作「雙向允收表」。
如下圖表格，針對系統功能將需求範疇的「產生來源」記錄，由左至右細分發展出「蒐集到的需求」與「客觀定義產出成果」，以此為多方共識，專案邁入尾聲時將請客戶在最右邊勾選是否符合作為驗收結果。

若客戶較難理解文字表述，也可佐以附圖來討論。
「需求凍結」須像冷凍住需求一般，遏止需求無限增長發散，確保依此為基準進行後續開發，才不會開發到中途因範疇不清而產生爭議並撼動開發範疇。

三、需求的任何決議與調整都須留下白紙黑字

實務面來說要理想「凍結需求」是不可能的任務，折衷辦法是留下調整變動的紀錄。
白紙黑字的定義最嚴謹標準是「契約、公文」，稍隨意則採取「Email」，甚至有人可接受Line之類的通訊軟體。
有寫有依據，即使見面三分情口頭約定，也需事後留下文字紀錄，以免未來大家翻臉不認人揮不清楚。

除了專案管理之外，身為PM助理的角色時，也可運用上述觀念在各個任務上，所有事情都先釐清「範疇」可以減少認知不同而多做額外工作的風險。

「範疇」就像是專案工作的底線，踩緊不放開才能只做應該要做的事情，別讓範疇以外的多餘雜事佔用到資源。