Ch04 — 03 第3章 (183 min)

講師: Richard | 對應 PDF: [[03-第3章]] 影片: C:\Users\User\Desktop\PGMP Video\2026-05-08 08-22-31.mp4 回到 [[MOC-PgMP-精講筆記]]

產製方式: 章節切 2 段交給 2 個 agent 平行逐段精煉, 共 165 個 §N (Part A: §1-116, Part B: §117-165).

Part A 綜述

承上啟下：上一段講「收益識別」的整體框架，這一段（PDF 第 3 章前段）一路鋪完整個 Benefit Management 流程的 5 個過程（Identification → Analysis & Planning → Delivery → Transition → Sustainment），緊接 Stakeholder Engagement 績效域的 5 個過程（Identification → Analysis → Planning → Engagement → Communications），最後在收尾切到 Governance 的開場。重點在於辨析「這個東西記錄在哪、由誰來做、用什麼動詞」——這是 PgMP 考試最會偷換的細節。

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

§1 收益識別承接：識別完了就要規劃實現 (05:01:13)

核心: 收益既然已被識別並認同，下一步自然是規劃如何把它做出來。

• 收益識別 → 收益分析跟規劃，是承接關係
• 收益總要有「基本要素」與「載體」來記錄

講師原話: 「如果大家認同了這個收益識別，那麼下一步不就規劃他該怎麼實現了嗎」

§2 收益的最初來源：商業論證 + 專案級章程 (05:01:34)

核心: 收益不是憑空產生的，最初來源是兩份檔案——商業論證（business case）與專案級章程（program charter）。

• 商業論證描述「收益的有效性」與宏觀層面的收益
• 戰略目標也可能在專案級層面被細化為收益
• 識別完成後，將結果記錄到「收益登記冊（benefit register）」

§3 商業論證 = formal declaration of benefit (05:02:00)

核心: 商業論證是對收益的第一次正式宣告。

• 關鍵詞：formal declaration
• 它正式宣告專案級要實現「哪些」收益（宏觀層面）
• 詞語上要與 charter 區分

PMI 術語: formal declaration of benefit ↔ 收益的正式宣告 ↔ 講師：「商業論證是對收益的第一次正式宣告」

講師原話: 「正式宣告，叫 formal declaration，正式宣告這個專案級要實現哪些收益」

§4 專案級章程 = formal defining of benefit (05:03:09)

核心: 章程在資源承諾之前必須先正式定義出收益是什麼，所以對應的詞是 formal defining。

• 章程要承諾資源 → 承諾前必須先 define
• 定義要更詳細，比商業論證更具體

PMI 術語: formal defining of benefit ↔ 收益的正式定義（章程）

§5 define vs identify 的本質差異 (05:03:26)

核心: define 必須完備、清晰、值得推敲；identify 只是「識別到了」這個簡單動作。

• define：完備的、清晰的、值得推敲的（章程用）
• identify：只強調動作，未必完備（識別過程用）
• 章程必須做正式定義，登記冊只是記錄狀態/列表

PMI 術語: define ↔ 定義（要完備）；identify ↔ 識別（只標記到）

講師原話: 「define 定義這個詞用的話，它必須是完備的，清晰的，值得推敲的」

§6 收益登記冊：列表 + 對應關係 + 進展狀態 (05:04:26)

核心: benefit register 三個必記要點：① 它是列表；② 記錄收益和元件的mapping 對映；③ 記錄當前狀態跟進展。

• 列表：清單性質
• mapping：把收益對映到專案級元件
• 狀態：每個收益的當前情況、進展

PMI 術語: benefit register ↔ 收益登記冊；mapping ↔ 收益—元件對映關係

§7 mapping 在登記冊只是「更新」，真正動作在規劃過程做 (05:05:35)

核心: 識別過程的 mapping 是「同步更新進來」；真正執行收益—元件對映是在收益分析跟規劃過程完成的。

• 做筆記時要加註釋：「mapping 在識別只是 update」
• 完成後同時記錄到收益登記冊 + 收益管理計劃（收益實現計劃）兩個檔案

講師原話: 「真正做這件事是在收益的分析跟規劃這個過程完成」

§8 收益登記冊還要含的細節：KPI、風險、target dates、責任人 (05:06:52)

核心: 除三大要點外，登記冊還記錄：KPI 衡量、跟收益有關的風險、target dates and milestones、責任人（如收益管理經理）。

• KPI：怎麼衡量這個收益
• target dates and milestones：何時要完成
• 責任人：誰對收益實現負責
• 對應角色：收益管理經理、風險管理經理、品質管理經理

PMI 術語: target dates and milestones ↔ 目標日期與里程碑

§9 案例：流程變革專案的「組織效率提升」如何被測量 (05:07:55)

核心: 講師親身案例——「組織效率提升」第一版被高層否決（無法衡量），第二版給數字又被質疑「怎麼證明」，最後做基線調研＋兩年後對比才被認同。

• 收益不僅要定義「是什麼」，還要定義「如何測量」
• 否則高階管理層無法接受
• 側面說明：識別收益要讓關鍵相關方參與並認同

講師原話: 「我們在定義收益的時候，不僅要定義收益是什麼，還要定義他如何測量」

§10 強烈建議大家記住三個要點 (05:09:33)

核心: 重複加深印象——專案級收益登記冊要記住三件事。

• ① 列表跟清單
• ② 完成收益跟元件之間的對映關係
• ③ 記錄進展和狀態的檔案

講師原話: 「強烈建議大家記住三個」

§11 小問題：哪個檔案可以衡量收益實現的好壞？ (05:10:00)

核心: 收益登記冊只記狀態與進展，那麼「衡量收益實現好壞」的檔案是誰？答案不唯一，留待下一過程解。

• progress data 你都記下來了
• 但「換成好/壞」的判斷在哪？→ 收益管理計劃

§12 收益分析跟規劃過程：產出 benefit management plan (05:10:28)

核心: 這個過程比前一個更複雜但比較好懂，目的就是 establish the program benefit management plan。

• 又叫 benefit realization plan（收益實現計劃）
• 規劃「收益怎麼管理、什麼時間實現」

PMI 術語: benefit management plan ↔ 收益管理計劃 ≡ benefit realization plan ↔ 收益實現計劃

§13 計劃要建立 benefit metrics and framework (05:10:36)

核心: 除了訂出計劃，還要 develop the benefit metrics and framework——衡量標準＋管理框架。

• metrics：一系列指標體系（不是單一 KPI）
• framework：條條框框、規則性的內容，不是細節

PMI 術語: framework ↔ 框架（≠ 細節，是規則性結構）

§14 計劃用來 verify benefits realized as planned (05:11:52)

核心: 答案揭曉——use to verify that the benefits are being realized as planned，benefit management plan 就是衡量收益實現是否符合預期的依據。

• 前面 §11 的問題答案：收益管理計劃
• 它是「衡量你這個收益實現的進展進度是不是符合預期」

PMI 術語: verify that the benefits are being realized as planned ↔ 驗證收益按計劃實現

§15 路線圖也可衡量，但只是高階粗略 (05:12:18)

核心: roadmap 也能衡量收益實現，但詳細程度遠不如收益管理計劃。

• 路線圖：更粗略、更高階
• 收益管理計劃：更具體、how / when 都明確
• 二選一找衡量標準時：優先選 benefit management plan

§16 計劃兩大關鍵詞：「好（how）」和「問（when）」 (05:13:40)

核心: 計劃要寫明白：① 好處如何實現（realize benefit）；② 何時實現。

• realize benefit + when the benefit
• 甚至要寫：何時移交、如何移交、何時維持、如何維持

講師原話: 「一個叫好，一個叫問，好是如何實現收益」

§17 落點都在 benefit realize 上 (05:14:26)

核心: how + when 兩條主線最終都落在 benefit realize（收益實現）這個動作上。

• 記住一一對詞：how + when → realize
• 第二大要素：link components output to program outcomes

§18 link components output to program outcomes (05:14:44)

核心: 計劃要把「專案元件的可交付成果」與「專案預期收益」連線起來。

• program outcomes ≈ 收益
• component output ≈ 可交付成果
• 形成複雜的對應關係 = 「收益依賴地圖」

PMI 術語: benefit dependency map ↔ 收益依賴地圖（收益與元件對映關係）

§19 metrics vs KPI：登記冊有 KPI，計劃形成體系 (05:15:14)

核心: 登記冊裡是一個個的 KPI；收益實現計劃要把整個指標形成a set of metrics / KPIs——一個完整體系。

