Ch05 — 04 第4章 (230 min)

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

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

Part A 綜述

本段承接「第4章 專案級管理計劃」與「第7章 Program Lifecycle」之尾，正式進入 Section 7（生命週期 Delivery / Closure 階段）+ Section 8（Program Activity） 的核心。一句話定位：前面講「過程組+整合5活動」，這段開始把 Supporting Activity 10 大領域，依生命週期階段（Construct 構建 / Plan 規劃 / Delivery 交付）逐一拆解。

四條主線： 1. 專案級管理計劃 的 baseline 角色 + 11 子計劃（含路線圖、變更、配置） 2. 生命週期三階段 + 整合管理 5 活動 + Supporting 10 領域 的對應關係 3. 構建子階段四個 Initial Assessment（Cost / Resource / Risk / Scope），全部為了支撐 Business Case + Charter 獲准 4. 規劃子階段與交付階段的細化（Financial Framework、Risk Plan、Schedule Plan、Scope Plan、Financial M&C）

兩個會考鐵則先記： - 風險題首選 Risk Management Plan（不是 Risk Register） - Project Charter 不在 Integration 5 活動裡，而在 Strategic Alignment / Definition Phase

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

§1 收益管理計劃也是 baseline (08:03:45)

核心: 收益管理計劃（Benefit Mgmt Plan）跟財務管理計劃一樣，都是獨立的 baseline 文件，不被合併進專案級管理計劃裡。

• 兩個獨立 baseline：Benefit Mgmt Plan、Financial Mgmt Plan
• 講師承認：「這個標準當中還有一些不盡完美的地方」——獨立卻又重疊
• 帶出今天要講的「專案級管理計劃」結構

講師原話: 「收益管理計劃，它也是獨立的一個 baseline，除了它之外，還有一個叫專案級的財務管理計劃。」

§2 專案級管理計劃的三大主構件 (08:04:25)

核心: 專案級管理計劃的組成只是「幫助理解」不需記憶——三大塊分別對應收益績效域、相關方績效域、治理績效域。

• 效益管理計劃 ↔ 收益管理績效域
• 相關方爭取計劃 ↔ 相關方參與績效域
• 治理計劃 ↔ 治理績效域
• 缺的那個績效域是 戰略一致性 → 它沒獨立計劃，內容放在 Program Charter 專案級章程

PMI 術語: Benefits Management Plan ↔ 效益管理計劃；Stakeholder Engagement Plan ↔ 相關方爭取計劃；Governance Plan ↔ 治理計劃；Program Charter ↔ 專案級章程

講師原話: 「戰略一致性的戰略計劃……是沒有這個獨立的東西。它在哪呢？它在我們的專案級章程當中。」

§3 八大支援領域 + 一個資訊管理 (08:05:00)

核心: 範圍/進度/成本/質量/資源/溝通/風險/採購這 8 項熟悉的——成本升格成「財務」、相關方升格成「績效域」、溝通領域多了「資訊管理」。

• 九大知識領域（PMP）→ 對應到 PgMP 的 supporting：除「整合」「相關方」外
• 範圍、進度、財務（升格自 Cost）、質量、資源、溝通、風險、採購
• 多一個：資訊管理（在 PMP 裡是合併在 Communication 內，PgMP 把它拆出來）
• Communication ≠ Information，是兩個獨立 supporting activity

PMI 術語: Cost Management → Program Financial Management（升格）；Communication 拆成 Communication Management + Information Management

§4 兩個獨特子計劃：變更 + 配置 (08:05:50)

核心: 除前面那些子計劃外，PgMP 還獨立列出 變更管理計劃 與 配置管理計劃 兩個獨立 plan（PMP 也有這兩個）。

• Change Management Plan：獨立計劃
• Configuration Management Plan：獨立計劃
• 在 PMP 已存在，PgMP 只是繼續沿用
• 不算特別之處，但要列入專案級管理計劃的成份清單

§5 最特別：Program Roadmap 也納入專案級管理計劃 (08:06:15)

核心: 路線圖會讓人混淆——它本來是宏觀層面的獨立檔案，但在這個版本裡也被「安插」進專案級管理計劃裡，跟進度計劃高度重疊。

• 標準確實在概念與名字上有交叉使用
• 講師建議的理解：這裡的 Roadmap 是「整體的、最高層級的進展」
• 它可作為獨立檔案，也可納入專案級管理計劃
• 講師傾向：把 Roadmap 獨立成「整個專案級層面的最高階檔案那一組」
• 與 進度計劃 Schedule 重疊度很高
• 題目穩定答案：「專案級路線圖在何處構建？」 → 構建子階段（Construct sub-phase）

講師原話: 「但如果問你專案級路線圖是在什麼地方構建，我們的答案應該還是在我們的那個構建子階段，這是一個最穩定的答案。」

§6 不要硬背組成、理解含義就好 (08:07:32)

核心: 講師的學習建議——不要把專案級管理計劃當成「特別精準的支點」去背，理解它的含義就行了。

• 它涉及 PgM 全方面：範圍/進度/成本/質量/資源/溝通/風險/採購/相關方/收益/治理/變更/路線圖等等
• 知道「它涵蓋方方面面」即可，避免細節糾結
• 形成這個計劃的核心輸入要記：戰略計劃、商業論證、專案級章程

PMI 術語: Strategic Plan / Business Case / Program Charter 三個輸入是必記的

§7 計劃必須由 Steering Committee 批准 + 動態更新 (08:08:32)

核心: 專案級管理計劃不是寫一次就定案——它需要 定期更新，且因「很重要」必須由 Program Steering Committee 批准。

• 把前面所有規劃工作 進一步闡述和彙總
• 不是一成不變，要隨環境變化定期更新與重新整理
• 批准權：Program Steering Committee（不是 Sponsor、不是 Program Manager 自己）

PMI 術語: Program Steering Committee ↔ 專案級指導委員會（批准方）

§8 進入 Delivery 階段：站高處看專案組合 (08:09:07)

核心: 專案級交付階段（Program Delivery Phase）= 站在更高處看一群專案的「啟動/規劃/執行/監控/收尾」起點與終點各不相同、陸續加入。

• 底下每個專案都有自己的五大過程組
• 起點各不相同，結束點也各不相同
• 有的元件還在啟動，有的已在執行，甚至有的已收尾
• 細節全部在 PMBOK 裡講過，這裡只在「高層面」看

PMI 術語: Program Delivery Phase ↔ 專案級交付階段

§9 Delivery 階段的 4 個動作 (08:09:50)

核心: 站在 Program 角度，Delivery 階段四件事：授權元件 → 規劃元件 → 監督監控（Oversight & Integration）→ 整合可交付物為收益 → 結束時監督移交與關閉。

• 元件需要被 授權 (authorized)
• 元件需要被 規劃 (planned)
• 定義好元件結構與關係
• 進入執行後 Program 做 Oversight and Integration
• 整合各專案產生的可交付成果 → 形成 Program 收益
• 結束時監督專案的移交（主要是可交付成果的移交）與專案的結束
• 所有專案結束後 Program 才能進入收尾

§10 「Full suit of components may not be known」鐵律 (08:11:21)

核心: 進入 Delivery 階段時，並不代表所有元件都齊全——元件會在過程中陸續 add / update / edit / terminate。這句話既適用於 Definition Phase，也適用於 Delivery Phase。

• the full suit of program components may not be known in program definition phase
• 同樣的邏輯：在 Delivery Phase 一開始也未必全部已知
• 不可能等所有事情都具備了才開始
• Program 是一個 不斷反覆 (iterative) 的過程
• 元件操作四動作：add / update / edit / terminate

PMI 術語: the full suit of program components may not be known 是標準原文要記

講師原話: 「the program delivery phase, the full suit of program components, may not be known——這句話也依然成立。」

§11 Closure 階段：In a Controlled Manner (08:13:00)

核心: Closure 階段的存在意義是 避免 program 草草收尾——強迫在 a controlled manner 下完成 benefit transition + formal close。

• 過去版本 Closure 分兩個子階段：移交 + 關閉
• 本版合併為一個 Closure Phase（但實質還是這兩個動作）
• 標準原句："Transition program benefit to sustaining organization and formally close the program in a controlled manner"
• 沒有顯形化階段時，program 容易「隨事情進展慢慢結束」沒有明確終結
• Closure 強制存在 = 為了 visible、controlled 的關閉

PMI 術語: Benefit Transition / Formal Closure / Sustaining Organization（接收方）

講師原話: 「In a controlled manner to close the program——他想起到這樣的一個作用。」

§12 Closure 要做的具體事 (08:14:11)

核心: 收尾階段不只是「停掉」——要 把收益移交給接收方 + 跟接收方說明怎麼用 + 提供培訓 + 後期支援。

• 把收益移交到接收方
• 跟接收方說明怎麼去做
• 提供培訓
• 後期還要 提供支援（這些都要在收尾階段考慮清楚）

§13 Program Integration Management 的定位 (08:14:33)

核心: 標準把整合管理拉出來單獨講（其他放第八章），對應的就是 PMP 整合知識領域——把分領域過程統合起來，本質一樣。

• PMBOK 整合知識領域包含「將分領域過程統合」的過程
• PgMP Integration Management 把專案級其他領域（範圍/進度/成本/質量/資源/溝通/採購/相關方/收益/變更/治理）統合起來
• 講師承認：「它的涵蓋面不夠廣泛和全面」「給學習者帶來一定難度」
• 一個高階學習者應該接受並了解背後意思

§14 為什麼整合管理「值得商榷」(08:15:50)

核心: 講師客觀指出標準缺陷——整合管理第一個過程是「建立基礎設施」不是 Charter，因為 Charter 被放到 Strategic Alignment / Definition Phase 去了。

• PMP 印象：整合管理應該從 章程 開始
• 但 Program Charter 放在 戰略一致性的 Definition Phase
• 所以 Integration 從 Program Infrastructure Development 起步
• 這帶來理解上的難度，但「標準在演進，後續一定會改進」

§15 Program Activity vs Component Activity 分層 (08:16:46)

核心: Program Activity = 專案級經理及其團隊做的事，主要為了 support 專案經理；Component Activity = 專案經理在元件上開展的具體活動——它們是支援關係，不是干預關係。

• Program Activity → 支援 Component Activity
• Project Manager 完成具體工作 → 達成 program 目標
• 「Program Manager 不過多干預 Project Manager 的工作」
• 互動最多在哪？啟動和規劃時 Program Manager 參與多
• 執行/監控時 PgM 不干預，由 PM 正常彙報；只有需要升級的問題才上來
• 主體工作 → PM 完成；PgM 做 協調差異與依賴關係

PMI 術語: Program Activity ↔ Project (Component) Activity；分層概念是核心

