項目範圍管理包括確保項目做且只做所需的全部工作，以成功完成項目的各個過程。
管理項目範圍主要在於定義和控制哪些工作應該包括在項目內，哪些不應該包括在項目內。
核心概念：
規劃範圍管理：為記錄如何定義、確認和控制項目範圍及產品範圍， 而創建範圍管理計劃的過程
在項目環境中，“範圍”這壹術語有兩種含義：
{
}
從預測型方法到適應型或敏捷型方法， 項目生命周期可以處於這個連續區間內的任何位置。
在預測型生命周期中，在項目開始時就對項目可交付成果進行定義，對任何範圍變化都要進行漸進管理。
在適應型或敏捷型生命周期中，通過多次叠代來開發可交付成果，並在每次叠代開始時定義和批準詳細的範圍。
采用適應型生命周期， 旨在應對大量變更， 需要相關方持續參與項目；因此，應將適應型項目的整體範圍分解為壹系列擬實現的需求和擬執行的工作（有時稱為產品未完項）。在壹個叠代開始 時，團隊將努力確定產品未完項中，哪些最優先項應在下壹次叠代中交付。在每次叠代中，都會重 復開展三個過程：收集需求、定義範圍和創建 WBS。
在預測型項目中，這些過程在項目開始時開展，並在必要時通過實施整體變更控制過程進行更新。
在適應型或敏捷型生命周期中，發起人和客戶代表應該持續參與項目，隨同可交付成果的創建提供反饋意見，並確保產品未完項反映他們的當前需求。在每次叠代中，都會重復開展兩個過程：確認範圍和控制範圍。
在預測型項目中，確認範圍在每個可交付成果生成時或者在階段審查點開展，而控制範圍則是壹個持續性的過程。
在預測型項目中，經過批準的項目範圍說明書、工作分解結構（WBS）和相應的 WBS 詞典構成項目範圍基準。只有通過正式變更控制程序，才能進行基準變更。在開展確認範圍、控制範圍及其他控制過程時，基準被用作比較的基礎。
而采用適應型生命周期的項目，則使用未完項（包括產品需 求和用戶故事）反映當前需求。
項目範圍的完成情況是根據項目管理計劃來衡量的， 而
產品範圍的完成情況是根據產品需求來衡量的。在這裏，“需求”是指根據特定協議或其他強制性規範，產品、服務或成果必須具備的條件或能力。
確認範圍是正式驗收已完成的項目可交付成果的過程。
從控制質量過程輸出的核實的可交付成果是確認範圍過程的輸入，而驗收的可交付成果是確認範圍過程的輸出之壹，由獲得授權的相關方正式簽字批準。因此，相關方需要在規劃階段早期介入（有時需要在啟動階段就介入），對可交付成果的質量提出意見，以便控制質量過程能夠據此評估績效並提出必要的變更建議。
項目範圍管理的發展趨勢和新興實踐：
如何運用商業分析，通過定義、管理和控制需求活動來提高競爭優勢。
商業分析活動可在項目啟動和項目經理任命之前就開始。
{
}
裁剪時需要考慮的因素：
{
}
在敏捷或適應型環境中需要考慮的因素：
不斷湧現的需求往往導致真實的業務需求 與最初所述的業務需求之間存在差異。
因此， 敏捷方法有目的地構建和審查原型， 並通過多次發布版本來明確需求。
這樣壹來，範圍會在在整個項目期間被定義和再定義。
在敏捷方法中，把需求 列入未完項。
========================規劃範圍管理========================
規劃範圍管理是為記錄如何定義、確認和控制項目範圍及產品範圍， 而創建範圍管理計劃的過程。
本過程的主要作用是， 在整個項目期間對如何管理範圍提供指南和方向。
本過程僅開展壹次或僅在項目的預定義點開展。
輸入：
項目章程：
項目管理計劃：
{
項目生命周期描述：項目生命周期定義了項目從開始到完成所經歷的壹系列階段。
開發方法：開發方法定義了項目是采用瀑布式、叠代型、適應型、敏捷型還是混合型開發方法。
}
事業環境因素
{
uu組織文化；
uu基礎設施；
uu人事管理制度；
uu市場條件。
}
組織過程資產
{
}
工具與技術：
家判斷：
{
}
數據分析：
會議：
輸出：
範圍管理計劃：範圍管理計劃是項目管理計劃的組成部分， 描述將如何定義、制定、監督、控制和確認項目範圍。根據項目需要，範圍管理計劃可以是正式或非正式的，非常詳細或高度概括的。範圍管理計劃要對將用於下列工作的管理過程做出規定：
{
}
需求管理計劃（“商業分析計劃”）：需求管理計劃是項目管理計劃的組成部分， 描述將如何分析、記錄和管理項目和產品需求：
{
}
========================收集需求========================
收集需求：為實現項目目標而確定、記錄並管理相關方的需要和需求的過程。
本過程的主要作用是， 為定義產品範圍和項目範圍奠定基礎，
僅開展壹次或僅在項目的預定義點開展。
需求是指根據特定協議或其他強制性規範，產品、服務或成果必須具備的條件或能力。
它包括發起人、客戶和其他相關方的已量化且書面記錄的需要和期望。
應該足夠詳細地探明、分析和記錄這些需求，將其包含在範圍基準中，並在項目執行開始後對其進行測量
需求將成為工作分解結 構（WBS）的基礎，也將成為成本、進度、質量和采購規劃的基礎。
輸入：
項目章程：
項目管理計劃：
{
}
項目文件：
{
}
商業文件
{
}
協議：
事業環境因素：uu組織文化； uu基礎設施； uu人事管理制度； uu市場條件。
組織過程資產：uu政策和程序； uu包含以往項目信息的歷史信息和經驗教訓知識庫。
工具與技術：
專家判斷
{
}
數據收集
{
}
數據分析
{
}
決策：
{
}
數據表現：
{
}
人際關系與團隊技能
{
}
系統交互圖：系統交互圖是範圍模型的壹個例子， 它是對產品範圍的可視化描繪， 顯示業務系統（過程、設 備、計算機系統等）及其與人和其他系統（行動者）之間的交互方式。系統交互圖顯示 了業務系統的輸入、輸入提供者、業務系統的輸出和輸出接收者。
原型法：原型是有形的實物，它使得相關方可以體驗最終產品的模型，而不是僅限於討論抽象的需求描述。原型法支持漸進明細的理念，需要經歷從模型創建、用戶體驗、反饋收集到原型修改的反復循環過程。在經過足夠的反饋 循環之後，就可以通過原型獲得足夠的需求信息，從而進入設計或制造階段。
故事板是壹種原型技術，通過壹系列的圖像或圖示來展示順序或導航路徑。故事板用於各種行業 的各種項目中，如電影、廣告、教學設計，以及敏捷和其他軟件開發項目。在軟件開發中，故事板使用實體模型來展示網頁、屏幕或其他用戶界面的導航路徑。
輸出
需求文件：描述各種單壹需求將如何滿足與項目相關的業務需求。
壹開始可能只有高層級的需求， 然後隨著有關需求信息的增加而逐步細化。
只有明確的（可測量和可測試的）、可跟蹤的、完整的、相互協調的，且主要相關方願意認可的需求，才能作為基準。
需求文件的格式多種多樣，既可以是壹份按相關方和優先級分類列出全部需求的簡單文件，也可以是壹份包括內容提要、細節描述和附件等的詳細文件。
許多組織把需求分為不同的種類（相關方的需要）， 如業務解決方案和技術解決方案（指導需求實現）。
把需求分成不同的類別，有利於對需求進行進壹步完善和細化。需求 的類別包括：
{
}
需求跟蹤矩陣：把產品需求從其來源連接到能滿足需求的可交付成果的壹種表格。
使用需求跟蹤 矩陣，把每個需求與業務目標或項目目標聯系起來，有助於確保每個需求都具有商業價值。
需求跟蹤矩陣提供了在整個項目生命周期中跟蹤需求的壹種方法，有助於確保需求文件中被批準的每項需求在項目結束的時候都能交付。
最後，需求跟蹤矩陣還為管理產品範圍變更提供了框架。
應在需求跟蹤矩陣中記錄每個需求的相關屬性，這些屬性有助於明確每個需求的關鍵信息。
需求跟蹤矩陣中記錄的典型屬性包括唯壹標識、需求的文字描述、收錄該需求的理由、所有者、來源、 優先級別、版本、當前狀態（如進行中、已取消、已推遲、新增加、已批準、被分配和已完成）和 狀態日期。
為確保相關方滿意，可能需要增加壹些補充屬性，如穩定性、復雜性和驗收標準。
========================定義範圍========================
定義範圍：制定項目和產品詳細描述的過程。
本過程的主要作用是，描述產品、服務或成果的邊界和驗收標準。
由於在收集需求過程中識別出的所有需求未必都包含在項目中，所以定義範圍過程就要從需求文件（收集需求過程的輸出）中選取最終的項目需求，然後制定出關於項目及其產品、服務或成果的詳細描述。
應根據項目啟動過程中記載的主要可交付成果、假設條件和制約因素來編制詳細的項目範圍說明書。
在項目規劃過程中，隨著對項目信息的更多了解，應該更加詳細具體地定義和描述項目範圍。
此外，還需要分析現有風險、假設條件和制約因素的完整性，並做必要的增補或更新。
需要多次反復開展定義範圍過程：在叠代型生命周期的項目中，先為整個項目確定壹個高層級的願景，再壹次針對壹個叠代期明確詳細範圍。
通常，隨著當前叠代期的項目範圍和可交付成果的進展，而詳細規劃下壹個叠代期的工作。
輸入：
項目章程
項目管理計劃:
{
}
項目文件:
{
}
事業環境因素：uu組織文化； uu基礎設施； uu人事管理制度； uu市場條件。
組織過程資產:
{
}
工具與技術：
專家判斷：
數據分析：
{
}
決策：
{
}
人際關系與團隊技能：
{
}
產品分析：可用於定義產品和服務， 包括針對產品或服務提問並回答， 以描述要交付的產品的用途、特征及其他方面。每個應用領域都有壹種或幾種普遍公認的方法，用以把高層級的產品或服務描述轉變為有意義的可交付成果。首先獲取高層級的需求，然後將其細化到最終產品設計所需的詳細程度。產品分析技術包括（但不限於）：
{
}
輸出：
項目範圍說明書：是對項目範圍、主要可交付成果、假設條件和制約因素的描述。
它記錄了整個範圍，包括項目和產品範圍；詳細描述了項目的可交付成果；
還代表項目相關方之間就項目範圍所達成的***識。
為便於管理相關方的期望，項目範圍說明書可明確指出哪些工作不屬於本項目範圍。
項目範圍說明書使項目團隊能進行更詳細的規劃，在執行過程中指導項目團隊的工作，並為評價變 更請求或額外工作是否超過項目邊界提供基準。
項目範圍說明書描述要做和不要做的工作的詳細程度，決定著項目管理團隊控制整個項目範圍的有效程度。
詳細的項目範圍說明書包括以下內容（可能直接列出或參引其他文件）：
{
}
雖然項目章程和項目範圍說明書的內容存在壹定程度的重疊，但它們的詳細程度完全不同。
項目章程包含高層級的信息，而項目範圍說明書則是對範圍組成部分的詳細描述，這些組成部分需要在項目過程中漸進明細。
項目文件更新：
{
}
========================創建WBS========================
創建WBS：將項目可交付成果和項目工作分解為較小的、更易於管理的組件的過程。
本過程的主要作用是， 為所要交付的內容提供架構， 它僅開展壹次或僅在項目的預定義點開展。
WBS是對項目團隊為實現項目目標、創建所需可交付成果而需要實施的全部工作範圍的層級分解。
WBS 組織並定義了項目的總範圍，代表著經批準的當前項目範圍說明書中所規定的工作。
WBS 最低層的組成部分稱為工作包，其中包括計劃的工作。
工作包對相關活動進行歸類，以便對工作安排進度、進行估算、開展監督與控制。
在“工作分解結構”這個詞語中，“工作”是指作為活動結果的工作產品或可交付成果，而不是活動本身。
輸入：
項目管理計劃：項目範圍管理計劃（範圍管理計劃定義了如何根據項目範圍說明書創建 WBS。）
項目文件：
{
}
事業環境因素：包括（但不限於）項目所在行業的 WBS 標準，這些標準可以作為創建 WBS 的外部參考資料。
組織過程資產：uu用於創建 WBS 的政策、程序和模板； uu以往項目的項目檔案； uu以往項目的經驗教訓。
工具與技術：
專家判斷：
分解：
分解是壹種把項目範圍和項目可交付成果逐步劃分為更小、更便於管理的組成部分的技術；
工作包是 WBS 最低層的工作，可對其成本和持續時間進行估算和管理。
分解的程度取決於所需的控制程 度，以實現對項目的高效管理；
工作包的詳細程度則因項目規模和復雜程度而異。
要把整個項目工作分解為工作包，通常需要開展以下活動：
{
}
圖 圖 5-12 顯示了某工作分解結構的壹部分，其中若幹分支已經向下分解到工作包層次。
對 WBS 較高層組件進行分解，就是要把每個可交付成果或組件分解為最基本的組成部分，即可核實的產品、服務或成果。
如果采用敏捷方法，可以將長篇故事分解成用戶故事。
WBS 可以采用提綱式、組織結構圖或能說明層級結構的其他形式。
通過確認 WBS 較低層組件是完成上層相應可交付成果的必要且充分的工作，來核實分解的正確性。
不同的可交付成果可以分解到不同的層次。
某些可 交付成果只需分解到下壹層，即可到達工作包的層次，而另壹些則須分解更多層。
工作分解得越細 致，對工作的規劃、管理和控制就越有力。
但是，過細的分解會造成管理努力的無效耗費、資源使 用效率低下、工作實施效率降低，同時造成 WBS 各層級的數據匯總困難。
要在未來遠期才完成的可交付成果或組件， 當前可能無法分解。
項目管理團隊因而通常需要等待對該可交付成果或組成部分達成壹致意見，才能夠制定出 WBS 中的相應細節。這種技術有時稱做滾動式規劃。
WBS 包含了全部的產品和項目工作，包括項目管理工作。
通過把 WBS 底層的所有工作逐層向上匯總，來確保既沒有遺漏的工作，也沒有多余的工作。
這有時被稱為 100% 規則。
輸出：
範圍基準：是經過批準的範圍說明書、WBS 和相應的 WBS 詞典，只有通過正式的變更控制程序才能 進行變更，它被用作比較的基礎。範圍基準是項目管理計劃的組成部分，包括：
{
}
項目文件更新：
{
}
========================確認範圍========================
確認範圍：正式驗收已完成的項目可交付成果的過程。
本過程的主要作用是，使驗收過程具有客觀性；
同時通過確認每個可交付成果，來提高最終產品、服務或成果獲得驗收的可能性。
本過程應 根據需要在整個項目期間定期開展。
由客戶或發起人審查從控制質量過程輸出的核實的可交付成果，確認這些可交付成果已經圓滿完成並通過正式驗收。
本過程對可交付成果的確認和最終驗收，需要依據：從項目範圍管理知識領域的各規劃過程獲得的輸出（如需求文件或範圍基準），以及從其他知識領域的各執行過程獲得的工作績效數據。
確認範圍過程與控制質量過程的不同之處在於，前者關註可交付成果的驗收，而後者關註可交付成果的正確性及是否滿足質量要求。控制質量過程通常先於確認範圍過程，但二者也可同時進行。
輸入：
項目管理計劃：
{
}
項目文件：
{
}
核實的可交付成果：核實的可交付成果是指已經完成，並被控制質量過程檢查為正確的可交付成果。
工作績效數據：工作績效數據可能包括符合需求的程度、不壹致的數量、不壹致的嚴重性或在某時間段內開展確認的次數。
工具與技術：
檢查：
指開展測量、審查與確認等活動，來判斷工作和可交付成果是否符合需求和 產品驗收標準。
檢查有時也被稱為審查、產品審查和巡檢等。
在某些應用領域，這些術語具有獨特 和具體的含義。
決策：投票（當由項目團隊和其他相關方進行驗收時，使用投票來形成結論。）
輸出：
驗收的可交付成果：
符合驗收標準的可交付成果應該由客戶或發起人正式簽字批準。
應該從客戶或發起人那裏獲得正式文件， 證明相關方對項目可交付成果的正式驗收。
這些文件將提交給結束項目或階段程序
工作績效信息：工作績效信息包括項目進展信息
需求變更：對已經完成但未通過正式驗收的可交付成果及其未通過驗收的原因，應該記錄在案。可能需要針對這些可交付成果提出變更請求，開展缺陷補救。
項目文件更新：
{
}
========================控制範圍========================
控制範圍：監督項目和產品的範圍狀態，管理範圍基準變更的過程。
本過程的主要作用是，在整 個項目期間保持對範圍基準的維護，且需要在整個項目期間開展。
控制項目範圍確保所有變更請求、推薦的糾正措施或預防措施都通過實施整體變更控制過程進行處理。
在變更實際發生時，也要采用控制範圍過程來管理這些變更。
控制範圍過程應該與其他控制過程協調開展。
未經控制的產品或項目範圍的擴大（未對時間、成本和資源做相應調整）被稱為範圍蔓延。
變更不可避免，因此在每個項目上，都必須強制實施某種形式的變更控制。
輸入：
項目管理計劃：
{
}
項目文件：
{
}
工作績效數據：
組織過程資產：
{
}
工具與技術：
數據分析：確定偏離範圍基準的原因和程度，並決定是否需要采取糾正或預防措施，是項目範圍控制的重要工作。
{
}
輸出：
工作績效信息：
本過程產生的工作績效信息是有關項目和產品範圍實施情況（對照範圍基準）的、相互關聯且與各種背景相結合的信息，包括收到的變更的分類、識別的範圍偏差和原因、偏差對進度和成本的影響，以及對將來範圍績效的預測。
變更請求：分析項目績效後，可能會就範圍基準和進度基準，或項目管理計劃的其他組成部分 提出變更請求。
項目管理計劃更新：
{
}
項目文件更新：
{
}