• KPI = 單一指標
• metrics = 指標體系
• 計劃強調 internal logic（內在聯絡）

PMI 術語: KPI ↔ 單一關鍵績效指標；metrics ↔ 指標體系（系統性）

§20 第三要素：how + when，移交給誰 (05:15:42)

核心: How and when 在計劃裡又一次出現，這次強調「如何移交、移交給誰、何時移交」。

• 移交給：運營方 / 接收方（recipient）
• 「How and when 都跟收益有關的，是 benefit management plan」

§21 收益管理 vs 路線圖：Architecture vs Structure of Components (05:16:23)

核心: 收益管理績效域 = 整個專案級的架構（收益與元件對應關係）= Architecture；路線圖 = 元件結構 = Structure of Program Components。

• 收益管理 → Architecture（總體結構）
• 路線圖 → Structure of Components（元件結構）
• 路線圖核心是元件，不是收益

PMI 術語: Architecture ↔ 架構（收益管理）；Structure of Components ↔ 元件結構（路線圖）

§22 路線圖最核心：元件結構，收益只是次要內容 (05:17:24)

核心: 路線圖裡會有收益內容，但收益不是路線圖的最核心，元件才是。

• 路線圖在第一章學過：元件1、元件2、元件3、元件4
• 元件新增/減少/結束 → 隨時更新到路線圖（路線圖是當時狀態）

§23 規劃完成後同步更新登記冊：mapping 在這完成 (05:18:40)

核心: 規劃過程帶來登記冊更新——Program Benefits are mapped to Program Components 真正在這完成，再回更到登記冊裡。

• mapping 動作真實發生在規劃過程
• 結果同步到收益登記冊

§24 Define and Approve KPIs：規劃後 KPI 要再更新 (05:19:18)

核心: 分析後資訊更多，識別階段定義的 KPI 可能需要 update 甚至改變，要返回登記冊更新。

• Define and Approve KPIs
• 改變後 → 重新返回收益登記冊 update

PMI 術語: Define and Approve KPIs ↔ 定義並批准 KPI

§25 與恰當的相關方協商定義 KPI (05:19:38)

核心: 指標由誰定義？要跟「恰當的相關方」一起協商——通常是更高層管理層比團隊成員更恰當。

• 回扣 §9 案例：高階管理層才知道什麼算「足夠的證明」
• 團隊成員只在某些情況下恰當

§26 收益交付過程：把計劃落實 (05:20:11)

核心: benefit delivery = 實現/產生這個收益，不是「交出去」（交出去是 transition）。

• delivery 目的：確保專案能交付預期收益
• 按照上一過程完成的收益管理計劃落實執行

PMI 術語: benefit delivery ↔ 收益交付（產生收益）；benefit transition ↔ 收益移交（交出去）

§27 過程蠻簡單：歸要工作前面已完成 (05:20:45)

核心: 交付過程最簡單，只是「去做真正的工作 / 持續執行」，因為規劃工作前面都做完了。

• 在這只是去持直線（按計劃執行）

§28 誰來交付收益？專案完成 vs 專案級經理協調 (05:21:03)

核心: 答「人」→ 是專案經理；答「結構單元」→ 是專案（不是專案級）完成收益的交付；專案級經理只是協調。

• 收益由「專案」實現，不是專案級
• 專案級經理 = 協調多個專案經理，整合結果讓收益最大化

講師原話: 「他是協調多個專案和多個專案經理來讓收益能夠最大化」

§29 交付過程要不斷測量收益實現 (05:21:46)

核心: 持續測量收益實現情況，並回報給對應相關方。

• 三個典型對象：PMO、發起人、專案級指導委員會
• 基於 metrics（定義在收益實現計劃 + 登記冊裡）

§30 二選一優先選 benefit management plan，但登記冊也有 (05:22:29)

核心: 選最權威的衡量檔案——優先收益管理計劃；但登記冊裡的 KPI（被 update 過）也可以用。

• 因為計劃將指標形成體系
• 二選一情境陷阱：很多事情並不是唯一的，多個地方可能都有

§31 交付過程帶來變更：元件可能新增/變更/終止 (05:23:23)

核心: 交付過程中收益可能無法實現（terminated）、或產生新收益要新元件——必然帶來變更。

• 收益的交付跟收益的規劃跟分析是交叉進行/迴圈的
• correct action（糾正措施）：條件環境改變

PMI 術語: terminated ↔ 終止；corrective action ↔ 糾正措施

§32 元件變更/終止都依據收益決定 (05:24:55)

核心: 無論元件增加、變更、終止，都要依據收益來完成——專案級經理關注收益，看哪個方案讓收益損失最小或最大。

• 戰略目標改變 → 專案級調整
• 當前專案無法支撐收益 → 新建元件

§33 元件變化要立即同步路線圖 + 進度計劃 (05:25:09)

核心: initiation and closure of components 一發生，第一時間更新路線圖（成為里程碑）+ 後期的專案級進度計劃。

• 元件啟動/結束 = 路線圖的標誌性事件 = Milestone

PMI 術語: initiation and closure of components ↔ 元件啟動與關閉；Milestone ↔ 里程碑

§34 治理與收益的關係：治理保證戰略一致 (05:26:02)

核心: 治理 = 確保收益在組織授權範圍內、由適當決策者完成的場合 + 規則。

• review 收益實現情況 → 保證專案級持續與組織戰略一致

§35 收益的推導鏈：收益→目標→目的→願景→戰略 (05:26:43)

核心: 收益向上是目標，目標向上是目的，目的向上是願景，願景對應戰略。驗證收益實現 = 驗證戰略實現。

• 治理是「手段」，保證收益實現

講師原話: 「收益向上是目標，目標向上是目的，目的向上是願景，願景對的是我們的戰略」

§36 移交與維持：兩個收尾過程 (05:27:07)

核心: 專案級是臨時性行為，收益必須移交給接收方持續維持，否則意義打折扣。

• 移交是維持的前提條件
• 類比：交付產品但無人售後

§37 移交目的：transitioned and sustained (05:27:52)

核心: purpose is to ensure that program benefits are transitioned and can be sustained。

• 先 transitioned（交出去）
• 再 sustained（維持下來）
• 兩個關鍵動作：① 制定移交計劃（含培訓/相關方參與）；② 驗證收益已按預期實現

PMI 術語: transitioned ↔ 移交；sustained ↔ 持續維持

§38 verifying that integration transition and closure...meet (05:28:55)

核心: 移交前必須驗證——integration、transition、closure 達到或超過 benefit realization criteria。

PMI 術語: benefit realization criteria ↔ 收益實現衡量標準

§39 benefit realization criteria 在哪？考點題 (05:29:04)

核心: 標準不唯一，可在：① 收益登記冊；② 收益管理計劃（=收益實現計劃）。二選一優先選收益管理計劃。

• 考試陷阱：要看選項給哪幾個
• 同時提到時優先計劃；只有一個時就選那個

§40 接收方要參與規劃：Stakeholders are identified and participated in the planning (05:30:08)

核心: 移交規劃時要邀請接收方提前介入——識別出哪些人需要介入、讓他們參與設計。

講師原話: 「Stakeholders are identified and participated in the planning，這個很關鍵的」

§41 multiple transition events：元件移交可進行多次 (05:30:33)

核心: There may be multiple transition events as individual program components close——元件結束就可以做一次 component transition；專案級全部結束時再做一次整體移交。

• 例如元件四完成 → 元件四的移交
• 整體移交 + 元件移交 = 不衝突

PMI 術語: components transition ↔ 元件移交（可多次）

§42 收益維持責任屬接收方 (05:31:59)

核心: 移交完，接收方負責持續維持收益。

• 接收方可以是內部或外部
• 移交前要識別接收方並讓其參與設計/規劃

§43 維持目的：ongoing maintenance by receiving organizations (05:32:43)

核心: ongoing maintenance activities performed by receiving organizations to ensure a continual generation of the improvements and outcomes delivered by the program。

• 持續產生改進與結果
• 確保收益最大化

§44 維持規劃由「專案級經理 + 專案經理」共同設計 (05:33:40)

核心: 專案級經理 + 專案經理共同設計「未來如何維持收益」的方案，由接收方執行。

• 規劃方：專案級經理 + 專案經理
• 執行方：接收組織（內部 or 外部）

§45 接收方常見 = 運營部門 + 維護部門（運維） (05:34:22)

核心: 兩個典型接收方部門：運營 + 維護，常合稱運維部門。

• 他們持續實現專案/專案級的結果
• 維持過程可能需要技術支援、遠端支援

§46 對收益要求高的情境，要保留專人做後期支援 (05:35:26)

