Ch07 — 06-第6章

🏠 主入口 🎯 答題速查 📖 全部章節 字幕索引 重點矩陣 📘 大綱與標準

Ch07 — 06 第6章 (43 min)

講師: Richard | 對應 PDF: [[06-第6章.pdf]] 影片: C:\Users\User\Desktop\PGMP Video\2026-05-08 23-36-51.mp4 回到 [[MOC-PgMP-精講筆記]]

章節綜述

本章是 PgMP 五大績效域的「串講」整合篇，銜接前一章「收益交付」結尾，依序串起： 1. 收益管理：移交 + 維持的責任分配（5 過程 + 4 關鍵文件） 2. 收益生命週期映射：商業論證 → 章程 → 路線圖 → 收益登記冊 → 收益實現計劃 3. 相關方爭取（Stakeholder Engagement）：5 過程 + 2 關鍵文件 4. 專案級治理（Program Governance）：12 最佳實踐 + 治理角色 5. 專案級生命週期：定義（構建 + 規劃）/ 交付 / 收尾，三階段對應的關鍵活動

核心串講邏輯：收益是主線，治理是另一條主線，相關方是人這條線，三線最後都歸集到生命週期框架下對應。

📑 思維導圖海報 (PDF 講義)

章節思維導圖

§1 收益移交：協調統一到接收方既有體系 (01:16:38)

v2 01:16:38

核心: 專案級產生的收益要 consolidate（統一）到接收方原有的流程/體系中，並完成 ongoing responsibility 的移交。

PMI 術語: - Consolidate Coordinated Benefits ↔ 整合協調收益 ↔ 統一在一起 - Transfer Ongoing Responsibility ↔ 移交持續責任 ↔ 責任移交 v2 01:16:38

講師原話: 「接收過來的意思就是我原來已經有的體系，要將專案級產生的收益融合進來，所以叫 consolidate coordinated benefit。」

§2 收益維持：責任主體 vs. 專案級的延續支援 (01:18:14)

v2 01:18:14

核心: 收益維持的責任主體是接收方，但專案級不能撒手不管，仍需 monitor + 必要時提供技術/人員支援。

PMI 術語: - Sustainment ↔ 維持/延續 ↔ 持續維持 - Monitor Performance of the Benefit ↔ 收益績效監控 ↔ 關注收益狀態

講師原話: 「專案級也不能夠一撒手就完全都不去管他了——要繼續關注他的狀態。」

§3 維持計劃 vs. 移交計劃：誰制定？給誰用？ (01:21:43)

v2 01:21:43

核心: 兩份計劃都由專案級制定，但角色不同——移交計劃管「怎麼移交」，維持計劃管「接收方怎麼維持」。

PMI 術語: - Program Transition Plan ↔ 專案級移交計劃 ↔ 移交計劃 - Program Benefits Sustainment Plan ↔ 專案級收益維持計劃 ↔ 維持計劃

講師原話: 「維持計劃實際上是由專案級這一方制定，交給接收方按照這個維持計劃去做的。」

§4 收益管理 5 過程 + 4 關鍵文件總覽 (01:23:54)

v2 01:23:54

核心: 收益管理有 5 過程 和 4 關鍵文件，是整章最高頻的考點之一。

5 過程（Benefits Management Processes）： 1. 收益識別 Benefits Identification 2. 收益分析與規劃 Benefits Analysis & Planning 3. 收益交付 Benefits Delivery 4. 收益移交 Benefits Transition 5. 收益維持 Benefits Sustainment

4 關鍵文件： | 文件 | 作用 | | ---- | ---- | | 收益登記冊（Benefits Register） | 記錄收益的狀態與進展 | | 收益實現計劃（Benefits Realization Plan / Benefits Management Plan） | 基準文件，判斷收益實現進展是否合理 | | 收益移交計劃（Benefits Transition Plan） | 指引整體移交安排 | | 收益維持計劃（Benefits Sustainment Plan） | 指引接收方持續維持 |

