Ch08 — 07 第7章 (57 min)

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

章節綜述

本章把整本《Standard for Program Management》收尾，再橋接到 PgMP 考試大綱（ECO） 的任務式學習。

前半段沿著「Program Life Cycle」往下推：交付階段的元件啟停、整合監督、收益移交；收尾階段的「真正關閉」與「風險移交」；再把 Integration Management 拆成 5 個核心活動（基礎設施、交付管理、績效監控、收益維持與專案級移交、專案級關閉）。

接著把 Supporting Activities（10 個方面 × 4 個階段）跟核心活動／治理三者串成一張大網，提醒「定義階段重 estimate / assess、規劃階段重 plan / framework、收尾階段重 closure / transition」。

後半段切換到 ECO： - 標準的 5 大績效域 vs ECO 用詞的差異（Strategic Alignment ↔ Strategic Program Management；Stakeholder Engagement ↔ Stakeholder Management）。 - 72 個 task / 170 題的權重分配 → 相關方管理 4:1 含金量最高，其他大多 2:1。 - 進入 Strategic Program Management Domain 11 個 task 的逐項精讀（本集只開到 task 1–2）。

學習方法雙軌：標準要建構整體網絡；ECO 要「機械式」反覆讀句，至少 5 遍以上，越接近考試越要刷句感。

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

§1 規劃子階段：把已明確的元件管理計劃融入專案級 (02:00:00)

核心: 規劃階段如果某些元件已在定義階段被明確，就要把它的管理計劃「融」進專案級管理計劃，不是疊加。

• 元件正式的啟動／規劃／執行／監控／收尾發生在交付階段，但早期就明確的元件例外。
• 早期已存在的元件 → 必須包含在專案級管理計劃內。
• 還沒明確的元件 → 規劃時可不納入。
• 「融」≠ 把元件計劃整份貼上來；只把最重要的部分抽出做監督評審。
• 衝突就要求元件改；夠重要就把它寫進專案級管理計劃。

PMI 術語: Program Management Plan ↔ 專案級管理計劃 ↔ 講師「專案級管理計劃」

講師原話: 「這個整合不是把元件的計劃拿到專案級層面把它疊加在一起，只是把元件當中最重要的那部分拿到專案級層面來，觀察監督評審一下。」

§2 交付階段四動作：元件的啟停 / 規劃 / 監督整合 / 移交收尾 (02:01:05)

核心: 站在專案級看元件，就是「授權→規劃→監督整合→移交收尾」四件事，自己不執行，只整合。

• 元件被授權才能啟動，元件做規劃時專案級也對應規劃。
• 執行階段：元件是主，專案級監督與整合。
• 移交收尾：專案級參與並監督，不是親手做。
• 主導者永遠是 program manager 或 program management。

PMI 術語: Component ↔ 元件（即專案級下的專案）↔ 講師「元件就是專案」

講師原話: 「站在專案級的角度看元件，那就是元件被授權你才可以啟動。」

§3 元件啟動的鐵律：必有 Business Case (02:01:50)

核心: 任何新元件的啟動／重新規劃，前提條件就是商業論證——而且是「元件層面的」，不是專案級層面的。

• 元件原本有價值，環境變了 → 重新規劃或新啟動。
• 沒有商業論證就不會被批准。
• 元件 BC 是元件級的，不要跟專案級 BC 搞混。

PMI 術語: Component Business Case ↔ 元件商業論證 ↔ 講師「元件層面的商業論證」

講師原話: 「元件啟動被批准的前提條件，必須具備它的商業論證 business case，這個不是專案級層面的。」

§4 整合的特別方式：把整合本身設成一個元件 (02:03:40)

核心: 元件之間整合太複雜時，可以打引號地「啟動一個新元件」專門做整合——往往由 PMO 或專案級管理團隊承擔。

• 整合元件代表 program manager 去協調其他元件之間的銜接。
• 沒授權新元件時 → 專案級經理自己做。
• 授權後 → 該團隊負責整合與監管。

PMI 術語: PMO (Program Management Office) ↔ 專案級管理辦公室 ↔ 講師「PMO」

講師原話: 「在專案級也依然可以有這樣一個整合所有元件的這麼樣一件事，作為一個新的元件。」

§5 元件依賴：先成項目 A 推完，B 才能成 (02:04:40)

核心: 當 B 的可交付以 A 為前提，program manager 必須主動 push 專案 A，才能讓 B 完成。

• 「部分元件收益實現前，需要其他元件整合」是常見場景。
• Program manager 的工作 = 推動、協調、整合，不是做。