核心: 一般情況下專案資源要釋放；但對維持要求高的情境，專案經理要安排「特定人員」做後期支援。

• 大部分團隊解散，但保留少數人做支援

§47 支援不在專案 LC 內，但在專案級收益 LC 內 (05:36:16)

核心: 「支援接收方的維持活動」不在專案的生命週期內，但在專案級經理的職責發揮之內——說明專案級經理站在客戶角度將收益最大化。

• 體現「客戶側維持」的視角

講師原話: 「站在客戶角度將收益最大這個收益實現方實際上的維持方式在客戶那一側是有可能」

§48 Stakeholder Engagement 績效域開場 (05:37:10)

核心: 接著進入「專案級的相關方爭取」績效域。和 PMP 的相關方管理差別不大，但在更高層面做爭取，考察難度大。

• 內容聽起來容易，考察時很難（理解不深會錯）

§49 相關方爭取五個過程 (05:38:19)

核心: 識別 → 分析 → 爭取規劃 → 爭取（執行） → 溝通。

• ① 相關方識別
• ② 相關方分析
• ③ 相關方爭取規劃
• ④ 相關方爭取
• ⑤ 相關方溝通

§50 把溝通和爭取合在一起的獨特考慮 (05:38:58)

核心: 專案級把 communication 和 engagement 放在一起談，反映 PMI 對兩者關係的認識——溝通是爭取的具體手段之一。

• engagement 也翻譯成「參與」
• 跟 PMBOK 可能不一致，但有其獨特考慮

§51 相關方定義：individual / group / organization (05:40:12)

核心: The stakeholder is an individual, group or organization——三個層面，不只指個體。

• 個體（individual）
• 群組（group）
• 組織（organization）

PMI 術語: stakeholder ↔ 相關方（個體/群組/組織三層面）

§52 相關方含義：影響/被影響/perceive 三層 (05:40:54)

核心: ① 為專案級結果提供貢獻；② 被專案級結果影響；③ perceive itself to be affected（自認為受影響）——這第三層最有啟發。

• 自認為受影響的群體 → 也要當相關方對待
• 這是 PgMP 標準的重要觀點

PMI 術語: perceive itself to be affected ↔ 自認為受影響

講師原話: 「如果這些群體個人或者是組織自認為他被受到了影響，那這個時候呢，我們也應該把這些人當成我們的相關方」

§53 perceive itself to be affected：自認為受影響也算 (05:41:36)

核心: 完整三種情形：① 專案級成敗影響他；② 他影響專案級成敗；③ 他自認為會影響到他。

• 第三種對 PgMP 管理特別有啟發

§54 為什麼用 engage 而不是 manage？ (05:43:03)

核心: 西方/美國認為「人不能被管理」——能被管理的是期望值、不是人本身。

• manage 用在「管理期望」
• engage 用在「爭取相關方」

PMI 術語: manage expectations ↔ 管理期望；engage stakeholders ↔ 爭取相關方

§55 資源可以 manage，相關方要謹慎用 manage (05:43:43)

核心: 用 resource 一詞時可放心 manage；單獨拿出相關方/團隊成員時要謹慎使用 manage，儘量用 engage。

• resource ↔ 可 manage
• stakeholder ↔ 用 engage

§56 engage 的含義：讓相關方願意參與進來 (05:47:11)

核心: engage 在中文裡沒有單一對應詞——含義是「做一些事讓相關方願意參與到我的事情中來」。

• 手段：情感交流、信任建立、工作交往
• 翻譯成「爭取」帶有主動意味（積極爭取支援、降低抵制）

講師原話: 「透過各種各樣的手段讓對方發自內心的情願的參與到我的專案集當中來」

§57 相關方分類：internal/external × positive/negative (05:48:28)

核心: 兩個維度劃分相關方——內外（internal/external）× 態度（positive/negative）。

• 內部：組織內 / 專案級內
• 外部：組織外 / 專案級外
• 態度：支援 vs 抵制

§58 相關方爭取的工作三件事：識別 needs / 管理期望 / 溝通 (05:49:02)

核心: ① 識別、分析相關方的 needs（需要/需求）；② manage expectations；③ communications。

• needs 嚴格翻譯是「需要」，但實務上需要≈需求
• 三件事最終目的都是 foster 培養支援

PMI 術語: needs ↔ 需要/需求；manage expectations ↔ 管理期望；foster ↔ 培養/促進

§59 最終目的：減少抵制 + 培養支援 (05:49:50)

核心: foster = 培養/促進相關方對我們起正向作用。

• 不希望反對 → 降低反對程度
• 最好消除（depend on situation 程度差異）

§60 gain and maintain stakeholders' buy-in (05:52:07)

核心: the primary objective is to gain and maintain stakeholders' buy-in for the program's objective benefits and outcomes——buy-in = 認同/買賬。

• 對目標、收益、結果要認同
• 要靠專案級經理+管理團隊的努力

PMI 術語: buy-in ↔ 認同（買賬）；gain and maintain ↔ 獲得並維持

講師原話: 「翻譯成認同會比較好，他要對我們向...這點上他要認同」

§61 communicate vs negotiate：兩種溝通含義 (05:52:42)

核心: communicate 強調資訊傳遞；negotiate 也可譯溝通，更強調談判、協商一致。

• 與相關方溝通 = 資訊層面 + 達成 buy-in 層面
• 看到「溝通」時要注意原文用哪個詞

PMI 術語: communicate ↔ 資訊傳遞型溝通；negotiate ↔ 談判/協商型溝通

§62 常見專案級相關方類型 (05:54:15)

核心: 向上：發起人、指導委員會、組織決策者；橫向：核心管理團隊、專案級 PMO；向下：專案經理、專案團隊、專案層 PMO；外圍：投資組織、發起組織、執行組織。

• 專案經理對專案級經理 = 向下的重要相關方
• 專案級 PMO 不含專案經理

§63 相關方識別過程開場 (05:55:38)

核心: 第一個跟相關方有關的過程：identification。

§64 與 PMP 區別：相關方分析獨立成過程 (05:55:44)

核心: PMBOK 把相關方分析放在識別工具裡；PgMP 標準把分析完全獨立成一個過程——是重要改進。

• 識別 = 識別 + 記錄（不含分析）
• 分析 → 由下一過程 Program Stakeholder Analysis 完成

§65 識別目的：所有「關鍵」相關方 (05:56:34)

核心: 系統識別 all key stakeholders——個體、群體、組織三層面。

• key 是隱含的關鍵詞
• 因為專案級涉及面廣、相關方多 → 必須區分重要程度

§66 載體：相關方登記冊 (05:57:13)

核心: 識別後存放在 stakeholder register——姓名、基本資訊、崗位、職位、愛好。

• 還要記錄：對專案級的資訊需求

PMI 術語: stakeholder register ↔ 相關方登記冊

§67 溝通偏好/需求要寫進登記冊 (05:57:30)

核心: 標註相關方偏好——書面/口頭、會議/郵件、正式/非正式。

• 喜好：偏主觀
• 需求：偏客觀量化

§68 相關方角色與支援度也要記錄 (05:58:16)

核心: 還要記：組織內地位、專案級角色（供應商？接收方 recipient？）、支援/抵制/中立。

• recipient = 收益接收方 → 對應另一種管理策略

PMI 術語: recipient ↔ 收益接收方

§69 識別過程要客觀記錄，不做分析 (05:59:01)

核心: 識別 = 客觀記錄分析動作；分析動作不在這個時候做。

• 登記冊是非常關鍵的工具
• 用途：① 支援後續分析；② 動態狀態記錄

§70 登記冊主要用途 1：reporting 與 distributing deliverables (05:59:46)

核心: easily for use in reporting, distributing program deliverables——交付資訊時知道送給誰、用什麼方式。

• 因為前面記錄了相關方特徵 → 可方便處理

§71 GDPR：個人資訊有敏感性 (06:00:35)

核心: 2018 年歐盟 GDPR 為代表的法律要求——個人資訊有敏感性，標準裡也體現了這點。

• 政治/法律/個人隱私三種敏感性
• 中國/亞洲文化原本不太在意，但近年也開始重視

PMI 術語: sensitive information ↔ 敏感資訊

§72 對策：許可權設定，不對所有人開放 (06:01:41)

核心: 好做法：對相關方資訊做許可權設定，不對所有人開放。

• 政治、法律、個人隱私 → 主動限制

§73 Dynamic / Living Document (06:01:53)

核心: 相關方登記冊是動態文件 / 活檔案——隨時更新，顯示當前最新狀態。