PMI 術語: - Benefits Register ↔ 收益登記冊 ↔ 客觀記錄 - Benefits Realization Plan ↔ 收益實現計劃 ↔ 基準文件（用來評估） v2 01:23:54

講師原話: 「收益實現計劃是作為基準檔案存在，用來判斷和評估收益的實現的進展和狀態是否合理。」

§5 責任轉移時點：左 = 專案級，右 = 接收方 (01:25:51)

核心: 從「移交」開始責任主體切換——移交前 = 專案級主導，移交後 = 接收方主導，但專案級給予足夠支撐。

講師原話: 「雖然這時候主力責任已經不是專案級了，但是你要關注，一旦有問題，我們還可以依然給接收方給最大的幫助。」

§6 收益識別：商業論證 + 章程是首要輸入 (01:31:21)

v2 01:31:21

核心: 收益識別最重要，兩個輸入文件——商業論證和專案級章程，必須與組織戰略保持一致。

PMI 術語: - Business Case ↔ 商業論證 ↔ 商業論證 - Program Charter ↔ 專案級章程 ↔ 章程 - Benefits Register ↔ 收益登記冊 ↔ 收益登記冊

講師原話: 「兩個檔案在整個考試的佔比是非常高，也就是它們的重要地位有戰略意義，也有收益實現的現實意義。」

§7 收益生命週期映射：早期 vs. 構建期的 develop / update (01:36:26)

v2 01:36:26

核心: 專案級在「構建子階段」之前可能已有 portfolio 階段的初步工作，這時要區分 develop（制定）vs. update（更新）。

PMI 術語: - Develop ↔ 制定 ↔ 從零開始 - Update ↔ 更新 ↔ 早期已有則更新 - Program Roadmap ↔ 專案級路線圖 ↔ 路線圖

講師原話: 「它不像專案經理——給你的資訊幾乎都是確定的。相比於專案級經理而言，那麼到了構建階段，資訊就大家會更加清晰。」

§8 收益描述方式：有形 + 無形，靠專案承載 (01:46:36)

核心: 專案級的收益描述「通常不用可交付成果」，而是用有形或無形的收益方式，這些收益靠下層的專案來承載。

PMI 術語: - Tangible / Intangible Benefits ↔ 有形/無形收益 ↔ 有形或無形收益 - Component ↔ 元件（即下層專案/子專案級）↔ 元件

§9 收益實現由元件完成；元件完成 → 移交 → 維持 (01:51:09)

v2 01:51:09

核心: 收益的實現透過元件（Component，即專案）完成；每個元件完成 → 收益移交 → 同步制定維持計劃給接收方。

PMI 術語: - Benefits Map / Benefits Dependency Map ↔ 收益依賴關係圖 ↔ 依賴關係圖

§10 相關方爭取：5 過程 + 與專案層面的差異 (02:14:30)

v2 02:14:30

核心: 專案級相關方爭取與專案的差異只在「層面」——複雜度高、戰略性強，所以相關方級別明顯高於專案層面。

5 過程 / 階段： 1. 專案級相關方識別 Identification 2. 相關方分析 Analysis（分析對專案級的影響/重要性） 3. 制定爭取策略 Engagement Planning 4. 執行爭取 Engagement（按計劃執行） 5. 監督爭取 Monitor

重要規則： - 專案層面的「重要相關方」可以納入專案級登記冊 - 一個是客觀記錄（登記冊），一個是分析後的判斷 - 為每個重要相關方制定爭取策略（Engagement Strategy） - 爭取手段最基本就是溝通：面對面 / 遠端 / 電子郵件 / 電話 / 視訊會議 / 書面報告

PMI 術語: - Stakeholder Engagement ↔ 相關方爭取 ↔ engagement - Stakeholder Register ↔ 相關方登記冊 ↔ 登記冊 - Stakeholder Engagement Plan ↔ 相關方爭取計劃 ↔ 爭取計劃 v2 02:14:30

講師原話: 「engagement 叫爭取——就是這樣重要的相關方，我用什麼樣的方法來爭取它。」

§11 考試陷阱：相關方無回應時，先查爭取計劃 (02:46:42)

