Ch06 — 05 第5章 (77 min)
講師: Richard | 對應 PDF: [[05-第5章.pdf]] 影片:
C:\Users\User\Desktop\PGMP Video\2026-05-08 23-36-51.mp4回到 [[MOC-PgMP-精講筆記]]
章節綜述
本章是 PgMP 備考衝刺前的「標準回顧 + ECO 任務銜接」章節,分兩大模組:
- 模組一(標準要點回顧):把 SPM 第 1~8 章的核心壓縮成五大績效域 (Strategic Alignment / Benefits Management / Stakeholder Engagement / Governance / Life Cycle Management) 的高密度速習,並把易混的「治理 vs 管理」「定義 vs 規劃 vs 交付 vs 收尾」「Roadmap vs Charter vs Business Case」「benefit register vs benefit management plan」逐一掃乾淨。
- 模組二(ECO 任務鋪墊):點出 ECO 74 個任務是「點狀知識」,互相間沒有明顯邏輯,須由講師把它們和 SPM 標準的內在關係串起來;後續章節會逐一解讀。
講師強調的學前條件:精講看 ≥3 遍、標準讀 ≥2 遍、ECO 大綱讀 ≥5 遍,否則本章收益有限。
📑 思維導圖海報 (PDF 講義)

§1 ECO 任務的定位 (00:00:10)

核心:ECO 的 74 個任務是 PgMP 認證最直接的考試對應,需要與標準「點—面」結合理解。
- ECO = Examination Content Outline,依「五大績效域」評估考生對每個任務的熟悉度
- 越接近認證日,ECO 任務的權重越高
- 任務與任務之間邏輯關係不強,必須用標準 (SPM) 補出內在連結
- 兩大模組設計:(1) 第 1~6 章標準要點回顧;(2) 第 7、8 章生命週期 + 知識活動的零碎內容由標準補
PMI 術語:ECO (Examination Content Outline) ↔ 考試大綱 ↔ 講師「ECO 大綱」

講師原話:「精講看到了三遍以上,標準讀了兩遍以上,這套簡要的考試大綱讀了五遍以上,否則往後延一延再來看,否則收益會比較小。」
§2 五大績效域全景 (00:03:32)

核心:SPM 標準的核心是五大績效域,五者相輔相成、互相滲透。
- Strategic Alignment(戰略一致性)
- Benefits Management(效益/收益管理)
- Stakeholder Engagement(相關方爭取)
- Governance(治理)
- Life Cycle Management(生命週期管理)
PMI 術語:Five Performance Domains ↔ 五大績效域 ↔ 講師「五大績效率」

講師原話:「概述部分基本上可以把整套標準裡的核心要點做一個陳述。」
§3 戰略一致性的五要素 (00:03:42)
核心:戰略一致性的五要素 = 三份「弓箭」檔案 + 兩種前置分析。
- 三份弓箭(artifacts):商業論證 (Business Case)、專案集章程 (Program Charter)、專案集路線圖 (Program Roadmap)
- 兩種前置:環境評估 (Environmental Assessment)、風險管理策略 (Risk Management Strategy)
- 結構圖:左側組織戰略計劃 → 中間五要素 → 右側影響商業論證、章程、路線圖
- 三份檔案是戰略落地的「核心要點 + 文件式載體」
PMI 術語:Business Case / Program Charter / Program Roadmap ↔ 商業論證/章程/路線圖

講師原話:「左側是組織的戰略計劃,中間五個要素是專案集的風險管理策略、環境評估、商業論證、章程、路線圖。」
§4 收益管理五步驟 (00:04:44)
核心:收益管理 = 識別 → 分析 → 交付 → 移交 → 維持,是 SPM 最有代表性的績效域。
- 識別:早期由發起人、高層、PgM、關鍵相關方一起完成,登記到「收益登記冊 (Benefits Register)」
- 分析:透過收益依賴地圖 (Benefits Dependency Map/收益分解結構) 釐清收益間關係,指導要啟動哪些元件 → 構建出 Program Architecture
- 交付:透過元件完成而「產生」收益(不是把收益交出去)
- 移交:把產生的收益交給接收方/預期受益人 (Intended Beneficiary),通常是運營組織
- 維持:移交後由接收方/維持方 (Sustainer) 持續產生收益
PMI 術語:Benefits Identification / Analysis / Delivery / Transition / Sustainment ↔ 收益的識別/分析/交付/移交/維持

