PMP 的題目大多是情境題:題幹給一段狀況,最後問一句「專案經理應該怎麼做?」。最常見的問法沒有 BEST、FIRST 這類限定詞;也有題目會加上「最先」「最佳」,判斷方式相同,只是要多比一步先後或好壞。四個選項多半都「有幫助」,所以很難選。
PMI 要的不是任何有幫助的事,而是稱職的專案經理此刻該採取的那一步:對準題幹點出的真正問題、在自己的職權內、照正規做法處理。那一步常常是引導團隊,而不是自己跳下去做。下面的例子用的是我們自己寫的練習題。
先刪這四種
- 放著不管,或「再觀察看看」。團隊有能力自己解決、所以先讓團隊處理,或評估後決定接受風險,都不算放著不管。
- 一開始就往上推:上報發起人、丟給人資、請主管裁示。
- 專案經理自己拍板:沒評估就改計畫或基準、替團隊做決定、私下答應客戶。
- 還沒弄清原因就動手:換人、要求團隊加班。
剩下的,看題幹卡在哪裡
| 題幹的狀況 | PMI 期待的做法 |
|---|---|
| 人的問題(衝突、表現) | 私下直接談、了解原因,或引導團隊一起訂規則 |
| 已經發生、事先沒料到的問題 | 帶團隊找原因、處理,記進議題紀錄 |
| 新發現、還沒發生的風險 | 記進風險登錄表,分析後規劃回應、指定負責人 |
| 早就登錄、有回應計畫的風險發生了 | 照原先規劃的回應去做。這時它已經從風險變成議題:記進議題紀錄,並更新風險登錄表 |
| 要改範疇 | 先評估影響,再走變更流程。敏捷專案則放進待辦清單,由產品負責人排序 |
| 供應商出狀況 | 先看合約怎麼寫,再協商 |
最難刪的:方向對,但太早或跳步
刪完上面四種,常常還剩兩個。輸的那個多半方向是對的,只是做得太早,或越過了該有的步驟。例如還沒評估影響就送變更控制委員會、還沒了解狀況就改計畫書、事情還在團隊能處理的範圍就直接找發起人。
例外:什麼時候上報才是對的
團隊層級已經試過仍然解決不了,或事情本來就超出專案經理的職權(例如要調度其他部門的資源,或要發起人才能做的決定),這時帶著影響說明和已經嘗試過的紀錄上報,才是正解。要改基準則不是上報了事,而是提出變更申請,走變更控制流程。
例團隊的測試環境要靠外部部門開通權限。Scrum 主管(Scrum Master)已經依正式管道協調三次,對方仍然以人力不足推遲,Sprint 目標快要受影響。這時繼續每天催沒有用;該做的是整理障礙的影響和協調紀錄,上報給有權調度跨部門資源的管理層。
四個例子
衝突兩名開發人員為技術方案激烈爭執,Scrum 主管最先怎麼做?答案是引導兩人在團隊層級直接對話。把兩人分開只是迴避,方案終究要選;直接裁定是替團隊做決定;上報發起人太早。
範疇預測式專案中,工程師想順手升級一個不在工作說明書範圍內的程式庫。答案是肯定他的專業判斷,請他提出變更申請,讓影響經過正式評估後再決定。直接同意是跳過評估;一口回絕會澆熄成員提出改善的意願。
進度Sprint 燃盡圖連續五天沒有下降。答案是先和團隊找原因:工作被阻塞、任務切得太大,還是做完沒更新看板。宣布加班、向發起人預告延期,都是還沒診斷就下結論。
利害關係人系統上線前兩週,法務部門才知道有這個專案,並提出多項合規疑慮。最大的缺失是利害關係人辨識不完整。不是法務太慢,也不是上線日期訂得太早:就算當初把日期訂得更晚,法務沒被找進來,合規需求一樣不會被納入。
同樣的狀況,預測式和敏捷的答案不一樣
- 同樣是時程落後:預測式專案看計畫和變更控制;敏捷專案回到團隊和待辦清單。
- 同樣是新需求:預測式專案走變更申請;敏捷專案交給產品負責人排進待辦清單。
- 已經發生的是議題,還沒發生的是風險,兩者用的工具不同。已登錄的風險一旦發生,就從風險變成議題。
新版考綱有六成題目是敏捷或混合式,而且題目不一定會明講是哪一種。沒講的時候,先從題幹找線索,再決定用哪一套做法。考綱的細節整理在〈PMP 2026 新考綱重點〉。