• Dynamic Document ≡ Living Document
• 有變化要及時更新

PMI 術語: Dynamic Document / Living Document ↔ 動態文件 / 活檔案

§74 識別工具：頭腦風暴 (06:02:26)

核心: 專案級管理很少提工具，提到時要留意——頭腦風暴用於識別相關方。

• 大家平等、自由發表
• 不允許評價別人觀點
• 時間不能太久（會疲勞）
• 重數量不重質量

PMI 術語: brainstorming ↔ 頭腦風暴

§75 相關方分析過程：分類與優先排序 (06:04:12)

核心: Program Stakeholder Analysis——基於識別來的資訊深入分析。

• 最簡單做法：分類（重要/次要/一般/基本）

§76 分類工具：Power Interest Grid 仍有效 (06:04:33)

核心: 權力—利益方格在這仍有效，是相關方地圖的具體應用。

§77 分析工具 1：歷史資訊 (06:05:02)

核心: 過去組織內專案/專案級做過的工作、相關方曾經參與的記錄，對當前分析有幫助。

§78 分析工具 2：individual interview 一對一面談 (06:05:19)

核心: 對重要相關方拜訪、一對一面談——更容易獲得關鍵資訊。

PMI 術語: individual interview ↔ 一對一面談

§79 分析工具 3：focus group 焦點小組 (06:05:34)

核心: 就某一個問題深入討論，需要專業主持。

• 重大決策、早期關鍵目標、關鍵收益定義時用

PMI 術語: focus group ↔ 焦點小組

§80 分析工具 4：問卷調查 (06:06:19)

核心: 應用場景：相關方數量大、需要快速收集觀點時。

• 優勢：效率高
• 劣勢：無法獲取面對面的隱性資訊
• 要綜合多種工具

§81 開放式 vs 封閉式問題 (06:06:59)

核心: 與相關方交流儘量用開放式問題，少用 yes/no 封閉式。

• 反例：「您喜歡這個目標嗎？」→ 對話結束
• 正例：「您感覺怎麼樣？還有哪些要求？」→ 持續深入

§82 引入新工具：Stakeholder Map 相關方地圖 (06:07:58)

核心: 大型複雜專案級用視覺化方式表達相關方間的相互關係與互動。

• 可用思維導圖
• 顯示人與人、利益與利益的背後聯絡

PMI 術語: Stakeholder Map ↔ 相關方地圖

§83 替代方案：Power Interest Grid (06:09:02)

核心: An Alternative Classification Model = Power Interest Grid。縱座標權力、橫座標利益。

• 是相關方地圖的「具體應用」
• 不是所有情境的萬能解法

PMI 術語: Power Interest Grid ↔ 權力—利益方格

§84 PI 方格四象限策略：Manage Closely (06:09:16)

核心: 右上（高權高利）→ Manage Closely 重點管理。

• 它的事情都是最重要的
• 一一去看待

PMI 術語: Manage Closely ↔ 重點管理

§85 PI 方格：低權低利 → Monitor (06:09:46)

核心: 低權低利 → Monitor 監督——最小時間和精力投入。

• 提要求就滿足
• 沒要求就不花太多時間

§86 PI 方格：高權低利 → Keep Satisfied (06:10:14)

核心: 高權低利 → Keep Satisfied 令其滿意——它決定生死但本身受影響不大，要保持滿意。

• 它的「一舉一動」可能對我們是災難性的
• 但它自身受到的影響不大

PMI 術語: Keep Satisfied ↔ 令其滿意

§87 PI 方格：低權高利 → Keep Informed（典型 = 團隊成員） (06:10:53)

核心: 低權高利的典型 = 專案級團隊成員——影響你的權力小，但成敗對他影響巨大。

• 對應策略 keep informed（保持告知）
• 考察機率較高

§88 分析後更新登記冊：分類、優先順序、深入需求 (06:11:17)

核心: 分析後資訊更新到登記冊：分類資訊、優先順序排序、更深入的需要/期望、影響力。

• 動態文件特性再次體現

§89 相關方爭取規劃：Stakeholder Engagement Planning (06:12:29)

核心: 基於前面識別與分析，制定爭取計劃。

PMI 術語: Stakeholder Engagement Planning ↔ 相關方爭取規劃

§90 計劃要 outline how all stakeholders will be engaged (06:12:40)

核心: Outlines how all program stakeholders will be engaged——勾勒輪廓，可粗可細。

• 用 all 不加 key 是有意的：提醒要關注所有相關方
• 實際行動還是要關注重要的（影響更大）

§91 critical document vs baseline document (06:13:19)

核心: 相關方爭取計劃 = critical document（不是 baseline document）。

• 考試會考細節：哪些屬 critical / 哪些屬 baseline

PMI 術語: critical document ↔ 關鍵檔案；baseline document ↔ 基準檔案

§92 計劃內容 1：detailed strategy 細節層面策略 (06:14:19)

核心: detailed strategy 的糾結點——strategy 通常是粗略的，但加上 detailed 表示要更具體、不能太寬泛。

• 不能籠統而論

§93 計劃內容 2：基於分析識別來的爭取方案 (06:14:48)

核心: 計劃要寫「如何去做才能爭取到這個相關方」——爭取方法不僅跟自身有關，還跟相關方特徵有關。

• 例：分析發現他喜歡面對面 → 計劃就用面對面
• 識別/分析 → 制定方案，邏輯閉環

§94 計劃內容 3：定義爭取衡量標準 (06:15:36)

核心: 計劃要定義 metrics——能衡量相關方被爭取的程度與我們工作做得如何。

§95 衡量指標 1：會議參加頻次 (06:16:28)

核心: 例：每月參加重要會議 2 次——若不參加要趕緊瞭解原因。

• 老闆若忙到不參加你的會 = 你的事在他眼裡不重要
• 重要的事一定會參加

§96 衡量指標 2：提案被贊同的程度 (06:17:57)

核心: 你的提案/想法被贊同的次數與深度——粗略贊同 / 仔細審查後贊同 / 沒看就反對。

• 次數可以變成衡量爭取程度的指標

§97 衡量指標 3：會議上的表現品質 (06:18:37)

核心: 不只看「參不參加」，還看「會議上的表現」——是否對決策推進起關鍵作用。

§98 相關方爭取過程（執行）：持續活動 (06:18:58)

核心: 規劃 → 執行落實。continuous program activity，對成敗至關重要。

• 有計劃沒執行 = 等於沒做
• 因為相關方態度動態變化

§99 相關方態度會 change as the program progresses (06:19:30)

核心: stakeholder's attitude and opinion changes as the program progresses and delivers benefits——他們不是一直忠誠的。

• 鐵桿相關方不常見
• 專案碰到嚴重問題且持續未改善 → 原本支援的會轉變

§100 三大技巧：溝通 + 談判 + 衝突解決 (06:20:49)

核心: 標準在「相關方爭取（執行）」過程強調三技巧——communication / negotiation / conflict resolution。

• 沒出現在識別/分析/規劃，只出現在執行階段
• 主要目的：削減/抵消相關方的反對；同時也能獲得支援

PMI 術語: communication / negotiation / conflict resolution ↔ 溝通/談判/衝突解決

§101 用早期高層檔案統一認識 (06:21:59)

核心: 商業論證 + 章程是早期被高層批准的，可在爭議出現無法解決時用來「壓住場」。

• establish common high-level expectations for the delivery of the program's benefit
• 商業論證 = formal declaration of benefit
• 章程 = formal defining of benefit
• 最好少用，但價值在爭議無解時體現

§102 問題日誌 issue log：附帶小檔案 (06:23:42)

核心: 在跟相關方爭取過程中，日常問題的記錄載體 = 問題日誌。

• 找人跟蹤、給出解決方案、給出時間點
• 幫助專案級團隊理解相關方反饋
• have the entire program team understand the feedback received from the stakeholders

PMI 術語: issue log ↔ 問題日誌

§103 問題日誌三要素 (06:24:31)

核心: ① 問題是什麼；② 解決人/責任人是誰；③ 什麼時候能解決。

• 促進與相關方之間的溝通

§104 相關方溝通過程：把溝通獨立成過程 (06:24:46)

核心: 溝通基礎且重要 → 單獨成為一個過程 Program Stakeholder Communications——把它當成整個專案級的資訊傳遞。

• 是 vehicle for information sharing, negotiation and collaboration
• 工具就是相關方登記冊

PMI 術語: Program Stakeholder Communications ↔ 專案級相關方溝通

§105 Communication is at the heart of stakeholder engagement (06:25:47)

