收益管理生命週期

PgMP 第一性原理 — program 存在就是為了產生 strategic benefits;本主題涵蓋 Benefits Management 五階段、四大核心文件(BMP/Register/Roadmap/Map)、Charter/Business Case 中的收益、metrics/KPI 設計、transition 與 sustainment 的分工,以及戰略改變時收益對齊的處理。 收錄 88 條原料,聚類為 12 個知識點

子主題 1: 五階段口訣「識規交移持」+ Metrics 永在規劃

核心:Benefits Management Life Cycle 五階段 = Identification → Analysis & Planning → Delivery → Transition → Sustainment(口訣「識規交移持」)。Metrics 不論是收益、品質還是進度,永遠在「分析與規劃」階段 被定下來,承上 identification 提供的候選收益,承下 delivery 的可量測標的。

出題形式: - 「Metrics 屬於哪個 benefits 階段?」→ Analysis & Planning(分析與規劃) - 「接收組織準備度 + 驗收標準對應哪個階段?」→ Transition - 「Benefits 五階段順序為?」→ Identification → Analysis & Planning → Delivery → Transition → Sustainment

題號:模擬1 Q1 · 模擬A Q47 · 模擬x Q1

子主題 2: BMP(Benefits Management Plan)是收益總綱

核心:BMP 是 Benefits Analysis & Planning 階段的「畢業證書」與最終輸出,負責定義 metrics、KPI、target;描述每個收益的 何時 / 如何 / 誰責(when/how/responsibility),含實現時序 + 維持安排。BMP 同時是 Gate Review 與收益實現的「藍圖/評分卡」,而 Register 是「進度條」。

出題形式: - 「Benefits Analysis & Planning 的最終輸出?」→ BMP - 「評估 program 收益進展看哪份文件?」→ BMP(計畫 + 跟蹤 + 評估三合一) - 「Gate review 對照哪份文件評估收益?」→ BMP(預期收益 + metrics + targets 都在此) - 「Metrics / KPI 的官方文件?」→ BMP(BMP 定 / Register 跟 / Report 報) - 「BMP 含哪些 benefits 規劃?」→ 實現時序 + 維持安排(包山包海) - 「收益已確定 + 假設 + 職責定義完後,下一步?」→ 制定 BMP

陷阱:Benefits Register 是「清單」/「進度條」,BMP 是「計畫」/「藍圖」,題目問「對照基準/評分卡」用 BMP,問「當前狀態/進展證據」用 Register。

題號:模擬1 Q101 · 模擬1 Q136 · 模擬1 Q153 · 模擬1 Q157 · 模擬1 Q161 · 模擬A Q104 · 模擬A Q137 · 模擬A Q158 · 模擬B Q1 · 模擬B Q8 · 模擬B Q26 · 模擬B Q144 · 模擬x Q2 · 模擬x Q52

子主題 3: Benefits 文件四件套分工(BMP / Register / Roadmap / Map)

核心:Benefits 文件分工 = BMP(如何)+ Map(連結)+ Register(狀態)+ Roadmap(時間)。 - BMP:細節 — 收益怎麼實現(規劃 + 跟蹤 + 評估) - Benefits Register:收益清單與當前實現狀態(識別/規劃/實現中/已實現),含 metrics + KPI + 衡量過程 - Benefits Roadmap:大粒度時序視圖 — 含里程碑、決策點、收益實現節點;activities ↔ benefits 視覺橋樑 - Benefits Map:outputs → outcomes → benefits 轉化關係;Dependency Map 則顯示收益間依賴

出題形式: - 「顯示收益實現進度/狀態?」→ Benefits Register - 「展示活動與收益時間線關係?」→ Benefits Roadmap - 「描述 outputs → benefits 的因果鏈?」→ Benefits Map(+ Dependency Map) - 「Benefits register 核心內容?」→ Metrics + KPI + 衡量過程 - 「向 Sponsor 展示 activities ↔ benefits 高層視圖?」→ Roadmap(BMP 太細) - 「Benefits 進展溝通看哪份文件?」→ Benefits Register(現況證據) - 「客製化承諾後要更新什麼?」→ Benefits Register

陷阱:Q76 vs Q89 — 同樣是 activities/benefits 主題,問「實現狀態」選 Register,問「活動與收益連結 / 建立關係」選 Roadmap;對象是 sponsor 高層幾乎都選 Roadmap。

題號:模擬1 Q61 · 模擬1 Q76 · 模擬1 Q78 · 模擬1 Q89 · 模擬1 Q125 · 模擬A Q82 · 模擬A Q93 · 模擬A Q120 · 模擬A Q126 · 模擬B Q3 · 模擬B Q66 · 模擬B Q104 · 模擬x Q6 · 模擬x Q121 · 模擬x Q104 · 模擬x Q155

子主題 4: BMP ↔ Roadmap 雙向同步原則

核心:BMP 改 → Roadmap 必同步更新(roadmap 含收益實現節點,BMP 變化時間線也會變)。Component closure 也要反映在 roadmap(活的時間線)。Roadmap 也是「戰略 ↔ 計畫工作」/「work ↔ benefits」的視覺橋樑。

出題形式: - 「BMP 修改後要連帶更新哪份文件?」→ Roadmap - 「Component closure 後更新哪份文件?」→ Roadmap(反映里程碑與組件狀態變化) - 「戰略 / Mandate / Environmental analysis 的下游視覺輸出?」→ Roadmap

題號:模擬1 Q147 · 模擬1 Q149 · 模擬A Q148 · 模擬A Q150 · 模擬B Q29 · 模擬B Q35 · 模擬B Q43 · 模擬B Q123 · 模擬x Q70

子主題 5: Charter 與 Business Case 中的收益

核心:Benefits 文件時序層級 = Business case(啟動前,全面收益論證 + ROI)→ Charter(啟動,vision + 戰略目標 + 期望收益 + 高層 scope)→ BMP(規劃)→ Register(狀態)。新 stakeholder 入門順序 = 章程 → 路線圖 → BMP → 會面,Charter 是入口。

出題形式: - 「啟動前識別的 benefits 記在哪?」→ Business case - 「Program 完成後的『期望收益』定義在哪?」→ Charter(expected benefits 是 charter 標準章節) - 「新人不了解預期收益要看什麼?」→ Charter(比 BMP 更概念性 / 更易讀) - 「Charter 六件套內容?」→ 合理性 + 願景 + 成果 + 收益戰略 + 組件 + 時間線 - 「向 Sponsor 展示『共同高層期望』?」→ Charter + Business case 兩文件組合 - 「新成員 onboard 不熟目標 → 回到?」→ Charter + BMP(目標看 Charter / 收益看 BMP)

陷阱:Business case 是源頭(全面論證),BMP 是執行細節,Register 是清單;同一道「收益在哪」題,依時序與粒度給出不同答案。模擬A Q11 答案是 Charter 不是 BMP/Register。

題號:模擬1 Q59 · 模擬1 Q126 · 模擬1 Q137 · 模擬1 Q158 · 模擬A Q11 · 模擬A Q14 · 模擬A Q64 · 模擬A Q138 · 模擬B Q28 · 模擬B Q141 · 模擬B Q148 · 模擬x Q27

子主題 6: Sustainment 階段 — 收益不在 closure 結束

核心:Closure 不等於收益結束。Benefits 必須在 program 結束後持續維持 = Sustainment 階段的核心(持續實現 + 持續監督)。Benefits 三 plan 分工 = BMP(規劃)+ Transition(移交)+ Sustainment(維持改善)。Closure 後出現的 feedback / improvement / KPI 不符,皆由 Sustainment plan 規範。

出題形式: - 「已交付但未追蹤維持問題?」→ Benefits Sustainment Plan - 「交付後 6 個月跟進改善 / KPI 不符?」→ Sustainment plan - 「Closure 前收益還未全達標怎麼辦?」→ 可在 sustainment 才實現,不要求 closure 前全達 - 「Sustainment 兩大職責?」→ 持續實現 + 持續監督 - 「Closure 後維持期問題看?」→ Benefits 四段最後一份(Sustain)

陷阱:Closure 條件是「outcomes(直接成果)達成」,不是 benefits(長期效益)全實現;benefits 可能要 sustainment 階段才完全顯現。

題號:模擬1 Q138 · 模擬1 Q151 · 模擬A Q139 · 模擬A Q152 · 模擬A Q154 · 模擬B Q10 · 模擬B Q70 · 模擬B Q149 · 模擬x Q20 · 模擬x Q21 · 模擬x Q140 · 模擬x Q163

子主題 7: Transition 階段 — 從 program 移交運營

核心:Transition Plan = program-to-operations 移交的 forward-looking 指南,規範「交付活動 + 流程 + 接收方」,從 development 到 operational 的步驟。題目出現「計畫如何移交 / plan how」、「依賴斷裂 / 接力」、「receiving organization readiness」、「administration 負面 = 使用不安心」皆對應 Transition plan。Transition plan 必須生命週期全程執行(早期溝通 + 漸進準備)才能防 stakeholder 抵抗;且要公開 review、透明全體一致。

出題形式: - 「計畫如何移交(plan how)?」→ Transition plan(forward-looking) - 「接收組織準備度 + 驗收標準?」→ Benefits Transition 階段 - 「Stakeholder 負面 / Administration 不安心?」→ 先看 Transition plan 是否清楚 - 「組件依賴斷裂、接力要重規劃?」→ Transition plan - 「Product 交付 + 流程屬於?」→ Transition plan - 「Program 結束後的收益實現如何規範?」→ Transition plan(計畫如何移交 + 後續實現)

陷阱:「計畫如何移交」是 plan(forward-looking),不是 report(已發生事實);Transition request 給 GB 屬於 Direct and Manage execution 標準輸出。

題號:模擬1 Q27 · 模擬1 Q162 · 模擬A Q30 · 模擬A Q162 · 模擬B Q13 · 模擬B Q82 · 模擬B Q100 · 模擬B Q122 · 模擬B Q127 · 模擬B Q128 · 模擬B Q167 · 模擬x Q53 · 模擬x Q103 · 模擬x Q133 · 模擬x Q136

子主題 8: Closure 與收益的關係 + Outcomes vs Benefits

核心:Program Closure 的判斷依據是 Program Management Plan 中明文的關閉準則(exit criteria) + governance approval,不是 PM 個人判斷。Closure 三必要 = (1) plan 中關閉條件達成;(2) Sustainment 移交;(3) Governance approval。Component closure 觸發 = deliverables completed(不是 benefits realized),因 benefits 在 sustainment 後續實現。但 component closure 前的驗證核心 = benefits realization metrics 達標(收益指標勝過技術指標)。Outcomes vs Benefits:Outcomes 是直接成果、Benefits 是長期效益。

出題形式: - 「Closure 的依據?」→ PMP 明文關閉準則 + governance approval - 「Closure 三必要?」→ Plan 條件達成 + Sustainment 移交 + Governance approval - 「Closure 階段才發現收益達不到?」→ 取消是正確選擇(不能擅自擴範圍) - 「Component closure 觸發點?」→ Deliverables completed - 「Component closure 前驗證核心?」→ Benefits realization metrics 達標 - 「Closeout 前 PgM 動作?」→ 與 sponsor 一起 review BMP

題號:模擬1 Q4 · 模擬1 Q15 · 模擬1 Q131 · 模擬A Q25 · 模擬A Q46 · 模擬A Q53 · 模擬A Q161 · 模擬B Q107 · 模擬B Q134 · 模擬x Q7

子主題 9: 戰略改變 / 商業環境變化 → 先評估收益對齊

核心:戰略改變的第一檢測 = expected benefits 是否仍對齊新戰略。標準動作鏈 = 評估 BMP → 改 Plan → 走 CR;對齊先於更新。健康度恢復順序 = 戰略對齊 → roadmap 修訂 → BM 落實 → execution(Recovery 雙拳:Roadmap 重對齊 + BM 重收益)。

出題形式: - 「戰略變化的第一動作?」→ 評估 BMP 是否仍對齊新戰略 - 「商業環境變動 → 第一步?」→ 評估 BMP(收益是否仍可達/仍相關) - 「Governance 在戰略變化時第一關切?」→ Strategic alignment 是否仍成立 - 「戰略改變 → 先看什麼?」→ 先看收益對齊 - 「程式失對齊 + 收益不清?」→ 修訂 roadmap + 落實 benefit management

題號:模擬1 Q75 · 模擬1 Q105 · 模擬1 Q132 · 模擬A Q108 · 模擬A Q133 · 模擬B Q138 · 模擬B Q142 · 模擬B Q161 · 模擬x Q149

子主題 10: KPI 設計 — 由上而下 + 容忍區間觸發

核心:KPI 永遠 由上往下 設計(org → program → component),向上對齊組織戰略。KPI 兩大功能 = 測量 + 觸發;介入時機 = 超出容忍區間(tolerance band) 才動,沒超出不報告(Exception reporting principle),避免微管與資訊雜訊。Metrics 設計三特性 = 量化 + 定期 + 對照基準;設計原則「通用 + 客觀 + 可比」,滿足所有 stakeholder 不為某一人客製。

出題形式: - 「KPI 設計順序?」→ Org → Program → Component(由上而下) - 「KPI 介入時機?」→ 超出容忍區間才動(別微管) - 「KPI 在容忍度內要不要報告?」→ 不需要(Exception reporting) - 「KPI 觸發機制?」→ 警戒線啟動計畫應對(tolerance-based response) - 「Metrics 設計三特性?」→ 量化 / 定期 / 對照基準 - 「Metrics 應通用還客製?」→ 通用設計滿足所有 stakeholder - 「M&A 合併執行核心?」→ KPI 對齊

題號:模擬1 Q7 · 模擬1 Q23 · 模擬A Q18 · 模擬A Q32 · 模擬B Q21 · 模擬B Q27 · 模擬x Q42 · 模擬x Q45 · 模擬x Q127

子主題 11: Benefits 監督工具 + Gate Review 收益評估

核心:監督 benefits metrics 屬於 Performance Analysis & Reporting;工具是統計類、模擬類、變異類 — 收益監督三件套 = Variance + What-if + Simulation。Critical Chain / Critical Path / PERT 是排程方法,與收益監督無關,在收益題選項中幾乎必為干擾項。Gate review 雙軸 = 實際已實現收益 + BMP 跟蹤報告;三看 = 治理 + 收益 + 風險(缺一不可),但不評估 component 啟動行為(屬執行細節)。Benefits 分析雙工具 = Maps 視覺 + Models 邏輯。

出題形式: - 「監督 benefits metrics 屬於哪個過程?」→ Performance Analysis & Reporting - 「下列哪個不是收益監督工具?」→ Critical Chain / Path / PERT(干擾項) - 「Gate review 評估什麼?」→ 治理 + 收益 + 風險(實際收益 vs BMP 跟蹤) - 「Gate 決策依據三層?」→ Status report → Performance → Benefits - 「Variance analysis 用途?」→ 計畫 vs 實際差異分析 - 「報告太細缺少摘要視覺化?」→ Dashboard(KPI 顏色高層視圖) - 「Benefits ↔ outputs 分析工具?」→ Benefits maps + modelling tools

題號:模擬1 Q3 · 模擬1 Q23 · 模擬1 Q85 · 模擬1 Q86 · 模擬1 Q122 · 模擬A Q15 · 模擬A Q123 · 模擬A Q144 · 模擬B Q31 · 模擬x Q5 · 模擬x Q62 · 模擬x Q121

子主題 12: Program = 產生 strategic benefits 的協調機制(核心目的)

核心:Program 存在的根本目的 = 透過協調管理產出 strategic benefits(整合收益 = 1+1>2)。PMI 標準定義三要素 = 相關項目/子 program/活動 + 協調管理 + 個別不可得的收益和控制。Program vs Project 核心差 = 收益階段性實現 + 中期資金獲取(多階段 + 收益累積)。Program 三大死亡情境 = 戰略改變 / ROI 不可達 / 收益基礎消失(三者都建議 cancel)。新組件納入的核心考量 = Benefits 是否強化整體收益;Program 選擇鐵律 = 收益勝過所有其他指標。Sponsor 視角優先序 = Benefits 對齊 > 財務 > 執行。Program 啟動第一步 = 量化收益(收益量化在前,結構在後)。

出題形式: - 「Program 存在目的?」→ 產生 strategic benefits - 「Program 與 Project 核心差?」→ 收益階段性 + 中期資金獲取 - 「Program 何時應該取消?」→ 戰略改變 / ROI 不可達 / 收益基礎消失 - 「『不可能交付收益』時?」→ 終止 program(失去存在理由) - 「新組件納入核心考量?」→ Benefits(是否強化整體收益) - 「Program 選擇最重要標準?」→ 收益 - 「Sponsor 視角優先序?」→ Benefits 對齊 > 財務 > 執行 - 「Program 啟動第一步?」→ 量化收益 - 「實際交付收益這個動作屬於哪個過程?」→ Direct and Manage Program Execution(過程),Benefits management 是領域

陷阱:「交付收益」過程 vs 「benefits management」領域 — 題目問過程選 Direct and Manage Program Execution,問領域選 Benefits management(模擬1 Q26 / 模擬A Q35)。

題號:模擬1 Q22 · 模擬1 Q26 · 模擬1 Q35 · 模擬A Q9 · 模擬A Q20 · 模擬A Q31 · 模擬A Q35 · 模擬A Q44 · 模擬A Q83 · 模擬A Q140 · 模擬B Q83 · 模擬B Q84 · 模擬B Q88 · 模擬B Q113 · 模擬B Q116 · 模擬B Q132 · 模擬x Q69 · 模擬x Q81 · 模擬x Q164 · 模擬x Q166 · 模擬x Q168

治理與變更管理

PgMP 第二大坑:從「誰決定、誰批准、什麼時候開會、變更怎麼走」一路打底到「PgM 何時要服從、何時要堅持」的治理紀律全集。 收錄 96 條原料,聚類為 14 個知識點

子主題 1: Governance Plan 五要素

核心:Governance Plan 標準五要素(PMI 4th)= (1) 角色職責 (2) 治理結構/組成 (3) 治理目標 (4) 階段 Gate Review 規劃 (5) 定期 Health Check。口訣「角結目關健」。執行層面再加「會議時間表」(含 gate + health + audit 三種會議)。

出題形式: - 「Governance plan 包含哪些?」→ A/B/C 都是其元素,選 ALL - 「新成員不懂自己角色怎辦?」→ 回頭看 governance plan,若沒寫清楚就修 plan - 「Steering 拒絕啟動組件,為什麼?」→ governance plan 缺啟動標準(plan 沒寫,steering 無依據批准) - 「Steering committee management plan 是 PMI 標準子計畫嗎?」→ 不是(steering 是治理結構,不是被管理對象)

陷阱:把 governance plan 跟其他子計畫混為一談。子計畫名單記為「範進成質風採資沟 SEP 治益財」12 個,沒有 steering committee plan。

題號:模擬1 Q33 · 模擬A Q42 · 模擬B Q47 · 模擬B Q79 · 模擬B Q135 · 模擬x Q65 · 模擬x Q94 · 模擬x Q158

子主題 2: Gate Review vs Health Check vs Audit 三種檢核

核心:三種治理檢核分工固定:Gate Review 提前固定日(治理紀律,里程碑審查) vs Health Check 按需安排(彈性診斷,即時反映狀況) vs Audit 第三方獨立。常被合稱「Gate 固定、Health 按需、Audit 第三方」。

出題形式: - 「程式正常績效進展,該用什麼?」→ Health check(不是 gate review,gate 是里程碑關卡) - 「Health check 多久排一次?」→ 按需,不是死板年度體檢 - 「治理檢核三件套?」→ Gate / Health / Audit

