心智圖資源庫 專案範圍管理
PMP第5章專案範圍管理,專案範圍管理包括確保專案做且只做所需的全部工作,以成功完成專案的各個流程。確認範圍是正式驗收已完成的專案可交付成果的過程。
編輯於2022-02-24 18:41:57This 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.
專案範圍管理
定義
專案範圍管理包括確保專案做且只做所需的全部工作,以成功完成專案的各個流程。確認範圍是正式驗收已完成的專案可交付成果的過程。
主要在於定義和控制哪些工作應該包括在專案內,哪些不應該包括在專案內。
產品範圍
完成情況是根據產品需求來衡量的
某項產品、服務或成果所具有的特徵和功能。
專案範圍
為交付具有規定特性與功能的產品、服務或成果而必須完成的工作。專案範圍有時也包括產品範圍。
專案範圍的完成情況是根據專案管理計劃來衡量的
預測型生命週期範圍說明
中在專案開始時就對專案可交付成果進行定義,對任何範圍變更都要漸進式管理
確認範圍在每個可交付成果產生時或在階段審查點開展,而控制範圍則是一個持續性的過程。
經過核准的專案範圍說明書、工作分解結構WBS和對應的WBS字典構成專案範圍基準。只有透過正式變更控管程序,才能進行基準變更
適應型項目範圍說明
整體範圍分解為一系列擬實現的需求和擬執行的工作(有時稱為產品未完項),在每次迭代中,都會重複進行三個過程:收集需求、定義範圍和創建 WBS
每次迭代中,都會重複進行兩個過程:確認範圍和控制範圍。
使用未完項(包括產品需求和使用者故事)反映當前需求
補充說明:「需求」是指根據特定協議或其他強制性規範,產品、服務或成果必須具備的條件或、能力。 需求將成為工作分解結構(WBS)的基礎,也將成為成本、進度、品質和採購規劃的基礎。
需求管理過程結束於需求關閉,即把產品、服務或成果移交給接收方,以便長期測量、監控、實現和維持效益。
剪裁需要考慮的因素
知識和需求管理。
確認和控制。
開發方法。
需求的穩定性。
治理。
計劃
5.1規劃範圍管理
定義
要作用是,在整個專案期間對如何管理範圍提供指南和方向。
為記錄如何定義、確認及控制專案範圍及產品範圍,而建立範圍管理計畫的流程
範圍管理計畫是專案或專案集管理計畫的組成部分,描述將如何定義、制定、監督、控制和確認專案範圍
輸入
專案章程
專案管理計劃
品質管理計劃
在專案中實施組織的品質政策、方法和標準的方式會影響管理專案和產品範圍的方式
項生命週期描述
義了專案從開始到完成所經歷的一系列階段
開發方法
定義了專案是採用瀑布式、迭代型、適應型、敏捷型還是混合型開發方法
事業環境因素
組織文化;基礎建設;人事管理制度;市場條件。
組織過程資產
工具與技術
專家判斷
數據分析
於評估收集需求、詳述項目和產品範圍、創造產品、確認範圍和控制範圍的各種方法。
會議
與會者可能包括專案經理、專案發起人、選定的專案團隊成員、選定的相關方、範圍管理各流程的負責人,以及其他必要人員
輸出
範圍管理計劃
定義:範圍管理計畫是專案管理計畫的組成部分,描述將如何定義、制定、監督、控制和確認專案範圍
制定專案範圍說明書;
根據詳細專案範圍說明書建立WBS
確定如何審批和維護範圍基準;
正式驗收已完成的專案可交付成果。
*需求管理計劃
定義:專案管理計畫的組成部分,描述將如何分析、記錄和管理專案和產品需求。有些組織稱之為“商業分析計劃”
如何規劃、追蹤和報告各種需求活動
配置管理活動,例如,如何啟動變更,如何分析其影響以及變更審批權限
需求優先排序過程;
測量指標及使用這些指標的理由;
反映哪些需求屬性將被列入追蹤矩陣的追蹤結構。
5.2收集需求
定義:為實現專案目標而確定、記錄並管理相關方的需要和需求的過程。作用是,為定義產品範圍和專案範圍奠定基礎,且僅進行一次或僅在專案的預先定義點進行。
輸入
專案章程
專案管理計劃
範圍管理計劃。
需求管理計劃。
相關方參與計劃。
專案文件
商業計劃
會影響收集需求過程的商業文件是商業論證,它描述了為滿足業務需求而應該達到的必要、期望及可選標準
協定
事業環境因素
組織過程資產
*工具與技術
專家判斷
商業分析;需求取得;需求分析;需求文件;以往類似專案的專案需求;圖解技術;引導衝突管理。
*數據收集
腦力激盪
訪談
訪談是透過與相關方直接交談,來獲取資訊的正式或非正式的方法。
訪談的典型做法是向受訪者提出預設和即興的問題,並記錄他們的答案。
經常是「一對一」談話,但也可以包括多個訪談者和/或多個被訪者
訪談有經驗的專案參與者、發起人和其他主管,以及主題專家,有助於識別和定義所需產品可交付成果的特徵和功能。訪談也可用於取得機密資訊。
焦點小組
焦點小組是召集預定的相關方和主題專家,了解他們對所討論的產品、服務或成果的期望和態度
由一位受過訓練的主持人引導大家進行互動式討論。
問卷調查
非常適合以下情況:受眾多樣化,需要快速完成調查,受訪者地理位置分散,適合進行統計分析
標竿對照見
標竿對照所採用的可比較組織可以是內部的,也可以是外部的
數據分析
*決策
投票
集體決策
獨裁型決策制定
多標準決策分析
該技術借助決策矩陣,以系統分析方法建立諸如風險水平、不確定性和價值收益等多種標準,以對眾多創意進行評估和排序。
*數據表現
親和圖
用來對大量創意分組的技術,以便進一步檢視和分析
心智圖
*人際關係與團隊技能
名義小組技術
透過投票排列最有用的創意,以便進一步進行腦力激盪或優先排序。
向集體提出一個問題或難題。每個人在沉思後寫出自己的想法。
主持人在活動掛圖上記錄大家的想法
集體討論各個想法,直到全體成員達成明確的共識。
個人私下投票決出各種想法的優先排序,通常採用5分制,1分最低,5分最高
觀察和交談
觀察和交談是指直接察看個人在各自的環境中如何執行工作(或任務)和實施流程
當產品使用者難以或不願清楚說明他們的需求時,就特別需要透過觀察來了解他們的工作細節。
觀察,也稱為“工作跟隨”,通常由旁站觀察者觀察業務專家如何執行工作,但也可以由“參與觀察者”來觀察,通過實際執行一個流程或程序,來體驗該流程或程序是如何實施的,以便挖掘隱藏的需求。
引導
引導與主題研討會結合使用,把主要相關方召集在一起定義產品需求。
用於快速定義跨職能需求並協調相關方的需求差異。
因為具有團體互動的特點,有效引導的研討會有助於參與者之間建立信任、改善關係、改善溝通,從而有利於相關方達成一致意見
引導情景
聯合應用設計或開發(JAD),以收集需求和改進軟體開發流程。
品質功能展開(QFD),製造業則採用QFD這種引導技能來幫助確定新產品的關鍵特徵。客戶需求又稱“客戶聲音”,客觀地對這些需要進行分類和排序,並為實現這些需要而設定目標。
使用者故事。使用者故事是對所需功能的簡短文字描述,經常產生於需求研討會。使用者故事描述哪個相關方將從功能中受益(角色),他需要實現什麼(目標),以及他期望獲得什麼利(動機
*系統互動法
系統交互圖是範圍模型的一個例子,它是對產品範圍的可視化描繪,顯示業務系統(過程、設備、電腦系統等)及其與人和其他系統(行動者)之間的交互方式
系統互動圖顯示了業務系統的輸入、輸入提供者、業務系統的輸出和輸出接收者。
*原型法
定義:在實際製造預期產品之前,先造出該產品的模型,並據此徵求對需求的早期饋。
括微縮產品、電腦產生的二維和三維模型、實體模型或模擬
原型是有形的實物,它使得相關方可以體驗最終產品的模型,而不是僅限於討論抽象的需求描述。
原型法支持漸進明細的理念,需要經歷從模型創建、使用者體驗、回饋收集到原型修改的反覆循環過程。
經過足夠的回饋循環之後,就可以透過原型獲得足夠的需求訊息,從而進入設計或製造階段。
故事板
是一種原型技術,透過一系列的影像或圖示來展示順序或導航路徑。
故事板用於各種行業的各種專案中,如電影、廣告、教學設計,以及敏捷和其他軟體開發專案。
在軟體開發中,故事板使用實體模型來展示網頁、螢幕或其他使用者介面的導航路徑。
輸出
*需求文件
定義:描述各種單一需求將如何滿足與專案相關的業務需求
始可能只有高層級的需求,然後隨著有關需求資訊的增加而逐步精進。
只有明確的(可測量和可測試的)、可追蹤的、完整的、相互協調的,且主要相關方願意認可的需求,才能作為基準。
需求文件的格式多種多樣,既可以是一份按相關方和優先級分類列出全部需求的簡單文件,也可以是一份包括內容提要、細節描述和附件等的詳細文件
需求分為不同的種類,如業務解決方案和技術解決方案。前者是相關方的需要,後者是指如何實現這些需要。
需求的類別
業務需求:整個組織的高層需要
相關方需求
解決方案需求
功能需求。
功能需求描述產品應具備的功能,例如,產品應該執行的行動、流程、資料和交互
非功能需求。
非功能需求是功能需求的補充,是產品正常運作所需的環境條件或品質要求,例如可靠性、保密性、性能、安全性、服務水準、可支援性、保留或清除等
過渡和就緒需求
這些需求描述了從「當前狀態」過渡到「將來狀態」所需的臨時能力,如資料轉換和培訓需求。
專案需求
專案需要滿足的行動、過程或其他條件,例如里程碑日期、合約責任、限制等
品質需求
用於確認專案可交付成果的成功完成或其他專案需求的實現的任何條件或標準,例如測試、認證、確認等
*需求矩陣追蹤法
產品需求從其來源連結到能滿足需求的可交成果的一種表格。
需求追蹤矩陣是把產品需求從其來源連結到能滿足需求的可交付成果的一種表格。使需求追蹤矩陣,把每個需求與業務目標或專案目標連結起來,有助於確保每個需求都具有商業價值。
需求追蹤矩陣提供了在整個專案生命週期中追蹤需求的一種方法,有助於確保需求文件中被批准的每項需求在專案結束的時候都能交付。
最後,需求追蹤矩陣也為管理產品範圍變更提供了框架。
類別
業務需求、機會、目的和目標;專案目標;專案範圍和WBS可交付成果;產品設計;產品開發;測試策略和測試場景;高階需求到詳細需求
應在需求追蹤矩陣中記錄每個需求的相關屬性,這些屬性有助於明確每個需求的關鍵資訊。
需求追蹤矩陣中記錄的典型屬性包括唯一識別、需求的文字描述、收錄該需求的理由、所有者、來源、優先順序、版本、當前狀態(如進行中、已取消、已推遲、新增加、已批准、被指派和已完成)和狀態日期
為確保相關方滿意,可能需要增加一些補充屬性,如穩定性、複雜性和驗收標準。其中列有相關的需求屬性。
5.3定義範圍
定義:制定項目和產品詳細描述的過程。
定義範圍過程就要從需求文件(收集需求過程的輸出)中選取最終的專案需求,然後制定出關於專案及其產品、服務或成果的詳細描述。準備好詳細的專案範圍說明書,對專案成功至關重要
應根據專案啟動過程中記載的主要可交付成果、假設條件和限制因素來編制詳細的項範圍說明書
隨著對專案資訊的更多了解,應該更詳細具體地定義和描述專案範圍。
需要分析現有風險、假設條件和限制因素的完整性,並做必要的增補或更新。
隨著目前迭代期的專案範圍和可交付成果的進展,而詳細規劃下一個迭代期的工作。
輸入
專案章程
專案章程中包含專案的高層描述、產品特徵和批准要求
專案管理計劃
專案管理計劃元件包括(但不限於)範圍管理計劃,其中記錄如何定義、確認和控制專案範圍。
專案文件
假設日誌。需求文件。風險登記冊。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據分析
決策
人際關係與團隊技能
*產品分析
產品分析可用於定義產品和服務,包括針對產品或服務提問並回答,以描述要交付的品的用途、特徵及其他方面。
每個應用領域都有一種或幾種普遍公認的方法,用以把高層的產品或服務描述轉變為有意義的可交付成果。首先取得高層級的需求,然後將其細化到最終產品設計所需的詳細程度
產品分析技術:
產品分解;需求分析;系統分析;系統工程;價值分析;價值工程。
輸出
*專案範圍說明書
專案範圍說明書是專案範圍、主要可交付成果、假設條件和限制因素的描述
它記錄了整個範圍,包括專案和產品範圍;詳細描述了專案的可交付成果
也代表專案相關方之間就專案範圍所達成的共識。為便於管理相關方的期望,專案範圍說明書可明確指出哪些工作不屬於本專案範圍。
專案範圍說明書使專案團隊能進行更詳細的規劃,在執行過程中指導專案團隊的工作並為評價變更請求或額外工作是否超過專案邊界提供基準。
專案範圍說明書描述要做和不要做的工作的詳細程度,決定專案管理團隊控制整個專案範圍的有效程度
內容
產品範圍描述。可交付成果。驗收標準。項目的除外責任。
雖然專案章程和專案範圍說明書的內容存在一定程度的重疊,但它們的詳細程度完全不同專案章程包含高層的信息,而專案範圍說明書則是對範圍組成部分的詳細描述,這些組成部分需要在專案過程中漸進明細
專案文件更新
5.4創建WBS
將專案可交付成果和專案工作分解為較小的、更易於管理的組件的過程。工作包
WBS是專案團隊為實現專案目標、創建所需可交付成果而需要實施的全部工作範圍的層級分解。
WBS組織並定義了專案的總範圍,代表著經批准的目前專案範圍說明書中所規定的工作。
最低層的組成部分稱為工作包,其中包括計劃的工作。工作包將相關活動歸類,以便對工作安排進度、進行估算、進行監督與控制
在「工作分解結構」這個字詞中,「工作」是指作為活動結果的工作產品或可交付成果而非活動本身
分解程度取決於所需的控製程度,已實現對專案的高校管理,工作包的詳細程度因專案規模和複雜程度而異
輸入
專案管理計劃
專案文件
專案範圍說明書。需求文件。
事業環境因素
專案所在產業的WBS標準,這些標準可以作為創建WBS的外部參考資料
組織過程資產
工具與技術
專家判斷
分解
分解是一種把專案範圍和專案可交付成果逐步劃分為更小、更便於管理的組成部分的技術
識別和分析可交付成果及相關工作;確定WBS的結構和編排方法;自上而下逐層細化分解;為WBS組成部分制定和分配標識編碼;核實可交付成果分解的程度是否恰當
建立 WBS 的方法
上而下分解方法、自下而上驗證使用組織特定的指南和使用 WBS模板
以專案生命週期的各階段作為分解的第二層,把產品和專案可交付成果放在第三層,
以主要可交付成果作為分解的第二層,
納入由專案團隊以外的組織所開發的各種較低層次組件(如外包工作)。隨後,作為外包工作的一部分,賣方須制定相應的合約WBS
輸出
範圍基準
專案範圍說明書、工作包、WBS、規劃包
WBS字典
是針對WBS中的每個元件,詳細描述可交付成果、活動和進度資訊的文件。 WBS 字典對 WBS 提供支持,其中大部分資訊由其他過程創建,然後在後期添加到字典中。
專案文件更新
控制
確認範圍
正式驗收已完成的專案可交付成果的過程。本過程應根據需要在整個專案期間定期開展
輸入
專案管理計劃
範圍管理計劃。需求管理計劃。範圍基準。
專案文件
經驗教訓登記冊。品質報告。需求文件。需求追蹤矩陣。
核實的可交付成果
是指已經完成,並被控製品質過程檢查為正確的可交付成果。
工作績效數據
可能包括符合需求的程度、不一致的數量、不一致的嚴重性或在某一時間段內進行確認的次數
工具與技術
檢查
來判斷工作和可交付成果是否符合需求和產品驗收標準;檢查有時也被稱為審查、產品審查和巡檢等
決策
輸出
*驗收的可交付成果
符合驗收標準的可交付成果應由客戶或發起人正式簽署批准。
工作績效訊息
更新請求
專案文件更新
控制範圍
監督專案和產品的範圍狀態,管理範圍基準變更的過程
要作用是,在整個專案期間保持對範圍基準的維護,且需要在整個專案期間進行。
輸入
專案管理計劃
範圍管理計劃。需求管理計劃。變更管理計劃。配置管理計劃。範圍基準。績效測量基準。
專案文件
工作績效數據
組織過程資產
工具與技術
數據分析
偏差分析。趨勢分析。
確定偏離範圍基準的原因和程度,並決定是否需要採取糾正或預防措施,是專案範圍控制的重要工作
輸出
工作績效訊息
變更請求
專案管理計畫更新
專案文件更新
如果已經驗收完畢,出現bug,需要改進,如果客戶增加需求,不接受改進,放到下一個階段
厲害的PM用專家判斷,小白用分解
輸入需求檔是為了校對