講師原話: 「B 完成它的可交成功的前提條件，是 A 產生了它的可交成功，那麼這時候你還要去 push，去推動專案 A。」

§6 收益維持計劃：移交給運營 / 接收方 (02:05:25)

核心: 元件成果交給運營或接收方後，要附上維持計劃，確保收益持續產生。

• 維持計劃是 program manager 與元件協作制定。
• 接收方拿到成果時就要知道「該怎麼用、怎麼維持」。
• 直到所有元件完成 → 專案級才能評審整體收益是否達成 → 進入收尾。

PMI 術語: Benefits Sustainment Plan ↔ 收益維持計劃 ↔ 講師「維持計劃」

§7 專案級收尾的兩種解讀：先做完 vs 在收尾「確認」 (02:06:30)

核心: 講師個人傾向「收尾只是確認，不是做」——元件關閉與合同關閉應在交付階段就做完，收尾只是再確認一次。

• 第一種解讀：所有事做完才能進收尾（強）。
• 第二種（標準傾向，講師也採此）：收尾時把這些事確認一遍。
• 確認對象：所有元件已關閉、所有採購合同已關閉、預期收益已實現、收益維持已安排。
• 否則 PSC（Program Steering Committee）不批准收尾。

PMI 術語: Program Closure ↔ 專案級收尾 ↔ 講師「專案級收尾」

講師原話: 「在這只是確認，並不是在這去做所有元件收尾這件事⋯⋯我個人都傾向於在這只是確認，而不是做這件事。」

§8 收尾必做：報告 / 歸檔 / 知識移交 / 風險移交 (02:08:00)

核心: 收尾不是把事再做一遍，而是「結帳 + 留底 + 分發」四件事。

• 資源遣散：program 是臨時組織，要解散。
• 最終報告：program 出最終報告。
• 歸檔：所有有價值檔案歸檔。
• 知識移交：接收方要的給接收方，不要的留給自己組織做經驗教訓。
• 風險移交（新概念）：收尾後仍存在的風險要交給長設組織（通常 PMO）持續看管。

PMI 術語: Risk Transition ↔ 風險移交 ↔ 講師「風險移交」

講師原話: 「專案級關閉的時候風險可能不一定關閉，就它還存在，那這時候不能沒有人管。」

§9 風險移交的接手者：常設 PMO 而非臨時 program (02:09:15)

核心: Program 解散後，風險由專案級所在組織的 PMO承接，因為 PMO 是長設機構。

• Program = 臨時組織，解散後不存在。
• PMO = 長設機構 → 適合扛遺留風險。
• PMO 隨時監督風險狀態直到事件結束。

講師原話: 「專案級這個組織就不存在了，它是一個臨時性的組織，而專案級所在的組織的專案管理辦公室它是一個長設的機構，它可以把這個風險接收進來。」

§10 收尾的兩道批准門：PSC + Sponsor (02:09:30)

核心: 收尾啟動和收尾結束都要 PSC 與 Sponsor 雙重批准。

• 一個人 → 通常叫 Sponsor。
• 一群人 → 通常叫 Program Steering Committee。
• 收尾結束的最終批准方：發起組織 (sponsoring organization)。

PMI 術語: PSC (Program Steering Committee) ↔ 專案級指導委員會 ↔ 講師「專案級製造（指導）委員會」

講師原話: 「如果是一個人的時候，我們通常叫 sponsor；如果是一群人的時候，我們通常把它叫專案級指導委員會。」

§11 整合管理為何放在生命週期章 (02:10:30)

核心: 標準把 Integration Management 塞進生命週期章，是因為 program 太複雜，總需要整合動作。整合管理 = 5 個核心活動 (Core Activities)。

• 多樣支援活動展開時必有整合需求。
• 5 個核心活動構成整合管理。

PMI 術語: Integration Management / Core Activities ↔ 整合管理 / 核心活動 ↔ 講師「核心活動」

§12 核心活動 1：Program Infrastructure Development (02:11:00)

核心: 在定義階段完成。基礎設施 = 三大塊：PMO/政策流程、program management team、program 資訊管理系統——含硬性（IT 系統）+ 軟性（規範流程）。

• 考試常見題：不同元件用各自最好的工具，program manager 怎辦？→ 答案在治理：統一基礎設施使用流程規範。
• 軟性：制度、流程、標準化、資源／技術共享。
• 硬性：統一的資訊管理系統。

PMI 術語: Program Infrastructure ↔ 專案級基礎設施 ↔ 講師「基礎設施」

講師原話: 「infrastructure 既包括硬性的也包括軟性的。」

§13 核心活動 2：Program Delivery Management (02:13:00)