講師原話:「收益的交付其實是收益的產生過程,它不是將收益交出去的;交出去的過程被稱為收益的移交。」
§5 相關方爭取五步驟 (00:07:15)
核心:相關方爭取 = 識別 → 分析 → 規劃 → 爭取 → 溝通,是迴圈迭代的過程。
- 識別重要相關方要在早期,因為他們要參與戰略與收益管理
- 分析後:分析資訊納入「相關方爭取計劃」、基本資訊與分析結論納入「相關方登記冊」(兩文件區別是要點)
- 計劃要前置規劃,不是專案進行中臨時決定
- 爭取主要靠溝通手段
- 注意:相關方在不同階段會進進出出,整個過程是 iterative loop
PMI 術語:Stakeholder Engagement Plan / Stakeholder Register ↔ 相關方爭取計劃/相關方登記冊

講師原話:「在早期重要的相關方在中期和後期可能沒有那麼重要,相同的情況也是在早期沒有出現的相關方後期可能介入進來,它是一個迴圈迭代不斷重複進行的過程。」
§6 治理 vs 管理的本質區別 (00:09:09)
核心:治理 = 「關於管理該怎麼開展」的規則,是更高層面的實體對管理行為做評審決策。
- 治理涉及:決策、監控、做出判斷、批准、檢查、評審
- 治理機制涵蓋:變更、風險、問題、彙報關係、階段關口 (Stage Gate)、健康檢查節點、元件啟動/移交/收尾批准
- 治理需事前設定機制(Program Governance Plan)+ 角色職責定義
- 偶發事件可臨時處理,可預見的須提前規劃
- 一句話:治理是「更高層面的管理對管理行為做出判斷或評審」
PMI 術語:Program Governance ↔ 專案集治理 ↔ 講師「治理」

講師原話:「治理實際上是一種更高層面的管理,它對管理的行為做出判斷或做出評審,然後給出繼續或者是不繼續的決定。」
§7 生命週期管理三階段對應關係 (00:10:55)
核心:專案集生命週期 = 定義 (Definition) + 交付 (Delivery) + 收尾 (Closure),分別對應 PMP 的啟動規劃/執行監控/收尾。
- 定義階段 = PMP 啟動 + 規劃;可細分為 Formulation Sub-phase + Planning Sub-phase
- 交付階段 = PMP 執行 + 監控;可細分為元件識別與分析、規劃、監控、整合等三個子階段
- 收尾階段 = PMP 收尾;包含「移交 + 關閉」兩個動作(舊版標準是兩階段,新版合併)
- 區別關鍵:專案集 vs 元件層面執行的活動內容不同;元件做五大過程組/十大知識領域,專案集做 Program-level activities
PMI 術語:Definition Phase / Delivery Phase / Closure Phase ↔ 定義/交付/收尾
PMI 術語:Formulation Sub-phase / Planning Sub-phase ↔ 構建子階段/規劃子階段

講師原話:「在新的標準當中收尾包括移交和關閉兩個動作,在以前的標準當中它是兩個獨立的階段。」
§8 專案集的定義(What is a Program) (00:12:23)
核心:Program = 一組互相依賴 (interdependent) 的元件,以協調管理方式 (coordinated manner) 取得分別管理得不到的額外收益。
- 元件三種形式:(1) 專案 (project)、(2) 子專案集 (subsidiary program)、(3) 專案集活動 (program activity)
- 標準用 "related",講師指出
interdependent比related含義更清晰 - 必要條件:(a) 多要素構成 (b) 要素之間有內在聯絡
- 否則只是複雜的個別管理 → 接近 portfolio management,而不是 program management
- 核心關鍵字:
obtain benefits not available from managing them individually
PMI 術語:Program / Components / Interdependent / Coordinated Manner ↔ 專案集/元件/互相依賴/協調管理

