簡單來說，專案範圍管理就是做範圍內的事情，只做範圍內的事情，既不多也不多。
專案範圍管理通過6個主要過程實現：
1） 準備乙個範圍管理計畫流程，描述如何定義、驗證和控制專案的範圍。
2）收集需求。識別和記錄專案利益相關者的相關需求以實現專案目標的過程。
3）定義範圍。詳細描述產品範圍和專案範圍，並準備專案範圍宣告，作為未來專案決策的基礎。
4）建立工作分解結構。將整個專案工作分解為更小、更易於管理的元件，以形成自上而下的分解結構。
5）確認範圍。正式接受已完成的可交付成果。
6）量程控制。監督專案和產品的範圍狀態，管理範圍基線變更。
1. 制定範圍管理計畫。
準備範圍管理計畫是專案或專案群管理計畫的組成部分，它描述了如何定義、開發、監督、控制和驗證專案的範圍
範圍管理計畫指定將用於以下目的的管理流程：
1）制定詳細的專案範圍宣告。
2）根據詳細的專案範圍宣告建立。
3）維護和批准工作分解結構。
4）正式驗收已完成的專案可交付成果。
5） 處理對詳細專案範圍宣告或 WBS 的更改。根據專案的需要，範圍管理計畫可以是正式的或非正式的，非常詳細的或高度概括的。
2.需求管理計畫。
1. 收集需求。
收集需求是識別、記錄和管理人們的需求和需求以實現專案目標的過程。 此過程的主要作用是為定義和管理專案範圍（包括產品範圍）奠定基礎。
1）收集需求流程的工具和技術。
1）面試：面試是通過與部門人員直接交談來獲取資訊的正式或非正式方法。面試通常是在面試官和面試者之間進行的"一對一"對話，但也可以包括多個面試官或多個面試官。
2） 焦點小組：焦點小組是將預先確定的人群和主題專家聚集在一起的焦點小組，以了解他們對所討論的產品、服務或結果的期望和態度，由訓練有素的主持人領導。焦點小組往往不止"一對一"採訪更加熱烈。
3） 指導研討會：指導研討會將主要利益相關者聚集在一起，通過集中討論來定義產品需求。研討會是快速定義跨職能需求和協調利益相關者差異的重要技術。 由於小組互動的性質，有效指導的研討會有助於在參與者之間建立信任，改善關係，改善溝通，從而促進參與者之間的共識。 此外，與個人會議相比，研討會能夠更早地發現問題並更快地解決問題。
4）集團創新技術。
可以組織小組活動以確定專案和產品需求。 以下是一些常用的人群創新技術：
1.>頭腦風暴法。 一種用於生成和收集專案需求和產品需求的多個想法的技術。
2>標稱組技術。 一種用於促進頭腦風暴的技術，通過投票對最有用的想法進行排名，以便進一步進行頭腦風暴或確定優先順序。
3> 概念思維導圖。 將頭腦風暴中獲得的想法整合到乙個圖表中，以反映想法之間的共同點和差異並激發新想法的技術。
4>親和圖。 用於對大量想法進行分組以供進一步審查和分析的技術。
5> 多標準決策分析。 借助決策矩陣，採用系統分析方法建立風險水平、不確定性、價值收益等多個標準，從而對多個選項進行評估和排序。
5）群體決策技術：群體決策技術是評估多個未來行動計畫以達到一定預期結果的過程。此技術用於生成、分類和確定產品需求的優先順序。 例如：
1）一致同意。每個人都同意某種行動方案。
2）大多數原則。在超過50%的小組成員的支援下，可以做出決定。 將參與決策的組數設定為奇數。
防止因平局而無法做出決定。
3）相對多數原則。決策是根據群體中相對多數人的意見做出的，即使它沒有得到大多數人的支援。 它通常在有兩個以上的候選人時使用。
4） *在這種方法中，乙個人為小組做決定。
6）問卷調查：問卷是一系列書面問題，旨在用於受眾多樣化、調查需要快速完成、受訪者地理位置分散、統計分析適合統計分析的情況。
7）觀察：觀察是指直接觀察個人如何在各自的環境中執行工作（或任務）和實施流程。
8）原型製作法：原型製作法是指在實際製造之前建立預期產品的實用模型，並據此徵求對需求的早期反饋。原型方法支援增量詳圖的概念，從模型建立、使用者體驗、反饋收集到原型修改，都需要經歷乙個迭代和迴圈的過程。 經過足夠的反饋迴圈後，原型可用於獲得足夠的資訊，以進入設計或製造階段。
9） 基準測試：基準測試將實際或計畫的做法（例如流程和操作流程）與其他可比組織的做法進行比較，以確定最佳實踐，形成改進建議，並為績效評估提供基礎。用於基準測試的可比組織可以是內部的，也可以是外部的。
10）系統互動圖：系統互動圖是範圍模型的乙個例子，它是對產品範圍的直觀描述，它顯示了業務系統以及它如何與人和其他系統（參與者）互動。系統互動圖顯示了業務系統的輸入、輸入提供者、業務系統的輸出和輸出接收者。
11）文件分析：文件分析是通過分析現有文件並識別與需求相關的資訊來挖掘需求。
3. 範圍的定義。
1. 定義範圍是制定專案和產品詳細描述的過程。
1） 通過明確哪些收集的需求包含在專案範圍內，哪些將排除在專案範圍之外，來明確專案、服務或輸出的邊界。
2）定義範圍最重要的任務是詳細定義專案的範圍邊界，範圍邊界是應該做的工作和不需要執行的工作之間的分界線，範圍的定義可以增加專案時間的準確性， 成本和資源估算，明確專案控制基礎，明確專案相關負責人的職責。明確專案的範圍、基本原理和目標，以及主要的可交付成果。
2.範圍宣告。
1） 專案範圍宣告是對專案範圍、關鍵可交付成果、假設和約束條件的描述。專案範圍宣告記錄了整個範圍，包括專案和產品範圍。 專案範圍宣告詳細說明了專案的可交付成果以及建立這些可交付成果所必須完成的工作。
2）包含內容的詳細範圍描述。
1）專案目標。
2）產品範圍說明。
3）專案要求。
4）專案邊界。
5）專案的可交付成果。
6）專案的約束。
7） 假設。
雖然專案章程和專案範圍說明的內容有一些重疊，但它們的詳細程度完全不同。 專案章程包括高階資訊，而專案範圍宣告是對專案範圍的詳細說明。 在專案過程中，需要逐步細化專案的範圍。
4. 建立工作分解結構。
1. 建立工作分解結構是將專案可交付成果和專案工作分解為更小、更易於管理的元件的過程。
2.WBS的作用和意義。
1）通過對工作結構的分解，分解專案範圍，使專案相關人員對專案一目了然，對專案的概況和組成一目了然。清晰、透明、具體。 使專案經理和專案利益相關者（如投資者或客戶）能夠通過WBS掌握專案，了解和控制專案過程。
2）保證專案結構的系統化和完整性。由於分解過程要求將專案的所有工作都包括在內，因此可以確保專案的規劃和實施中沒有遺漏，從而確保專案的完整性。
3）通過對工作結構的分解，可以建立完整的專案保障體系，因為這個分解過程側重於專案的總體目標，如進度等。
成本和質量被分解為可控的專案單元，以促進執行並實現目標要求。
4）專案工作結構的分解，可以明確專案參與各方的工作介面，便於職責的分工和落實。
5）最終工作分解結構，可直接作為進度計畫和控制的工具。
6）為建立專案溝通管理提供依據，便於掌握資訊焦點。
7）是制定專案各項分計畫和控制措施的依據和主要依據。
8） 有助於防止需求和範圍蔓延。
3. WBS中最低的工作單元稱為工作包，它是我們排程、成本估算和監控的基礎。
4.工作分解結構是用來確定專案範圍的，專案的所有工作都必須包含在工作分解結構中，任何未包含在工作分解結構中的工作都不是專案的組成部分，不能做，否則是"鍍金"。
5. 工作分解結構的準備需要所有專案利益相關者和專案團隊成員的參與。
6、工作分解結構逐層分解。 一般來說，工作分解結構應控制在3-6層。
7. 工作分解結構中的要素應相對獨立，並應儘量減少它們之間的交集。
8、目前常用的工作分解結構主要有兩種形式：（1）層次樹結構，類似於組織結構圖。 樹形圖的 WBS 層次結構清晰、非常直觀且結構化，但不容易修改。 對於大型、複雜的專案，也很難代表專案的全貌。 由於其直觀性，它通常更多地用於一些小型、中等應用中。
2） * 形式，類似於分級圖書目錄。該錶可以顯示專案工作的所有元素，但並不直觀。 但是，在一些大型和複雜的專案中還是用得比較多，因為有些專案分解後，內容更分類，容量更大，以縮排圖表的形式表達起來更方便，也可以裝訂為手冊。
9. 里程碑標誌著可交付成果或階段的正式完成。
10. 工作包是位於工作分解結構每個分支的最低級別的可交付成果或專案工作元件。 根據經驗，8-80 規則（80 小時規則）建議工作包的大小至少需要 8 小時才能完成，總完成時間不應大於 80 小時。
11. 在制定分解結構的過程中，將每個工作包分配給乙個控制科目，並根據："帳號"為工作包建立唯一標識，為成本、進度和資源資訊的分層聚合提供層次結構。 控制帳戶是管理控制點。 在這個控制點，範圍、預算、實際成本和進度被整合在一起，並與掙值進行比較以衡量績效。 控制帳戶是在 WBS 中選擇的管理節點上設定的。 每個控制帳戶可以包含乙個或多個工作包，但乙個工作包只能屬於乙個控制帳戶。 需要生成一些證明檔案，需要與工作分解結構結合使用，稱為工作分解結構字典，其中包括工作分解結構元件的詳細資訊、賬戶程式碼、職位描述、所有者、進度里程碑列表等，還可能包括合同資訊、質量要求、技術文獻、 計畫的活動、資源和成本估算等。
12. WBS用於創作作品的工具和技術。
分解是將專案範圍和專案可交付成果逐步劃分為更小的單元，通常需要以下活動：
1）識別和分析可交付成果和相關工作。
2） 確定 WBS 的結構和編排。
3）從上到下逐層細化分解。
4） 開發並分配 WBS 元件的標識程式碼。
5） 驗證可交付成果是否被分解到適當的程度。
13、分解工作結構應把握以下原則：
1）在層面上保持專案的完整性，避免遺漏必要的元件。
2）工作單位只能隸屬於上級單位，避免交叉從屬。
3）相同的屬性應應用於同一級別的工作單元。
4）工作單位應能分工不同的職責和不同的工作內容。
5）促進專案管理計畫和專案控制的需要。
6）最低級別的工作應該是可比的、可管理的和可定量的。
7）應包括專案管理工作，包括分包工作。
5.確認範圍。
驗證範圍是正式接受已完成的專案可交付成果的過程。 確認範圍需要對可交付成果和工作產品進行審查，以確保專案中的所有工作都準確和令人滿意地完成。 確保專案中的所有工作都準確、令人滿意地完成。 使驗收過程客觀化：通過同時接受每個可交付成果，提高最終產品、服務或結果被驗收的可能性。
1、專案範圍確認工作要點。
範圍驗證過程與質量控制過程的不同之處在於，前者側重於可交付成果的驗收，而後者側重於可交付成果的正確性以及它們是否符合質量要求。 質量控制過程通常先於範圍驗證過程，但兩者也可以同時完成。
2. 確認範圍的一般步驟：
1）確定需要確認範圍的時間。
2） 確定確認範圍所需的輸入。
3）確定正式接受範圍的標準和要素。
4）確定確認範圍會議的組織步驟。
5）組織會議確認範圍。
6.範圍控制。
1.變化是不可避免的，所以在每個專案上，都必須是書面的。 主要工具和技術：偏差分析。
補充資訊：產品範圍和專案範圍。
1）產品範圍;表示產品、服務或結果的特性和功能。 產品範圍包括對產品規格和效能技術指標的描述，即產品的特點和具體功能及效能。 隨著專案的推進，其產品功能將逐步細化。
2）專案範圍：為完成具有指定特性和功能的產品、服務或結果而必須完成的專案工作。專案範圍的完成情況由專案管理計畫、專案範圍報表、WBS、WBS字典來衡量，而產品範圍的完成情況則以產品需求來衡量。 兩個範圍管理需要很好地融合，以確保專案工作產生指定的產品並按時交付。