心智圖資源庫 第五章專案範圍管理
專案管理師是指掌握專案管理原則、技術、方法和工具,參與或領導啟動、規劃、組織、執行、控制和收尾過程的活動,確保專案能在規定的範圍、時間、品質與成本等約束條件下完成既定目標的人員。
編輯於2022-06-21 11:42:52This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
第五章專案範圍管理
專案範圍管理
專案目標得更具體的表達,必須在幹係人之間達成一致 做範圍內的事,而且只做範圍內的事,既不少做也不多做
1明確專案邊界 2對專案執行工作進行監控 3防止專案範圍發生蔓延
範圍蔓延:客戶提出新要求,超出範圍基準;未經控制的產品或專案範圍擴大 ——專案外部原因造成的蔓延
範圍鍍金:客戶沒有提新要求,專案自己額外做了不需要工作 ——專案團隊內部原因造成的蔓延
範圍潛變:客戶不斷提出小的、不易察覺的範圍改變,不加控制,累加導致專案嚴重偏離範圍基準,專案失控或失敗
產品範圍(技術主線):產品或服務縮影保險的功能 ——強調結果
判斷產品範圍是否完成:根據產品是否滿足了產品描述來判斷
專案範圍(管理主線):為了能夠交付產品,專案必須做的工作 ——強調過程
判斷專案範圍是否完成:專案範圍基準(經核准的專案範圍說明書、WBS、WBS字典)
產品範圍市專案範圍的基礎,產品範圍的定義是專案範圍的描述,專案範圍的定義是產品專案管理計畫的基礎 產品範圍描述市專案範圍說明書的重要部分,產品範圍變更後首先影響專案範圍
規劃範圍管理
輸入:1專案管理計畫 2專案章程 3事業環境因素 4組織過程資產
工具與技術:專家判斷 會議
產出:1範圍管理計劃 2需求管理計劃
範圍管理計劃
內容: 1.如何制定專案範圍說明書 2.如何根據範圍說明書建立WBS(工作分解結構) 3.如何維護和批准WBS 4.如何確認和正式驗收已完成的專案可交付成果 5.如何處理專案項目範圍說明書的變更
WBS編製指南內容: 1.確定WBS滿足職能和專案的要求,包括重置和非重置成本 2.檢查WBS是否為所有的專案工作提供了邏輯細分 3.保證每一個特定層的總成本等於下一個層次構成要素的成本和 4.從全面適應和連續角度來檢查WBS 5.所有的工作職責需分配到個人或組織單位
需求管理計劃
需求管理計畫描述在整個專案生命週期中如何分析、記錄和管理需求。貫穿整個過程, 最基本任務: 明確需求,並使專案團隊和使用者達成共識,建立需求基線,建立需求追蹤能力聯繫鏈,確保所有使用者需求都被正確地應用,並且在需求發生變更時,能夠完全地控制其影響範圍,始終保持產品與需求的一致性。
內容: ①如何規劃、追蹤和報告各種需求活動 ②需求管理需要使用的資源、③培訓計劃 ④專案利害關係人參與需求管理的策略 ⑤判斷專案範圍與需求不一致的準則與修正規程 ⑥需求追蹤結構、⑦配置管理活動
收集需求
輸入:1範圍管理計畫 2需求管理計畫 3利害關係人管理計畫 4計畫章程 5利害關係人登記冊
輸出: 需求文件(窮盡法) 需求追蹤矩陣
工具與技術:1訪談 2焦點小組 3引導式研討會 4群體創新技術 5群體決策技術 6問卷調查 7觀察 8原型法 9標竿對照 10系統交互圖 11文件分析
需求分類
業務需求:實施專案的原因(整個組織的高階需求)
解決方案需求(功能需求、非功能需求)
利害關係人需求
過渡需求
專案需求
品質需求:用於確認可交付成果完成的標準1.基本需求2.期望需求3.意外需求
工具與技術
訪談
焦點團體(一對多群體訪談,獲得更有價值的集體意見)
引導式研討會(快速定義跨職能需求,協調利害關係人差異,做終於形成既定目標的一致意見)
群體創新技術
腦力激盪法BS(各抒己見)
名義小組技術(BS的深化、結構化BS,投票排序)
德爾菲技術:防止個人觀點被不正確放大(專家、匿名、多輪、趨同、消除偏見)
概念/心智圖(心智圖、腦圖,反映共通性與差異,激發新創意)
親和圖(KJ圖,核心是BS,有助於WBS製訂)
多標準決策分析(多種標準、權重、評估、排序)
群體決策技術(一致同意、多數原則、相對多數原則、獨裁)
標竿對照(別人家的孩子,可比較組織、內部、外部、辨識最佳實踐、形成改進意見、為績效考核提供依據)
問卷調查
觀察
原型法(減輕風險、漸進明細、敏捷、分鏡)
系統互動圖(拓樸圖、視覺化)
文件分析(分析現有文件)
需求文件
既可以是一份按幹係人和優先級分類列出全部需求的簡單文件,也可以是一份包括內容提要、細節描述和附件等的詳細文件
內容:①業務需求②幹係人需求③解決方案需求④專案需求⑤過渡需求 ⑥與需求有關的假設條件、依賴關係及限制因素
需求追蹤
需求管理包括在產品開發過程中維持需求一致性和精確性的所有活動,包括控制需求基線,保持專案計畫與需求一致,控制單一需求和需求文件的版本情況,管理需求和聯繫鏈之間的聯繫,或管理單一需求和專案其他可交付物之間的依賴關係,追蹤基準中需求的狀態。
可跟踪性:需求跟踪是將單一需求和其他元素之間的依賴關係和邏輯聯繫建立跟踪,包括各種類型的需求、業務規則、系統組件,以及幫助文件等。
雙向可追蹤性
正向追蹤:檢查需求文件中的每個需求是否都能在後繼工作產品(成果)中找到對應點; (以免需求被做漏、做偏)
反向追蹤:逆向跟踪,檢查設計文件、產品構件、測試文件等工作成果是否都能在需求文件中找到出處。 (是查需求源頭,了解為什麼要做這個需求,來源背景和原因是什麼)
1.從使用者原始需求可向前追溯到需求文件,可區分受變更影響的需求,確保需求文件包含所有使用者需求
2.從需求文件回溯到對應的使用者原始需求,確認每個需求的出處
3.從需求文件追溯到產品元素,可知每個需求對應的產品元素,從而確保產品元素滿足需求
4.產品元素回溯到需求文件,使專案團隊成員知道產品元素存在的原因 (如無法回溯到需求文件,則可能是鍍金;如果孤立的產品元素是一個正當功能,則可能是需求遺漏)
5.需求文件之間的追蹤,便於更好地處理各種需求之間的邏輯相關性,檢查需求分解中可能出現的錯誤或遺漏
需求追蹤矩陣
表示需求和其他產品元素之間的聯繫鏈的最普遍方式是使用需求追蹤(能力)矩陣,需求追蹤矩陣是將產品需求從其來源連接到能滿足需求的可交付成果的一種表格。
需求追蹤矩陣中記錄的典型屬性包括唯一識別、需求的文字描述、收錄該需求的理由、所有者、來源、優先順序、版本、當前狀態(例如,進行中、已取消、已推遲、新增加、已批准、已分配、己完成等)和狀態日期。
定義範圍
輸入:1範圍管理計畫 2專案章程 3需求文件 4組織過程資產
工具與技術:1專家判斷 2產品分析 3備選方案產生 4引導式研討會
輸出:1專案範圍說明書 2專案文件更新
專案範圍說明書
內容
①產品範圍描述(逐步細化在專案章程和需求文件中所描述的產品、服務或成果的特徵) ②驗收標準(定義可交付成果通過驗收前必須滿足的一系列條件,以及驗收的過程) ③可交付成果 ④專案的除外責任(需辨識出什麼是被排除在專案之外的。明確說明哪些內容不屬於專案範圍,有助於管理利害關係人的期望) ⑤限制因素 ⑥假設條件
作用:①確定範圍、②溝通基礎、③規劃與控制依據、④變更基礎、⑤規劃基礎
創建WBS
輸入:1範圍管理計畫 2專案範圍說明書 3需求文件 4事業環境因數 5組織流程資產
工具與技術:1分解 2專家判斷
輸出:1範圍基準 2專案文件更新
WBS層次
里程牌
里程碑標誌著某個可交付成果或階段的正式完成。重要的檢查點是里程碑、重要的里程碑是基線
工作包
工作包應便於完整地分派給不同的人或組織單元,所以要求明確各工作單元直接的介面。工作包應非常具體,以便承擔者能明確自己的任務、努力的目標和承擔的責任。 8/80規則(80小時原則)建議工作包的大小至少需要8小時來完成,而總完成時間也不應該大於80小時
控制帳戶
一種管理控制點。在該控制點上,將範圍、預算(資源計劃)、實際成本和進度加以整合,並將它們與掙值進行比較,以測量績效。 控制帳戶是WBS某個層級的要素,既可以是工作包,也可以是比工作包更高層次上的要素。
規劃戶
在控制帳戶之下,工作內容已知但尚缺詳細進度活動的WBS組成部分。規劃包是在控制帳戶之下、工作包之上的WBS要素。 規劃包是暫時用來做規劃的,隨著情況的逐漸清晰,規劃包最終將被分解成工作包以及相應的具體活動。
WBS字典
也稱WBS詞彙表,描述WBS各組成部分的文件。對於WBS的每一組成部分,包括帳戶編碼標識、工作說明、假設條件和限制因素、負責人或組織單元、進度里程碑、相關的進度活動、所需資源、成本估算、品質要求、驗收標準、技術參考文獻、協議資訊等。 (WBS字典實際上是相當於新華字典,是WBS中每個元素的描述)
範圍基準
專案範圍說明書--是專案範圍、主要可交付成果、假設條件和限制因素的描述。記錄了整個範圍, 包括項目和產品範圍。
WBS--全部工作範圍的層級分解(有助於防止範圍蔓延)
WBS字典--針對每個WBS組件,詳細描述可交付成果、活動和進度資訊的文件(有助於評估變更的影響)
WBS分解
分解需開展活動
①識別及分析可交付成果及相關工作。
②確定WBS的結構和編排方法。
③自上而下逐層細化分解。
④為WBS組件製定和分配標識編碼。
⑤核實可交付成果分解的程度是恰當的
應該由全體專案團隊成員、使用者和專案利害關係人共同完成和一致確認。
WBS劃分原則
①功能或技術原則:在創建WBS時,需要考慮將不同人員的工作分開。
②組織架構:對於職能型的專案組織而言,WBS也要適應專案的組織架構形式
③系統或子系統:總的系統分割為幾個主要的子系統,然後再對每個子系統進行分解。
WBS分解方法
①專案生命週期的各階段作為分解的第二層,產品和專案可交付成果放在第三層
②主要可交付成果作為分解的第二層
③整合可能由專案團隊以外的組織來實施的各種組件(例如,外包工作),然後作為外包工作的一部分,賣方需編制相應的合約WBS。
WBS表示形式
樹型結構(組織結構圖式):WBS層次清晰、直覺性和結構性強,但不容易修改,對大的、複雜的項目很難表示出項目的全貌(小項目)。
表格形式(列表式):表格形式的直覺性比較差,但能反映出專案所有的工作要素(大項目)。
WBS分解注意8個方面
①WBS必須是面向可交付成果的:所有下一級的元素總和必須100%的代表上一級元素。
②WBS必須符合專案的範圍。 WBS必須包括,也僅包括為了完成專案的可交付成果的活動
③WBS的底層應該支援計劃和控制。 WBS是專案管理計劃和專案範圍之間的橋樑,WBS的底層不僅要支持專案管理計劃,而且要讓管理層能夠監視和控制專案的進度和預算。
④WBS中的元素必須有人負責,而且只由一個人負責,儘管實際上可能需要多個人參與。
⑤WBS的指導,WBS應控制在4〜6層。當然,大項目可以超過6層。
⑥WBS應包括專案管理工作(因為管理是專案具體工作的一部分),也要包括分包出去的工作。
⑦WBS的編制需要所有(主要)專案利害關係人的參與,需要專案團隊成員的參與。
⑧WBS並非是一成不變的。在完成了WBS之後的工作中,仍然有可能需要對WBS進行修改。
確認範圍
輸入:1專案管理計畫 2需求文件 3需求追蹤矩陣 4核實的可交付成果 5工作績效數據
工具與技術:1檢視 2群體決策技術
輸出:1驗收的可交付成果 2變更請求 3工作績效資訊 4專案文件更新
正式驗收專案已完成的可交付成果的過程 貫穿專案始終 客戶或發起人一起審查可交付成果
確認範圍的步驟:①確定需要進行範圍確認的時間、②識別範圍確認需要哪些投入、③確定範圍正式被接受的標準與要素、④確定範圍確認會議的組織步驟、⑤組織範圍確認會議。
關注點不同:
管理階層:關注專案範圍,指範圍對專案的進度、資金和資源的影響,這些因素是否超過了組織承受範圍,是否在投入產出上具有合理性。 【企業管理階層不會關心太細節的東西。只需要關心投入產出的合理性】
客戶:關心產品的範圍,關心專案的可交付成果是否足夠完成產品或服務
專案管理人員:專注於可交付成果是否足夠且必須完成,時間、資金和資源是否足夠,主要的潛在風險和預備解決的方法。
專案團隊成員:關心專案範圍中自己參與的元素和負責的元素
核實產品:針對產品是否完成,在專案(或階段)結束時由發起人或客戶來驗證,強調產品是否完整; 確認範圍:針對專案可交付成果,由客戶或發起人在階段末確認驗收的過程。
確認範圍與專案收尾的不同:
①雖然確認範圍與專案收尾工作都在階段未進行,但確認範圍強調的是核實與接受可交付成果,而專案收尾強調的是結束專案(或階段)所要做的流程性工作。
②確認範圍與專案收尾都有驗收工作,確認範圍強調驗收專案可交付成果,專案收尾強調驗收產品。
確認範圍與品質控制的不同:
①確認範圍主要強調可交付成果獲得客戶或發起人的接受度;品質控制強調可交付成果的正確性,並符合為其製定的具體品質要求(品質標準)。
②品質控制一般在確認範圍前進行,也可同時進行;確認範圍一般在階段末尾進行,而品質控制並不一定在階段未進行。
③品質控制屬內部檢查,由執行組織的相應品質部門實施;確認範圍則是由外部幹係人(客戶或發起人)對專案可交付成果進行檢查驗收。
控制範圍
輸入:1專案管理計畫 2需求文件 3需求追蹤矩陣 4工作績效資料 5組織流程資產
工具與技術:偏差分析
輸出:1工作績效資訊 2變更要求 3專案管理計畫更新 4專案文件更新 5組織流程資產更新
監督專案和產品的範圍狀態、管理範圍基準變更的過程,其主要作用是在整個專案期間保持對範圍基準的維護。對專案範圍進行控制,就必須確保所有要求的變更、建議的糾正措施或預防措施都經過實施整體變更控制過程的處理。在變更實際發生時,也要採用範圍控制流程來管理這些變更。
①影響導致範圍變更的因素,並儘量使這些因素向有利的方面發展。
②判斷範圍變更是否已經發生。
③範圍變更發生時管理實際的變更,確保所有被要求的變更依照專案整體變更控制流程處理
補充
1)在層次上保持項目的完整性,避免遺漏必要的組成部分。
2)—個工作單元只能從屬於某個上層單元,避免交叉從屬。
3)相同層次的工作單元應用相同性質。
4)工作單元應能分開不同的責任者和不同的工作內容。
5)便於專案管理計畫和專案控制的需要。
6)最底層工作應該具有可比性,是可管理的,可定量檢查的。
7)應包括專案管理工作,包括分包出去的工作。