PGMP 跨章節綜合題集

1️⃣ 題幹:A newly assigned PgM joins a smart-city transformation program. The sponsor wants to know how the program supports corporate strategy and when incremental benefits will land. The component PMs each provide their own slide decks. What should the PgM do NEXT?
新任 PgM 接手智慧城市轉型項目集。發起人想知道項目集如何支援公司戰略、增量收益何時實現。組件 PM 各自提供自己的簡報。PgM 下一步該做什麼?
A. 請 PMO 統一各 PM 簡報模板後彙整呈報
B. 立即召開治理委員會說明戰略對齊
C. 由 PgM 親自整合 business and program roadmap 向發起人呈報
D. 把問題下放給組件 PM 各自說明各組件對戰略的貢獻

2️⃣ 考點:戰略對齊的承載文件(business + program roadmap)+ Program Manager 不能下放的「戰略呈現」職責 + 下一步反射(先呈現整合視圖,而非開治理會議)。

3️⃣ 逐項排除

• A:統一模板是 PMO 的事,但題幹要的是戰略對齊內容而非格式,順序錯置。
• B:還沒整合資料就召開治理委員會,沒料可講,且戰略對齊溝通屬 PgM 日常職權,不必動到 Board。
• C ✅:Business + program roadmap 是戰略對齊 + 收益時序的雙效文件,且這是 PgM 親自負責、不能下放的整合視圖,符合「下一步反射」。
• D:把戰略對齊下放給組件 PM = 各自為政,違反 PgM 的整合協調職責,各 PM 只看自己的組件範圍。

4️⃣ 最佳選項:C
判斷關鍵:「戰略對齊 + 增量收益時序」雙重訴求 = roadmap;「呈現給發起人」= PgM 親自不能下放。

5️⃣ 實務記憶:口訣「戰略題用 Roadmap、整合呈現 PgM 親自」。三主題混合時優先抓「呈報對象 = 發起人」這個訊號,角色立刻定位在 PgM 自己。

1️⃣ 題幹:During program execution, two component PMs disagree on resource priority. Each cites different sections of the program management plan. The PgM needs to resolve quickly. What should the PgM do NEXT?
項目集執行期間,兩位組件 PM 對資源優先順序有分歧,各自引用項目集管理計畫的不同章節。PgM 需快速解決。下一步該做什麼?
A. 直接根據自己判斷裁示資源分配
B. 對照 program resource management plan 與 priority schema,釐清優先順序規則後協調雙方
C. 把爭議升報指導委員會請其裁示
D. 召集 PMO 重寫整份 program management plan

2️⃣ 考點:文件對照(找對的文件 = resource management plan + priority schema)+ 下一步(PgM 先用文件協調,不是裁示也不是升報)+ 角色職責(PgM 是協調者,不是獨裁者也不是直接走治理)。

3️⃣ 逐項排除

• A:直接裁示違反 PgM 的協調定位,且未對照文件依據,屬於主觀決策。
• B ✅:先對照「對的文件」(resource management plan 含 priority schema),依文件規則協調雙方,是 PgM 標準的整合管理動作。
• C:升報治理委員會跳過 PgM 的協調權,違反 escalation 漸進原則。
• D:重寫整份 program management plan 過度反應,且太晚解決當下爭議。

4️⃣ 最佳選項:B
判斷關鍵:看到「資源優先順序」直接定位 Resource Management Plan;PgM 的標準動作是「依文件協調」而非裁示或升報。

5️⃣ 實務記憶:口訣「先對文件、再協調、最後才升報」。資源優先順序 = Resource Management Plan,不是 Program Charter 或 Roadmap。

1️⃣ 題幹:A program sponsor questions whether the program is still aligned with updated corporate strategy after a recent CEO change. The PgM has the program charter, roadmap, and benefits management plan on hand. What should the PgM do NEXT?
項目集發起人質疑近期 CEO 更換後項目集是否仍與更新後的公司戰略對齊。PgM 手上有 charter、roadmap、benefits management plan。下一步該做什麼?
A. 立即修改 program charter 反映新戰略
B. 暫停所有組件並等待新戰略明朗
C. 召集治理委員會討論是否終止項目集
D. 以 charter 為基準對照新戰略,評估 benefits 與 roadmap 影響後向治理委員會提報

2️⃣ 考點:文件對照(charter 是戰略對齊的基準文件)+ 下一步(先評估再提報,不是先動文件也不是先停組件)+ 角色職責(PgM 評估 → Governance 決策)。

3️⃣ 逐項排除

• A:還沒評估就改 charter = 順序錯,且 charter 通常由 Governance 授權,PgM 無權單方面修改。
• B:暫停所有組件影響 benefits realization,屬於激烈反應,不該在評估前做。
• C:還沒評估影響就討論終止 = 跳過 PgM 該做的「先評估再提報」職責。
• D ✅:PgM 標準動作 = 以 charter(戰略對齊基準)為起點對照新戰略,評估對 benefits 與 roadmap 的影響,再向治理委員會提報供決策。這是 PgM 評估 + Governance 決策的標準分工。

4️⃣ 最佳選項:D
判斷關鍵:「戰略變動」第一個對照的是 Charter(戰略對齊基準),不是 roadmap(時序圖)或 BMP(指標);評估是 PgM 職責,決策是 Governance 職責。

