10-專案範圍管理(2/10 十大管理)

LHX2018發表於2024-04-27

image

9.1 管理基礎

9.1.1 產品範圍和專案範圍

  • 產品範圍:指某項產品、服務或成果所具有的特徵和功能。產品範圍的完成情況是根據產品需求來衡量的。
  • 專案範圍:包括產品範圍,是為交付具有規定特性與功能的產品服務或成果而必須完成的工作。專案範圍的完成情況是根據專案管理計劃來衡量的。

專案範圍 > 產品範圍

9.1.2 管理新實踐

需求一直是專案管理的關注重點,需求管理過程結束於需求關閉,即把產品、服務或成果移交給接收方,以便長期策略、健康、實現並維持收益。

商業分析師(BA),該角色的職責還應包括需求管理相關的活動,專案經理則負責確保這些活動列入專案管理計劃,並且在預算內按時完成,同時能夠創造價值

專案經理與商業分析師之間應該是夥伴式合作關係

9.2 專案範圍管理過程

9.2.1 過程概述

過程 過程定義 主要作用
1.規劃範圍管理 為了記錄如何定義、確認和控制專案範圍及產品範圍,而建立範圍管理計劃的過程 在整個專案期間對如何管理範圍提供指南和方向
【僅開展一次或僅在專案的預定義點開展】
2.收集需求 為實現目標而確定,記錄並管理干係人的需要和需求的過程 為定義產品範圍和專案範圍奠定基礎
【僅開展一次或僅在專案的預定義點開展】
3.定義範圍 制定專案和產品詳細描述的過程 描述產品、服務或成果的邊界和驗收標準
【整個專案期間多次反覆開展】
4.建立WBS 把專案可交付成果和專案工作分解成較小、更易於管理的元件的過程 為所要交付的內容提供架構
【僅開展一次或僅在專案的預定義點開展】
5.確認範圍 正式驗收已完成的專案可交付成果的過程 使驗收過程具有客觀性
透過確認每個可交付成果來提高最終產品、服務或成果獲得驗收的可能性
【整個專案期間定期開展】
6.控制範圍 監督專案和產品的範圍狀態,管理範圍基準變更的過程 在整個專案期間保持對範圍基準的維護
【在整個專案期間開展】

規劃過程組:1,2,3,4

監控過程組:5,6

9.2.2 裁剪考慮因素

裁剪考慮:

  • 知識和需求管理
  • 確認和控制
  • 開發方法
  • 需求的穩定性
  • 治理

9.2.3 敏捷與適應方法

敏捷或適應型方法特意在專案早期縮短定義和協商範圍的時間,為後續細化範圍、明確範圍爭取更多的時間。在許多情況下,不斷湧現的需求往往導致真實的業務需求與最初所述的業務需求之間存在差異。因此,敏捷方法有目的地構建和審查原型,並透過多次釋出版本來明確需求,範圍會在整個專案期間被定義和再定義

採用敏捷或適應型生命週期,旨在應對大量變更,需要干係人持續參與專案。因此,應將適應型專案的整體範圍分解為一系列擬實現的需求和擬執行的工作(有時稱為產品未完成項),透過多次迭代來併發可交付成果,並在每次迭代開始時定義和批准詳細的範圍。在一個迭代開始時,團隊將努力確定產品未完成項中,哪些優先順序高的未完成項需要在下一次迭代中交付。在每次迭代中,都會重複開展三個過程:①收集需求 ②定義範圍 ③建立WBS

在適應型或敏捷型生命週期中,發起人和客戶代表應該持續參與專案,並對迭代交付的可交付成果提供反饋意見,確保產品未完成項真實地反映了他們的當前需求。在每次迭代中,都會重複開展兩個過程:①確認範圍 ②控制範圍

9.3 規劃範圍管理

image
規劃範圍管理是為了記錄如何定義、確認和控制專案範圍及產品範圍,而建立範圍管理計劃的過程。

本過程的主要作用是在整個專案期間對如何管理範圍提供指南和方向。

本過程僅開展一次或僅在專案的預定義點開展。