講師原話:「我們發現事物之間內在聯絡是一個能力,基於這種內在聯絡加以對它進行更恰當的管理是另外一種能力——專案集管理思想聚焦在這個地方。」
§9 定義階段:構建子階段做什麼 (00:14:50)
核心:構建子階段 (Formulation Sub-phase) 主要產出三個 top-level 檔案——商業論證、章程、路線圖。
- 邏輯鏈:組織戰略計劃 → 商業論證 → 專案集章程 → 專案集路線圖(逐步展開、逐步細化)
- 早期戰略計劃與商業論證通常不輕易改變(不像後期管理計劃內 14 子計劃會頻繁互動)
- 主要落腳點:(1) 專案集獲得認同認可;(2) 章程宣佈專案集開始、任命 PgM、授權動用組織資源
- 商業論證的批准依據是「對組織有收益和價值,能支持戰略落地」
- 路線圖描述時間節奏、關鍵節點、決策點,是章程的可讀化、圖形化補充
PMI 術語:Top-level documents / Resource Commitment ↔ 高層級檔案/資源承諾

講師原話:「組織的高層憑什麼來批准這個專案集呢?它的依據其實是我們的專案集商業論證——做這個專案集對組織是有收益和價值的,它能給組織的戰略落地提供支援。」
§10 定義階段:規劃子階段做什麼 (00:18:44)
核心:規劃子階段 (Planning Sub-phase) 把 top-level 檔案細化為 14 子計劃,輸出「專案集管理計劃」。
- PgM 已被任命,帶領核心團隊做進一步規劃
- 14 個方面:範圍、進度、財務、質量、資源、溝通、風險、採購、變更、治理計劃、收益實現計劃、資訊、…
- 子計劃之間互動關係明顯,且有迴圈關係
- 重點提醒:定義階段並不代表所有元件都已被定義出來;元件的真正啟動/規劃/執行/監控/收尾是在交付階段
- 早期已明確的元件可納入規劃,但不強迫所有元件在定義階段都明確
PMI 術語:Program Management Plan ↔ 專案集管理計劃

講師原話:「這 14 個組成部分——範圍、進度、財務、質量、資源、溝通、風險、採購、治理計劃、收益實現計劃等等,這些計劃之間的互動關係和迴圈關係會非常的明顯。」
§11 交付階段:元件授權/監管/整合/移交 (00:20:12)
核心:交付階段 = 元件授權與規劃 → 元件監管與整合 → 元件移交與關閉。
- 元件授權與規劃對應 PMP 的「啟動」+「規劃」
- 對專案集而言是「授權元件啟動」;對專案而言是「專案本身的啟動」
- PgM 透過治理批准元件啟動,元件依專案集管理計劃做自身規劃
- 元件規劃要與專案集管理計劃「指導與保持一致」(雙向互動)
- 執行階段:PgM 做 Component Oversight(監督),不過度干預專案層面活動
- Integration:元件之間有依賴時,PgM 將可交付成果整合,形成專案集層面的收益
- Component Transition:完成後將可交付成果或收益移交給接收方
PMI 術語:Component Oversight / Integration / Component Transition ↔ 元件監督/整合/移交

講師原話:「整合在一起,形成了整個專案集層面的收益,叫 Integration。」
§12 元件 vs 專案集的「收益」概念差別 (00:23:25)
核心:元件有「關閉」的概念,但收益沒有「完成」的概念,只有「交付、移交、維持」。
- 所有元件都關閉後,整個專案集才進入收尾
- 收尾前要確認元件層面合同付款、風險移交、財務收尾等都做完
- 專案集還要做整體移交 + 整體收尾(一頭一尾都是專案集層面做)
- 中間階段是專案集 + 元件層面行為混合
- Program Deliverance 涵蓋了 PMBOK 單專案管理的所有生命週期
PMI 術語:Program Deliverance / Component Closure ↔ 專案集交付/元件關閉

