專案範圍管理的6個過程：

規劃範圍管理收集需求定義範圍建立WBS確認範圍控制範圍

簡單的理解，專案範圍管理就是要做範圍內的事，而且只做範圍內的事，既不少做也不多做。專案範圍管理需要做以下三個方面的工作：

明確專案邊界對專案執行工作進行監控防止專案範圍發生蔓延

產品範圍和專案範圍

產品範圍 是 指產品或者服務所應該包含的功能

專案範圍 是 指為了能夠交付產品，專案所必須做的工作

顯然產品範圍是專案範圍的基礎

專案的範圍基準（scope baseline）是經過批准的專案範圍說明書、WBS和WBS詞典。判斷專案範圍是否完成，要求範圍基準來衡量。而產品範圍是否完成，則根據產品是否滿足了產品描述來判斷。產品範圍變更後，首先受到影響的是專案的範圍。

規劃範圍管理

編制範圍管理計劃，書面描述將如何定義、確認和控制專案範圍的過程。

範圍管理計劃是專案或專案集管理計劃的組成部分，描述將如何定義、制定、監督、控制和確認專案範圍。

範圍管理計劃是制定專案管理計劃過程和其他範圍管理過程的主要輸入，要對將用於下列工作的管理過程做出規定：

如何制定專案範圍說明書如何根據範圍說明書建立WBS如何維護和批准WBS如何確認和正式驗收已完成的專案可交付成果如何處理專案範圍說明書的變更確定wbs滿足職能和專案要求，包括重置和非重置成本保證每一個特定層的總成本等於下一個層次構成要素的成本和從全面適應和連續角度來檢查WBS所有的工作職責需分配到個人或組織單元

專案範圍管理計劃可能在專案管理計劃之中，也可能作為單獨的一項，根據不同的專案，可以是詳細的或者概括的，可以是正式的或者非正式的。

在資訊系統整合專案中，需求管理貫穿於整個過程，它的最基本的任務就是明確需求，並使專案團隊和使用者達成共識，即建立需求基線。另外，還要建立需求跟蹤能力聯絡鏈，確保所有使用者需求都被正確地應用，並且在需求發生變更時，能夠完全地控制其影響範圍，始終保持產品與需求的一致。

需求管理計劃描述在整個專案生命週期內如何分析、記錄和管理需求

規劃範圍管理的輸入：

整體管理計劃專案章程事業環境因素組織過程資產

規劃範圍管理的工具與技術：

專家判斷會議

規劃範圍管理的輸出：

範圍管理計劃需求管理計劃收集需求

收集需求是為實現專案目標而確定、記錄並管理干係人的需要和需求的過程，其作用是為了定義和管理專案範圍奠定基礎。

收集需求旨在定義和管理客戶期望，需求是WBS的基礎、成本、進度和質量計劃也需要在這些基礎上進行。需求開發始於對專案章程和干係人登記冊中相關資訊的分析。

業務需求：整個專案的高層級需求

干係人需求：指干係人或干係人群體的需求

解決方案需求：為了滿足業務需求和干係人需求，產品、服務或成果必須具備的特性、功能和特徵。解決方案需求有進一步分為：功能需求、非功能需求。

功能需求：是關於產品能開展的行為

非功能需求：是對功能需求的補充，是產品正常執行所需的環境條件和質量，例如可靠性、安全性、效能和服務水平

收集需求的輸入：

範圍管理計劃需求管理計劃干係人管理計劃專案章程干係人登記冊

收集需求的工具與技術