陷阱:把 Health check 當成「年度體檢」固定排,或把 Gate 當成「按需」彈性辦。兩者倒過來都錯。

題號:模擬1 Q37 · 模擬B Q33 · 模擬x Q66 · 模擬x Q73

子主題 3: Gate Review 主審文件與決策依據

核心:Gate Review 主審文件 = PMP(Program Management Plan,整合性視圖含所有子計畫);子計畫只是支撐材料。Go/No-Go 決策依據三層 = Status Report(實際績效快照)→ Performance(SPI/CPI)→ Benefits(對照 BMP)。收益評估走「實際 vs BMP」雙軌。Gate review 三看 =「治理 + 收益 + 風險」,不評估 component 啟動行為(那屬執行細節)。

出題形式: - 「Gate review 主審哪份文件?」→ PMP / Program Management Plan - 「Gate review 用什麼判 go/no-go?」→ Status report(PMP 是計畫不是現況) - 「Gate review 對照誰評估收益?」→ BMP - 「Gate review 不評估下列哪項?」→ component 啟動行為

陷阱:選「BMP / Benefits report」當主審文件 — 那是收益評估的對照基準,不是 gate 主審。

題號:模擬1 Q44 · 模擬1 Q122 · 模擬1 Q143 · 模擬1 Q161 · 模擬A Q52 · 模擬A Q123 · 模擬A Q144 · 模擬B Q31 · 模擬x Q62 · 模擬x Q87

子主題 4: Gate Review Go/No-Go 決策權與取消準則

核心:Phase Gate Review 的 Go/No-Go 決策權屬於 Program Governance Board(治理委員會),PgM 只負責報告。三定律「Gate 屬治理、Go 屬 board、PgM 報告」。取消判斷看績效綜合分數(SPI + CPI + ROI + 風險),三紅燈即取消;或看財務淨值(Revenue - Cost)最差的取消。決策三選:Go / No-Go(= terminate) / Hold。

出題形式: - 「Phase gate 的 go/no-go 誰拍板?」→ Program governance board - 「Gate review 取消哪個 component?」→ 算 SPI/CPI/ROI 三紅燈或財務淨值最差 - 「Benefit 無法實現,誰決定取消?」→ Sponsor 核實 → Governance 取消(PgM 識別而已)

題號:模擬1 Q93 · 模擬A Q70 · 模擬A Q83 · 模擬A Q84 · 模擬A Q96

子主題 5: Gate Review 是治理紀律,不可妥協

核心:Gate Review 是 治理機制,不因客戶滿意/表現好/外部要求而取消。「Gate review 不取消、不縮減、不協商」。即將到 gate 時用既有 go/no-go 標準評估,不是改流程,而是套用標準。

出題形式: - 「客戶覺得 gate review 多餘,要 PgM 取消,該怎辦?」→ 堅持治理流程,gate 是 PgM 對治理的承諾 - 「快到 gate 怎準備?」→ 用已有 go/no-go 標準評估 → 對標 → 上報

陷阱:選「為了客戶滿意度跳過 gate」/「精簡 gate 流程」一律錯。

題號:模擬1 Q128 · 模擬A Q129 · 模擬x Q16

子主題 6: Governance 三柱 = Sponsor + GB + PMO

核心:Program Governance 結構建立在 Sponsor + Governance Board(GB) + PMO 三柱上,缺一即失。Sponsor 三責 = Resource + Funding + Success(資源、資金、成功促進)。Governance 四大活動 = 評估 / 指導 / 監督 / 決策,評估績效是首要;會議標準輸出 = Go/No-Go decisions + Decision Register。PMIS 五角色貢獻 = Sponsor + GB + PMO + Team + PgM,缺一不可。

出題形式: - 「Sponsor 缺席 + GB 不運作 + PMO 解散,是什麼問題?」→ 治理(governance)結構崩潰 - 「Sponsor 主要責任?」→ Resource + Funding + Success - 「Governance oversight 會議標準輸出?」→ Go/No-Go + Decision Register - 「治理結構崩潰怎辦?」→ 先建 governance 結構,再談其他

陷阱:Sponsor 個人批准不取代委員會;PMO 只是流程模板提供者,不是決策方。

題號:模擬1 Q115 · 模擬1 Q119 · 模擬A Q90 · 模擬A Q116 · 模擬B Q54 · 模擬B Q129 · 模擬x Q22 · 模擬x Q108

子主題 7: Governance Board 拒絕新組件 = 戰略對齊不足

核心:Governance Board 把關核心 = Strategic Alignment(戰略對齊)。新增 component 必須證明能貢獻 program 戰略目標和預期收益,否則一律拒絕。Board 三看「戰略對齊 + 收益清楚 + 風險可控」,缺一即拒。CR 被拒最常見根因 = 外部 stakeholder 立場分歧(若 board 含 4 名外部代表)→ 治理變更前先做 stakeholder pre-alignment(私下協調有投票權的外部代表)。

出題形式: - 「Board 為什麼拒絕新組件?」→ 戰略對齊驗證不足 - 「CR 漏拉外部 stakeholder 對齊,後果?」→ Governance approval 失敗

題號:模擬1 Q5 · 模擬1 Q31 · 模擬x Q9 · 模擬x Q61

子主題 8: CCB 雙層架構與層級對應原則

核心:CCB 層級對應原則 = 變更影響範圍對應到變更批准層級。影響單一 project → Project CCB;跨 project 或影響架構 → Program CCB;戰略影響 → Governance Board。容忍區間(tolerance,例如 5%)內處理在 project,超出進 program CCB。範圍變更應在「適當的治理層級」,不是死板對應到 PM 或 PgM 個人身份 — 「影響決定層級,不是身份決定」。

出題形式: - 「Scope 變更僅限單一 project,誰批准?」→ Project CCB - 「5% 容忍區間是什麼概念?」→ Tolerance,內部 project 處理,超出進 program - 「Component scope 變更走哪個層級?」→ 適當的 governance level(看影響範圍)

陷阱:選「所有變更都走 program CCB」/「PgM 自己批就好」一律錯。

題號:模擬1 Q121 · 模擬1 Q144 · 模擬A Q122 · 模擬A Q145 · 模擬B Q41 · 模擬x Q82

子主題 9: Change Request 必走流程(治理紀律核心)

核心:任何 program 範圍變更(不論大小、不論是否為強制法規變更)都必須走 正式變更控制流程(integrated change control),PM 不能單方決定接受或拒絕。三步「評估 + 治理 + 撥款」。即使團隊已自行修復(繞過 CCB),也必須回頭補正式 CR,確保變更可追溯。Baseline 變更鐵律「先 CR 再改 baseline」。新組件加入也走 CR 流程「CR → 評估 → Board 審 → 整合」。

出題形式: - 「客戶提變更,PgM 第一動作?」→ 評估 + 治理 + 撥款,不單方決定 - 「Mandatory change(法規)該怎走?」→ 走 CR 接受延遲,不能強壓進度 - 「團隊已修復但繞過 CCB,怎處理?」→ 接受修復但回頭補正式 CR - 「新組件加入 program?」→ 走變更請求

陷阱:選「Fast track / Crash / Leveling」壓縮進度繞過 mandatory change 一律錯;選「PgM 直接批准小變更」也錯。

題號:模擬1 Q10 · 模擬1 Q58 · 模擬1 Q82 · 模擬A Q85 · 模擬A Q86 · 模擬A Q159 · 模擬A Q161 · 模擬x Q8 · 模擬x Q19 · 模擬x Q115

子主題 10: Closure 必有 Governance Approval

核心:Program / Component Closure 是 governance act,必須由 Steering Committee / Governance Board 正式批准。Closure 三必要 = (1) Plan 中關閉條件達成 (2) Sustainment 移交 (3) Governance Approval。Closure 前最後一步 = 與 sponsor + GB 共同 review,雙人組缺一不可。Closure 順序「取得批准 → 執行收尾 → 報告 → 歸檔」。當委員會決定 closure / sponsor 已決終止,PgM 職責是執行不挑戰 — 治理紀律「Sponsor 決,PgM 執」「Board 決、PgM 行,不挑戰」。

出題形式: - 「什麼能阻止 closure?」→ 缺 governance approval(其他都是 PM 內部任務) - 「Component closure 最終決定權誰有?」→ Governance Board - 「Sponsor 已決終止,PgM 該?」→ 執行終止,不挑戰 - 「Closure 前最後一步?」→ 與 sponsor + GB 共同 review

陷阱:選「PgM 評估後自行決定 closure」/「爭辯型答案反駁委員會」一律錯。

題號:模擬1 Q15 · 模擬1 Q32 · 模擬1 Q90 · 模擬1 Q109 · 模擬A Q25 · 模擬A Q94 · 模擬B Q65 · 模擬B Q157 · 模擬x Q63 · 模擬x Q130

子主題 11: Component 啟動需 Steering Committee 批准

核心:所有 component lifecycle event(啟動 / 關閉)都走 governance 正式流程,不能個人批准(Sponsor 個人簽字不取代委員會)。組件啟動正式批准權 = Steering Committee(治理層,不是 stakeholder / sponsor / 其他 PM)。Steering 評組件啟動 = 先看是否符合 governance plan 中的啟動標準;若 plan 沒寫標準,steering 無依據批准。Component 啟動最根本要件 = Business Case(沒有 BC = 沒有 governance 評估的根據)。

出題形式: - 「Sponsor 個人批准 component 啟動可以嗎?」→ 不可,要走 steering committee - 「Steering 拒絕啟動為什麼?」→ Governance plan 缺啟動標準 - 「Component 啟動最根本需要什麼?」→ Business case

題號:模擬1 Q79 · 模擬1 Q81 · 模擬B Q79 · 模擬x Q157 · 模擬x Q158

子主題 12: Definition Phase 輸出含 Governance Structure

核心:Program 兩大 phase = Definition + Delivery。Definition phase 核心輸出四件「章任路治」= (1) Charter (2) Program Manager + Sponsor 任命 (3) Roadmap (4) Governance Structure。Input = 組織戰略 + Business Case;Output = Charter + PMP + Roadmap + Governance。Governance 結構在 Definition 階段就建立,與 Charter / Roadmap 同期。

出題形式: - 「Definition phase 輸出?」→ 章程 + 人員任命 + Roadmap + 治理結構 - 「Governance 結構什麼階段建立?」→ Definition

題號:模擬1 Q69 · 模擬1 Q77 · 模擬B Q89 · 模擬x Q137

子主題 13: Escalation 鏈與治理層級

核心:Escalation Process 處理「需要更高層決策的內部事項」三類「問風變」(Issues / Risks / Change Requests);Regulations 是 EEF 不在升級流程內。標準升級鏈「PM 升 PgM → PgM 找 Sponsor → Sponsor 找 GB」,衝突解決階梯「直接溝通 → 協商 → 升級 sponsor → 升級 governance」。組件問題不該全在組件層解決,部分必須升級到 program 級(治理層級互通)。當 PM 跳級通報 sponsor,PgM 要雙重處理 — 解問題 + 修正 escalation 路徑(培訓 PM 應先通知 PgM)。PgM 沟通四向 = 客戶(外)+ Sponsor(上)+ Steering(治)+ 組件經理(下)。

出題形式: - 「升級流程處理什麼?」→ Issues / Risks / Changes(法規不在) - 「PgM 協商失敗的衝突,下一步?」→ 升級 sponsor - 「PM 越級通報 sponsor,PgM 該?」→ 雙重處理 — 解問題 + 修通報鏈 - 「PgM 沟通三軸/四向?」→ 上下外(三向),加治理 = 四向

陷阱:選「直接跳最高層」/「PgM 強壓 PM」一律錯;regulations 屬 EEF 不走 escalation。

題號:模擬1 Q54 · 模擬1 Q142 · 模擬A Q91 · 模擬A Q143 · 模擬B Q14 · 模擬B Q17 · 模擬B Q95 · 模擬B Q137 · 模擬x Q28 · 模擬x Q34

子主題 14: 治理透明 / Dashboard / 戰略一致

核心:Program Governance PMI 標準定義 = Framework + Functions + Processes (FFP),目標達戰略與營運目標。戰略改變後 governance 第一關切 = strategic alignment 是否仍成立;戰略轉型成功的關鍵 = governance approach(治理為骨、領導為魂)。Program Plan 更新觸發 =「Gate review / Portfolio 變動 / 戰略改變」三大觸發。財務 baseline 變動 = 必通知治理 + 審計(透明 + 合規);Tiered funding 是治理層標準作法,PgM 先順從後規劃,不要硬槓組織治理。高層輸出三層「Dashboard(即時紅黃綠燈)→ Performance Report(定期完整)→ PMP(計畫)」— Governance level 看 dashboard,operation level 看 detailed reports;Sponsor 高層級關切要儀表化呈現,Red flag 即時狀態用 dashboard 進 GB 會議。Board 視角聚焦 program 級議題,project 級不報,避免淹沒重點。加速請求 → 「分析影響 + 利弊報告 → Sponsor 決定」/ CBA + GB 決策,涉成本與收益權衡走治理層決定。沟通計畫最終 approver = Sponsor;Plan 三部曲「PgM 制定 → Sponsor 審 → GB 批准」。

出題形式: - 「Program governance 標準定義?」→ Framework + Functions + Processes - 「戰略改變後 governance 第一看什麼?」→ Strategic alignment 是否成立 - 「Sponsor 要看高層即時狀態,用什麼?」→ Status dashboard - 「Baseline 變動該通知誰?」→ 治理 + 審計 - 「CEO 要加速,PgM 該?」→ 評估影響 + 利弊報告 → Sponsor 決定(不直接執行) - 「沟通計畫誰最終批准?」→ Sponsor

陷阱:選「給 sponsor 看 detailed performance report」/「PgM 直接執行 CEO 命令」一律錯。

題號:模擬1 Q16 · 模擬1 Q29 · 模擬1 Q30 · 模擬1 Q74 · 模擬1 Q75 · 模擬1 Q86 · 模擬1 Q89 · 模擬1 Q123 · 模擬A Q26 · 模擬A Q68 · 模擬A Q74 · 模擬A Q78 · 模擬A Q124 · 模擬B Q16 · 模擬B Q57 · 模擬B Q85 · 模擬B Q94 · 模擬x Q17 · 模擬x Q31 · 模擬x Q114 · 模擬x Q132

文件對照(誰寫誰核、何時用)

PgMP 最大坑類型：哪份文件描述什麼、誰寫誰核、什麼時候更新、與其他文件如何連動。Memory 記錄錯題 47 題，幾乎全堆在「Charter vs PMP vs BMP」「Register vs Plan vs Map」「Roadmap vs BMP」這類 trap 上。看到「描述」「展示」「規範」「記錄」等動詞要先停下來判定文件層級與時態。 收錄 142 條原料，聚類為 14 個文件子主題 + 2 個對照速查表

子主題 1: Business Case（商業論證書）

核心：Program 存在的「通行證」。在 charter 之前就生成的最早文件，論證為什麼這個 program 值得做、戰略對齊何在、財務合理性是否成立。任何 component 啟動必須先有 business case 作為治理評估根據。

包含內容： - 戰略對齊論證（why this serves strategy） - 預期收益概念（高層 benefits） - 商業合理性 / 財務論證（ROI、cost-benefit） - 高層假設與約束

何時建立 / 誰寫誰核：Pre-program formulation 階段；由 sponsor / portfolio 提出，governance / sponsor 核准

典型 content：strategic alignment + expected benefits + ROI + 風險論述 + 資源粗估

出題形式： - 「Definition phase 早期資金端新需求變化 → 先回頭驗證什麼？」→ business case（驗證根本假設） - 「Component 啟動最根本要件？」→ business case（沒它連討論都進不去） - 「Program 戰略對齊論證的源頭文件？」→ business case - 「Cost-benefit 合理性權威文件？」→ business case - 「Feasibility 驗證工具」→ business case + SWOT - 「Program 建議完整評估還需什麼文件？」→ business case - 「啟動前識別的 benefits 記錄在哪？」→ business case

陷阱： - 與 Charter 易混 — BC 是「值不值得做」（論證），Charter 是「正式授權做」（authorization）。BC 在前，Charter 在後 - 與 BMP 易混 — BC 是高層收益概念，BMP 是細部規劃。BC 全面論證、BMP 跟蹤、Register 清單

題號：模擬1 Q24 · Q81 · Q102 · Q126 · 模擬A Q33 · Q41 · Q79 · Q105 · Q127 · 模擬B Q32 · Q61 · Q97 · Q148 · Q164 · 模擬x Q27 · Q64

子主題 2: Program Charter（項目集章程）

核心：Program 的「正式出生證」。批准後 PgM 才正式有權力動用組織資源。Charter 是 high-level vision/scope/benefits 的最佳概覽文件，新 stakeholder 入門必讀 #1。

包含內容（六件套「合願果益組時」）： - 合理性（justification）/ 願景（vision）/ 預期成果（outcomes） - 收益戰略（benefits strategy）/ 高層 scope / 組件結構 / 高層時間線 - 戰略目標（strategic objectives）+ 預期收益（expected benefits） - 假設 / 約束 / 組織需求 - PgM 正式授權 + 資源動用權限（charter 雙核心）

何時建立 / 誰寫誰核：Definition phase；由 PgM 主導草擬，governance board / sponsor 正式批准

典型 content：vision + strategic objectives + expected benefits + high-level scope + assumptions + constraints + organizational needs + PgM 授權

出題形式： - 「新 stakeholder 最快認識 program 的文件？」→ charter（含 program 目標、範圍、收益的完整摘要） - 「Onboarding 新人入門首發材料？」→ charter（最高層級） - 「Program 完成後的『期望收益』記錄在哪？」→ charter（不是 BMP） - 「不了解預期收益的 stakeholder 要重發哪份？」→ charter > BMP（charter 更易讀更概念性） - 「Stakeholder 共同高層期望文件？」→ charter + business case 雙搭配 - 「Definition phase 輸出？」→ charter + 人員任命 + roadmap + governance structure - 「Charter 完成後下一步？」→ 提交 GB 獲授權 → kick-off meeting - 「Charter 雙核心？」→ 授權 program 存在 + 授 PgM 資源權

陷阱： - 與 PMP 易混 — Charter = WHY 與 WHAT；PMP = HOW；Roadmap = WHEN。Gate review 主審 PMP 不是 Charter - 與 BC 易混 — BC 在前是論證，Charter 在後是授權 - Charter 是「戰略結構」不是「執行細節」（50 國細節屬 PMP 層級）

題號：模擬1 Q14 · Q59 · Q67 · Q135 · Q137 · 模擬A Q11 · Q14 · Q40 · Q41 · Q64 · Q72 · Q125 · Q138 · 模擬B Q5 · Q6 · Q19 · Q28 · Q29 · Q61 · Q69 · Q99 · Q125 · Q141 · 模擬x Q10 · Q23 · Q54 · Q56 · Q137 · Q138 · Q139 · Q153

子主題 3: Program Roadmap（項目集路線圖）

核心：Program 的「時間軸總圖」。在時間軸上同時展示 activities + benefits 實現節點 + 關鍵里程碑 + 決策點。Sponsor 級別最直觀工具。

包含內容： - 時間線 + 里程碑 + 決策點 + 收益實現節點 - 高層目標的時序視覺呈現 - Activities ↔ Benefits 視覺橋樑

何時建立 / 誰寫誰核：Definition phase（charter 之後 / PMP 之前的 high-level 推進文件）；PgM 制定，governance 批准