講師原話:「收益其實沒有完成的概念,它是移交、維持,它沒有關閉的概念;但是元件是有關閉的概念的。」
§13 元件之間的非順序性 (Non-Sequential Nature) (00:24:35)
核心:專案集元件不是順序執行,而是在不同時間點同時啟動、執行、收尾,呈非順序性。
- 到了時間點,該啟動的元件就啟動,該收尾的就收尾
- 同時可能有:元件 A 還沒啟動、元件 B 在執行、元件 C 已收尾
- 因此 PgM 必須有更高層面的管理實體(治理)對所有行為做指示、判斷、批准
- 三階段 (定義/交付/收尾) 對應的是專案集生命週期;戰略收益是在過程中不斷核定、核實、批准
PMI 術語:Non-Sequential Nature ↔ 非順序性

講師原話:「有的專案還沒啟動,有的專案已經收尾了,所以它之間是一種非順序性的關係。」
§14 治理與組織治理的關係 (00:25:48)
核心:專案集治理 + 專案集管理都要在組織治理模型之下開展。
- 專案集層面再高,也需要組織層面做監管,才能保證組織戰略一致性
- PgM 負責推進治理職能,由更高的管理實體(PSC)做評審決策
- 治理規則 + 流程在早期定義階段就須建立
PMI 術語:Program Governance / Organizational Governance / PSC (Program Steering Committee) ↔ 專案集治理/組織治理/專案集指導委員會

講師原話:「也就是說你專案集層面再高,也需要組織層面去做出一定的這種監管,保證整個組織層面的戰略一致性是得以保證的。」
§15 專案集管理的定義(含 principles) (00:26:33)
核心:Program Management = 將「知識、技能、原則」應用於專案集要素,獲得分別管理得不到的額外收益與管控。
- 注意是
principles(原則),不是過去的tools(工具) - 必要條件:(a) 互相依賴 (b) 多要素構成
- 雙重收益:(1) 收益最大化 (2)
obtain benefits AND control(可掌控感) - principles 對應五大績效域的核心思想:收益最大化、戰略一致性、組織治理分級、相關方恰當爭取、生命週期有序/靈活展開
PMI 術語:Program Management = knowledge + skills + principles → benefits + control

講師原話:「不是原來我們說的知識技能和工具了,是原則。基於原則協調管理,目的是為了獲得額外的收益。」
§16 PgM 的角色:alignment + integration + control (00:28:30)
核心:PgM 由組織授權帶領團隊,確保 alignment + integration + control 三件事。
Organization authorizes a program manager to lead the team for achieving program goals and objectives- alignment:專案集內部要素一致性 + 專案集與組織層面一致性
- integration:元件之間協同、可交付成果的有效結合
- control:對事情的額外掌控,避免偏離原來的軌道
PMI 術語:Alignment / Integration / Control ↔ 一致性/整合/掌控

講師原話:「Program manager ensures effective alignment, integration and control。」
§17 三種結構化方法的關係 (00:29:25)
核心:Project / Program / Portfolio Management 都是「結構化方法 (structured means)」,目的都是讓組織戰略落地。
- Project Management:聚焦在範圍進度成本質量的限制條件之內,按確定性方式交付專案結果(早期詳細規劃)
- Program Management:關注組成部分的依賴關係,最終要實現收益最大化;五大績效域結構化
- Portfolio Management:透過排列元件優先順序分配資源,最大化組織價值;更高階
- 兩個層次的關係:(1) 高低層次 (2) 各有側重
PMI 術語:Structured Means / Project vs Program vs Portfolio Management