講師原話: 「專案經理乾的都是具體的工作，而專案級經理是管理專案經理做具體的工作。他的管理要產生增量的收益，否則他的價值就不存在了。」

§16 增量收益 = PgM 存在的合理性 (08:18:50)

核心: 假如沒有 PgM，PM 還能做得更好，那 PgM 就 沒有存在的基礎——所以 PgM 必須產生「協調帶來的增量收益」。

• 假設前提：PgM 管理的專案之間有 內在聯繫
• PM 站在自己角度可能不關注那些內在聯繫
• PgM 必須協調差異
• 例：交付日期臨近、團隊還在爭吵細節時，有人來協調衝突 + 做取捨 + 排優先順序
• 取捨的目標：保證收益最大化
• 收益最大化 → 戰略有效落實 → 組織未來願景達成

§17 Interdependent and Complementary 兩個關鍵詞 (08:20:23)

核心: PMI 用「program activities are interdependent and complementary」描述各 Program activity 的關係——翻譯成中文就是 相輔相成。

• Interdependent：相互依賴
• Complementary：互補（你那兒沒有、我這兒有）
• 互補後 + 讓彼此工作做得更好 = 五個英文字的含義

PMI 術語: interdependent and complementary 是標準用詞

§18 Integration Management 的 5 個核心活動清單 (08:20:50)

核心: PgMP Integration Management 列出 5 個 Core Activity，記住這 5 個就掌握了 Program Integration 的骨架。

1. Program Infrastructure Development 專案級基礎設施的制定/建立
2. Program Delivery Management 專案級的交付管理
3. Program Performance Monitoring and Controlling 專案級的績效監控
4. Benefit Sustainment & Program Transition 收益的維持與專案級的移交
5. Program Closure 專案級的關閉

PMI 術語: 這 5 個英文要會背 → 對應到 Lifecycle 也容易記（1=Definition、2-3=Delivery、4-5=Closure）

§19 Delivery Management 容易跟 Delivery Phase 混淆 (08:21:09)

核心: Delivery Phase = 階段名稱（框架性）；Delivery Management = 具體要交付的事（管理活動）——是兩個層次的東西。

• Delivery Phase 階段對應做兩件事：
• Delivery Management（執行）
• Performance Monitoring and Controlling（監控）
• 對應五大過程組：一個是執行、一個是監控
• Delivery Management 關心：元件啟動、關閉、移交、變更怎麼處理
• Performance M&C 關心：執行偏差、報告

§20 Benefit Sustainment & Transition 順序顛倒？ (08:22:07)

核心: 名字「先 Sustainment 後 Transition」順序有點怪——應該是 先移交再維持，但因為這部分關注的是 program 收尾要做的事，講師說「這裡確實存在問題」。

• 正常邏輯：先移交（Transition）→ 再維持（Sustainment）
• 標準把 Sustainment 放前面
• 講師：「這部分其實關注的是專案級收尾的時候要做的事」
• 對於 PMP 移交是「可交付成果」；對於 PgMP 移交是 收益
• Benefit Transition 出現在這 = 收益跟可交付成果一個改進的地方就在於它提出了「可維持」的概念

§21 Closure = Final Report 把過程梳理出來 (08:23:30)

核心: Closure 過程 ≠ 簡單關門——它是 整個 program 的最終報告，要回顧整個專案過程。

• Closure 的核心動作：梳理並產出最終報告
• 回顧整個專案的過程
• 是 Integration 的第 5 個 Core Activity

§22 Infrastructure 三件事：Core Team / PMO / PMIS (08:23:49)

核心: 第一個 Core Activity「Program Infrastructure Development」涵蓋三項：Program Core Management Team、PMO、Program MIS——對 PgM 管理整個 program 起非常大作用。

1. Program 管理核心團隊
2. PMO 建立

3. Program Information Management System (PMIS)

4. Infrastructure 不是基建那種——指的是 管理團隊結構 + PMO + 可用系統工具

5. PMIS 不僅指 IT 系統，也包括 手動的、由文件規則制度構成的體系

PMI 術語: Program Core Management Team、PMO、PMIS 三件套

§23 細節知識點：PgM 何時被任命 vs Infrastructure 何時建 (08:26:18)

核心: PgM 是在「構建子階段（Construct）」任命；而 Program Core Mgmt Team + PMO + PMIS 屬於 Infrastructure，建立在「規劃子階段（Plan）」——兩者都在 Definition Phase 內，但子階段不同！

• Program Manager → Construct sub-phase 任命
• Program Core Management Team / PMO / PMIS → Plan sub-phase 建立（屬 Infrastructure 過程）
• 都歸屬於 Program Definition Phase

講師原話: 「專案級經理是在構建階段任命的，而我們的專案級管理核心團隊，是在……專案基礎設施建設那個過程裡面。」

§24 PMIS 包含的工具清單 (08:28:00)

核心: PMIS 的範疇舉例——軟體工具、配置管理、變更管理工具、組織知識庫、風險資料庫、財務管理系統等等，只要是 IT 工具能解決的範疇都屬於 Infrastructure。

• 軟體工具
• 配置管理 / 變更管理工具
• 組織知識庫
• 風險資料庫
• 財務管理系統

§25 Program Delivery Management 細節：Proposer 角色 (08:26:17)

核心: PgM 在 Delivery Management 裡的角色叫 Proposer（提出建議的那個人）——他來提出元件啟動/關閉/移交/變更的申請。

• PgM = proposer
• 提出申請：啟動元件、關閉/移交元件、變更請求
• 申請後判斷：在 PgM 授權範圍內 → 自己決定；超過授權 → 交給 Steering Committee

PMI 術語: proposer 是 PgM 在 Delivery Management 的特定角色

§26 元件啟動/關閉必須更新 Roadmap (08:27:54)

核心: PgM 落實元件啟動/關閉/移交時，必須更新 Program Roadmap——因為 Roadmap 定義了 component structure。

• Roadmap 定義 Component Structure
• 收益管理定義 Architecture
• 元件的啟動跟結束 → 更新到 Roadmap

PMI 術語: Component Structure（在 Roadmap）↔ Architecture（在收益管理）區別要清楚

§27 Performance Monitoring & Controlling 三個重點 (08:28:33)

核心: 第三個 Core Activity「Performance M&C」做的是 比較執行偏差 + 提糾正/預防措施——也由 PgM 提，授權內自己做、超過交 Steering。

• 比較執行偏差、看績效
• 偏差大 → 提 Corrective Action / Preventive Action / Adaptive Change
• 在 PgM 授權內 → 直接給結論執行
• 超過授權 → 交 Steering Committee → 也是再交回 PgM 落實

PMI 術語: Corrective Action Preventive Action Adaptive Change

§28 Adaptive Change ≠ Corrective/Preventive (08:29:28)

核心: Corrective/Preventive 是「跟計劃比較」；Adaptive Change 是「計劃裡本來沒有，但發現這樣調整更有意義」——這是 PgM 跟 PM 不一樣的地方：PgM 可以主動追求變更。

• Corrective / Preventive：基於計劃 → 比較 → 糾正或預防
• Adaptive Change：計劃裡沒有，主動發起調整
• PgM 不一樣的地方：他可以主動追求變更
• 兩個原則（其實是一個）：戰略一致性 + 收益最大化
• 因為「收益和戰略其實是一回事」——戰略佔層面高，收益是具體層面

講師原話: 「我們專案級管理跟專案管理不一樣的地方在哪呢？他可以主動追求變更。只要有一個原則就是戰略一致性和收益最大化。」

§29 Performance Report and Forecast 必出題 (08:30:34)

核心: Performance M&C 輸出兩樣：Performance Report（過去與當前）+ Forecast（對未來的判斷）——「考察的時候經常出現」。

• Performance Report：描述當前和過去狀態的偏差
• Forecast：對未來走向的判斷
• 講師強調：「考察的時候經常出現」

PMI 術語: Performance Report and Forecast 同時要會說

講師原話: 「在專案級處理整個專案級的監控、績效監控的時候，他要輸出一個報告一個預測。」

§30 Benefit Sustainment 主體是接收方 (08:31:32)

核心: 第四個 Core Activity「Benefit Sustainment」的主體 是接收方（Sustaining Organization），PgM 只是提供 support，不是替接收方維持。

• 收益維持的主體 = 接收方
• 收益維持已超過專案的 lifecycle、超過 PM 的責任
• 但在 PgM 與 program 管理職責內 → 做 支援工作
• PgM 不替接收方做維持，只支援
• 標準原文：This activity transcends the scope of individual program component, but this work is performed as a program is closed.

PMI 術語: Maintenance and Operations（M&O，接收方）；transcend the scope of individual program component

§31 收益移交給 M&O (08:34:17)

核心: Benefit Transition 的接收對象就是 Maintenance and Operations——日常運營/維護組織。

• benefit transition → 交給 maintenance and operations
• 是 program closure 的一部分

§32 Program Closure：資源 appropriately released (08:37:57)

核心: 第五個 Core Activity「Program Closure」的鐵句：Program resources are appropriately released——關鍵字 appropriately，不是 all！

• 不是絕對的把所有團隊成員全部釋放
• 對維持收益有支援責任的那些人 → 要保留
• 用詞 appropriately released 而不是 all released
• 經驗教訓 / 知識移交 / 經驗教訓登記冊留存 → 也在 Closure 完成

PMI 術語: program resources are appropriately released 標準原句要會背

講師原話: 「並不是絕對的將所有團隊成員全部都釋放。如果對維持收益有支援責任的那些人是要保留的。所以他用的詞叫 appropriately released。」

§33 保留的人也是「臨時」保留 (08:39:37)

核心: 為了 support 接收方而保留的少量團隊成員，也只是暫時保留——支援期（3 / 5 / 10 年）結束後也要釋放。所有收益維持的責任最終都交給接收方。

• 大部分資源還是要釋放（組織要拿去做更重要的事）
• 少數跟收益維持支援活動有關 → 保留
• 保留也是 臨時：支援期結束就釋放
• 所有 Sustainment 責任最終都歸 接收方

§34 Core Activity vs Supporting Activity 分類 (08:41:23)

核心: 整張總圖的精髓——剛講完的 Integration 5 活動 = Core Activity；其他列出的所有領域 = Supporting Activity。PgM 主要關注 Core，Supporting 由 program 管理團隊幫他做。

• Core Activity (5)：Integration 那 5 個（PgM 關注）
• Supporting Activity (10 領域)：其他所有
• Supporting Activity 的執行人：Program 管理團隊
• Supporting Activity 所處位置：輔助（輔助 Integration 5 活動 + 輔助所有績效域）

PMI 術語: Core Activity ↔ Supporting Activity 分類要會