典型 content：時序圖 + 階段門 + 里程碑 + 收益實現節點 + 組件啟動/關閉節點

出題形式： - 「Sponsor 要看 activities ↔ benefits 高層視圖？」→ roadmap（不是 BMP，BMP 太細） - 「建立 activity 與 benefit 關係的視覺橋樑？」→ roadmap - 「Component 啟動 / 關閉後要更新哪份文件？」→ roadmap（roadmap 是「活的時間線」） - 「BMP 修改後必同步什麼？」→ roadmap（BMP ↔ Roadmap 雙向同步） - 「Definition phase 推進順序？」→ 初步批准 → roadmap → charter → PMP → setup - 「Strategic mandate / Strategic plan 的下游？」→ roadmap（roadmap 源頭是戰略）

陷阱： - 與 BMP 易混 — Roadmap = 時序視覺（高層橋樑、大粒度）；BMP = 收益詳細規劃（細粒度）。Sponsor 高層永遠選 roadmap，操作層才看 BMP - 「描述活動」用 plan、「展示時間線」用 roadmap、「邊界」用 scope statement

題號：模擬1 Q14 · Q78 · Q89 · Q125 · Q147 · Q149 · Q170 · 模擬A Q40 · Q93 · Q126 · Q148 · Q150 · Q169 · 模擬B Q19 · Q29 · Q43 · Q66 · Q123 · Q155 · 模擬x Q70 · Q155

子主題 4: Program Management Plan (PMP)（項目集管理計畫）

核心：「所有 plan 的母艦」— 整合所有 subsidiary plans（scope/schedule/cost/quality/risk/procurement/resource/comms/SEP/governance/benefits/financial）。Gate review 主審文件。題目問「描述 X 活動寫在哪」幾乎都選 PMP。

包含內容： - Subsidiary plans 整合視圖 - 各管理 process 描述（含 benefits realization 等活動） - 整合 baselines - Program 整體 how-to 框架

何時建立 / 誰寫誰核：Definition phase；PgM 制定，sponsor / governance 批准；component 變動 + 重大 risk + governance gate 觸發 update（portfolio 變化不在內）

典型 content：整合 plans + how-to-achieve 描述 + baselines + 各子計畫摘要

出題形式： - 「描述 benefits realization 活動寫在哪？」→ PMP（整合所有 plan） - 「跟蹤評估記錄收益的活動描述在哪？」→ PMP（含 BMP 子計畫整體層級） - 「Gate review 主審文件？」→ PMP（含子計畫整合視圖；子計畫只是支撐材料） - 「Definition 階段定義 how 實現戰略目標的整合性文件？」→ PMP（BC 定 why、PMP 定 how） - 「操作層看什麼？」→ PMP（高層 sponsor 看 dashboard、中層看 status report、操作層看 PMP）

陷阱： - 與 BMP 易混 — PMP 整合所有 plan，BMP 是其中一個 subsidiary（專收益子計畫） - 與 Charter 易混 — Charter = WHY/WHAT；PMP = HOW；Roadmap = WHEN - Gate review 主審是 PMP 不是 status report；但 Gate review 的 go/no-go 依據是 status report（PMP 是計畫不是現況）

題號：模擬1 Q44 · Q64 · Q67 · 模擬A Q52 · Q69 · Q72 · 模擬B Q5 · Q19 · 模擬x Q10 · Q87 · Q143

子主題 5: Benefits Management Plan (BMP)（收益管理計畫）

核心：Benefits Analysis & Planning 階段的「畢業證書」。指導整個 program 的收益管理工作 — 定義 metrics、targets、實現時序、維持安排、收益責任分配。是評估收益實現進展的「藍圖」與「評分卡」。

包含內容： - Benefits metrics + KPI + target - 各收益的 when / how / 誰負責 - 收益實現時序 - 收益實現後的維持安排 - 與 roadmap 對應的時間節點

何時建立 / 誰寫誰核：Benefits Analysis & Planning 階段（即 Definition phase 內）；PgM 制定，sponsor / governance 批准

典型 content：metrics + KPI + target + 實現時序 + 維持安排 + benefit owner

出題形式： - 「Benefits Analysis & Planning 階段主要輸出？」→ BMP - 「可量化收益目標（投訴減 30%）記錄在？」→ BMP（expected benefit + metric） - 「Metrics / KPI 的官方文件？」→ BMP - 「Gate review 對照什麼評估收益交付？」→ BMP（藍圖） - 「評估 program 收益進展的標準文件？」→ BMP - 「BMP 描述 benefits 如何實現 + outcomes 如何交付」 - 「商業環境改變先評估什麼？」→ BMP（收益是否仍可達 / 仍相關） - 「戰略改變第一動作？」→ 先審 BMP 對齊評估 - 「BMP 修改後 → 必同步 roadmap」 - 「Closeout 前 → 與 sponsor 一起 review BMP」

陷阱： - 與 Roadmap 易混 — BMP 細粒度（如何）、Roadmap 大粒度（時間總圖） - 與 Register 易混 — BMP = 藍圖 / 計畫；Register = 進度條 / 清單狀態 - 與 Charter 易混 — Charter 寫「期望收益」概念，BMP 寫「收益細部規劃」 - 與 Business Case 易混 — BC 全面論證、BMP 跟蹤、Register 清單

題號：模擬1 Q26 · Q76 · Q78 · Q101 · Q105 · Q136 · Q149 · Q150 · Q153 · Q157 · Q158 · Q161 · 模擬A Q35 · Q104 · Q108 · Q137 · 模擬B Q1 · Q8 · Q26 · Q83 · Q138 · Q142 · Q144 · 模擬x Q2 · Q52 · Q149 · Q166

子主題 6: Benefits Register（收益登記冊）

核心：Benefits 的「清單與進度條」。記錄每個收益的當前狀態（識別 / 規劃 / 實現中 / 已實現），是顯示「收益實現進度」的最佳工具。Identification 階段的早期產出。

包含內容： - 各收益的 metrics + KPI + 衡量過程 - 當前實現狀態（識別 / 規劃 / 實現中 / 已實現） - Benefit owner / 受益者

何時建立 / 誰寫誰核：Benefits Identification 階段早期產出（早於 BMP）；PgM 維護，sponsor 監督

典型 content：收益清單 + metrics + 當前狀態 + owner

出題形式： - 「顯示收益實現進度的文件？」→ benefits register（當前狀態） - 「Benefits 進展展示用什麼沟通？」→ register（含當前實現狀態，是現況證據） - 「Register 核心內容？」→ metrics + KPI + 衡量過程 - 「當地化收益要更新什麼？」→ benefits register（承諾客製化 + 後續追蹤）

陷阱： - 與 BMP 易混 — BMP = 計畫（如何）；Register = 清單（當前狀態） - 「展示狀態」用 register、「描述如何實現」用 BMP、「時間線」用 roadmap

題號：模擬1 Q76 · 模擬A Q120 · 模擬B Q3 · Q104 · 模擬x Q6 · Q104

子主題 7: Benefits Transition Plan / Sustainment Plan（收益移交 / 維持計畫）

核心：兩份配套文件，處理 program 結束後的收益延續。Transition plan 規範「如何移交給運營」；Sustainment plan 規範「移交後如何持續維持與監督」。

包含內容： - Transition plan：移交活動 + 接收方準備度 + 驗收標準 + 流程；交付後的步驟 - Sustainment plan：移交後持續實現 + 持續監督 + KPI 追蹤 + feedback / improvement 機制

何時建立 / 誰寫誰核：Benefits Planning 階段制定；Delivery / Transition / Sustainment 階段執行；PgM 制定，sponsor / 接收 ops 共同核准

典型 content（Transition）：移交活動 + 流程 + 接收方培訓 + 驗收標準 + 接班人員整合

典型 content（Sustainment）：移交後監督 + KPI 持續追蹤 + 改善機制 + feedback 提交流程

出題形式（Transition）： - 「計畫如何移交」（forward-looking）→ transition plan，不是 report - 「移交運營議題」→ transition plan - 「Product 交付活動 + 流程」→ transition plan - 「從 development 到 operational 的步驟」→ transition plan - 「依賴關係斷裂 = transition plan 重新規劃」 - 「Stakeholder 對 admin 負面 = 看 transition plan 是否清楚」 - 「Stakeholder 抵抗預防 = transition plan 早期執行 + 全週期」

出題形式（Sustainment）： - 「交付後 6 個月發現不符 KPI / 後續跟進舉措」→ sustainment plan - 「已交付但未追蹤維持」→ sustainment plan - 「Benefits 維持階段問題」→ sustainment plan - 「收益可在 sustainment 階段才實現」（不要求 closure 前全達）

陷阱： - 三 plan 分工：BMP 規劃 → Transition 移交 → Sustainment 維持 - 「Plan vs Report 時態」：未來 / 將要 → plan；已發生 → report

題號：模擬1 Q27 · Q138 · Q151 · Q152 · Q162 · 模擬A Q30 · Q47 · Q139 · Q152 · Q154 · 模擬B Q10 · Q13 · Q68 · Q82 · Q100 · Q167 · 模擬x Q20 · Q53 · Q103 · Q136 · Q163

子主題 8: Stakeholder Register（干系人登記冊）

核心：Stakeholder 的「靜態名單」。Identification 階段的標準產出。包含 expectation、interest、influence、engagement strategy 等欄位。

包含內容： - 各 stakeholder 基本資料 - 期望（expectation）/ 興趣 / 影響力 / engagement strategy - 沟通需求

何時建立 / 誰寫誰核：Identification 階段；PgM 制定，動態維護；新人進出、stakeholder 變化即更新

典型 content：名單 + 期望 + 影響力 + 態度 + engagement strategy + 沟通需求

出題形式： - 「Identification 階段主要產出？」→ stakeholder register - 「Stakeholder register 內容？」→ expectation + interest + influence + engagement strategy - 「Stakeholder 進出 → register 必更新 + 通知相關方」 - 「新成員加入 → 更新 register + 通知」 - 「儲存 stakeholder 資訊（含沟通需求）的權威文件」→ register - 「Stakeholder identification → 建立 register」（漸進更新） - 「Program stakeholder register = program 獨有 + 組件 key 都要」 - 「靜態列表用 register；要量化用 metrics；要視覺用 map」

陷阱： - 與 SEP 易混 — Register 靜態名單；SEP 動態管理計畫（見子主題 9） - 與 Map 易混 — Register 詳細欄位、Map 視覺化關係、Analysis 動態評估 - 「Stakeholder 四件套」：Register 存 + Analysis 分析 + Map 視覺 + Log 記事

題號：模擬1 Q6 · Q39 · Q83 · Q148 · Q154 · 模擬A Q17 · Q21 · Q80 · Q149 · 模擬B Q45 · Q56 · Q60 · Q152 · 模擬x Q11 · Q90 · Q112 · Q120 · Q145 · Q165

子主題 9: Stakeholder Engagement Plan (SEP)（干系人爭取計畫）

核心：Stakeholder 動態管理的「第一手冊」。Analysis 之後立即產出，描述如何 engage、跟蹤、管理 stakeholder 期望，是整個生命周期的 stakeholder 動態管理文件。Stakeholder 任何反應永遠先回 SEP。

包含內容： - 各 stakeholder 的 engagement strategy - 期望管理規劃 - Engagement 跟蹤指標 - 與沟通計畫的銜接

何時建立 / 誰寫誰核：Identification + Analysis 之後（與 Register 同期出生）；PgM 制定，sponsor 核准；分發給所有 components + non-project work

典型 content：engagement strategy 矩陣 + 期望追蹤 + 跟蹤頻率 + 動態管理機制

出題形式： - 「Stakeholder analysis 後緊接什麼？」→ SEP + Register 雙輸出 - 「Stakeholder 出現負面反應第一動作？」→ 回到 SEP 找預定 engagement strategy - 「Stakeholder 期望管理規劃文件？」→ SEP - 「Stakeholder engagement 影響 → 更新 SEP」 - 「SEP 描述如何 engage、跟蹤、管理期望」 - 「SEP 完成 → 分發給所有相關方（含 component + non-project work）」 - 「Sponsor 端變化通常觸發 → 沟通計畫 + SEP 雙更新」

陷阱： - 與 Register 易混 — Register = 靜態名單；SEP = 動態管理 / engagement strategy - 與 Communications Plan 易混 — SEP → Comms Plan（comms plan 從 SEP 派生，定方向由 SEP 來）

題號：模擬1 Q6 · Q28 · Q80 · Q120 · Q164 · Q166 · 模擬A Q17 · Q36 · Q37 · Q54 · Q121 · 模擬B Q2 · Q108 · 模擬x Q11 · Q117 · Q159

子主題 10: Communications Management Plan（沟通管理計畫）

核心：定義 who / what / when / how / why 的沟通框架。從 SEP 派生（誰需要什麼資訊、頻率、媒介）。也定義角色、職責、流程、資訊儲存位置。

包含內容： - 沟通的 who / what / when / how / why - 角色與職責（含資訊保存位置） - 沟通頻率 / 媒介 / 文化考量 - 沟通任務分配

何時建立 / 誰寫誰核：SEP 之後立即制定；PgM 制定，sponsor 為最終 approver；sponsor 端 / SEP / stakeholder 變化即更新

典型 content：沟通矩陣 + 頻率 + 媒介 + 角色職責 + 文化禁忌

出題形式： - 「分發資訊 who/what/when/how 的文件？」→ communication management plan - 「SEP 批准後 → 制定 program communications plan」（順序） - 「該員的職責定義（資訊保存位置）保存在哪？」→ comms plan（plan 定規定 / log 是執行結果） - 「沟通任務分配規定？」→ comms plan - 「文化差異整合處理？」→ 更新 communications plan - 「沟通計畫最終 approver？」→ sponsor（PgM 是制定者） - 「跨組件 comms 不一致 → 拉到 program 層整合 comms plan」 - 「沟通不足診斷雙文件」→ comms plan + stakeholder register

陷阱： - 與 Communication Log 易混 — Plan 定規則、Log 記事件、Report 出結果 - Project 內沟通議題 → PM 審；Program 級 → PgM 審

題號：模擬1 Q110 · Q116 · Q120 · Q123 · Q148 · Q166 · 模擬A Q38 · Q54 · Q112 · Q114 · Q117 · Q121 · Q130 · Q140 · Q149 · Q166 · 模擬B Q22 · Q59 · Q101 · Q137 · Q140

子主題 11: Risk Register / Risk Plan（風險登記冊 / 風險計畫）

核心：所有識別風險的完整紀錄（含 threat + opportunity 雙面），不可預先過濾。Risk planning 完成後設立 contingency reserve。Risk response 規劃完成必須更新 register。

包含內容： - 所有已識別風險（不論可控與否） - Threat + Opportunity 雙面 - 風險評估 + 優先級 + response strategy - 應急儲備（contingency / management reserve）

何時建立 / 誰寫誰核：Risk Identification 後立即建立；PgM 維護；失敗事件後先審查、再延伸識別、後更新；Risk M&C 階段持續監控

典型 content：風險清單 + 機率 + 影響 + response + 觸發條件 + reserve

出題形式： - 「Risk identification 結果記在哪？」→ risk register - 「所有識別風險（包含可控）都要記 register」（先記後篩） - 「Opportunity 也記 register」→ risk register 含 threat + opportunity 雙面 - 「Program 層機會記 program risk register」（不是 component） - 「失敗事件後順序」→ 回顧現有 register → 延伸識別 → 更新 - 「Risk response 規劃完成 → 設立 contingency reserve + 更新 register」 - 「Trigger conditions monitoring」→ Risk M&C 階段

陷阱： - Risk register 與 BMP 關係 — 「可能」（may）含影響收益的風險，不是必須，也不能合併（文件獨立、可連結、可互引，不合併） - Reserve 兩種：Contingency（PM 控制 / 已知未知）+ Management（sponsor 控制 / 未知未知）

題號：模擬1 Q56 · Q57 · Q84 · Q108 · Q124 · Q165 · 模擬A Q88 · Q101 · Q111 · Q125 · 模擬B Q9 · Q76 · Q103 · Q117 · Q163 · Q169 · 模擬x Q26 · Q77 · Q111 · Q113

子主題 12: Scope Statement（範圍說明書）

核心：Charter 之後最先要詳化的文件。具體化範圍 / 限制 / 驗收 / 假設。是 stakeholder 共識基礎文件，確立 program 方向 + 基本面。

包含內容（四件套「範邊假驗」）： - 範圍（scope / limit）/ 邊界（boundary） - 假設與約束（assumption / constraint） - 驗收標準（acceptance criteria） - 期望 + 業務影響（business impact）

何時建立 / 誰寫誰核：Definition phase（Charter 之後）；PgM 制定，sponsor 批准

典型 content：scope/limit + boundary + assumption/constraint + acceptance + 期望 + business impact + deliverables

出題形式： - 「Scope statement 標準四要素？」→ 範圍 + 邊界 + 假設約束 + 驗收 - 「Scope statement 涵蓋？」→ 範圍 + 限制 + 期望 + 業務影響 - 「Stakeholder 對範圍共同理解的權威文件？」→ scope statement - 「Charter 之後最先詳化的文件？」→ scope statement - 「Formulation 階段 scope statement = general 等級，definition 才 detailed」 - 「Scope 變更 → PWBS 同步更新」 - 「Scope statement 輸入三件套」→ 範圍/限制 + preliminary scope statement + 假設/約束

陷阱： - Scope 層級：General（formulation）→ Detailed scope statement（definition）→ PWBS - 「展示時間線」是 roadmap，「邊界」才是 scope statement

題號：模擬1 Q53 · Q70 · 模擬A Q59 · Q75 · 模擬B Q51 · Q114 · Q168 · 模擬x Q24 · Q105 · Q139 · Q155

子主題 13: Governance Plan / Financial Plan / Quality Plan / Resource Plan（其他關鍵子計畫）

13a. Governance Plan

核心：定義治理結構與運作。Governance plan 五件套「角結目關健」：角色職責 + 治理結構/組成 + 治理目標 + 階段 gate review 規劃 + 定期 health check。也定義組件啟動標準與會議時間表。

典型 content：角色 + 結構 + 目標 + gate review 規劃 + health check + 會議時間表（gate/health/audit）+ 組件啟動標準

出題形式： - 「Governance plan 標準五要素？」→ 角結目關健 - 「Steering 評組件啟動依據？」→ governance plan 中的啟動標準 - 「新成員不懂角色 → 回頭看 governance plan」（plan 沒寫清楚就要修） - 「Steering committee management plan 是 PMI 標準子計畫嗎？」→ 不是（steering 是 governance 結構不是被管理對象）

13b. Financial Plan / Framework / Baseline

核心：三層結構 Sources → Framework → Plan → Baseline → Budget。Framework 反映財務環境（funding sources、currency、tax 等變化）；Plan 從 framework 派生；Baseline 自下而上匯總 component cost estimates。

典型 content： - Framework：四結構（單組織內部 + 單組織分離 + 外部 + 混合）+ 資金來源 + 環境因素 - Plan：含閾值與超支處理規則（baseline 只說「計畫多少」、plan 說「超多少算重大」） - Baseline：Σ component cost estimates + reserves

出題形式： - 「啟動準備階段第一動作？」→ 識別 funding sources（framework 之前的基礎） - 「Initiation 早期了解財務環境？」→ 建立 financial framework - 「Baseline 構成？」→ 自下而上匯總 component cost estimates - 「判斷是否重大問題對照什麼？」→ financial plan（含 baseline + reserves + thresholds，不是只看 baseline） - 「Financial baseline 變動 → 必通知治理 + 審計」 - 「Program 與組件可有不同資金源」（framework 彈性）

