專案的定義是為創造獨特的產品、服務或成果而進行的臨時性工作。請注意定義中的兩點，一是獨特的產品、服務或成果，即專案要有一個成果，這個成果是可控的，不能無限放大;二是臨時性工作，即專案是有時效性的，與專案成果是匹配的，這也印證了專案成果必須是可控的，不能無限放大而失控。專案範疇、時間、成本是專案約束三角形，當一個發生變化時，其他兩個中至少一個會跟隨變化。我認為困擾我們最大的就是範疇管理，客戶對需求本身的不確定性和經常變更，對我們的範疇管理帶來了很大的困擾，從而又引起了進度控制(時間管理)困難，進而增加專案成本。因此，在此我想主要談一談範疇管理。
由於國內資訊化整體水準的影響，使用者再提出資訊化系統需求時均有脫離實際，將資訊化理解成自動化，將企業某一過程的資訊化系統理解成大而全，什麼都想要，什麼都想有。用戶有時自己都無法說清想要的是什麼系統，一會轉向這一會轉向那，這是很危險的信號，如果不能及時理清用戶需求確定專案範疇，那麼該專案就會被無限放大，專案一旦開始就會陷入泥潭，這是其一。其二，專案開始後，用戶對需求提出變更、增加外延、擴大需求等，也會使專案失控而被拖入泥潭。那麼如何規避這種風險呢？結合我們的實際經驗淺談一下專案範疇管理。
專案範疇管理是指對專案包括什麼與不包括什麼的定義與控制過程。這個過程用於確保專案組和專案干係人對作為專案結果的專案產品以及生產這些產品所用到的過程有一個共同的理解。專案的範疇管理，即該專案做什麼?不作什麼?包括什麼?不包括什麼?由於IT專案的特殊性，客戶與專案管理者均難於形象地展示出專案成果，致溝通不暢，理解不一致。我們採用測試先行的思想，在專案之初根據客戶需求整理出一組客戶所想要的測試資料，依此資料理清客戶的功能邏輯、介面風格等，從而確定需求。
專案啟動後，制訂詳細的專案範疇管理計畫，明確專案範疇的定義、記錄、核實和控制，並據此衡量一個專案或專案階段是否已經順利完成。專案範疇計畫完成後，進行專案需求調研。需求調研將專案發起人、客戶和其他干係人提出的功能點進行量化整理，需求調研時針對干係人提出的需求列出測試資料、操作畫面樣例等進行印證，用資料樣例的方式展示關係人的需求，同時詮釋我們的理解，這種方式很直接，可以很好地把需求詮釋清楚，避免需求人提出的需求和我們理解的不一致。
需求調研結束後定義專案範疇，將需求調研階段的成果系統性地進行整理挖掘，對專案交付物進行詳細描述，從而形成需求分析報告，即專案範疇說明書。把需求階段收集的需求點、測試資料樣例進行串聯，把測試資料樣例連貫起來進行加工，修正不一致的功能點，使資料能夠環環相扣，相互印證，這樣，專案關係人的需求就清晰確定了。同時，創建工作分解結構(WBS)，把專案可交付成果和專案工作分解成較小的、更易於管理的組成部分。WBS使得原來看起來非常籠統、非常模糊的專案目標一下子清晰下來，使得專案管理有依據，專案團隊的工作目標清楚明瞭。再把測試資料樣例進行整理套入，使其覆蓋每個WBS工作包，再次印證客戶需求。至此，專案範疇定義完成，專案範疇基準產生，專案範疇基準是控制專案範疇的重要依據。
隨著專案交付成果的產出，核實範疇和控制範疇是必須面臨的兩個重要過程。核實範疇是指正式驗收專案已完成的可交付成果的過程。核實範疇包括與客戶或發起人一起審查可交付成果，確保可交付成果已圓滿完成，並獲得客戶或發起人的正式驗收。核實範疇採用測試樣例代入的方式與客戶進行確認，測試樣例是需求階段與客戶一起整理確認的，是印證專案交付物是否符合客戶需求最好的武器。通過測試樣例找出偏差，啟動控制範疇過程，及時糾正。控制範疇是監督專案和產品的範疇狀態、管理範疇基準變更的過程。專案範疇變更必須進行有效控制，使所有請求的變更、推薦的糾正措施或預防措施都遵循一套規範的變更管理過程。專案變更是不可避免，因而必須強制實施專案範疇變更控制，及時調整專案範疇基準，防止專案範疇蔓延。
專案範疇管理是專案的基石，做好專案範疇管理是專案成功的第一步。在專案範疇確定的情況下，專案時間和成本都是可度量和可計畫的，做好了專案範疇管理，就奠定了時間管理、成本管理基礎，即能形成一個比較穩定的專案管理三角形，整個專案的風險將可以得到很好的控制。當然，就一個專案而言，畢竟是一個整體的過程，僅僅做好專案範疇管理還是不夠的，只有按照專案週期的要求，做好各階段的各項工作，才能保證專案的最終成功。
本文中所描述的利用測試資料樣例確定專案需求的方法在我們多個專案中均有應用，且效果較好，客戶也反映說能夠通過這種方式比較好地理解自己的想法以及想要的功能。以上個人拙見，供各位同仁參考。
文章節錄：項目管理者聯盟
ProjectClub 專案俱樂部為一群專案經理人組成的平台，網站分享專案運作的各種專案管理手法與實用專案工具，並分享如何提昇職場人的軟技巧與硬實力。