講師原話: 「整合管理的處於核心的活動，就專案級經理你主要要關注的事；而其他的這些活動是交給專案級管理團隊幫你去做的，所以它叫 Supporting Activity。」

§35 Financial Management 跨多個績效域 (08:42:13)

核心: 用 Financial Management 為例說明 Supporting Activity 的跨域影響——Cost vs Financial 區別很大：Cost 只關心花錢，Financial 還關心錢從哪來、要彙報、要符合監管。

• PMP 用 Cost Management
• PgMP 升格成 Financial Management
• Financial 涵蓋面更大：投入比、報告、彙報、跟治理/相關方/收益管理都有關
• Financial 跨 Definition / Delivery / Closure 三階段

PMI 術語: Cost Management (PMP) ↔ Program Financial Management (PgMP) 升格

§36 Section 8 開始：Program Activities 詳解 (08:44:10)

核心: 進入第八章，依生命週期三階段（Definition / Delivery / Closure）逐一拆解 Supporting Activity 的重點。

• 第八章分三節：Definition / Delivery / Closure 階段的活動
• 重點放在 與 PMP 有明顯差異 的內容
• Definition 階段內容最多（含 Construct + Plan 兩個子階段）

§37 10 個 Supporting 領域按字母順序排列 (08:46:59)

核心: PgMP 標準裡 10 個 supporting 領域的英文版是按 字母順序排（去掉 program 那個字後排）：Change → Communication → Financial → Information → Procurement → Quality → Resource → Risk → Schedule → Scope。

• 排序方法：去掉 program → 按 a-z
• 跟 PMP 閱讀習慣不同
• 講師建議：可按自己喜歡順序讀（範圍 → 進度 → 財務 → 質量…）
• 它們之間連線關係不明顯，可獨立解讀
• 加上「整合 Integration」共 11 個方面

§38 Definition 階段目的：建立 Business Case + 細化 Plan (08:48:25)

核心: Definition Phase（含 Construct + Plan 兩子階段）的兩大目的——建立並確認 Business Case + 制定詳細計劃用於 program 收益交付。

• 建立並確認 Business Case 的權威地位
• 進一步細化制定文件
• 從粗到細：Business Case → Program Charter → Program Roadmap → Program Management Plan
• 講師：Charter 跟 Roadmap 屬於同一層面的高階檔案

§39 Construct 子階段四大初始評估總覽 (08:53:38)

核心: Construct 子階段裡，會考的 4 個 supporting 過程是 4 個初始評估： 1. Initial Cost Estimation 初始成本估算 2. Resource Requirement Estimation 資源需求估算 3. Initial Risk Assessment 初始風險評估 4. Program Scope Assessment 範圍初始評估

• 這四個都是「比較粗的」估算
• 都是為了支撐 Business Case + Charter 獲准
• 詞性差異：用 Assessment（不強調量化、可主觀判斷）vs Estimation（要量化）
• 例：cost / resource → estimation（可量化）
• risk / scope → assessment（較難量化）

PMI 術語: Estimation vs Assessment vs Estimate（estimate=結果、estimation=動作）

§40 ROM Rough Order Magnitude (08:56:59)

核心: 初始成本估算用 ROM（Rough Order Magnitude）級別——粗略級。對應 PMBOK 三級精準度：ROM / Budget / Definitive。

• 三級準確度：粗略量級 / 預算級 / 精確級
• ROM 範圍大約 -25% 到 +75% 之間（PMBOK 數值）
• 此階段不需要特別準確
• 知道 ROM = 比較粗的就夠

PMI 術語: Rough Order Magnitude (ROM) / Budget Estimate / Definitive Estimate

§41 Initial Cost Estimation 是 Business Case 的 critical element (08:59:00)

核心: 標準原文 it's a critical element of benefits of a business case——初始成本估算是 Business Case 最核心內容之一（投入多少、回收多少）。

• Business Case 最關鍵：投入多少 + 回收多少
• 初始成本估算的輸出 → 餵給 Business Case
• 後續還會接著做 Detailed Program Cost Estimation

PMI 術語: critical element of benefits of a business case 標準原文

§42 Resource Requirement Estimation 重點：人 + 設施 (09:00:11)

核心: 第二個初始評估——資源需求估算。最關鍵的兩類資源：Staff（人）+ Facilities（設施）。

• 跟「資金」分離 → 在這指的是 人 / 設備 / 基礎設施投入
• 早做的核心原因：人和設施箝制性很強，需要長時間準備
• 沒早估 → program 一旦批准會非常被動
• 影響 Business Case 的合理性與高層認同
• 也跟 採購管理 有互動

PMI 術語: staff and facilities 是兩類資源代表詞

§43 Initial Risk Assessment 在哪做：Construct 子階段 (09:02:13)

核心: 第三個 Initial Assessment——初始風險評估在 Construct 子階段執行。「考察的時候經常出現問題：是在什麼時候做的」。

• 執行時點 = Construct sub-phase
• 講師強調過很多次：「跟大家提到過，務必要特別清楚」
• 講師再強調：「跟大家說，專案級的初始風險評估在什麼時候做和執行，務必要特別清楚」
• 目的：把風險的情況客觀描述出來、為 Business Case + Charter 提供依據

講師原話: 「我跟大家說，專案級的初始風險評估，在什麼時候做和執行，務必要特別清楚。」

§44 Program 風險來源最多的是「內在依賴」(09:04:00)

核心: Program 風險與 Project 風險不同——來源、複雜度、不確定性更高。最直接的來源是「program 內部構成要素之間的依賴關係」。

• 來源可能：外部環境、技術複雜性、組織變動
• 最直接的來源 = program 內部構成要素間的依賴關係
• 依賴關係本身就帶來大量不確定性
• 互動關係也會隨 program 推進改變

§45 風險二要素 + 組織 Risk Appetite (09:05:30)

核心: 識別關鍵風險時要考慮 可能性 + 影響（風險二要素 = Probability + Impact），重大風險還要考慮組織的 Risk Appetite（風險偏好）。

• 風險二要素：Probability（可能性 / 機率）+ Impact（影響）
• 重大風險 → 考慮 組織風險偏好
• 發起組織、投資組織、接收組織各有偏好
• 風險偏好 → 影響 Business Case 是否被批准
• 風險描述差，可能遭 Steering Committee 拒絕或猶豫

PMI 術語: Probability Impact Risk Appetite

§46 範圍與成本的關係 + 範圍最影響成本 (09:08:00)

核心: Program Scope Assessment 跟前三個的關鍵差別——它對成本影響最大，因為 Business Case 要論證經濟可行性，成本是核心要素。

• 對成本影響很大（也對資源、進度影響大）
• 進度影響可體現在 Roadmap
• 成本影響 → 直接決定 Business Case 經濟可行性

§47 Program Scope = 用 Benefit 描述的工作 (09:09:00)

核心: Program Scope 通常用 expected benefits 的方式表達——這跟 Project Scope 用「工作內容」表達不同。它們是互補關係。

• Program Scope = work required to deliver a benefit at the program
• 用 收益 / objective 描述要實現的結果
• 工作內容部分：要支援 program 達到結果的事
• 兩者 = 互補關係

PMI 術語: work required to deliver a benefit / expected benefit

§48 Program Scope Assessment 5 個對照影響 (09:10:00)

核心: 標準明列 Program Scope Assessment 的 5 個 support：support initial cost, change, resource, risk, and schedule assessment——但講師強調 這些初始評估彼此非線性、誰先誰後不重要。

• Scope assessment 影響：cost / change / resource / risk / schedule 全部
• 不是線性關係，沒有絕對的先後順序
• 大家都互相影響、可從任何一個切入
• 例如：風險對進度有影響、進度對風險也有影響
• 不要糾結誰先誰後

講師原話: 「他們之間其實本來就是互相影響的一種關係……所以大家不用糾結，它到底是誰在先誰在後。」

§49 Program Scope Statement 在 Construct 末已雛形 (09:11:17)

核心: Construct 子階段的 Scope Assessment 結果 → 充實 Program Charter 的「scope」一項。Charter 要交給 Program Governance 層稽核批准。

• 輸出：Program Scope Statement 雛形
• 充實 Program Charter 的 scope 欄位
• 對 Business Case 也有影響
• 標準在這特別強調 Charter

PMI 術語: Program Scope Statement ↔ Project Scope Statement 但層面更高

§50 進入 Plan 子階段：4 個面向 6 個過程 (09:12:33)

核心: Plan 子階段比 Construct 更豐富——講師挑出 4 大面向、共 6 個過程：Financial（3）/ Risk（1）/ Schedule（1）/ Scope（1）。

• 規劃子階段 = 漸進明細，將細節呈現
• Business Case + Charter 變成 Plan 子階段的輸入
• 4 大面向：
• Financial 財務 → 3 個過程
• Risk 風險 → 1 個過程
• Schedule 進度 → 1 個過程
• Scope 範圍 → 1 個過程

§51 Financial Management 三過程概覽 (09:16:46)

核心: Plan 子階段的 Financial 有 3 個過程： 1. Program Cost Estimation（去掉「初始」→ 變更細緻） 2. Program Financial Framework Establishment（資金從哪裡來） 3. Program Financial Management Planning（細化成 baseline）

• 1 比初始更細緻
• 2 → 框架，回答 funding 從何來
• 3 → 細化框架成 management plan
• Financial Framework 不屬於 Program Mgmt Plan，是獨立檔案
• Program Financial Management Plan 屬於 Program Mgmt Plan 的一部分

PMI 術語: Program Financial Framework ≠ Program Financial Management Plan 兩個獨立文件

§52 Tiered Funding Process + Go/No-Go Decision (09:20:12)

核心: Program 的 funding 是 a tiered funding process with a series of go and no-go decision at each major stage——一筆一筆階梯狀注入，每階段有 go/no-go 評審。

• Tiered = 階梯狀：一筆投入 → 用一段時間 → 再來一筆
• 每個 major stage 結束 → Phase Gate Review → Go/No-Go Decision
• 即使資金充裕也要分批，因為要評估「program 是否還值得做下去」
• 過去 performance 好 ≠ 未來繼續做（戰略可能調整）
• 連結回 Governance 那張 Phase Gate Review 圖

PMI 術語: Tiered Funding Process / Go and No-Go Decision / Phase Gate Review

講師原話: 「a tiered funding process, with a series of go and no-go decision at each major stage」

§53 Funding Structure 反映 Financial Environment (09:26:10)

核心: Funding Structure 不是只列出資金來源——它 反映了當下的 Financial Environment，因為資金的可用性受外部金融環境影響。