13c. Quality Plan

核心：Program quality plan 高層級，三件套 標準 + 政策 + 質量成本估算。組件層細節（檢查單、QC 活動、角色）屬 component plan。

出題形式： - 「Program quality plan 內容？」→ standard + policy + cost of quality estimation（檢查單留給 component） - 「Program 統一品質標準 → PgM + PMO 合作」

13d. Resource Plan

核心：定義 resource lifecycle（acquire → use → release），何時要 / 怎麼取得 / 何時釋放三件套。External 但被 program 動員的角色（inspector / auditor / regulator）也歸 resource plan 管理。

出題形式： - 「Code inspector 屬於哪份 plan？」→ resource plan - 「Resource lifecycle 定義文件？」→ resource management plan - 「資源分配決策依據？」→ program resource plan（plan 定規則 / interdependency 看依賴 / priority 排優先）

題號： - Governance：模擬1 Q33 · Q119 · 模擬A Q42 · Q119 · 模擬B Q79 · Q135 · 模擬x Q65 · Q158 - Financial：模擬1 Q91 · Q92 · Q100 · Q146 · Q169 · 模擬A Q5 · Q92 · Q95 · Q103 · 模擬B Q30 · Q115 · 模擬x Q47 · Q48 · Q60 · Q114 - Quality：模擬1 Q48 · Q150 · 模擬A Q56 · Q106 · Q151 · 模擬x Q95 - Resource：模擬1 Q9 · 模擬A Q10 · Q23 · 模擬B Q118

子主題 14: 報告類文件（Status / Performance Report / Dashboard / Final Report / Lessons Learned）

核心：Plan vs Report 時態二元對照 — 未來 / 將要 → plan；已發生 → report。Report 是執行結果輸出，分多層服務不同對象。

14a. Status Report

核心：實際績效快照，含當前狀態、進展、健康度。Gate review 的 go/no-go 決策依據。

出題形式： - 「Gate review 通過 / 不通過依據？」→ status report（驗證能否進入下階段的數據基礎；PMP 是計畫不是現況） - 「機密資訊應獨立報告（不混入標準分發 status report）」

14b. Performance Report

核心：Performance analysis 標準輸出 = performance reports + forecasts（現況 + 預測雙輸出）。中層 stakeholder 看 performance report。在 closure 前用來證明績效達標支持收尾。

出題形式： - 「Performance analysis 標準輸出？」→ report + forecast 雙輸出 - 「Closure 前支持？」→ performance report（向 stakeholder 展示績效達標） - 「綜合狀態？」→ performance report（內含 status + cost + risk） - 「Performance report 戰略層級看什麼？」→ 目標 + 收益（不只資源/成本）

14c. Dashboard

核心：高層 snapshot，用顏色和關鍵指標即時展示，比文字報告更適合 sponsor / GB 階層。Red flag 即時狀態。

出題形式： - 「Sponsor 高層級關切要看什麼？」→ program dashboard（顏色 + 關鍵指標） - 「Governance level 看什麼？」→ dashboard；operation level 看 detailed reports - 「Red flag 即時狀態 = dashboard」（高層紅黃綠燈 snapshot）

14d. Final Report / Lessons Learned

核心：Closure 三件套 Sign-off + Lessons Learned + Transition。Final report 四件套：財務/績效 + 成敗 + 關閉原因 + Lessons learned。

出題形式： - 「Post-review session？」→ lessons learned - 「Final report 四件套？」→ 財務 + 成敗 + 關閉原因 + 教訓 - 「類似情境先做什麼？」→ 先查 lessons learned（歷史經驗） - 「Program 終止 → 正式記錄存檔」（future reference）

陷阱： - 三層分流：Dashboard（即時）→ Performance Report（定期）→ PMP（計畫） - 高層 stakeholder 看 dashboard；中層看 status report；操作層看 PMP

題號： - Status / Performance：模擬1 Q18 · Q74 · Q86 · Q143 · 模擬A Q66 · Q78 · Q144 · 模擬B Q73 · Q81 · Q85 · Q91 · Q92 · Q143 · Q170 · 模擬x Q35 · Q132 · Q162 - Closure / Lessons：模擬B Q24 · Q53 · Q98 · Q112 · Q136 · 模擬x Q78

對照速查表 1：易混文件配對 (重點 trap)

對照速查表 2：Program 文件出生順序與更新連動

文件出生時序鏈

組織戰略 / Strategic Plan / Mandate
    ↓
Business Case （論證）         ← 啟動前
    ↓
Program Charter （正式授權）   ← Initiation
    ↓
Program Roadmap （高層時序）   ← Definition
    ↓
Scope Statement （細化範圍）
    ↓
PMP （所有 plan 整合母艦）
    ├── BMP（收益子計畫）— 對應 Benefits Register
    ├── SEP（stakeholder 子計畫）— 對應 Stakeholder Register
    │       ↓
    │   Communications Plan（從 SEP 派生）
    ├── Risk Plan — 對應 Risk Register
    ├── Quality Plan / Resource Plan / Procurement Plan
    ├── Governance Plan
    └── Financial Plan / Framework / Baseline
    ↓
Status Reports / Performance Reports / Dashboard（執行期持續輸出）
    ↓
Transition Plan（移交）→ Sustainment Plan（維持）→ Final Report + Lessons Learned

變更連動規則（PMI 標準連動）

各 Phase 畢業文件

Stakeholder Engagement

Stakeholder engagement 是 PgM 的主動行為——任何負面反應、不參與、抗拒都不能成為不作為的藉口;PMI 標準動詞永遠是 develop / foster / engage / negotiate,絕不是「等待」或「放棄」。 收錄 95 條原料,聚類為 12 個知識點

子主題 1: 五級轉化矩陣與主動推進

核心:Engagement matrix 五級「Unaware → Resistant → Neutral → Supportive → Leading」,PgM 的責任是逐級往右推進。Sponsor 的悲觀、stakeholder 的對立都不是停下來的理由,題目出現「對立但必要」永遠選「設計分階段轉化計畫」。

出題形式: - 「Sponsor 悲觀地說某 stakeholder 不可能轉變」→ PgM 設計分階段轉化計畫 - 「對立但必要的 stakeholder 怎麼處理」→ 主動規劃 engagement strategy 往 supportive 推

陷阱:選項出現「接受 sponsor 判斷不再 engage」「等待對方主動」都是錯;PgM 不能被動。

題號:模擬1 Q2 · 模擬x Q3

子主題 2: SEP vs Stakeholder Register(動態 vs 靜態)

核心: - Stakeholder Register = 靜態名單(identify 階段產出),含 expectation / interest / influence / engagement strategy 欄位 - SEP(Stakeholder Engagement Plan) = 動態管理手冊(plan 階段產出),描述如何 engage / 追蹤 / 管理期望 - 兩者「分析後一起出生」(SEP & Register 同源),但職責不同。Stakeholder 任何負面反應 → 第一動作回 SEP 找預定 strategy。

出題形式: - 「stakeholder 負面反應第一步」→ 回 SEP - 「期望管理規劃文件」→ SEP - 「stakeholder 細部資訊存哪」→ Register - 「Identification 階段產出」→ Stakeholder Register - 「stakeholder 變更要做什麼」→ 更新 Register + 通知相關方

陷阱:Register 是名單不是計畫;SEP 才是處理動態反應的「第一手冊」。

題號:模擬1 Q6 · 模擬1 Q28 · 模擬1 Q39 · 模擬1 Q80 · 模擬1 Q83 · 模擬1 Q98 · 模擬1 Q120 · 模擬1 Q148 · 模擬1 Q154 · 模擬1 Q164 · 模擬1 Q166 · 模擬A Q17 · 模擬A Q21 · 模擬A Q36 · 模擬A Q37 · 模擬A Q80 · 模擬A Q121 · 模擬A Q149 · 模擬B Q22 · 模擬B Q45 · 模擬B Q56 · 模擬B Q101 · 模擬B Q108 · 模擬x Q11 · 模擬x Q90 · 模擬x Q112 · 模擬x Q145 · 模擬x Q159 · 模擬x Q165

子主題 3: Engagement 流程順序(五步)

核心:標準鏈「Identify → Analyze → Plan(SEP) → Engage → Monitor」(口訣「識規爭監」或「識分規爭督」)。下游影響:SEP → Communication Plan(沟通計畫從 SEP 派生)。順序不可顛倒、不可跳級。

出題形式: - 「分析完緊接什麼」→ Plan engagement(SEP + Register) - 「SEP 批准後做什麼」→ 制定 communication plan - 「Stakeholder analysis 後下一步」→ 沟通需求定義 + 沟通計畫 - 「Stakeholder identification 順序」→ Analysis → List → Categorize - 「Stakeholder engagement domain 三活動」→ Identification + Planning + Engagement

陷阱:沟通計畫是 SEP 下游(SEP 在前),別倒過來;先分析再列再分類,不是直接列。

題號:模擬1 Q6 · 模擬1 Q98 · 模擬1 Q120 · 模擬1 Q166 · 模擬A Q121 · 模擬B Q22 · 模擬B Q101 · 模擬x Q11 · 模擬x Q117 · 模擬B Q152

子主題 4: Prioritization 與 Monitoring 三軸(注意期別差異)

核心: - Engagement 規劃期優先級 =「收益期待 × 影響力 × 文化適配」(strategic relevance to benefits) - Engagement 監督期指標 =「影響力 × 參與度 × 態度」 - 兩階段用不同三軸,別混用。

出題形式: - 「Stakeholder prioritization 看什麼」→ 收益期待 + 影響 + 文化 - 「規劃 vs 監督的三軸差異」→ 規劃看戰略,監督看行為

陷阱:把「態度」放進規劃期 prioritization 是錯;態度屬監督期。

題號:模擬1 Q8 · 模擬A Q7

子主題 5: Engagement Metrics(量化追蹤命脈)

核心:要「量化追蹤」出席率、參與趨勢、不參與根因 → 必用 stakeholder/engagement metrics。Metrics 三特性 = 量化 + 定期 + 對照基準;設計原則 = 通用 + 客觀 + 可比(滿足所有 stakeholder,不為單一人客製)。Stakeholder 不參與的根因往往是「缺 engagement metrics」。

出題形式: - 「要量化追蹤出席率/參與」→ stakeholder metrics - 「要視覺化關係」→ stakeholder map - 「要靜態列表」→ stakeholder register - 「engagement metrics 是何時看」→ 持續/定期,不是某特定階段 - 「Metrics 設計為某 stakeholder 客製」→ 錯,要通用

陷阱:metrics(量化)/ map(視覺)/ register(列表)三者用途不同,別混。

題號:模擬1 Q20 · 模擬A Q29 · 模擬A Q32 · 模擬B Q21 · 模擬x Q29 · 模擬x Q39 · 模擬x Q42

子主題 6: 沟通強度階梯與個別處理

核心: - 沟通強度由弱到強「Email → 電話 → 視訊 → 面對面」 - 失敗升級規則:低強度失敗 → 升中強度,別直接跳最高(別越級到 sponsor) - 個別 stakeholder 承諾減弱 → 1-on-1 face-to-face 最有效(避免群體政治稀釋訊息) - Stakeholder buy-in 第一步 = 個別 + 面對面;後續才小組 → 公開

出題形式: - 「Email 失敗下一步」→ 電話(不是直接升 sponsor) - 「個別 stakeholder 承諾減弱」→ 1-on-1 - 「Key stakeholder 用什麼方式接觸」→ face-to-face - 「Buy-in 順序」→ 1-on-1 → 小組 → 公開

陷阱:跳級到 sponsor、改群體會議都是干擾項。

題號:模擬1 Q63 · 模擬1 Q71 · 模擬1 Q117 · 模擬1 Q141 · 模擬A Q76 · 模擬A Q118 · 模擬x Q125

子主題 7: 衝突升級階梯與 Sponsor 處理

核心:衝突解決階梯「直接溝通 → 協商 → 升 Sponsor → 升 Governance Board / Steering」,逐級不跳。 - Sponsor 三責 = Resource + Funding + Success promotion - 接管 program 時第一順位拜訪 = Sponsor(他是倡議者 + 戰略對接) - 衝突在 PgM 層解不掉 → 升 sponsor;sponsor 解不掉 → 升 steering - Sponsor 已決定終止 → PgM 執行(不挑戰) - 新機會鏈「PgM → Sponsor → Steering」依序

出題形式: - 「協商失敗下一步」→ 升 sponsor - 「兩 program 整合第一步」→ 雙方 sponsor 戰略共識 - 「接管 program 第一順位拜訪」→ sponsor - 「Sponsor 衝突」→ 升 steering committee

陷阱:跳級到 GB 或 CEO、PgM 自行決定終止 program 都錯。

題號:模擬1 Q142 · 模擬A Q91 · 模擬A Q143 · 模擬B Q95 · 模擬B Q157 · 模擬x Q4 · 模擬x Q22 · 模擬x Q34 · 模擬x Q126 · 模擬x Q154

子主題 8: 抗拒/負面反應處理流程

核心:Stakeholder 強烈反對的標準順序「先研究歷史與現狀 → 形成策略 → 再溝通」,順序不可顛倒。直接開會收集期望太被動。 - 緊急情境第一動作 = 快速資訊蒐集(歷史 + 當前立場) - Stakeholder 不滿 = 傾聽 + 系統化緩解(放入 board 議程),不單方說服 - Stakeholder 害怕 → 傾聽關切並調整交付物(系統化緩解) - Stakeholder 不參與 = 先了解情況(不越級也不推責) - Stakeholder 擔憂 = 歷史資料分析 + 找盟友(資深 board 成員)雙管齊下 - 負評/抗議 → 識別根因 + 系統調整 + 重新培訓

出題形式: - 「Stakeholder 強烈反對如何先動」→ 先研究歷史與現狀 - 「stakeholder 不滿/害怕」→ 傾聽 + 系統化緩解 - 「stakeholder 不參與」→ 先了解,別越級也別推責 - 「stakeholder 擔憂」→ 找盟友 + 歷史分析

陷阱:直接開會、跳級升 sponsor、把責任推給 team 都是錯。

題號:模擬1 Q46 · 模擬1 Q52 · 模擬A Q110 · 模擬B Q36 · 模擬B Q55 · 模擬B Q131 · 模擬x Q72 · 模擬x Q91 · 模擬x Q102 · 模擬x Q110

子主題 9: Develop / Foster Relationship(PMI 偏好正解詞)

核心:PMI 用語「develop relationship / foster / engage」常為正解。 - 與 stakeholder 非正式交流(午餐/晚宴)= legitimate relationship building,屬 engagement 一部分(非個人利益交換才合倫理) - Stakeholder concern 非正式處理 = 社交 + 等對方重啟接話 + 接住議題(PMI 推薦軟技巧) - 影響 stakeholder 接受變更 = Negotiation + Influencing(談判 + 期望管理) - 意外情境管理 = Negotiation + Influencing 雙技

出題形式: - 「非正式 stakeholder 互動是否合倫理」→ 是 legitimate(只要不是利益交換) - 「影響 stakeholder 接受變更的第一技巧」→ Negotiation - 「PgM 軟技巧處理 concern」→ 社交 + 接話

陷阱:看到「拒絕互動」「正式公文」優先選項要懷疑;PMI 偏好軟技巧 + 關係建立。

題號:模擬1 Q87 · 模擬B Q102 · 模擬B Q159 · 模擬x Q102

子主題 10: Stakeholder Pre-alignment(治理前先協調)

核心:治理變更前先做 stakeholder pre-alignment(私下協調),尤其是有投票權的外部代表。Governance board 含外部 stakeholder 代表(常見 4 名),變更請求漏拉外部對齊是 governance approval 失敗的核心原因。CR 被拒 → 先找外部 stakeholder 立場分歧根因,再修案再上。

出題形式: - 「Governance 變更被否決根因」→ 漏拉外部 stakeholder 對齊 - 「CR 被拒怎麼辦」→ 先看反對方,再修案

陷阱:選項出現「再次直接送 GB」「找 sponsor 推翻」都是錯;PMI 強調事前協調。

題號:模擬1 Q31 · 模擬x Q61

子主題 11: 跨文化與外部 / 社區 Stakeholder

核心: - 文化議題不只是 training,核心是 stakeholder 共建 + 沟通計畫更新 - 文化整合「Comms plan + Stakeholder 共識」,不是單一培訓 - 社區/外部 stakeholder 三招「Negotiate scope > Engage > Inform」 - 社區支持 = 協商範圍(把社區關切納入 program scope,例「活動後建公園」) - 收益實現有風險時 = 與 stakeholder 重新協商範圍(trade-off 必保 vs 可放棄)

出題形式: - 「文化議題標準動作」→ 與 stakeholder 合作 + 更新 comms plan - 「社區支持如何爭取」→ 協商範圍納入社區關切 - 「收益實現受阻」→ 與 stakeholder 重新協商範圍

陷阱:只做 training、只發 newsletter、PgM 自行決定範圍都是錯。

題號:模擬1 Q110 · 模擬1 Q133 · 模擬A Q20 · 模擬A Q112 · 模擬A Q134

子主題 12: Stakeholder 衝突的 Trade-off 原則 與多方共識動員

核心: - Stakeholder 衝突解決原則 = trade-off + balance + 透明,不是 winner-take-all - PgM 職責是平衡所有 stakeholder 群體需求,不偏向任一方 - 增加團隊承諾 / 識別最佳實踐 → 多方共識(Sponsor 戰略 + Stakeholder 利害 + PMO 方法)三角全包 - PgM 沟通四向「外(客戶) + 上(sponsor) + 治(steering) + 下(組件經理)」(從三向擴展) - Key stakeholders 啟動 = 集體 kick-off 建共識 - 「期望管理方向」= 把 stakeholder 期望對齊 program(不是改 program 來配合 stakeholder)

出題形式: - 「stakeholder 群體衝突」→ trade-off + balance - 「增加承諾」→ 多方合作識別最佳實踐(sponsor + stakeholder + PMO) - 「Key stakeholders 啟動」→ 集體 kick-off - 「期望管理方向」→ 對齊 program

陷阱:winner-take-all、單方說服、改 program 來配合 stakeholder 都是錯。

題號:模擬1 Q156 · 模擬1 Q167 · 模擬A Q157 · 模擬A Q167 · 模擬B Q11 · 模擬B Q133 · 模擬B Q137 · 模擬x Q170

角色職責

PgMP 錯題第 3 大坑(30 題)。核心鐵律:問題在哪層、誰就處理;治理決定、PgM 執行不挑戰;衝突一方就是解決者。陷阱永遠在 PgM vs PM vs Sponsor vs GB 的邊界與決策權誰屬。 收錄 78 條原料,聚類為 9 個知識點

子主題 1: Program Manager (PgM) — 任命時機與核心職責

核心職責: - 任命時機:在 program definition phase 早期(formulation / pre-setup)就要被選定,以便主導 charter、roadmap、PMP 等規劃工作。 - 任命第一指標:program management experience(經驗深度)永遠勝過單一技能/語言/籍貫/技術細節。 - 核心職責 7 件:沟通 + stakeholder + 領導 + 變革 + 分析 + 整合 + 戰略願景(口訣「沟領變分整戰」+ stakeholder)。 - 沟通方向:四向沟通 = 客戶(外)+ sponsor(上)+ steering/治理(治)+ 組件經理(下)。 - 全週期負責:PgM 對 program 全生命週期負責,含 post-transition 維持規劃。 - 整體性聚焦:PgM 關注通用標準 + 整體性議題,不下沉到 project 細節。 - 跨組件影響:任何跨組件影響由 PgM 主動評估,不推給 PM 也不消極等待。 - 資源規劃:program 所有人力與外部專家(含 inspector/auditor/regulator)歸 PgM 在 resource management plan 統籌。