講師原話:「如果你分別管理它,你雖然做一件很複雜的設計,但是我們通常不把它叫 program management,我們甚至可以把這種方式稱為叫 portfolio management。」
§18 Portfolio / Program / Project 三層級關係 (00:31:18)
核心:在從屬關係下,Portfolio 含 Program、Program 含 Project,三者都為落實組織戰略。
- Portfolio Manager:
Selectportfolio components → 排列優先順序 →staff(分配資源,含人員、設施、設備)→ 達成Organizational Value - Program Manager: 在 PfM 指導下,協調專案集元件的依賴關係,交付
benefit - Project Manager: 由 PgM
Select / Assign,管理單個專案,產生Output / Outcome / Deliverables - 詞語區分:value(組織層)↔ benefit(專案集層)↔ deliverable(專案層)
- PfM「協調」、PgM「協調」、PM「管理」
PMI 術語:Organizational Value vs Benefits vs Deliverables

講師原話:「組合經理透過排列專案組合元件 ... 它的最主要工作是協調;那麼專案經理就是它的工作主要是管理。」
§19 PgM 與 PM 的互動隨生命週期變化 (00:35:01)
核心:The interactions and relationships between program managers and project managers may change over the program life cycle。
- 專案集早期 (Formulation):PgM 工作複雜重要,需協調統一認識;PSC 與 Sponsor 給予較多幫助
- 專案啟動 + 規劃:PgM 介入較多,提供
Oversight, Direction, Guidance,協助 PM 完成工作 - 專案執行 + 監控:PgM 主要按治理規則、彙報原則收資訊,元件之間有衝突才介入協調
- 專案收尾/元件移交:PgM 又要密集介入,因為可交付成果可能對其他元件有影響
- 整個專案集收尾:PgM 與 Sponsor 要高效互動;移交動作好不好直接決定收益的可維持性
PMI 術語:Oversight / Direction / Guidance

講師原話:「可維持性取決於你的移交的平滑性。」
§20 五大績效域整體回顧 + 與更高層的關係 (00:40:14)
核心:五大績效域相輔相成,每一個都會涉及其他四個。
- 五大績效域:戰略一致性、效益管理、相關方爭取、專案集治理、生命週期管理
- 與組織戰略 + Portfolio Management + Program Management 的關係要記憶猶新
- 本次會補充更多新內容

講師原話:「在每個領域一邊都會涉及到其他四個方面的內容。」
§21 從願景使命到專案集:商業論證的定位 (00:41:00)
核心:戰略計劃 → 商業論證是專案集生命週期之外 → 之內第一份正式檔案的關鍵跳轉。
- 組織願景使命 → 戰略規劃週期 → 戰略計劃(在專案集生命週期之外,作為輸入)
- 專案集商業論證 = 專案集內部的「第一份正式檔案」
- 商業論證提交組織高層 → PSC 或 Portfolio Review Board 評審
- 早期還沒有 PSC 時,由 Portfolio Review Board 承擔職責;嚴格來說那時叫
initiative(提案/舉措),而非 program;考試時不用嚴格區分
PMI 術語:Initiative / Portfolio Reviews / Portfolio Review Board / Program Steering Committee

講師原話:「在早期我們並不知道它一定是專案集的方式,它只是一個 initiative,是個舉措,是個提案。」
§22 商業論證 → 章程 → 路線圖的順序 (00:43:14)
核心:認證記憶順序 = 商業論證在前 → 章程在中間 → 路線圖在後(實際時間順序略有不同)。
- 商業論證透過後 = 組織授權該專案集啟動下一步
- 下一步 = 制定專案集章程:明確目標、收益策略、PgM、組織高層形成 PSC 後批准
- 章程裡最核心的時間線可由獨立檔案 Roadmap 進一步深入描述
- Roadmap 比文字檔案 (charter / business case) 更可見、圖形化、按時間順序排列
- 標準把 Roadmap 與 Charter 分離,實踐中可合併;考試當兩個獨立檔案處理沒問題
PMI 術語:Business Case → Program Charter → Program Roadmap