核心: 如果某相關方對你提交的資訊「幾乎從來都不回應」，正確選擇是去查爭取計劃，不是直接換溝通方式。

PMI 術語: - Stakeholder Register（客觀記錄）vs. Engagement Plan（要遵循的安排）

講師原話: 「你正常的選擇就是要查閱你的相關方爭取計劃，看看那裡邊是要你怎麼做。」

§12 治理（Governance）入門：建規則 + 定角色 (03:05:46)

v2 03:05:46

核心: 治理 = 建立組織規則 + 定義角色職責，覆蓋變更/風險/問題/質量/採購/彙報關係。

PMI 術語: - Program Governance ↔ 專案級治理 ↔ 治理 - Best Practices ↔ 最佳實踐 ↔ 實踐

§13 治理 12 最佳實踐：實踐 1-3 (03:09:25)

v2 03:09:25

核心: 前三個最佳實踐建立治理的「基礎設施文件」。

實踐 1: 治理計劃（Governance Plan） - 文件化（Documented）的安排 - 囊括後面所有內容——誰批准、什麼情況誰決策都記在這 - 這是最重要的單一實踐

實踐 2: 制定專案級的願景與使命（Vision & Mission） - 高層面決策時用，能團結更多人 - 專案級的願景 + 目標必須定義出來

實踐 3: 專案級批准與背書（Endorsements） - 描述哪些情景下需要批准 / 背書

PMI 術語: - Program Governance Plan ↔ 專案級治理計劃 ↔ 治理計劃 - Program Vision & Mission ↔ 專案級願景與使命 ↔ 願景使命 - Endorsements ↔ 背書 ↔ 背書

§14 治理 12 最佳實踐：實踐 4-7 (03:23:49)

核心: 實踐 4-7 涵蓋成功標準、監控彙報、風險問題治理規則、質量治理。

實踐 4: 成功標準（Success Criteria）早期制定 - 由委員會或發起人定義 - 早期定清楚，將來使用更有價值

實踐 5: 監督、彙報、控制（Monitor, Report, Control） - 誰向誰彙報、傳遞什麼資訊、由誰決策 - 可約定報告上去後幾天內必須給決策意見

實踐 6: 風險與問題治理規則 - 什麼層面的風險/問題到哪個層面解決 - 規定到治理文件中

實踐 7: 質量治理（Quality Governance） - 質量通常是強制要求 - 兩種治理選擇： - 放權給專案層面制定質量政策 - 專案級制定統一規則 + 專案執行 - 體現質量在專案級層面也非常重要

講師原話: 「把質量列為治理層面，由就能看出來——質量對於專案級管理也依然非常重要。」

§15 治理 12 最佳實踐：實踐 8-12 (03:35:36)

核心: 實踐 8-12 涵蓋變更治理、階段關口、健康檢查、元件啟動批准、收尾批准。

實踐 8: 變更治理（Change Governance） - 專案層面有規則範圍內自己執行

實踐 9: 階段關口評審（Phase Gate Reviews） - 由指導委員會 / 評審委員會給出決策意見 - 依據成功標準、出口標準（Exit Criteria） - 出口標準滿足才能進下一階段

實踐 10: 健康檢查（Health Checks） - 在關口之間進行的細緻檢查 - 嚴格程度比關口評審次要

實踐 11: 元件啟動 / 移交批准 - 每個元件啟動都必須經過批准 - 邏輯：每個元件都應該支援專案級的某個收益；未批准就啟動會破壞戰略一致性 + 收益實現 - 元件的啟動、移交都要批准

實踐 12: 專案級收尾批准 - 專案級能否進收尾要更高管理主體確認 - 判斷專案級前期收益是否達成 - 同意後才能正式收尾

PMI 術語: - Phase Gate Review ↔ 階段關口評審 ↔ 關口評審 - Health Check ↔ 健康檢查 ↔ 健康檢查 - Exit Criteria ↔ 出口標準 ↔ 出口標準