5️⃣ 實務記憶:口訣「戰略變 → 對 Charter、評估 PgM 做、決策 Board 拍」。記住「Assess First 黃金鏈」:Assess → Review/Update → Communicate。

1️⃣ 題幹:A component project requires a new vendor outside the approved supplier list. The component PM asks the PgM how to proceed. What should the PgM do NEXT?
某組件項目需要採購商核可清單外的新供應商。組件 PM 詢問 PgM 該如何進行。PgM 下一步該做什麼?
A. 對照 program procurement management plan 與 governance plan,確認新增供應商的審批路徑,指導 PM 走正式流程
B. 直接核准新供應商以加快進度
C. 把問題完全交給組件 PM 自行處理
D. 召集治理委員會討論是否例外處理

2️⃣ 考點:文件對照(procurement management plan + governance plan)+ 下一步(走正式審批流程)+ 角色職責(PgM 是流程指導者,不是核准者,不是甩鍋者)。

3️⃣ 逐項排除

• A ✅:對照兩份文件(採購計畫 + 治理計畫)確認審批路徑,指導 PM 走正式流程,是 PgM 的標準動作 - 整合 + 治理框架運用。
• B:PgM 直接核准 = 跳過 governance,且未必有此權限,違反治理框架。
• C:完全甩給組件 PM = PgM 失職,沒提供應有的程序指導。
• D:小事走治理委員會 = escalation 過度,違反漸進原則。

4️⃣ 最佳選項:A
判斷關鍵:供應商審批 = procurement 流程,PgM 對照計畫 + 指導 PM 走流程,不直接核准也不甩鍋。

5️⃣ 實務記憶:口訣「採購問題對 procurement plan + governance plan」。PgM 是「教 PM 走流程」的人,不是替 PM 核准的人。

1️⃣ 題幹:During quarterly stakeholder review, several stakeholders complain they were not informed of recent program changes. The PgM realizes the communications matrix may be outdated. What should the PgM do NEXT?
季度利害關係人審查時,多位利害關係人抱怨未收到近期項目集變更通知。PgM 意識到溝通矩陣可能已過時。下一步該做什麼?
A. 立即向所有利害關係人發送補充通知
B. 把責任推給組件 PM
C. 對照 stakeholder register 與 communications management plan,更新 engagement assessment matrix 後重新規劃溝通頻率與管道
D. 召集治理委員會討論溝通失效

2️⃣ 考點:文件對照(三件套:stakeholder register + communications management plan + stakeholder engagement assessment matrix)+ 下一步(先評估更新文件再執行)+ 角色職責(PgM 親自負責利害關係人關係,不下放也不升報)。

3️⃣ 逐項排除

• A:補發通知是治標,沒解決矩陣過時的根因,且沒對照文件確認誰該收到什麼。
• B:推給組件 PM = PgM 失職,stakeholder engagement 是 PgM 親自負責。
• C ✅:三份文件對照(stakeholder register / communications plan / engagement assessment matrix)是 stakeholder engagement 的標準三件套,先更新文件再規劃溝通 = 從根因解決。
• D:溝通矩陣過時是 PgM 該自己修的問題,不需動到治理委員會。

4️⃣ 最佳選項:C
判斷關鍵:「stakeholder 沒被通知」直接對照三件套(register + comms plan + engagement matrix),PgM 親自處理。

5️⃣ 實務記憶:口訣「Stakeholder 三件套:Register / Plan / Matrix」。看到 stakeholder 溝通問題立刻找這三份文件,且必由 PgM 親自處理(Develop / Foster / Build Relationship 是正解信號)。

1️⃣ 題幹:Mid-program metrics: BAC=10M USD, EV=4M, AC=5M, PV=4.5M. Two component PMs propose absorbing a new regulatory requirement within current budget. What should the PgM do NEXT?
項目集中期指標:BAC=10M、EV=4M、AC=5M、PV=4.5M。兩位組件 PM 提議在現有預算內吸收新法規需求。下一步該做什麼?
A. 接受 PM 提議以避免變更程序成本
B. 計算 CPI=0.8、SPI=0.89,確認已超支落後,將新法規需求送入正式變更管控評估對 EAC 與風險的影響
C. 立即升報治理委員會請求追加預算
D. 推遲新法規需求至下一個項目集

2️⃣ 考點:EVM 計算(CPI=EV/AC=0.8 超支、SPI=EV/PV=0.89 落後)+ 風險識別(新法規未評估即吸收 = 新增風險)+ 變更管理(走正式變更流程,不是繞過)。

3️⃣ 逐項排除

• A:在已超支落後狀態下「吸收」新範圍 = 雪上加霜,且繞過變更管控違反流程。
• B ✅:先算 CPI/SPI 證實已超支落後,將新法規送變更管控(component → program CCB),評估對 EAC、風險、benefits 的整體影響後再決定。是 PgM 的標準綜合反射。
• C:還沒評估就升報追加預算 = 跳過 PgM 該做的影響評估,且未必需要追加(可能可調整其他組件)。
• D:推遲法規需求往往不可行(法規有時程強制),且未做評估就推遲屬主觀決策。

4️⃣ 最佳選項:B
判斷關鍵:CPI<1 + SPI<1 = 已亮紅燈,新範圍必須走正式變更管控,Program 鼓勵變更但要走流程不能繞過。

