專案執行過程最為人詬病的問題，就是用戶或sponsor持續追加需求，導致範疇不斷變更、膨脹。變更的原因有很多，最常見的情況是專案初期PM就無法明確定義範疇，也沒有讓團隊成員、用戶及sponsor都充分理解專案執行的邊界在哪裡，當邊界模糊，對於新增的需求自然也缺乏約束力，無法排除在專案之外。

在《專案管理知識體系指南》(PMBOK® Guide, A Guide to the Project Management Body of Knowledge)中，雖然有定義專案初始階段的任務，包含確認專案範疇、展開WBS...等，但如何有效界定範疇、用何種圖表來呈現，就需要靠PM自己想辦法。

為了讓團隊成員及相關利害關係人都能理解專案範疇，我自己習慣使用UML中的Use Case Diagram加上流程圖的形式來輔助說明。UML是一種軟體開發的統一塑模語言(Unified Modeling Language)，用來為即將開發的系統進行塑模分析。簡單來說，就是在開發前建立一個模型概念，以統一的圖文規則來表述系統架構、功能等。而Use Case Diagram是其中一種圖形工具，從高層次的角度辨識系統所應提供的功能。

在圖形的繪製上，通常會有Actor(通常為某個角色，例如系統的使用者)、Use Case(使用案例，或可想像為操作行為、或者執行的功能)，以及兩者之間的關聯，其中Actor和Use Case之間常為一對多關係。

舉一個簡單的例子來說明，假設專案要開發一套進出貨管理系統，那麼我們必須先釐清使用者有哪些，以及他們個別會如何進行操作。

簡單的關係圖如下，業務建立訂單後，分別由撿貨員進行備料，再由送貨員遞送給客戶，其中訂單必須經過主管簽核才能正式成立，亦即一份完整的訂單包含了主管核准的動作，因此在圖形上使用虛線箭頭加上《include》標示，代表他們的關聯。每個專案、系統的情況不同，在拆解關係時務必以使用者為出發點，列出他們與系統、產品之間的互動關係即可，不須太過著墨細節，畢竟這個階段還未進入流程的分析。

當主要的關係釐清之後，接著便可從圖中找出隸屬專案範疇的部分，有時候專案必須仰賴其他系統的功能作為輔助，例如案例中的簽核流程可與公司原有的機制串接，此時便可將其排除在範疇之外，繪製出如下的關係圖。

當然，大部分的專案絕不會像範例一樣有如此簡單的關聯，且定義太過模糊也無法有效匡列範疇，因此PM必須與團隊成員一同檢視Use Case，從不同面向進行拆解，歸納出完整的關係圖。

例如訂單成立後，是否需與銷用管理系統有資料的往來? 財務或經管單位是否需針對銷售金額或成果進行檢視? 這些都必須透過提問、訪談，逐步彙整而成。在匡列範疇的同時，也等於是對專案做整體評估，對後續展開WBS有極大的幫助。

為了確保盤點周詳，我通常會將Use Case Diagram當作初階範疇定義，接著再以系統的角度繪製流程圖，並將不同系統的功能或操作行為以色塊區隔，產出如下圖所示的結果。

圖中我將簽核、用印歸納至合約管理系統內，並將備料過程拆解成「有庫存」、「缺貨」兩條動線，其中「向其他門市調貨」的動作，必須與相關單位確認配合方式，因此用不同的顏色來標示，作為日後討論的重點(可能會被移除在專案範疇外)。

當要對利害關係人說明專案內容時，可以著重在「進出貨管理系統」匡列的範圍內，對團隊成員則可聚焦在「與合約管理系統之間的串接點」，這是因為範疇內的任務通常掌握度較高，但與外部系統的關聯或處理不當，很可能會導致專案範疇膨脹(例如原定要與合約系統串接的項目，因為架構不符規範，必須要自行開發)。

也就是說，初期流程圖所定義的，只是團隊們「期望」的範疇，它的邊界尚有模糊地帶需要進一步釐清，等到相關利害關係人都充分理解這張圖所匡列的範圍之後，才能算是真正定義完成，可以避免日後衍生的爭議。

當專案越複雜，就越需要明確定義用戶、專案範疇，以及外部系統之間的關係，日後才能辨識新需求是否屬於專案原本的範疇內。雖然這些做法無法保證專案不須變更，但可以作為開發排序的參考，越接近專案範疇核心，表示有越高的機率優先處理，當預計變更的項目有一致的評估標準，才不會讓用戶及sponsor衍生錯誤的期待，或者讓團隊成員陷入左右為難的窘境。