9.3.1 輸入

1.專案章程

2.專案管理計劃

3.事業環境因素

4.組織過程資產

9.3.2 工具與技術

1.專家判斷

2.資料分析(備選方案分析)

3.會議

9.3.3 輸出

1.範圍管理計劃:是專案管理計劃的組成部分,描述將如何定義、制定、監督、控制和確認專案範圍。包括:

①制定專案範圍說明書

②根據詳細專案範圍說明書建立WBS

③確定如何審批和維護範圍基準

④正式驗收已完成的專案可交付成果

【可以是正式或非正式的,非常詳細或高度概括的】

2.需求管理計劃:是專案管理計劃的組成部分,描述如何分析、記錄和管理需求。包括:

①如何規劃、跟蹤和報告各種需求活動

②配置管理活動,例如:如何啟動變更,如何分析其影響,如何進行追溯、跟蹤和報告,以及變更審批許可權

③需求優先順序排序過程

④測量指標及使用這些指標的理由

⑤反映哪些需求屬性將列入跟蹤矩陣等

9.4 收集需求

image

9.4.1 輸入

1.立項管理檔案

2.專案章程

3.專案管理計劃

4.專案檔案

5.協議

6.事業環境因素

7.組織過程資產

9.4.2 工具與技術

1.專家判斷

2.資料收集(頭腦風暴,訪談,焦點小組,問卷調查,標杆對照)

3.資料分析(檔案分析)

4.決策(投票,獨裁型決策,多標準決策)

5.資料表現(親和圖:對創意分組;思維導圖)

6.人際關係與團隊技能

  • 名義小組技術:用於促進頭腦風暴的一種技術,透過投票排列最有用的創意
  • 觀察和交談:直接檢視個人在各自環境中如何執行工作/任務和實施流程。觀察也稱為 '工作跟隨',來挖掘隱藏的需求
  • 引導:引導與主題研討會結合使用,把主要干係人召集在一起定義產品需求。研討會可用於快速定義跨職能需求並協調幹系人的需求差異

7.系統互動圖

8.原型法

9.4.3 輸出

1.需求檔案

需求檔案描述各種單一需求將如何滿足專案相關的業務需求。一開始可能只有高層級的需求,然後隨著有關需求資訊的增加而逐步細化。

只有明確的(可測量和可測試的)、可跟蹤的、完整的、相互協調的,且主要干係人願意認可的需求,才能作為基準

需求檔案的格式多種多樣,既可以是一份按干係人和優先順序分類列出全部需求的簡單檔案,也可以是一份包括內容提要、細節描述和附件等的詳細檔案

  1. 業務需求
  2. 干係人需求
  3. 解決方案需求:功能需求和非功能需求
  4. 過渡和就緒需求
  5. 專案需求
  6. 質量需求

2.需求跟蹤矩陣

把產品需求從其來源連線到能滿足需求的可交付成果的一種表格。使用需求跟蹤矩陣,把每個需求與業務目標或專案目標聯絡起來,有助於確保每個需求都具有業務價值。需求跟蹤矩陣提供了在整個專案生命週期中跟蹤需求的一種方法,有助於確定需求檔案中被批准的每項需求在專案結束的時候都能實現並交付

跟蹤需求的內容包括:

  1. 業務需要、機會、目的和目標
  2. 專案目標
  3. 專案範圍和WBS可交付成果
  4. 產品設計
  5. 產品開發
  6. 測試策略和測試場景
  7. 高層級需求到詳細需求等

9.5 定義範圍

image

9.5.1 輸入

1.專案章程

2.專案管理計劃

3.專案檔案

4.事業環境因素

5.組織過程資產

9.5.2 工具與技術

1.專家判斷

2.資料分析(備選方案分析)

3.決策(多標準決策分析)

4.人際關係與團隊技能(典型示例是引導)

5.產品分析

9.5.3 輸出

1.專案範圍說明書:是對專案範圍、主要可交付成果、假設條件和制約因素的描述

內容有:

  • 產品範圍描述
  • 可交付成果
  • 驗收標準
  • 專案的除外責任