核心: 溝通在相關方爭取中處於核心/基礎位置——必須做到。

• 用對方喜歡的方式做（電子郵件 / 面對面 / 電話）

講師原話: 「Communication is at the heart of the program stakeholder engagement」

§106 溝通帶來登記冊更新：每個相關方策略要量身定製 (06:26:37)

核心: 溝通過程帶來登記冊更新——每個相關方的溝通策略要更細化。

• 強調 each 而不是「一群人共用」

§107 a strategy can be crafted/graphed for each stakeholder (06:26:54)

核心: crafted / graphed for each stakeholder = 量身定製、精確打造。

• 每個人的資訊只要努力就可做到
• 溝通＝必須做到

PMI 術語: crafted for each stakeholder ↔ 為每位相關方量身定製策略

§108 治理績效域開場 (06:27:53)

核心: 接下來進入治理。治理 vs 管理常分不清，但難度適中——把定位區別出來就行。

§109 治理就是「分層管理」中上一級對你行使的權力 (06:29:15)

核心: 講師心法——管理是分層的，上一級對你行使的管理權對你而言就叫治理。

• 你在上級要求下做的 = 管理行為
• 你對下級制定要求/原則 = 治理行為

講師原話: 「你的上一級，對你行使的那種管理權，對你而言就叫治理」

§110 治理三部分內容預告 (06:30:06)

核心: 治理績效域三部分：① 12 個治理實踐；② 治理角色（誰治理誰）；③ 我們在過程中要做哪些事來設計治理結構。

• 規則要先定好，否則執行起來再定會浪費時間 + 難達成一致

§111 專案級治理含義：Enables and performs (06:31:49)

核心: Enables and performs——既要使能/促進，也要執行。要規定誰有權做什麼、提供什麼材料才能批准。

• 例：商業論證由相關團隊制定 = 角色分工 = 治理行為
• 誰決定這件事 = 誰有治理權

§112 oversight = 頂層透視（一切盡在掌握） (06:34:46)

核心: support the program and maintains program oversight——所有都要能被看到（monitor and control 的高層版本）。

• 上級透視下級
• 看到 ≠ 每件事插手（規則決定）
• 站在更高層向下看 → 透視概念

PMI 術語: oversight ↔ 頂層透視 / 監督監視

§113 治理保證收益交付：Systems and Methods (06:37:09)

核心: 治理透過建立 systems and methods（體系 + 方法論）來保證專案級交付收益。

• 由更高權力、更瞭解戰略的人在關鍵節點做判斷與決策

§114 專案級治理兩個層面：被治理 + 行使治理 (06:38:15)

核心: ① 專案級被更高層（發起人/指導委員會/組織層/組合層）治理；② 專案級向下對組件/專案/子專案級行使治理。

• 標準強調上下兩層同時發揮作用
• 被治理 vs 行使治理是相對的

§115 治理關鍵詞：monitor / endorsement / approval / review (06:39:46)

核心: 看到下列詞通常都和治理有關——

• monitor 監督
• endorsement 簽署/背書
• approval 批准
• review 評審

背後共通點 = 強制權：不遵守就沒人簽字、批准、評審。

PMI 術語: monitor / endorsement / approval / review ↔ 治理四關鍵動詞

§116 governance vs management 強度差異（part A 收尾） (06:40:11)

核心: governance 語氣強烈、必須遵守、定下規則後不能協商；management 在已有條件下運轉，可有協商餘地。

• 治理 = 必遵守
• 管理 = 可運轉、可協商
• 誰向誰彙報、誰要求誰彙報 → 也是治理

講師原話: 「治理通常在制定治理規則之後不能協商，它有這個含義」

Part B 綜述

本段聚焦兩大主題：專案級治理 (Program Governance) 與 生命週期管理 (Life Cycle Management)。

治理部分以「專案組合 → 專案級 → 專案」三層治理金字塔切入，再以專案級治理為中心展開：先講為何需要治理（環境複雜度與不確定性 VUCA），再以 OCID（Oversight/Control/Integration/Decision Making）四職能描述 A 流（從上到下）與 B/C 流（從下到上）兩個方向。然後逐一展開12 個治理實踐：治理計劃 → 願景使命 → 批准/簽署/定義 → 成功標準 → 監控彙報控制 → 問題與風險 → 質量 → 變更 → 階段關口評審 (Phase Gate Review) → 健康檢查 (Health Check) → 元件啟動移交 → 專案級收尾批准。其中跨元件的問題、所有元件啟動/移交/關閉、收尾的入口與出口，都必須升級到專案級指導委員會。最後說明四大治理角色（Sponsor/Steering Committee/PMO/Component Manager）與治理設計時的五大考量（戰略一致、收益實現、相關方、工具與流程、組織約束）。

生命週期部分強調這是第五個績效域，把前面四個績效域 (戰略一致性/收益管理/相關方爭取/治理) 的活動按時間維度串起來，再加上它獨有的活動。整體生命週期分三個階段：定義 (Definition) → 交付 (Delivery) → 收尾 (Closure)。定義階段又分構建 (Formulation) 與規劃 (Planning) 兩個子階段；交付階段又分元件授權與規劃 → 元件監督與整合 → 元件移交與關閉三個子階段，恰好對應專案五大過程組。階段之間有大量重疊與迴圈，元件可以「先提前移交、先提前關閉」，收益也可在交付過程中漸進交付（Delivered Benefit）。最後深入解讀專案級章程（合理性、願景、假設與制約、時間線、收益、範圍、效益策略、風險與問題、資源、元件、相關方、治理推薦）與專案級管理計劃（baseline document，三個 baseline 之一）。

§117 治理金字塔三層級 (06:41:08)

核心: 治理由上而下分三層：專案組合治理 → 專案級治理 → 專案治理。

• 專案組合治理在最上層，往下是專案級治理，再往下是專案治理
• 三層之間是包容與被治理的關係
• 本章以專案級治理為中心展開
• 專案級向上彙報給專案組合，向下治理專案
• 概念上很容易理解，重點在角色與流向

講師原話: 「其次是專案組合治理，再向下叫專案級治理，再向下叫專案治理，很容易理解。」

§118 專案級對誰彙報：發起人 vs 指導委員會 (06:41:32)

核心: 專案級向上彙報的對象，預設是「專案組合經理」當發起人；若太複雜，發起人會擴展成「專案級指導委員會」。

• 專案級發起人 (Program Sponsor) 預設就是專案組合經理
• 若一人無法做決策，就改用群體 → 專案級指導委員會 (Program Steering Committee)
• 指導委員會通常由專案組合管理團隊的人組成，組合經理為負責人
• 發起人/指導委員會對專案級做出指導，不直接管理

PMI 術語: Program Sponsor ↔ 專案級發起人；Program Steering Committee ↔ 專案級指導委員會 ↔ 講師簡稱「指導委會」

講師原話: 「專案級發起人，通常或者預設的是專案組合的經理。」

§119 OCID 四職能與 A/B/C 兩個方向 (06:42:38)

核心: 治理從上向下叫 A 流（制定政策），從下向上叫 B/C 流（彙報與請示）；A 流執行四個職能 OCID。

• O = Oversight 監督
• C = Control 控制
• I = Integration 整合（下面被上面整合）
• D = Decision Making 決策（上面做決策）
• A 流：從上到下，制定政策、規定實踐
• B/C 流：從下到上，含義相同，只是層面不同
• 這就是專案級治理的整體結構

PMI 術語: OCID = Oversight / Control / Integration / Decision Making

講師原話: 「O Oversight、C Control、I Integration、D Decision Making，它實行這些幾個職能，從上到下做監督，從上到下做控制，從上到下被整合，還有一個上面做決策。」

§120 為何要做治理：應對環境複雜度與不確定性 (06:43:37)

核心: 治理的根本動機是環境越來越複雜、越來越不確定，黑天鵝事件已從極小機率變得普遍，反應慢就會導致組織失敗。

• 環境 (Environment) 複雜度與不確定性與日俱增
• 黑天鵝事件已不再是極小機率
• 變化頻繁 → 你的決策權、批准權、評審權要與之相適
• 否則環境快變、組織反應慢 → 整個組織包括專案級失敗
• 所以需要更有效的專案級治理 = 權力的分配

講師原話: 「黑天鵝事件已經變得比較普遍了，這說明變化的情況越來越頻繁，你未預期的事情是越多的。」

§121 治理權力下放：制定總原則、減少干預 (06:44:50)

核心: 由「全面詳細的層級分工」改成「制定總原則 + 下放執行」，超過臨界值再升級。