核心: 與「收益交付」有大交集但範圍更大——既包括元件的形成與交付，也含一部分收益交付。

• Delivery management 重點是元件層面。
• 也吃進收益相關內容，但不止於此。
• 易與 Benefits Delivery 混淆，記住：元件 + 收益。

PMI 術語: Program Delivery Management ↔ 專案級交付管理 ↔ 講師「專案級交付管理」

§14 核心活動 3：Program Performance Monitoring (02:13:40)

核心: 兩件事——比較分析偏差 + 預測未來走向。

• 對比計劃 vs 實際 → 找偏差。
• 對未來趨勢做預測判斷。
• Program 層面 糾正措施 (corrective) 多，預防措施 (preventive) 幾乎不提；但考試碰到含義同 PM。

PMI 術語: Performance Monitoring ↔ 績效監控 ↔ 講師「績效監控」

§15 核心活動 4：Benefits Sustainment & Program Transition (02:14:30)

核心: 區分 Benefits Transition vs Program Transition——後者範圍更大。

• Benefits Transition：移交收益，由接收方維持。
• Program Transition：除收益外還含檔案、文件、設施等非收益資產。
• 收益維持的主體永遠是接收方，program 只協助。

PMI 術語: Benefits Transition vs Program Transition ↔ 收益移交 / 專案級移交 ↔ 講師「benefit transition 和 program transition 是有不同的」

講師原話: 「benefit transition 和 program transition 是有不同的，這個大家在碰到的時候要格外的區分它。」

§16 核心活動 5：Program Close-out (02:16:00)

核心: Program Close-out 與 Program Transition 都對應收尾階段。

• Transition + Close-out 一對：先移交，再關閉。
• 移交內含 program transition + 收益維持（其實也含 benefit transition）。

PMI 術語: Program Close-out ↔ 專案級關閉 ↔ 講師「program close out」

§17 切換視角：Supporting Activities = Program 的「九大知識領域」 (02:16:50)

核心: Supporting Activities 與 Core Activities 的關係，像 PMBOK 整合管理 vs 其他 9 個知識領域。

• 整合（核心）= 協調者；支援活動 = 被協調者。
• 按生命週期 4 階段（構建 / 規劃 / 交付 / 收尾）逐一看互動。
• 每階段都涉及 10 個方面（與專案管理 10 大知識領域不同）：變更評估 / 溝通 / 財務 / 資訊 / 採購 / 質量 / 資源 / 風險 / 進度 / 範圍。

PMI 術語: Supporting Activities ↔ 支援活動 ↔ 講師「Supporting Activity」

§18 構建子階段：4 大評估最重要 (02:18:35)

核心: 構建子階段最該留意：範圍 / 資源 / 成本 / 風險的初始評估 (assessment)。

• 第一：成本初始評估。
• 第二：資源需求評估。
• 第三：風險評估。
• 第四：範圍。
• 這四個就是「定義階段」常考題的命中區。

PMI 術語: Initial Cost Estimation / Initial Risk Assessment ↔ 初始成本估算 / 初始風險評估

§19 構建子階段協同關係：戰略章程路線圖鏈 (02:20:00)

核心: 構建子階段最重要的核心管理活動 = 基礎設施構建；流程是「戰略計劃 → 環境/風險評估 → Program Charter → 組織批准 → 頒布」。

• Charter 跟 BC 內容大量重疊；Charter 比 BC 更細。
• BC 對應 approve；Charter 對應 authorize——兩字差異要記。

PMI 術語: Approve (BC) vs Authorize (Charter) ↔ 批准 vs 授權 ↔ 講師「approve 批准、authorized 授權」

講師原話: 「一個是批准一個是授權。」

§20 規劃子階段：估算升級為計劃 (02:22:30)

核心: 構建用 estimation/assessment（粗略），規劃用 planning（細緻）。

• 同樣是 10 個方面，但活動數超過 10。
• 兩個最重要輸入：Business Case + Program Charter。
• 路線圖未單獨列出 → 因為它是 BC 或 Charter 的一部分內容（Charter 有 timeline 即路線圖另一表現）。

講師原話: 「assessment 是初步的評價，在這就叫細緻的規劃。」

§21 規劃重頭戲：Financial Framework & Financial Plan (02:24:25)

核心: 規劃階段最關鍵活動是財務管理——三個產出層次：估算 → 框架 → 計劃。

• Cost estimate（規劃用 estimate，比構建的 assessment 更細）。
• Program Financial Framework：資金來源 vs 支出的關係結構。
• Program Financial Management Plan：對 framework 的進一步細化。
• 估算 → 框架 → 計劃，是新概念，考試願意考。