5️⃣ 實務記憶:口訣「先算 CPI/SPI、再走 CCB、最後升報」。EVM 計算公式:CPI=EV/AC、SPI=EV/PV,小於 1 即不利。Program 鼓勵變更 ≠ 接受繞過流程。

1️⃣ 題幹:A program has 8 components. One component shows TCPI=1.35 (需要極高效率才能達標) and rising risk exposure due to vendor instability. A change request to swap vendors is proposed. What should the PgM do NEXT?
某項目集 8 個組件。一個組件 TCPI=1.35(需極高效率才能達標)且供應商不穩風險上升。提出更換供應商的變更請求。下一步該做什麼?
A. 立刻批准換供應商以止血
B. 拒絕變更維持原供應商
C. 把問題完全交由組件 PM 與供應商談判
D. 評估該組件對 program benefits 的關鍵性、更新 risk register、將變更請求送 program CCB 並評估對其他組件的連動影響

2️⃣ 考點:EVM TCPI(>1.1 通常不可達)+ 風險登記更新 + 跨組件變更影響評估(雙層 CCB:component → program)。

3️⃣ 逐項排除

• A:立刻批准跳過評估與變更程序,且未評估對其他組件的連動影響。
• B:拒絕變更等於放任 TCPI 危機 + 供應商風險,違反「Program 鼓勵變更」原則。
• C:完全交給組件 PM = PgM 失職,跨組件議題 PgM 必須介入。
• D ✅:TCPI=1.35 已警示原計畫近不可達,PgM 先評估關鍵性 + 更新風險 + 送 program CCB(因影響跨組件),三主題綜合反射。

4️⃣ 最佳選項:D
判斷關鍵:TCPI > 1.1 警示原計畫難達 + 風險變化 + 跨組件影響 = 必送 program CCB(雙層 CCB 中的 program 層)。

5️⃣ 實務記憶:口訣「TCPI > 1.1 拉警報、跨組件變更上 program CCB」。TCPI = (BAC-EV)/(BAC-AC),代表「剩餘工作要多有效率才能達標」。

1️⃣ 題幹:EAC trending higher than BAC by 12%. Risk register shows three high-impact risks materialized this quarter. Stakeholders demand action. What should the PgM do NEXT?
EAC 高出 BAC 12%。風險登記顯示本季三個高影響風險已發生。利害關係人要求行動。下一步該做什麼?
A. 對照 risk response plan,執行已預先規劃的回應,並將 EAC 與風險變化匯整成變更請求送 program CCB 與 governance board 評估
B. 立即砍預算 12% 平衡 EAC
C. 解散該項目集釋出資源
D. 隱瞞風險避免利害關係人恐慌

2️⃣ 考點:EVM(EAC > BAC = 預期超支)+ 風險(已發生風險需執行預先計畫的回應)+ 變更管理(超出 tolerance 需送 CCB + Governance 雙層)。

3️⃣ 逐項排除

• A ✅:已有 risk response plan 就執行(這是預先規劃的目的),變化大到改變 EAC 12% 屬重大變更,送 program CCB + governance board(因影響預算門檻),是三主題綜合反射。
• B:砍預算 12% 不解決根因,且未經評估即執行,違反變更管控。
• C:解散項目集是極端反應,還沒評估其他選項。
• D:隱瞞風險違反 PgM 透明溝通職責,且阻礙正確決策。

4️⃣ 最佳選項:A
判斷關鍵:已發生風險 → 執行預先 response plan;EAC 變化 12% 超出 tolerance → 送 CCB + Governance(因涉及預算戰略議題)。

5️⃣ 實務記憶:口訣「風險發生 → 跑 response plan、超預算 tolerance → 送雙層」。EAC = AC + ETC,EAC > BAC 即預期最終超支。

1️⃣ 題幹:Component A reports CPI=1.1 (efficient), Component B reports CPI=0.7 (over-spending). The PgM is asked to reallocate Component A's underspend budget to Component B. What should the PgM do NEXT?
組件 A 報 CPI=1.1(效率佳)、組件 B 報 CPI=0.7(超支)。有人請 PgM 把組件 A 的未支出預算挪給組件 B。下一步該做什麼?
A. 直接同意挪用以止住 B 的超支
B. 評估雙方對 program benefits 的關鍵性與風險暴露,作為跨組件變更送 program CCB 審批
C. 拒絕挪用,讓 B 自己想辦法
D. 終止組件 B

2️⃣ 考點:EVM 跨組件比較(CPI 差異)+ 風險(挪用對 A 的 benefits 風險)+ 變更管理(跨組件預算重分配 = 跨組件變更必送 program CCB)。

3️⃣ 逐項排除

• A:直接同意 = 繞過變更管控,且未評估對 A benefits 的風險。
• B ✅:跨組件預算挪用 = 跨組件變更,必送 program CCB;且需評估雙方對 benefits 的關鍵性與風險,是 PgM 的標準綜合動作。
• C:拒絕又不評估 = 失職,沒履行整合管理職責。
• D:終止組件 B 是極端反應,沒先試其他選項。

4️⃣ 最佳選項:B
判斷關鍵:跨組件預算挪用 = 跨組件變更 = 必送 program CCB,且需綜合評估雙方影響。

5️⃣ 實務記憶:口訣「跨組件預算挪用一律走 program CCB」。CPI > 1 不代表可隨意挪走,要先看對 benefits 的影響。