• 資金來源：自有 / 社會 / 政府 / 股東 / 投資方
• Funding structure decided the financial environment for the duration of the program
• 例：銀行貸款在某些時段充裕、某些時段收緊
• 講師區別：
• 籌資 = 全口徑（含現金、母公司投入、銀行貸款）
• 融資 = 籌資的子集（銀行貸款）
• 自有資金不能叫融資

PMI 術語: Funding Structure Financial Environment

§54 Financial Framework 描述 Funding Flows (09:27:35)

核心: 標準原文 Financial framework defines and describes funding flows——關鍵字 flows：資金流入 + 流出，要平衡。

• flows = 流入 + 流出 完整流動
• 流出多、來源少 → 斷流（嚴重）
• 流入多、用得慢 → 浪費（也麻煩）
• 對組織資金佔用情況非常龐大
• 要達 流入 / 流出平衡

PMI 術語: funding flows、Financial Framework 的核心訴求

§55 Framework 應該很早就建 (09:30:12)

核心: 雖然講課順序是「Cost Estimation → Financial Framework」，但 Financial Framework 實際上應該在更早期就介入——「沒有資金來源，事情連啟動的基本前提都沒有」。

• 講解順序 ≠ 實際順序
• Framework 是 high-level initial plan
• 早做才能讓 framework 可行可信
• 講師建議：把這個過程的「思考時點」往前移

§56 Business Case Updates + Funds Updates 觸發 (09:31:27)

核心: 完成 Financial Framework 分析後，可能回頭觸發 Business Case Updates + 連鎖更新（含相關方、風險、質量、範圍、進度）——因為資金影響面特別廣。

• Framework 輸出 → 可能改變 Business Case 條件 → Business Case Updates
• Funds Updates 連帶觸發：
• Stakeholder Engagement Plan（投資方變相關方角色）
• 溝通策略
• 風險、質量、範圍、進度也可能受影響
• 為什麼相關方？投資方 ≠ 普通相關方，需要 量身定製 (crafted) 的爭取策略

PMI 術語: Business Case Updates Funds Updates crafted strategy

§57 Program Financial Management Plan 5 大成份 (09:32:54)

核心: Plan 把 Framework 細化，包含： 1. Program Funding Schedule 籌資進度 2. Component Payment Schedule 元件支付進度 3. Operation Cost 運營成本 4. Program Financial Metrics 財務管理指標 5. Initial Budget、Contract Payments、Reporting Activity 等

• Funding Schedule = 出資方何時注資、要協商
• Component Payment Schedule = program 撥付給元件 / 專案的支付時間
• Operation Cost = program 自身運營（辦公場地 / 管理人員工資福利）
• Reporting Activity = 受嚴格監管，要按規定時間 / 格式提交（尤其上市公司）

PMI 術語: Funding Schedule / Payment Schedule / Financial Metrics / Initial Budget

§58 Financial Metrics = Plan 的最關鍵內容 (09:35:18)

核心: Financial Metrics 是 Program Financial Mgmt Plan 最關鍵的一點——用來 measure program benefit，回報必須高於投入，否則 program 績效難看。

• 用來 measure program benefit
• Benefit = 投入資金帶來的回報
• 回報必須 高於 投入
• 過程中可能成本 > 收益（前期）
• 到 收益維持階段 一定要達到收支平衡甚至大幅超出

PMI 術語: Program Financial Metrics

§59 Budget vs Cost 差異 (09:36:01)

核心: Cost = 總數估算結果；Budget = Cost 經批准 + 放到時間維度上。Budget 更嚴格、嚴肅，經過批准確認 才能成為 Budget。

• Cost = 評估結論、總數
• Budget = 經批准 + 時間維度展開
• 「什麼時間花的錢、什麼時間要花多少錢」 = Budget
• Budget 嚴格度 > Cost
• Cost → 批准 → Budget

PMI 術語: Cost ↔ Budget 區別

§60 Program Mgmt Plan = Baseline Document (09:38:00)

核心: Program Financial Mgmt Plan 屬於 baseline document——執行過程中要 不斷被引用、當成標準 衡量實際執行。

• Baseline = 標準
• 標準必須存在 → 文件才發揮作用
• 實際支出 vs 計劃 → 高度吻合 → 風險小
• 偏差大 → 風險大

PMI 術語: Baseline Document

§61 Risk Management Planning：規劃 ≠ 執行 (09:40:49)

核心: 第二大面向 Risk Management Planning（基於前面 Initial Risk Assessment）——主要描述 how risk management activities will be structured and performed：結構 + 執行責任 + 分工。

• 描述風險管理活動的 結構 + 執行 + 責任分工
• 跟專案層面風險管理沒大區別，只是層面更高
• Program 只制定 原則 + 處理超過閾值的風險
• 沒超過 risk threshold → 在元件層面處理
• 超過 threshold → 升級到 Program 層面

PMI 術語: Risk Threshold 閾值

§62 Risk Management Plan 包含「風險本身的時間 + 資源」(09:41:30)

核心: 標準原文 identify the resource and the time required for risk management activity——意思是 風險管理本身需要消耗的時間和資源（時間儲備、資金儲備）也要納入。

• 翻譯白話：為風險管理本身預留資源 + 時間
• 若早期就規劃 → 後期應對更從容
• should be conducted early in the program definition phase

§63 PgMP 認證題：選 Risk Management Plan 不是 Risk Register (09:43:20)

核心: PgMP 風險題 大量證明 → 想找風險登記冊裡的內容時，在 program 層面 應優先選 Risk Management Plan，而非 Risk Register——「正確機率比較高」。

• 風險題 → 首選 Risk Management Plan
• 不要選 Risk Register
• 「優先選擇風險管理計劃，正確機率是比較高的」
• 仍需具體情景判斷

講師原話: 「在認證測試的時候，其實很多的情況下都證明，優先選擇風險管理計劃，正確機率是比較高的。」

§64 Risk Mgmt Planning 5 步驟回顧 (09:44:00)

核心: Program 風險管理規劃流程：識別 → 記錄 → 分析 → 對每個 / 每類風險給應對計劃或策略。

• 識別 (Identify)
• 記錄 (Record)
• 分析 (Analyze)
• 應對計劃 / 策略 (Response Plan / Strategy)

§65 Schedule Management Planning：分到元件 (09:44:33)

核心: Program Schedule Mgmt Planning 主要 determine the order and the timing of the components——只規劃到 專案 / 元件層面，不再向下分解。

• 規劃元件 / 專案的 執行順序 + 時機
• 在 program 角度，每個專案 = 一個節點（一個開始一個結束）
• 在專案層面，看的是一個個 Activity
• Activity 在 PgM 層 vs PM 層意義不同
• Program Activity = 我們講的這幾個 supporting 過程
• Project Activity = 真正的具體動作

PMI 術語: Order and timing of components 標準原句

§66 PWBS 分到第二層就停 (09:47:17)

核心: PWBS（Program WBS）只分解到「專案的下一級」，最多到第二層——再向下會干擾專案經理工作。

• WBS（PMP）→ 專案內細到活動
• PWBS（PgMP）→ 只到 Component 層 / 第二層
• 再向下分解 → 干擾 PM 工作
• Work decomposition into deliverable component
• 元件用來交付收益

PMI 術語: PWBS (Program Work Breakdown Structure)

講師原話: 「只分解到元件層面的，最多到第二層，不能再向下分解。如果再向下分解，那就干擾了專案經理的工作。」

§67 Schedule Plan 輸出兩個文件 (09:48:03)

核心: 規劃輸出兩個東西：Program Schedule Management Plan（怎麼管）+ Master Schedule（具體進度）。

• Schedule Management Plan = 怎麼管理進度
• Master Schedule = 具體進度安排
• 規劃進度時要考慮 風險因素 + Roadmap 內容（是否更新）
• 一般是 Roadmap → 餵 → Schedule Plan（Roadmap 為輸入）
• 少量情況：執行有戰略改變 → 反向更新 Roadmap

PMI 術語: Master Schedule Schedule Management Plan

§68 元件啟動點變動 → 必須回更新 Roadmap (09:49:37)

核心: 當元件實際啟動 / 結束時間跟 Roadmap 不一致時，必須回去把 Roadmap 也更新成最新基準。

• Roadmap 與實際吻合 = 理想
• 不吻合 → 回去更新 Roadmap → 成為新進度基準

§69 Scope Management Planning + Program Scope Statement (09:49:55)

核心: Plan 子階段的 Scope 過程輸出 Program Scope Statement——比 Construct 子階段的初始評估更細，但仍比 PMP 的 Project Scope Statement 高層級。

• 比初始範圍評估更細節（包含 detail）
• 仍是 high-level（因為在 program 層面）
• 同時輸出 Program Scope Management Plan
• Scope Statement 要分解成 PWBS（最多第二層）

PMI 術語: Program Scope Statement ↔ Program Scope Management Plan

§70 Scope 必須對齊 Program Goals & Objectives (09:51:00)

核心: 標準原文 include activities in planning and aligning program scope with program's goals and objectives——範圍細化但 不能偏離 program 目的目標，最終 = 不能偏離 收益 + 戰略。

• Scope 細化 ≠ 偏離 objective
• Objective 再分解 = benefits
• 範圍 ↔ 收益 ↔ 戰略目標 → 一直保持一致
• 可以更細，但不能 超 出 program 目的目標
• Program 目的不能超組織戰略目的目標

PMI 術語: aligning program scope with goals and objectives

講師原話: 「範圍跟收益、跟戰略目標之間，它是一直以來要保持一致的，它可以更細化、更細緻，但是不能超、不能夠偏離我的專案級的目的和目標。」

§71 Program Scope = Expected Benefit (09:52:02)

核心: 標準原文 Program scope is typically described in the form of expected benefit——程級範圍 典型用「預期收益」描述。

• 與 §47 的 work-required 觀點互補
• 描述形式：expected benefits
• Scope 跟 program 收益匹配 → 跟目的目標匹配 → 完成戰略目標
• 一脈相承

PMI 術語: Program scope is typically described in the form of expected benefit 必背

§72 進入 Delivery 階段：總體框架 (09:53:20)

核心: 進入第八章第二節 Delivery 階段——同樣在治理框架下，前一階段（規劃）的工作結果作為 Program Guidance 進入交付，透過 Integration 5 Core Activity 協同 10 領域 Supporting Activity。

• Plan 階段輸出 → Program Guidance
• 進入 Delivery → Integration 協同 10 領域
• 特別之處：在 Program Performance Monitoring 知識活動裡，監控的物件是元件（Component）
• 完整迴圈：Plan 輸入 → Integration 協同 → Supporting → 元件執行產生報告 → 彙報上來
• 需要管理計劃更新 → 提交對應層面批准 → 形成迴圈
• 直到 program 收益交付（依賴元件成功執行）

PMI 術語: Program Guidance

§73 Delivery 主體在「專案層面」(09:55:30)