講師原話: 「每一個元件都應該支援專案級的某一個收益。如果沒有經過批准的元件啟動了，很可能在戰略一致性跟收益實現下，就會出現問題。」

§16 治理角色：發起人 vs. 指導委員會 (04:05:48)

v2 04:05:48

核心: PgMP 認證中，指導委員會做決策的情景遠多於單一發起人——專案級複雜度高、相關方多。

角色 主要職責
專案級發起人 Sponsor 提供資源（資金）；對專案級成敗負最終責任
專案級指導委員會 Steering Committee 多發起人 / 多參與方時集體決策；組織高層執行層；給整個專案級執行提供指導

考試提示: - 「絕大部分情況都是專案級指導委員會給出決策意見」 - 出現專案級指導委員會選項時「正確率比較高」 - 單一發起人決策的情景在認證中非常少

PMI 術語: - Program Sponsor ↔ 專案級發起人 ↔ 發起人 - Program Steering Committee ↔ 專案級指導委員會 ↔ 指導委員會

講師原話: 「如果出現專案級指導委員會在選項當中，通常它的正確率是比較高的。」

§17 治理角色：PMO / 專案級經理 / 專案經理 (04:15:35)

核心: PMO 主標準化 + 協助；專案級經理對專案經理實施治理（治理另一個個體）。

PMO（專案級管理辦公室）： - 標準化專案級流程 - 協助指導委員會、專案級經理做資源分配 - 方法論開發

專案級經理 ↔ 專案經理： - 專案級經理對專案經理實施治理 - 專案經理在許可權範圍內完成專案層面管理 - 上面還有更高層：組合經理 / 運營經理，他們對專案級層面實施治理

§18 生命週期管理：三大階段總覽 (04:35:23)

v2 04:35:23

核心: 串講要把戰略 / 收益 / 治理 / 相關方都歸集到生命週期框架——三階段：定義 / 交付 / 收尾。

PMI 術語: - Program Definition Phase ↔ 專案級定義階段 ↔ 定義 - Program Delivery Phase ↔ 專案級交付階段 ↔ 交付 - Program Closure Phase ↔ 專案級收尾階段 ↔ 收尾 - Formulation Sub-phase ↔ 構建子階段 ↔ 構建 - Planning Sub-phase ↔ 規劃子階段 ↔ 規劃

§19 定義階段兩大要點：批准啟動 + 定義收益 (04:55:02)

核心: 定義階段最關鍵兩件事——批准專案級啟動 + 定義專案級的預期成果與收益。

第一句話「批准專案級啟動」串聯： - 涉及專案級章程批准 - 章程批准前提 = 商業論證存在 - 章程批准 = 組織提供資源 + 提供資金 - 發起人負責找資金，或組織負責找

第二句話「定義收益」串聯： - 對應收益識別過程 - 從商業論證/章程收集收益資訊 - 早期已確定的成果可以是某專案要產生的可交付成果 - 也可以把收益跟成果等同起來 - 如果是收益→記錄到收益登記冊

章程被批准的標誌性事件： - 商業論證的制定或更新（develop or update） - 專案級章程被批准 - 路線圖批准 - 專案級管理計劃批准（在規劃子階段結束時完成）

講師原話: 「資金的批准和專案級經理的任命，這兩個都是專案級章程被批准的一個前提條件。」

§20 交付階段：元件啟動 → 收益交付的對應關係 (05:30:05)

v2 05:30:05

核心: 交付階段兩件大事——元件的啟動規劃執行移交關閉 ↔ 收益的交付移交維持，一一對應。

核心邏輯： - 收益識別 → 分析 → 規劃 → 形成依賴關係 → 形成元件架構 - 元件啟動需要設定原則（治理規則） - 必要時重新規劃和整合——首先要從收益開始重新思考，而不是從元件層面

元件管理計劃 vs. 專案級管理計劃： - 元件制定自己的管理計劃 - 專案級層面整合所有元件的管理計劃 - 大部分情況下：元件管理計劃要與專案級管理計劃保持一致 - 專案經理要協調差異