• 原來大家詳細決策流程很長 → 反應慢
• 制定專案級治理原則時要考慮環境變化
• 專案級經理不要過多干預專案層面，只制定總原則
• 專案經理在原則之下自己處理
• 超過臨界值 (Threshold) → 升級到專案級層面
• 專案級也處理不了 → 再升級到更高層面

PMI 術語: Threshold ↔ 臨界值 ↔ 講師用詞「臨界值」

§122 為何不能直接套用組織治理 (06:45:55)

核心: 組織治理涵蓋面太廣（運營、戰略、專案級全包），關注點與專案級不完全相同，所以專案級要在組織治理原則下另立。

• 組織層面治理涵蓋專案級 + 運營管理 + 戰略管理
• 完全用組織治理在專案級層面不恰當
• 專案級層面遵循組織治理原則之下加以制定
• 目的：保證專案級對環境變化和不均衡能快速做出反應

§123 12 個治理實踐總覽 (06:46:31)

核心: 最著名的「專案級治理 12 個實踐」是核心考點，每個都要掌握。

• 第 1 個 = 治理計劃 = 把其餘 11 個實踐在本專案中的具體要求寫進去，形成具體文件
• 12 個實踐很常見，只是過去沒以「治理」角度理解過
• 後面會逐一解讀每一個

PMI 術語: Program Governance Plan ↔ 專案級治理計劃

講師原話: 「這就是最著名的專案級治理的 12 個實踐，每一個實踐都要求大家掌握。」

§124 實踐 1：專案級治理計劃 (06:46:50)

核心: 治理計劃比管理計劃層面更高，幾乎只明確決策層級升級機制、什麼時間點與情形需要審批。

• 治理跟管理沒剝離開時，大家對治理概念其實不明晰
• 治理計劃 = 決策層級 + 升級機制 + 審批時點
• 文字載體的優勢：關鍵相關方與專案級團隊都能看到

§125 實踐 2：願景使命目標 (06:47:48)

核心: 專案級體量巨大、影響也巨大，要團結更多人就必須在治理過程中明確願景、使命、最終目標。

• 大家若沒有歸屬感，往往是因為對未來的描述不到位
• 治理計劃當中、治理過程當中要明確專案級的願景、使命、目標
• 願景使命 = 一致性的想法跟行為

§126 實踐 3：批准/簽署/定義（Approval / Endorsement / Definition）(06:48:32)

核心: 在什麼情況下、什麼條件下、誰來參加、什麼樣的過程，可以被「批准/簽署/定義」。

• Approval = 批准
• Endorsement = 簽署，常翻成「背書」
• Definition = 定義（誰有權定義一件事，他就行使治理權）
• 「這個工作怎麼做、我來出規則跟制度」 = 治理；執行規則 = 管理
• 建立規則的就是 Definition 的角色

PMI 術語: Approval / Endorsement / Definition ↔ 批准 / 簽署（背書）/ 定義

講師原話: 「誰有權利去定義一件事，那麼這個人，他其實就是行使的治理權。」

§127 實踐 4：專案級成功標準 (06:49:07)

核心: 在什麼條件下才算合格、成功，標準明確下來，這就是治理的判定權。

• establish the minimum acceptable criteria = 定義最低水平
• 高於標準當然好，但這是底線
• 必須與關鍵相關方一起討論確定，不是專案級經理一個人定
• 不僅結果要達到，過程也要符合公司原則（手段不對也不算成功）
• 還要明確怎麼測量 (method by which those criteria will be measured)
• 測量結果要 communicated and endorsed

PMI 術語: Minimum Acceptable Criteria ↔ 最低可接受標準

講師原話: 「成功標準其實定義的最低水平，這個最低水平得需要相關方一起來討論確定。」

§128 實踐 5：監督、彙報、控制 (06:49:32)

核心: Standardized Reporting and Controlling Process，組織越正式、彙報控制越標準化，專案級經理就越省事。

• 月底向哪些相關方提交報告，有時是強制的
• 越正式的組織，彙報控制要求越正式
• 標準化的好處：專案級經理不用自己花時間做一套，遵循組織要求即可

PMI 術語: Program Monitoring, Reporting and Controlling ↔ 專案級監督彙報控制

§129 實踐 6：問題與風險升級 (06:50:06)

核心: Escalation 把事情放到合適的層面：所有事情都升級 → 效率慢；標準設太高 → 嚴重影響前沒人知道。

• 治理計劃要明確 Threshold (臨界值)：什麼樣的問題到什麼層面處理
• 考點 1：元件層面解決不了 → 升級到專案級層面
• 考點 2：跨元件的問題（即便專案經理之間能談妥）→ 通常專案級經理必須介入；絕對一點不允許專案間自己解決，因為專案級經理對整個專案級目的目標負責

PMI 術語: Escalation ↔ 升級；Threshold ↔ 臨界值（風險臨界值；問題類比概念）

講師原話: 「跨元件的問題，一定要升級上來，大家考察的時候、在參加考試的時候要留意這一點。」

§130 實踐 7：質量治理 — 專案級給原則、元件做執行 (06:50:40)

核心: 專案級層面的質量自己定義 + 對元件只給指導原則；元件層面定 minimum quality criteria 並執行 QA/QC。

• Any required QA and QC activity should be defined at program level 指的是專案級自身的質量
• The components level should define minimum quality criteria and standards 元件自己負責規劃/保證/控制
• Quality management planning is often performed at the component level and governed at that level = 元件層面完成質量規劃與治理
• 專案級經理對元件不要過多干預，只給原則
• 體現了專案級管理是 principle based 的根本特性

PMI 術語: Principle Based ↔ 基於原則

§131 實踐 8：變更治理 (06:50:59)

核心: 變更和風險/問題類似 — 在專案級經理授權範圍內自己處理，超過權限升級到專案級指導委員會。

• 早期就要與指導委員會明確：The types of change program manager authorize to approve
• If significant enough → escalate 到指導委員會
• CCB vs Steering Committee 關係（重要釐清）：
• 變更控制委員會 (CCB) = 指導委員會的一個職能/下屬小組
• 指導委員會 = 對專案級所有問題的決策機構
• CCB = 只針對變更的決策機構

講師原話: 「專案級的變更控制委員會，可以理解成是專案級指導委員會的一個職能或者一個下屬的小組。」

§132 實踐 9：階段關口評審 (Phase Gate Review / Governance Review) (06:51:26)

核心: 在生命週期關口（構建/規劃/交付/收尾之間）做評審，舊版叫 Phase Gate Review，新版改稱 Governance Review。

• 在每個階段結束、進入下一階段之前都要評審
• 由專案級指導委員會做出判斷，他同意才能繼續
• 治理計劃要描述：哪些事情專案級經理可以自己處理 → 體現 Autonomy 自主權
• 自主權大小 ≠ 越大越好，與組織風格、專案級經理本人、專案級重要程度有關
• 自主權太小 → 反應速度與決策速度受影響

PMI 術語: Phase Gate Review (舊) = Governance Review (新)；Autonomy ↔ 自主權

§133 實踐 10：定期健康檢查 (Program Periodical Health Check) (06:52:04)

核心: 在關鍵節點之間進行的日常檢查，比 Phase Gate 語氣弱、稽核重要性低，但仍是好實踐。

• Assess Ongoing Performance，不在關口
• 何時、何頻次做 → 由專案級自己決定
• 與 Phase Gate 區別：
• Phase Gate = 關鍵節點 + 強制 + 由指導委員會
• Health Check = 非關鍵節點 + 經驗判斷 + 自行決定

PMI 術語: Program Periodical Health Check ↔ 專案級定期健康檢查

§134 實踐 11：元件啟動與移交 (06:52:35)

核心: 元件啟動、移交、關閉都必須經過正式評審，專案級經理不能單獨決定，需要指導委員會甚至發起人批准。

• 標準上只說啟動跟移交，實際上關閉也是
• 不能草草啟動、潦草結束
• 每個元件啟動都耗費資源，影響全域性
• 專案級經理是提議者，不是決策者
• 指導委員會依據治理結構 + 資源/產能均衡來批准

講師原話: 「專案級經理自己是不能夠單獨做決定的，這個時候需要專案級指導委會參與進來，甚至專案級發起人單獨做出這個決策。」

§135 實踐 12：專案級收尾批准 (06:53:39)

核心: 專案級收尾的入口與出口都需要批准 — 沒批准不能開始收尾，收尾結束也要批准。