核心: 在 Delivery 階段，主體工作由 Project（元件）層面完成——Program 層面只 support，比較少干預專案層面行為。

• Program 關注點：早期規劃 + 構建階段
• 執行階段 → 工作主要交給 Project Management 完成
• 專案 = 實際交付收益的載體
• PgM 在 Delivery 介入不頻繁，只需知道進展 + 必要時調整管理層檔案

§74 Delivery 階段 4 個重點 Supporting (09:56:30)

核心: Delivery 階段挑出 4 個重點 supporting activity 解讀： 1. Financial Management（執行 + M&C） 2. Risk Monitoring & Control 3. Schedule Monitoring & Control 4. Scope Monitoring & Control

• Financial 用 Management（含監督控制，但避免「監控」字眼帶來「對人方向性」誤解）
• Risk / Schedule / Scope 直接用 Monitor and Control

PMI 術語: Financial Management (含 Monitoring) vs Risk/Schedule/Scope Monitoring & Control

§75 為什麼用 Management 不用 Monitoring (09:58:00)

核心: 講師補充 PMP 標準演進——以前監控過程組裡許多過程曾叫過「管理」（Resource Mgmt = 資源監控）。「監控」容易讓人覺得是 對人的方向性偏差，所以避免用，改用 Management。實質上裡面包括 monitoring + controlling。

• PMP 過去版本「資源監控」叫過「資源管理」
• 「監控」帶有「對人方向性」聯想 → 避免
• Information / Communication / Financial 都用 Management 涵蓋 M&C
• Risk / Schedule / Scope 直接稱 Monitoring & Control

§76 Program Financial Management 真正動作：Tracking (09:58:27)

核心: 標準鐵句 Once the program receives initial funding, the financial management focus shifts to tracking, monitoring and controlling the performance, fundings and expenditures——第一筆資金到了，重心立刻轉到追蹤資金使用。

• 觸發點：Once program receives initial funding
• 焦點轉移：規劃 → Tracking + Monitoring + Controlling
• 三項對象：Performance / Fundings / Expenditures
• 之前在「籌劃資金從哪來、預計怎麼花」
• 第一筆資金到 → expenditure 開始 → 管理行為變為 跟蹤資金事實
• 用詞 being expense / 已開始支出

PMI 術語: Once the program receives initial funding... shifts to tracking, monitoring and controlling

講師原話: 「只要第一筆資金來之後，專案級財務管理的中心就轉向了監督、跟蹤這些資金的花費情況。」

§77 超預算 → 不再符合 Business Case → Cancellation (10:01:37)

核心: 在 Delivery 階段如果 exceeding planned budget——很嚴重——可能 no longer satisfy the business case——後果是 may be subject to cancellation 專案級面臨被取消！

• If exceeding planned budget
• program may no longer satisfy the business case
• may be subject to cancellation
• Program 危險訊號：Budget 超支 → Business Case 失效 → 可能被取消

PMI 術語: exceeding planned budget / no longer satisfy the business case / subject to cancellation 三句連鎖必背

講師原話: 「如果一旦不符合或者沒有達到商業論證當中的要求，那麼這個時候專案級可能會面臨非常大的危險——may be subject to cancellation——專案級面臨被取消的危險。」

Part B 綜述

本段接續 Part A 講完「監督與整合」之後，進入交付階段最後幾項活動：財務的監督與超支處置 → 預算編制邏輯 → 風險監督控制 → 進度監督 → 範圍監督 → 收尾階段（兩收尾三移交）→ 課程總結 → 串講 Part 1（標準要點回顧）。串講部分從 11:35:28 開始進入新一輪的全域複習，把第 1 到第 8 章的核心架構（五大績效域、三層管理、生命週期）重講一次，是 ECO 任務串講前的橋接。

§78 監督與追蹤資金支出 (10:02:17)

核心: 執行階段持續追蹤資金支出，超支的專案級可能面臨被取消的風險。

• 執行過程中的「操之情況」要謹慎，靠不斷監督專案級花費來掌握
• 超過預計可能讓專案級被取消，但「並不一定」，是 may be
• 前期已做了周密的資源、資金來源、支付計劃，一旦失控就比較嚴重
• 至少要說明資金支出超在哪、決策權已上移到更高層面

PMI 術語: Monitoring and tracking the money expenditures ↔ 監督與追蹤資金支出 ↔ 講師用「監督花費情況」

講師原話: 「超過了預計的情況，專案級面臨被取消的風險，當然並不一定，它只是說 may be，可是這種情況已經是很嚴重了。」

§79 基於合同的支付 (10:02:43)

核心: 正常情況下基於合同的可交付物產生對應付款，必須符合合同規定。

• 元件層面有外包合同時，合同當中肯定有「如何支付」的條款
• 作為買方要把基於合同的支付寫入財務管理計劃
• 實際執行時要按合同履行完畢的情況進行支付

PMI 術語: Based contract deliverables, payments are made in according with the contracts ↔ 基於合同可交付物按合同規定支付

講師原話: 「必須要符合合同的規定，來去支付對應的款項。」

§80 變更帶來的預算重定基準 (10:04:02)

核心: 變更被批准時，專案級預算基準可能更新並 rebaseline；未批准的超支則風險很高。

• Because of change, programs budget baseline may be updated and rebaselined
• 前提是「變更被批准了」之後，對應的成本基準/預算才會被修改
• 沒被批准的超支 → 專案級面臨的風險很高
• 超支可能源自元件層面，但專案級層面要有人解釋（專案級經理）
• 經批准的變更帶來的超支（because of the change），情況沒那麼嚴重

講師原話: 「如果經過批准了的變更，叫 because of the change，因為變更帶來的超支，如果大家確認，那麼這個情況可能就沒有那麼嚴重。」

§81 元件預算關閉與成本不再進入 (10:05:00)

核心: 單一元件預算關閉後，不再有新成本進入該元件——代表元件結束。

• Individual component budgets are closed
• 預算關閉就代表元件結束，不再有跟元件有關的成本納入
• 「元件結束→不應該再有跟元件有關的成本納入到元件成本當中」

§82 專案級財務管理的兩重含義 (10:05:24)

核心: 專案級財務管理有兩個含義——管理資金 + 監督控制。

• 第一是管理這些資金與資金情況
• 第二是監督和控制
• 管理資金時要關注 contract payments、program budget baseline update
• 元件預算關閉的時候要把元件總體資金情況列明

PMI 術語: Program budget baseline update ↔ 專案級預算基準更新

§83 EAC 與 ETC 在專案級的延伸 (10:09:14)

核心: EAC 與 ETC 是「正職管理」（單專案管理）的概念，但在專案級也會出現，考試難以避免。

• EAC = Revised Estimate at Completion：專案級結束時預計需要支出多少錢
• 預算或成本支出有變化時，必須對未來完成整個專案級還要花的成本做出估算
• 一旦財務有變化，會帶動整個 program management plan 跟著更新
• 因為財務管理是專案級管理當中非常關鍵的一步

PMI 術語: EAC / ETC ↔ 完工估算 / 完工尚需估算

§84 元件層面預算與整體預算的構成 (10:10:21)

核心: 專案級總體預算 = 所有元件預算 + 專案級自身預算，「主體」應在元件層面。

• 元件在 delivery phase 啟動，前期規劃與啟動都在這時候發生
• 元件啟動就要做對應的成本規劃 = Program Cost Budgeting
• 專案級層面的估算是把元件層面預算加總而成
• Program Benefit Budget includes Cost of all Components and Cost of Program Resource Itself

PMI 術語: Program Cost Budgeting ↔ 專案級成本預算編制

§85 大部分成本在元件、不在專案級本身 (10:12:02)

核心: The majority of the program cost is for individual components——專案級本身只是管理協調，不應成為支出主體。

• 專案級總體成本「絕大部分」用在元件層面
• 自身層面不應成為支出主體，否則「不太正常」
• 專案級層面以管理和協同為主，用掉大量成本就是異常

講師原話: 「你用掉了大量的成本和資金的話，那麼這就是不太正常。」

§86 預算的兩個主要部分：Program/Component Payment Schedule (10:13:11)

核心: 預算 = 錢進+錢出+時間節點，含 Program payment schedule 與 Component payment schedule 兩部分。

• 預算指的是「錢進來、錢出去 + 時間節點」概念
• 兩個最主要部分：Program payment schedule 與 Component payment schedule
• 兩者加在一起才是專案級預算當中支出的那一大部分
• 資金來源 = 財務框架/財務管理計劃裡面解決的資金
• 主要指的是支出（payment）

§87 Program Cost Budgeting 的更新邏輯 (10:13:25)

核心: 隨著資訊完善，預算基準會調整 — Update to the program budget baseline。

• 隨著資料完善，預算可能會被調整（update）
• 變更一發生就會帶來變化
• 程序：元件估算 → 元件預算 → 元件預算結合 + 專案級層面預算 → 整個專案級含元件總體預算

§88 元件估算的時機悖論：ROM 的解法 (10:14:38)

核心: 早期不知道有多少元件、確定元件後才精準——Good practice: calculate and estimate as close to the beginning of work effort as possible。

• 早期做元件估算「實際意義也不太大」，最好在元件將要開始時做
• 矛盾在於：早期做預算時不知道元件有多少
• 一旦知道元件就要回頭看、可能出現矛盾，這是「常見的現象」
• 好做法 = 早期做粗略的 ROM 級別估算，後續隨資訊精化

PMI 術語: ROM (Rough Order of Magnitude) ↔ 粗略量級估算

講師原話: 「在早期做元件層面的估算，實際上意義也不太大。最好的做法是在元件將要開始的時候，你再去做這件事。」

§89 元件啟動的兩個核心要素：Governance + Resource Commitment (10:17:19)

核心: 元件啟動時專案級指導委員會要審 governance structure/rules + resource commitment 兩個核心要素。

• 元件新啟動由專案級指導委員會（PSC）批准
• 第一個：組織規則 — Governance Structure and Governance Rules，要有啟動元件的標準
• 第二個：Resource Commitment — 資源能否支撐
• 兩者都符合才會被批准
• 增加/減少元件都是這套流程

PMI 術語: Governance Structure / Rules ↔ 治理結構/規則；Resource Commitment ↔ 資源承諾

§90 商業論證的資金總量是上限 (10:18:05)

核心: 超出最初批准專案級商業論證所給予的資金總量，專案級就面臨風險。

• 大家贊同後，資源增補成為可能 → 風險小
• 但若超支「不是合理原因帶來的」+ 超過商業論證裡的資金總量 → 專案級面臨被取消
• 元件成本「在專案級層面確定」，確定後成為元件層面的預算基準/限制（只能在這範圍內考慮）
• And become the budget for that particular component

