控制專案範圍是指監控專案狀態，發現可交付成果是否滿足文件化的需求，以及管理對專案範圍基線的變更的專案管理活動。

你需要什麼來控制範圍？

首先要看的是專案管理計劃，特別是範圍基線，它是“預期範圍”，與之相比較的是專案的實施範圍，並計算差異。如果有偏差，專案經理需要透過變更控制委員會提出變更請求來計劃糾正或預防措施。

我們從專案管理計劃中使用的其他資訊是需求管理計劃、範圍管理計劃、變更管理計劃和配置管理計劃。這些文件分別告訴我們如何管理需求和範圍的變更，管理基線化文件的任何變更，以及更新可配置項的過程。控制範圍過程也會出現意外，你可能會發現其他的變化，比如需求的變化，從而影響到其他的附屬計劃。

“可配置項”是什麼意思？

簡而言之，可配置項是版本化的文件（或專案工件，如設計、美術、電子表格和原始碼）。這意味著對它們的任何更改都是由團隊中授權的人員進行的，並與所需的團隊成員和/或其他涉眾進行協商，並使用變更控制過程。

這些文件儲存在一個訪問控制的環境中，使用允許多人對同一文件進行更改而不覆蓋彼此修改的系統。配置管理計劃定義了這些項以及控制這些工件變更的過程。當對可配置項進行了批准的更改時，將對其進行版本控制並重新基線化。

我們可能需要返回並參考需求文件和需求追溯矩陣——為了驗證交付是否確實滿足文件化的需求或者存在任何偏差。

接下來，我們將需要知道我們如何執行專案，這是與效能相關的資料。例如有多少可交付成果已經開始，它們處於開發的哪個階段，收到了多少變更請求，以及哪些可交付成果已經完成。

最後，組織為控制範圍而設定的策略、過程、模板和指導方針，以及任何已經可用的模板，將幫助我們更好地控制範圍。

你如何控制範圍？

透過比較專案當前的範圍狀態與基線化的範圍資訊，並發現差異。如果發現了變異，應採取糾正或預防措施。任何變更都需要專案經理（或任何干系人）決定是否需要採取預防或糾正措施，並提出變更請求。當變更請求被變更控制委員會批准時，透過對日程進行必要的變更並重新建立範圍和日程基線來執行它。

對範圍的更改可能會由於不同的原因發生——範圍蔓延、鍍金或客戶請求。有些變更非常小，以至於專案經理（或專案管理團隊）發現實施這些變更對任何專案約束都沒有影響。在這種情況下，變更控制過程是不必要的。

第一個是更改請求。你或客戶可能會發現許多不正確的東西，這樣的“投訴”被記錄下來並透過變更控制委員會。它們用於實施糾正或預防措施，以及管理範圍差異。由於客戶特別要求的範圍變更，也可能會提出變更請求。

附屬管理計劃，如專案管理活動本身的範圍管理計劃，提供了關於我們早先計劃如何完成的反饋。因此，你可以使用這些資訊更新專案管理計劃。

在這個過程中，隨著範圍基線的更新，我們可能會更新成本基線、進度基線以及效能度量基線。

如果變更的影響是巨大的，那麼我們甚至可能最終更新專案文件，如需求文件和需求追溯矩陣。

如何實現範圍變更？

團隊中的某個人或任何涉眾發現需要更改範圍，並提交更改請求。然後，透過執行整合的變更控制流程，將此變更請求提交給變更控制委員會。專案經理可能同時評估變更對專案目標的影響，從而幫助在變更控制會議中做出決定。

如果變更獲得批准，則詳細評估對專案約束（如進度、範圍和成本）的影響。這就是方差分析發揮作用的地方。然後根據方差分析的結果規劃新的工作。

範圍基線被更新以建立新的基線，並分發給團隊。所有進一步的開發工作都將參考這個新的基線。當建立一個新的基線時，以前的基線就過時了。最後根據修改的時間表進行更改以實施。

為執行變更控制，必須建立有效的範圍變更流程。現代

專案管理軟體

8Manage PM可以幫你作出有效的決策，以及衡量是否每個變更都有意義和可負擔。

你和團隊可透過8Manage PM的變更管理模組來處理事務、問題、缺陷報告、改進需求等溝通。在系統中，變更請求可以按照嚴重性進行區分，可以排入不同的優先級別佇列，以便控制訪問許可權，也可重新分配優先順序或轉移變更請求。

控制範圍的重要性在於，它應記錄變更並通知利益相關者。8Manage 提供變更請求功能快捷有效地記錄和管理專案變更，自動實時追蹤和記錄所有提交者和評審者的行為。變更請求可應用於記錄專案 WBS 的更改，變更的影響資訊和變更請求永久關聯，這樣可幫助專案人員作出更加有效和準確的決策與衡量。

專案範圍管理並不難實施，但是這確實需要努力和時間，而專案管理軟體是值得的投資。藉助其流程化的範圍管理將避免專案可能因膨脹範圍和不合要求的清單而面臨的挑戰，以最小的風險交付專案。

TAG: 變更範圍基線文件請求