項目範圍變更控制，就是指當項目範圍發生變化時對其採取糾正措施的過程以及為使項目朝著目標方向發展而對某些因素進行調整所引起的項目範圍變化的過程。
項目範圍變更是不可避免的，通常對發生的變更，需要識別是否在既定的項目範圍之內。如果是在項目範圍之內，那么就需要評估變更所造成的影響，以及如何應對的措施，受影響的各方都應該清楚明了自己所受的影響；如果變更是在項目範圍之外，那么就需要商務人員與用戶方進行談判，看是否增加費用，還是放棄變更。因此，項目範圍變更及控制不是孤立的。
基本介紹
- 中文名：項目範圍變更控制
- 特點：項目範圍變更及控制不是孤立的
- 基礎：（進行工作任務分解等
- 任務：對造成範圍變化的因素施加影響等
基礎,步驟,任務,依據,原因,舉例,軟體項目範圍變更控制,範圍項目變更控制流程分析,
基礎
（1）進行工作任務分解
（2）提供項目實施進展報告
（3）提出項目變更請求
（4）項目管理計畫，項目管理計畫應對變更控制提出明確要求和有關規定，以使變更控制做到有章可循。
步驟
（1）在收集到已完成活動的實際範圍和項目變更帶來的影響的有關數據，並據此更新項目範圍後，對範圍進行分析並與原範圍計畫進行比較，找出要採取糾正的地方。
（2）對需要採取措施的地方確定應採取的具體措施。
（3）估計所採取的糾正措施的效果，如果所採取的糾正措施仍無法獲得滿意的範圍調整，則重複以上步驟。
任務
範圍變更是對已批准的工作分解結構所規定的項目範圍進行修正。範圍變更控制的任務有三項：
一是對造成範圍變化的因素施加影響，以保證變化是有益的；
二是判斷範圍變化已經發生；
三是當實際變化發生時對變化進行管理。
範圍變更控制必須與其他控制過程，如時間控制、成本控制、質量控制等結合起來。
依據
範圍變更控制的主要依據包括項目契約檔案、進度報告和變更令。
(一)項目契約檔案
在總承包項目或施工項目契約中，涉及工作範圍描述的是技術規範和圖紙。
技術規範(Specifications)規定了提供服務方在履行契約義務期間必須遵守的國家和行業標準、工作範圍以及項目業主的其他技術要求。技術規範中單列一章“工作範圍(ScopeofWofk)”對需要完成的契約工作做出詳細的文字描述。
業主提供的設計圖紙，以工程語言描述了需要完成的項目工作，簡單而直觀。但其缺陷是當一個項目被劃分成多個契約時，無法從圖紙上區分各個契約的具體內容。即頒發給某一承包商的圖紙，圖紙上的內容並不一定全部是該承包商必須完成的工作。
由於技術規範和圖紙都涉及工作範圍，就有可能產生模糊不清或矛盾，此時技術規範優先於圖紙(Drawinss)。即當兩者發生矛盾時，以技術規範規定的內容為準。
(二)進度報告
進度報告提供了項目範圍執行狀態的信息。例如，項目的哪些中間成果已經完成，哪些還未完成。進度報告還可以對可能在未來引起不利影響的潛在問題向項目組織發出警示信息。
(三)變更令
形成正式變更令的第一步是提出變更請求，變更請求可能以多種形式發生——口頭或書面的，直接或間接的，以及合法的命令或業主的自主決定。變更令可能要求擴大或縮小項目的工作範圍。
原因
大部分變更請求是由於下列原因造成的：
(1)由於外界的因素，如政府法規的變化;
(2)在定義項目範圍方面的錯誤或遺漏;
(3)增值變化，如在一個環境治理項目中，利用最新技術能夠減少費用，而這種技術在定義項目範圍時還未產生。
舉例
軟體項目範圍變更控制
項目範圍變更控制要素分析
制約一個項目的條件是項目“三約束條件”——範圍、時間、成本。在一個項目中這三個條件是相互影響、相互制約的，而且往往是由於範圍變更影響了時間和成本的變更。如果項目一開始確定的範圍小，那么它需要完成的時間以及耗費的成本必然也小，反之亦然。很多項目在開始時都會粗略地確定項目的範圍、時間以及成本，然而在項目進行到一定階段之後往往會變成讓人感覺到不知道項目什麼時候才能真正結束，要使得項目結束到底還需要投入多少人力和物力，整個項目就好像一個無底洞，對項目的最後結束誰的心裡也沒有底。這種情況的出現對於企業的高層來說，他們是最不希望看到的，然而這樣的情況出現並不罕見。造成這樣的結果就是由於沒有控制和管理好項目的範圍。可見項目的三約束中範圍的影響起到關鍵作用。
一般來說，在啟動軟體項目初期，客戶就應該提出一個相對確定的項目範圍，為項目的實施提供一個牢固的前提和框架，同時也是為後期的項目管理劃出一個明晰的 “圈”，所有項目活動的開展，包括項目成本、質量和時間的控制也應該在此範圍內進行。但是，在實際的操作過程中，這個“圈”的邊界有可能會出現模糊、擴大的現象，甚至這些擴大和模糊的部分會給項目帶來風險。項目範圍（Scope）、時間（Time）、成本（Cost）、質量（Quality）之間的關係模型如圖1所示。
如果項目範圍即既定的面積S不變，成本C、質量Q、時間T就可以在一個固定的S的邊界限制下給出一個約束的關係模型 Cost=f(Quality,Time,Scope)。但是，如果S的值並不固定，就如圖1所示出現邊界模糊或者向外擴展時， C、Q、T就失去可依賴的邊界限制，其之間的約束關係就會變得複雜。因此，我們在對項目範圍進行控制時，一是要保證項目初期的S是準確可靠的，儘量減少邊界的模糊性；二是要保證項目實施過程中S的穩定，儘量避免擴大化，或是說讓擴大化受到合理的控制。
範圍項目變更控制流程分析
範圍變更控制是指對有關項目範圍的變更實施控制。主要的過程輸出是範圍變更、糾正行動與教訓總結。
一個項目的範圍計畫可能制訂的非常好，但是想不出現任何改變幾乎是不可能的，因此變更是不可避免的，關鍵問題是如何對變更進行有效的控制。項目經理和項目小組必須意識到範圍變更本身並沒有什麼不對，事實上很多時候這會使系統更健壯、更實用。客戶通常不能一開始就確定所有需求，而且情況會隨時間而變化，如果不能包容變更，那么最終的軟體系統可能就達不到應有的價值。但是如果變更失控，後果也非常嚴重，甚至於導致整個項目的失敗。
變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。為執行變更控制，必須建立有效的範圍變更流程，它對管好項目至關重要。變更控制流程主要包括四個關鍵控制點：授權、審核、評估、確認。在變更過程中要跟蹤和驗證，確保變更被正確執行。範圍變更控制流程如圖2所示。
提交變更請求：項目的任何涉眾均可提交變更請求。通過將變更請求狀態設定為已提交，變更請求被記錄到變更請求追蹤系統中並放置到變更控制委員會（CCB）複審佇列中。
複審變更請求：此活動的作用是複審已提交的變更請求。在 CCB 複審會議中對變更請求的內容進行初始複審，以確定它是否為有效請求。如果是，則基於小組所確定的優先權、時間表、資源、努力程度、風險、嚴重性以及其他任何相關的標準，判定該變更是在當前發布版的範圍之內還是範圍之外。確認重複或拒絕：如果懷疑某個變更請求為重複的請求或已拒絕的無效請求（例如，由於操作符錯誤、無法重現、工作方式等），將指定一個 CCB 代表來確認重複或已拒絕的變更請求。如果需要的話，該代表還從提交者處收集更多信息。
更新變更請求：如果評估變更請求時需要更多的信息，或者如果變更請求在流程中的某個時刻遭到拒絕，那么將通知提交者，並用新信息更新變更請求。然後將已更新的變更請求重新提交給CCB複審佇列，以考慮新的數據。
安排和分配工作：一旦變更請求被置為已打開，項目經理就將根據請求的類型把工作分配給合適的角色，並對項目時間表做必要的更新。
進行變更：指定的角色執行在流程的有關部分中指定的活動集，以進行所請求的變更。 這些活動將包括常規開發流程中所述的所有常規複審活動和單元測試活動。然後，變更請求將標記為已解決。
核實測試工作版本中的變更：指定的角色解決變更後，變更將放置在要分配給測試員的測試佇列中，並在產品工作版本中加以核實。
核實發布工作版本中的變更：已確定的變更一旦在產品的測試工作版本中得到了核實，就將變更請求放置在發布佇列中，以便在產品的發布工作版本予以核實、生成發布說明等，然後關閉該變更請求。
範圍變更控制流程中的每個活動由指定的角色或組織來完成。