PMI 術語: Program Financial Framework ↔ 專案級財務框架 ↔ 講師「program financial framework」

講師原話: 「專案級的財務管理計劃是財務框架的細化。」

§22 規劃輸出：Program Management Plan (PMP) 形成 (02:25:50)

核心: 經過所有支援活動 + 核心活動，最終形成 Program Management Plan——子計劃 14 個 / 支援活動 10 個領域。

• 是專案級交付階段最重要的輸入。

§23 交付階段：指導原則 = Program Management Plan (02:26:15)

核心: 交付階段所說的「Program Directive (指導原則) 」本質就是 Program Management Plan。

• 執行中發生變更 → 必須更新 PMP。
• 交付階段最主要工作 = 督導元件啟動／規劃／執行／監控／收尾。
• Program manager 介入元件的力度：早期（啟動規劃）多，執行監控少，收尾多。

講師原話: 「本質上就是我們說的專案級管理計劃，它籠統的或者泛泛的叫專案級的指導原則，最核心的是專案級管理計劃。」

§24 交付階段彙報鏈：元件 → 專案級 → PSC (02:27:30)

核心: 元件向專案級彙報；專案級整合元件資訊與本身資訊再向上到 PSC 或更高層。

• 變更須經批准；批准後 PMP 更新才能成為新執行依據。
• 交付階段重點：財務管理 / 風險 / 進度 / 範圍。

§25 收尾階段：聚焦財務 + 歸檔 + 移交 (02:28:25)

核心: 收尾要做的事少而集中——財務收尾 / 採購收尾 / 資源釋放 / 風險移交四件最重要。

• Program Transition ⊃ Benefits Transition（前者範圍更大，含資訊歸檔、培訓、文件、設施）。
• 風險移交：給組織內常設組織（PMO）。
• 治理層提供 closure 指導 + 批准啟動 closure。
• 最終由治理層批准專案級真正關閉。

PMI 術語: Procurement Closure / Resource Release / Financial Closure ↔ 採購收尾 / 資源釋放 / 財務收尾

§26 移交給「運營」：可內可外 (02:30:30)

核心: 收尾移交目標 = 運營 (operations)——可能是組織內部運營，也可能是組織外部運營。

• 移交內容 = 資產 + 資源 + 風險。

§27 收尾階段四個必考點 (02:31:30)

核心: 把 supporting activities 重點總結，收尾四個關鍵點：財務收尾 / 採購收尾 / 資源移交 / 風險移交。

• 構建：初始成本估算 + 初始風險評估。
• 規劃：財務框架建立（新知識，必考）。
• 收尾：上述四件事。

§28 整章大整合：把支援活動 + 核心活動 + 戰略 + 收益放一起 (02:32:30)

核心: 一張全景圖——Supporting Activities + Integration Management + Strategy + Benefits + Stakeholder + Governance 全部串起來。

• 構建子階段 + 規劃子階段 = 定義階段 ↔ 對應收益識別 + 收益分析/規劃。
• 交付子階段 ↔ 對應收益交付（元件啟動／規劃／執行／監控／收尾）。
• 收益交付方式叫 creative / productive。
• 收尾階段 ↔ 對應收益移交與維持。
• Stakeholder 是相對獨立的章節，可單獨複習。

講師原話: 「這一頁大家如果能夠掌握清楚的話，對你來講應該幫助是非常大的。」

§29 切換到 ECO：學習方式截然不同 (02:35:00)

核心: ECO (Exam Content Outline) = task 是離散的點，跟標準的網狀結構完全不同——學習方法要切換成「機械式反覆閱讀」。

• ECO 每個 task 一句話；句子之間沒有強連結。
• 不要強行串聯任務，本就是離散的。
• 結合標準理解每個 task 背後的內在意義即可。

PMI 術語: ECO (Exam Content Outline) ↔ 考試大綱 ↔ 講師「ECO 叫 Exam Content Outline」

講師原話: 「它本身就是離散的一個一個的任務，大家以這種方式來去看待它，可能對你的學習這部分會有更大的幫助。」

§30 ECO 與標準的命名差異 (02:37:00)

核心: 5 大績效域名稱 ECO 跟標準有差異——記住對應關係，ECO 是 2011 年舊版。

• Strategic Program Management = 戰略一致性。
• Stakeholder Engagement → ECO 還叫 Management。
• 治理跟生命週期幾乎一致。

§31 72 個 task / 170 道題的權重 (02:38:40)

核心: 72 個 task / 170 題 / 全英文 / 4 選 1 單選。Stakeholder Management 含金量最高，1 task ≈ 4 題；其他大多 1 task ≈ 2 題。