9.6 建立WBS

image
WBS最低層的組成部分稱為工作包

9.6.1 輸入

1.專案管理計劃

2.專案檔案

3.事業環境因素

4.組織過程資產

9.6.2 工具與技術

1.專家判斷

2.分解

專案工作分解為工作包,通常需要開展如下活動:

  1. 識別和分析可交付成果及相關工作
  2. 確定WBS的結構和編排方法(樹形和表格/列表)
  3. 自上而下逐層細化分解
  4. 為WBS組成部分制定和分配標識編碼
  5. 核實可交付成果分解的程度是否恰當

WBS注意事項

1)WBS必須是面向可交付成果的

2)WBS必須符合專案的範圍,所有下一級的元素之和必須100%代表上一級的元素

3)WBS的低層應該支援計劃和控制

4)WBS中的元素必須有人負責,而且只有一個人負責

5)WBS應控制在 4~6 層,一個工作單元只能從屬於某個上層單元,避免交叉從屬

6)WBS應包括專案管理工作,也要包括分包出去的工作

7)WBS的編制需要所有(主要)專案干係人的參與

8)WBS並非是一成不變的


分接任務的8/80(每天八小時,持續10天)

9.6.3 輸出

1.範圍基準:是經過批准的範圍說明書、WBS和相應的WBS詞典。只有透過正式的變更控制程式才能進行變更。範圍標準是專案管理計劃的組成部分。

1)專案範圍說明書

2)WBS:全部工作範圍的層級分解

3)工作包:WBS的最低層是帶有獨特標識號的工作包

4)規劃包:規劃包是一種低於控制賬戶而高於工作包的工作分解結構元件,工作內容已知,但詳細的進度活動未知,一個控制賬戶可以包含一個或多個規劃包

5)WBS欄位:是針對WBS中的每個元件,詳細描述可交付成果、活動和進度資訊的檔案

WBS字典中的內容一般包括:賬戶編碼標識、工作描述、假設條件和制約因素、負責的組織、進度里程碑、相關的進度活動、所需資源、成本估算、質量要求、驗收標準、技術參考文獻、協議資訊等

2.專案檔案

9.7 確認範圍

image
確認範圍的步驟包括:

  1. 確定需要進行範圍確認的時間
  2. 識別範圍確認需要哪些投入
  3. 確定範圍正式被接受的標準和要素
  4. 確定範圍確認會議的組織步驟
  5. 組織範圍確認會議

確認範圍過程與控制質量過程的不同之處在於:前者關注可交付成果的驗收,而後者關注可交付成果的正確性及是否滿足質量要求。控制質量過程通常先於確認範圍過程,但二者也可同時進行。


干係人關注的的不同:

  • 管理層關注專案範圍
  • 客戶關注產品範圍
  • 專案管理人員主要關注專案制約因素
  • 專案團隊人員主要關注專案範圍中自己參與的元素和負責的元素

9.7.1 輸入

1.專案管理計劃

2.專案檔案

3.工作績效資料

4.核實的可交付成果

9.7.2 工具與技術

1.檢查(開展測量、審查與確認等活動)

2.決策

9.7.3 輸出

1.驗收的可交付成果

2.變更請求

3.工作績效資訊

4.專案檔案

9.8 控制範圍

image
確保所有變更請求、推薦的糾正措施或預防措施都透過實施整體變更控制過程進行處理。在變更實際發生時,也需要採用控制範圍過程來管理這些變更。控制範圍過程應該與其他專案管理知識領域的控制過程協調開展。未經控制的產品或專案範圍的擴大(未對事件、成本和資源做相應調整)被稱為範圍蔓延

9.8.1 輸入

1.專案管理計劃

2.專案檔案

3.工作績效資料

4.組織過程資產

9.8.2 工具與技術

1.資料分析(偏差分析:偏差是否處於臨界值區間內,趨勢分析:績效是正在改善還是正在惡化)

9.8.3 輸出

1.工作績效資訊

2.變更請求

3.專案管理計劃

4.專案檔案

相關文章