• The program steering committee reviews and make decisions on recommendations for the closure of the program
• 收尾是一個持續時間段
• 入口批准 + 出口批准 → 由指導委員會給出最終決定意見
• 關閉後專案級要移交到運營組織 (Operation Organization)
• 完成從 Program Governance → Operation Governance 的過渡
• 通常在這時要出最終報告（總體情況、每個元件、採購、財務、風險）
• 採購必須處理完畢；風險可以轉移到運營繼續處理

PMI 術語: Program Closure ↔ 專案級收尾；Operation Governance ↔ 運營治理

§136 治理角色 1：Program Sponsor 發起人 (07:16:37)

核心: Program Sponsor 個體或群體都可以；為專案級成功負最終責任 (Accountable for Enabling Success)。

• 不僅是 enabling，而且要為 Program Success 負最終責任
• 若是群體 → 涵蓋於指導委員會
• 主導早期工作（在專案級經理產生之前）
• 核心職責 1：為專案級籌備資金 (Secure Financing for the program)，可以是組織自有 / 外部投資 / 它代表組織給
• 核心職責 2：選定專案級經理
• 一旦選定 PgM，就可以從規劃活動中抽身
• 專案級章程批准 → 專案級經理被正式任命

§137 治理角色 2：Program Steering Committee 指導委員會 (07:17:01)

核心: 通常是群體，多個關鍵相關方代表組成；對專案級所有重大問題做決策。

• 在標準上理論上可以為所有重大問題做決策
• 但其實上面還有專案組合評審委員會、戰略評審委員會
• 在授權範圍內，從 PgM 角度看它有極高權力代表組織做決策
• 通常是組織層面執行層（高階管理層）= Typically Organizational Executives

§138 治理角色 3：PMO 與 Component Manager (07:17:44)

核心: PMO 做標準化與日常管理，是支援專案級經理的管理結構；Component Manager 比 Project Manager 更廣，可包含子專案級經理與運營經理。

• PMO 職責：標準化、日常管理；大型複雜專案級還處理法律、HR、風險
• 組織層面 PMO（公算 PMO）= 共享資源、方法論、技術
• Component Manager 範圍：專案經理 + 子專案級經理 + 運營經理（你專案級底下的運營負責人）
• 還有組合經理（更上層）給制造原則 + 運營經理（給專案/專案級提供資源）

PMI 術語: Component Manager 比 Project Manager 範圍更廣

§139 治理設計考量：法律/決策層級/與組合對齊 (07:19:02)

核心: 設計治理時要考慮戰略一致、收益保家護航、相關方、工具與流程，外加立法環境、決策層級、與組合對齊。

• 戰略一致 = 治理保證最終不偏離戰略方向
• 收益保家護航 = 初期定義好的收益要能達成
• 相關方爭取 = 相關方要被恰當參與，否則收益達不成
• Appropriate supportive tools and processes are defined：審批、背書最好有電子流程支撐
• 立法環境：境外/境內專案，法律可能沒涵蓋，前無古人後無來者要考慮立法是否支援
• Decision Making Hierarchy：專案級內決策層級不能與組織決策層級衝突，否則整個組織紊亂
• Alignment with portfolio and organization governance：不能違背組合治理、更不能違背組織治理
• 還要考慮：戰略重要性、PMO 參與情況、籌資結構（外部資金可能受所有者干預）

PMI 術語: Decision Making Hierarchy ↔ 決策層級金字塔

§140 生命週期管理：第五個績效域，把前四個串起來 (07:24:04)

核心: 生命週期管理把整個專案級分成三個階段，綜合了戰略一致性/收益/治理/相關方爭取的活動，加上它自己獨有的活動。

• 五大績效域中生命週期強調的是「階段間 + 階段內」的順序性
• 每條主線都有側重，這條主線按時間維度串聯
• 包含前四個績效域的部分 + 自己獨有的（如出收尾報告）

§141 兩部分：專案級活動 + 整合管理 (07:26:10)

核心: 生命週期分成「專案級活動」和「整合管理」，最終會看到 整合管理 = 核心活動 (Core Activities)，其他 = 支援活動 (Supporting Activities)。

• 第二部分名稱「整合管理」，與專案管理的整合管理有點像
• 但這裡先分開來看
• Core Activities = 專案級的整合管理
• Supporting Activities = 整合以外的方方面面

PMI 術語: Core Activities ↔ 核心活動；Supporting Activities ↔ 支援活動

§142 三大階段架構：定義/交付/收尾 (07:27:27)

核心: 第四版標準把生命週期分成 Definition / Delivery / Closure 三個階段，比之前版本更清晰簡潔。

• 之前版本「Delivery」叫「Benefit Delivery」→ 與收益管理混淆，第四版去掉 Benefit 兩字
• Program Definition 又分兩個子階段：Formulation Subphase（構建/形成） + Planning Subphase（規劃/準備）
• Planning 之前版本叫 Preparing Subphase
• 生命週期 ≠ 管理生命週期，在專案級不區分這兩個概念
• 而專案的生命週期 vs 管理生命週期是有區別的（PMP 觀念）

PMI 術語: Program Definition / Program Delivery / Program Closure；Formulation Subphase ↔ 構建/形成子階段

§143 不在專案級生命週期之內的工作 (07:30:59)

核心: 篩選專案級在專案組合管理生命週期，運營維持收益在運營範疇 — 這兩個都不在專案級生命週期內。

• 篩選 = 專案組合在做（篩選/排序/分配資源）
• 早期高層商業論證 → 通過後才有「專案級」這個說法
• 後期運營：收益移交後由運營部門/接收組織負責持續維持
• 運營工作在專案級生命週期之外

§144 專案級結束後仍有少量工作：運維支援 (07:33:30)

核心: 大部分工作不參與，但有少量運維支援需要 PgM 安排專人去支援運營方。

• 專案結束後團隊釋放，但專案級要考慮這一點
• 嚴格意義上專案級生命週期 = 定義 + 交付 + 收尾
• 「關閉」與「收尾」同義

§145 專案級生命週期完整圖解 (07:34:09)

核心: 從上到下 = 組織戰略 → 篩選專案級 → Program Definition → Delivery → Closure；定義階段內 Formulation 與 Planning 有交叉/重疊/迴圈。

• 組織戰略作為輸入進入專案級
• 戰略 → 戰略計劃 → 戰略目標
• Formulation 子階段：核實專案級到底值不值得做，最終標誌 = 章程產生
• Planning 子階段：章程頒佈觸發，專案級經理帶領團隊整體規劃
• 構建跟規劃之間是迴圈：規劃資訊更新會回去調整構建
• 規劃完畢 → 進入 Delivery 階段

§146 交付階段第一子階段：元件授權與規劃 (07:37:27)

核心: 交付階段主要是識別元件並依靠元件完成收益。第一子階段叫元件的授權與規劃。

• 對專案經理而言這就是「專案的啟動 + 規劃」
• 對專案級而言 = 專案級授權專案啟動（注意：是專案級，不是專案級經理單人）
• 元件啟動不是 PgM 單獨可決策的 → 必須指導委員會綜合考慮資源、治理結構決定
• 早期已明確的元件可在規劃中就確定；後期還可能再增加

§147 交付階段第二子階段：元件監督與整合 (07:39:11)

核心: Component Oversight and Integration — 專案級對元件做監控與整合（整合元件之間有依賴的輸出）。

• 元件之間有關聯性 → 輸出有依賴關係 → 整合形成「1+1>2」的增量收益
• 對專案級 = Oversight；對專案 = 執行
• 監控資料：第一給專案經理看；還要向上彙報，讓專案級看見

§148 交付階段第三子階段：元件移交與關閉 (07:39:45)

核心: 元件移交可交付成果 + 元件關閉，對應專案管理的「收尾」過程組。

• 站在專案 = 收尾流程第一步是移交可交付成果 = Component Transition
• 站在專案級 = Oversight 元件的移交與關閉，或叫批准它
• 三個子階段對應專案管理五大過程組（啟動/規劃對應第一子階段；執行/監控對應第二；收尾對應第三）
• 直到所有元件完成 → 專案級進入收尾階段 → 整個專案級關閉

PMI 術語: Component Transition ↔ 元件移交

§149 細節 1：階段之間有大量重疊 (Overlap) (07:40:34)

核心: Definition / Delivery / Closure 重疊很多，因為各元件分別向前推進；交付階段中已可能有元件提前進入收尾。

• 元件可以先提前移交、先提前關閉
• 這時要執行部分專案級收尾活動，但專案級本身還沒收尾 = Multiple Transition（多次移交）
• 這個知識點較深入，要多理解

PMI 術語: Overlap ↔ 重疊；Multiple Transition ↔ 多次移交

