1. 創建工作分解結構WBS

1.1. 自上而下的分解結構

1.2. 把項目可交付成果和項目工作分解成較小的、更易于管理的組件的過程

1.3. 用來確定項目范圍的

1.3.1. 包括分包出去的工作

1.3.1.1. 【21上選40】

1.4. 輸入

1.4.1. 項目范圍管理計劃

1.4.2. 項目范圍說明書

1.4.3. 需求文件

1.4.4. 事業環境因素

1.4.5. 組織過程資產

1.5. 工具與技術

1.5.1. 分解

1.5.1.1. 在層次上保持項目的完整性，避免遺漏必要的組成部分

1.5.1.2. 一個工作單元只能從屬于某個上層單元，避免交叉從屬

1.5.1.3. 相同層次的工作單元應用相同性質

1.5.1.4. 工作單元應能分開不同的責任者和不同的工作內容

1.5.1.5. 便于項目管理計劃和項目控制的需要

1.5.1.6. 最底層工作應該具有可比性，是可管理的，可定量檢查的

1.5.1.7. 應包括項目管理工作，包括分包出去的工作

1.5.2. 專家判斷

1.6. 輸出

1.6.1. 范圍基準

1.6.1.1. 【21下選43】

1.6.1.2. 經過批準的范圍說明書、工作分解結構(WBS)和相應的WBS詞典組成了范圍基準

1.6.2. 項目文件更新

1.6.2.1. 更新需求文件

1.7. 項目管理的基礎

1.7.1. 項目的所有規劃和控制工作都必須基于工作分解結構

1.7.2. 后續管理工作的主要依據

1.7.3. 有助于防止需求和范圍蔓延

1.8. 需要所有項目干系人的參與

1.9. 逐層向下分解的

1.9.1. 應控制在3?6層為宜

1.10. 各要素應該是相對獨立的，要盡量減少相互之間的交叉

1.10.1. 【21下選40】

1.11. 一般用圖表形式表達

1.11.1. 分級的樹型結構

1.11.1.1. 一些小的、適中的應用項目中用得較多

1.11.2. 表格形式

1.11.2.1. 一些大型的、復雜的項目中使用還是較多的

1.12. 里程碑

1.12.1. 某個可交付成果或者階段的正式完成

1.12.2. 具體時間+在這個時間應完成的事件

1.12.3. 關注事件是否完成

1.13. 最低層的工作單元被稱為工作包

1.13.1. 位于工作分解結構每條分支最低層的可交付成果或項目工作組成部分

1.13.2. 8/80規則（80小時原則）建議工作包的大小應該至少需要8個小時來完成，而總完成時間也不應該大于80小時

1.13.3. 分配到一個控制賬戶

1.13.3.1. 控制賬戶是一個管理控制點

1.13.3.1.1. 【22上選40】

1.13.3.2. 設置在WBS中選定的管理節點上

1.13.3.3. 可能包括一個或多個工作包

1.13.3.3.1. 【19下選39】

1.13.4. 一個工作包只能屬于一個控制賬戶

1.13.5. 工作分解結構詞典

1.13.6. 從邏輯上講，不能再分了

1.14. WBS編碼設計

1.14.1. 任何等級的一位項目要素，是其余全部次一級項目要素的總和

1.14.2. 所有子項目的編碼第一位數字是相同的，再下一級的工作單元的編碼依此類推

2. 確認范圍

2.1. 正式驗收已完成的可交付成果

2.2. 正式驗收己完成的項目可交付成果的過程

2.3. 控制質量過程通常先于確認范圍過程

2.4. 由于范圍的確認可以是階段性的，所以交付物可能是中間交付物。這涉及到系統集成項目的驗收問題，即可先分批驗收，最后再終驗，但是每一次驗收都需要客戶的書面確認

2.4.1. 【22下選40】

2.5. 使驗收過程具有客觀性；同時通過驗收每個可交付成果，提高最終產品、服務或成果獲得驗收的可能性

2.5.1. 【19下選41】

2.6. 確認范圍過程與控制質量過程的不同之處在于，前者關注可交付成果的驗收，而后者關注可交付成果的正確性及是否滿足質量要求

2.6.1. 【21下選41】

2.6.1.1. 【21上選41】

2.7. 應該貫穿項目的始終，從WBS的確認或合同中具體分工界面的確認，到項目驗收時范圍的檢驗

2.8. 輸入

2.8.1. 項目管理計劃

2.8.2. 需求文件

2.8.3. 需求跟蹤矩陣

2.8.4. 核實的可交付成果

2.8.5. 工作績效數據

2.8.5.1. 【22上選42】

2.9. 工具與技術

2.9.1. 檢查

2.9.1.1. 【20下選41】

2.9.1.2. 審查、產品審查、審計和巡檢

2.9.2. 群體決策技術

2.9.2.1. 【19上選44】

2.10. 輸出

2.10.1. 驗收的可交付成果

2.10.1.1. 以書面的形式正式簽字批準

2.10.1.2. 沒有被客戶接受的交付物也應當記錄下來，同時還要記錄未被客戶接受的原因

2.10.1.3. 可以是階段性的

2.10.1.3.1. 可能是中間交付物

2.10.2. 變更請求

2.10.3. 工作績效信息

2.10.4. 項目文件更新

2.10.5. 【22上選41】

3. 范圍控制

3.1. 監督項目和產品的范圍狀態，管理范圍基準變更的過程

3.2. 問題

3.2.1. 未經控制的產品或項目范圍的擴大（未對時間、成本和資源做相應調整）被稱為范圍蔓延

3.2.1.1. 【21上選42】

3.2.2. 得不到投資人的批準

3.2.2.1. 【21下選42】

3.2.2.2. 客戶通常只能提出范圍變化的要求，但卻沒有批準的權力

3.2.2.2.1. 【19上選45】

3.2.3. 項目小組未盡責任

3.3. 需求變更及項目范圍變更一定要遵循由變更控制委員會制定的變更控制流程

3.3.1. 【19下選42】

3.4. 缺乏溝通有可能導致范圍或需求不符合客戶要求，有可能導致范圍變更

3.4.1. 【22下選41】

3.5. 在整個項目期間保持對范圍基準的維護

3.6. 輸入

3.6.1. 項目管理計劃

3.6.2. 需求文件

3.6.3. 需求跟蹤矩

3.6.4. 工作績效數據

3.6.5. 組織過程資產

3.7. 工具與技術

3.7.1. 偏差分析

3.7.1.1. 一種確定實際績效與基準的差異程度及原因的技術

3.8. 輸出

3.8.1. 工作績效信息

3.8.2. 變更請求

3.8.3. 項目管理計劃更新