講師原話:「商業論證和專案集章程相比較的話,商業論證就是更高層面的,是 outline 的、輪廓性的、方向性的、框架性的;而專案集章程就是比它更細緻一些。」
§23 環境評估 + 風險策略 (00:46:30)
核心:在制定三檔案的同時,要做環境分析判斷與專案集早期風險策略。
- 環境分析有五個工具(請回去複習)
- 早期不確定性大,相關方對專案集認識差異大 → 風險管理「策略性」內容(不是 risk activity,也不是 risk management planning)
- 需要的是 high-level 的策略性方向
PMI 術語:Environmental Assessment / Risk Management Strategy (Early)

講師原話:「不是風險管理的 activity,也不是 risk management planning,而是在早期的風險的策略性的東西,也是高層面的。」
§24 戰略一致性的「上下傳遞」邏輯 (00:48:00)
核心:戰略落地是「下→上」完成、戰略規劃是「上→下」完成;兩者必互動。
- 後端檔案要以前端為輸入,且必須與其保持一致
- 一致性鏈:管理計劃 → 與章程一致 → 章程與商業論證一致 → 商業論證與戰略計劃一致 → 戰略計劃與組織願景使命一致
- 通過這種方式保證「做的事情都是有意義和價值的」
- 認證題庫此處題目特別多:檔案之間關係、定位、所處階段
PMI 術語:Strategic Alignment / Cascade & Aggregate

講師原話:「能夠讓組織的戰略一以貫之的從頭貫徹到尾——戰略的落地是從下向上完成,但是戰略的規劃是從上向下完成的。」
§25 商業論證的本質:經濟可行性 (00:50:30)
核心:商業論證 = economic feasibility study,建立收益的「合法地位 / 有效性」。
- 強調商業(economy)面,不涵蓋 military / political 等其他面
- 核心成分:商業需求 + 成本收益分析
established validity of the benefit:建立收益的有效性- 提交給 PSC 或 Portfolio Review Board 批准
- 批准 = 組織願意投入資源讓你做
PMI 術語:Economic Feasibility Study / Cost-Benefit Analysis / Validity of Benefit

講師原話:「商業論證它是組織批准專案集裡邊收益的一個最主要載體,它描述了專案集的經濟可行性。」
§26 章程的本質:define + authorize + resource commitment (00:53:30)
核心:章程 = define the strategic objective + define the scope + resource commitment + trigger Planning Sub-phase。
- 章程把商業論證的核心內容做更明確的描述
define在這一層只是相對商業論證更詳細,不是指後端管理計劃級別的詳細- 組織以正式方式做出 resource commitment(PSC 已批准)
- 章程定義 scope,但層面仍然較高、方向性的(與專案管理 scope 不同層面)
- 章程被批准 = 觸發 (
trigger) 規劃子階段
PMI 術語:Program Charter / Define / Authorize / Resource Commitment / Trigger

講師原話:「組織批准章程意味著真正的授權 authorize 專案集可以啟動了,專案集經理有權利動用組織資源。」
§27 戰略一致性五要素的歸屬 (00:56:35)
核心:戰略一致性五要素(商業論證、章程、路線圖、上面的風險、底下的環境評估)主要在構建子階段完成。
- 五要素中最重要的是商業論證 + 專案集章程
- 構建子階段 = 戰略一致性的「主戰場」

講師原話:「中間的這一部分是戰略一致性的主戰場——它的主戰場的意思就是在這要做大量的工作。」
§28 收益管理在生命週期中的對應 (00:57:48)
核心:收益管理五步驟與專案集生命週期是「大致對應」(非一一對應)。
- 收益識別:通常在定義階段早期(構建子階段)開始,持續到規劃子階段
- 整個生命週期會反覆做收益識別
- 重點:定義早期就要識別「絕大部分最重要」的收益
- 識別人:發起人、PgM(若早期已任命)、PSC、組織高層的期望都可轉化成收益
PMI 術語:Benefits Identification