變更升級邏輯： - 元件變更在專案經理授權內 → 自己處理 - 超過授權 → 升級到專案級層面 - 必要時可能關閉元件、換方式做

PMI 術語: - Adaptive Change ↔ 適應性變更 ↔ 適應性變更 - 標準特別強調：元件啟動/關閉/移交不是元件決定，是專案級經理決定

講師原話: 「適應性變更——他的意思就是隨著戰略的變化、隨著專案級目標的調整，來將對元件做出調整和改變。」

§21 收尾階段：移交 + 關閉，兩大關鍵動作 (06:01:13)

v2 06:01:13

核心: 收尾階段由兩個動作構成——移交（Transition）+ 關閉（Closure），順序固定且各有前提。

動作 1: 移交效益到接收組織： - 將收益移交給接收組織 - 同時把維持計劃也制定好交給對方 - 因為「沒有人比專案級或專案級裡更瞭解他產生的收益該怎麼維持才能最好」

動作 2: 關閉專案級： - 所有元件先關閉（必要前提） - 專案級向指導委員會申請關閉 - 申請被批准後才能正式啟動關閉動作

關閉前提（兩種情況）： - 專案級期望的效益實現了（移交後或專案結束時實現） - 所有元件必須移交 + 必須關閉 - 接收組織能正常接收 - 或：環境變化決定終止

標誌性事件： - 定義結束 = 專案級管理計劃被指導委員會批准（不是發起人，與專案管理常識有差異） - 交付結束 = 效益實現 + 接受 + 進收尾申請被批准

講師原話: 「沒有人比專案級或者專案級裡更瞭解，他產生的收益該怎麼維持才能最好。」

§22 構建子階段：發起人任命 + 範圍/資源/成本/風險初估 (06:34:16)

v2 06:34:16

核心: 構建子階段（Formulation）最重要的工作——明確發起人、初始估算「範圍 + 資源 + 成本」+ 風險評估。

起始條件: 組合批准（Portfolio Review）

主要活動： 1. 明確專案級發起人（執行發起人） - 由組織指派高階管理者擔任 - 主要職責：處理資金 + 找接班人（委派專案級經理） 2. 委派專案級經理 3. 範圍 / 資源 / 成本初始估算 - 加上風險評估，這四個是專案級早期最重要的因素 - 進度是基於這四個判斷後才能排出 4. 初始風險評估 → 對應戰略一致性中的「制定管理策略」 5. 三大基準文件： - 商業論證（Business Case） - 專案級章程（Program Charter） - 專案級路線圖（Program Roadmap） - 三者順序：商業論證在前 → 章程中間 → 路線圖在後 - develop = 早期沒做過；update = 早期已有

標誌性事件: 章程被批准 → 進入規劃子階段

講師原話: 「這四個尤其是範圍資源成本——要熟練到只要提不到因素就能準確把握到。」

§23 規劃子階段：專案級基礎設施 + 管理計劃 (07:13:38)

v2 07:13:38

核心: 規劃子階段建立「專案級基礎設施」+ 完成專案級管理計劃。

重要時點記憶： - 專案級經理 → 在構建子階段任命（要早） - 專案級團隊 + 治理結構 + PMO + 資訊管理系統 → 在規劃子階段建立

專案級基礎設施（Program Infrastructure）三件套： 1. 專案級的核心團隊（Core Team） 2. 專案級的資訊管理系統（PMIS） 3. 專案級的 PMO

治理結構： - 定義專案級指導委員會 / 專案級經理 / 專案經理三者職責 - 各自負責什麼層面的問題

最重要產出: 專案級管理計劃（Program Management Plan）必須制定出來

PMI 術語: - Program Infrastructure ↔ 專案級基礎設施 ↔ 基礎設施 - Program Core Team ↔ 專案級核心團隊 ↔ 核心團隊 - Program Management Information System (PMIS) ↔ 專案級資訊管理系統 - Program Management Plan ↔ 專案級管理計劃 ↔ 管理計劃

講師原話: 「專案級經理是在構建子階段任命，這個大家容易被忽略——記住，牢牢記住。」

章末重點考前清單