專案管理/PMBOK/範圍管理
範圍指的是專案的界限：它決定了在專案生命週期內將完成哪些工作。這包括確定在當前產品/服務開發階段中不包含的工作。在規劃階段，建立輸出以捕獲和定義需要完成的工作。控制和監控過程關注的是管理範圍蔓延，記錄、跟蹤以及批准/拒絕專案變更。最後，收尾過程包括對專案可交付成果的審計，並根據原始計劃評估結果。
範圍涉及產品範圍和專案範圍。專案範圍包括業務需求、專案需求和交付需求。產品範圍包括技術需求、安全需求和效能需求。
亨利·法約爾曾經說過“沒有計劃的行動會導致混亂”。當我們試圖理解與為任何組織設定範圍相關的議題時，這句話就很有意義。因此，設定範圍是規劃階段完成的第一個專案管理流程之一，因為它定義了結果和可交付成果。它是為團隊和利益相關者共同建立一個願景的一部分。
確定專案的範圍是一個非常具有挑戰性的過程。許多因素影響著範圍的確定方式以及該過程的難易程度。例如，如果一個專案正在實施一項新技術，或者是一種相對新穎的服務型別，那麼收集需求的過程可能需要更長的時間才能完成。在確定範圍之前，可能需要先進行原型設計、焦點小組和概念驗證工作，以確定可行性因素。另一方面，具有穩定需求和相對成熟的技術/服務的專案可能更容易計劃。此外，取決於利益相關者溝通和計劃其工作環境的程度，收集設定範圍所需事實的過程可能非常順利，也可能需要經過多輪談判才能達成一個共同的詳細願景。這些只是關於因素如何決定範圍規劃過程的一些簡單示例。
請注意圖 4 中的示例。此圖總結了範圍規劃過程，使用特定的輸入、工具和技術，建立範圍規劃文件作為相應的輸出。
專案經理從專案章程中收集初始專案事實。此外，有關利益相關者工作場所、現有業務模式和規則等的背景資訊有助於建立最終產品/服務的願景，進而形成專案範圍。
當然，成為一名經驗豐富的專案經理會擴大個人範圍規劃技術的範圍。他們可以借鑑以往類似專案的經驗，根據當前專案的時限和成本限制，確定哪些工作是切實可行的。溝通和談判技巧也是“必備”技能。專案經理需要向利益相關者介紹某些需求對專案的潛在影響。增加專案的複雜性可能需要更多的人員、時間和/或資金。它也可能影響專案質量。專案的某些方面可能是不可行的——利益相關者需要了解這一點，以便他們可以調整自己的願景或為未來的挑戰做好準備。
收集需求是範圍定義的一部分，可以使用以下一項或多項技術來完成
完成範圍管理計劃的兩個重要工具包括範圍說明書 (SOS) 和工作分解結構 (WBS) 模板。當然，完成此規劃過程最重要的模板是整體範圍管理計劃的模板。在這本書中，我們概述了 SOS 和 WBS 中通常包含的內容。
SOS 通常以問題陳述開頭。該陳述捕獲與專案基本原理相關的催化劑的描述以及正在建立的新產品/服務的摘要。SOS 的這一部分通常讀起來就像整個專案的執行摘要。
SOS 中一個重要的內容區域是產品/服務特徵/需求和功能的列表。本節通常反映了專案經理、利益相關者和團隊成員之間協商達成的共同願景。此處列出的產品服務不僅反映了專案中包含的內容，還反映了其實現方式（即複雜程度、功能、深度等）。本節還可以包含有關本專案當前範圍中未解決的專案的宣告。
SOS 中的其他部分可能包括預期收益和專案成功標準的列表。還可能有一個部分總結了將包含在專案範圍內的可交付成果的列表。
顧名思義，WBS 列出了完成 SOS 中列出的專案所需完成的所有工作。它使用樹形結構（圖表或列表）來組織工作列表。這意味著該工具本質上是分層的。如本書前文所述，IT 專案有時會根據 SDLC 階段來構建 WBS。這些階段通常構成“根節點”或父專案，每個階段下的所有相關任務都列在下面（通常按可交付成果進行組織）。
更好地解釋可交付成果和工作包。假設您的 WBS 是一棵有三層級的樹。第一層級是樹根，代表您的專案。第二層級是專案的可交付成果，第三層級是工作包。工作包可以進行控制、監控、成本估算和計劃。它們可能具有用於效能管理和掙值估算的控制帳戶。
在分解所需工作時，不要忘記包含所有專案管理活動。這被稱為 100% 規則。
不要忘記 WBS 詞典，它包含對 WBS 元件的文字說明——包括可交付成果和工作包。此詞典可能包括
- 帳戶程式碼識別符號
- 工作描述
- 負責組織
- 計劃里程碑列表
- 相關計劃活動
- 所需資源
- 成本估算
- 質量要求
- 驗收標準
- 技術參考
- 合同資訊
專案的範圍可能會從範圍基線中描述的工作發生變化。專案經理使用控制範圍和驗證範圍流程來控制和管理此類更改，這兩個流程都是監控和控制流程組的一部分。[1][2]
專案經理實施驗證範圍流程，以獲得所有利益相關者的書面確認（正式簽字），確認交付成果與要求和專案管理計劃（正式驗收）相符。驗證範圍流程正式確認利益相關者對專案範圍的接受。
驗證範圍通常是專案經理在專案中執行的最後一個範圍管理流程，因為產品已交付。此外，專案經理還在每個專案階段結束時或需要正式接受任何交付成果時，與客戶驗證範圍。
作為控制範圍流程的結果，專案經理將任何已批准和記錄的專案和產品範圍修改更新到範圍、計劃、基線和 WBS 資訊中。控制範圍流程透過衡量和評估工作績效資料與範圍基線的對比，防止對專案範圍進行不受控制的更改，即範圍蔓延。
自建立範圍基線以來，專案經理在任何需要變更範圍時執行控制範圍。
當範圍計劃良好時，專案經理會提高積極的團隊士氣和專案質量的可能性。但是，這並不意味著專案範圍會隨著時間的推移而成為一個靜態的目標。在執行階段發現新的需求時，範圍會發生變化。這種情況通常發生在將交付成果推出給利益相關者時，從而使產品/服務的功能更具實質性。有時，組織政策在開發過程中會發生變化，這會導致在最終產品/服務中新增/刪除功能。這意味著：無論專案經理如何很好地計劃專案範圍，他/她都必須在執行階段積極控制、監控和調整計劃，以應對發生的更改。
- ↑ 《專案管理知識體系指南》（第三版），第 133 頁，專案管理協會，2004 年
- ↑ PMP 認證考試準備 - 專案範圍管理