一、專案的性質：過去和現在
IT 業內早期的專案比較直接，簡單。大部分是把企業內部的運作進行自動化，例如薪資管理系統，庫存管理系統等。這些專案的範圍可以從功能部門的工作內容，和雇員的工作說明，按人工運作流程等方面搜集功能需求，進而建立專案的範圍。
到了今天，大部分的專案是從概念進而立項，成為專案。例如一些網站的建設，或客戶關係管理( CRM )系統等，這些專案都是跨部門的需求，而且沒有任何模式可以依從。在客戶來說，功能需求也只是一個很模糊的概念，當我們接收一個類似的專案開始進行交付的時候，最感覺頭痛的問題便是如何建立整個專案的明確範圍，建立專案的功能需求。不但合約的服務內容常常含糊不清，或者只有一個服務框架的說明，讓很多技術人員發覺合約簽訂後所建立的『範圍』內包括的工作和交付物，絕對不能按合約簽訂時的服務價格和指定的工期內可以『成功』地把專案完成。
二、建立專案的範圍
上世紀 80 年代中期，一些編程工具開始提供系統快速示範模板建立的功能，利用『快速應用開發』( Rapid Applications Development簡稱RAD )模式進行系統開發，利用工具建立一個示範程序，讓客戶可以看到一些結果，從而啟發客戶對系統的功能需求，一些技術人員認為只有採用這模式才能夠建立初步專案範圍，可惜這是一個錯誤的觀念。
任何一個客戶在決定投資系統開發的時候，已經很明確的知道這系統所能夠帶來的商業效益，不然客戶絕對不會花費這筆系統開發的費用，簽訂有關的合約。縱然是內部的系統開發，要沒有一個商業效益，企業絕對不會投資在系統的開發專案。
當作者開始負責加拿大滿銀行的客戶關係管理( CRM )系統建設的時候，銀行對這專案的目標和最終效益有一個明確的指示：了解客戶對銀行的服務要求，提供客戶所需的高效、優質服務，為銀行建立準確的客戶財務資訊，提升客戶對銀行的滿意度，提供客戶財務投資機會和建立客戶的財務記錄，包括個人帳戶，跟個人有關的企業帳戶，信用卡、貸款、投資等資訊。
從表明上看，我們可以從不同的現有數據庫內有關客戶的記錄進行匯總，建立有關的客戶數據庫，讓銀行能夠得到有關資訊來管理客戶的關係，但客戶資訊管理只是專案的一部分要求，如何才能夠了解客戶對銀行服務的要求，如何提升客戶對銀行的服務滿意度，如何為客戶提供所需的高效優質服務呢？這些都是整個專案的最終效益要求。
三、為效益建立定義
首先我們為這些效益建立個別的定義。我們組合了十數名跟銀行關係密切的客戶，包括企業客戶和個人客戶，共同進行效益定義的探討，同時在不同的分行內為客戶進行調查，以服務範圍和服務態度等方面從中了解客戶對服務的要求和滿意度。我們從實際客戶口中和客戶小組的研討過程中建立有關的效益定義，了解 客戶對銀行服務的實際需求和期盼，也了解客戶所希望達到的服務水平和質量要求。
從客戶的服務需求中我們明確地知道客戶希望銀行能夠為客戶進行全面的理財服務，而且希望能夠讓客戶在實際的服務需求前有足夠的時間進行分析和決定，同時能夠為客戶提供財務的狀態分析，讓客戶能夠全面掌握本身的財務管理資訊。
四、為效益建立解決方案
透過業務流程的開發，數據庫的處理，系統的建設和開發來達到專案的功能需求和商業效益。從解決方案的建立，我們製訂了有關的專案範圍。
每一個專案都有期待的商業效益，而每一個效益按有關的功能需求來完成，只要能夠建立有關的效益定義，是建立範圍的基礎。每一個效益有一樣或多樣的功能需求才能完成，從功能的需求上我們可以建立一個或多個有關的解決方案，而每一個解決方案均有一定的交付物，可能是一個或多個的業務流程，一個或多個系統 的建設，一個或多個數據庫，一個或多個的方法。這些交付物將建立專案的範圍周邊，要能成功地完成專案的指標，我們還需把專案範圍內的工作內容和工作需求建立起來，才能夠有效地管理範圍的變動。
這一個案例讓我們了解範圍的建立並不單依靠客戶所能提供的資訊。往往客戶不知道本身的需求，故此無法提供專案的範圍，要建立服務的範圍，我們必需從效益的定義開始。也只有讓客戶了解專案的最終效益的描述，而能夠讓客戶了解如何能夠提供期待的效益，才能夠降低開發過程的範圍變動，才能夠減少專案過程中的修改，才能夠有效地管理專案的交付。
文章來源：中國專案管理聯盟