講師原話:「大家要逐漸接受這種非一一對應、非清晰對應的這種理論知識體系,它是大致對應的。」
§29 收益登記冊:客觀記錄載體 (01:01:05)
核心:Benefits Register 是收益的「客觀資訊與狀態」載體,首次產生於識別階段,後續持續更新。
- 識別出的收益 → 登記到收益登記冊
- 早期登記主要部分;後續有更重要收益可更新進來
- 主體工作在識別階段完成
- 用途:記錄客觀資訊(收益是什麼、進展如何)
PMI 術語:Benefits Register ↔ 收益登記冊

講師原話:「收益登記冊是記錄客觀狀態、客觀資訊。」
§30 收益分析與規劃 + Benefits Management Plan (01:02:40)
核心:收益分析 = 釐清收益間依賴 + 對應到元件 + 定指標 + 定時間 → 輸出「收益實現計劃 / 收益管理計劃」。
- 為什麼要做規劃:收益間有依賴(A → B → C),需在元件設計前先有收益概念
- 把幾個有內在聯絡的收益組合 → 交給一個元件執行
- 還要定指標 (Benefit Management Metrics) + 定時間(什麼時間實現什麼收益)
- 輸出:Benefits Realization Plan / Benefits Management Plan(在 ECO 任務中兩名稱交替使用,標準用 Management Plan,考試用 Realization Plan,等同處理)
- 這份計劃是「基準型檔案」:定義「要做成什麼樣子」
PMI 術語:Benefits Realization Plan / Benefits Management Plan / Benefit Management Metrics

講師原話:「收益管理計劃還有一個定位,它是一個基準型的檔案——也就是要做成什麼樣子是在這個檔案當中記錄的。」
§31 收益登記冊 vs 收益管理計劃對比 (01:09:50)
核心:兩份文件分工——登記冊記「實際做到什麼樣」,管理計劃記「該做到什麼樣」(基準)。
| 文件 | 定位 | 內容 |
|---|---|---|
| Benefits Register | 客觀記錄 | 收益是什麼、進展、狀態 (status / progress) |
| Benefits Management Plan | 基準 | 要怎麼實現、什麼時間實現、測量指標 |
- 進度更新(progress / status)記錄在登記冊,不是管理計劃
- 比較計劃 vs 基準 → 監督收益 (
monitor benefit/monitor component,兩者意義在此互通) - 監督收益最終轉化成「監督元件可交付成果與專案狀態」

講師原話:「客觀記錄收益狀態的是這個檔案(登記冊);那麼他到底是做的好與壞,要回到收益管理計劃當中定義好的收益測量指標去衡量他。」
§32 收益交付:監督元件 + 維持登記冊 (01:11:00)
核心:收益交付透過元件完成,需 monitor component + maintain benefit register + report benefit。
- 監督元件:因為元件 = 對應收益的執行載體,元件完成 = 收益產生
- 維持收益登記冊:隨元件進展實時 update 收益狀態
- 報告收益:依溝通管理計劃,將收益狀態報告給相關方
- 交付給哪一方 = 收益移交,由該方負責收益維持
PMI 術語:Monitor Component / Maintain Benefit Register / Report Benefit

講師原話:「監督收益最終會轉化成監督專案的交付成果、專案的狀態來完成的。」
§33 「專案集收益交付階段」改名 (01:14:09)
核心:新版標準把「專案集收益交付階段」改名為「專案集交付階段」(Program Delivery Phase),避免與收益管理混淆。
- 舊名
Program Benefits Delivery Phase容易與收益管理內容大量交叉 - 新名
Program Delivery Phase強調主要工作是「元件的啟動規劃執行監控收尾」 benefit delivery中的 delivery =produced / generate(產生)- 所以與專案集交付階段「大致對應」而非「等同」
PMI 術語:Program Delivery Phase(取代舊 Program Benefits Delivery Phase)

