專案範圍管理是專案管理中至關重要的管理知識領域，專案範圍包括專案的最終產品或服務定義以及實現該產品或服務所需的各項具體工作。專案範圍管理主要包括範圍管理計劃、範圍定義、制訂WBS、範圍核實、範圍控制等過程。在專案的實施過程中，我重點關注了以下幾個方面。

一、收集需求與定義範圍

軟體的範圍直接與需求相關，需求收集和分析的不到位導致專案執行過程中範圍不斷“蔓延”，是資訊系統專案失敗最常見的原因之一。因此明確專案需求，做好專案範圍定義，確認專案該做的工作，使專案範圍清晰化是專案管理中至關重要的一項工作。xxx專案存在幾個問題：業務流程複雜、涉及干係人眾多、辦公地點分散、缺乏統一業務規範。

針對以上幾個問題，我在需求收集與範圍定義階段採取了以下幾點措施。首先，為了減少需求遺漏的可能性，我著重加強了識別干係人的工作，並召集相關客戶多次的、逐漸細化的需求分析討論會，不斷明晰使用者模糊的需求、挖掘和引導使用者的潛在需求，從而使專案範圍邊界不斷清晰。專案初期，我們特意組織集中的封閉式研討會，將省公司、地市公司及關鍵應用提供商、裝置廠商、卡商等有關人員，集中邀請到海南南沙封閉兩週來集中頭腦風暴專案的需求，輸出需求框架及相關業務規範。其次，我安排需求分析工程師使用Rational Rose畫用例圖，將分析的需求形成需求說明書和需求跟蹤矩陣，在功能性需求與非功能性需求上

在建立WBS過程中，我們重點保障活動無遺漏和可評估。在本專案的實際操作中，我們是將需求檔案做細，將整個系統分為兩大子系統，前臺門戶部分、後臺業務邏輯部分，再細分為50個功能模組，每個功能模組又分別具有多個子功能，這樣需求檔案本身便是一個三級的WBS雛形，WBS的分解也相對容易。我們要求所有底層工作包預估工作量不超過10人日，即兩週工作日做為最小的分解單位，這樣的顆粒度更容易定義和評估。

二、範圍確認

是專案干係人正式接受已完成定義的專案範圍的過程，範圍確認需要審查可交付物和工作成果，以保證專案中所有工作都能正確滿意地完成。

三、專案範圍控制

範圍是最可能變更的基線，範圍變更也是最常見的變更。範圍變更主要源自於使用者的前期需求未正確識別或使用者中後期新增需求。Xxxx專案，由於各個地市公司需要拓展市場，需要將本地具有廣泛使用者群體的代表性業務接入到認證鑑權平臺上來，在專案的實施過程中，隨著應用提供商合作範圍的不斷擴大，個性化的業務需求不斷湧現，使用者使用業務的場景及互動流程都存在差異，對原有的專案範圍基線造成衝擊。

需求變更不可避免，但也不能一味的全盤接受，一定要在專案實施前建立好雙方達成共識的遊戲規則，避免專案範圍失控。我在專案啟動初期，就組織了省公司資料部認證支付室室經理、客戶方專案經理，我方業務部門總監、專案經理、產品經理、架構師等組成CCB變更控制委員會，形成專案管理過程中相關變更事項的變更決策管理機制。包括專案範圍在內的所有專案變更活動，都需要經過變更申請、變更評估、變更批准、變更實施、變更驗證和資訊同步等變更控制流程，保證包括範圍變更在內的專案變更在CCB的控制和變更控制流程的約束下統一進行。制定常態化會議機制，定期由CCB成員共同討論階段性的變更需求，根據優先順序及對專案整體的影響程度綜合評估，來決定接受還是拒絕，通過嚴格的專案範圍變更控制流程，在不排斥需求變更的前提下，實現專案範圍的有序和控制，達到既及時響應客戶需求，滿足系統的實際需要，又是專案範圍始終在可控的範圍內，接受需求變更也要按照流程調整對專案進度、質量、資源、風險等方面的計劃調整。

經過團隊的共同努力，該系統順利在2011年11月份正式上線，半年後通過初驗，得到客戶的好評，本專案的成本得益於我成功的整體管理。回顧專案的實施過程，雖然專案交付物基本上滿足客戶要求，但仍然存在一些不足之處，譬如不能針對地市公司個性化需求的快速響應，系統使用互動介面使用者使用體驗不足等。針對問題，我們及時採取應急措施進行補救，總體上沒有對專案進度、成本及質量造成大的影響。

綜上所述，合理科學的工具和方法詳細的定義專案的範圍、做好專案範圍確認、嚴格控制和管理專案範圍的變更，是我專案中範圍管理中的幾個主要實踐，為專案的成功奠定了基礎。在以後的專案管理工作中，我將不斷的總結學習，多和業界同事交流，努力提高自己的業務和專案管理水平，能夠更好地完成專案管理工作。