§150 細節 2：Delivered Value/Benefit 三種狀態 (07:41:49)

核心: Delivered Value 應理解為 Delivered Benefit（Value 詞更多用在組合管理）— 收益交付有三種狀態。

• 元件啟動規劃過程中，有些元件已完成使命 → 移交可交付成果
• 若不依賴其他元件 → 本身就成為一個收益 → 可移交 = Delivered Benefit
• Benefit 是 Value 下的詞集；Value 主要在 Portfolio Management
• 三種狀態：
• 過程當中產生（漸進交付，增量收益交付）
• 專案級結束時就產生
• 專案級結束後很長時間才產生（如藥品研發 — 必須臨床/上市/銷售後才有收益）

講師原話: 「明明看著專案級還在交付過程當中，而我的收益已經實現了。第一它的含義是有可能是增量的收益交付。」

§151 生命週期的獨有活動 (07:44:37)

核心: 收尾要出具最終報告 — 這是生命週期獨有的，戰略一致性/相關方/收益管理裡都沒提到。

• 學習方法：不要像 PMBOK 那樣記「四十九個過程、多少 ITTO」
• 那種方法不適合 Program Management（基於原則 / 細節不過多涉獵）
• 知識是糾纏在一起的，理解關係更重要

§152 Formulation 子階段：核實值不值得做 (07:46:55)

核心: Formulation 主要工作 = 核實專案級到底值不值得做，標誌是章程在這產生。

• 章程之前要驗證商業論證的結論是否成立
• 流程：組織任命發起人 → 發起人選定 PgM → 章程批准
• 考點：
• 「PgM 在哪個階段指定？」答 Definition 階段
• 「PgM 在哪個子階段指定？」答 Formulation 子階段
• 核心團隊（除 PgM 外的管理團隊）= Planning 子階段才組建（細節考點，頻率較高）

講師原話: 「如果問你專案級經理是在哪個子階段指定的，要打 formulation。」

§153 PgM 不屬於基礎設施，PMO 與核心團隊屬於 (07:47:31)

核心: 專案級經理不屬於專案級基礎設施 (Infrastructure)；PMO 與核心管理團隊屬於基礎設施。

• 後面會講到 Infrastructure
• 這是區分 PgM 角色獨特性的關鍵

PMI 術語: Infrastructure ↔ 基礎設施

§154 定義階段做的事與「approve for the program」邏輯 (07:48:42)

核心: 定義階段先 Authorize the Program，然後將目標漸進明細展開，定義收益，目的是尋求批准。

• 主要 = Define the Program Benefit（產出 = 收益）
• 邏輯糾纏：被批准之前其實不叫專案級，叫 Initiative（提議/動議/舉措）
• Initiative 翻譯豐富：提案/動議/舉措/想法
• 批准之後才成為正式的 Authorize the Program
• 批准後也不一定是專案級方式，可能是專案、子專案、組合方式
• 真正成為專案級才到本標準涵蓋範圍

PMI 術語: Initiative ↔ 提議/動議/舉措；Authorize the Program ↔ 正式授權專案級

§155 發起人定位：籌備資金 + 選定 PgM (07:50:44)

核心: 專案級發起人定位 = 專案發起人定位 — 主要職責 = 籌備資金 (Secure Financing for the program) + 選定 PgM。

• 「資源」可以擴大理解，但核心是資金
• 發起人不一定直接給錢，是確保資金來源
• 來源可以是組織自有、外部投資、它代表公司給
• 怎麼確保是它自己要考慮的
• 同時要選定 PgM → 後者帶領規劃

§156 章程批准是集體決策（指導委員會），不是發起人個人 (07:52:48)

核心: 專案級章程批准通常由指導委員會做出，不是發起人個人 — 因為專案級複雜度高，需要群體決策。

• 大部分情況都應該由委員會批准
• 各個利益相關方代表在章程上要確認
• 某些情況可認為發起人來批准，但考試與理解標準時都要當成集體決策

講師原話: 「我建議大家，無論在考試的過程當中，還是在理解標準的時候，都要把它當成是一個集體的決策。」

§157 章程的代表性意義 > 內容本身 (07:53:32)

核心: 章程的代表意義比內容更有價值 — 標誌專案級正式啟動 + 專案級經理正式任命。

• 內容很多，不需要背書，理解為何在這裡就好
• 關鍵兩個意義：
• 專案級的正式啟動標誌
• 專案級經理被正式任命

§158 章程內容 1：合理性 (Justification) (07:54:12)

核心: Justification — 專案級存在的價值，從商業論證繼承並細化而來，不是取代關係。

• 商業論證 vs 章程：是繼承關係，不是「商業論證有的章程就不要」
• 章程合理性比商業論證更細緻
• 至少要把宏觀內容繼承下來

§159 章程內容 2：願景（與組織願景對應） (07:55:16)

核心: 願景一定要與組織戰略、組織願景一脈相承，體現戰略一致性（願景的對應關係 + 戰略的對應關係）。

• 章程要描述：組織願景是什麼 + 專案級願景是什麼 + 兩者如何吻合
• 一致性至少要兩個元素才叫一致

§160 章程內容 3：假設、制約、時間線 → 與路線圖的關係 (07:56:26)

核心: 假設與制約 + 時間線 (Timeline)；時間線會在專案級路線圖中以圖形化方式擴充套件。

• 路線圖兩個關鍵詞：Logical (按時間順序) + Graphically (圖形化)
• 路線圖基礎資訊來自章程
• 路線圖獨立成檔案比放在章程裡更有效（便於比照進展）
• 「非此即彼」 → 你可以放外面也可放章程，傾向獨立

PMI 術語: Timeline ↔ 時間線；Roadmap ↔ 路線圖（Logical + Graphically）

§161 章程內容 4：收益 (Defining the Benefit) (07:57:53)

核心: 章程關鍵詞 Defining the Benefit — 比商業論證的收益更具體、更正式。

• 商業論證收益只是宣告「我們想設定一個專案級」
• 章程收益已進一步細化

§162 章程內容 5：範圍（粗布的，與專案範圍不同） (07:58:49)

核心: 專案級範圍以收益方式體現，是粗布、框架性的；與專案管理 WBS 詳細範圍完全不同。

• 專案級範圍通常模糊不確定，可能從始至終都這樣
• 專案範圍要分解到 WBS 工作包；專案級只分到第一/第二層
• 再往下分 → 與專案管理 WBS 衝突，影響專案經理工作

講師原話: 「專案級層面的範圍，它也要向下分解，但是強調分解到第一層第二層就足夠了。」

§163 章程內容 6：效益策略、風險與問題、資源、元件、相關方、治理 (07:59:52)

核心: 章程還包含效益策略（收益實現方法源頭）、風險與問題（治理升級輸入）、資源承諾 (Resource Commitment)、已明確的元件、相關方、推薦的治理結構。

• 效益策略：源頭在章程，會作為收益實現計劃輸入
• 風險與問題：對治理計劃 (Risk and Issues Escalation 機制) 提供輸入
• 資源：商業論證只是組織有意願投入；章程才是正式承諾 = Resource Commitment → 正式授權 PgM 動用組織資源
• 元件：早期已明確的可列出，沒有也不影響後續規劃（從收益分解 → 元件 → Architecture）
• 相關方：作為相關方識別/分析/爭取規劃的輸入；溝通規劃也用得上
• 治理：早期治理結構若明確 → 作為治理計劃輸入；標準中可推薦治理結構

PMI 術語: Resource Commitment ↔ 資源承諾；Architecture ↔ 元件結構

§164 章程定位：所有計劃的源頭 (08:02:20)

核心: 章程比治理計劃、收益實現計劃、進度管理計劃、範圍管理計劃層面更高 — 其他計劃都是把章程內容進一步細化。

• 章程 = 高層面、框架性
• 各管理計劃 = 細化執行

§165 專案級管理計劃：Baseline Document (08:03:33)

核心: 專案級管理計劃在 Planning 子階段形成；定位是 Baseline Document，整個標準只有 3 個 baseline document，這是第一個。

• 章程在 Formulation 子階段；管理計劃在 Planning 子階段
• 上游：戰略計劃 → 商業論證 → 章程 → 路線圖 → 管理計劃
• 下一個 baseline 即將出現 = 專案級收益實現計劃（也叫收益管理計劃）
• 三個 baseline 是不多的稀有檔案

PMI 術語: Baseline Document ↔ 基準檔案（全標準僅 3 個）

講師原話: 「叫這個名字的檔案是不多的，是不多的，一共是有三個。」