| 日期 | 推薦答案 (Q1-Q10) |
|---|---|
| 5/11 | BDACCCACAC |
| 5/12 | CADDCBACBA |
| 5/13 | DAABDACBCA |
| 5/14 | CACADADDAC |
| 5/15 | DBBABBADAD |
1️⃣ 題幹:基礎設施項目集 20 個項目,前 10 個因變更單過多 + 關鍵風險 + 資源不足導致延誤,如何確保剩餘 10 個組件項目不步上後塵?
A. 重設剩餘組件基線 B. 制定變更管理策略 C. 更新項目集管理計畫 D. 安排每週與 PM 會議
2️⃣ 考點:Program Change Management(項目集變更管理)。「multiple change orders」直接點出變更控制失靈,Program Manager 應建立統一的變更管理機制,而非治標的重設基線或開會。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:題幹核心痛點 = 「change orders 太多」+ 「key risks」,根因是變更管控缺位,Program Manager 應建立變更治理策略,而非個別救火。
5️⃣ 實務記憶:口訣「先治流程、再救個案」。看到「multiple change orders」第一反應 = 變更管理策略,不是重設基線(那是補救最後手段)。
1️⃣ 題幹:小型公用事業關閉客戶獎勵項目集並移交營運,擔心對收益實現的影響。PgM 該做什麼確保成功移交?
A. 各 PM 整合所有項目集文件歸檔 B. 取得 PM 聯絡資訊並讓他們回歸職能經理 C. 請商業分析師收集所有項目資訊製作報告 D. 確保所有項目集文件含經驗教訓存入知識庫
2️⃣ 考點:Program Closure 階段,知識資產(含 lessons learned)的封存。Transition / Close 兩個 PG 都會處理文件歸檔,但組織層級的「knowledge repository」是 Program Manager 自己的責任,不能下放給 PM。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:「ensure / 確保」+ 「knowledge repository」+ 「lessons learned」是 Close Program 三件套,Program Manager 親自負責。
5️⃣ 實務記憶:口訣「收尾三寶:歸檔、教訓、知識庫」。Program 結束 ≠ 收益結束,文件必須留給後續 Sustainment 階段使用。
1️⃣ 題幹:組件 PM 們對 status report template 各有偏好,PgM 該如何決定使用哪個?
A. 與 PMO 一起審查決定 B. 與 PM 們互相協調達成共識 C. 與治理委員會選擇 D. 允許 PM 各用自己偏好的模板
2️⃣ 考點:PMO 的職責 = 標準化(templates、processes、tools)。Status report template 是組織級流程資產,屬於 PMO 治理範疇,而非 governance board(管 go/no-go decisions)。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:「template / 模板/流程標準」= PMO 業務範圍,直接找 PMO 而非治理委員會或讓 PM 自決。
5️⃣ 實務記憶:口訣「PMO 管標準、Board 管決策」。看到 template/process/tool → PMO;看到 go/no-go/funding → Governance Board。
1️⃣ 題幹:準備向客戶提交項目集主進度計畫,討論 WBS 時,主排程員指出 master program schedule 應包含什麼?
A. 項目集收益 + 所有組件活動 B. 組件資源與責任指標 C. 項目集層級活動 + 整合的組件項目 D. 項目集活動、組件活動 + 所有其他工作
2️⃣ 考點:Program Master Schedule(項目集主進度計畫)的內容範圍。依 Standard 4th,master schedule 包含 program-level activities + component milestones/integrated views,而非把所有 component 活動明細塞進來(那是 component schedule 的事)。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:Master schedule 的「Master」= 整合視角,只收 program-level + 各 component 整合點,不重複 component 內部明細。
5️⃣ 實務記憶:口訣「主排程裝 milestone,不裝 task」。Master = 整合,Component = 明細,各司其職。
1️⃣ 題幹:新任 PgM,組織已給定收益清單,並要求 PgM 確定何時可實現增量收益,首先該做什麼?
A. 制定收益維持計畫 B. 制定項目集管理計畫 C. 制定項目集路線圖 D. 制定組件項目時間表
2️⃣ 考點:Program Roadmap 的時序定位。新項目集起步,需要先用 Roadmap 把高層級時程、依賴、決策點與「incremental benefits delivery 時間點」視覺化,作為後續 program management plan 的基礎。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:題幹要「確定何時實現增量收益」= 時序+benefit 的高層級視圖 = Program Roadmap。
5️⃣ 實務記憶:口訣「Roadmap 畫時間軸 + benefit 里程碑」。新 program 第一張地圖就是 Roadmap,管理計畫之前畫出來。
1️⃣ 題幹:IT PgM 擔心因業務團隊未交付而錯失增量收益,業務團隊不向他匯報,只有 2 位適任資源。下一步該做什麼?
A. 開會討論把 2 位業務資源轉到 IT 團隊 + 更新風險登記冊 B. 升報指導委員會 + 雇新人 + 更新風險登記冊 C. 釐清業務團隊角色職責 + 評估對收益進度的影響 + 指派 IT PM 與業務團隊釐清依賴與資源 D. 修改里程碑加大應急 + 評估實施日期影響 + 更新收益管理計畫
2️⃣ 考點:跨團隊依賴與利害關係人協調。PgM 第一步不是升報、不是雇人、不是改里程碑,而是先 澄清角色 + 評估影響 + 直接溝通協調(Stakeholder Engagement + Program Integration)。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:「next」+ 跨團隊依賴 = 先澄清角色責任 + 評估影響 + 協調溝通,不是直接動組織結構或升報。
5️⃣ 實務記憶:口訣「先澄清、再評估、再協調,最後才升報」。PgM 不是一遇問題就找 Board,先用自己的協調職權處理。
1️⃣ 題幹:幫 XYZ 公司改善 transitioning 程序以滿足 close-out 需求,以下哪個程序不屬於 close-out 階段應該移除?
A. 管理從「As-Is」到「To-Be」狀態的移交 B. 與相關方及發起人審查收益狀況 C. 管理向營運的必要移交 D. 將經驗教訓記錄於組織資料庫
2️⃣ 考點:Close Program 階段 vs Program Transition 階段的區別。Close 階段聚焦 行政性收尾 + 知識歸檔 + benefit transition 確認;而「As-Is → To-Be」的狀態轉換管理屬於 執行/交付期間的組織變革管理,不是 close-out 的活動。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:題目問「哪個不該留在 close-out」= 找出非收尾活動。As-Is → To-Be 是 delivery 階段的變革管理,close 時應已完成。
5️⃣ 實務記憶:口訣「Close 階段:審收益、移營運、存教訓」。狀態轉換(As-Is → To-Be)發生在 delivery,不是 close。
1️⃣ 題幹:新 PgM 加入已執行近一年的多年項目集,訪談時利害關係人說「不懂這 program 怎麼幫到組織」。下次會議應展示什麼?
A. 項目集章程 B. 項目集範圍評估結果 C. 商業與項目集路線圖 D. 預期收益管理計畫
2️⃣ 考點:利害關係人對 program 的「戰略價值」不理解,需要展示 business strategy → program → benefits 的對齊視圖。Business and program roadmap 同時呈現戰略連結與時序里程碑,最能回答「怎麼幫到組織」。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:利害關係人問「program 怎麼幫組織」= 戰略對齊問題 = roadmap(business + program 雙層)。
5️⃣ 實務記憶:口訣「講戰略用 Roadmap、講授權用 Charter、講指標用 BMP」。看到「不懂如何幫到組織」第一反應就是 Roadmap。
1️⃣ 題幹:program 執行遇問題,利害關係人擔憂,PgM 感受壓力,當收到低於預期結果時用什麼工具觸發計畫好的回應?
A. 關鍵績效指標(KPI) B. 收益管理計畫 C. 溝通管理計畫 D. 石川圖
2️⃣ 考點:Performance Monitoring 中的 threshold-based response。KPI 是設定門檻、量測偏離、觸發預先規劃回應(corrective action / escalation)的核心工具,屬於 Program Performance Monitoring & Controlling 域。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:「trigger planned response」+ 「lower than expected results」= KPI 的 threshold/tolerance 機制。
5️⃣ 實務記憶:口訣「KPI 是儀表板,過紅線就拉警報」。預先設好門檻 → 偏離 → 觸發回應,這是 KPI 而非 BMP 或溝通計畫。
1️⃣ 題幹:製藥公司 PgM 規劃新藥開發,預計產出 3 種藥物變體,PgM 闡明 program scope boundaries,哪份交付物包含這些事項?
A. 項目集範圍管理計畫 B. 項目集治理計畫 C. 項目集範圍說明書 D. 項目集 WBS
2️⃣ 考點:Program Scope Statement vs Scope Management Plan。Scope Statement 是 具體描述範圍邊界、可交付成果、排除項 的「文件本身」;Scope Management Plan 是「怎麼管範圍的流程描述」。題幹「articulates scope boundaries」= 描述具體邊界 = Scope Statement。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:「scope boundaries / 範圍邊界」是 Scope Statement 的核心內容;Management Plan 講「怎麼管」、WBS 講「怎麼拆」。
5️⃣ 實務記憶:口訣「Statement 寫邊界、Plan 寫流程、WBS 畫分解」。看到「articulate boundaries」直接選 Scope Statement。
---
1️⃣ 題幹:PgM 解決 CRM 重複資料問題,從知識庫查歷史趨勢、識別矯正措施並落實流程變更。這份「過程中獲得的知識」該怎麼處理?
A. 寫進每週項目集報告 B. 更新沟通管理計畫 C. 更新經驗教訓資料庫 D. 把矯正措施告知發起人
2️⃣ 考點:Knowledge Management — 個人從活動產生的學習,要回流到組織級的 lessons learned repository,使下一個 program 可重複利用。考的是「組織學習資產」vs「事件性溝通」的區別。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:題幹同時出現「access knowledge repository」與「knowledge gained」,標準的閉環題 — 拿了就要還回去,更新 lessons learned database。
5️⃣ 實務記憶:「拿過知識庫的人有責任回填」=「借書還書」原則。LL repository 是組織級,週報只是當期溝通,別搞混。
1️⃣ 題幹:PgM 在「Program Definition(準備)」階段加入團隊,要拿到發起人正式批准、進入「Benefits Delivery」階段。下一步該做什麼?
A. 根據組織戰略計畫制定項目集管理計畫 B. 撰寫項目集章程(含使命聲明與相關方參與計畫) C. 定義含初步估算的高層級項目集路線圖 D. 在收益管理計畫中識別並記錄預期收益
2️⃣ 考點:Program Definition Phase → Benefits Delivery Phase 的閘門關卡 — Program Management Plan 才是發起人批准進入 Delivery 的核心輸出物。Charter、Roadmap、Benefits Plan 都是更早或子層級產出。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:題目問「formal sponsor approval to begin benefits delivery」=Definition → Delivery 閘門,唯一的整合性批准對象就是 Program Management Plan。
5️⃣ 實務記憶:Charter 授權「program 存在」、Plan 授權「delivery 啟動」、Roadmap/Benefits 是其中一部分。記閘門口訣:「Charter 開門、Plan 通關、Roadmap/Benefits 隨行」。
1️⃣ 題幹:原 PgM 因表現不佳被撤,新 PgM 接手,最後一個 component 一週內 go-live。在 program closure 前,新 PgM 必須做什麼?
A. 審查收益管理計畫,確認第一個啟動的 component 是否符合期望 B. 請治理委員會在最後 component 啟動後立即開始關閉 C. 開始收集 lessons learned 並提前準備減輕策略 D. 與發起人合作確認收益維持(benefit sustainment)責任歸屬,並從 BMP 找衡量指標
2️⃣ 考點:Program Closure 前的 Transition Planning — 收益常在 program 結束後才完全實現,必須先指派「benefits sustainment owner」(營運單位、PMO、產品主)接手,並備妥成功衡量指標。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:看到「before program closure」+「last component go-live」,答案幾乎一定指向 Transition + Benefits Sustainment。
5️⃣ 實務記憶:「Closure 之前先 Transition,Transition 必問三件事 — 誰接手?用什麼 KPI?資源/合約怎麼移交?」答案永遠不會是「直接關掉」。
1️⃣ 題幹:相關方常臨時(ad-hoc)發出請求,造成報告重複與沟通落差,影響 program 績效。要解決這狀況,必須嚴格審查並變更的是?
A. 收益管理績效域 B. 相關方沟通需求 C. 項目集沟通報告 D. 項目集沟通管理計畫
2️⃣ 考點:沟通問題的「根因文件」是 Communications Management Plan — 它定義誰需要什麼資訊、頻率、格式、回應流程。需求變動時,需審查並更新計畫本體,不是只調個別報告或單一需求。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:題幹的「critical review and change」指向「制度層級的計畫」,只有 Communications Management Plan 同時涵蓋「需求 → 規則 → 報告」三層。
5️⃣ 實務記憶:「報告亂、計畫先改;計畫不改,報告永遠亂。」Plan > Report > List。
1️⃣ 題幹:關鍵相關方的需求與組織戰略目標相矛盾,PgM 與其溝通但無法達成妥協。首先該怎麼做?
A. 與 PMO 會面更新 BMP B. 與組織戰略規劃委員會會面以澄清 C. 與項目集發起人會面解決該議題 D. 與客戶會面確認需求是否有效
2️⃣ 考點:Stakeholder Engagement + Governance — 戰略對齊衝突無法在 PgM 層級解決時,第一升級對象是 Program Sponsor(出資代表戰略意志);Sponsor 可裁示或再向 Steering Committee/戰略委員會升級。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:題幹明說「戰略矛盾 + 無法妥協」,首要動作永遠是升級給 Sponsor,而非自行更新計畫或越級。
5️⃣ 實務記憶:戰略衝突三線判斷 — 「PgM 處理執行、Sponsor 處理戰略、Governance Board 處理治理」。先找 Sponsor 是 PgMP 的標準首動作。
1️⃣ 題幹:Delivery 階段,相關方抱怨沒收到某 component 的關鍵沟通。PgM 該怎麼處理?
A. 審查並更新詳細相關方清單 B. 審查並更新相關方參與計畫 C. 執行該 component 的沟通管理計畫 D. 更新風險登記冊
2️⃣ 考點:Stakeholder Engagement 績效域 — 「沟通漏接」反映的是 engagement plan 中該相關方的資訊需求、頻率、管道未正確定義/執行,要從 program-level engagement plan 著手而非 component 層或單純清單。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:相關方抱怨「沒收到」=engagement plan 未涵蓋他需要的資訊,從 program 層更新最高效。
5️⃣ 實務記憶:Engagement Plan = 誰要什麼資訊;Communications Plan = 怎麼送出去;Stakeholder Register = 名單。題目問「漏接」優先動到 Engagement Plan,因為它管「需求」。
1️⃣ 題幹:自然災害導致停工兩天,Program 有重要里程碑且需在期付 100 萬美元。停工未預料,PgM 首先該做什麼?
A. 實施適當的風險應對計畫並通知相關方 B. 動用應急儲備聘承包商加速以保住里程碑 C. 評估影響、重評風險、把選項提交治理委員會 D. 與 Sponsor 合作確認選項並協商里程碑新日期
2️⃣ 考點:Risk Management — Delivery 階段已識別/已規劃的風險(自然災害屬「外部、低頻、高衝擊」常見已在 risk register 中)發生時,第一動作是執行對應的 risk response,並同步通知相關方;之後才會評估剩餘衝擊、需要時升級到治理委員會。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:「first」+「災害已發生」=先執行 risk response plan,並用沟通減少 stakeholder 不確定感,事後再評估與升級。
5️⃣ 實務記憶:風險發生時 SOP — 「響應 → 沟通 → 評估 → 升級 → 學習」。Choose A 是因為它一次完成「響應+沟通」。
1️⃣ 題幹:Program 已完成、預期收益已實現。在執行 transition 與 closure 前,PgM 該做什麼?
A. 建立最終 program report B. 歸檔文件與經驗教訓 C. 取得項目集治理委員會批准以啟動 program closure 活動 D. 執行行政與 PMIS 關閉活動
2️⃣ 考點:Program Closure 的「正式啟動」需 Governance Board / Program Steering Committee 的核可 — 沒有批准,所有 closure 動作(報告、歸檔、PMIS、解散團隊)都不應啟動;這是 SfPM 4th 在 Program Life Cycle Management 的明確要求。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:題幹「before executing the transition and closing」=尚未啟動,必須先「拿批准」,治理批准 = Governance Board。
5️⃣ 實務記憶:Closure 啟動 SOP — 「先批准、再執行、後歸檔」;Sponsor 出資、Governance Board 拍板、PgM 執行,題目問 close 啟動就找 Governance Board。
1️⃣ 題幹:組織戰略改變,影響某 component(已完成 90%),導致其與 program 目標及新戰略不對齊。PgM 下一步該做什麼?
A. 立即向 Sponsor 提交 component closure request 以重分配資源 B. 評估關閉對其他 component 的影響,把建議提交治理委員會 C. 建議 component PM 完成工作,為組織交付收益 D. 更新 BMP 反映變更對 program 與收益的影響
2️⃣ 考點:Strategic Alignment + Governance — 當戰略改變、component 不再對齊,PgM 不能單方面決定關閉;必須先評估關閉對其他 component、benefits、依賴關係的衝擊,再以「建議方案」交付 Program Governance Board 裁決。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:看到「戰略改變 + 不對齊 + 下一步」永遠是 assess impact → recommend → governance board,這是 PgMP 戰略題的固定三段式。
5️⃣ 實務記憶:戰略變動三步走 — 「先評估、再建議、後治理」。別自己當 Sponsor、別當 PM 硬做完。Governance Board 是戰略級變動的最後裁判。
1️⃣ 題幹:有一個新的 program component 帶來提升 program 成果的「機會」。PgM 用什麼來記錄並監督這個機會?
A. 項目集風險登記冊 B. 項目集範圍管理計畫 C. 項目集風險管理計畫 D. 組件項目風險登記冊
2️⃣ 考點:Risk Management — PMI 定義「機會 = 正面風險(positive risk / opportunity)」,記錄與監督的工具是 Risk Register;且因屬「program 層級成果」,應在 program-level register 而非 component register。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:Opportunity = 正向風險,「document + monitor」永遠對應 Risk Register;「program outcome」=用 program-level 而非 component-level。
5️⃣ 實務記憶:Risk Plan 定方法、Risk Register 記事件、機會也是風險的一種。題目問「記錄 + 監督」=Register;問「方法 + 門檻」=Plan。
---
1️⃣ 題幹:Sponsor 從董事會回來,新識別出一項會影響 program schedule 與 benefits 實現的重大風險,PgM 接下來該做什麼?
A. 更新 benefits management plan 與風險登記冊 B. 直接執行該風險的減輕計畫 C. 調整 program 範圍以避開風險 D. 記錄該風險並制定減輕計畫
2️⃣ 考點:風險管理流程順序 — 新識別風險的標準下一步是「記錄 + 分析 + 規劃回應」,而非跳過分析就更新基線或執行回應。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:新風險浮現,PgM 的標準下一步是「先入庫 + 規劃應對」,後續才會 update plan(A)或 execute(B)。
5️⃣ 實務記憶:風險「四步走」— 識別 → 記錄 → 分析+規劃 → 執行;先 plan 後 implement,先 document 後 update baseline。
1️⃣ 題幹:多年期 program 中,某組件 project 移交客戶驗收階段時又發現潛在風險,PgM team 該如何處理?
A. 納入風險登記冊並徹底分析 B. 還沒納入 risk management plan 前就先減輕 C. 寫進 transition plan 並當作潛在 issue D. 寫進 issue log 並立刻通知指導委員會
2️⃣ 考點:Risk vs Issue 區別 + 風險識別後的標準動作。Potential risk 還沒發生屬於風險,不是 issue;且 program 尚未結束前 risk register 持續維護。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:potential risk = 走風險流程的入口,登記 + 分析是首要動作;不要混淆 risk 與 issue。
5️⃣ 實務記憶:「Risk = 未發生、Issue = 已發生」;不管 program 進到哪一階段,新風險一律先進 register 再分析。
1️⃣ 題幹:CEO 下令把新客戶 onboarding 自動化取代紙本,Sponsor 與 PgM 已正式接受 program charter,下一步該做什麼?
A. 組團隊制定 program management plan B. 估算範圍、資源、成本 C. 識別 program 組件並制定資源管理計畫 D. 審查並更新 BMP 連到 program outcomes
2️⃣ 考點:Program 生命週期順序 — Charter 通過後進入 Program Definition Phase,核心是 Program Planning,首要產出是 Program Management Plan(PgMP 是「總綱」,其下才有各子計畫)。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:Charter approved 之後的標準下一步 = 制定 Program Management Plan(整合母計畫)。
5️⃣ 實務記憶:口訣「BC-PMP-Components」— Business Case → Charter → Program Management Plan → 各組件規劃。Charter 之後必接 PgMP。
1️⃣ 題幹:矩陣型組織下,PgM Robert 的資源橫跨 program 內外多個 project,他要跟 PMs 一起做什麼計畫來確保資源排程與溝通?
A. 資源管理計畫 B. Program management calendar(項目集管理日曆) C. 進度管理計畫 D. 資源日曆
2️⃣ 考點:Program Management Calendar 在跨 project 共享資源時的角色 — 它整合所有組件的資源使用時間窗,讓 PMs 互相看見彼此的資源檔期。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:跨組件、跨 PM 的資源時間視覺化 = Program Management Calendar。
5️⃣ 實務記憶:Plan 講「規則」,Calendar 講「時間軸」;PgM 要跨 PM 對齊「何時用」就找 Program Management Calendar。
1️⃣ 題幹:五年戰略週期第二年初的 checkpoint,去年新政府法規影響戰略,PgM 該如何回應?
A. 更新 PgMP/BMP/RMP,改優先級與相依性 B. 與利害關係人開會修 roadmap 以符合法規與戰略對齊 C. 取得利害關係人核准停掉或延後不合規 program,並改 roadmap D. 審查資源容量能力、優先級、相依性,並提 change request 修 roadmap 以確保戰略對齊
2️⃣ 考點:戰略變動下 program roadmap 變更的完整路徑 — 必須先評估資源/優先級/相依性,再透過 formal change control 提出 CR,而不是直接改計畫。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:戰略變化導致 roadmap 變動,必須「評估 + 走 CR」,不能跳過治理直接改。
5️⃣ 實務記憶:「Strategy 變 → 先 Assess(資源/優先/相依) → 再 CR → 後改 Roadmap」;Roadmap 是 controlled artifact,動它就要 CR。
1️⃣ 題幹:PgM 與 sponsor/利害關係人/指導委員會合作制定 program 的 benefits sustainment 與 transition plan,要怎麼建?
A. 識別關鍵衡量指標,以便 transition 後比對 BMP 預期 vs 實際績效 B. 把 sustainment plan 創建分配給負責監控維持期的組織 C. 訪談利害關係人並修訂 BMP D. 更新 BMP 並把副本給負責測量維持期的組織
2️⃣ 考點:Benefits Sustainment Plan 的核心 — 必須定義「衡量指標」,讓收益在 transition 後仍可被量測、比較預期與實際,才能 sustain。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:Sustainment 看「衡量」,沒有 key measures 就無法持續比對與維持收益。
5️⃣ 實務記憶:「Sustain = Measure」;benefits 在 close 之後還要靠關鍵指標長期追蹤,所以建 plan 第一件事是定 measures。
1️⃣ 題幹:醫療管理系統 program,5 個月後 PgM 找到整合線上醫療方案的機會,sponsor 已批准 scope 變更。PgM 要確保這機會的結果與下列何者「同步運作」?
A. 關鍵成功因素 B. KPI C. Benefits management plan D. 利害關係人參與計畫
2️⃣ 考點:Program 變更的根本錨點 — 任何新機會、新範圍變更必須回扣 BMP,確保仍對齊 program 預期收益,否則就是無收益的範圍增生。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:Program 一切以 benefits 為中心,新機會 → 對齊 BMP。
5️⃣ 實務記憶:「Program = Benefits」,任何 scope change/opportunity 都要回頭問 BMP「有沒有把我帶向預期收益」。
1️⃣ 題幹:JNH program 中 PM Tom 已完成 project 準備正式 close,你身為 PgM 在 Tom 的 project closure 中扮演什麼角色?
A. 必須確保 project sponsor 關閉 project B. 必須確保 program 中的 projects 已在 project 層級關閉 C. 必須在 operations 關閉 project 之前先關閉 D. 必須確保 PgM team 替 PM 關閉 project
2️⃣ 考點:Program Manager 對組件 closure 的職責邊界 — PgM 不取代 PM closure,但 PgM 需「確保」所有組件在 project 層級依規程關閉,並整合到 program 層級 transition/closure。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:PgM 的角色是「ensure / oversight」,不取代 PM 操作。
5️⃣ 實務記憶:「PM 做、PgM 確保」;PgM 不下海 close project,只確保各 component 依規程關閉並交接。
1️⃣ 題幹:跨國軟體部署 program 在規劃階段,contracts manager 告知主要分包商合約的激勵條款可能與 program 目標衝突,PgM 首先該做什麼?
A. 審查合約並建立預算意外開支 B. 起草變更請求供 steering committee 批准 C. 請 PMO 進行風險評估 D. 審查 program charter 並相應更新 program 目標
2️⃣ 考點:利害關係人/採購衝突的首要動作 — 「first」題,標準節奏是先評估(風險/影響)再決定怎麼處理,不要直接動 budget/CR/charter。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:「First」題 = 先評估、先理解,再動手;PMO 風險評估是合理的首要動作。
5️⃣ 實務記憶:「First → Assess」;遇到衝突/異常,先弄清楚範圍與嚴重度,再決定 mitigate/CR/escalate。
1️⃣ 題幹:大型 program 6 個 PM,治理委員會要求所有組件在發布到 production 前必須通過 UAT,PgM 應記錄在哪?
A. Program governance plan B. Program requirements C. Component test plan and test cases D. Program quality management plan
2️⃣ 考點:來自「Governance Board 的要求」屬於治理規則 / 階段審查決策門 — 應記錄在 governance plan,因為它定義 governance board 對 program 的監督機制、決策權與 stage gate 規則。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:「來自 governance board 的跨組件硬性要求」= governance plan;治理規則寫上層,組件依規執行。
5️⃣ 實務記憶:「Governance Board 出規 → Governance Plan 入冊」;區分 governance gate(治理層)vs 品質標準(品質層)vs 測試操作(組件層)。
---
1️⃣ 題幹:項目集挣值(EV)的計算公式是什麼?
A. 完成百分比 × 項目集剩餘百分比 B. 完成百分比 × 項目集成本估算 C. 完成百分比 × 項目集完工預算(BAC) D. 完成百分比 × 項目集人工與材料成本
2️⃣ 考點:EVM 基礎公式 — Earned Value(EV)= % complete × BAC,這是 PgMP / PMP 必背公式。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:EV 公式的「基準」永遠是 BAC(Budget at Completion),不是估算、不是直接成本。
5️⃣ 實務記憶:口訣「EV = %做完 × 應花的錢(BAC)」;再配 PV = %該做 × BAC、AC = 實付。三兄弟都以 BAC 為錨。
1️⃣ 題幹:RFP 要求供應商團隊「至少 4 名持證電工」,這項要求屬於哪個術語?
A. Screening system 篩選系統 B. Scoring model 評分模型 C. Vendor analysis requirements 供應商分析要求 D. Evaluation criteria 評估標準
2️⃣ 考點:採購中 Screening system(門檻式必要條件,Yes/No 過濾)vs Scoring model(加權打分)vs Evaluation criteria(整體評估標準集合)的區辨。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:「至少 X 個」「必須具備 Y」這種硬門檻 = Screening system;「打 80 分以上」這種比較 = Scoring model。
5️⃣ 實務記憶:Screening = 黑白題(過/不過),Scoring = 選擇題(分高低)。本題是「沒 4 個電工就直接出局」典型 screening。
1️⃣ 題幹:管理層要求編制一份文件,記錄干系人對項目集及組件項目的關切、感知威脅、具體目標。這是什麼文件?
A. Requirements document 需求文件 B. Project charter 項目章程 C. Business case 業務論證 D. Scope statement 範圍說明書
2️⃣ 考點:Program 啟動階段各項基線文件的用途差異;Business case 是回應「Why + Stakeholder concerns + Objectives」的核心立項文件。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:題目同時要「關切 + 威脅 + 目標」三項合集,只有 Business case 一次涵蓋(SWOT、戰略對齊、Benefit 都在裡面)。
5️⃣ 實務記憶:Business case = Program 的「為什麼要做」+ 風險威脅 + 收益目標,是 Program Charter 的前置輸入。
1️⃣ 題幹:檢查工作是否按範圍完成,有缺陷要在客戶檢查前整改。這是什麼過程?
A. Quality control 質量控制 B. Scope verification 範圍核實 C. Quality assurance 質量保證 D. Planning 規劃
2️⃣ 考點:QC(內部檢查/挑缺陷)vs QA(過程審計/防缺陷)vs Scope verification(客戶驗收)三者順序與差異。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:順序記:QC(內部查缺陷)→ Scope verification(客戶驗收) → 客戶簽收。「客戶看之前先整改」= QC。
5️⃣ 實務記憶:QC = 找錯誤(產品),QA = 改流程(過程),Scope verification = 客戶點頭。三者不要混。
1️⃣ 題幹:你公司與競爭對手簽訂團隊合作協議共同完成大型項目集,這是哪種風險應對?
A. Teaming 團隊合作 B. Exploiting 開拓 C. Accepting 接受 D. Sharing 分享
2️⃣ 考點:正面風險(機會)的四種應對 — Exploit(開拓/獨吃)/ Enhance(提升)/ Share(分享/找夥伴)/ Accept(接受)。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:Teaming agreement / JV / Partnership = 經典 Share strategy(正面風險);與競爭者合作就是把機會的部份利益讓出去交換成功率。
5️⃣ 實務記憶:「跟人一起做」= Share(機會) 或 Transfer(威脅);Teaming Agreement 永遠對應 Sharing。
1️⃣ 題幹:項目經理發現預算剩 $27,876,自己決定加額外功能用完預算,客戶可能會喜歡。這是?
A. Gold plating 鍍金 B. Errors and omissions 錯誤與遺漏 C. PM 的專家判斷 D. Value added change 增值變更
2️⃣ 考點:Gold plating(鍍金) — PM 未經授權自行追加超出範圍的功能,即使客戶喜歡也是壞實踐。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:沒走變更控制 + 自行加範圍 = Gold plating(壞);走了變更控制 + 增加價值 = Value added change(好)。
5️⃣ 實務記憶:鍍金 = 廚師沒問客人擅自加菜;增值變更 = 問過客人加菜還補了菜單。PMI 永遠反對 gold plating。
1️⃣ 題幹:項目集經理 Andy 要求團隊找額外可交付成果,把預算剩餘的 $25,000 用完。這是什麼術語?
A. Value-added change requests 增值變更請求 B. Zero based budgeting 零基預算 C. Integrated change control 整合變更控制 D. Gold plating 鍍金
2️⃣ 考點:同 Q6,但這次是 Program Manager 在主導鍍金行為 — PgMP 視角更嚴格,把「用完預算」當動機去加範圍即為 gold plating。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:動機是「budget 還沒花完」就加東西 = Gold plating;PgMP 視角下,剩餘預算應該交回 program reserve 或 release back,而非擴大範圍。
5️⃣ 實務記憶:「Use it or lose it」心態 = Gold plating 經典觸發點。Program Manager 對 reserve 的紀律比 PM 更高。
1️⃣ 題幹:在項目集中,用哪種分析比較積極干系人 vs 消極干系人的立場、權力、影響力?
A. Sensitivity analysis 敏感性分析 B. Stakeholder analysis 干系人分析 C. Monte Carlo simulation 蒙特卡洛模擬 D. Force field analysis 力場分析
2️⃣ 考點:Force field analysis(Kurt Lewin 力場分析)— 專門用來比較「推動力(driving forces / pros)」與「阻力(restraining forces / cons)」的工具,在 PgMP 干系人管理常用。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:「正面 vs 負面 兩邊力量對比」= Force field 的標誌性結構;Stakeholder analysis 是上位概念,Force field 是其中專門對比工具。
5️⃣ 實務記憶:Force field 像拔河 — 一邊推項目集前進,一邊拉項目集後退,PgM 任務是讓推力 > 阻力。
1️⃣ 題幹:擔心新材料使用不熟導致延誤浪費,安排培訓 + 試用採購,確保錯誤不進入項目。這是?
A. Preventive action 預防措施 B. Team development 團隊建設 C. Quality assurance 質量保證 D. Corrective action 糾正措施
2️⃣ 考點:Preventive action(預防,問題還沒發生先擋)vs Corrective action(糾正,問題已發生回到基線)vs Defect repair(修缺陷)三者區分。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:時間軸 — 還沒出事(Preventive) vs 已出事(Corrective)。題目「擔心可能會」= 還沒出事 = Preventive。
5️⃣ 實務記憶:口訣「事前防 = Preventive,事後修 = Corrective,事中查 = QA」,三者時間點不同。
1️⃣ 題幹:項目集經理駁回多項範圍變更請求,對被駁回的請求必須如何處理?
A. 溝通駁回原因 + 記在 lessons learned B. 告知干系人請求被駁回 C. 向干系人溝通狀態 + 記錄在 change register(變更登記冊) D. 告知干系人駁回原因
2️⃣ 考點:Perform Integrated Change Control 的兩個 output — ① 通知受影響干系人 ② 記錄到 Change log / Change register。PgMP 強調治理可追溯。
3️⃣ 逐項排除
4️⃣ 最佳選項:C
判斷關鍵:Change request(無論批准或駁回)兩件事缺一不可 — ① 通知 stakeholders ② 寫入 Change register 留底。Lessons learned 是另一個檔案,不是首選。
5️⃣ 實務記憶:口訣「變更兩件事:Communicate + Register」。被拒絕也要登記,治理可追溯是 PgMP 鐵律。
---
1️⃣ 題幹:NHQ 項目集最終可交付成果完成,完成證書已建立。PgM 此時還應建立什麼?
A. 生命週期成本估算 B. 經驗教訓文件 C. 運營轉移計劃 D. 項目集關閉報告
2️⃣ 考點:Program Closure 績效域。Final Report / Program Closure Report 是 Close Program 階段的最終正式產出,標誌治理層正式關閉項目集。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:完成證書(certificate of completion)= Transition 已完成 → 下一份文件是「Program Closure Report」給治理委員會。
5️⃣ 實務記憶:「證書 → 報告 → 解散」三步驟。完成證書是門票,關閉報告才是收據,沒有收據治理委員會不會放人。
1️⃣ 題幹:轉型項目集即將完成,運營經理抱怨沒被事先通知、未受訓、無法支援新服務。PgM 最該事先做什麼來預防?
A. 把運營經理列為關鍵干係人 B. 規劃階段就為受影響運營區制定移交計劃 C. 確保溝通管理計劃涵蓋運營移交 D. 在 PMO/HR 協助下起草培訓計劃
2️⃣ 考點:Program Transition / Benefits Transition。運營未受訓本質是 Transition Plan 沒有提早在 Planning 階段建立並執行,而不是溝通或培訓單點補救。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:「prevent this」的根本動作是 Planning 階段建立 Transition Plan,內含所有運營準備事項。
5️⃣ 實務記憶:Transition Plan = 早規劃、早納入、早演練。Program 結束前一刻才找運營,等於把交班當交差。
1️⃣ 題幹:CEO 要求專案 A 提前兩個月交付,A 依賴 B、C 的可交付物。PgM 首先做什麼?
A. 指示三位 PM 趕工 B. 與三位 PM 審查資源管理計劃、關鍵路徑與共享資源,評估加速可能性 C. 召集變更委員會評估壓縮的成本/效益 D. 請執行發起人與項目集委員會評估 CEO 要求
2️⃣ 考點:Program Schedule Management / 變更請求前的可行性分析。PgM 收到加速要求,首要動作是先做「事實基礎」分析,再走治理流程,不是直接拍板或越級。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:「first」= 先收集事實、量化代價,才能向治理層提出有依據的選項。
5️⃣ 實務記憶:加速題的 PgM SOP =「先量資源 → 再算代價 → 再走變更 → 再上治理」。沒有事實的治理是表演。
1️⃣ 題幹:Wan 發現團隊被分配過多工作,決定強制資源平衡為每週最多 30 小時專案工時。項目集與項目會如何變化?
A. 完成工作的時程會變長 B. 項目集與項目成本會增加 C. 失敗風險會增加 D. 項目經理士氣會下降
2️⃣ 考點:Resource Leveling 的典型副作用。資源平衡(限制每週工時)的最直接後果是專案工期延長,因為人力供給被限額。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:Resource Leveling 對時程的影響是「最直接、最可預測」的副作用。
5️⃣ 實務記憶:Leveling = 把山推平,但路會變長。把人壓在 30 小時,時程必延。
1️⃣ 題幹:組織必須加速產品上市,PgM 完成初步步驟、開了 kick-off,PM 們提交初步進度。PgM 接下來做什麼?
A. 為進度分配資源,並向 PM 回報修訂後的交付日期 B. 與 PM 一起精煉專案進度與交付物,使其對齊項目集里程碑 C. 修訂專案進度以滿足項目集進度,並與干係人溝通 D. 將專案進度整合進項目集進度,並向 PM 回報修訂後的交付日期
2️⃣ 考點:Program Schedule Management 中,PgM 不是專案排程的獨裁者。收到初步進度後,正確動作是「協同精煉」而非「單方修訂」或「直接整合」。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:Program 與 Component 之間是「對齊、精煉」關係,不是「整合、下令」關係。
5️⃣ 實務記憶:Program 排程三層次「先協同精煉 → 再對齊里程碑 → 才整合報告」。跳步等於失控。
1️⃣ 題幹:PgM 向 CIO 匯報,CIO 告知預算可能被削減並要求更快交付收益。PgM 首先做什麼?
A. 更新收益管理計劃並送干係人審查 B. 記錄對項目集的影響,然後向指導委員會提交以決定下一步 C. 進行加速進度的風險評估、更新風險登記冊、請指導委員會批准 D. 修訂項目集進度以適應收益加速交付,並提交指導委員會批准
2️⃣ 考點:預算/範圍受到高階干預時,PgM 首要動作是「量化衝擊 → 上呈治理層 → 由 Steering Committee 決議」,而不是直接接受指令並執行。
3️⃣ 逐項排除
4️⃣ 最佳選項:B
判斷關鍵:CIO 是上司也是利害關係人之一,「削預算+加速交付」這種對撞型要求必須由治理委員會仲裁。
5️⃣ 實務記憶:對撞要求的 PgM 公式 =「量化衝擊 → 上呈治理 → 等指示」。不要當夾心餅自己消化。
1️⃣ 題幹:項目集定義階段確定要外部採購補充企業資源,PgM 用什麼來決定並/或記錄採購規劃結果?
A. 自製或購買決策、備選方案分析、競爭方法、合同類型最佳組合 B. RFP、建議書評估標準、合同管理、合同類型最佳組合 C. RFP、備選方案分析、競爭方法、RFQ D. 自製或購買決策、方案評估標準、合同管理、RFQ
2️⃣ 考點:Program Procurement Planning 的產出。規劃階段的核心結果是「決策類」與「策略類」文件(make-or-buy、approach to competition、contract types),而非執行階段的 RFP/RFQ/contract management。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:題目問的是「採購規劃活動的結果」,規劃 = 決策與策略,執行 = RFP/RFQ/合約管理。
5️⃣ 實務記憶:Plan Procurement 四件套「Make-or-Buy + Alternatives + Competition Approach + Contract Mix」。看到 RFP/RFQ/contract management 就是執行階段,別選。
1️⃣ 題幹:三年全球項目集已執行 6 個月,新發起人要求所有管理計劃、流程、技術全部統一,會產生問題與成本增加。PgM 下一步做什麼?
A. 接受要求並實施變更 B. 與干係人和 PM 討論變更,給發起人最佳選項 C. 等發起人第二次問再回覆 D. 向發起人呈現變更的風險與收益
2️⃣ 考點:當 Sponsor 強推會傷害項目集的要求時,PgM 應「主動」呈現決策所需的事實(風險 vs 收益),讓 Sponsor 做出知情決策,而不是迴避、盲從或越權代決。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:新 Sponsor 不知道既有 program 的水深,PgM 的責任是把客觀事實攤在桌上,而非自己拍板。
5️⃣ 實務記憶:對 Sponsor 不能「盲從」也不能「越權」,正確姿勢是「上呈風險收益、由 Sponsor 拍板」。資訊透明 = PgM 護身符。
1️⃣ 題幹:PgM 應在何時批准組件專案的關閉?
A. 專案符合驗收標準時 B. 專案交付專案收益時 C. 項目集可交付成果完成時 D. 專案可交付成果完成時
2️⃣ 考點:Component Closure 的判定標準。組件專案關閉的依據是「達成驗收標準(Acceptance Criteria)」,這是 Program-level governance 對 Component 結案的正式判準。
3️⃣ 逐項排除
4️⃣ 最佳選項:A
判斷關鍵:Acceptance Criteria 是 Component 結案的「正式驗收章」,只有可交付完成但沒驗收,等於沒簽收。
5️⃣ 實務記憶:組件結案 = 驗收標準達成。Deliverable 完成 ≠ Accepted,沒驗收章就不能關門。
1️⃣ 題幹:創新項目集流程要被未來重複使用,Sponsor 擔心知識需高效保留。PgM 該怎麼做?
A. 在項目集管理計劃中記錄經驗教訓 B. 建立總結團隊經驗的培訓材料 C. 指導 PM 建立事件日誌記錄經驗 D. 在每個項目集階段後組織審查會議,記錄成功、問題與經驗教訓
2️⃣ 考點:Knowledge Management / Lessons Learned。PgM 視角下,知識萃取的高效做法是「定期、跨階段、跨組件」地系統化捕捉,而不是事後單點記錄。
3️⃣ 逐項排除
4️⃣ 最佳選項:D
判斷關鍵:「efficiently」+「reused for future programs」= 需要結構化、跨階段、跨組件的萃取機制,階段後 review session 是最系統化的方式。
5️⃣ 實務記憶:知識重用三件事「分段萃取、跨組件比對、階段後 review」。事後才整理 = 已經漏掉一半細節。
---