講師原話: 「只有相關方管理是含金量最高的，它的一個任務幾乎會有 4 道題目出現。」

§32 學習法：ECO 每句至少讀 5 遍 (02:42:00)

核心: 標準學「網絡」，ECO 學「句感」——每句任務描述至少讀 5 遍以上，越接近考試讀越多。

• 在做題時靠潛意識熟悉度判答。
• 「答案的描述方式很熟悉」→ 正確機率高。
• 講師接下來會逐個 task 解讀要點 + 考點提醒。

講師原話: 「ECO 裡邊的每一句話，你至少要讀到 5 遍以上，其實甚至都不夠。」

§33 進入 Strategic Program Management Domain：戰略 vs 收益 (02:43:30)

核心: SPM domain 的核心就一句話——「執行 program 是為了交付收益，從而達成組織戰略目標」。

• 戰略講收益必出現；收益講戰略必出現。
• 兩者關係：戰略 = 願景使命 → 細化成目的與目標；收益 = 完成這些目標的衡量。
• 戰略是起點 (early)，收益是終點 (closure 時拿出來對比)。

PMI 術語: Strategy ↔ Goals/Objectives ↔ Benefits ↔ 戰略 → 目的目標 → 收益

講師原話: 「戰略是我們最終要達到的結果，收益是我完成了它就可以達到這個尊重結果。」

§34 SPM 11 個 task 鳥瞰：6 個聚焦點 (02:46:30)

核心: SPM 的 11 個 task 環繞 6 件事：目標定義 / 路線圖 / 使命描述 / 組織能力評估 / 範圍與收益 / 環境驗證。

1. Define program objectives（保持與組織戰略一致）。
2. Establish high-level roadmap with milestones + preliminary estimate。
3. Define more detailed roadmap as program evolves。
4. Describe program mission；諮詢組織高層評估能力是否能達成目標（資源能力與目標匹配的驗證環節）。
5. Identify preliminary scope = preliminary benefits（高層收益、實現方式、時點）。
6. Estimate high-level financial + non-financial benefits。
7. 全方位評估目標：立法 / 環境 / 行業趨勢 / 組織結構。
8. Charter 批准 → program 啟動。
9. 組織內外整合 program activities + operational activities。
10. 越早讓接收方介入 → 越能維持收益。
11. 持續發現讓收益最大化的戰略機會。

PMI 術語: Tangible vs Intangible Benefits ↔ 有形 vs 無形（≈ financial vs non-financial）↔ 講師「tangible 和 intangible」

講師原話: 「組織領導對專案級的財務收益不太認同，問你該怎麼辦——你的可選的做法之一，就是向組織高層陳述非財務收益。」

§35 SPM Task 1 精讀：定義目標 = 驗證戰略一致性 (02:51:30)

核心: Task 1 看似冗長，核心思想就是「在定義目標的同時，驗證它是否符合組織戰略」。

• 透過明確 program objectives + needs + risks → 對 program 做初始評估。
• 目標跟戰略方向一致 → program 存在價值凸顯。
• 戰略計劃目標、願景使命、戰略陳述 → 籠統說「跟組織戰略保持一致」就涵蓋要點。
• 戰略本質：評定優先順序，用來分配資源。

講師原話: 「為什麼要做專案級的初始評估和定義它的目標呢？就在定義的過程當中發現它是否跟組織戰略一致，跟組織的目標是否一致。」

§36 SPM Task 2 精讀：High-level Roadmap 要被 Sponsor 批准 (02:54:40)

核心: Task 2 = 建立含里程碑與 preliminary estimate 的高層路線圖，獲得 executive sponsor 認可批准。

• Roadmap 兩個關鍵詞：圖形化 + 時間順序。
• Preliminary estimate 不是資源估算，而是對 里程碑節點與時間維度的高層評估。
• 標準沒強調 roadmap 要批准，ECO 強調——把它跟 Charter、BC 並列為「三件需要組織確認與批准」的東西。

PMI 術語: Program Roadmap ↔ 專案級路線圖 ↔ 講師「roadmap 路線圖」

講師原話: 「商業論證、章程跟路線圖，都需要組織的確認跟批准，那就可以了。」

§37 本集尾聲：定義階段「高層 → 細節」的演進 (02:56:35)

核心: 早期建立 high-level roadmap；隨時間推進，演進為更細緻的 roadmap 來設定 program 的定義。下一集從 task 3 接續。

• Establishment（建起來，高層）vs Define（找細節，相對更細，但對下一階段仍是高層）——這對詞要記住。

講師原話: 「establishment 把它建立起來，高層面的在那，但是細節可能不一定很清楚，而定義是要把細節找出來。」