講師原話: 「他只能在這個範圍內考慮他的一件事。」

§91 風險的監督和控制：完整流程 (10:19:39)

核心: 風險過程跟單專案管理「概念上完全一樣」，只是分類位置不同。

• 流程：識別 → 分析（定性 + 定量）→ 應對規劃 → 應對管理 → 監督與控制
• 在 PMP 當中分析風險分成「定性」與「定量」，先定性後定量
• Program Risk Response Management 準備好方案不代表立即執行，要關注風險狀態
• Program Risk Monitoring and Controlling 監督風險狀態，一旦發生立即執行應對方案

PMI 術語: Program Risk Response Management ↔ 專案級風險應對管理；Program Risk Monitoring and Controlling ↔ 專案級風險監督控制

§92 未知風險與管理儲備 (10:23:24)

核心: 未預料的風險發生 → 動用管理儲備；已預料風險發生 → 呼叫應急預案。

• 未預料到的稱為「未知風險」，發生時要動用管理儲備
• 「這點上和專案管理的這個質地是沒有區別的」
• 預料到的風險苗頭出現/實際發生 → 立即呼叫應急預案
• 整個過程跟單專案層面的風險管理沒有特別大的區別

§93 風險預測（Forecasting）的價值 (10:24:10)

核心: 監督風險除了看當前狀態，還要做「預測」——對未來可能發生的形式有預見性。

• 基於當前掃描發現，有些風險還沒出現但未來可能以什麼形式出現 = 預測
• 「對風險有預見性」→ 風險臨近或發生時，應對可以提前準備
• 預測是執行過程中、特別是監督控制中很關鍵的一環

§94 Risk Audit / 風險審計 (10:25:01)

核心: 風險審計 = 用既有風險策略與手段去 review 當前風險狀態。

• Risk Audit 平時叫「掃描風險」，專業俗語叫風險審計
• 隨時關注風險狀態，以已具備的風險管理策略與手段重新整理
• 兩個層面：(1) 風險應對措施是否按計劃執行；(2) 應對手段實際發生後的有效性
• 兩個面向：風險管理過程的有效性 + 風險應對的有效性

PMI 術語: Risk Audit ↔ 風險審計

§95 專案級進度監督的本質 (10:26:18)

核心: 比對實際時間點 vs 原計劃，出現偏差就分析、預測進展狀態。

• 實際執行/完成時間點是否跟原計劃一樣
• 不一樣就分析偏差，對專案級進展時間狀態做預測
• 主要監督對象：Tracking and monitoring the start and finish of all high-level components and program activities
• 兩個關鍵節點：start（起點）+ finish（終點），主要在元件層面，其次是專案級活動

§96 Program Master Schedule 主進度計劃 (10:27:35)

核心: 專案級用「主進度計劃」術語，只看元件 start/finish，不過多干預中間狀態。

• 因為層面比較高，所以叫 Program Master Schedule
• 不會包括特別多的細節，細節留在專案層面（活動級）
• 專案級層面只看元件的 Start and Finish 兩節點
• 中間狀態「不過多的干預」

PMI 術語: Program Master Schedule ↔ 專案級主進度計劃

§97 範圍×進度×成本 alignment 是成功關鍵 (10:27:46)

核心: Successful management depends on alignment of scope with cost and schedule——三者必須整合考慮。

• 三者互相影響：範圍擴大 → 成本/時間要更多；成本不足 → 縮減範圍或壓縮排度
• 壓縮排度也不是完美方案（可能需要更多錢）
• 「應該把它們統一整合在一起考慮」，所以用 alignment
• 到處都在使用這個 alignment

講師原話: 「專案級管理成功是要把範圍、進度、成本綜合在一起考慮，因為它們三個是互相影響的。」

§98 主進度計劃因元件增減而更新 (10:28:23)

核心: 新元件加入或舊元件被 terminate 都要更新主進度計劃 + 路線圖，保持 alignment。

• Programs master schedule may be updated to include new components or remove the components
• 第四層（前面提過）就出現這種情況
• 無論新元件出現還是舊元件被取消，都要更新主進度計劃
• 同時要在「專案級路線圖」當中做出更新

§99 主進度計劃 vs 路線圖：細節層級 (10:28:51)

核心: 路線圖更宏觀（早在章程/商業論證階段就存在），主進度計劃比路線圖細節更多。

• 路線圖在專案級章程/商業論證環節就已經存在
• 表達「希望專案級在什麼樣的時間節奏上完成收益交付」
• 進入專案級進度管理時，路線圖作為輸入產生主進度計劃
• 主進度計劃 vs 路線圖：細節程度更多
• 主進度計劃 vs 專案層面進度計劃：又是更高層次

§100 remain alignment：路線圖與主進度計劃同步 (10:30:53)

核心: 元件變更同時更新主進度計劃與路線圖，保持兩者一致。

• 新元件產生 / 原元件 terminate → 兩處都要更新
• 用詞：remain alignment，「這兩個也要保持一致」
• 進度要跟範圍、成本保持一致
• 「一致性是專案級經理關注的重點」
• 需要專案級經理具備全域性、高階視野看到依賴關係

§101 範圍監督控制 ≈ 收益監督控制 (10:31:36)

核心: 範圍監督控制與收益管理高度相關——範圍大部分以收益形式呈現。

• 收益管理「展現的另外一面是範圍」，反過來範圍大部分以收益方式呈現
• 範圍監督控制「一大部分程度上其實是跟收益有關的」
• 必須遵照變更管理計劃 + 範圍管理計劃的要求，不能隨意變更
• 收益層面變更 → 影響整個專案級收益能否達成 → 影響整個組織

§102 Major change approved 帶來的全面更新 (10:32:50)

核心: 重大變更被批准 → 專案級管理計劃（17 個子計劃）都可能更新，尤其範圍說明書。

• Major change approved 沒講明哪一個方面，泛指各種
• 只要對收益、進度、範圍有影響的（尤其範圍）→ 經批准 → 影響整個專案級管理計劃
• 因為不便說具體哪些，所以用 Program Management Plan 總稱
• 「14 個 + 3 個 = 17 個計劃都有可能帶來更新」
• 要強調：專案級範圍說明書要及時調整

§103 Manage scope only to allocated level — 不要管太細 (10:34:05)

核心: Program Manager manage scope only to allocated level for components and should avoid controlling component scope——避免專案級干預元件過多。

• 監督專案級範圍時，要避免「干預到組建層面過多」
• 在「商量好/協商好的範圍」、「指定的層面」進行
• 實務建議：停止在組建（component）的「第二層」就可以
• 再往下就跟專案經理管理範疇高度重合
• WBS 描述最多到第二層

講師原話: 「最好是停止在組建層面的第二層就可以了。再往下就會跟專案經理的管理範疇有高度重合了。」

§104 範圍監督的影響：管理計劃 + 範圍說明書 + WBS (10:34:55)

核心: 範圍變更會連動範圍管理計劃、範圍說明書、WBS、處置方式，最終整個專案級管理計劃。

• 範圍管理計劃、專案級範圍說明書可能被更新
• 跟範圍有關的變更要加以 dispositions（處置）：可能是批准/否決/受理
• 收益的出發點一旦改變，影響是全域性 → 帶來專案級管理計劃更新
• 直接相關：範圍說明書 + WBS（範圍說明書分解成 WBS，跟 PMP 一樣）

PMI 術語: Dispositions ↔ 處置（變更請求的處置決定）

§105 收尾階段：兩個收尾 + 三個移交 (10:46:21)

核心: 收尾階段支援活動 = 兩收尾（財務、採購） + 三移交（資訊、風險、資源）。

• 兩個收尾：(1) 財務的收尾、(2) 採購的收尾
• 三個移交：(1) 資訊歸檔與移交、(2) 風險移交、(3) 資源移交
• 加上核心管理活動裡的：專案級收尾、收益維持、專案級移交
• 完整對照 = 兩個收尾 + 三個移交，搭配核心活動的 benefit sustainment + program transition + program closure

PMI 術語: Benefit Sustainment / Program Transition / Program Closure ↔ 收益維持/專案級移交/專案級收尾

§106 收尾階段內部互動關係 (10:47:09)

核心: 在組織治理/專案級治理規則之下，整合管理核心活動協調支援過程，輸出 Program Final Report。

• 在組織治理、專案級治理規則之下完成收尾
• 整合管理核心活動 → 協同支援過程活動 → 完成整個專案級的收尾系列動作
• 最終要輸出 Program Final Report（專案級最終報告）
• 在專案級收尾之前產出，需要專案級指導委員會批准

PMI 術語: Program Final Report ↔ 專案級最終報告

§107 移交目的地：Operations 與接收方 (10:50:00)

核心: 收益維持責任交到 Organizational Operations——可能是內部組織也可能是接收組織。

• Organizational Operations 不一定是專案級所在組織，可能是接收組織
• Program Management Archives, Assets and Resources 也要交出去
• 內部專案級：交給內部運營部門
• 外部組織：交到外部去

§108 專案級財務收尾總覽 (10:50:31)

核心: 財務收尾將成本做截止，便於核算整個專案級收支與成本/收益。

• 財務內容很多：初始評估 → 估算 → 框架 → 管理計劃 → 監控 → 收尾
• 整體專案是否符合預期收益，跟成本支出與收益高度相關
• 財務收尾「將專案級的成本做一個截止」，從此不再納入新成本
• 便於核算整個專案級的收支情況

§109 財務收尾要點 1：是 Final Report 的一部分 (10:51:35)

核心: 財務收尾結果是專案級最終報告的一部分（或主要輸入）。

• 可以視為最終報告的一部分，也可單獨作為主要輸入
• 看怎麼看，「也可以是它的輸入之一」
• 同時 Financial Management Plan 也要更新成最新

§110 財務收尾要點 2：放入 Knowledge Repository (10:53:02)

核心: 財務收尾資訊作為 Knowledge Repository 輸入，因為財務工作具高度可複製性。

• 作為知識經驗庫/knowledge repository 的輸入
• 財務管理可複製的地方比較多，幾乎是所有專案共通
• 要納入組織過程資產，拿到知識庫當中
• Documentation of new tools and techniques 新方法/新核算方法/新核定科目，要記錄供其他專案級使用

PMI 術語: Knowledge Repository ↔ 知識文件庫

§111 財務收尾要點 3：Financial Closing Statement (10:55:05)

核心: 對外宣告整個專案級財務關閉，且預算實質關閉，再無新成本進入。

• Financial closing statement — 對外宣告專案級不再納入新成本
• 「告知大家：新的東西不能再記進來了」
• 一個是宣告 + 一個是真正把預算關閉
• 對整個專案級關閉非常關鍵