出題形式: - 「PgM 任命的第一指標?」→ program management experience(不是語言/籍貫/技能) - 「PgM 何時被指派?」→ definition phase 早期 / pre-setup / formulation - 「PgM 與哪些角色沟通?」→ 上(sponsor)/ 下(組件 PM)/ 外(客戶)/ 治理 - 「PgM 主要核心技能?」→ 7 件套(沟領變分整戰 + stakeholder) - 「post-transition 規劃由誰?」→ PgM(全週期責任)

陷阱: - PgM 任命題的選項常出現「技術專精」「在地語言」「同產業背景」當干擾項,正解永遠是「program management experience」。 - 「整體性 vs 細節」:題目給 PM 細節層議題時不要選 PgM 介入。

題號:模擬1 Q21 · 模擬1 Q72 · 模擬1 Q112 · 模擬A Q41 · 模擬B Q11 · 模擬B Q12 · 模擬B Q78 · 模擬B Q136 · 模擬B Q137 · 模擬B Q149 · 模擬x Q41 · 模擬x Q43 · 模擬x Q150 · 模擬x Q156 · 模擬1 Q9

子主題 2: Program Manager (PgM) — 不過度介入 vs 主動介入的判斷

核心職責: - 不過度介入:當組件 PM 自己沒升級(沒 escalate),且工程師/PM 已表態能解決時,PgM 尊重組件自主權,不介入。 - PM 主動升級 = 已認定無法解決:此時 PgM 必須進場,正式與 sponsor 討論風險與緩解,不可單靠工程師信心而忽略。 - 組件內部衝突:先要求 PM 自評(尊重組件 PM 自主),不越級。 - 跨組件衝突 / 自身是衝突源:PgM 必須介入(衝突一方就是解決者)。 - PgM 失職時:即便要保護 PgM 權威,PM 未實施纠正時 PgM 要立即纠正 + coaching 培育(雙手:止血 + 培育),不是只責備或越俎代庖。 - 客戶拒絕 PM 前:PgM 應先審查項目技能要求(可能是定義錯誤,非人選錯誤),不直接換人。 - 越級通報:雙重處理 — 解問題 + 修通報鏈(PM 跳過 PgM 直找 sponsor 要事後修正 escalation 政策)。

出題形式: - 「PM/工程師說會處理 — PgM 應?」→ 不過度介入,讓組件處理 - 「PM 升級了 — PgM 應?」→ 進場,與 sponsor 正式討論 - 「客戶要換 PM,PgM 應?」→ 先審查技能要求是否定義正確 - 「PM 越級找 sponsor,PgM 應?」→ 解問題 + 修 escalation 流程 - 「PM 持續未改善,PgM 應?」→ 立即纠正 + 教導決策責任

陷阱: - PgM 不是萬能介入者,有 PM 還想做的 PMP 變越界。PMI 強調尊重組件 PM 自主權。 - 「客戶說 PM 不行」不等於 PM 真不行 — 永遠先回頭審視標準是否合理。

題號:模擬1 Q134 · 模擬A Q91 · 模擬A Q102 · 模擬A Q134 · 模擬A Q166 · 模擬B Q44 · 模擬B Q165 · 模擬x Q44 · 模擬x Q88 · 模擬1 Q58

子主題 3: Project Manager (PM) — 職責邊界

核心職責: - 單一項目內成員工作分配衝突 = PM 處理(不是 PgM)。 - 對「某一 project」報告 / 信息不滿 = 該 project 的 PM 負責,只有當涉及 program 級才到 PgM。 - 層級對應原則:「問題在哪層,誰就處理」。Project 內 → PM;跨 project → PgM。 - PM 選擇標準:技能矩陣(skill set inventory)vs 項目需求對比 + 技能優先、可用性次之。 - 新成員/Sub-PM 發展:Coaching 1-on-1(個別發展)優於群體 training 或長期 mentor。 - 組隊順序:先定義角色 + 能力要求(competency requirements)→ 招募 → 培訓。 - 固定價合同下 PM 風險:自備完整應對計畫 + 充足 contingency reserve,不依賴客戶或合同變更。

出題形式: - 「單一 project 成員衝突由誰處理?」→ PM(不是 PgM) - 「對 a project 的報告不滿 — 誰負責?」→ 該 project 的 PM - 「選 PM 第一標準?」→ 技能矩陣 vs 項目需求 - 「PgM 想發展 PM 個人能力?」→ Coaching(個別發展)

陷阱: - 題幹常用「a project」「單一項目」「該組件內」暗示是 PM 層議題,正解選 PM 不選 PgM。 - 與「跨 project」「多組件」「program 級」嚴格區分。

題號:模擬1 Q50 · 模擬A Q57 · 模擬A Q114 · 模擬A Q134 · 模擬A Q166 · 模擬B Q162 · 模擬1 Q68 · 模擬A Q73 · 模擬B Q77 · 模擬B Q87

子主題 4: PgM 與 Functional Manager / 跨組織衝突

核心職責: - PgM 自己是衝突一方時(PgM vs 職能經理):向上協調職能經理屬 PgM 職責 — 衝突一方就是解決者。 - 對比:PM vs 職能經理衝突 → PM 處理(同層級);PgM vs 職能經理衝突 → PgM 處理。 - 能力不足取得資源:與職能經理協商取得跨部門資源(soft skill + organization politics),勝過外部採購或越級。 - 跨 program 資源衝突:與另一 PgM 合作找協同,不是單方搶資源;再升級到 portfolio manager。 - 跨 portfolio / 上層協調:由 portfolio manager 處理(層級對應)。 - 矩陣型組織跨職能協調:由 PgM 統籌(PMI:PgM 是 program 層級資源衝突的協調者)。

出題形式: - 「PM 與職能經理衝突 — 誰解?」→ PM - 「PgM 與職能經理衝突 — 誰解?」→ PgM(衝突一方就是解決者) - 「跨 program 資源衝突 — 怎處理?」→ 先協作另一 PgM → 升 portfolio - 「資源不夠時要找誰?」→ 先與職能經理協商(內部)再外部採購

陷阱: - 看清「衝突的雙方是誰」— Q50/Q51 模擬1 對比題就是測試:衝突一方(誰)決定解決者(誰)。

題號:模擬1 Q50 · 模擬1 Q51 · 模擬A Q61 · 模擬B Q106 · 模擬x Q43 · 模擬x Q151

子主題 5: Sponsor — 三責、Kickoff 角色與 PgM 關係

核心職責: - Sponsor 三責:Resource(資源)+ Funding(資金)+ Success(成功促進)。 - Sponsor 在 Kickoff 角色:設定戰略基調 + 激發團隊使命感(vision alignment + motivation),不處理行政細節(細節留給 PM/PgM)。 - Sponsor 視角看 program:Benefits 對齊 BMP > 財務 > 執行(高層永遠先看收益是否對齊)。 - Sponsor 高層級關切:用 Program dashboard(顏色/關鍵指標的 snapshot),不給細節報告。 - 接管 program 第一順位:Sponsor(他是 program 倡議者 + 戰略對接者),其次 PMO → 客戶 → 團隊。 - Plan 系列審查者:Sponsor 是戰略代表,Comms plan / SEP 等 PgM 制定後與 sponsor 共同 review,PMO/PM 是支援角色。 - 沟通計畫最終 approver:Sponsor(最高 stakeholder + 治理代表)。 - 預算有餘:回頭找 sponsor 探額外機會(主動創造價值),不立即收尾。 - Sponsor 端變化:通常觸發「沟通計畫 + SEP」雙更新。

出題形式: - 「Sponsor 三大責任?」→ 資源 + 資金 + 成功促進 - 「Kickoff sponsor 主軸?」→ Vision + motivation,不是行政細節 - 「Sponsor 看什麼?」→ Dashboard、收益對齊 - 「接管 program 先找誰?」→ Sponsor - 「Comms plan 由誰審批?」→ Sponsor

陷阱: - 「sponsor 悲觀但 program 必要」題,sponsor 的悲觀不能成為 PgM 不作為的藉口 — PgM 仍需主動推進 stakeholder engagement。 - Sponsor 不處理 kickoff 的行政細節(會議流程、人員報到等),只設戰略基調。

題號:模擬1 Q41 · 模擬1 Q74 · 模擬1 Q123 · 模擬A Q49 · 模擬A Q54 · 模擬A Q78 · 模擬A Q124 · 模擬B Q52 · 模擬B Q83 · 模擬B Q107 · 模擬x Q4 · 模擬x Q22 · 模擬x Q166

子主題 6: Sponsor 與 GB 的決策權 — PgM 服從不挑戰

核心職責: - 治理紀律鐵律:「PgMP 題目中治理委員會 / sponsor 要求做 X + 立即行動」= 服從。爭辯型答案永遠錯。 - Closure 決定權:在 steering committee / GB,PgM 執行不挑戰,即使 PgM 認為時機未到。 - Sponsor 已決終止:執行終止(治理紀律),PgM 不挑戰 sponsor 決定。 - CEO/Sponsor 要求加速:評估影響 + 提建議永遠勝過「直接執行」,但最終決策權在治理層。 - Sponsor 衝突(無法直接協調):升 steering committee 解決(治理層級對應)。 - Component closure 決定權 = GB / Steering committee(治理層,不是 sponsor/PgM 個人)。 - Sponsor 個人批准不取代委員會:component lifecycle event(啟動/關閉)必須走 governance 正式流程。 - 協商失敗的衝突:已用盡 PgM 層級權限 → 升級 sponsor(再失敗升 GB)。

出題形式: - 「GB 要 closure 但 PgM 反對 — 怎做?」→ 服從,執行 - 「PgM 與其他 sponsor 衝突 — 升給誰?」→ steering committee - 「Component closure 決定權?」→ GB(不是 sponsor 個人/PgM) - 「加速請求由誰決定?」→ 治理層(PgM 只能分析 + 建議)

陷阱: - 「PgM 不同意 board 決定」型題目,任何「反對/拖延/重新議論」選項都錯,正解永遠是「服從 + 執行」。 - Sponsor 與 GB 是兩個不同層級:Sponsor 個人決定不能取代 GB 的治理流程批准。

題號:模擬1 Q15 · 模擬1 Q32 · 模擬1 Q79 · 模擬1 Q142 · 模擬A Q25 · 模擬A Q26 · 模擬A Q70 · 模擬A Q84 · 模擬A Q119 · 模擬A Q143 · 模擬B Q65 · 模擬B Q94 · 模擬B Q95 · 模擬B Q146 · 模擬B Q157 · 模擬x Q63 · 模擬x Q130 · 模擬x Q154

子主題 7: Governance Board (GB) — 治理結構、職責邊界與啟動標準

核心職責: - GB 拒絕新組件的核心原因 = strategic alignment 不足(戰略對齊永遠是第一審查標準)。 - GB 四大活動:評估 + 指導 + 監督 + 決策(評估績效是首要)。 - Governance plan 五要素(口訣「角結目關健」):(1)角色職責(2)治理結構/組成(3)治理目標(4)階段 gate review 規劃(5)定期 health check。 - Governance 三柱:Sponsor + GB + PMO — 三者失能即治理崩潰,治理重建是首要(不能先談其他)。 - 新成員不懂角色 → 回頭看 governance plan(plan 應定義角色;若沒寫清楚要修)。 - 組件啟動正式批准權 = steering committee(治理層,不是 stakeholder/sponsor/PM)。 - Steering 評組件啟動:看是否符合治理計畫中的啟動標準(若 plan 沒寫標準,steering 無依據批准)。 - Definition phase 必建治理結構:與 charter/roadmap 同期建立 governance。 - CR 被 board 拒絕的常見根因:外部 stakeholder 立場分歧(尤其 board 含外部代表時要做 pre-alignment 私下協調)。

出題形式: - 「Board 拒絕變更最常見原因?」→ strategic alignment 不足 - 「Governance plan 標準內容?」→ 角結目關健五件套 - 「組件啟動誰批准?」→ steering committee(走治理批准,別繞道) - 「新成員不懂角色 — 看哪份文件?」→ governance plan - 「Sponsor + GB + PMO 都失能 — 先建什麼?」→ governance 結構

陷阱: - GB 拒絕題型,正解永遠跟「戰略對齊」相關,不是「資源不足」「時機不對」等其他理由。 - 治理變更前要先做 stakeholder pre-alignment(尤其有投票權的外部代表)。

題號:模擬1 Q5 · 模擬1 Q31 · 模擬1 Q33 · 模擬1 Q79 · 模擬1 Q119 · 模擬A Q42 · 模擬A Q70 · 模擬A Q90 · 模擬B Q31 · 模擬B Q54 · 模擬B Q79 · 模擬B Q89 · 模擬B Q129 · 模擬B Q132 · 模擬B Q135 · 模擬x Q9 · 模擬x Q61 · 模擬x Q65 · 模擬x Q108 · 模擬x Q132 · 模擬x Q157 · 模擬x Q158

子主題 8: PMO — 標準制定者與方法夥伴

核心職責: - PMO 三件套:方法 + 模板 + 標準(是 PgM 的方法夥伴),也說成「流程標準 + 工具模板 + 知識共享」。 - 質量標準 / 工具標準化 = PMO 主導(PMI 標準:PMO 是組織方法/標準/模板的提供者)。 - PMIS 衝突 / 抵抗:PMO 主導協商(系統解,不強制不另買)。 - 複雜技能 / 能力缺失問題:PMO 評估 + 推薦,不直接跳培訓或外援(評估 → 推薦 → 執行三段)。 - PMO 治理三柱之一:Sponsor + GB + PMO 缺一即治理失能。 - OPA 缺失自製順序:模板 → 結構 → 知識庫(repository structure 是 program 持續累積知識資產的核心,PMO 角色)。 - 報告格式標準化 = PMO 主導。 - Program 統一標準制定三角:PgM 推動 + PMO 提供 + PM 執行。

出題形式: - 「Program 統一品質標準由誰主導?」→ PMO(同 PgM 合作) - 「工具標準化由誰?」→ PMO - 「PMIS 抵抗怎處理?」→ PMO 主導協商 - 「PMO 三件套?」→ 標準 + 模板 + 一致性 - 「OPA 缺失怎建?」→ PMO 模板 → 結構 → 知識庫

陷阱: - PMO 不是「執行單位」是「方法/標準提供者」— 選項中「PMO 直接執行 X」往往是干擾。 - 標準制定權在 PMO,但執行靠 PM,推動靠 PgM,三者分工不互相取代。

題號:模擬1 Q115 · 模擬1 Q150 · 模擬A Q106 · 模擬A Q116 · 模擬A Q151 · 模擬B Q74 · 模擬B Q109 · 模擬B Q120 · 模擬x Q38 · 模擬x Q108 · 模擬x Q148 · 模擬x Q160(OPA repository)

子主題 9: 升級路徑、委派與 RACI/Accountability

核心職責: - Escalation 鏈(由低到高):PM → PgM → Sponsor → GB(逐級,跳級要修通報鏈)。 - Escalation 處理三類(內部事項):Issues / Risks / Changes(口訣「問風變」)。Regulations(法規)= EEF 外部,不走 escalation。 - 衝突解決階梯:直接溝通 → 協商 → 升級 sponsor → 升級 governance。 - CCB 層級對應:單 project = Project CCB(在 tolerance 內)、跨組件/影響架構 = Program CCB、戰略影響 = Governance Board。變更管理通則:影響決定層級,不是身份決定。 - Tolerance 內 vs 超:內 = project 自決,超 = program / Escalation。容忍度太窄 = 每個微小變更都觸發 CR → 流程開銷增加 → 拖慢執行。 - Escalation 政策:risk plan 應明確 escalation 政策(哪些風險可自決、哪些必上呈),避免每事都堆到 PgM(瓶頸)。 - Benefit owner 原則:Benefit owner = primary beneficiary(誰受益誰負責),不是 PgM 也不是 component PM。 - Accountability matrix:PMI Program 標準用語(對比 project 層 RAM)。記法「Program: Accountability matrix、Project: RAM」。 - Executive 核心參與:批准目標收益(戰略對齊的核心檢核),不下沉執行細節。 - PMIS 全層級貢獻:Sponsor + GB + PMO + Team + PgM 五角色缺一不可。 - Charter 雙核心授權:正式授權 program + 授 PgM 資源權(不只是 program 授權,還有 PgM 個人權限)。

出題形式: - 「PM 跳過 PgM 直接找 sponsor — 怎處理?」→ 解問題 + 修 escalation 鏈(雙重) - 「容忍度太窄會怎樣?」→ 過度 CR 觸發 → 拖慢 - 「跨組件變更走哪個 CCB?」→ Program CCB(依影響範圍) - 「Benefit owner 應該是誰?」→ 主要受益者 - 「Risk plan 為什麼要明確 escalation?」→ 避免事事堆 PgM - 「Charter 授權什麼?」→ Program + PgM 資源權(雙核心)

陷阱: - CCB 不是身份對應(PM 一定是 Project CCB)而是影響範圍對應(影響跨組件就升 program CCB)。 - 「逐級升級」不能跳級;跳級了要事後修補通報流程,不是只責備跳級者。 - Regulation 不走 escalation(EEF 是接受性,不是內部升級)。

題號:模擬1 Q23 · 模擬1 Q54 · 模擬1 Q121 · 模擬1 Q144 · 模擬1 Q155 · 模擬A Q19 · 模擬A Q58 · 模擬A Q60 · 模擬A Q91 · 模擬A Q122 · 模擬A Q145 · 模擬B Q14 · 模擬B Q17 · 模擬B Q41 · 模擬B Q113 · 模擬B Q156 · 模擬x Q28 · 模擬x Q34 · 模擬x Q46 · 模擬x Q82 · 模擬x Q107 · 模擬x Q138 · 模擬x Q151 · 模擬x Q169

流程順序「下一步」反射庫

PgMP 第 2 大坑(38 題),看到觸發情境秒選「正確第一動作」。聚類為 38 條反射規則,涵蓋 Closure / Init & Charter / 變更請求 / 戰略變化 / Stakeholder 觸發 / 風險觸發 / Sponsor 變動 / 文件鏈順序 / 資源衝突順序九大子主題 收錄 95 條原料,聚類為 38 個反射規則

反射總表(優先掃)

子主題 1: Closure 流程順序與觸發

核心:Closure 順序「審查 → 共識 → 授權 → 執行」;PgM 不自決,所有 closure 動作都受 governance plan 與 GB 監管。

Closure 必要三件: 1. Plan 中的關閉條件達成(exit criteria) 2. Sustainment 移交 3. Governance approval(steering committee 正式批准)

Closure 順序細節: - 取得批准 → 執行收尾 → 報告 → 歸檔(模擬1 Q109) - 與 sponsor + GB 共同 review → 達成共識 → 授權 → 執行(模擬1 Q90、模擬A Q94、模擬B Q146) - Closeout 前先與 sponsor 一起 review BMP(模擬B Q107) - Closure 前正式提交 GB 關閉申請 → 批准 → 執行(模擬B Q146)

Component closure 特殊規則: - 觸發 = deliverables completed(模擬1 Q131) - 不要因單一採購爭議卡住,可以「關了再處理」(模擬1 Q36、模擬A Q45、模擬x Q71) - 最終決定權在 GB,不是 PgM(模擬x Q130、模擬B Q65、模擬1 Q149) - Closure 前先評估跨組件影響(模擬B Q139) - 驗證四件套 = deliverables + contracts + personnel + acceptance(模擬1 Q159)