1️⃣ 題幹:A program's SPI drops to 0.75 after a key supplier missed a major milestone. The risk was identified earlier but no mitigation was activated. Stakeholders demand recovery. What should the PgM do NEXT?
某項目集 SPI 因關鍵供應商錯過里程碑而降至 0.75。該風險早被識別但未啟動緩解。利害關係人要求復原。下一步該做什麼?
A. 開除供應商換新人
B. 隱瞞 SPI 等下季再說
C. 啟動原本規劃的 risk response、評估 schedule 復原方案(crashing/fast-tracking)、將復原方案與成本影響送 program CCB
D. 把問題完全交給供應商管理部門

2️⃣ 考點:EVM SPI(<1 落後)+ 風險(預先識別但未啟動 response = 該補啟動)+ 變更管理(復原方案改變 baseline 需走 CCB)。

3️⃣ 逐項排除

• A:極端反應,且未先嘗試緩解。
• B:隱瞞違反透明原則,且越拖越嚴重。
• C ✅:風險已識別 → 補啟動 response;落後 → 評估 crashing/fast-tracking 復原方案;改 baseline → 送 CCB。完美三主題綜合反射。
• D:完全甩鍋 = PgM 失職,跨組件議題必須 PgM 介入。

4️⃣ 最佳選項:C
判斷關鍵:SPI=0.75 + 風險未啟動 response = 雙重失誤,PgM 補啟動 + 評估復原 + 走變更管控,三件套同時做。

5️⃣ 實務記憶:口訣「風險已識別就要啟動 response,落後就評估 crashing/fast-track」。記住:Crashing = 加資源加錢、Fast-tracking = 並行高風險。

1️⃣ 題幹:Two senior executives (CFO and CIO) publicly disagree on the program's investment priorities at a governance meeting. The PgM senses this could escalate. What should the PgM do NEXT?
兩位高階主管(CFO 與 CIO)在治理會議公開對項目集投資優先順序意見不合。PgM 感覺可能升級。下一步該做什麼?
A. 對照 stakeholder engagement plan 與 governance plan,協助雙方在治理框架內提交議題到 portfolio steering committee 仲裁
B. 在會議中直接判定哪位主管的意見正確
C. 私下選邊站,確保未來資源
D. 忽略爭議,讓主管自己解決

2️⃣ 考點:Stakeholder engagement(高階利害關係人)+ 衝突管理(高階主管衝突 PgM 不可裁示)+ 治理(高階主管衝突屬 portfolio 或 steering committee 層級)。

3️⃣ 逐項排除

• A ✅:PgM 角色是「促進」而非「裁示」高階衝突;對照 engagement plan + governance plan,把議題在治理框架內提交對的層級(portfolio steering committee)仲裁,是標準動作。
• B:PgM 沒權限裁定 CFO/CIO 誰對,且違反專業中立。
• C:選邊站違反 PgM 中立職責,且會破壞 stakeholder 關係。
• D:忽略爭議違反「Foster relationship」原則,且讓爭議可能影響 program。

4️⃣ 最佳選項:A
判斷關鍵:高階主管衝突 = 超出 PgM 裁示權,但 PgM 要「促進在治理框架內解決」,不是逃避也不是越權。

5️⃣ 實務記憶:口訣「高階衝突 PgM 促進不裁示、走治理框架仲裁」。PgM 的標準動作 = Develop / Foster / Build Relationship(三 verb 都是正解信號)。

1️⃣ 題幹:A key external regulator (high power, low interest currently) suddenly increased interest in the program due to media coverage. The PgM detects misalignment between regulator expectations and current program direction. What should the PgM do NEXT?
某外部關鍵監管者(目前高權低關注)因媒體報導突然提高關注。PgM 偵測到監管者期望與項目集方向不一致。下一步該做什麼?
A. 等監管者主動提出要求再回應
B. 透過媒體公開回應監管者
C. 把監管者問題交給法務部門
D. 更新 stakeholder engagement plan(因 power/interest 變化)、與 governance board 對齊應對策略、主動約見監管者 build relationship

2️⃣ 考點:Stakeholder 變化(power/interest 矩陣 quadrant 移動)+ 衝突預防(期望不一致主動處理)+ 治理(外部監管屬高階議題需 governance 對齊)。

3️⃣ 逐項排除

• A:被動等待 = 違反 PgM 的主動利害關係人管理,且風險擴大。
• B:透過媒體回應 = 失控的單向溝通,可能擴大爭議。
• C:甩給法務 = PgM 失職,且法務不負責 stakeholder engagement。
• D ✅:三主題綜合反射 - 更新 engagement plan(因 stakeholder 變化)+ 與 governance 對齊(外部監管屬高階議題)+ 主動 build relationship(PgM 的核心動詞)。

4️⃣ 最佳選項:D
判斷關鍵:外部監管者變化 = 三主題全觸發 - stakeholder 矩陣要更新 + 治理層級議題要對齊 + 主動 build relationship。

5️⃣ 實務記憶:口訣「Stakeholder 變化先更新矩陣、外部高階對齊 governance、永遠 Build Relationship」。Power/Interest 矩陣的 quadrant 移動是 engagement plan 必須更新的觸發信號。