訪談：透過與干係人直接交談來獲取資訊的正式或非正式的方法，是最基本的一種收集需求的手段焦點小組（群體訪談）：將預先選定的干係人和主題專家集中在一起，瞭解他們對所提產品、服務或成果的期望和態度。由一位受過訓練的主持人引導大家進行互動式討論。焦點小組比一對一的訪談更加熱烈。焦點小組是一種群體訪談而非一對一訪談，可以有6-10個被訪談者參加。針對訪談者提出問題，被訪談者之間開展互動式討論，以求得到更有價值的意見。引導書研討會：邀請主要的跨職能幹系人一起參加會議，對需求進行集中討論與定義。研討會是快速定義跨職能需求和協調幹系人差異的重要技術。由於群體互動的特點，被有效引導的研討會有助於建立信任、促進關係、改善溝通，從而有利於參加者達成一致意見，能夠比單項會議更快地發現和解決問題。群體創新技術：指可以組織一些群體活動來識別專案和產品需求，群體創新技術包括：頭腦風暴、名義小組技術、德爾菲技術、概念/思維導圖、親和圖和多維標準決策分析。頭腦風暴名義小組：透過投票來排列最有用的創意，以便進行下一步的頭腦風暴或優先排序，名義小組技術是頭腦風暴法的深化應用，是更加結構化的頭腦風暴法，德爾菲技術：組織專家就某一個主題達成一致意見的一種資訊收集技術，由一組選定的專家回答問卷，並對每一輪需求收集的結果再給出反饋，專家的答覆只能給到主持人，以保持匿名狀態概念/思維導圖親和圖：又稱KJ法，是針對某一個問題，充分收集各種經驗、知識、想法和意見等語言、文字資料、透過圖解方式進行彙總，並按其相互親和性歸納整理這些資料，使問題明確起來，求得統一認知，以利於解決的一種方法。親和圖的核心是頭腦風暴法，是根據結果去找原因，可以將大量創意分類，以便審查和分析。多維標準決策分析群體決策技術：為達成某種期望的結果而對多個未來行動方案進行評估一致同意大多數原則相對多數原則獨裁問卷調查觀察原型法標杆對照：將實際或計劃的做法與其他類似組織的做法進行比較，以便識別最佳實踐，形成改進意見，併為績效考核提供依據。系統互動圖檔案分析

收集需求的輸出：

需求檔案：描述各種單一的需求將如何滿足與專案相關的業務需求需求跟蹤矩陣：是將產品需求從其來源連線到能滿足需求的可交付成果的一種表格使用者原始需求-->需求檔案-->下游工作產品 （正向跟蹤，追溯）；使用者原始需求<--需求檔案<--下游工作產品（反向跟蹤，回溯）第四類聯絡鏈是從產品元素回溯到需求檔案第五類聯絡鏈是需求檔案之間的跟蹤定義範圍

定義範圍是制定專案和產品詳細描述的過程，其主要作用是明確所收集的需求哪些將包含在專案範圍內，哪些將排除在專案範圍外，從而明確產品、服務或成果的邊界。

定義範圍的輸入：

範圍管理計劃專案章程需求檔案組織過程資產

定義範圍的工具與技術：

專家判斷產品分析備選方案生成引導式研討會

定義範圍的輸出：

專案範圍說明書產品範圍描述，逐步細化在專案章程和需求檔案中所描述的產品、服務或成果驗收標準，定義可交付成果透過驗收前必須滿足的一系列條件，以及驗收的過程可交付成果專案的除外責任制約因素假設條件，不需驗證即可視為正確、真實或確定的因素專案檔案更新建立工作分解結構（WBS）里程碑：重要的檢查點是里程碑（milestone），主要的里程碑是基線。里程碑標誌著某個可交付成果或階段的正式完成。里程碑關注是否完成工作包：是位於WBS每條分支最底層的可交付成果或專案工作組成部分。工作包不宜太大太小，一般遵循8/80原則。一天/一週一個人能幹完。控制賬戶：是一種管理控制點，是WBS某個層次上的要素，既可以是工作包，也可以是比工作包更高層次上的一個要素。一個控制賬戶可以包括多個工作包，但一個工作包僅能屬於一個控制賬戶。管理團隊在控制賬戶之上考核專案的執行情況，在控制賬戶的相應要素下，將專案執行情況與計劃情況進行比較，以便評價執行情況好壞，並發現與糾正偏差。規劃包：是指在控制賬戶之下，工作包之上的WBS要素，雖然知道它是一個什麼樣的成果，但尚不清楚究竟要做哪些具體的活動才能將成果開發出來的時候。規劃包是暫時用來做計劃的，隨著情況情況逐漸明晰，規劃包終究將被分解成工作包以及相應的活動。WBS詞典：也稱WBS詞彙表，它是描述WBS各組成部分的檔案。

專案範圍分解：

將整個專案分解為工作包，通常需要開展以下工作：

識別和分析可交付成果及相關工作確定WBS的結構和編排方法自上而下逐層細化分解為WBS元件制定和分配標識編碼核實可交付成果分解的程度是恰當的

常用的WBS表現形式主要有分級的樹形結構和表格形式（列表形式），樹形結構的WBS層次清晰、直觀性和結構性強，但不易修改，對大的、負責的專案很難表示出專案的全貌。表格形式直觀性比較差、但能夠反映出專案所有的工作要素

列式：適合大型專案

樹形：中小型專案

