範圍管理是專案成功的基礎和重要因素。如果不能合理界定專案範圍，專案就無法啟動，無法進行專案管理，意外的變更將會隨時出現，專案也會返工、費用上公升甚至不能完成。
專案範圍管理的核心就是控制專案範圍變更。目前，專案在實施過程中由於受到內外多種因素的影響，使得專案範圍的變更已經不可避免，也無法避免。所以，控制變更的關鍵在於如何規範變更的標準、程式，把範圍變更對專案造成的影響降到最低。
我認為，降低範圍的變更，可以從三方面努力：
一、準確定位專案需求
專案最重要的階段是進行需求分析，明白真正的需求。專案需求指是使用者真正需要什麼，而不是**商假設使用者需要什麼和**商能夠**什麼。需求的準確定位就是要按使用者要求，對目標系統提出完整、準確、清晰、具體要求。這對乙個專案的成功來說非常重要，需求分析做得不好，就會造成需求不斷變更，從而影響進度、費用，甚至會導致專案失敗。但我們往往由於對需求的重要性認識不足，使需求調研不細緻、需求分析不到位、控制變更能力弱。如：
a、需求定位不准。
專案團隊在大多數情況下對於專案了解和理解很少，對專案的背景在廣度和深度兩方面的挖掘不夠、認識不足、把握不准，從而導致了專案需求定位不准。
b、需求不合理。
使用者無法提出完整、詳細需求，或使用者認為已經明確表達自己要求，但實際上專案團隊並不能按照使用者所想象的那樣去理解他們的需求，使用者對於專案期望過高，或希望在短時間看到效果，但由於技術卻滿足不了要求，導致需求過度。
二、科學定義專案範圍
我們定義專案工作範圍，有三種方法，wbs、pbs、工作關係表。
a、樹立「可計畫量」概念。
wbs的分解元、計畫圖的資訊即為「可計畫量」，它是專案的精華。而團隊運轉、人際關係、協調方式、溝通技巧和風險管理等是不可能計畫的，無法放進wbs，是非計畫量，但這部分也需要管理。
b、重視「邊界」。
明確wbs、實施計畫和邊界非常重要。無論什麼專案，範圍的管理都是動態的，存在模糊邊界、交涉邊界和搭接邊界，所以我們一定要重視對邊界問題處理。
c、專案工作範圍是無形和可控的。
對範圍限制來自三方面：成本預算、計畫時間和質量標準。對工作的分解要符合限制條件的要求。
d、按分解的規律去工作。
wbs是工作邏輯的有機體，不同型別的專案分解，有不同的要求，要按照專案自身規律去做事，專案範圍經常變化，是乙個從不確定到確定，再到不確定的迴圈往復的過程，wbs需要進行更新。
變更時應按以下流程進行：
（1）提出變更申請，進行**；
（2）對變更申請進行審查；
（3）對申請變更事項進行分析；
（4）審查分析，如通過，指定角色進行變更；
（5）核實測試工作版本中的變更；
（6）核實發布工作版本中的變更；
（7）變更請求結束。
專案管理（八） 控制專案的範圍
接著上篇，確定了專案的利益相關者之後，先別急著進入開發階段，我們接下來要做的是先控制專案的範圍,專案的範圍控制好了才能保證後續的開發不會因為專案範圍變更而做大量無用功,看下面介紹 一 確定專案不做什麼 實踐經驗告訴我們，在進行專案範圍變更時，或者說在劃分專案邊界時，確定專案不做什麼比確定專案做什麼更...
軟體專案的需求變更管理
一 做好需求工程 需求分析是軟體工程專案最重要 最基礎的起始階段，為後續的規劃設計階段提供參照依據。在軟體研發專案過程中一定要樹立需求工程的意識，將需求視為一項系統工程。為了能夠全面做好需求管理，應根據專案實際情況嚴格劃分專案階段，清晰界定 定義專案階段的基線，在每個專案階段制訂 執行階段性需求管理...
軟體變更控制
軟體生存期內全部的軟體配置是軟體產品的真正代表，必須使其保持精確。軟體工程過程中某一階段的變更，均要引起軟體配置的變更，這種變更必須嚴格加以控制和管理，保持修改資訊，並把精確 清晰的資訊傳遞到軟體工程過程的下一步驟。變更控制包括建立控制點和建立報告與審查制度。對於乙個大型的軟體來說，不加控制的變更很...