1️⃣ 題幹:A component PM repeatedly bypasses the PgM and reports directly to the sponsor, creating tension. The sponsor seems to enjoy the direct access. What should the PgM do NEXT?
某組件 PM 反覆繞過 PgM 直接向發起人匯報,造成緊張。發起人似乎享受這種直接接觸。下一步該做什麼?
A. 公開譴責組件 PM 越權
B. 對照 governance plan 與 communications management plan 釐清匯報路徑,私下與發起人協調建立正式 channel,並與組件 PM 重申角色職責
C. 解雇組件 PM
D. 順其自然讓 PM 繼續越級匯報

2️⃣ 考點:Stakeholder(發起人 + 組件 PM 雙重)+ 衝突管理(內部繞報衝突)+ 治理(匯報路徑 governance 議題)。

3️⃣ 逐項排除

• A:公開譴責破壞關係,且不解決根因。
• B ✅:三步驟綜合 - 文件對照(治理 + 溝通計畫釐清匯報路徑)+ 私下與發起人協調(維護關係 + 建立正式 channel)+ 與 PM 重申角色(角色職責澄清)。
• C:過度反應,還沒先試協調。
• D:順其自然 = PgM 失職,且整合管理受損。

4️⃣ 最佳選項:B
判斷關鍵:繞報問題不能公開衝突,也不能順其自然,要走「文件對照 + 私下協調 + 角色澄清」三步驟。

5️⃣ 實務記憶:口訣「繞報衝突先看治理計畫的 reporting channel、再私下 build relationship」。發起人是高層,得罪不得 - 私下協調勝過公開譴責。

1️⃣ 題幹:A new governance board member challenges the program's existing decision-making framework, claiming it is too slow. Other board members support the existing framework. What should the PgM do NEXT?
新加入治理委員會的成員質疑現有決策框架太慢,其他成員支持現有框架。PgM 下一步該做什麼?
A. 立即依新成員意見修改決策框架
B. 忽略新成員的質疑
C. 對照 governance plan 呈現框架的歷史依據與運作數據,促進 board 內部討論達成共識,必要時更新框架
D. 把新成員從 board 移除

2️⃣ 考點:Stakeholder(新加入的 governance 成員)+ 衝突管理(board 內部不同意見)+ 治理(治理框架本身是否需更新)。

3️⃣ 逐項排除

• A:單憑新成員意見就改框架 = 違反多數共識,且未評估影響。
• B:忽略新成員 = 違反 PgM 的 stakeholder engagement 原則,且新成員可能是高權力者。
• C ✅:綜合三主題 - 對照 governance plan(文件)+ 促進 board 內部討論(衝突管理)+ 必要時更新框架(治理演進)。PgM 是促進者不是裁示者。
• D:PgM 無權移除 board 成員,且違反治理結構。

4️⃣ 最佳選項:C
判斷關鍵:Board 內部衝突 PgM 是促進者,提供文件依據 + 促進共識,不是替 board 做決策。

5️⃣ 實務記憶:口訣「Board 內部衝突 PgM 提資料、促進、不裁示」。Governance plan 是裁判文件,PgM 是球員兼裁判助手,不是裁判本人。

1️⃣ 題幹:A program is approaching closure. Three components have delivered, but benefits realization shows only 60% of expected metrics achieved. Operations team is reluctant to take over. What should the PgM do NEXT?
某項目集即將收尾。三個組件已交付,但 benefits 實現顯示僅達預期指標 60%。營運團隊不願接手。下一步該做什麼?
A. 強行移交給營運團隊以準時收尾
B. 隱瞞 benefits 落差繼續收尾
C. 延後 closure 等到 benefits 達 100% 再說
D. 與 sponsor 及營運團隊評估 benefits 落差根因,擬定 sustainment plan 將剩餘 benefits 在 transition 後持續監測,文件化教訓進知識庫後再正式 close

2️⃣ 考點:Benefits transition(移交營運不能強行)+ Sustainment(benefits 可在 close 後持續實現)+ Closing(close 三件套:評估 + 文件 + 知識庫)。

3️⃣ 逐項排除

• A:強行移交 = 違反 transition 雙方同意原則,且 benefits 未達標的鍋會被營運接走。
• B:隱瞞落差違反透明原則,且後續 benefits 監測不可能。
• C:無限延後 closure 不切實際,且 benefits 本可在 close 後持續實現。
• D ✅:綜合三主題 - 評估根因(透明)+ 擬 sustainment plan(close 後持續監測)+ 文件化教訓 + 知識庫(close 三件套)。

4️⃣ 最佳選項:D
判斷關鍵:Program 鐵律「Benefits 可在 close 後實現」+ Sustainment plan 是橋樑 + close 三件套(評估 / 教訓 / 知識庫)缺一不可。

5️⃣ 實務記憶:口訣「Benefits 未達標不阻止 close,Sustainment 接手 60% → 100%」。Close program ≠ Close benefits,兩條時間線不同。

1️⃣ 題幹:During transition phase, the operations manager requests detailed training and runbooks before accepting handover. The PgM has not budgeted for this. What should the PgM do NEXT?
Transition 階段,營運經理要求接手前提供詳細訓練與 runbook。PgM 未編此預算。下一步該做什麼?
A. 評估 transition readiness 缺口,將訓練/runbook 需求送 program CCB 評估預算與 schedule 影響,並更新 transition plan
B. 拒絕營運經理要求準時關閉
C. 找個藉口拖延 transition
D. 把訓練責任完全甩給營運團隊

2️⃣ 考點:Benefits transition(營運不接 = benefits 無法持續)+ Sustainment(訓練 + runbook 是 sustainment 基礎)+ Closing(transition 是 close 前置條件)。