陷阱: - 「PM 個人判斷可 close」永遠錯,closure 是 governance decision - 「收益全達才能 close」錯,benefits 可在 sustainment 後實現 - 「客戶滿意了就 close」錯,缺 governance approval 不算 close - 「小 bug 還在,延後 close」錯,維持日期 + 文件化遺留 + 移交 ops

出題形式: - 「Program 接近 closure,什麼是阻止 closure 的根本原因」→ 缺 governance approval - 「Component closure 觸發點是什麼」→ Deliverables completed - 「Closure 前 PgM 應該做什麼」→ 與 sponsor + governance 共同 review - 「治理委員會建議 closure,PM 該怎麼做」→ 執行,不挑戰

題號:模擬1 Q4/Q15/Q36/Q90/Q109/Q131/Q139/Q149/Q152/Q159、模擬A Q25/Q45/Q46/Q94/Q132/Q136/Q153/Q160、模擬x Q7/Q18/Q20/Q63/Q71/Q130/Q133/Q140、模擬B Q10/Q52/Q53/Q70/Q107/Q139/Q146/Q157

子主題 2: Initiation / Charter 階段觸發

核心:Program 啟動文件鏈固定不變:Strategic mandate → Business case → Charter → Roadmap → PMP;Definition phase 標準輸出 = 章程 + 任命(人員)+ 路線圖 + 治理結構(章任路治)。

啟動順序變體: - 經典版:Business case → Charter → Roadmap → BMP → PMP(模擬1 Q14) - Strategic mandate 版:Mandate → Charter → Roadmap → PMP → 客戶簽收(模擬x Q10、模擬B Q5/Q99) - Approval 順序:BC → Charter → Roadmap → PMP(模擬A Q41) - Definition 推進:初步批准 → roadmap → charter → PMP → setup(模擬1 Q170)

Charter 完成後的標準下一步: - Charter 完成 → 提交 GB 獲授權(模擬x Q56) - Charter 批准後 → Kick-off meeting(模擬B Q125) - Charter 後緊接 → Scope statement(模擬1 Q53、模擬A Q75、模擬x Q139)

Component 啟動規則: - 必走 steering committee 正式批准(模擬1 Q79、模擬x Q157) - Steering 評組件啟動看「governance plan 中的啟動標準」(模擬x Q158) - 必要條件 = business case 必存在(模擬1 Q81、模擬x Q161)

Pre-launch 階段: - 第一動作 = 識別資金來源(funding sources)(模擬1 Q91) - Financial 順序:Sources → Framework → Plan → Baseline → Budget

Program 啟動最初動作: - 依據戰略要素定義 program 目標/需求/風險(formulation)(模擬x Q23) - 量化收益(收益是 program 存在理由)(模擬B Q116) - 展示 + 評估組織能力(在授權之前)(模擬B Q130、模擬x Q55)

陷阱: - 「Sponsor 個人批准 component」錯,必走 GB - 「先做 charter 才搞 business case」錯,BC 在 charter 前 - 「先建 framework 才找 sources」錯,sources 是最早

出題形式: - 「Charter 批准後下一步應做什麼」→ Kick-off meeting - 「Strategic mandate 授權後下一步」→ Charter(formal authorization) - 「Business case 授權後下一步」→ Roadmap(高層方向圖)

題號:模擬1 Q14/Q41/Q53/Q69/Q77/Q79/Q81/Q91/Q170、模擬A Q40/Q41/Q49/Q75、模擬x Q10/Q23/Q27/Q54/Q55/Q56/Q60/Q70/Q137/Q138/Q139/Q153/Q157/Q158/Q161、模擬B Q5/Q19/Q25/Q86/Q89/Q99/Q116/Q125/Q130/Q153/Q155

子主題 3: 變更請求(CR)流程與層級

核心:所有變更都必須先走 formal CR,PM 不能單方決定接受或拒絕;CR 批准層級依「變更影響範圍對應到適當 governance level」決定。

Mandatory change(法規類): - 必走正式變更請求記錄(模擬1 Q82) - 不能直接改 baseline,不能用 fast track 跳過治理 - 走 CR 接受延遲,不能強壓進度(模擬A Q86)

新組件加入 program: - 必走 CR → 評估 → Board 審 → 整合(模擬x Q8、模擬1 Q5) - Board 拒絕最常見原因 = 戰略對齊驗證不足(模擬x Q9)

Stakeholder / 客戶提變更: - 永遠先建 CR,再評估(模擬A Q6) - 客戶外部新需求:評估 → 提案 → 批准 → 整合(模擬x Q19、模擬1 Q159) - 任何 fix 都要回到 change control,事後也要補 CR(模擬1 Q58、模擬x Q115)

CR 接受/拒絕後: - 接受 = baseline 變動 → 必走 re-plan(模擬x Q33) - 拒絕 = 原計畫繼續但需 re-confirm(模擬x Q32) - GB 拒絕 = 找外部 stakeholder 立場分歧根因(模擬x Q61、模擬1 Q31)

CCB 層級分配: - 單 project = Project CCB(模擬A Q122) - 跨組件或影響架構 = Program CCB - 戰略影響 = Governance board - 「影響決定層級,不是身份決定」(模擬1 Q144、模擬A Q145)

容忍度與 CCB 關係: - 5% 容忍區間 = tolerance,內部 project CCB 處理(模擬x Q82) - 超出 → 進 program CCB - 容忍度太窄 → 每個微小變化觸發 CR → 拖慢執行(模擬1 Q155)

陷阱: - 「PgM 個人評估後接受」錯,跳過 CR 必經步驟 - 「直接 fast track 解決 mandatory change」錯,沒走 CR - 「客戶滿意就跳過 CR」錯,治理紀律不可妥協

出題形式: - 「Stakeholder 提變更請求,PgM 應該做什麼」→ 建 CR 走流程 - 「Mandatory change 影響進度,應該怎麼做」→ 走 CR,接受延遲 - 「Project 變更 CCB 在哪個層級」→ Project CCB 即可

題號:模擬1 Q10/Q31/Q58/Q82/Q121/Q144/Q155/Q159、模擬A Q6/Q85/Q86/Q122/Q145、模擬x Q8/Q19/Q32/Q33/Q34/Q61/Q82/Q115、模擬B Q4/Q23

子主題 4: 戰略變化 / 商業環境變化的觸發動作

核心:戰略變化的第一動作永遠是「先評估 BMP / 收益是否仍對齊新戰略」;不是修改計畫,不是通知治理,而是先看根本。

戰略變化反射: - 先評估 BMP 是否仍對齊新戰略(模擬1 Q75/Q105、模擬x Q149、模擬B Q138) - 順序:對齊先於更新

Governance 第一關切: - 戰略改變後 = strategic alignment 是否仍然成立(模擬1 Q75) - expected benefits 是否仍對齊新戰略

商業環境變動: - 先評估 BMP(模擬A Q108) - 鏈條:評估 BMP → 改 Plan → 走 CR

競爭威脅: - 重新評估戰略對齊(模擬B Q105) - 鏈條:重評 + 對齊 + 決定方向

Program 三大死亡情境: 1. 戰略改變 2. ROI 不可達 3. 收益基礎消失 → 三者都建議 cancel(模擬1 Q22、模擬A Q31/Q62)

戰略目標變化處理: - 三大可能結局 = 變更 / 暫停 / 取消(模擬A Q62) - Benefit goal 無法實現決策層級:PgM 識別 → Sponsor 核實 → Governance 取消(模擬A Q84)

戰略對齊已恢復後: - 修訂 roadmap + 落實 benefits management(模擬1 Q132、模擬A Q133) - 健康度恢復順序:戰略對齊 → roadmap 修訂 → BM 落實 → execution

陷阱: - 「先改 PMP 才看 BMP」錯,BMP 是收益核心,先看根本 - 「直接通知 governance」過早 - 「立即修改計畫」過早,先評估對齊

出題形式: - 「Strategy changed,what does PgM do first」→ 評估 BMP / 收益對齊 - 「ROI 不可達,governance 應該做什麼」→ Cancel

題號:模擬1 Q22/Q75/Q105/Q132、模擬A Q31/Q62/Q84/Q108/Q133、模擬x Q149、模擬B Q105/Q138

子主題 5: Sponsor / Stakeholder 觸發

核心:Stakeholder 任何反應,先回 SEP;Sponsor 任何變動,同時更新沟通計畫 + SEP。

Negative stakeholder / 負面反應: - 回到 SEP 找預定 engagement strategy 並執行(模擬1 Q28、模擬A Q36/Q37) - SEP = 處理 stakeholder 動態的第一手冊;Register 只是靜態名單

未通過評審 + Stakeholder 強烈反對: - 先快速研究歷史與現狀 → 形成策略 → 再溝通(模擬1 Q46) - 順序不可顛倒

新 stakeholder 入門: - 第一手材料 = program charter(模擬1 Q59、模擬A Q64) - 順序:章程 → 路線圖 → BMP → 會面 - 新成員 onboard 不熟目標 = 回到 charter + BMP(模擬B Q141)

Stakeholder buy-in 第一步: - 個別 + 面對面(1-on-1)(模擬x Q125) - Key stakeholders 啟動 = 集體 kick-off 會議(模擬x Q170) - 個別 stakeholder 承諾減弱 = 個別溝通(模擬1 Q117、模擬A Q118)

Stakeholder 不參與根因: - 缺 engagement metrics(模擬x Q29) - 先了解情況,不越級也不推責(模擬x Q110、模擬B Q55)

Stakeholder satisfaction 評估: - 定期 review meeting 取得直接回饋(模擬1 Q11、模擬A Q22)

Sponsor 變動: - 同時更新沟通計畫 + SEP(雙更新)(模擬1 Q104、模擬A Q54) - Sponsor 已決終止 → PgM 執行,不挑戰(模擬B Q157)

陷阱: - 「先改 plan 才看 SEP」錯,SEP 是 stakeholder 議題第一手冊 - 「先開大會收集期望」太被動,要先研究歷史 - 「Stakeholder 不參與 = 推給他們解決」錯,先了解情況

題號:模擬1 Q11/Q28/Q46/Q59/Q104/Q117、模擬A Q14/Q17/Q22/Q36/Q37/Q54/Q64/Q118、模擬x Q4/Q29/Q72/Q110/Q117/Q125/Q145/Q170、模擬B Q22/Q55/Q56/Q86/Q131/Q133/Q141/Q142/Q157

子主題 6: 風險事件觸發

核心:失敗事件第一動作 = 回顧現有 risk register(先存量再增量);風險發生時雙管齊下(嘗試解決 + 評估後果),不過早通知 governance。

Risk 過程順序: - 識別 → 分析 → 規劃 → 監控(M&C)(模擬1 Q165、模擬B Q163) - Monitoring 是執行階段持續動作

失敗事件發生後順序: - 回顧現有 risk register → 延伸識別新 risks → 更新(模擬1 Q57、模擬x Q113) - 先存量後增量

風險發生(剛發生): - 雙管齊下:嘗試解決 + 評估後果(模擬1 Q73、模擬x Q77) - 不應立即修改 BMP(過早)或通知 governance(過早)

新風險識別: - 先記錄(register) + 制定減輕計畫(模擬B Q9、模擬A Q101) - 風險流程:識 → 記 → 計畫 → 執行

風險響應順序: - 應對 → 評估影響 → 通知 steering(模擬x Q77) - 通知在評估後

Risk response 規劃完成後: - 設立 contingency reserve(模擬1 Q84/Q124、模擬B Q76)

風險識別紀律: - 全部記錄,不可預先過濾(模擬x Q111) - 先記後篩,不能先篩後記

陷阱: - 「失敗事件直接識別新風險」錯,先審查既有 - 「風險發生立即通知 governance」過早 - 「風險識別時過濾低概率」錯,全部記錄

題號:模擬1 Q57/Q73/Q84/Q124/Q165、模擬A Q101、模擬x Q77/Q111/Q113、模擬B Q9/Q76/Q163

子主題 7: 資源 / 加速 / 衝突的順序

核心:跨組件資源衝突永遠先 program 內部 leveling/smoothing,失敗才走外部 CR;加速請求要走「分析影響 + 利弊報告 → Sponsor 決定」。

跨組件資源衝突順序: - 內部 rebalance → 外部 CR(模擬1 Q65/Q114) - 順序固定:leveling → smoothing → rent → buy(模擬x Q129) - 先 leveling → 再 transfer → 後 buy/rent(模擬x Q128)

資源處理三招: - Leveling 平衡、Smoothing 緩衝、Transfer 轉移(模擬x Q14) - 加速首選 leveling(模擬B Q7)

預算減縮處理: - 次要組件資源轉到關鍵組件(模擬x Q13) - 從次要 → 關鍵,別動關鍵組件

加速請求: - 分析影響 + 利弊報告 → Sponsor 決定(模擬A Q26) - CBA → GB 治理層決策(模擬B Q16) - 加速 = 跨組件 leveling 首選(模擬B Q7)

Sponsor 衝突: - 升 steering committee 解決(模擬B Q95)

衝突解決階梯: - 直接溝通 → 協商 → 升級 sponsor → 升級 governance(模擬1 Q142、模擬A Q143) - PMI 優先級:自己先嘗試直接溝通,失敗再升級(模擬A Q76)

Escalation 跳級: - 雙重處理:解問題 + 修通報鏈(模擬x Q34、模擬B Q17) - 組件問題不該全在組件層 → 部分必升 program 級(模擬x Q28)

陷阱: - 「資源不足直接申請 CR」錯,先內部 rebalance - 「直接買/租資源」錯,先 leveling 優化 - 「Sponsor 要求加速 → 直接執行」錯,先分析利弊

題號:模擬1 Q65/Q114/Q142、模擬A Q26/Q76/Q143、模擬x Q13/Q14/Q28/Q34/Q43/Q128/Q129、模擬B Q7/Q16/Q17/Q44/Q64/Q95

子主題 8: 文件鏈與「下一步是哪份文件」

核心:文件出生順序固定為論證 → 章程 → 路線圖 → 計畫(Business case → Charter → Roadmap → BMP → PMP);Scope 鏈為 Charter → Scope statement → Plan → WBS。

文件出生順序(經典): - Business case → Charter → Roadmap → BMP → PMP(模擬1 Q14、模擬A Q40) - Business case 在 program 啟動前就存在,是策略可行性的最早文件

Approval 順序: - BC → Charter → Roadmap → PMP(模擬A Q41) - Business case 是最早,先批准它才有資格制定 charter

啟動文件鏈(Strategic mandate 版): - Strategic mandate → Charter → Roadmap → PMP → 客戶簽收(模擬x Q10、模擬B Q5/Q99) - Strategic mandate 是 roadmap 的源頭輸入(模擬x Q70)

Definition phase 鏈: - Analysis → Roadmap → Charter → PMP(模擬B Q43) - Environmental analysis 支撐戰略方向

Scope 文件鏈: - Charter → Scope statement → Plan → WBS(模擬x Q139) - Charter 後緊接細化 = Scope statement(模擬1 Q53)

Onboarding 文件層級: - Charter → BMP → Roadmap → 細部 plan(模擬A Q64)

Benefits 文件層級: - Charter(概念)→ BRP(規劃)→ Register(狀態)(模擬A Q11) - BMP 是 Benefits Analysis & Planning 階段輸出(模擬1 Q136)

Stakeholder 文件鏈: - Identify → Register → Analyze → Plan(SEP)→ Engage → Monitor(模擬x Q11/Q112、模擬B Q56) - SEP 後 → Communications plan(模擬1 Q120、模擬A Q121)

執行前置順序: - Charter → Roadmap → Stakeholder ID → 分配資源(模擬A Q109)

Financial 鏈: - Sources → Framework → Plan → Baseline → Budget(模擬1 Q91、模擬A Q95)

Cost 鏈: - Estimation → Budgeting → Baseline → Control(模擬B Q145)

陷阱: - 「Charter 在 BC 之前」錯,BC 是最早 - 「Sources 在 Framework 之後」錯,Sources 是最早 - 「PMP 在 Charter 之前」錯,Charter 是入門文件

題號:模擬1 Q14/Q53/Q69/Q77/Q91/Q120/Q136/Q170、模擬A Q11/Q40/Q41/Q64/Q75/Q95/Q109/Q121/Q153/Q160、模擬x Q10/Q11/Q27/Q56/Q60/Q70/Q112/Q137/Q138/Q139/Q153、模擬B Q5/Q19/Q43/Q56/Q61/Q99/Q145

子主題 9: Program lifecycle / 階段順序與輸出

核心:Program lifecycle 分為 Formulation → Definition → Delivery → Closure(或 Definition → Setup → Delivery → Closure);Component 規劃 + 執行屬於 Delivery 階段。

完整版階段順序: - Formulation → Definition → Delivery → Closure(模擬B Q153)

簡版階段順序: - Definition → Setup → Delivery → Closure(模擬B Q25)

Definition phase 輸出: - 章任路治(Charter + 人員指定 + Roadmap + 治理結構)(模擬1 Q69、模擬x Q137) - Definition input = 組織戰略 + business case(模擬1 Q77) - Governance 結構建立在 Definition 階段(模擬B Q89)

Definition 推進順序: - 初步批准 → roadmap → charter → PMP → setup(模擬1 Q170、模擬A Q169)

Component lifecycle: - Initiate → Execute → Transition → Close(模擬B Q128)

Re-planning 三大觸發: - Gate review / Portfolio 變動 / 戰略改變(模擬x Q31、模擬1 Q16) - Portfolio 變動是核心觸發

Program plan 更新觸發點: - Component lifecycle event + 重大 risk + governance gate(模擬1 Q16) - Portfolio 變化不在內

Closure 後 benefits: - Sustainment 接力(不是結束)(模擬x Q20、模擬B Q10) - Benefits 必須在 program 結束後維持

Closure 條件本質: - 章程目標達成(formal closure criteria)(模擬x Q7) - 不是看收益是否全達

Strategic planning 初步確認: - 高層 roadmap + 初步估算(模擬B Q155)

Post-transition 規劃: - PgM 職責(全週期含 post-transition)(模擬B Q149)

陷阱: - 「Definition phase 不含 governance」錯,governance 在此期建立 - 「Setup 是第一階段」錯,Formulation/Definition 在前 - 「Closure 後就結束」錯,Sustainment 接力

題號:模擬1 Q16/Q69/Q77/Q170、模擬A Q169、模擬x Q7/Q20/Q23/Q31/Q137/Q170、模擬B Q10/Q25/Q86/Q89/Q116/Q128/Q130/Q149/Q153/Q155

戰略對齊

Program 永遠向上對齊組織戰略，組織戰略對齊股東價值；Portfolio 統管戰略、Program 協調收益、Project 執行交付——三層邊界與文件鏈是 PgMP 第一性。 收錄 58 條原料，聚類為 8 個知識點

子主題 1: Portfolio vs Program vs Project 邊界

核心:Portfolio 是策略層級可彈性組合 portfolio/program/project/非項目工作（"所有都可、無一必須"）；Program 的 components 必相互依存（interdependency 是 program DNA），透過協調管理產出單一項目不可得的整合收益；Project 是獨立可交付物。Program ≠ 多項目集合，而是「產生策略性收益的協調機制」。