建立WBS需要注意以下問題：

WBS必須面向可交付成果WBS必須符合專案的範圍，必須包括且僅包括為了完成專案可交付成果的活動。100%原則要求，WBS的下一級的元素之和必須100%，不多做不少做。WBS的底層應該支援計劃和控制WBS中的元素必須有人負責，而且僅由一個人負責，但可以多人參與WBS應控制在4-6層，如果超過6層，可將大專案分解成子專案，一個工作單元只能從屬於某個上層單元，避免交叉從屬WBS應包括專案管理工作，也要包括分包出去的工作WBS的編制需要所有專案干係人的參與，需要專案團隊成員的參與，各專案干係人站在自己立場上，對同一個專案可能編制出大相徑庭的WBSWBS並非一成不變，在完成WBS之後的工作中，仍然有可能需要對WBS進行修改

WBS的作用：

明確和準確說明專案範圍清楚的定義專案的邊界為各獨立單元分派人員針對獨立單元，進行時間、成本、資源需求量的估算，提高估算的準確性為計劃、預算、進度安排和費用控制奠定共同基礎，確定專案進度和控制的基準將專案工作和專案的財務賬目聯絡起來確定工作內容和工作順序有助於防止需求的蔓延

建立WBS的輸入：

範圍管理計劃專案範圍說明書需求檔案事業環境因素組織過程資產

建立WBS的工具與技術：

分析專家判斷

建立WBS的輸出：

範圍基準（經過批准的範圍說明書、WBS、WBS詞典）專案檔案更新確認範圍

確認範圍是正式驗收專案已完成的可交付成果的過程，其主要作用是使驗收過程具有客觀性、同時，透過驗收每個可交付成果，提高最終產品，服務或成果獲得驗收的可能性。

確認範圍包括與客戶或發起人一起審查可交付成果，確保可交付成果圓滿完成，並獲得客戶或發起人的正式驗收。

確認範圍的主要工具與技術是檢查和群體決策技術，檢查也成為：審查、評審、審計、走查、巡檢、測試

在確認範圍之前，專案團隊需先進行質量控制工作。先質量控制後範圍確認。

確認範圍與核實產品：

核實產品是針對產品是否完成，在專案（或階段）結束時由發起人或客戶來驗證，強調產品是否完整確認範圍是針對專案可交付成果，由客戶或發起人在階段末尾來確認驗收的過程。

確認範圍與質量控制：

確認範圍主要強調可交付成果獲得客戶或發起人的接受，質量控制強調可交付成果的正確性，並符合為其制定的具體質量要求（質量標準）質量控制一般都在確認範圍之前，也可同時進行，確認範圍一般在階段的末尾進行，而質量控制不一定在階段的末尾質量控制屬於內部檢查，由執行組織的相應質量部門實施，確認範圍則是由於外部干係人（客戶或發起人）對專案可交付成果進行檢查驗收

確認範圍與專案收尾：

雖然兩者都是階段的末尾進行，但確認範圍強調是核實與接受可交付成果。而專案收尾強調的是結束專案（或階段）所要做的流程性工作確認範圍和專案收尾都是驗收工作，確認範圍強調驗收可交付成果，專案收尾強調驗收產品。

確認範圍的輸入：

專案管理計劃需求檔案需求跟蹤矩陣確認的可交付成果工作績效資料

確認範圍的工具與技術：

檢查（審查、產品評審、審計、走查、巡檢）群體決策技術

確認範圍的輸出：

驗收的可交付成果變更請求工作績效資訊專案檔案更新控制範圍

控制範圍是監督專案和產品的範圍狀態，管理範圍基準變更的過程，其主要作用是在整個專案期間保持對範圍基準的維護。

範圍變更的原因：

政府政策原因專案範圍的計劃編制不周密詳細，有一定的錯誤和遺漏市場上出現了或者設計人員提出新的技術，新手段或新方案專案執行組織本身發生變化客戶對專案、專案產品或服務的要求發生變化

範圍變更控制的工作：

影響導致範圍變更的因素，並儘量使這些因素向有利的方向發展判斷範圍變更是否已經發生範圍變更發生時管理實際的變更，確保所有被請求的變更按照專案整體變更控制過程處理

控制範圍的輸入：

專案管理計劃需求檔案需求跟蹤矩陣工作績效資料組織過程資產

控制範圍的工具與技術：

偏差分析

控制範圍的輸出：

工作績效資訊變更請求專案管理計劃更新專案檔案更新組織過程資產更新