3️⃣ 逐項排除

• A ✅:三主題綜合 - 評估 transition readiness(transition 主題)+ 走變更管控(因新增訓練需求屬範圍變更)+ 更新 transition plan(支撐 sustainment)。
• B:拒絕營運要求 = transition 失敗 = benefits 無法持續,違反 PgM 核心職責。
• C:拖延不解決根因。
• D:甩鍋給營運 = 違反 transition 共擔原則,且營運可能無資源做。

4️⃣ 最佳選項:A
判斷關鍵:Transition readiness 缺口要評估 + 走變更管控,不是拒絕也不是甩鍋。Transition 是 PgM 與營運雙方共擔。

5️⃣ 實務記憶:口訣「Transition readiness 不夠先評估、走變更管控、不甩鍋」。Training + Runbook 是 sustainment 的兩塊基石。

1️⃣ 題幹:Six months after program closure, sustainment review shows benefits declining due to operations not following the original benefits realization process. The previous PgM has left the company. Who should be involved?
項目集關閉六個月後,sustainment 審查顯示 benefits 因營運未依原 benefits realization 流程而下降。前任 PgM 已離職。應由誰參與?
A. 直接認賠,benefits 無法挽救
B. Program sponsor、operations owner、benefits owner 共同檢視 sustainment plan 與 lessons learned,啟動補救行動
C. 重新啟動該項目集
D. 把責任推給已離職的前任 PgM

2️⃣ 考點:Sustainment(close 後 benefits 持續責任歸屬)+ Closing 的文件遺產(lessons learned + sustainment plan)+ 角色職責(sponsor / ops owner / benefits owner 仍在崗)。

3️⃣ 逐項排除

• A:認賠 = 違反 benefits 可持續實現原則,且未試補救。
• B ✅:三主題綜合 - sustainment 屬 sponsor + ops owner + benefits owner 共同責任(角色)+ 對照 sustainment plan 與 lessons learned(close 遺產)+ 啟動補救(benefits 仍可挽救)。
• C:重啟項目集是極端反應,且未必必要。
• D:推給已離職的前任 PgM 違反 PgM 文化(透明 + 學習導向)。

4️⃣ 最佳選項:B
判斷關鍵:Close 後 benefits 由 sponsor + ops owner + benefits owner 守護,close 的文件遺產(sustainment plan + lessons learned)是補救的基準。

5️⃣ 實務記憶:口訣「Close 後 benefits 三角守護:Sponsor / Ops / Benefits Owner」。前任 PgM 離職不影響 sustainment 責任歸屬。

1️⃣ 題幹:The PgM is preparing the final program closure report. Sponsor requests a single document showing benefits delivered, lessons learned, and sustainment commitments. What should the PgM produce?
PgM 準備最終項目集收尾報告。發起人要求一份文件顯示已交付 benefits、教訓與 sustainment 承諾。PgM 該產出?
A. Program charter 更新版
B. Program management plan 收尾版
C. Final program report,整合 benefits realization 紀錄 + lessons learned + sustainment plan,並確認 lessons learned 已進入組織知識庫
D. Component closure reports 的集合

2️⃣ 考點:Closing 階段的核心交付物(Final program report)+ Sustainment(sustainment plan 是 close 的一部分)+ Transition(benefits 已交付紀錄是 close 的證據)。

3️⃣ 逐項排除

• A:Charter 是起源文件,不是收尾文件,不該在 close 時更新。
• B:Program management plan 是執行期文件,close 時不該再更新。
• C ✅:Final program report 是 close 階段的標準綜合交付物,整合三大要素:benefits 已交付 + lessons learned + sustainment plan,並必須確認 lessons learned 進入組織知識庫(close 三件套之一)。
• D:Component reports 是組件層級,不是 program 層級的收尾文件。

4️⃣ 最佳選項:C
判斷關鍵:Close 三件套 = 評估收益 / 文件化教訓 / 進知識庫,Final program report 是承載者,sustainment plan 附加。

5️⃣ 實務記憶:口訣「Close 看 Final Report、起源看 Charter、執行看 Plan」。Close 一定要有:Final report + Lessons learned + Knowledge repository + Sustainment plan。

1️⃣ 題幹:After 18 months, the program enters its first major stage gate. Governance board asks for evidence the program is still on track to deliver strategic benefits. What should the PgM present?
18 個月後,項目集進入首次主要 stage gate。治理委員會要求佐證項目集仍能交付戰略收益。PgM 該呈報什麼?
A. Charter 與 roadmap 的對照 + benefits realization report + 當前 stage 的 gate review 文件,呈現戰略對齊持續性
B. 所有組件 status report 的合集
C. Master schedule 細節
D. 個別 PM 的工作日誌

2️⃣ 考點:Stage gate(go/no-go 決策需要的證據)+ Charter(戰略對齊基準)+ Roadmap(時序對照)。

3️⃣ 逐項排除

• A ✅:三主題綜合 - Charter(戰略基準)+ Roadmap(時序進度)+ Benefits report + Stage gate review 文件,正是 governance 做 go/no-go 決策需要的標準包。
• B:Status report 偏執行,缺戰略對齊視角,層級不對。
• C:Master schedule 是時序工具,但不直接證明戰略對齊。
• D:PM 工作日誌層級過低,且不是 program 層交付物。