出題形式: - 「Portfolio 可包含哪些」→ 所有層級（含 program/project/非項目工作）皆可 - 「Program 與 Project 本質差異」→ Program 必有 interdependency；Project 為獨立可交付物 - 「Program 的存在價值是什麼」→ 跨 component 相互依賴可帶來無法獨立管理的價值 - 「Program 對 Project 集合的核心增值」→ 收益整合 + 風險集中 + 資源優化 + 治理一致

陷阱:把 program 當成「多個 project 集合」是最常見誤解；component 沒有 interdependency 就不該打包成 program。

題號:模擬1 Q17 · 模擬1 Q25 · 模擬1 Q35 · 模擬A Q9 · 模擬A Q16 · 模擬A Q27 · 模擬A Q34 · 模擬A Q44 · 模擬x Q12 · 模擬x Q69 · 模擬x Q81 · 模擬x Q96 · 模擬x Q164 · 模擬B Q48 · 模擬B Q88 · 模擬B Q111

子主題 2: Program 對齊組織戰略（Strategic Alignment 第一性）

核心:Strategic Alignment 是 PgMP 第一性。任何 KPI/component/變更/組件啟動都必須能向上追溯到組織戰略目標——KPI 永遠 by Org → Program → Component 由上而下設計，不是由下往上。Governance board 把關核心就是 strategic alignment，新增 component 必須證明貢獻 program 戰略目標，否則一律拒絕。Executive leadership 的核心介入點 = 批准目標收益。

出題形式: - 「治理委員會為什麼拒絕新組件」→ 戰略對齊驗證不足 - 「KPI 如何設計」→ 由上而下 Org → Program → Component - 「Executive 在 program 的核心參與」→ 批准目標收益（戰略對齊的核心檢核） - 「program 主要目標是什麼」→ 產生 strategic benefits（協調機制）

陷阱:選「最完整列舉」常輸給「最聚焦戰略對齊」的選項；KPI 由下往上是干擾項。

題號:模擬1 Q5 · 模擬1 Q7 · 模擬x Q9 · 模擬A Q18 · 模擬x Q25 · 模擬x Q69 · 模擬B Q113 · 模擬A Q74

子主題 3: 股東價值鏈 / 組織價值鏈

核心:股東利益的根本來源 = 組織戰略目標達成。Program 與戰略對齊 = 創造股東價值。鏈條清楚：Program 永遠向上對齊組織戰略；組織戰略對齊股東價值。Sponsor 的視角永遠是「收益實現對齊 BMP」，財務/狀態/資源都是次要。

出題形式: - 「股東利益的根本來源」→ 組織戰略目標達成 - 「Sponsor 視角優先順序」→ Benefits 對齊 > 財務 > 執行 - 「Strategic alignment 鏈條」→ 股東價值 → 戰略目標 → Program 對齊

陷阱:選「直接給股東財務報告」或「縮短交付」忽略中間的戰略對齊環節。

題號:模擬1 Q96 · 模擬A Q99 · 模擬x Q166 · 模擬B Q83

子主題 4: Business Case（戰略對齊源頭文件）

核心:Business Case 是論證 program 與戰略對齊的根本文件，包含戰略合理性、預期收益、ROI 的說服性論證——「值不值 + 花得起」雙論證。它是 program 啟動前就存在的最早文件，是 charter 的前置與授權依據。組件啟動最根本要件 = business case（沒有 BC = 沒有 governance 評估根據）。Definition phase 早期任何資金端新需求變化，永遠先回頭驗證 business case 的根本假設；新機會出現也先驗證 BC，再走 BMP 改 → Plan 更新。Feasibility 驗證常用 SWOT 全方位分析。

出題形式: - 「論證 program 與戰略對齊的源頭文件」→ Business Case - 「組件啟動的通行證」→ Business Case - 「定義階段資金來源新需求出現，第一動作」→ 回到 Business Case 驗證根本假設 - 「Business Case 驗證工具」→ SWOT（全方位）優於 CBA（單財務面）

陷阱:Charter 是授權但不是論證，BC 才是論證源頭；早期變化跳過 BC 直接改 plan 是常見錯誤。

題號:模擬1 Q14 · 模擬1 Q24 · 模擬1 Q81 · 模擬1 Q102 · 模擬1 Q126 · 模擬A Q33 · 模擬A Q40 · 模擬A Q41 · 模擬A Q79 · 模擬A Q105 · 模擬A Q127 · 模擬x Q27 · 模擬x Q64 · 模擬B Q19 · 模擬B Q32 · 模擬B Q97 · 模擬B Q148 · 模擬B Q164

子主題 5: 戰略文件鏈（Mandate → Charter → Roadmap → PMP）

核心:Program 文件批准順序固定：Strategic Mandate / 組織戰略計畫 → Business Case → Charter → Roadmap → BMP → PMP → 客戶簽收。組織戰略計畫是 program 的 input（前提）不是 output。Definition phase 的 input = 組織戰略 + business case；output = charter + PMP + roadmap + governance。Strategic mandate 授權後下一步是 charter（formal authorization），charter 是 business case 的延伸。Roadmap 是戰略 ↔ 計畫工作的視覺橋樑。

出題形式: - 「Program 文件出生順序」→ 論證 → 章程 → 路線圖 → 計畫（BC → Charter → Roadmap → PMP） - 「Strategic mandate 授權後下一步」→ Charter - 「組織戰略計畫在 definition phase 的角色」→ Input（前提），不是 output - 「Roadmap 本質」→ 戰略 ↔ 計畫工作的視覺橋樑

陷阱:把組織戰略當成 program 的產出是干擾項；把 charter 當成最早文件忽略上游 BC/mandate。

題號:模擬1 Q77 · 模擬A Q70 · 模擬x Q10 · 模擬x Q70 · 模擬x Q153 · 模擬B Q5 · 模擬B Q6 · 模擬B Q29 · 模擬B Q35 · 模擬B Q43 · 模擬B Q61 · 模擬B Q99 · 模擬B Q123

子主題 6: 戰略變化的回應（Recovery & Re-alignment）

核心:戰略變化的第一動作 = 評估 BMP 是否仍對齊新戰略（BMP 是收益核心，新戰略可能導致現有收益失效）。順序：對齊先於更新。Governance 在戰略改變後的第一關切就是 strategic alignment 是否仍成立。健康度恢復順序「戰略對齊 → roadmap 修訂 → BM 落實 → execution」。商業環境變動同理：先評估 BMP（收益是否仍可達/仍相關），才能決定後續動作。競爭威脅出現要重新評估戰略對齊。Program 三大死亡情境 = (1) 戰略改變 (2) ROI 不可達 (3) 收益基礎消失——三者都建議 cancel。

出題形式: - 「戰略改變後第一動作」→ 評估 BMP 是否仍對齊新戰略 - 「Program 三大死亡情境」→ 戰略改變 / ROI 不可達 / 收益基礎消失 - 「Recovery 雙拳」→ Roadmap 重對齊 + Benefit Management 重收益 - 「商業環境變動」→ 先評估 BMP → 改 Plan → 走 CR

陷阱:跳過 BMP 對齊評估直接改 plan/通知 governance 是常見錯誤；只更新 charter 不評估收益對齊也錯。

題號:模擬1 Q22 · 模擬1 Q75 · 模擬1 Q105 · 模擬1 Q132 · 模擬A Q31 · 模擬A Q62 · 模擬A Q108 · 模擬A Q133 · 模擬x Q149 · 模擬B Q75 · 模擬B Q105 · 模擬B Q138 · 模擬B Q156

子主題 7: Portfolio 預防組織內重複工作

核心:Portfolio management 是預防組織內重複 program 的最高層級機制。Portfolio optimization 的核心 = 最大化戰略價值（平衡而非追求單一維度最優化），三軸 = 價值 + 風險 + 資源。Program 選擇最重要標準 = 收益（strategic alignment 的具體展現）。重複工作三層防：Portfolio 預防 / Gate 發現 / Closure 整合。跨 program 級的協調由 portfolio manager（該 portfolio 涵蓋本 program）處理。

出題形式: - 「預防組織內重複 program 的最高層級機制」→ Portfolio management - 「Portfolio 優化核心目標」→ 最大化戰略價值（平衡，非單一維度） - 「Program 選擇最重要的標準」→ 收益（勝過所有其他指標） - 「跨 program 協調誰處理」→ portfolio manager

陷阱:選 Gate review 或 Closure 整合都是次階防線；portfolio 預防才是「最高層級」。

題號:模擬1 Q62 · 模擬A Q81 · 模擬x Q96 · 模擬x Q123 · 模擬x Q151 · 模擬x Q167 · 模擬x Q168 · 模擬B Q84 · 模擬B Q132

子主題 8: Charter 中的戰略要素（願景/目標/預期收益）

核心:Program charter 是正式文件，明文定義 program 的 strategic objectives 和 expected benefits，含 high-level vision/scope/assumptions/constraints/organizational needs，是與高管同步的標準文件。Charter 雙核心 = 正式授權 + PgM 資源權限。Charter 標準六件套：合理性 + 願景 + 成果 + 收益戰略 + 組件 + 時間線。Vision 是「具體可達的未來狀態」（一句話、清楚的未來）。新 stakeholder/PM/sponsor 對齊 program 時，Charter 是入門首發文件（Onboarding 順序：Charter → BMP → Roadmap → 細部 plan）。Stakeholder 早期共識文件 = Charter + Business Case 雙搭配。

出題形式: - 「Charter 標準內容」→ Vision + Strategic Objectives + Expected Benefits + 高層 Scope - 「新 stakeholder 入門首發文件」→ Charter（不是 BMP） - 「Charter 雙核心」→ 正式授權 program + 授權 PgM 動員資源 - 「Vision 定義」→ 具體可達的未來狀態（一句話、清楚的未來）

陷阱:Charter 是戰略結構文件，不是執行細節（細節在 PMP）；把 BMP 當入門文件比 Charter 早是干擾項。

題號:模擬1 Q59 · 模擬1 Q135 · 模擬1 Q137 · 模擬1 Q158 · 模擬A Q11 · 模擬A Q14 · 模擬A Q64 · 模擬A Q138 · 模擬x Q54 · 模擬x Q124 · 模擬x Q138 · 模擬B Q28 · 模擬B Q62 · 模擬B Q69 · 模擬B Q141

EVM 與計算

EVM 9 公式是本週要默寫的盲區; PGMP 計算題集中在 EVM (CV/SV/CPI/SPI/EV/EAC/ETC) + Critical Path 最長路徑 + PERT/溝通渠道公式 + ROI/Cash Flow/Payback, 全部要能直接套公式 收錄 44 條原料, 聚類為 18 個知識點

EVM 9 公式總表(默寫用)

口訣: - 符號:「>1 好、<1 壞 ; + 好、- 壞」(SPI/CPI 比率, CV/SV 差值) - 解讀:「SPI 看快慢、CPI 看貴賤」, 負落後、負超支 - ETC vs EAC:「ETC 未來 / EAC 總計 / CPI 效率 / SPI 進度」

EAC 5 種情境

口訣: EAC 三公式「EAC1 假設過去不延續、EAC2 假設過去繼續(CPI)、EAC3 雙指標」。

EVM 應用陷阱與情境判讀

子主題 1: EVM 四象限 (進度 × 成本)

陷阱:「進度落後且花得多」=最差; gate review 看「SPI/CPI/ROI 三紅燈」=取消最差表現組件。

子主題 2: EVM 加總與 Program 層

• Program EV = 各 project EV 加總 (例:80 + 200 + 200 = 480)
• 任一 project 缺 AC / PV / EV 任一欄, 無法算 program 總值
• Program 層整合看 EAC vs BAC 金額, 不是比率 (金額才看得到絕對缺口)
• Program 績效監控四件套 = EVM + 財務報告系統 + 績效衡量技術 + PMIS

典型題型: 給 3-4 個 project 的 EVM 數據, 問 Program 級總 EV / 總 AC, 或問哪個 project 缺資料無法加總。

題號: 模擬1 Q49 · 模擬x Q97 · 模擬x Q98 · 模擬B Q49 · 模擬B Q72 · 模擬B Q91 · 模擬x Q144

子主題 3: EVM 報告紀律

• EVM 高層摘要要明指問題組件 + 其他狀態, 不能模糊化或過度推論整體
• EVM 算出 SV<0 / CV<0 表面進度落後 / 成本超支, 中文「進度計畫超出預算」常是翻譯不精準, 實際指 cost overrun
• 發現差異用 variance analysis (計畫 vs 實際); 找原因用 root cause / Ishikawa。順序: 先測量差異, 再找原因

題號: 模擬A Q4 · 模擬A Q66 · 模擬B Q170 · 模擬1 Q85

子主題 4: Critical Path (CP) vs Critical Chain (CC)

核心定義: - CP = 最長路徑 = 必達 program 完成時間 (CPM, Critical Path Method) - CC = 排程方法 = 處理資源約束下的活動排序 (Critical Chain Method)

CP 三特性: 「最長 + 無 float + 延誤即延整體」 - CP 上的 activity = 無 float (浮時為 0) - Program 進度不是簡單加總, 看依賴關係 + 整合影響才能結論

陷阱題: Critical Chain 出現在收益監督 / 風險 / Stakeholder 題目選項中, 幾乎必為干擾項 (因為 CC 是排程工具, 與這些領域無關)

收益監督正確三件套: Variance + What-if + Simulation (不含 critical chain / critical path / PERT)

題號: 模擬x Q30 · 模擬x Q49 · 模擬x Q50 · 模擬B Q15 · 模擬1 Q3 · 模擬A Q15 · 模擬x Q5 · 模擬x Q106

子主題 5: PERT 與三點估算

PERT (Beta 分佈) 公式 = (O + 4M + P) / 6 - O = Optimistic (樂觀) - M = Most Likely (最可能) - P = Pessimistic (悲觀) - 例:(2 + 4×3 + 7) / 6 = 21/6 = 3.5

口訣:「樂觀 1 倍、最可能 4 倍、悲觀 1 倍, 除以 6」, PMI 標配考點

題號: 模擬1 Q60 · 模擬A Q65

子主題 6: 溝通渠道公式

公式 = n(n-1) / 2 (人數平方減人數除以 2)

關鍵陷阱: PgM 也算 1 人! 若題目說「PgM 帶 7 人團隊」→ n = 8, 不是 7 - 例:n = 8 → 8 × 7 / 2 = 28 條渠道

題號: 模擬A Q67

子主題 7: 財務公式 (ROI / NPV / Cash Flow / Payback)

口訣: - Financial 三件「ROI 報酬 + Cash flow 流量 + Payback 回本」 - 續資論證「剩餘投資 + ROI」具體化

Program 三大死亡情境 (與 ROI 高度相關): 戰略改變 / ROI 不可達 / 收益基礎消失 — 三者都建議 cancel

題號: 模擬A Q163 · 模擬1 Q22 · 模擬A Q31 · 模擬B Q67 · 模擬B Q121

子主題 8: 預算與基準線 (Budget / Baseline / Reserve)

• Budget Baseline = Σ component cost estimates + reserves (自下而上匯總)
• 匯率 / 付款計畫是後續調整, 不是 baseline 構成
• Financial Plan 含閾值與超支處理規則 (例:超 10% 為重大); Baseline 只訂基準, 不訂規則
• Financial 三層「Plan 訂規則、Baseline 訂基準、Report 看實績」

未預期成本來源 (三類正當管道): - Contingency reserve — 已識別的風險用 - Management reserve — 未識別的風險用 - Sponsor 額外資金 — 跳出 program 預算範圍

口訣: 成本超支「Contingency 已識別 / Management 未識別 / Sponsor 額外」

題號: 模擬1 Q92 · 模擬A Q103 · 模擬B Q96

子主題 9: 進度壓縮與變更

Schedule 壓縮三招: Fast track / Crash / Leveling - 三招都不能違反 mandatory change (法規/合規) 的本質 - Mandatory change (例如法規) → 永遠先 CR 再執行, 任何壓縮進度的手段都在 CR 之後 - 接受延遲是合規, 不能強壓進度

進度 CR 被接受 = baseline 變動 = 必走 re-plan - Re-plan 鐵律「baseline 動就 re-plan」

跨 project 時間避超支: 用共享日期 + 里程碑 (讓 PM 可規劃資源衝突)

題號: 模擬1 Q82 · 模擬A Q86 · 模擬x Q33 · 模擬B Q150

子主題 10: 進度計算實例 (CV / SV 速算法)

情境: 計畫 3 個月做完 1M€, 實際 1 個月做完 - SV 算法:「計畫 - 實際」直接相減 = 3 - 1 = 2 個月節省 - CV 算法:「節省 = 比例 × 預算」, 只用 1 月 = 省 2/3 = 1M × 2/3 = 0.66M€ 節省 - 也可寫成: 實際成本 = 1/3 × 1M = 0.33M, CV = PV - AC = 1 - 0.33 = 0.67M

口訣: 成本/進度題先抓「總量 ÷ 期間 = 單位率」, 再算節省/超支

題號: 模擬1 Q19 · 模擬x Q36 · 模擬x Q37 · 模擬B Q18

子主題 11: 進度標準術語

• Schedule Network Diagram = PMI 標準術語 (進度網路圖), 不是 box 或 critical path

題號: 模擬x Q118

反射快查表 (拿到題目立刻判斷)

風險管理 + 沟通管理

PgMP 風險管理重「全記錄 + 雙面性(威脅/機會) + 兩種儲備 + 五步驟流程」，沟通管理重「SEP 派生 + 五要素計畫 + 強度遞增 + 文化整合」。 收錄 78 條原料，聚類為 14 個知識點。

風險管理

子主題 1: Risk Process 五步驟流程

核心：標準流程 = 識別 → 分析 → 應對 → 寫入 Register → 監督(M&C)。Monitoring & Control 屬執行階段持續動作，不要與前期識別/分析/規劃混淆。當題目強調「監督應急計畫和殘餘風險」「trigger conditions monitoring」「評估 effectiveness」就是 Risk M&C。

出題形式： - 「監督應急計畫和殘餘風險」→ Risk Monitoring & Control - 「Trigger conditions monitoring 屬哪階段」→ Risk M&C - 「評估 risk response 有效性」→ Risk M&C - 「Risk 流程完整步驟」→ 識別 → 分析 → 規劃 → 應對 → 監督

陷阱：識別/分析/規劃是前期動作，不是「監督」；分清前後階段別把規劃當監督。

題號：模擬1 Q165 · 模擬A Q101 · 模擬B Q9 · 模擬B Q103 · 模擬B Q163 · 模擬B Q169 · 模擬A Q125

子主題 2: Risk Register 鐵律(全記錄 + 雙面性)

核心：所有識別的風險都必須完整記錄(不論可控與否)，後續再評估 priority 與 response strategy；Opportunity 與 Threat 都記在 risk register(雙面性)，Program 層機會記 program risk register，不歸組件。Risk register 也可能(may)含影響收益的風險，但不強制合併入 benefits register。

出題形式： - 「PM 想忽略不可控風險」→ 錯，所有風險都進 register - 「Opportunity 記在哪」→ risk register (Program 層機會 → program risk register) - 「失敗事件第一動作」→ 回顧現有 risk register(先存量後增量) - 「風險識別結果記哪」→ risk register

陷阱：「先記後篩，別先篩後記」；不要為了「不可控」就略過。

題號：模擬1 Q56 · 模擬1 Q57 · 模擬1 Q108 · 模擬A Q111 · 模擬B Q103 · 模擬x Q26 · 模擬x Q111 · 模擬x Q113

子主題 3: 兩種風險儲備(Contingency vs Management Reserve)

核心： - Contingency reserve = 應對「已知未知」(已識別風險)，由 PM 控制 - Management reserve = 應對「未知未知」(未識別風險)，由 sponsor 控制

