一個專案的範疇在定義上並不困難，但卻是很多專案無法驗收的關鍵點，範疇錯誤，時程、成本與資源的預估都是錯誤的，甚至可以說是整個專案的規劃都會出了問題，一個範疇定義不清或者範疇控制不當的專案，到專案後期的修正成本往往非常高，而範疇定義首重需求的收集與確認，前頭多下功夫，後頭才會輕鬆。
範疇管理大概是我們在工作上頭最關鍵的一項工作了，當老闆交辦一項工作下來時，你如何確保你完全明瞭老闆要你做的內容是什麼？也就是說做到那些東西就能滿足老闆的需求，老闆要的是一部LUXGEN的國產車，你卻買了一台日製的TOYOTA給他，因為你告訴他TOYOTA的車品質比較好，而且比較省油，但老闆卻跟你說他買LUXGEN的原因是他愛國，把你痛罵了一頓，說你搞不清楚狀況，當你犯了類似的錯誤，代表你執行的範疇不對，因為範疇管理清楚的告訴我們：「完成所有範疇內的事情，且只做範疇內的事情。」
專案的範疇就像這個：
(http://urachris.pixnet.net/blog/post/32233020-%E5%81%87abc)
那個黃線就是我的邊界，黃線內的東西歸我管，我就會努力做完，你到黃線外我就不理會了，簡單的說，專案範疇就像一個圈，將這個專案要做的項目劃進圈內，不做的、暫時不做的則畫到圈外，如下圖所示，我們可以看到有些在圈內中，有些是部分在圈內，有些則在圈外，在圈內的就是專案一定會做的，部分在圈內的，則必須要盡快討論清楚是否要做，而在圈外的，我們則要持續關注(注意，是要關注，不是不用理會)，在確認專案範疇時，專案經理必須要精確的跟Sponsor確認清楚哪些「要做」、哪些「不做」，為什麼我們要關注那些不做的呢？因為專案進行中常常會出現前面說不做，後面卻反過來說要做的狀況，留下紀錄對於專案的控管是非常重要的。
在軟體行業中，我們定義專案範疇習慣上用的是系統邊界，如下圖所示，在跟Sponsor溝通專案範疇時我們可能會畫這樣簡單的示意圖，明確的說明本專案只做哪些內容，例如以下，我們可以看到做一個電子商務的網站，物流與金流兩塊在本專案中不會實作，而是透過與3rd party廠商的系統整合，而整合的API介面則由廠商定義(若介面由我們自己定義與開發，那也要劃入系統邊界內)，所以本專案的主要範疇為App、電子商務平台、進銷存系統三塊，這樣我們可以先簡要的定義出專案範疇，而進一步的細節則需再往下看看各個子系統的模組與特性配置。
在定義範疇時，如果要定義的更精細一點，我們會將各個子系統的模組定義出來，並在每個模組中配置需求特性(不懂的可以參考這篇)，確保每個特性都被配置到模組中，這樣子我們就可以將這個專案的範疇給定義清楚了，因為所有的需求，我們都已經涵蓋進來，我們看到的模組內容，就是我們的專案範疇了，往後我們只要透過追溯關係來進行範疇的追溯與控制。
一個專案的範疇在定義上並不困難，但卻是很多專案無法驗收的關鍵點，範疇錯誤，時程、成本與資源的預估都是錯誤的，甚至可以說是整個專案的規劃都會出了問題，一個範疇定義不清或者範疇控制不當的專案，到專案後期的修正成本往往非常高，而範疇定義首重需求的收集與確認，前頭多下功夫，後頭才會輕鬆。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