4️⃣ 最佳選項:A
判斷關鍵:Stage gate 決策需「戰略對齊 + 時序 + benefits」三維證據,即 Charter + Roadmap + Benefits report 鐵三角。

5️⃣ 實務記憶:口訣「Stage gate 三證據:Charter(戰略)、Roadmap(時序)、Benefits(成果)」。Stage gate 不是看 status,是看戰略對齊是否仍成立。

1️⃣ 題幹:A program approaches its second stage gate with mixed results: benefits on track but two components show high uncertainty. Governance board considers no-go. What should the PgM do NEXT?
某項目集接近第二個 stage gate,結果混合:benefits 進度正常但兩個組件高度不確定。治理委員會考慮 no-go。PgM 下一步該做什麼?
A. 隱瞞組件不確定性以通過 gate
B. 對照 charter 確認戰略對齊仍有效,評估兩組件對 benefits 的關鍵性,提出選項(continue with mitigation / pause components / re-baseline)讓 board 做 go/no-go 決策
C. 自行決定終止項目集
D. 強迫 board 通過 gate

2️⃣ 考點:Stage gate(go/no-go 決策)+ Charter(戰略對齊驗證)+ 角色職責(PgM 提選項 board 做決策)+ Roadmap(re-baseline 屬時序調整)。

3️⃣ 逐項排除

• A:隱瞞違反透明,且若後續爆雷會更糟。
• B ✅:三主題綜合 - 對照 charter 驗戰略 + 評估 benefits 關鍵性 + 提出選項給 board(stage gate 標準動作),PgM 不替 board 做決策但提供決策資訊。
• C:PgM 無權自行終止項目集,屬 governance board 職權。
• D:PgM 不能強迫 board,違反治理結構。

4️⃣ 最佳選項:B
判斷關鍵:Stage gate 是 board 的 go/no-go 決策時機,PgM 是「提供決策資訊 + 提出選項」的角色,不是決策者也不是隱瞞者。

5️⃣ 實務記憶:口訣「Stage gate PgM 提選項、Board 做決策」。Continue / Pause / Re-baseline 是三個經典選項。

1️⃣ 題幹:Mid-program, executive leadership announces a major business pivot. The PgM realizes the original program charter may no longer reflect the new strategy. What should the PgM do NEXT?
項目集中期,執行高層宣布重大業務轉向。PgM 意識到原 charter 可能不再反映新戰略。下一步該做什麼?
A. 立即修改 charter 反映新戰略
B. 隱瞞戰略變動繼續執行
C. 對照 charter 評估戰略偏離程度、更新 roadmap 與 benefits 映射、向 governance board 提報是否需要 emergency stage gate / re-baseline / 終止
D. 假裝沒看到繼續執行

2️⃣ 考點:Charter(戰略對齊基準)+ Roadmap(時序與 benefits 映射要更新)+ Stage gate(戰略大變需 emergency stage gate)+ 角色職責(PgM 評估、board 決策)。

3️⃣ 逐項排除

• A:PgM 無權單方面改 charter,屬 governance 授權文件。
• B:隱瞞違反透明,且戰略偏離越久損害越大。
• C ✅:四件套綜合反射 - 對照 charter(戰略基準)+ 更新 roadmap 與 benefits 映射 + 提報 board 評估 emergency stage gate 或 re-baseline 或終止選項。是 PgM 經典標準動作。
• D:擺爛違反 PgM 職責。

4️⃣ 最佳選項:C
判斷關鍵:戰略大變 → 對照 charter 評估偏離 → 更新 roadmap → 走 emergency stage gate(因為原 gate 假設不成立)。

5️⃣ 實務記憶:口訣「戰略變動鐵三角:Charter 對照、Roadmap 更新、Stage gate 觸發」。Emergency stage gate 是「out-of-cycle review」,專門應對重大變動。

1️⃣ 題幹:A program's roadmap shows three planned stage gates. The PgM realizes the gaps between gates are too long, with no early-warning checkpoints. What should the PgM do NEXT?
某項目集 roadmap 顯示三個計畫 stage gate。PgM 意識到 gate 間隔太長且無早期預警 checkpoint。下一步該做什麼?
A. 提案在 stage gates 之間增加 informal checkpoint review,對照 charter 確認戰略對齊監測頻率,將 roadmap 與 governance plan 更新送 governance board 核准
B. 維持原 roadmap 不動
C. 取消所有 stage gates 以加快進度
D. 把 stage gate 全改成季度

2️⃣ 考點:Roadmap(時序工具)+ Stage gate(正式 go/no-go 決策點)+ Charter(戰略對齊監測頻率)+ Governance(roadmap 變更需 board 核准)。

3️⃣ 逐項排除

• A ✅:綜合三主題 - 增加 informal checkpoint(非取消正式 gate)+ 對照 charter 確認戰略監測 + 更新 roadmap 與 governance plan 送 board 核准,正面整合解法。
• B:不動 = 不解決根因。
• C:取消 stage gate = 失去 governance 控管,違反治理原則。
• D:全改季度過度,且未必符合各階段風險特性。

4️⃣ 最佳選項:A
判斷關鍵:Stage gate 是正式決策,checkpoint 是非正式預警,兩者互補不取代;roadmap 變更要走 governance。

5️⃣ 實務記憶:口訣「Stage gate 不可少、checkpoint 可加碼、roadmap 變更走 board」。Informal checkpoint review 是「risk-aware governance」的補充工具。