講師原話: 「專案的成本有時候難以做出最終的決算，是因為它有不斷的成本會記進來。」

§112 財務收尾要點 4：Estimate cost of sustaining benefit (10:55:32)

核心: 對「將來維持收益所需要的成本」做估算，給接收方做參考。

• Estimate the cost of a sustaining benefit created by the program
• 為了讓接收方知道「未來要維持這樣的收益你需要投入多少」
• 便於接收方維持整個專案級收益持續進展

§113 財務收尾要點 5：預算關閉與報告分發 (10:56:38)

核心: Near completion, program budget is closed + Financial reports are communicated——預算關閉、最終財務報告分發出去。

• 接近完成時 → 專案級預算被關閉，不再有新成本記進來
• 最終財務報告要產生並 communicate 給應該瞭解的相關方
• 是整個專案級「最簡單最明瞭也最重要」的一份報告
• 納入收尾報告一部分，但只跟財務有關 → 直觀直接看到財務狀態

§114 財務收尾要點 6：未用完的錢要還回去 (10:57:33)

核心: Any unspent monies should return to the funding organization——沒用完的錢必須還回投資方。

• 從哪來 → 要還到哪去
• 想辦法把錢花掉 → 審計時很難交代
• Funding organization = 給你出錢的那一方

講師原話: 「沒有用完的錢，如果你想辦法把它花掉，那麼可能會面臨到審計的時候，你會很難交代。」

§115 財務移交完成的判定 (10:58:13)

核心: Program financial transition is complete once sustaining budgets are developed, benefits are delivered and the statement has been commenced。

• Financial transition 不是把錢移交出去，是「整個財務管理的情形」要交個點
• 交給接收方
• Sustaining budget 是為了接收方而做
• 一旦 sustaining benefit 的成本估算完成 → 財務移交工作完成

§116 財務移交：再次整理 4 件事 (11:00:22)

核心: 重複歸納財務移交要做：(1) 最終報告輸入、(2) 財務管理計劃更新、(3) 經驗教訓入庫、(4) financial closing statement + 預算關閉。

• 第一：作為專案級最終報告的輸入
• 同時把財務管理計劃更新成最新
• 經驗教訓納入 knowledge repository
• 記錄財務管理過程使用到的新工具和技術，未來重新審計時可作證據
• Financial closing statement 釋出給所有相關方/部門
• 預算關閉，不能再以該專案級名義報銷或產生成本

§117 資訊歸檔與移交 (11:04:21)

核心: 大量檔案要歸集、編號編碼以利檢索，移交給接收方或專案級所在組織接納。

• Archive = 歸檔，不只是放在一起，還要編號編碼便於將來檢索
• 移交給：接收方，或接收方不需要的部分留在專案級所在組織
• 對未來專案級執行幫助很大

PMI 術語: Archive ↔ 歸檔

§118 資訊移交 3 條要點 (11:04:48)

核心: (1) Collect and organize program records、(2) Transfer program knowledge to supporting organization、(3) Assess program performance + collect observations + provide a financial license learning report。

• 第一：Collect and organize program records for activating or for other elements of organization use
• 整理專案級記錄供組織其他部門/未來類似專案級使用
• 第二：Transfer program knowledge to supporting organization with documentation, training or materials supporting benefits sustaining
• 把資訊移交給未來維持專案級收益的接收方，包括文件 + 培訓材料
• 維持方若是新人，可透過培訓材料瞭解專案級過程

§119 經驗教訓報告：Program Information Achieving and Transition (11:06:38)

核心: 評估績效 + 收集觀察 + 提供 Lessons Learned Report，作為組織資產與知識庫輸入。

• Assess program performance, Collect observations, Provide a financial license learning report
• 整體報告也要做好，對最終關閉「奉獻它應有的價值」
• 作為評價整個專案級最終績效的一部分
• 有些專案級「收益完成的很不錯，可是整個的管理過程又很不規範」
• 歸檔有助於讓更有價值的東西能傳承下去
• 過程稱為 Program Information Archiving and Transition
• 是組織歸檔庫的一部分 = Inputs to organizational activities
• Lessons Learned Report 給組織治理主體 / 管理層使用

PMI 術語: Program Information Archiving and Transition ↔ 專案級資訊歸檔與移交

§120 採購收尾 (11:09:14)

核心: 跟單專案採購收尾很像，但執行在專案級層面，關注所有元件採購是否都結束。

• 關注專案級下所有元件的採購是否都結束
• 出具合同關閉的最終報告 + 經驗教訓（採購方面）
• 注意：剛才說的 Lessons Learned 是財務方面的，這裡是採購方面
• 另一輸出：被關閉了的合同

§121 採購收尾 4 個要點 (11:11:31)

核心: (1) Formally close out each agreement、(2) Ensure all deliverables completed + all payments made、(3) Ensuring no outstanding contract issues、(4) 資源移交。

• Formally close out each agreement of the program — 每個協議都被正式關閉
• 用詞 agreement（協議）vs contract（合同）：contract 是 agreement 更嚴格的形式
• 所有協議都被關閉 = 履行完畢，沒有遺留責任
• Ensuring all deliverables completed — 留意是「可交付成果」不是「收益」（收益可能持續到專案級之後）
• All payments have been made — 跟合同有關的付款都得付出去，不能有應付未付
• Ensuring no outstanding contract issues — 沒有特別突出的合同問題
• 實在難以解決的，「也不能因為它沒解決專案集都不關閉了」，可以等專案關閉之後再恰當處理
• 最理想：All payment should have been made

§122 資源移交 (11:13:43)

核心: 專案級結束資源要釋放，但要留 supporting team；資源移交目的地依內外部而異。

• 跟單專案結束一樣，資源要釋放
• 「專案釋放是比較徹底的」，但專案級要留一些 Supporting teams
• Supporting teams 應該是在「專案之外」，但仍在專案級範圍之內
• 收益維持在專案級範圍之內 → 你要做支援
• 釋放給：內部組織（讓組織再分配）或外部資源（更要釋放）

PMI 術語: Supporting Teams ↔ 支援團隊

§123 資源移交注意點 1 + 2：恰當釋放 + 再分配 (11:14:32)

核心: Ensure that program resources are properly released + 關注團隊成員 Relocation and reassignment + funding to other activities or program。

• 「恰當的被釋放」= 有些人要留下來做支援活動，大量的人要釋放
• As the program is being closed
• 關注 relocation and reassignment of team members
• 包括 the funding to other activities or program
• 資源再分配/再部署「不是專案級經理的許可權範圍」，但他要關注
• 真正的權利是交到專案組合層面去處理

§124 專案級內部 vs 收尾後的權限差異 (11:16:13)

核心: 元件關閉時專案級經理「有權」轉移已釋放資源；專案級收尾時則無此權限。

• 專案級還沒關閉、有元件關閉 → 專案級經理「有權」將已釋放的某元件資源/資金轉移到其他未完成元件
• 但專案級收尾時，資源再分配/團隊成員再分配「在專案級經理的許可權範圍之外」
• 因為你的專案級已經結束
• 資源安排是專案組合經理或組織層面（如 PMO、組織資源管理部門）負責

§125 資源移交產出與權限歸屬 (11:18:03)

核心: Program Resource Transition 主要輸出是「資源被釋放」，且釋放給組織其他單元；不細講原因是不在 PgM 權限內。

• 主要輸出：資源被釋放、釋放給「組織其他單元」
• 不專門講細節，因為再分配情形很多 + 不是專案級經理權限範圍

§126 風險移交 — 一個新概念 (11:18:46)

核心: 風險可以移交：大型/長期專案級的遺留風險由 PMO 或運營部門承接。

• 「原來其實一直沒有提到過：如果風險還可以移交」
• 大型複雜或長期的專案級，PMO 可能要把遺留未處理的風險接過來
• 或運營部門接過來
• 專案級總是要關閉，關閉之後團隊資源釋放，但風險得有人跟進
• 有接收方 → 告知接收方還有其他風險，提醒留意
• 同時告知過程中發生了什麼事
• 是 PMO 也一樣告知

§127 風險移交 3 條要點 (11:21:20)

核心: (1) There may be remaining risk 影響 benefit realization、(2) Transfer this risk to appropriate organization、(3) Remaining risk may be managed by a different organization group then the one intended to realize the benefit。

• 第一：專案級關閉後依然可能有遺留風險，影響 benefit realization
• 第二：將遺留風險「Transfer to appropriate organization」
• 什麼叫 appropriate？接收收益的部門 / PMO 都比較合適
• 客戶可能不管你這風險，但我們有責任義務告知
• 第三：Remaining risk may be managed by a different organization group then the one intended to realize the benefit
• different = 專案級所在的組織（不同於接收收益方）
• 可能交給第三方（要支付費用），也可能你自己承接
• 接受收益的一方「他不應該承擔這種風險」

§128 風險移交與運營部門承接 (11:24:28)

核心: 像專案結束後我們要提供支援一樣——支援收益實現 + 處理過程中不可預知事件。

• 跟「專案結束後給接收方提供支援」的概念一樣
• 支援包括「持續實現收益」+「過程中遇到不可預知事件」
• PMO 是一個選擇，組織內運營部門更佳
• 運營部門不接受收益，但負責「收益移交到客戶之後後期問題的處理」（包括風險）

§129 Program Risk Management Transition 的精髓 (11:25:28)

核心: Program Risk Management Transition = 把遺留風險「交出去而非丟出去」+ 登記到對方 risk register。

• 移交「不是丟出去」，是告知接收方/相關部門「這裡面還是有一些潛在的風險可能會發生」
• 同時告知對方該如何加以處理
• Input to Other Organization Risk Registry
• 把風險登記到接收方的風險登記冊當中 = 等於接手

PMI 術語: Program Risk Management Transition ↔ 專案級風險管理移交

§130 課程結束語 (11:28:22)

核心: 講到此整個課程告一段落 — 專案級管理是高階管理思維框架模型。

• 希望大家在過程中有深入的認識，掌握宏觀技巧跟原則
• 「專案級管理是一個高階管理、高階專案管理的一種思維框架模型」
• 對人的啟發和對實踐的製造作用「比較巨大」
• 課堂只是一個方式，實踐當中會碰到各種各樣問題
• 「希望這種知識體系能給大家帶來一定的收益和收穫」

講師原話: 「謝謝大家。」（10:54:45 / 39366.61 sec 處）

§131 串講啟動：標準回顧 + ECO 任務 (11:31:47)

核心: 串講分兩部分：(1) 整體標準簡要回顧（第 1～8 章）、(2) ECO 74 個任務逐一解讀。

• 跟認證考試直接相關 = ECO 部分（74 個任務的解讀）
• 建議先做的功課：精講看 3 遍以上、標準讀 2 遍以上、ECO 大綱讀 5 遍以上
• 否則「收益會比較小」
• ECO = Examination Content Outline，PgMP 認證的考試大綱