講師原話:「benefit delivery 這個 delivery 大家可以把它理解成產生,produced 或者是 generate 的這個意思。」
§34 收益移交:為什麼必須做 (01:15:55)
核心:移交是為了「後面能夠更好的維持」;缺了移交,接收方未來維持時一定有所損失。
- 接收方要提前參與,了解收益產生背景與未來該做的事
- 類比:銷售簽下訂單回來,若交付團隊完全不了解合同情境,僅看文字 → 大量資訊丟失
- 提前讓銷售與售後人員一起討論 → 便於理解
- PgM 重點工作:將專案集產生的收益合併移交給接收方
PMI 術語:Benefits Transition

講師原話:「交付之後緊跟著移交,移交的目的實際上是為了後面能夠更好的維持。」
§35 專案集收尾的「desired」收益概念 (01:11:23 — 跨段補充)
核心:專案集收尾時收益不必全部完成,只要「預期的 (desired) 收益部分」達到即可。
- 收尾條件:(1) 元件都完成 (2)
desired benefits achieved - 收益的維持週期長於整個專案集週期;許多收益要在移交後由接收方在未來幾年達成
- 收益實現的三種狀態:
- 專案集結束之前完成
- 專案集結束的那一刻立即實現
- 專案集結束之後由接收方在未來實現
- 三種狀態的共同落腳點:收益實現責任屬接收方(維持方)
PMI 術語:Desired Benefits Achieved / Sustainer / Beneficiary

講師原話:「他用的詞叫 desired benefit achieved,不代表是所有的收益都在專案級收尾之前要完成。」
§36 本章學習法總結
核心:本章是「複習 + 串聯」:用 SPM 標準的結構化邏輯,把 ECO 點狀任務串成可考的知識網。
- 模組一已涵蓋:五大績效域、生命週期三階段、Portfolio/Program/Project 三層級、PgM 與 PM 互動
- 模組二(後續章節):逐一解讀 ECO 74 個任務,並映射回標準
- 認證重點:(1) 三檔案 (Business Case / Charter / Roadmap) 的關係定位 (2) 收益登記冊 vs 收益管理計劃 (3) PgM 在不同階段的介入度 (4) 收益的 desired achievement 概念
建議下一步: 1. 把戰略一致性框架圖(§3、§22、§24)背到「閉眼能默畫」 2. 把收益登記冊 vs 管理計劃對照表(§31)做成 Anki 卡 3. 把 PgM 介入度曲線(§19)轉成情境題判斷練習 4. ECO 任務解讀章節(後續 Ch07+)開始時,回頭對照本章框架
章末速查表
| 概念 | 文件/工具 | 階段 |
|---|---|---|
| 戰略一致性 | Business Case → Charter → Roadmap + 環境評估 + 風險策略 | Formulation Sub-phase |
| 收益識別 | Benefits Register | Definition 早期 |
| 收益分析規劃 | Benefits Management Plan / Benefits Realization Plan | Definition 後期 |
| 元件啟動/執行 | Component Authorization / Oversight / Integration | Delivery |
| 移交 | Component Transition / Benefits Transition | Delivery 後期+Closure |
| 維持 | Sustainer (接收方) | Closure 之後 |
| PSC 評審 | Stage Gate Review | 全生命週期關鍵節點 |
| 易混 | 區別 |
|---|---|
| 治理 vs 管理 | 治理 = 規則 + 評審決策(更高層);管理 = 執行 |
| 交付 vs 移交 vs 維持 | 交付=產生;移交=轉手;維持=持續產生 |
| Charter vs Business Case | Charter 較細緻、宣告開始;BC 較概要、論證可行性 |
| 收益登記冊 vs 管理計劃 | 登記冊=客觀進展;管理計劃=基準與測量指標 |
| value vs benefit vs deliverable | Portfolio=value;Program=benefit;Project=deliverable |
| Program Delivery Phase(新) vs Benefits Delivery Phase(舊) | 改名避免與收益管理混淆 |