1️⃣ 題幹:Component A's change request impacts Components B and C's scope. Component A's CCB has already approved it. The PgM is notified after the fact. What should the PgM do NEXT?
組件 A 的變更請求影響 B、C 範圍。組件 A 的 CCB 已通過。PgM 事後才被通知。下一步該做什麼?
A. 接受既成事實
B. 撤銷組件 A 的 CCB 決議
C. 把問題推給組件 PM 們自己解決
D. 將變更請求重新送 program CCB(因跨組件影響),評估對 B、C 的衝擊,必要時送 governance board(若涉預算/戰略 tolerance),並重申「跨組件變更必先 program CCB」流程

2️⃣ 考點:跨組件變更(component CCB 無權單獨核准跨組件影響)+ 雙層 CCB(component → program)+ Escalation(若涉及 tolerance 再升 governance)。

3️⃣ 逐項排除

• A:接受既成 = 縱容流程違規,後續更難管控。
• B:撤銷組件 CCB 決議過於對抗,且部分決定可能合理,要評估後再說。
• C:推給組件 PM = PgM 失職,跨組件議題必由 PgM 處理。
• D ✅:四步驟綜合 - 送 program CCB(雙層的第二層)+ 評估對 B、C 衝擊 + 必要時升 governance(escalation 漸進)+ 重申流程(預防再發生),完美呈現雙層 CCB 與 escalation 邏輯。

4️⃣ 最佳選項:D
判斷關鍵:跨組件變更 = 必走 program CCB(component CCB 無權單獨核准);若超出 tolerance 才升 governance。

5️⃣ 實務記憶:口訣「Component CCB 管組件內、Program CCB 管跨組件、Governance Board 管 tolerance 外」。雙層 CCB 的「雙層」就是這 component → program 兩層,governance 是第三層只在超出門檻時觸發。

1️⃣ 題幹:A change request affects four out of six components, increases program cost by 8% (within tolerance of 10%) but extends timeline by 3 months (exceeds tolerance of 2 months). What should the PgM do NEXT?
變更請求影響六個組件中的四個,項目集成本增加 8%(在 10% 容差內)但時程延長 3 個月(超出 2 個月容差)。下一步該做什麼?
A. 因成本在容差內就核准,忽略時程超出
B. 由 program CCB 評估技術影響後,因時程超出 tolerance,升報 governance board 做 go/no-go 決策,並更新 risk register 與 benefits 影響
C. 拒絕變更維持原計畫
D. 由組件 PM 自行協調不需上 CCB

2️⃣ 考點:雙層 CCB(program CCB 先評估)+ Escalation(超出 tolerance → governance)+ 變更影響(時程 + 成本 + 風險 + benefits 多維)。

3️⃣ 逐項排除

• A:忽略時程超出 = 違反 tolerance 規則,且時程影響 benefits realization。
• B ✅:綜合反射 - program CCB 先評估技術 + 因時程超出 tolerance 升 governance + 更新風險與 benefits 影響,標準雙層 CCB + escalation 流程。
• C:拒絕變更未做評估 = 主觀,且 program 鼓勵變更不拒絕。
• D:跨組件變更必須上 program CCB,不可由 PM 自行處理。

4️⃣ 最佳選項:B
判斷關鍵:任一維度(成本/時程/範圍/品質)超出 tolerance 即觸發 governance escalation,不只看單一維度。

5️⃣ 實務記憶:口訣「Tolerance 是 OR 不是 AND,任一超出就升 governance」。Program CCB 先做技術評估,governance 做戰略決策。

1️⃣ 題幹:Three components simultaneously raise change requests, each individually within tolerance, but combined impact would exceed program budget tolerance. What should the PgM do NEXT?
三個組件同時提變更請求,個別都在容差內,但合併影響將超出項目集預算容差。下一步該做什麼?
A. 分別核准三個變更,反正各自都在容差內
B. 拒絕全部變更
C. 在 program CCB 做合併影響評估(aggregate impact analysis),因合併超出 tolerance 升 governance board,協調是否分階段或調整其他組件預算
D. 把三個變更全部推給組件 PM 自行協調

2️⃣ 考點:跨組件變更(三個並行變更需合併評估)+ 雙層 CCB(program CCB 做 aggregate analysis)+ Escalation(合併超出 tolerance 必升 governance)。

3️⃣ 逐項排除

• A:個別在容差內但合併超出 = 經典陷阱,分別核准 = 違反 program 整合視角。
• B:全拒絕沒評估 = 違反 program 鼓勵變更原則。
• C ✅:綜合三主題 - program CCB 做 aggregate impact analysis(整合視角)+ 因合併超出 tolerance 升 governance + 協調分階段或重分配預算(尋找替代方案),完美呈現 PgM 的整合與升報藝術。
• D:推給組件 PM = 失去整合視角,每個 PM 只看自己組件,沒人看合併影響。

4️⃣ 最佳選項:C
判斷關鍵:「個別在容差內、合併超出」是 program 整合視角的經典陷阱,必須在 program CCB 做 aggregate impact analysis,這是 program 層獨有的視角。

5️⃣ 實務記憶:口訣「個別 OK ≠ 合併 OK,Program CCB 看 aggregate」。這是 Program Manager 與單一 PM 視角最大的差異 - 看「合併效應」,不是單獨判斷。

---