PMI 術語: ECO (Examination Content Outline) ↔ 考試內容大綱

§132 標準的 6 個概要 + 第 7、8 章 (11:34:12)

核心: 主要 6 個部分概要性 + 第 7 章生命週期 + 第 8 章支援活動（零碎）。

• 最主要的 6 個部分是概要性的
• 第 7 部分 = 專案級生命週期；第 8 部分 = 支援活動
• 支援活動涉及很多零碎內容，「大家可以回到精講當中再去複習」

§133 五大績效域回顧 (11:35:28)

核心: 五大績效域 = 戰略一致性、效益管理、相關方爭取、治理、生命週期管理。

• Strategic Alignment 戰略一致性
• Benefits Management 效益管理（收益管理）
• Stakeholder Engagement 相關方爭取
• Governance 治理
• Life Cycle Management 生命週期管理

PMI 術語: Five Performance Domains ↔ 五大績效域

§134 戰略一致性的 5 大要素 (11:35:47)

核心: 商業論證、章程、路線圖 + 環境評估 + 風險管理策略。

• 商業論證的定位和內容
• 專案級章程的定位和內容
• 專案級路線圖
• 三者之間的關係 + 環境評估 + 風險管理策略
• 框架圖：左側組織戰略計劃 → 中間 5 要素 → 右側風險管理策略
• 環境評估影響商業論證/章程/路線圖
• 三個 artifacts（弓箭）= 戰略一致性要抓的三個核心要點 + 落地的檔案載體

PMI 術語: Artifacts ↔ 弓箭/載體（講師音譯）

§135 收益管理 5 步驟 (11:37:08)

核心: 識別 → 分析（含 BDM/BDS）→ 規劃（包括元件啟動）→ 交付 → 移交+維持。

• 識別由：早期發起人、戰略層、PgM、關鍵相關方協商完成
• 結果寫入 收益登記冊（Benefits Register）
• 分析、評估、分解 → 收益依賴地圖 或 收益分解結構（BDS）
• 透過收益內在聯絡，規劃要啟動哪些元件，建構整個 Program Architecture
• 元件結構 + 收益對應關係寫入收益登記冊
• 收益交付 = 透過元件完成達成整個收益產生（不是交出去）
• 收益移交 = 交給接收方/預期受益人/運營組織
• 移交後接收方 = 「收益的維持方」，負責持續產生

PMI 術語: Benefit Register ↔ 收益登記冊；Benefits Dependency Map / Structure ↔ 收益依賴地圖/分解結構；Program Architecture ↔ 專案級架構

§136 相關方爭取 5 步驟 + 兩個檔案的區分 (11:42:46)

核心: 識別 → 分析 → 規劃爭取 → 爭取 → 溝通；分析資訊去爭取計劃，基本資訊去登記冊。

• 早期識別關鍵相關方（要參與戰略/收益管理）
• 後期不斷重複識別
• 識別後對重要性 + 基本資訊做分析記錄
• 分析資訊 → 納入 相關方爭取計劃
• 基本資訊 + 分析結論 → 納入 相關方登記冊
• 「這兩個檔案的區分是一個要點」
• 規劃爭取 = 提前安排活動，不是過程中臨時決定
• 爭取的最主要手段 = 溝通
• 是迴圈迭代不斷重複的過程

PMI 術語: Stakeholder Engagement Plan / Register ↔ 相關方爭取計劃/登記冊

§137 治理 vs 管理：核心區分 (11:42:46)

核心: 治理 = 關於管理該怎麼開展所定義的規則；治理是「更高層面的管理」。

• 治理跟管理關係常分不清楚
• 治理通常跟決策、監控、判斷、背書、檢查、評審有關
• 背後核心 = 管理過程中有「更高層面的實體」（人或組織）
• 在關鍵節點對管理行為做評審 → 通過/不通過/繼續/修訂
• 因為複雜度高，要有意識設置治理機制
• 涵蓋：變更、風險、問題、彙報關係、節端關口、健康檢查節點、元件啟動/移交/收尾批准
• 「治理實際上是一種更高層面的管理」
• 預先做好治理規劃 = 專案級治理計劃，文字化、達成共識

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

§138 生命週期：3 階段 + PMP 對應 (11:41:38)

核心: 定義 / 交付 / 收尾，分別對應 PMP 的啟動規劃 / 執行監控 / 收尾。

• 定義 → PMP 的啟動 + 規劃
• 交付 → 執行 + 監控
• 收尾 → 收尾
• 工作內容差別 = 專案級層面 vs 元件層面
• 元件層面：五大過程組 + 十大知識領域
• 專案級層面 = Program Level Activities
• 定義階段細分 Formulation Subphase + Planning Subphase
• 交付階段細分：元件識別與分析、規劃、監控、整合（3 個子階段）
• 收尾階段實質上有移交 + 關閉兩動作（新標準合在一起）

PMI 術語: Formulation / Planning Subphase ↔ 構建/規劃子階段

§139 專案級的本質定義 (11:42:46)

核心: 一組互相依賴的元件（專案/子專案級/活動）以協調方式管理，獲得分別管理所不能的收益。

• 元件 = components，可能是專案、子專案級（substitutory program）、專案級活動
• 之間有內在聯絡 = interdependent（標準用 related，但 interdependent 更清晰）
• 必須以更新方式管理：managed in a coordinated way / managed manners
• 用協調管理方式執行
• 目的：obtain benefit not available from managing them individually
• 分別管理 = portfolio management 風格
• 專案級管理重點 = 管理內在依賴關係，會有額外的價值和收益

講師原話: 「我們發現事物之間內在聯絡，這是一個能力和素質。基於這種內在聯絡，我們加以對它進行更恰當的管理，這是另外一種能力。」

§140 專案級三階段固有特徵 (11:43:40)

核心: 定義 / 交付 / 收益階段，三個維度看專案級。

• 第一：定義階段做什麼事
• 第二：交付階段做什麼事
• 第三：受益階段做什麼事
• 不同於專案管理：早期決策影響非常明顯
• 專案級在 definition phase 早期分為 formulation subphase + planning subphase
• formulation 主要產出：商業論證 + 章程 + 路線圖（top level 文件，通常不輕易改）
• planning 主要產出：14 個方面的子計劃，互動關係明顯

§141 商業論證 → 章程 → 路線圖 互動鏈 (11:43:40)

核心: 商業論證 = 經濟可行性論證；章程 = 宣佈專案級開始 + 任命 PgM；路線圖 = 時間節奏宏觀規劃。

• 商業論證起點 = 組織戰略計劃中需要落地的內容
• 透過 PSC 或 portfolio review 委員會審批
• 商業論證證明做這個專案級對組織有收益和價值
• 是組織高層批准專案級的輸入
• 章程是早期專案級成立的標誌：宣佈專案級、任命 PgM、授權動用組織資源
• 路線圖：描述時間節奏、關鍵節點、決策點、場景，章程的輔助支撐
• 標準上把 charter / roadmap 分離，實踐可合一
• 規劃結束標誌 = Program Management Plan 批准

§142 元件層面的整體流程：授權→規劃→監管→整合→移交→關閉 (11:44:14)

核心: 元件本身走五大過程組（PMP），專案級層面對應 oversight + integration + transition。

• 元件啟動需 PSC 批准（對應 PMP 的「啟動」）
• 元件規劃要與專案級管理計劃保持一致 — 反向 alignment（元件對專案級保持一致）
• 元件執行 → 專案級層面做 oversight（監督）
• 元件可交付成果若對其他元件有影響 → 專案級經理介入做 integration
• 元件可交付成果可能在過程中就移交（提前移交） — 收益的移交
• Component Transition 移交給接收方
• 元件完成 → 元件關閉
• 所有元件關閉 → 進入專案級關閉階段
• 收益沒有「關閉」概念（只有交付/移交/維持），但元件有關閉概念

PMI 術語: Component Oversight / Integration / Transition ↔ 元件監督/整合/移交

§143 一頭一尾在專案級層面 (11:46:37)

核心: Program Deliver Phase 涵蓋單專案完整生命週期，但一頭（啟動）一尾（收尾）的專案級行為由專案級層面做。

• Program Deliver Phase 涵蓋 PMP/單專案管理的所有生命週期
• 元件之間的關係是 Non-Sequential Nature（非順序性）
• 此元件啟動時其他元件還沒做完，有些元件已啟動有些還沒
• 專案級做這些事都需要更高層面的管理實體做指示/判斷/批准 = 專案級治理
• 三個階段 = 專案級生命週期
• 戰略和收益是過程中不斷核定/核實/批准的
• 治理權責流程由 PgM 推進

§144 專案級管理定義：知識+技能+原則 (11:47:42)

核心: 專案級管理 = 將「知識/技能/原則」應用到專案級要素以保證 Achieve the program objectives。

• 重要點：不是「知識+技能+工具」，而是「知識+技能+原則」
• 兩個必要條件：(1) 元件之間有內在聯絡、(2) 多個要素構成
• 目的：To obtain benefits and control
• 還包含「讓事情在掌握之中」的訴求
• 分別管理沒有的額外效果 = 額外的掌控
• principle 就是五大績效域的核心思想：收益最大化、戰略一致性、組織治理分級、相關方恰當爭取、生命週期有序展開

§145 PgM 的工作核心：alignment + integration + control (11:48:38)

核心: PgM 確保 effective alignment + integration + control——內外一致 + 元件協同 + 額外掌控。

• Organization authorize a program manager to lead the team for achieving program goals and objectives
• Program manager ensures effective alignment
• alignment = (1) 專案級內部要素一致 + (2) 專案級與更高組織層面一致
• integration = 元件間協同、產出有效結合
• control = 獲得額外掌控，事情不偏離原軌道

§146 三個結構化方法的對比 (11:48:48)

核心: Project / Program / Portfolio 都是「結構化方法」(structured means)，目的都是支撐組織戰略，但側重不同。

• 三者都是 structured means
• 專案管理：聚焦範圍/進度/成本/質量受限條件，互動具體可交付成果，早期詳細規劃，按確定性方式互動結果
• 專案級管理：關注組件間的依賴關係，最終實現收益最大化（5 大績效域）
• 組合管理：管理元件間共享資源，透過排列元件優先順序分配資源，達成組織價值最大化
• 三者都是為了「保證組織戰略能夠得以實現」
• 它們之間有 (1) 高低層次關係 + (2) 各有側重

（Part B 結束於 11:48:48，專案級管理串講 Part 1 進行至五大績效域回顧的中段；後續主要進入 Part 2 ECO 74 個任務逐條解讀，由 Ch06 接續或下一段影片承接。）