Risk response 規劃完成後的標準補強動作就是設立 contingency reserve。Fixed-price 合同下 PM 承擔成本超支風險，必須「完整應對計畫 + 充足 contingency reserve + 殘餘控制」三件套自保。

出題形式： - 「Risk planning 完成後下一步」→ 設立 contingency reserve - 「已識別風險的補強機制」→ Contingency reserve - 「Fixed-price 合同 PM 怎自保」→ 應對 + 儲備 + 殘餘控制 - 「兩種 reserve 差異」→ Contingency(已知未知/PM)、Management(未知未知/sponsor)

題號：模擬1 Q84 · 模擬1 Q124 · 模擬1 Q127 · 模擬A Q88 · 模擬A Q125 · 模擬A Q128 · 模擬B Q76

子主題 4: 風險發生時的回應順序

核心：問題剛發生不立即修改 BMP、不直接通知 governance，而是「雙管齊下：嘗試解決 + 評估後果」。風險回應的標準順序 = 應對 → 評估影響 → 通知 steering，不是「直接通知 + 改計畫」。事件響應通用三步 = 評估 → 應對 → 溝通。失敗事件發生後特殊順序 = 先審查既有 register → 識別新風險 → 後更新。

出題形式： - 「問題剛發生 PgM 第一動作」→ 嘗試解決 + 評估後果 - 「風險回應後通知 steering 時機」→ 評估後再通知 - 「失敗事件首先做什麼」→ 回顧現有 risk register - 「跳過評估直接通知」→ 錯

陷阱：別跳評估直接通知；別還沒救火就先改計畫。

題號：模擬1 Q73 · 模擬x Q15 · 模擬x Q77 · 模擬x Q113 · 模擬1 Q57

子主題 5: Program-level Risk vs Component-level Risk + 升級規則(問風變)

核心： - Escalation 處理內部 issues / risks / change requests 三類，口訣「問風變」(Issues/Risks/Changes) - Regulations 是 EEF (外部環境因素)，不走 escalation 流程 - 升級鏈 = PM → PgM → Sponsor → Governance Board - Board / GB 視角聚焦 program 級風險，project 級風險不在 board 議論(避免淹沒重點) - 跨組件風險審查四維 = 資訊 + 資源 + 時間成本 + 變更 - 組件風險越級表示 escalation 規則不明，需審查強化 - 審批瓶頸的根本解 = risk plan 中明確 escalation 政策(自決 vs 上呈)

出題形式： - 「Escalation 處理什麼」→ Issues / Risks / Changes (問風變) - 「Regulations 算 escalation 嗎」→ 不算，是 EEF - 「Board 該看哪層風險」→ Program 級 - 「組件風險越級症狀」→ escalation 規則不明 - 「跨組件風險審查維度」→ 資訊 + 資源 + 時成 + 變更

題號：模擬1 Q54 (參考) · 模擬A Q58 · 模擬A Q60 · 模擬A Q91 · 模擬B Q117 · 模擬x Q46 · 模擬x Q132

子主題 6: 風險識別技術選擇(Delphi / Brainstorm / Interview)

核心： - Delphi = 跨域 / 跨國 / 跨時區專家，匿名輪詢 + 共識，避免群體壓力 - Brainstorm = 同地團隊集思 - Interview = 1 對 1 深度訪談 - Scenario analysis = 從已知條件出發建構多種可能未來，是 risk analysis 與 strategic planning 的標準工具 - Root cause identification = Risk definition + 按原因分組;Fishbone 是其中一種視覺工具，但「root cause」是更通用的方法論名稱

出題形式： - 「跨國專家識別風險」→ Delphi - 「Risk + 按原因分組」→ Root cause (Fishbone 是干擾項) - 「建構未來情境分析風險」→ Scenario analysis

陷阱：PMI 常用「概念名稱」(root cause) 作正解，「具體工具」(fishbone) 作干擾項。

題號：模擬1 Q12 · 模擬1 Q13(scenario) · 模擬B Q71 · 模擬x Q142

子主題 7: Tolerance / Threshold / KPI 觸發機制

核心： - Tolerance = 容忍區間;不超就不報，超了立刻報(Exception reporting principle) - 5% 容忍區間 = tolerance；CCB 分層「Tolerance 內 project、超出 program」 - KPI 介入觸發 = 超出容忍區間才介入，不是任何偏差(避免微調過度介入) - KPI 觸發機制 = 當 stakeholder 要求觸發 KPI 警戒線，自動啟動計畫應對(tolerance-based response) - 判斷「是否為重大問題」需對照完整財務計畫(含 baseline + reserves + tolerance + thresholds)，不是單一 baseline

出題形式： - 「為何設 tolerance」→ 不超不報、超了立報 - 「5% 偏差怎處理」→ Tolerance 內 project、超出 program CCB - 「KPI 何時介入」→ 超出容忍區間 - 「重大問題判斷依據」→ 完整 financial plan，不是單一 baseline

題號：模擬1 Q23 · 模擬1 Q100 · 模擬B Q27 · 模擬B Q41 · 模擬x Q45 · 模擬x Q82

子主題 8: 外部負面事件 / 機會 / 競爭威脅的風險處理

核心： - 外部負面事件(如媒體負評) = reputational risk → 進入 risk management 流程(識別、評估、應對、監督) - 競爭威脅 → 重新評估戰略對齊(重評 + 對齊 + 決定方向) - 新機會 = 戰略級評估 → 先驗證 business case → 再走 BMP / Plan 更新 - 新機會推進鏈 = PgM → Sponsor → Steering，不單方推進、不直跳 steering - 機會來臨「接受 + 評估 + 補強」三步，不是直接拒絕 - Program 預算有餘 → 回頭找 sponsor 探額外機會(主動創造價值，不立即收尾)

出題形式： - 「媒體負評怎處理」→ risk management 流程 - 「競爭對手新產品」→ 重評戰略對齊 - 「發現新機會」→ 先驗證 business case - 「預算還有剩」→ 找 sponsor 探機會

題號：模擬1 Q95 · 模擬A Q113 · 模擬B Q32 · 模擬B Q52 · 模擬B Q105 · 模擬x Q64 · 模擬x Q154

沟通管理

子主題 9: SEP 與 Communications Plan 的派生關係 + Stakeholder 五步

核心： - SEP (Stakeholder Engagement Plan) 描述如何 engage stakeholder - Communications Plan 從 SEP 派生(誰需要什麼資訊、頻率、媒介) - 順序：Identification → Analysis → SEP → Communication Plan → Engage (Stakeholder 五步) - Stakeholder 變化時沟通計畫必須同步調整 - Sponsor 端變化(財務安排等)通常觸發「沟通計畫 + SEP」雙更新 - 沟通計畫的最終 approver = sponsor(最高 stakeholder + 治理代表)；PgM 是制定者 - 當 component 沟通計畫不完整 / 不一致 → 拉到 program 層整合制定 program-level communications plan 向下展開

出題形式： - 「SEP 批准後下一步」→ 制定 communications plan - 「Stakeholder 五步順序」→ 識別 → 分析 → SEP → 沟通計畫 → 爭取 - 「Sponsor 端變化更新什麼」→ Comms plan + SEP 雙更新 - 「Comms plan 誰批准」→ sponsor - 「組件沟通不一致」→ 拉到 program 層整合

題號：模擬1 Q120 · 模擬1 Q123 · 模擬1 Q129 · 模擬1 Q166 · 模擬A Q54 · 模擬A Q121 · 模擬B Q22

子主題 10: Communications Plan 五要素 + 沟通目的三件套

核心： - Communication management plan 五要素 = who / what / when / how / why (誰、什麼、何時、怎樣、為何) - 分發資訊(who / what / when / how)的定義文件 = communication management plan - 沟通的最終目的 = Right info + Right way + Right person 三件套(正確資訊以正確方式到達正確 stakeholder) - 子計畫名單包含「範圍/進度/成本/品質/風險/採購/資源/沟通/SEP/治理/收益/財務」(沟通是 12 個子計畫之一) - 「Steering committee management plan」不是標準子計畫(steering 是 governance 結構)

出題形式： - 「分發資訊定義在哪」→ Communication management plan - 「Comms plan 含哪些要素」→ who/what/when/how/why - 「沟通最終目的」→ Right info × way × person

題號：模擬A Q38 · 模擬A Q39 · 模擬x Q94

子主題 11: 沟通強度遞增 + 沟通失敗升級 + 個別 vs 集體

核心： - 沟通強度依重要性遞增 = email → 電話 → 視訊 → 面對面；關鍵 stakeholder 用最高強度 - 低強度沟通失敗 → 升級到中強度(電話)，不是直接跳 sponsor 或重發 email - 個別 stakeholder 承諾減弱 → 個別溝通最有效(face-to-face)；集體會議稀釋訊息 - 群體 stakeholder 議題 = 召集所有人統一沟通；個別異議才用單獨會 - 衝突解決階梯 = 直接溝通 → 協商 → 升級 sponsor → 升級 governance - PMI 優先級 = 自己先嘗試直接溝通(call + visit)，失敗再升級 - 資源提供方不滿 → PgM 主動溝通(價值 + 影響 + 互利)，不威脅也不升級 - PgM 沟通方向 = 三軸(客戶/外 + sponsor/上 + 組件經理/下)；延伸為四向(再加 steering/治)

出題形式： - 「Email 沒回怎麼辦」→ 打電話(中強度)，不要直接找 sponsor - 「關鍵 stakeholder 個別處理」→ face-to-face - 「群體議題 vs 個別異議」→ 群體統一沟通；個別單獨會 - 「資源衝突」→ 主動溝通(價值 + 影響 + 互利) - 「PgM 對誰溝通」→ 上下外(三軸) / 外上治下(四向)

題號：模擬1 Q52 · 模擬1 Q63 · 模擬1 Q71 · 模擬1 Q117 · 模擬1 Q142 · 模擬A Q76 · 模擬B Q11 · 模擬B Q38 · 模擬B Q137 · 模擬x Q76

子主題 12: 文化整合 + Tailoring + 跨文化沟通

核心： - 文化差異透過更新 communications plan 處理(語言、頻率、媒介、文化禁忌)，且需 stakeholder 共識，不是單一培訓 - 文化議題標準動作 = 與 stakeholder 合作 + 更新 communication plan；Training 是後續動作 - Tailoring(裁剪) 是 PMI 處理組織文化差異的核心原則 — 適應 culture 而非強推流程；Tailoring 三場景「文化 / 規模 / 領域」，文化最常考 - Multi-culture 沟通 = 提案 + 等回饋 + 共識(不強制不投票) = PMI 標準協商「提 + 等 + 決」三步 - Engagement 規劃三軸「期待 × 影響 × 文化」；監督三軸「影響 × 參與 × 態度」 - Stakeholder prioritization 看的是 expectation of benefits + influence + organizational culture 三軸

出題形式： - 「跨文化團隊組成」→ 更新 comms plan + stakeholder 共識 - 「文化差異解決方案」→ 不是單一培訓，是 stakeholder 共建 + comms plan - 「PMI 文化差異核心原則」→ Tailoring (裁剪適應) - 「跨文化會議怎決議」→ 提 + 等 + 決(不投票不強制) - 「Engagement 優先級三軸」→ 期待 × 影響 × 文化

題號：模擬1 Q8 · 模擬1 Q110 · 模擬A Q7 · 模擬A Q77 · 模擬A Q112 · 模擬B Q59 · 模擬x Q160

子主題 13: 沟通粒度 + 沟通診斷雙文件 + 沟通儲存定義

核心： - 沟通失效常因資訊粒度太細(如 50 次外部 update 太細)，需中段綜合；粒度合適 + 中段綜合勝過量大 - 「沟通不足 + stakeholder 不滿」第一步 = comms plan + stakeholder register 雙文件診斷 - comms plan = 設計(沟通安排) - stakeholder register = 需求(誰、需什麼資訊) - 沟通管理計畫定義儲存位置 / 責任人 / 媒介;log 是執行記錄不是儲存定義 - 「該員職責定義保存在哪」(job description 描述儲存位置) → 沟通計畫 - Stakeholder register 是儲存 stakeholder 資訊(含沟通需求)的權威文件 - 沟通任務分配 = comms plan(plan 定誰沟通什麼) - Architecture interface change 必沟通條件 = 影響到其他 component 或整體架構 → 沟通範圍由「影響擴散範圍」決定

出題形式： - 「50 次外部 status update 為何失效」→ 粒度太細，需中段綜合 - 「沟通不足診斷看哪兩份文件」→ comms plan + stakeholder register - 「沟通資訊儲存位置定義在哪」→ comms plan(非 log) - 「Interface change 何時必沟通」→ 影響擴散到其他 component - 「任務分配誰沟通什麼」→ comms plan

題號：模擬1 Q43 · 模擬1 Q116 · 模擬1 Q148 · 模擬A Q51 · 模擬A Q80 · 模擬A Q117 · 模擬A Q149 · 模擬B Q140 · 模擬x Q146

子主題 14: 沟通輸出三層 + 沟通渠道公式 + NCC 軟技巧

核心： - 沟通輸出三層「Dashboard(即時/Red flag) → Report(定期 Performance) → PMP(計畫)」 - Dashboard = 高層 snapshot / 紅黃綠燈，適合 sponsor / GB 快速看風險與差異 - Performance report = 定期完整報告，內含 Status + Cost + Risk - Status dashboard 適合 sponsor 快速看「目前風險與差異狀況」 - 沟通渠道公式 = n(n-1)/2，且 PgM 自己也算 1 人 - NCC 三件套 = Negotiation + Conflict resolution + Communication = PMI 標準軟技巧 trio (Interpersonal skills) - Program 管理核心技能 7 件套 = 沟通 + stakeholder + 領導 + 變革 + 分析 + 整合 + 戰略願景 - Stakeholder 強烈反對 → 先研究歷史與現狀 → 形成策略 → 再溝通(順序不可顛倒)

出題形式： - 「高層即時紅綠燈」→ Dashboard - 「定期綜合績效」→ Performance report - 「7 人團隊 + PgM 沟通渠道數」→ n=8, n(n-1)/2 = 28 - 「PMI 軟技巧三件套」→ NCC (Negotiation + Conflict + Communication) - 「Stakeholder 強烈反對先做什麼」→ 先研究歷史與現狀

題號：模擬1 Q46 · 模擬A Q67 · 模擬A Q78 · 模擬B Q20 · 模擬B Q85 · 模擬x Q40 · 模擬x Q156

倫理 + 干擾項 + 單字易混

PMI 倫理「拒+透明+紀錄」三步、反覆出現的錯誤選項（Critical Chain/PERT/非標術語）、PgMP 易混 PMI 詞彙對照（Outcomes vs Benefits、BMP vs Roadmap、Register vs SEP、OPA vs EEF、Program vs Project/Portfolio） 收錄 62 條原料,聚類為 18 個知識點

PMI 倫理

子主題 1: 倫理「拒 + 透明 + 紀錄」三步

核心: 面對行賄/利益衝突 → 直接拒絕 + 透明討論 + 紀錄。不變通、不請示、不憑 PgM 個人決定。Self-judgment 永遠是錯的選項。

出題形式: - 「客戶/供應商提供金錢/禮物/個人利益」→ 拒絕 + 透明 + 紀錄 - 「PgM 與某 stakeholder 有利益關係」→ 揭露 + 走公司正式利益衝突確認程序(獨立第三方判斷) - 「廠商行賄要過 gate」→ 直接拒絕 + 透明討論

陷阱: - 「PgM 自行評估後接受」→ Self-judgment 必錯 - 「變通處理 / 私下回絕不留紀錄」→ 缺透明缺紀錄 - 「先請示後再決定」→ 不夠果斷，倫理題要直接拒

題號: 模擬1 Q94 · 模擬B Q93 · 模擬B Q151

子主題 2: PMI 倫理「正向能力觀」— 接受 + 補強

核心: PMI Code of Ethics 的 Responsibility + Competence 強調主動成長。能力不足 / 機會來臨時 → 接受 + 識別差距 + 培訓補強，不是直接拒絕也不是盲衝。

出題形式: - 「指派新領域 program，PgM 經驗不足」→ 接受 + 補強技能(A 選項) - 「成長機會出現」→ 接受 + 主動識別差距 + 請求支援

陷阱: - 「立刻拒絕避免風險」→ 違反 responsibility - 「直接接受不評估」→ 違反 competence

題號: 模擬1 Q95 · 模擬A Q98

子主題 3: 與 stakeholder 建立關係的「合法 vs 不合法」界線

核心: 與 stakeholder 的非正式交流（午餐/晚宴/關係建立）= legitimate relationship building，是 stakeholder engagement 的一部分。only 變成「個人利益交換」才不道德。

出題形式: - 「PgM 與外部 stakeholder 約晚餐討論 program 進展」→ 合法的關係建立(A) - 「PgM 收受廠商個人禮物換取合約」→ 不道德

陷阱: 把所有非正式接觸都打成「不道德」是過度反應，PMI 觀點區分「公務場合的關係建立」vs「私人利益交換」

題號: 模擬1 Q87

子主題 4: 文化敏感性 = Comms Plan + Stakeholder 共識

核心: 處理跨文化團隊 / 跨國 program → 更新 communications plan(語言、頻率、媒介、文化禁忌) + stakeholder 共識。不是單一培訓也不是強推流程。Tailoring 是 PMI 處理組織文化差異的核心原則。

出題形式: - 「Program 在多國運作出現文化摩擦」→ 更新 Comms plan + Stakeholder 共識 - 「跨國決策」→ 提案 + 等回饋 + 共識(不強制、不投票) - 「文化差異整合」→ 適應 culture 而非強推流程(Tailoring)

陷阱: - 「直接培訓所有人」→ 單一培訓不夠 - 「跳過共識直接執行」→ 缺 stakeholder 對齊

題號: 模擬1 Q110 · 模擬A Q77 · 模擬A Q112 · 模擬B Q59 · 模擬B Q74 · 模擬x Q160 · 模擬x Q170

子主題 5: 透明 / 公平 / 服從治理 三守則

核心: - Transition / Financial baseline 變動 → 公開 review、透明 + 全體 + 一致、必通知治理 + 審計 - 治理委員會做出決策 → PM 職責是執行，不是反對。爭辯型答案永遠錯 - Gate review = 治理紀律，不能因客戶滿意就停掉

出題形式: - 「Transition plan 怎麼 review」→ 公開 + 全 sellers 一致(不分群討論) - 「Steering 要求 closure，PgM 怎麼做」→ 立即行動，不爭辯 - 「客戶說 gate review 沒必要」→ 堅持治理流程

題號: 模擬1 Q41 · 模擬1 Q128 · 模擬x Q103 · 模擬x Q114

干擾項陷阱清單

反覆當錯誤答案的概念

單字易混對照

易混詞彙速查表

補充說明 — PgMP 答題語感（Develop vs Foster 推測）

核心: 題庫沒直接出現 Develop Relationship vs Foster Relationship 對比題，但志龍提示「Develop / Foster 兩者常為正解」。對應到題庫的「培養關係 / 建立關係 / relationship building」概念都收斂在以下用法:

• 建立關係（establish relationship）→ Roadmap(視覺化 activity ↔ benefit 橋樑)
• 培養關係（cultivate / develop）→ SEP 找預定 engagement strategy
• stakeholder engagement 是 PgMP 主動行為而非被動接受 — sponsor 的悲觀不能成為 PM 不作為的藉口

題號: 模擬1 Q2 · 模擬1 Q28 · 模擬1 Q87 · 模擬1 Q125