Ch14 — 新版精講 八大原則與績效域 戰略 收益 干係人 (472 min)

講師: Richard | 對應 PDF: — 影片: C:\Users\User\Desktop\PGMP\PGMP Video\2026-09-29 00-13-47.mp4 回到 [[MOC-PgMP-精講筆記]]

產製方式: 章節切 5 段交給 5 個 agent 平行逐段精煉, 共 267 個 §N (Part A: §1-59, Part B: §60-102, Part C: §103-155, Part D: §156-199, Part E: §200-267).

Part A (00:00:01 - 01:33:30) 綜述

這段接著上午的內容，把 Standard for Program Management 5th 第 1 章（引言）收尾，接著開講第 2 章「八大原則」的前三條。前半段講專案集（program）在組織裡的定位：組合（portfolio）負責篩選、排優先順序、分配資源；專案集負責以收益依賴關係為基礎做協調（coordination）、交付收益（benefits）；專案（project）在三重制約內交付可交付成果；最後價值（value）再回到戰略。講師反覆區分三組詞：協作 collaboration 指人與人、協同 synergy 指事情之間、協調 coordination 是專案集的管理特徵。接著講商業價值（有形/無形＝財務/非財務）、社會價值，以及三個核心角色：專案集經理（承擔 responsibility）、發起人（承擔 accountability，「東家與掌櫃」比喻）、專案集管理辦公室 PMO（標準化、方法論、培訓三大職能；考試時視為必選項，沒有 PMO 就由專案集經理自己承擔）。再來比較專案集和專案（不確定性、變更態度、複雜性：輸入與輸出之間缺乏明確因果關係），以及專案集和組合（關聯性、時間跨度、投資導向與管理導向）。後半段進入原則：原則是底線，指導六大績效域。收益實現原則包含「實現→過渡 transition→維持」；只要收益增加，可以容忍範圍蔓延；但增加或刪減元件必須由專案集指導委員會批准。干係人原則講分類分級，監控的是互動而不是人。最重要的判準：①專案內部問題沒有影響其他專案，就交給專案經理處理；②增加或刪減元件要送指導委員會；③PM 承擔 responsibility，Sponsor 承擔 accountability；④PMO 的三大核心職能是標準化、方法論和培訓；⑤複雜性看輸入與輸出之間的因果關係，不看規模。

§1 組合發起工作，專案集的特徵是協調 (00:00:01)

核心: 組合依優先順序保障資源，再依工作特徵發起專案集或專案；專案集的管理特徵是「協調 coordination」。

• 組合排完優先順序後，先保證高優先順序工作拿到資源，再發起工作
• 工作特徵像 program 就發起專案集，像單一專案就發起 project
• 專案集的管理單元特徵既不同於組合，也不同於專案，最貼切的詞是協調 coordination
• 協調資源、協調衝突、協調進度都只是表象，大部分管理人員都做得到

PMI 術語: Coordination ↔ 協調

§2 協調的本質：理解元件背後的收益依賴關係 (00:00:58)

核心: 真正的協調要理解元件之間的聯繫；這些聯繫建立在收益依賴關係上，而收益依賴關係是從收益目標推導出來的。

• 收益目標 → 推導出實現路徑 → 決定元件要怎麼產生
• 專案集關注交付收益；元件（專案）關注產出成果與可交付成果（deliverables/outputs）
• 價值鏈：專案經理交付成果 → 專案集經理整合、提煉成收益 → 組合經理再整合成價值 → 價值回到組織戰略
• 價值是最接近戰略的概念

PMI 術語: Benefits Dependency ↔ 收益依賴關係 / Component ↔ 元件

§3 協作 vs 協同：三層管理的「配合」 (00:02:25)

核心: 講師用「配合」同時涵蓋兩層意思：協作指人與團隊，協同指事情之間的分工搭配。

• 協作 collaboration：強調人和團隊之間的合作
• 協同 synergy：強調事情之間要各有分工、互相搭配
• 組合、專案集、專案三者要配合起來，才能交付價值

PMI 術語: Collaboration ↔ 協作 / Synergy ↔ 協同

§4 組合／專案集／專案在組織中的位置 (00:02:49)

核心: 公司戰略 → 業務戰略 → 在業務單元層面做組合管理；組合篩選出的工作交給專案集、專案或運營落實。

• 專案集管理大致位於組合之下，是組合用來落實「複雜舉措、複雜工作」的手段
• 組合篩選出來的工作，有的用專案集落實，有的用專案落實，也可以交給運營
• 這張圖資訊不完整，但層次概念很清楚，可以當參考

§5 戰略→舉措→元件→收益→價值的邏輯鏈 (00:03:39)

核心: 戰略拆成目標，目標識別出舉措（initiative），舉措經過篩選才取得具體身份（專案或專案集）。

• 專案關注輸出與成果；專案若在專案集內，這些輸出和成果還要進一步轉化成收益
• 專案集關注的是產品或成果能不能轉化成「接收組織」的收益
• 接收組織用更低成本、更高效率把收益轉成價值，價值再對應回戰略
• 同一個組織內部完成這條鏈最好理解；跨組織的就比較難理解

PMI 術語: Initiative ↔ 舉措 / Receiving Organization ↔ 接收組織

§6 三種管理各關注什麼：專案管理是基礎 (00:04:40)

核心: 專案管理關注成果和輸出的成功完成，專案集關注收益的達成，組合關注價值的實現。三者之中，專案管理是最基礎的工作。

• 離開收益、成果和輸出，價值就成了空中樓閣
• 無論是組合的價值還是專案集的收益，基礎都是先把交付做出來
• 舉措是從戰略推導出來、並經過篩選的工作

§7 三套結構化方法：PMP / PgMP / PfMP (00:05:26)

核心: 三者都是結構化方法，只是框架組成不同。

• 專案管理：五大過程組、十大知識領域、49 個過程，聚焦在把可交付成果做出來（可交付成果同樣支援戰略）
• 專案集管理（5th）：八大原則 + 六大績效域 + 一系列活動（講師說 42 或 40 個過程，數量本身沒有意義）
• 組合管理：三大過程組 + 五大績效域 + 16 個過程

⚠ 新版變化: 第 5 版把專案集管理重構成「原則 + 績效域 + 活動」，過程數量已經不是重點。

§8 三者的管理特徵 (00:06:40)

核心: 專案看範圍、進度、成本、質量的制約；專案集看收益管理與依賴關係管理（協調）；組合看篩選、排優先順序、分配資源。

• 專案：在三重制約內完成可交付成果
• 專案集：收益管理 + 依賴關係管理（也叫協調管理），產生收益交給組織
• 組合：用篩選、排序、配資源的方式工作

🎯 考點: 選項中看到「依賴關係/協調」就是 program 的特徵；看到「選擇、優先順序、資源分配」是 portfolio；看到「三重制約」是 project。

§9 角色鏈：組合經理—專案集經理—專案經理 (00:07:11)

核心: 組合經理排優先順序、配資源，選出專案集；專案集經理帶團隊交付收益，交回組合；專案集經理協調專案經理們的工作。

• 專案經理做出可交付成果，用來支撐專案集經理要交付的收益
• 專案集經理承上啟下，向上對組合，向下對專案

§10 專案集經理在專案生命週期中的參與度 (00:07:46)

核心: 專案從啟動到結束，整個生命週期都在專案集交付階段內走完。專案集經理在專案啟動、規劃時多參與，執行與監控時少參與，結束時再多參與。

• 早期不確定性最高，加上規劃是後期執行的基礎，所以要多參與，避免專案走彎路
• 執行階段把管理權大量交給專案經理
• 結束時找專案經理要結果，也就是可交付成果；專案集經理整合後把收益交給組合經理
• 只要還有一個專案沒做完，專案集就不能收尾
• 專案集經理主要透過監督、指導、協調依賴關係，與專案經理配合

🎯 考點: 專案集經理對元件的參與度呈「啟動規劃高 → 執行低 → 收尾高」的曲線。

§11 管理體系重構：活動都在專案集層面完成，不深入專案 (00:09:41)

核心: 專案集管理和專案管理最大的不同在於整個管理體系被重構了（八大原則 + 六大績效域 + 活動），這些活動全部在專案集層面完成。

• 不要深入專案內部太多
• 範圍方面：最多看到專案 WBS 的第一層或第二層，再往下是專案經理的職責
• 維護好分工介面，雙方才能配合好；過度干預專案經理，這套管理模式就會失效
• 第一線的具體活動，專案經理比專案集經理更熟悉

🎯 考點: 專案集經理的範圍管理只到元件 WBS 的高層級（L1/L2），工作包是專案經理的事。

§12 兩句話抓住專案集管理：抓收益，不抓可交付 (00:11:13)

核心: 專案集管理要觸及專案層面，但要和專案協作好（事情要協同，人要協作）；可以抓收益，不要抓可交付成果的細節。

• 可以抓可交付成果之間的關係與產出時間點，但不要抓可交付成果的生成細節（WBS 工作包）
• 潛台詞：組合、專案集、專案各司其職，管理重點不同
• 比喻：專案集經理關心「產品賣得好不好」；能不能按時做出來、滿足質量要求，是專案經理操心的事
• 單一專案內部的問題交給專案經理處理，不要給太多意見

🎯 考點: 題目說某專案出了問題，但沒有提到影響其他專案，就讓專案經理繼續想辦法；專案集經理只提要求，不替他給辦法，也不召集會議介入。

§13 商業價值：有形/無形＝財務/非財務 (00:13:03)

核心: 營利組織追求商業價值。商業價值等於有形價值加無形價值。

• 簡單區分：能用貨幣衡量的是有形，無法用貨幣衡量的是無形
• 有形價值也叫財務價值（financial），無形價值也叫非財務價值（non-financial）
• 例子看一下即可，選擇題能分辨有形和無形就夠了

PMI 術語: Business Value ↔ 商業價值 / Tangible / Intangible ↔ 有形/無形 / Financial / Non-financial ↔ 財務/非財務

§14 三種管理協同（Synergy）創造價值，各司其職 (00:14:26)

核心: 從商業價值的角度看，三種管理方式必須協同（synergy）；三者各是一整套結構化方法，不能互相套用思維框架。

• 專案集經理不要過度參與專案管理，也不要用專案管理的思維去管專案集
• 組合也不要用專案集的方式管價值，而是依戰略匹配度做選擇、分配資源
• 依賴關係對組合來說「不是重點」，不等於「不重要」，不要非黑即白

§15 標準原文：組合靠「對齊」、專案集靠「協調」、專案靠「應用知識」 (00:16:11)

核心: 三者的定義用字不同：組合讓專案、運營與戰略保持一致（alignment），以最佳化價值；專案集透過協調元件來追求戰略目標；專案把知識、技能、工具、技術應用到專案中，創造成果。

• 專案集的元件：子專案集、專案、其他專案集活動
• 專案創造成果，專案集為組織創造收益，組合為組織創造價值
• 三種工作模式配合起來，就叫協同 synergy

PMI 術語: Alignment ↔ 對齊 / Subsidiary Program ↔ 子專案集 / Other Program-related Activities ↔ 其他專案集活動

§16 創造價值的兩類手段：運營 vs 專案類 (00:17:18)

核心: 商業價值有兩種創造方式：運營靠低成本、高效率的重複（ongoing maintenance）；專案類（專案、專案集、組合）做的是從無到有的變革。

PMI 術語: Ongoing Maintenance ↔ 日常維護

§17 非商業組織：社會價值 (00:18:14)

核心: 非營利或非商業組織創造的是社會價值、組織價值或社群價值（social value）。

• 例子：地方政府改善綠化、交通便利、城市整潔度、醫院床位配比，追求的是民眾的健康與安全感
• 政府招商引資時，看重的仍是商業價值

PMI 術語: Non-profit / Non-commercial Organization ↔ 非營利/非商業組織 / Social Value ↔ 社會價值

§18 專案集經理的角色與「團隊之團隊」 (00:19:39)

核心: 專案集經理是組織依治理程序任命並授權的人，領導團隊交付收益和價值，並對專案集的領導與績效負責。

• 中文版「高階管理層分配」有翻譯問題，實際指組織任命專案集經理的程序
• 團隊之團隊（team of teams）：各專案有自己的團隊，專案集經理帶領的是由這些團隊組成的團隊；各團隊彼此獨立，同時要協同配合

PMI 術語: Team of Teams ↔ 團隊之團隊

§19 accountability vs responsibility 的兩組翻譯 (00:20:36)

核心: 看並列的詞來判斷翻譯：「問責 + 責任」並列時，問責是 accountability，責任是 responsibility；「職責 + 責任」並列時，職責是 responsibility，責任是 accountability。

• 兩組翻譯在翻譯書中都存在，要依搭配的詞判斷

PMI 術語: Accountability ↔ 問責（或單責）/ Responsibility ↔ 責任／職責

§20 核心職責：管理/協調複雜的風險、問題與依賴關係 (00:21:40)

核心: 重點是第 3、4 條：管理或協調複雜的風險與問題，以及元件之間的依賴關係。基於依賴關係所做的管理，就叫協調。

• 專案集內元件之間的依賴關係最典型、最普遍
• 不習慣「協調」這個詞，也可以叫管理，但這樣就和其他管理沒有區別了
• 專案集經理管理元件以及元件之間的關係，不深入每個元件內部，這一點在新版沒有改變

§21 協作對人、協同對事 (00:23:12)

核心: 專案集經理和專案經理、組合經理、治理機構、發起人、運營經理之間，用協作 collaboration（人與人、人與組織）；三種管理實踐之間的配合，用協同 synergy。

🎯 考點: 題目或選項的用字：人和人之間 → collaboration；事情、實踐之間 → synergy；基於依賴的管理 → coordination。

§22 經理承擔 responsibility，發起人承擔 accountability（東家與掌櫃） (00:23:53)

核心: 專案集經理代表發起組織及其高層推動專案集成功，專案集失敗時承擔 responsibility；真正承擔 accountability（最終成敗責任）的是發起人。

• 專案集經理對發起人負責
• 比喻：發起人是「東家」（出錢的人、承擔最終損失），專案集經理是「掌櫃」（事情沒做好可能被解僱）
• 「做東」就是出錢的人；講師同時提醒，這幾個詞在中國大陸的翻譯並不統一

🎯 考點: Sponsor 對應 accountability，Program Manager 對應 responsibility。

§23 專案集經理必須是專業人士，並在 OPM 背景下工作 (00:26:17)

核心: 專案集經理負責專案集的規劃、執行和整體管理，必須是專業人士（掌櫃要懂糧食）；東家主要負責出錢，可能懂行，也可能不懂。

• 專案集經理要在組織級專案管理（OPM）的標準、方法論和流程下開展工作
• 這部分了解即可，不用背

PMI 術語: Organizational Project Management (OPM) ↔ 組織級專案管理

§24 專案集經理的互動角色圖 (00:27:20)

核心: 專案集經理向下管理專案經理，橫向與 PMO 合作（PMO 定標準、定流程），向上向發起人或指導委員會匯報，往後端與預期受益人、運營經理對接。

• 專案集 PMO 可能向上連結組合辦公室，組織的部分政策透過它傳達到專案集經理
• 發起人通常是指導委員會主席；講師說預設情況下，專案集發起人往往就是組合經理
• 協助專案集經理的是專案集團隊

⚠ 新版變化: 第 5 版弱化了其他角色，重點只放在專案集經理、發起人、PMO 三個角色；第 3、4 版講的角色多很多。

§25 勝任力 competency：能力要和事情匹配 (00:28:45)

核心: competency 譯為「勝任力」比「能力」準確，重點是能力要和特定工作匹配。

• 《亮劍》李雲龍擅長游擊戰、殲滅戰、運動戰，但指揮大兵團作戰的勝任力不足
• 抗美援朝選總司令：林、彭兩人勝任力都夠；勝任力和意願無關，最後由意願強烈的彭總出任
• 戰爭 > 戰役 > 戰鬥，層次不同，所需的勝任力也不同

PMI 術語: Competency ↔ 勝任力

§26 competency vs competence vs capability (00:31:12)

核心: 講師參與制定 ISO 專案管理專業人員能力框架標準：整體能力框架用 competency，單一能力項用 competence；不用更寬泛、不夠專業的 capability。

• 兩個詞都和「勝任、匹配度」有關
• 有些書把 competency 譯成「能力」，意思差不多，只是少了匹配度的意涵

§27 專案集經理需要的能力 (00:33:25)

核心: 對專案集經理的能力要求很多，包括溝通談判、干係人參與、變更管理、分析、收益、協作、商業與戰略、整體思考等。

• 溝通談判：傳遞資訊、達成一致
• 干係人參與：爭取別人替你站台、支持你，不是拉錢
• 變更管理：分清哪些變更要嚴控，哪些變化要擁抱
• 分析：資料分析、收益分析
• 商業與戰略：懂業務、懂所在行業（醫療、軟體、AI、製造、新能源等）
• 整體思考（系統思維）：講師本課也是由上而下構建專案集的思維體系，而不是拼湊知識點

§28 懂三層管理、能與高層互動、建立合作關係 (00:35:30)

核心: 專案集經理要懂專案管理和組合管理，更要懂專案集管理，才能找準自己的位置；同時要能和高層互動。

• 就算有組合經理的能力，接到的是專案集的工作，就要用專案集的方法（從工具包裡選對工具）
• 和高層互動時，要展示專案集對高層和公司的意義與價值（展示，不是造假）
• 依領導風格調整匯報粒度：有的領導要細節，有的只要要點
• 要和他人建立合作關係，光靠自己的團隊做不了那麼多事

§29 發起人：提供資源、承擔最終責任的高層 (00:37:15)

核心: 發起人（sponsor）代表出錢的發起組織，可以是個人或團體，但通常是一個人。最主要的作用是提供資源（錢、人、設備），並對專案集成功承擔最終責任（accountability）。

• 同一個專案集，在供應商、本公司、政府各方都可以有各自的發起人，可以有多個，但不是必須有多個
• 發起人通常是高層（executive），例如 CEO、CFO、CTO 等 CxO；和 senior management（高階管理層）的用詞不同
• 實務上不保證都是最高層

講師原話:「一說到 sponsor，那他承擔的就是 accountability，這個沒什麼說的。」

PMI 術語: Sponsor ↔ 發起人 / Executive ↔ 高層 / Senior Management ↔ 高階管理層

§30 職權來自組織，領導力來自追隨 (00:39:46)

核心: 發起人的地位是組織給的，不代表他一定是大家認同的領導者。領導者是大家願意追隨才形成的，只有組織任命的，頂多是管理者。

• 發起人可以指導和支援專案集經理，甚至一起完成專案集的工作

§31 發起人 vs 專案集指導委員會 (00:40:28)

核心: 發起人和指導委員會是不同角色，但關係緊密：發起人通常擔任指導委員會主席；委員會由各主要干係人代表組成，主要透過投票做決策（類似董事會和董事長）。

• 委員會可以充當發起人，但只限有限的時間，最好不要長期如此
• 不建議由委員會集體擔任發起人，否則責任不明確
• 發起人是個人時，應是組織高層；發起人是一個小組時，就稱為指導委員會

🎯 考點: 發起人＝個體，通常是委員會主席，責任明確；不提倡長期由群體當發起人。

§32 專案集 PMO：臨時結構，三大核心職能 (00:42:26)

核心: 專案集 PMO 是臨時性的組織結構，專案集結束就解散。所有 PMO（project/program/portfolio）的共通工作是共享方法論、資源、工具技術，以及培訓。

• 其他職責：制定標準與流程、開發模板與方法論、培訓、文件管理、協助變更管理與溝通（例如組織大型會議）、管理進度與收益
• 要記住的三個：標準化、方法論、培訓
• PMO 也可以參與收益移交，甚至擔任收益的接收方
• 設置什麼樣的 PMO，取決於組織需要、治理結構和資源情況

PMI 術語: Program Management Office (PMO) ↔ 專案集管理辦公室

§33 PMO 的實例：出資方要求設 PMO，考試視為必選項 (00:44:28)

核心: 某疾控中心的 PMO 是出資方（美方研究資助）提出的條件之一；國外甲方也曾要求承包方設 PMO，方便和甲方的 PMO 對接。PMO 現在幾乎是必選項。

• PMO 的設置可能受很多因素影響，包括發起方或出資方的要求
• PMO 要定位成什麼樣子，依實際情況決定

🎯 考點: 考試時把 PMO 當作必選項（一定要有），但它的形式與定位要因應具體情況。

§34 PMO 的四種設置形式 (00:47:37)

核心: 有些組織不設正式 PMO，有些被要求設正式 PMO，有些由現有組織承擔 PMO 職能；如果沒有 PMO，就由專案集經理自己承擔這些職責。

• 講師明確指出，最後這句「沒有 PMO 就由專案集經理自己承擔」可能成為考點
• 職責中最常考的是標準化、方法論和工具共享、培訓

🎯 考點: 情境中沒有 PMO 時，PMO 的職能就是專案集經理的責任。

§35 5th 擴充：大型/長期專案集的 PMO 職能 (00:48:22)

核心: 在大型或複雜的專案集中，PMO 還可能承擔人力資源管理、採購和法律合規工作；持續時間特別長的專案集，PMO 可能承接移交的收益，協助日常運營。

• 在西方法治體系下，合規通常放在 PMO
• 沒有 PMO 時，這些工作都由專案集經理承擔

⚠ 新版變化: 這些擴充職能在第 5 版標準中有文字記載。

§36 專案集 vs 專案（一）：不確定性 (00:49:23)

核心: 專案集面對的環境和體量更大，不確定性明顯比專案高；專案集的做法是擁抱不確定性。

• 風險在專案集和專案中都存在，只是在專案集更明顯

§37 專案集 vs 專案（二）：變更：戰略層面擁抱 vs 戰術層面控制 (00:50:15)

核心: 專案集從戰略層面看待變更，追求適應變更，能帶來好處的變更要擁抱並抓住機會；專案在戰術層面控制變更，依據基準和計畫處理。

• 專案集層面的變更，來自外部環境和戰略的改變

🎯 考點: Program 對變更的態度＝擁抱、適應（看收益）；Project 對變更的態度＝控制（看基準）。

§38 專案集 vs 專案（三）：複雜性：簡單系統 vs 複雜系統 (00:51:01)

核心: 專案集的複雜性比專案更高。複雜性有三個來源：人類行為、系統行為、模糊性。

• 簡單系統不代表體量小，複雜系統也不代表體量大
• 工業生產線體量和金額都可能很大，但輸入和輸出確定、環節穩定，是「體量很大的簡單系統」
• 家裡 10 到 20 平方公尺的小花園，有土壤、水和生態關係，是「小的複雜系統」
• 規模越大，複雜性可能越高，但兩者沒有直接關係

PMI 術語: Human Behavior / System Behavior / Ambiguity ↔ 人類行為／系統行為／模糊性

§39 複雜系統的判準：輸入與輸出之間缺乏明確因果關係 (00:52:45)

核心: 複雜系統的主要區別因素，是輸入和輸出之間缺乏明確的因果關係，或只有較弱的因果關係。講師認為這是 Standard 對複雜系統最簡潔的解釋，建議記住。

• 輸入和輸出的關係穩定，系統再龐大也是簡單系統
• 天氣是典型的複雜系統，例如蝴蝶效應：很小的改變可能帶來破壞性的結果
• 反過來，大量投入也可能幾乎沒有效果，直到達到臨界值，例如氣候變化
• 因此專案管理的方法，在專案集中往往不太好用

講師原話:「複雜系統的主要區別因素是輸入和輸出之間缺乏明確的因果關係，或者只有較弱的因果關係。」

🎯 考點: 判斷複雜性要看輸入與輸出的因果關係是否明確，不看規模。

§40 定義重點：專案集提供收益，組合提供價值 (00:55:08)

核心: 專案集是「一組相互關聯」的子專案集、專案和專案集活動，以協調的方式管理；「相關」這個詞不能忽略。專案集通常是組合中的元素，重點是收益，價值則屬於組合層面。

§41 應對不確定性：專案保守、專案集站高 (00:55:50)

核心: 專案層面趨於保守，遵循流程、嚴格控制；專案集從更高的視角，和戰略保持聯繫來處理不確定性。

• 專案的資源有限，專案集經理的權限比較大
• 不確定性是事物的基本屬性，兩者都會遇到；差別在於處理的手段、原則和思維
• 兩個差異點：資源的多寡、權限的大小

§42 不確定性 vs 風險 (00:57:30)

核心: 精確地說，完全未知的叫不確定性；機率或影響至少有一個已知的，叫「已知的未知」風險。非專業人員可以把不確定性和風險畫上等號。

• 風險有兩面：機會（抓住了就能實現收益）和威脅（遇到了會減少收益，相當於負收益）
• 不確定性就是 VUCA 中的 U（uncertainty）

PMI 術語: Uncertainty ↔ 不確定性 / Known Unknowns ↔ 已知的未知 / Opportunity / Threat ↔ 機會/威脅

§43 收益導向的變更態度與三種變更 (00:59:05)

核心: 專案集在戰略層面處理變更時以收益為依據，能擴大收益的變更通常接受並擁抱；專案則以控制為主線，防止出現差異。

• 專案集經理要考慮三種變更：專案集變更、內部變更（組織內、專案集外）、外部變更（組織外）
• 專案集本身就是變革過程，例如收益移交時，接收方本身就要改變
• 專案集是前瞻性地面對變更：變更是為了適應不斷變化的環境，不把變化當成負面因素

§44 繁雜 complicated vs 複雜 complex (01:01:06)

核心: 大型專案集可能非常繁雜（complicated），有許多專案和相關運營；但每個專案是一個系統，整個專案集是「系統之系統」，屬於複雜（complex）系統，也就是輸入和輸出之間缺乏明確關係。

PMI 術語: Complicated ↔ 繁雜 / Complex ↔ 複雜 / System of Systems ↔ 系統之系統

§45 Stacey 複雜性矩陣 (01:01:55)

核心: Stacey 矩陣（PMBOK 第 7 版提出）從需求和技術兩個維度選擇方法。

• 需求和技術都確定：預測型（線性）方法
• 技術確定、需求不確定：增量型方法
• 需求確定、技術不確定：迭代型方法
• 增量 + 迭代 = 敏捷區域，對應 complicated
• 複雜（complex）區域：勉強可以用敏捷，預測型完全無能為力
• 兩者都不確定：混亂（chaos），沒有方法可以支撐，只能靠人在混沌中找出可以做的事
• 複雜性無法控制，但可以調整活動來應對

PMI 術語: Stacey Complexity Matrix ↔ Stacey 複雜性矩陣 / Chaos ↔ 混亂

§46 專案集 vs 組合（一）：關聯性 (01:04:47)

核心: 兩者的共性是都是元件的集合。差異之一：組合內的元件可以有關聯，也可以沒有；專案集內的元件必須相互依賴，否則不成立。

• 組合內的元件若有依賴關係，用組合或專案集的方法管理都可以；用專案集方法能獲得增量收益，組合方法不強調增量收益

🎯 考點: 組合的元件「可以」相互獨立；專案集的元件「必須」相關，不要模糊。

§47 專案集 vs 組合（二）：時間跨度、層級、投資導向 (01:06:42)

核心: 專案集的時間跨度比專案長，但仍是臨時性工作，有明確的開始和結束；組合不受限於特定的開始或結束日期，開始點是戰略調整的那一刻。

• 實務上組合也可以設定起訖時間，但答題時要視為「沒有明確的起點和終點」
• 組合在組織中的管理級別高於專案集
• 組合以投資為導向（投錢要回報，有價值就做，沒價值就停）；專案集以管理為導向（看目標達成與績效）
• 組合對專案集影響很大：可以啟動、暫停、延緩、取消專案集

🎯 考點: 組合＝沒有固定起訖、投資導向；專案集＝臨時性（有開始有結束）、管理導向。

§48 第 5 版新增「原則」：考題不易出，抓方向 (01:10:34)

核心: 原則是第 5 版新增的內容，比較高層次，講師判斷不太容易直接出題，建議掌握每條原則的指導方向。

• 例如：收益實現原則代表一切都要圍繞收益，不為收益實現服務的活動都可以拿掉
• 干係人原則：沒有搞定干係人、沒和他們配合好，就違背了這條基本原則

⚠ 新版變化: 第 5 版新增八大原則。

§49 八大原則總覽：原則是底線 (01:12:20)

核心: 八大原則從干係人、收益實現、協同到團隊之團隊等，共八條，指導後面六大績效域的具體活動。

• 原則（principles）有點像宗旨，是不能觸碰的底線
• 在管理上，觸碰底線不是會受懲罰，而是這套管理模式會失去應有的作用
• 協同原則用的是 synergy

§50 擁抱變化、領導力、風險、治理原則 (01:13:27)

核心: 擁抱變化是專案集和專案管理的一大區別；領導力原則強調激勵而不是管控；風險原則強調主動管理；治理原則強調要有規矩。

• 變化（change）也可以叫變革，變革一般屬於戰略層面
• 領導力：專案集經理雖然層級高，仍要展現領導行為，不要以強加要求、管控為主的形象出現
• 原則性的事情仍不能突破，例如多個專案之間的資源衝突，就需要有強力的要求，不能放任
• 風險：主動管理，確保專案集方向不偏離戰略目標
• 治理：強調要求與管控（governance 語氣強烈）
• 理論上原則之間不應有矛盾，實務上可能衝突，例如治理與領導力，要辯證地看

PMI 術語: Governance ↔ 治理 / Leadership ↔ 領導力

§51 原則的定位：位於六大績效域之上的燈塔 (01:15:41)

核心: 原則是價值觀和規範，位於六大績效域之上，指導績效域中的活動，這種指導帶有強制性。六大績效域之間是協作（collaboration）關係。

• 原則是知識、實踐、經驗和智慧的燈塔，為戰略制定、決策和問題解決提供基礎指導
• 用管理模式解決不了的事情，就用原則來判斷，就像價值觀是最後的判斷底線

§52 專案、專案集、組合原則之間的交集 (01:17:33)

核心: 專案、專案集、組合的原則之間有交集，這裡只是提出概念，沒有實質內容。

• 專案集原則有 8 條；PMBOK 第 8 版的專案管理原則也是 8 條（由原本 12 條精簡）
• 組合目前還沒有明確提出原則

⚠ 新版變化: PMBOK 8 把專案管理原則由 12 條改成 8 條。

§53 收益實現原則：實現 → 過渡 → 維持 (01:18:19)

核心: 收益實現原則要求專案集經理和團隊始終關注與組織戰略一致的專案集結果（outcomes）。除了收益實現，還要關注收益維持（sustainment），中間必須做好收益過渡（transition）。

• 收益實現只代表收益按計畫產生了，還要讓收益在未來延續下去
• 過渡做得好不好，決定了維持的起點；過渡不好，維持做到百分之百也達不到最佳
• 過渡中對接收方的培訓非常重要，而且不只上課，還包括現場或遠端的指導
• 考試中「移交」對應的譯詞是「過渡」（transition）

講師原話:「收益的過渡是我們收益能夠持續的前提和必要條件。」

PMI 術語: Benefits Realization ↔ 收益實現 / Transition ↔ 過渡（移交）/ Sustainment ↔ 維持

§54 delivery＝產生，transition＝交出 (01:22:01)

核心: 在專案集管理中，交付（delivery）指實現或產生（generate/create/produce），是把收益從無到有創造出來，並沒有交出去；交出去的動作叫 transition。

• 有些行業的「交付」指交給對方，容易混淆
• transfer 極少使用；如果選項同時出現 transition 和 transfer，transition 更精準
• 整理四個詞：收益實現、交付、移交（過渡）、維持

🎯 考點: 收益交付 benefits delivery＝產生收益；把收益交給運營或接收方＝benefits transition。

§55 收益最大化：收益增加就可容忍範圍蔓延 (01:23:33)

核心: 為了讓收益最大化，難免做一些原範圍以外的事。專案集管理不在意鍍金和範圍蔓延，前提是收益增加（付出少、獲得多）。

• 在專案管理中，範圍蔓延是大事：要走變更流程、送 CCB 審批；直接後果是進度延誤和成本增加（範圍是第一基準）
• 專案集弱化了範圍邊界：不是完全不在意，而是只要能擴大收益，範圍增減一點都沒關係
• 這也反映專案集對變更的態度：大量變更決策權下放給專案集經理，不強調層層審批

§56 增加或刪減元件必須送指導委員會 (01:27:02)

核心: 為了收益最大化，可能要新增元件（成立新專案）。增加、刪減或修改元件時，專案集經理不能自行決定，發起人也不行，必須送專案集指導委員會決策。

• 新增元件代表增加投入，預期收益只是預期，必須取得管理層背書（簽署、同意）
• 從收益實現、最大化、移交、維持的角度提出，獲批機率就會大大提高

講師原話:「增加減少元件這種行為，專案集經理不能自行決定，發起人都不行，必須要到專案集指導委員會去做決策。」

🎯 考點: 題目中為了收益要新增或取消元件，答案是提交指導委員會（治理）批准，專案集經理不能自行決定。

§57 指導委員會的各種名稱 (01:29:29)

核心: 專案集指導委員會最經典的英文是 program steering committee，也稱 program governance body 或 program governance committee（後者出現機率較低），指的都是同一個機構。

PMI 術語: Program Steering Committee ↔ 專案集指導委員會 / Program Governance Body ↔ 專案集治理主體

§58 干係人原則：全部識別、分類分級、監控互動而不是人 (01:30:33)

核心: 要盡最大努力爭取干係人，但不是一視同仁：識別所有干係人後，用權力/利益方格分類分級，不同區間用不同策略。

• 權力高、利益大的干係人重點管理；權力低、影響小的跟蹤即可
• 強調主動性，因此用詞是「干係人爭取」（engagement）
• 監控的是我們和干係人之間的互動有沒有達到預期，不是監控干係人本人（人不能被監控）

PMI 術語: Stakeholder Engagement ↔ 干係人參與（爭取）/ Power/Interest Grid ↔ 權力利益方格

🎯 考點: 「監控干係人參與」是監控互動和參與的成效，不是監視人。

§59 協同原則（開頭） (01:33:01)

核心: 第三條原則是協同：組合、專案集和專案管理實踐要配合好。協同（synergy）對事，協作（collaboration）對人，用這個區分來答題；實務上兩個詞混用也沒關係。

Part B (01:33:34 - 03:04:28) 綜述

這段是 Standard for Program Management 5th 第 2 章「專案集管理原則」(Program Management Principles)的完整精講,講師分兩輪進行:第一輪(01:33-01:49)快速把八大原則過一遍,第二輪(01:49-03:03)按講義逐條展開,依序為干係人(Stakeholders)、收益實現(Benefits Realization)、協同(Synergy)、團隊之團隊(Team of Teams)、變更(Change)、領導力(Leadership)、風險(Risk)、治理(Governance)。開頭先釐清三種管理模式的分工:專案組合管「篩選、排優先順序、分配資源」(管控),專案集管「協調」,專案管「管理與交付」。之後每條原則都拉回 PgMP 的主軸「收益」,講師用了很多比喻:曾國藩「勝則舉杯相慶,敗則拼死相救」講協同文化,師部、參謀講團隊之團隊,Blues 講協同的節奏,瓦良格號圖紙講移交範圍。最後講師提醒:原則偏抽象、直接考的比例不高,重點是理解背後的觀念;第 3 章的績效域(Performance Domains)才有具體活動和文件,是下一段的重點。

最重要的考點判準: 1. 干係人本身不能被管理,能被管理的是他的期望;爭取干係人要靠收益(利益)。 2. 收益實現的時間點分 before / at / after 三種;收益實現的規劃在「定義階段的規劃子階段」做,元件要到交付階段才產生。 3. 專案集層級的變更以「元件」為顆粒度(新增、取消、終止、修改),要由指導委員會核准;元件內的範圍、進度、成本變更屬於戰術層,由專案經理和 CCB 處理。 4. 專案集經理要充分授權給元件經理,不插手專案內部的事;跨專案的問題才由專案集出面協調。 5. 風險、問題、變更請求三者會互相轉化:威脅發生了叫問題,機會抓住了會轉成收益(capitalize);專案集結束時還沒關閉的風險要移交給接收方。

§60 組合、專案集、專案三種管理模式的分工 (01:33:34)

核心: 三者都是結構化的管理方法,但各有側重;有交集、有互動,不代表它們一樣。

• 專案組合(Portfolio)強調篩選、排優先順序、分配資源,關鍵詞是「管控」
• 專案集(Program)關鍵詞是「協調」(coordinate)
• 專案(Project)強調管理和交付
• 三者要配合好,形成互相促進的關係,而不是內耗;一旦把「人」的因素放進去,就不容易做到

🎯 考點: 看到 select / prioritize / allocate resources 就是組合層級;看到 coordinate 就是專案集層級;看到 deliver 就是專案層級。

§61 協同原則:協同是一種文化 (01:34:30)

核心: 協同(Synergy)講的是組織裡要有大家一起把事情做成的文化,這條原則具體指專案組合、專案集、專案三種管理實踐要互相配合。

• 講師引用曾國藩治軍的「勝則舉杯相慶,敗則拼死相救」,說明同生共死、目標一致的協同文化
• 舉古代親兵制度為例:主將被擒或被殺,身邊護衛全部處斬,所以主將不會輕易涉險,護衛也會拼死保護。機制一旦變成傳統,就成了文化
• 公司裡的理想狀態是:需要支援時大家一起衝,慶功時大家一起慶祝

PMI 術語: Synergy ↔ 協同

§62 團隊之團隊:專案集架構與專案集團隊 (01:37:20)

核心: 專案集架構(Program Structure)和專案集組織架構(Program Organizational Structure)不一樣;專案集團隊(program team)不包括底下的專案經理。

• Program Structure:指專案集和元件(component)之間的關係。元件之間一定有千絲萬縷的聯繫,沒有聯繫就不能叫專案集
• Program Organizational Structure:指團隊的管理架構,也就是專案集經理底下有誰
• Program team,也叫 program core team(專案集核心團隊),指專案集經理身邊的那些管理者;它可能和 PMO 是同一個團隊,也可能分開
• 專案集團隊不包括下面的專案經理;如果把專案經理也算進去,會很嚴重地支離破碎。但現實中大家常把專案經理都收上來一起做管理
• 團隊之團隊:底下各專案是一個個團隊,專案集是「團隊之上的團隊」,作用是整合團隊結構、跨元件建立關係網路,提升適應性和韌性

PMI 術語: Program Structure ↔ 專案集架構 / Program Organizational Structure ↔ 專案集組織架構 / Program Core Team ↔ 專案集核心團隊 / Team of Teams ↔ 團隊之團隊

🎯 考點: Program team = 專案集經理身邊的管理團隊,不含各元件的專案經理。

§63 將權力推至邊緣,同時做到頂層透視 (01:40:08)

核心: 專案集經理管好自己的事,不要過度插手底下;可以不干預,但資訊一定要往上流。

• 我可以不干預你,但你不能不告訴我:到了進度節點或關口(gate),一定要讓上層知道情況
• 這是敏捷的做法:「將權力推至邊緣」(把權力下放),同時「頂層透視」,關鍵時刻還能介入
• 特種兵小組:每個人看到資訊第一時間告訴隊友;我不管你先邁哪隻腳,但你的位置和狀況要讓大家知道
• 授權要充分,不能讓授權空轉
• 軍隊比喻:師部身邊是參謀、政委、通信兵,不是從前線部隊抽上來的人。上級只下達「死守某隘口 72 小時」這種目標,怎麼守由作戰部隊自己決定
• 企業效率低,往往是因為介面沒準備好、權力沒放好,上級總想干預下級

§64 變更原則與領導力原則(概覽) (01:43:46)

核心: 變更原則就是擁抱變更,只要能讓收益最大化,就可以主動追求變更;領導力原則以激勵為主,目的是團結團隊、維持整體交付節奏。

• 領導力和團隊之團隊有關聯
• 值得追隨的領導者,通常有人格魅力、給人充分信任、或能指出方向並幫助別人完成工作
• 領導力的基礎是人品:這個詞是給正義的一方用的;對煽動群眾的人只能叫「煽動力」,不能叫領導力
• 其他要素:同理心(換位思考)、充分信任、政治敏感度(看懂組織內部資源和權力怎麼分配),目標是用最少的消耗換最大的回報

講師原話:「只要能夠實現收益最大化,就可以主動追逐變更。」

§65 風險原則(概覽):前置管理與風險閾值 (01:45:50)

核心: 風險管理要前置,也就是要有預見性和主動性;同時要把干係人和組織的風險偏好(risk appetite)量化成閾值(threshold),碰到閾值就採取行動。

• 等風險來了才處理就太晚了;但風險又不可能 100% 預測和掌控,所以要設閾值
• 還沒碰到閾值的,先讓它自然發展;一碰到就啟動應對
• 風險偏好和風險閾值高度相關:閾值背後對應的就是偏好
• 講師提到 PMI-RMP 認證:內容大致是 PMBOK 第 6 版以前的風險管理章節,包括規劃風險管理、識別風險、定性分析、定量分析、規劃應對、實施應對、監督風險

講師原話:「我們要把重要干係人和組織的風險偏好量化為臨界值,達到這個臨界值我們就採取行動。」

PMI 術語: Risk Appetite ↔ 風險偏好 / Risk Threshold ↔ 風險閾值(逐字稿作「預值/臨界值」)

§66 治理原則(概覽):相稱且適當的治理框架 (01:48:04)

核心: 要建立並採用「相稱且適當」的專案集治理框架,必要時能把專案集控制住。

• 「相稱且適當」指的是:集權還是分權、決策走三層還是四層、核准要在多長時間內完成等,都要依情況設計
• 雖然要展現領導力、要協同,但不能把權力全部放掉,關鍵時刻要能控制住
• 八大原則的主要內容到此講完,接下來逐條細講

講師原話:「雖然要展現領導力、要跟大家協同,但確實不能夠完全放權,在關鍵時候你得能夠控制住。」

§67 干係人原則:人不能被管理,期望可以被管理 (01:48:55)

核心: 干係人本身不能被管理,但干係人的期望可以被管理。

• 干係人可能是一個人,也可能是一組或一群人,但終究是人
• 向主管匯報專案進展,本身就是在管理干係人期望:說什麼、不說什麼,都經過篩選
• 現實中很少有人能 100% 全部透明;匯報的內容都有傾向性,可能想讓對方安心,也可能想讓對方有危機意識

講師原話:「干係人不能被管理,但是干係人的期望是可以被管理的。」

PMI 術語: Stakeholder Expectations ↔ 干係人期望

§68 用收益爭取干係人;考試時的理想化假設 (01:51:23)

核心: 干係人原則和後面的「干係人爭取」績效域高度重疊;爭取干係人最根本的手段是收益(利益)。

• 干係人原則把三件事連在一起:干係人期望(個人層面)、專案集收益(中高層)、組織戰略(高層)
• 干係人不一定會把期望明確說出來
• 怎麼把干係人拉到同一戰線?靠利益。講得中性一點,就是用收益來爭取
• 可以從三個角度講:對組織戰略有什麼貢獻、專案集能帶來什麼收益、對他個人有什麼好處
• 考試要用理想化的假設:干係人是客觀的,認同組織戰略,而且他的利益和專案集收益一致。現實中個人因素可能是最重要的,但答題不能這樣想

講師原話:「考試你得把它想成:符合組織戰略的,一定是符合干係人的期望……他的利益跟專案集的收益是緊密相連的。」

PMI 術語: Stakeholder Engagement ↔ 干係人爭取/參與

🎯 考點: 答題時假設干係人以組織戰略為重;爭取支持的方法是說明收益和戰略價值,不是談私人交換。

§69 干係人參與的層面與關鍵特徵 (01:54:55)

核心: 干係人無處不在,要分類、分級;做好干係人原則要具備幾個特徵:主動、協作、了解(monitor)、促進(facilitation)、適應、清晰、人際技能。

• 層面:組織、組合、專案集、元件、外部環境
• 主動性:不要等別人來找你
• 協作性:大家要配合好
• Monitor:講師建議翻成「監督/了解」,不要翻成「監控」。英文原意是了解情況、比較分析、持續追蹤,語氣是中性的
• 促進(facilitation):主動推動事情往好的方向走,例如教育、培訓干係人
• 對高層要主動協作,對平級或整體要做好了解
• 適應性:干係人的重要性和立場會隨時間改變,可能從早期支持變成中立,後期甚至反對;也會有新的干係人出現
• 清晰性:每個人的需求不同,溝通偏好也不同(電子檔、紙本、口頭、印出來放桌上),對收益的需求也不同
• 人際關係技能:建立和維護關係的能力
• 講師說這部分不用死背,理解就好

講師原話:「monitor 是了解情況、對比分析、跟蹤……就是你要對干係人非常關注才行。」

PMI 術語: Monitor ↔ 監督(了解) / Facilitation ↔ 促進

§70 干係人關鍵實踐:分類分級、隨生命週期變化 (01:58:59)

核心: 想讓干係人充分參與,要做三件事:全面識別;分類分級並用不同策略爭取;在整個生命週期持續監督和回應干係人的變化。

• 參與級別、影響力和態度,會決定用什麼策略
• engagement 有時翻成「爭取」,有時翻成「參與」
• 利用協同效應:發現戰略上的共同點、降低溝通開銷、減少複雜情境
• 不同類別和級別用不同策略:有的要重點管理,有的令其滿意
• 干係人會變:早期只是骨幹,到第二、三期可能被提拔為處長,權力就變大了
• 要在整個生命週期持續監督並回應期望、權力、影響、需求和回饋的變化

講師原話:「識別需要強調的就是全面識別,但是爭取的時候並不是所有人都一視同仁。」

🎯 考點: 識別要全面;爭取要分類分級、區別對待;干係人分析不是做一次就好,要在整個生命週期持續更新。

§71 干係人清單與權力/利益方格 (02:00:54)

核心: 團隊、PMO、發起人、指導委員會都是干係人;權力/利益方格分四個象限,PMI 各項考試都會出現。

• 談到干係人,幾乎包括所有人,但所有人不代表一樣對待
• Power 可以換成 influence:power 偏強制性,influence 偏軟性,本質相近
• Interest 可以翻成利益,也可以翻成興趣
• 四個象限的策略(重點管理、令其滿意、隨時告知、監督)要記住

講師原話:「這四個特點大家記住,PMI 所有的考試當中都會出現這個問題。」

PMI 術語: Power/Interest Grid ↔ 權力/利益方格 / Influence ↔ 影響力

🎯 考點: 權力/利益方格四象限的策略要能直接對應(高權高利:重點管理)。

§72 專案集生命週期:定義、交付、收尾 (02:02:10)

核心: 專案集定義大致等於啟動加規劃,專案集交付等於執行,收尾就是收尾;專案集交付是靠元件的交付完成的。

• 元件完成各自的交付,專案集再把這些交付整合成收益
• 在整合成收益的過程中達成專案集目標,然後收尾

講師原話:「專案集的交付實際上是依賴元件的交付來完成的……然後專案集把它整合為收益。」

PMI 術語: Program Definition ↔ 專案集定義 / Program Delivery ↔ 專案集交付 / Program Closure ↔ 專案集收尾

§73 收益實現原則:定義,以及「結果」和「成果」 (02:02:56)

核心: 收益實現包括實現、移交、最大化、維持;定義是:一個或多個組織從專案集的結果中獲得收益,並透過運營這些產品、服務和成果,維持競爭優勢、達成目標。

• 講師認為講義上的「成果」應改成「結果」,問題可能出在標準的中文翻譯
• 目標導向是按早期的目標拆解去執行;結果導向是看最後做成了什麼
• 實現和維持收益是專案集的主要目的,兩者中間隔著「移交」
• 維持階段不只是維持現狀,還可以創造機會,讓收益繼續擴大
• 專案集從開始到結束,甚至到交給接收方之後,都要關注收益;有些是主責,有些是以協助者的身分參與

講師原話:「實現和維持收益是專案集最主要的目的,他們中間隔著一個移交。」

PMI 術語: Benefits Realization ↔ 收益實現 / Benefits Sustainment ↔ 收益維持 / Transition ↔ 移交

§74 專案集經理的終極責任:確保收益 (02:04:53)

核心: 專案集因收益而存在,專案集經理因專案集而存在;如果判斷專案集已經實現不了收益,結果通常是取消,或縮減範圍(縮小目標)。

• 題目若說「專案集經理判斷收益可能無法實現」,90% 的答案是取消專案集或縮減範圍
• 專案集經理要確保收益,做法是取得團隊的承諾(commitment):全心投入,兌現最初接下目標時的承諾,遇到困難也要團結所有人完成

講師原話:「專案集因為收益而存在,專案集經理因為專案集存在而存在;沒有了收益就沒有專案集,沒有了專案集就沒有專案集經理。」

🎯 考點: 收益已經無法實現時,方向是建議取消或縮減範圍,不是硬撐交付。

§75 收益的其他要素:戰略一致、投資合理、干係人認同、風險平衡 (02:06:12)

核心: 收益必須在戰略一致的前提下才有意義,投入要合理,要得到干係人認同,還要和風險取得平衡。

• 收益和戰略不一致,就沒有價值
• 投入合理性:不只看成本,要看投資報酬。成本可以高一點,只要收益擴大就好(例如為了擴大市場份額,組織可以接受不虧損,甚至小虧 3-5%)
• 收益要得到干係人和受益人認同才算數
• 風險和收益要平衡:收益大但風險也高,可能放棄;如果組織偏好風險,也可能接受
• 講師說這些了解即可,不用硬背

講師原話:「收益一定是在戰略一致的前提下,要不然收益沒有意義。」

§76 收益實現的三個時間點:before / at / after (02:07:35)

核心: 以專案集結束的那一刻為分界,收益分成三種:結束前就實現(before)、結束時實現(at)、結束後很久才實現(after)。

• Before:在過程中就產生,專案集或元件剛建立不久就開始產生成果
• At:在專案集完成(at the completion of the program)、完成整合和移交時立即實現
• After:專案集結束後很長一段時間才實現,有滯後效應
• 收益管理會在「收益管理」績效域詳細講

講師原話:「記住三個詞就行了,這個是考點,很重要的一種考點。」

PMI 術語: before / at / after the completion of the program ↔ 專案集結束前/結束時/結束後

🎯 考點: 判斷收益在哪個時間點實現:增量交付在過程中產生的屬於 before;結束時整合移交後立即產生的屬於 at;要多年後才顯現的屬於 after。

§77 向運營移交:移交範圍不只是可交付物 (02:09:33)

核心: 專案集要拉著運營方一起制定移交計劃;移交內容包括收益、可交付物、資料檔案和培訓,範圍由雙方協商。

• 收益只是移交的一部分,過程中的資料檔案也可能要移交,看移交計劃怎麼定範圍
• 瓦良格號例子:中國買下半成品航母,一開始以為圖紙也包含在內,結果對方沒給;如果只靠逆向工程,時間太長,後來花了功夫才拿到幾百噸的圖紙
• 培訓發生在移交過程中:不能只把結果和資料丟給對方,還要教會他們怎麼用
• 有好的移交,才可能有好的維持;移交的前提是先把收益創造出來
• 移交工作屬於專案集範圍;專案管理很少談移交,通常只移交可交付物

講師原話:「移交的內容當中除了收益和可交付物本身之外,還有可能是一些資料……沒有合適的移交,基本上收益維持做不到。」

🎯 考點: 移交計劃要和接收方(運營)共同制定;移交範圍包括收益、產品、文件和知識、培訓。

§78 收益實現規劃在定義階段的規劃子階段 (02:12:49)

核心: 收益實現的規劃在專案集定義階段的「規劃子階段」;元件要到交付階段才產生。

• 三個階段:定義(Definition)、交付(Delivery)、收尾(Close-out,不是 closer)
• 定義階段分成兩個子階段:構建(Formulation)和規劃(Planning)。講師建議叫「規劃」比「計劃」好,因為「計劃」通常被理解成一份文件
• 很多人會猶豫是不是選構建,但從名稱就看得出來:收益規劃是規劃子階段最重要的內容
• 規劃時要考慮收益之間的依賴關係和實現路徑;甚至這時就要開始考慮怎麼移交、怎麼維持
• 元件不是在規劃階段產生,而是在交付階段才出現,考題常考這裡

講師原話:「收益實現的規劃發生在專案集定義階段的規劃子階段……元件是在這個時候(交付階段)才出現的,要記住,考題很多出現在這個位置。」

PMI 術語: Program Formulation ↔ 專案集構建 / Program Planning ↔ 專案集規劃 / Close-out ↔ 收尾

🎯 考點: 問「收益實現計劃在哪個(子)階段制定」,答規劃子階段;問「元件何時授權、啟動」,答交付階段。

§79 各子階段的收益任務:構建、規劃、交付 (02:15:17)

核心: 構建子階段完成戰略論證並取得核准(專案集立項);規劃子階段把預期收益量化並規劃出來;交付階段一邊交付一邊跟蹤收益,一直延續到收尾。

• 收益在整個專案集生命週期中一直存在

講師原話:「規劃預期收益,量化並且規劃出來,是在規劃子階段;跟蹤收益是在交付階段同時完成,一邊交付一邊跟蹤。」

§80 收益管理貫穿生命週期;收益相關文件鏈 (02:16:00)

核心: 收益管理從識別到移交,貫穿整個生命週期,甚至在專案集關閉之後還會延續;收益相關文件從商業論證一路延伸到專案集管理計劃。

• 各績效域互相交叉,但「生命週期」和「收益管理」這兩個績效域的關係特別明顯,兩者並行很長一段時間
• 講師用 B 代表收益,PLC(Program Life Cycle)代表生命週期來畫圖
• 文件鏈:商業論證(Business Case)→ 路線圖(Roadmap)→ 章程(Charter)→ 收益實現計劃(也叫收益管理計劃)→ 專案集管理計劃
• 路線圖現在已經收納進專案集管理計劃

講師原話:「在專案集的生命週期當中收益一直存在,甚至在專案集結束以後收益還會存續很長時間。」

PMI 術語: Business Case ↔ 商業論證 / Program Roadmap ↔ 專案集路線圖 / Program Charter ↔ 專案集章程 / Benefits Realization Plan ↔ 收益實現計劃 / Program Management Plan ↔ 專案集管理計劃

⚠ 新版變化: 講師指出路線圖已歸入專案集管理計劃(作為其組成部分)。

§81 收益生命週期比專案集長;專案集不宜兼做運營 (02:18:28)

核心: 正常情況下,收益的生命週期一定比專案集長;如果運營工作還是由專案集來做,標準建議另外新建一個專案集來承接,不要讓當前專案集一直延續下去。

• 唯一的例外是專案集中途被叫停,收益不再需要
• 收益管理和元件(專案)的管理有緊密聯繫,也有相當大的差別
• 一旦移交,主導權就轉到接收方;專案集只介入一定程度的收益運營,提供支援,例如遠端支援、技術支援、help desk,不是主導方

講師原話:「收益的生命週期遠長於專案集的生命週期……如果仍然由專案集來進行,最好是新建立一個專案集接受當前這個專案集的運營工作。」

🎯 考點: 移交之後收益的主責屬於運營或接收方,專案集只提供支援;專案集不應無限延續成運營單位。

§82 協同原則細講:三種實踐協同,價值更大 (02:20:32)

核心: 協同指持續評估和協調元件的複雜性與依賴關係,以優化整個專案集,創造比單一元件更多的價值;重點是專案組合、專案集、專案三種實踐之間的協同。

• 協同需要兩手:軟的是領導力,硬的是管理技能
• 要分工、各有側重,要結構化
• 推動元件變更:組合或專案集底下的元件要跟著要做的事調整,不要固守原計劃;環境變了,計劃就可以跟著改
• 培養文化基礎(又提到勝則舉杯相慶,敗則拼死相救),同時要和複雜性配合

講師原話:「協同指的是持續評估和協調元件複雜性和依賴關係,以優化整個專案集,創造比單個元件所能實現的更多的價值。」

§83 Blues 比喻;組合管理三動作:選擇、排序、分配資源 (02:22:24)

核心: 協同就像 Blues:不規定每個環節奏什麼音,可以自由發揮、變長變短,但節奏不能亂;專案組合管理的三個代表動作依序是篩選、排優先順序、分配資源,順序不能顛倒。

• 先篩選出符合組織戰略的,淘汰不符合的;再排優先順序;優先順序最高的優先取得資源
• 專案組合的「能力和容量」講的就是資源:人力、物資、財務
• 講師說中文翻譯不準,capacity 和 capability 在中文很難找到完全對應的詞

講師原話:「第一個叫選擇,第二個叫排優先順序,第三個叫分配資源,他們有邏輯關係,是不能夠顛倒的。」

PMI 術語: Selection / Prioritization / Resource Allocation ↔ 選擇/排序/分配資源 / Capacity ↔ 容量 / Capability ↔ 能力

🎯 考點: 組合層級的動作順序是:篩選(對齊戰略)→ 排優先順序 → 分配資源。

§84 協同是全方位的:資源、戰略收益、風險複雜性、干係人 (02:25:17)

核心: 協同要從組合層面開始,發展多個專案集之間的共享能力;另外還要和戰略收益、風險複雜性、干係人做好協同。

• 共享能力可能原本不存在,要靠組合管理來建立;建立後組織整體能力提升,成本降低、品質提高、合規增強
• 戰略與收益:收益一定要在戰略一致的前提下完成;把和同一個或多個戰略目標相關的收益合併處理,資源效率會更好
• 風險與複雜性:危機中有機會,利用複雜結構和關係帶來的機會。真人 CS 例子:對方有人槍出問題、換彈匣時,隊友一個找位置、其他人射擊,高度協同的團隊才抓得住這種機會
• 干係人:人際關係好、互相認同度高,也容易產生協同效果
• 協同可以是主動的,也可以是被動的:專案集在組合裡被調動時,主動參與協同,對自己也有好處

講師原話:「協同一定是多方向的,是全方位的。」

§85 Capacity 和 Capability 的差別 (02:28:10)

核心: Capacity 是組織資源的上限(最大量),capability 是單一資源的具體能力;每個資源都很強,不代表組織整體能力最好。

• 一頭獅子帶領一群綿羊,可能比一群獅子戰鬥力更強;全是大牛的組織,未必配合得起來
• Capacity 不只是一個客觀數字,它由流程、人員能力等因素共同決定
• 講師會把圖上組合管理、專案集管理各自「管什麼」的三個詞挖空,讓學員自己補

講師原話:「capacity 說的是我們資源的上限……capability 可能講的就是我們單一資源的具體能力。」

§86 團隊之團隊細講:適應性、韌性、反脆弱性 (02:29:18)

核心: 團隊之團隊要跨產品、跨流程建立關係,形成垂直和水平都有連線的網路,讓組織更有適應性和韌性。

• 適應性(adaptability):專案集層面可能感知不到第一線的變化,把權力交給第一線去應對,組織就能跟著環境調整;等消息傳到專案集,可能已經太晚
• 韌性(resilience):受到外界打擊後,迅速回到原來狀態的能力
• 反脆弱性(antifragility):受到打擊後反而比原來更強(肌肉撕裂後長得更壯、堅持深度閱讀讓腦袋更靈活);團隊做到反脆弱的機率不高
• 團隊之團隊的結構是組織治理系統的關鍵,要有意識地建立多層級、協同的團隊

講師原話:「適應性是跟著改變,韌性是回彈到原來的水平。」

PMI 術語: Adaptability ↔ 適應性 / Resilience ↔ 韌性 / Antifragility ↔ 反脆弱性

§87 考試反射:專案集經理不插手專案內部,跨專案的事由專案集協調 (02:32:13)

核心: 跨專案的問題必須由專案集協調;專案內部、不涉及其他專案、又在授權範圍內的工作,交給專案經理處理。

• 專案集經理要拿捏分寸,不插手專案裡的事;但跨專案的事不找專案集也不行
• 要事先建立這套規則和團隊結構,形成網路化協作(networked collaboration)

講師原話:「跨專案的問題必須由專案集來協調;專案內部的工作不涉及到其他的專案,同時也在你的授權範圍內,交給專案經理處理。」

🎯 考點: 題目情境是單一專案內部的問題,專案集經理不應直接接手,而是讓專案經理在授權範圍內處理;牽涉多個元件的依賴或衝突,才由專案集經理協調。

§88 構建高效團隊:WBS、RAM、效率與效果、團隊規模 (02:34:11)

核心: 先用 WBS 把工作理清楚,再用責任分配矩陣(RAM)或 RACI 把責任分清楚;還要兼顧效率和效果,控制團隊規模。

• RAM 是根據 WBS,把工作包和控制帳戶分配給負責人
• 效率衡量的是量(單位時間處理多少),效果衡量的是質(達到的水準)
• 敏捷團隊的 7±2 原則:最多不超過 9 人,最少不少於 5 人
• 大型專案集的協作不受這個限制,但要在合理範圍內;如果團隊有幾百人,就要拆成多個小團隊,專案集經理只管各團隊的負責人
• 講師說這部分了解即可

講師原話:「量衡量的是效率,質衡量的是效果。」

PMI 術語: RAM (Responsibility Assignment Matrix) ↔ 責任分配矩陣 / RACI ↔ RACI 矩陣

§89 變更原則細講:戰略適應性、擁抱變更 (02:35:55)

核心: 抓住「戰略適應性變化」這一條就夠了:專案集對變更的態度是擁抱,前提是變更對收益有價值。

• 有效管理變更,對專案集生命週期內、以及移交運營後的收益實現、交付和維持,都非常關鍵
• 變更避免不了,能調整的是面對變更的方式;要識別變更來源(外部或內部),不同來源的應對策略不同,但目標一致
• 變更的終極動機是確保達成目標:對目標有利的就主動追求;不利的就主動迴避,或消除產生變更的原因
• 專案集比專案更能接受、適應變更;專案則專注於控制變更

講師原話:「有利於目標實現的我們主動求變,不利於目標實現的我們主動的去迴避或者消除它產生的原因。」

🎯 考點: 專案集是適應、擁抱變更;專案是控制變更。

§90 專案集層級和元件層級的變更差別,以及核准層級 (02:37:26)

核心: 專案集層級的變更通常是戰略性的,顆粒度是「元件」(新增或終止一個元件),要到指導委員會核准;元件層級的變更是戰術性的(範圍、進度、成本),專案經理和 CCB 就能決定。

• 專案集層級不是小打小鬧地加一點範圍、改一點進度
• 專案集層級的變更也會涉及收益,但最主要的是元件級別的增減
• 新增或減少元件要由指導委員會核准(也叫治理委員會、治理主體)
• 變更四要素:定義(含提出變更申請)、分析、交付(執行)、收尾。講師說了解即可,和 PMBOK 不同
• 變更仍然要有流程,但不像專案管理那樣強調程序細節;只要有利就推動;要培養主動擁抱變更的文化,放開範圍限制

講師原話:「專案集層面的變更的顆粒度通常是元件這個顆粒度,也就是說它的變更要麼是增加一個元件,要麼是終止一個元件。」

PMI 術語: Steering Committee / Program Governance Board ↔ 指導委員會/治理委員會 / CCB (Change Control Board) ↔ 變更控制委員會

🎯 考點: 增減元件,要提交治理委員會(指導委員會)決策;元件內部的範圍、進度、成本變更,由專案經理和 CCB 處理,不需升級到專案集。

§91 交付階段的變更類型:新增、取消、終止、修改元件 (02:39:51)

核心: 專案集交付階段的變更通常是新增、取消、終止或修改元件;最典型的是糾正措施,通常表現為元件的增減或重置。

• 變更來自環境和條件改變,實際情況和原計劃不同了
• 專案集層面的變更需求包括糾正措施、預防措施、更新;專案層面常見的缺陷補救不屬於這一類
• 取消(cancel)和終止(terminate)意思相近;新增指原本沒有的元件;另外還有修改(modify)

講師原話:「專案集交付階段出現的糾正措施,往往體現為對元件層面的增加、減少或者是重置。」

PMI 術語: Add / Cancel / Terminate / Modify component ↔ 新增/取消/終止/修改元件 / Corrective Action ↔ 糾正措施

§92 領導力原則細講:激勵人,保持政治敏銳度 (02:40:50)

核心: 領導力的核心是激勵人,對象是人;管理的對象主要是事。領導力靠激勵團隊把事情完成。

• 政治敏銳度(political awareness):指對政策、環境和影響力變化的敏感,不是黨派政治
• 有人升官,影響力變大;有人被降職或解職,權力就變了,有些事最好別再找他,找了也沒用,還會尷尬
• 專案集經理要洞察哪些人對專案集目標的影響力正在變強或變弱
• 其他要素:協作精神、促成事情的精神等

講師原話:「他不是說我們說的玩的那個黨派的政治,說的是政策環境影響力的改變,你要敏銳的感覺到。」

PMI 術語: Political Awareness ↔ 政治敏銳度

⚠ 辨識備註: 02:41:23-02:41:54、02:41:58-02:42:27 這兩段逐字稿有缺口,講師對管理與領導對比的內容不完整。

§93 垂直與水平管理;授權元件經理 (02:43:35)

核心: 專案集經理要做好向上、向下和橫向管理,在垂直和水平方向都取得支持;最重要的是授權元件經理,讓他們在授權範圍內領導自己的團隊。

• 向上是對領導和管理層,向下是對下屬和執行層,橫向是對同級的職能部門
• 標準傾向於把較多權力授予元件經理,這樣既展現領導力,也讓適應性和韌性更強;什麼事都自己決定,反而可能出大問題
• 不要代替元件經理去領導他的團隊
• 講師強調是標準原文:專案集經理對元件專案的干預越少,領導效果越好,元件團隊的士氣越高

講師原話:「專案集經理對組件專案的干預越少,領導效果就越好,組件專案的士氣就越高,這句話不是我寫的,是標準裡有的。」

🎯 考點: 選項出現「專案集經理直接介入、接管元件團隊」時,通常是錯的;正確方向是授權並支援元件經理。

§94 人際能力、認知智能與信任 (02:45:14)

核心: 領導力需要人際能力,包括情感感知、情商、社交能力和認知智能;領導力最基礎的是信任,而沒有透明就沒有信任。

• 認知智能(cognitive intelligence)和情商很像,但不一樣:感知對方情緒、理解人與人之間的社會關係、認知人與事物之間的關聯
• 信任可以有不同層次:對人格的信任(做事可靠)、對認知的信任(認知水準高)、對制度的信任(規則定了沒人敢破壞)
• PMI 人才三角(Talent Triangle)把領導力升格為「影響力技能」:影響他人,而不是強迫他人

講師原話:「沒有透明沒有信任,沒有信任沒有領導力。」

PMI 術語: Cognitive Intelligence ↔ 認知智能(逐字稿誤作 recognition intelligence) / Talent Triangle ↔ 人才三角 / Power Skills ↔ 影響力技能

§95 風險原則細講:風險是中性的,複雜性帶來不確定性 (02:46:45)

核心: 風險是中性的,包括機會(正面)和威脅(負面),泛指一旦發生會對專案集目標產生正面或負面影響的不確定事件或條件;專案集經理要平衡威脅與機會、風險與收益。

• 專案集目標可能不只一個
• 專案集複雜度高,複雜性引發風險的可能也越高;看不清、不了解的事,對你來說就是不確定的
• 複雜性和不確定性關聯極高,也和模糊性、波動性有關
• 要主動管理風險

講師原話:「你不了解的事情對你來講就是不確定性的事件,所以複雜性和不確定性之間關聯度極高。」

PMI 術語: Opportunity ↔ 機會 / Threat ↔ 威脅 / Uncertainty ↔ 不確定性 / Ambiguity ↔ 模糊性

§96 風險、問題、變更請求互相轉化;機會變現 (02:47:50)

核心: 風險(risk)、問題(issue)、變更請求(CR)會互相轉化:威脅發生了就成為問題;機會被抓住了會轉成收益,這叫 capitalize(變現)。

• 常聽到的「風險發生了叫問題」不完整,要修正為「威脅發生了叫問題」
• 問題是已經存在的;風險可能發生,也可能不發生
• 機會發生並被抓住後轉為收益(效益和收益統一譯為收益),這個過程叫 capitalize
• 問題處理不好,會引發新的風險,也可能走流程變成變更
• 執行風險應對措施時,往往要先提變更請求,所以風險也是變更的來源
• 變更會改變原計劃,帶來新的不確定性,也就是新的風險

講師原話:「問題、風險、變更之間是互相轉化的……機會被我們抓住了就發生了,它會轉化為收益,這個過程專門有一個詞叫 capitalize。」

PMI 術語: Issue ↔ 問題 / Change Request (CR) ↔ 變更請求 / Capitalize ↔ 變現(把握機會)

🎯 考點: 威脅發生了叫 issue,機會實現後轉成收益;執行風險應對時,往往要先提 CR。

§97 風險管理核心要素:閾值、全生命週期、對標、依賴關係 (02:52:12)

核心: 要建立風險閾值,把主觀的偏好轉成大家認同的觸發值;在整個生命週期持續識別和評估風險;用 benchmarking 參考最佳實踐;依賴關係是專案集風險的重要來源。

• 碰到閾值就觸發行動,對應風險管理裡的觸發因素(trigger)
• 風險意識要貫穿整個生命週期
• 對標管理(benchmarking):借鑑過去和業界的最佳實踐,講師說這是新出現的概念
• 依賴關係會放大效果:識別清楚的話,一分力能透過專案集這個複雜系統放大成十倍收益;但問題或危機也會被成倍放大
• 依賴關係管理是專案集管理的關鍵主題;分析收益依賴關係,能成為管理複雜工作的抓手:不再靠 WBS,而是靠收益分解結構來構建專案集
• 主動應對樂觀偏見:不要過度樂觀,也不要過度悲觀

講師原話:「依賴關係它是風險來源的重要源頭……它會成倍的放大我的負面效應。」

PMI 術語: Benchmarking ↔ 對標 / Trigger ↔ 觸發因素 / Benefits Breakdown Structure ↔ 收益分解結構 / Optimism Bias ↔ 樂觀偏見

⚠ 新版變化: 講師說 benchmarking 在風險管理中是新出現的概念。

§98 專案集風險一定影響收益;收尾時移交未關閉的風險 (02:54:59)

核心: 專案集風險一定會影響收益的實現,不影響收益的不確定性就和專案集無關;專案集結束時還沒關閉的風險,要告知並移交給接收組織。

• 移交後,運營層面的風險不由專案集經理處理,所以要把風險從專案集風險登記冊轉到接收組織的適當層級
• 收尾有幾種移交,風險移交是其中之一,另外還有資料移交、資源釋放等,後面再講
• 概念邏輯:主觀偏好(appetite)→ 識別出承受力(tolerance,最大值)→ 設定合理的閾值(threshold)→ 依閾值決定應對策略

講師原話:「專案集的風險一定會對收益帶來影響。」

PMI 術語: Risk Tolerance ↔ 風險承受力 / Risk Register ↔ 風險登記冊

🎯 考點: 專案集收尾時,把仍處於 open 狀態的風險移交給接收組織(運營),而且要記錄並告知對方。

§99 治理原則細講:建立機制,為收益保駕護航 (02:57:00)

核心: 治理強調建立決策、分工、監督、控制的機制和框架,不是寫鉅細靡遺的操作手冊;它是手段,目的是保障收益的實現和移交。

• 特點:透明、監督、掌控、合規、彈性;講師認為 resilience 翻成「韌性」比「彈性」更傳神。治理不能全是剛性要求,要隨環境和要求調整
• 治理貫穿整個專案集生命週期:講師回顧上午的圖,上面有兩條橫線,其中一條是組織治理和專案集治理,橫跨整個生命週期
• 啟動時核准資金、授權;過程中做和戰略對齊的評審、評價,都屬於治理
• 管理要在治理框架內進行;越過界線,就會有人叫停或來決定批不批准

講師原話:「這裡的焦點主要是為了保障收益的實現和移交,給它保駕護航用的,它是手段。」

§100 治理機構:專案集治理委員會與授權 (02:59:19)

核心: 治理要靠組織結構落實,最典型的是專案集治理委員會(Program Governance Board);專案集經理和元件經理也是治理的一環,各有自己的決策範圍。

• 專案集經理授權給元件經理,這同時體現了領導力原則、團隊之團隊原則,也體現監督控制
• 治理透過評審和決策小組(panel / committee)執行;西方多採委員會制,舉手投票,可以用多數決、獨裁或相對多數

講師原話:「Program Governance Board,它就是最典型的治理機構。」

PMI 術語: Program Governance Board / Program Steering Committee ↔ 專案集治理委員會/指導委員會

§101 專案集也要遵循治理;頂層監管與升級機制 (03:00:31)

核心: 除了治理委員會,專案集本身也是治理的一部分,要和治理主體協作,並確保專案集團隊遵循治理規則;要做到頂層監管(oversight),明訂哪些問題必須升級。

• 授權下去,但最終的「按鈕」要握在手裡;完全放掉就是失控
• 中國體制的例子:災害或事故傷亡超過一定人數,必須上報中央決策,平時可以不干預
• 問題或擔憂(concern)升級時,通常由監管或治理框架來解決;不只是問題,變更和風險也一樣
• 治理是處理重要、升級或高優先問題的平台和管道;超過專案集經理權限怎麼走、超過治理委員會權限又怎麼走,都要規定清楚

講師原話:「你手裡得有那麼一根線,最終的那個按鈕得在你手裡;如果完全都給下去了,完全就失控。」

PMI 術語: Oversight ↔ 監督/頂層監管 / Escalation ↔ 升級

🎯 考點: 超出專案集經理權限的問題、風險或變更,依治理框架定好的路徑升級到治理委員會,不要自己越權決定。

§102 治理是手段不是目的;八大原則小結,下一段是績效域 (03:02:37)

核心: 治理通常表現為決策框架、決策功能,並依靠流程和工具完成監督、管理和支援;它是實現組織戰略和運營目標的手段,不是目的。

• 分級邏輯:下一級向上一級升級問題、匯報;上一級向下一級做評審、決策
• 講師總結:八大原則對考試的重要程度不是特別高,理解核心思想、把觀念納入自己的思考角度就夠了
• 第 5 版把原本 8 個章節併成 4 個,很多內容都併進第 3 章;第 3 章的專案集管理績效域有具體的活動和文件,是整份標準最有代表性的內容

講師原話:「原則相對來說是比較偏虛的……考試也不太容易考察到,大家重點是理解他的一些思路和原則。」

⚠ 新版變化: Standard 5th 從原本 8 章濃縮為 4 章,績效域內容集中在第 3 章,這是本版內容最多、最重要的一章。

Part C (03:04:33 - 04:39:44) 綜述

這段從 Standard 5th 第三章「專案集管理績效域(Program Management Performance Domains)」開講。講師先交代結構變化:第四版 3.3–3.8 是各自獨立的章,第五版全收進第三章,並新增 3.7 協作(Collaboration),五大績效域變成六大。接著他講自己怎麼理解績效域:這是面對複雜、強依賴工作時的六個「入手方向」,彼此互相影響。六域裡最能代表專案集的是戰略一致性、收益管理、治理框架三個。他逐一講了六域的精神:收益要最大化,可以突破範圍;干係人「爭取」和「參與」是同一件事的兩個角度。協作他認為放在績效域裡有點牽強,下一版可能併回原則 Synergy。

後半段(約 03:32 起)深入戰略一致性。核心結構是「三個文件(商業論證、章程、專案集管理計劃)加兩個動作(環境評估、確定風險管理策略)」;組織戰略計劃算作第四個文件,但它在專案集外部。他用流程圖串起來:組織戰略計劃 → 商業論證 → 專案組合評審 → 章程 → 規劃 → 交付階段啟動元件。

最重要的判準: 1. 商業論證被 approve,只代表預留投資;章程是 authorize,這時才真正給權、給資源,專案集經理也從這裡登場。 2. 商業論證連接「組織戰略目標」和「專案集目標」;路線圖連接「組織戰略」和「專案集活動」。 3. 路線圖在 5th 不再是獨立文件,併入專案集管理計劃。關鍵字 chronological / graphical;早期只有里程碑和決策點,沒有元件。 4. 環境分析有五個工具,其中 SWOT 最全面(comprehensive)。 5. 風險管理策略在構建子階段確定,內容是閾值、初始專案集風險評估、應對策略,而且它驅動(drive)後續的風險管理活動,兩者不是同一件事。

§103 第三章結構:五大變六大績效域 (03:04:33)

核心: 第五版把各績效域收進同一章(第三章),新增 3.7 協作,五大變六大。

• 第四版 3.3–3.8 是獨立章節,第五版全劃進第三章
• 新增 3.7 協作(Collaboration),原本五個績效域變成六個
• 前面 3.1、3.2 是背景介紹。講師說書上「也沒講明白」,現實中也不容易講明白
• 理論上很難把各域講清楚,但在實際專案集運作中,各域之間的緊密交叉是看得到的

PMI 術語: Performance Domain ↔ 績效域 / Collaboration ↔ 協作

⚠ 新版變化: 4th 是五大績效域且各自成章;5th 是六大績效域(+協作),合併在第三章。

§104 績效域的本質:管理複雜工作的入手方向 (03:05:33)

核心: 績效域就是「管理複雜、強依賴工作時要從哪幾個方向下手」,六個域之間彼此影響。

• 專案集是一種面向複雜、有強烈內在依賴關係工作的管理模式,和單專案管理、專案組合管理都不同
• 績效域告訴你:這類複雜又互相關聯的工作要有一套方法,得從這六個方向入手才管得住
• 例:戰略一致性影響所有其他域,其他域反過來也會影響它;每個域都影響另外五個
• 講師認為專案集管理標準最大的貢獻,就是給出一套面對複雜工作的管理方法和模式

§105 三大專案集方法論比較:PMI / MSP / ISO 21503 (03:07:07)

核心: PMI 不是唯一的專案集體系,但講師認為 PMI 最清晰、最好理解。

• 其他體系:英國的 MSP(PeopleCert / AXELOS 系列),以及 ISO 21503(專案集管理標準)
• 三者本質一樣。講師認為 PMI 和 MSP 最好,ISO 的相當不完整
• ISO 標準要求高度簡明,不屬於知識體系類,內在關係和邏輯性不強
• MSP 相對複雜、輪廓不明顯;PMI 講得最清楚
• 績效域可以當成「面對複雜工作的一套管理方法論」,目的是讓專案集經理抓住重點

PMI 術語: MSP (Managing Successful Programmes) / ISO 21503

§106 協作域的定位:可能併回原則 Synergy (03:08:17)

核心: 協作更像撐在底層的團隊/組織文化。講師認為把它列成第六個績效域有點牽強,下一版可能併入八大原則的 Synergy。

• 協作是底層支撐整個運作的管理思想,也就是提倡的團隊文化或組織文化
• 從書寫內容可以看出,這部分寫得很吃力,沒寫出太多有價值的東西
• 原則中的 Synergy(協同)講的是管理模式之間要配合,是「事」
• 3.7 協作講的是人與人、組織與組織之間要配合,是「人」
• 兩者不同但本質類同,所以下一版很可能併回八大原則

PMI 術語: Synergy ↔ 協同(原則) / Collaboration ↔ 協作(績效域)

§107 最本質的五域與最具代表性的三域 (03:09:49)

核心: 最本質的五個域是戰略一致性、收益管理、干係人參與/爭取、治理框架(3.6)、生命週期管理(3.8);其中戰略一致性、收益管理、治理框架最能代表專案集。

• 干係人 engagement 有人翻「參與」,有人翻「爭取」。講師兩個都用,理由見 §10
• 新舊版都一樣:戰略一致性、收益管理、治理框架是專案集「極具代表性」的三域
• 其餘幾個域在專案管理、專案組合管理裡也大致類似,只是執行層面不同

🎯 考點: 題目要問「專案集特有/最具代表性」的領域時,優先想到戰略一致性、收益管理、治理。

§108 戰略一致性:定義與兩層意思 (03:11:02)

核心: 戰略一致性 = 識別專案集的輸出和成果,提供與組織戰略目標一致的收益。實際含義是「隨時盯住組織戰略方向,不偏離」。

• 每個績效域底下有許多相互搭配的功能(function)
• 第一層意思:專案集經理做事時要隨時關注組織的戰略方向,確保工作不偏離
• 第二層意思:專案集往下還有元件,在專案集內部(對元件)也要做到戰略一致
• 手段集中在幾份文件:專案集商業論證、專案集章程、專案集管理計劃。透過不斷調整對齊,指導後續工作

PMI 術語: Strategic Alignment ↔ 戰略一致性 / Program Business Case ↔ 專案集商業論證 / Program Charter ↔ 專案集章程 / Program Management Plan ↔ 專案集管理計劃

§109 收益管理:追求最大化,可突破範圍 (03:12:42)

核心: 在戰略一致的前提下,專案集收益的「最佳化」追求的是最大化,不是剛好達標;而且收益要交給接收方延續下去。

• 流程:識別、定義專案集能帶給組織的貢獻 → 找出實現路徑 → 執行 → 持續最佳化
• 標準用的動詞:定義、建立、最佳化、交付、維持(define / create / maximize / deliver / sustain)
• 專案的「最佳化」是剛好滿足目標、耗用資源最少;專案集的最佳化還包括更高要求:可以突破範圍、超過目標
• 只要對組織貢獻越大就可以做,不用管範圍邊界在哪,前提是不違背戰略一致性
• 專案集結束後要把收益移交給接收方,讓對方能接手,並把收益和創造收益的方式繼續發揚光大(sustain)

🎯 考點: 專案集收益「最佳化」= 最大化,可以超出原範圍和目標;專案層面的最佳化才是剛好滿足目標。

§110 戰略一致與收益管理:北極星與路徑 (03:15:03)

核心: 戰略一致性是永遠不動的北極星(錨點);收益管理則是路徑可以靈活,只要最後達成目標。

• 這兩域的關係比其他域之間都緊密
• 戰略一致:永遠不能偏離的錨定點
• 收益管理:繞路、直走、東看西看都可以,只要達成最終目標、不浪費資源、最大化利用資源

§111 治理框架:決策機制,5th 新增「框架」二字 (03:15:39)

核心: 治理框架 = 定原則、分角色、定決策點和關口的高效決策機制。專案集經理要花大量時間把它建出來。

• 涵蓋:做事的規則和原則、權力分配、決策時間點、決策場合、決策分工
• 專案集內外部環境都更複雜、動態、不確定、模糊(VUCA,現在甚至說 BANI:脆弱、難以理解、非線性)
• 外部的動態性再加上專案集本身的複雜度,特別需要高效又有效的治理機制
• 治理和管理的分工:治理「定原則、定角色、定時間點、定關口」,管理是在這個框架下運作,把治理原則落地
• 治理最核心的事情是做決策:分好工讓大家各司其職,關鍵時刻能把重要決策做出來

PMI 術語: Governance Framework ↔ 治理框架 / VUCA / BANI

⚠ 新版變化: 4th 這個域叫「治理(Program Governance)」,沒有「框架」。5th 改成 Governance Framework,講師認為是強調專案集經理要著力「構建」整套機制。

§112 干係人爭取 vs 參與:主格與賓格 (03:19:05)

核心: engagement 站在專案集經理的角度是「爭取」(主動),站在干係人的角度是「參與度」(結果)。兩個詞都對,重點是爭取支持,不是管理他們。

• 專案集經理和管理團隊要花很多心力,想方設法爭取干係人支持專案集活動,這是主動性
• 干係人表現出來的參與度,就是專案集經理爭取工作的結果。干係人沒參與進來,代表爭取沒做到位
• 「要求他做」是管理,「請他幫你做」是爭取,後者更容易有結果
• 和專案的干係人爭取本質一樣,差別在層面:對象級別更高、權力和影響力更大、利益更複雜
• 高層、投資方、客戶意見多,任何一方沒滿足,後果都很嚴重

講師原話:「如果站在我們自身,那我更加強調說我們要主動去爭取;如果我想看待別人是不是真的被我爭取到了,那我要看他的參與度。」

PMI 術語: Stakeholder Engagement ↔ 干係人參與/爭取

§113 生命週期管理與協作 (03:22:02)

核心: 生命週期把專案集切成階段來降低難度、看清節奏;協作強調跨干係人的人際協作文化,目的是產生協同效應。

• 生命週期的作用:一是切段簡化、降低難度;二是看清節奏(開始做什麼、中間做什麼、最後做什麼)
• 協作(collaboration)針對的是「人」:建立協作文化,和各方搞好關係
• 協同效應:步調匹配,一邊剛結束另一邊就接手。從事的角度叫協同,從人的角度就要提前告知對方、讓對方提前參與

PMI 術語: Program Life Cycle Management ↔ 專案集生命週期管理

§114 六域交織:以商業論證為例 (03:23:40)

核心: 任何一個活動(例如制定商業論證)都同時牽涉六個域。各域之間的互動沒辦法用語言精準描述。

• 制定商業論證(business case):核心是組織戰略在專案集中有沒有體現 → 戰略一致
• 要論證投資的合理性和可行性 → 收益
• 結果要向高層彙報,讓他們認同、參與決策 → 干係人
• 商業論證最終要被批准 → 治理
• 在專案集定義階段的構建子階段做 → 生命週期
• 以上各方都要配合起來 → 協作
• 決策方式可以是投票、獨裁、各司其職、分層、集權或分權,都屬於治理的範疇

§115 講師體會:專案集是複雜系統,收益需要業務經驗 (03:25:38)

核心: 標準不保證成功,但提供了一套方法:每個活動都要用六個維度思考。專案集本身是複雜系統,每個績效域又是更小的複雜系統。

• 抓住六個方向就能把複雜工作做得不錯,沒考慮到就可能做不好
• 專案集是 complex system,每個績效域是更小的複雜系統;這還只是管理模式的複雜,業務本身也複雜
• 業務複雜度最明顯的地方在收益之間的依賴關係,有可能理不清,看到的也可能不是本質
• 所以專案集經理需要豐富的業務經驗。沒有業務經驗,收益管理不可能做好
• 標準沒有精準地說「A 影響 B、B 影響 C」,籠統理解互動關係就好

講師原話:「沒有業務經驗,收益管理你不可能做得很好,你都不知道這個組織想要的東西是什麼以及怎麼實現的。」

PMI 術語: Complex System ↔ 複雜系統

§116 六域是「高階組織功能」,適用任何規模和行業 (03:27:33)

核心: 標準把六個績效域定位為高階組織功能,無論組織規模、行業或地理位置,都可以從這六個方面管理複雜工作。

• 講師認為這句話是在「拔高」專案集的定位。相對專案管理它確實是高階功能,但公司層面的高階功能通常指戰略管理、企業發展、薪酬激勵、股東權益、董事會和高管制度等
• 理解成「高於專案管理、以更高維度管理複雜工作」即可
• PMI 把這類複雜工作命名為 program(專案集)

PMI 術語: Organizational Function ↔ 組織功能

§117 專案集 = 強依賴;因果關係要慎用 (03:28:57)

核心: 專案集內部的工作必須有強烈的依賴關係或相互影響關係才算專案集。「因果關係」這個詞要慎用。

• 必須有依賴關係(相互影響),才稱得上專案集
• 很多事其實不是因果,只是沒深究就用因果概括了
• 講師延伸提醒:常說「因為…所以…」的人可能在影響你的判斷,他講的因果未必真實,或不是全部原因
• 事情越複雜,越難說清楚因果

§118 不在專案集或專案組合之下時要考慮更廣 (03:31:04)

核心: 專案不在專案集或專案組合之下時,專案經理要考慮更廣泛的領域功能(績效域)。專案集不在專案組合之下時也一樣,要直接放在組織整體的管理模式裡考慮。

• domain 也可以翻成「領域」
• 專案集如果不在專案組合之下,就直接處在組織的管理模式之內,要特別注意這種情況

§119 戰略一致性:三個文件加兩個動作 (03:32:02)

核心: 戰略一致性在考試中佔比高,但容易理解。抓住「三個文件(商業論證、章程、專案集管理計劃)+ 兩個動作(環境評估、確定風險管理策略)」就行。

• 目標:專案集從開始到結束的所有工作都要滿足戰略要求、不偏離
• 抓住三個文件的制定過程,加上了解環境,以及面對不確定環境時採取的策略,基本上就能做好戰略一致性

PMI 術語: Environmental Assessment ↔ 環境評估 / Program Risk Management Strategy ↔ 專案集風險管理策略

🎯 考點: 戰略一致性的五要素 = 商業論證、專案集章程、專案集管理計劃、環境評估、風險管理策略。

§120 前提:組織戰略要明確(外部輸入) (03:32:52)

核心: 專案集管理的前提是組織戰略已經明確。組織戰略計劃是專案集外部的輸入。

• 戰略不明確時,專案集方法論不適用,因為它不負責決定組織戰略方向
• 它是「組織戰略方向確定之後,怎麼把它做下去」的方法
• 專案集內部是三個文件加兩個動作;外部輸入是組織的戰略計劃(圖左下角)

§121 商業論證的核心:成本收益分析與戰略性投入 (03:33:49)

核心: 商業論證是要論證「值不值得做」,最重要的內容是成本收益分析。但值得做不一定是收益大於成本,也可能是戰略性投入。

• 這時候還不一定算 program,只是組織的一項舉措,為了方便描述才叫「專案集商業論證」
• 值得做的情況一:收益高於成本
• 值得做的情況二:成本高於收益,但有戰略屬性(例如奠定未來 3–5 年格局,可以接受連虧三年)
• 追求短期收益的商業組織看重財務收益;有遠見的公司會提前投入
• 論證可行性、合理性、成本收益時,都要隨時檢查是否和組織戰略方向一致,這是不可突破的原則

講師原話:「成本收益分析是最基礎的,你要把它算清楚。」

§122 環境評估:看外部,不只看自家 (03:36:03)

核心: 做論證不能只看自己,還要看競爭對手、市場需求和大趨勢。這就是環境評估。

• 例:消費觀念改變、油車需求下降,再大量投入油車可能就不適合環境(除非有情懷)
• 要評估有哪些機會、哪些威脅,過去的成功經驗和做不好的地方,並做比較分析
• 這部分有五個工具(可行性分析等,見 §49)

§123 考法:不考歸屬,考「從戰略傳遞到構建」 (03:37:23)

核心: 考試不會單純問「專案集管理計劃屬不屬於戰略一致性」。戰略一致性主要處理的是:組織戰略計劃怎麼經過構建子階段,傳遞到專案集。

• 構建(Formulation)等同於啟動(Initiation),意思一樣
• 第二、三版時構建子階段就叫啟動階段,主要工作是制定目標
• 構建階段的活動,其實就是戰略一致性的早期活動

PMI 術語: Program Formulation ↔ 專案集構建(子階段) / Initiation ↔ 啟動

§124 戰略一致性的目的:輸出、成果支撐收益 (03:38:56)

核心: 「識別專案集的輸出和成果」指的是元件(專案)的輸出和成果,它們支撐專案集收益的實現,最後提供與組織戰略目標一致的收益。

• 講師認為更準確的說法是「識別專案集將來要交付給組織的收益」
• 輸出和成果是專案產生的,所以專案集要盯住專案
• 專案集最終關注的是收益,但收益不能憑空產生
• 目的:和組織戰略保持一致,促進收益實現(講師補充:最大化、可持續)
• 方向偏了,做出來的東西就不是組織想要的

PMI 術語: Outputs ↔ 輸出 / Outcomes ↔ 成果 / Benefits ↔ 收益

§125 五要素圖與定義階段的兩個子階段 (03:40:27)

核心: 定義階段 = 構建子階段 + 規劃子階段。商業論證和章程是構建子階段的產物,專案集管理計劃是規劃子階段的產物。

• 圖和第四版不同,但核心邏輯沒變
• 構建子階段(Formulation)→ 規劃子階段(Planning),兩者合起來是專案集定義階段(Program Definition)
• 三個文件是輸出,兩個動作是為了保證文件的制定過程

PMI 術語: Program Definition Phase ↔ 專案集定義階段 / Program Planning ↔ 規劃子階段

⚠ 新版變化: 戰略一致性要素圖的樣子和 4th 不同,但核心邏輯不變。

🎯 考點: 商業論證、章程出自構建子階段;專案集管理計劃出自規劃子階段。

§126 風險管理「策略」不是風險管理「活動」 (03:41:47)

核心: 戰略一致性裡的要素是「確定風險管理策略」,不是執行風險管理活動。重點是搞清楚組織和關鍵干係人的風險偏好。

• 具體的風險管理活動(規劃風險管理、定性和定量分析等)發生在規劃和交付階段
• 這裡定的是策略,不是具體的風險管理行為
• 專案集經理這時要花大量精力,了解組織、發起人和高階管理層對這個專案集在風險上的期望值,也就是風險偏好
• 例:外部監管變嚴格就會產生風險,沒有應對策略,就實現不了商業論證裡 5000 萬的收入目標

PMI 術語: Risk Appetite ↔ 風險偏好

§127 三個文件還是四個?組織戰略計劃在專案集之外 (03:43:49)

核心: 加上組織戰略計劃就是四個文件。但組織戰略計劃在專案集外部(outside),不是專案集經理制定的,也不在專案集生命週期內產生。

• 「三個文件 + 兩個動作」和「四個文件 + 兩個動作」都對
• 組織戰略計劃很特別:它在專案集生命週期之前,由組織制定
• 這張圖是戰略一致性一章的總體結構,要牢牢記住

講師原話:「以下哪個檔案不是在專案集生命週期當中產生的?那就是它了。」

🎯 考點: 問「哪個文件不是在專案集生命週期內產生的」,答案選組織戰略計劃。

§128 總體流程:戰略計劃 → 商業論證 → 專案組合評審 → 章程 (03:45:11)

核心: 商業論證是為了讓專案集獲得批准而提交的材料,用來說服管理層投資。投資決策透過專案組合評審做出,評審通過後組織才投錢、投人。

• 位置:戰略計劃在組織層面 → 商業論證 → 章程 → 管理計劃
• 商業論證內含論證過程、各種資料分析和可能性
• 組織決定投資之後才有專案集章程。決定之前都只是論證
• 決策行為是專案組合評審(portfolio review)

PMI 術語: Portfolio Review ↔ 專案組合評審

§129 approve 對 authorize:商業論證被批准,章程才授權 (03:46:41)

核心: 商業論證用 approve(批准),代表管理層認同論證的結論;章程用 authorize(授權),這時才真正給權利和資源。

• approve:「你論證得不錯,我同意做這件事」。但只批准了論證,不代表可以啟動
• authorize:把權利交給你,讓你有權動用組織資源
• 商業論證只說明需要哪些資源,組織同意了但還沒交到你手上,你調不動
• 中文翻譯常把兩個都譯成「批准」,做題時要回頭看英文原詞

講師原話:「authorize 翻譯成授權是最準確的……強調的是給權利,有權利動用組織資源。」

PMI 術語: Approve ↔ 批准(商業論證) / Authorize ↔ 授權(章程)

🎯 考點: 看到 business case 搭 approve、program charter 搭 authorize。題目問「何時可以動用資源/正式啟動」,答案是章程授權之後。

§130 商業論證由發起人主導,章程之後專案集經理才登場 (03:49:46)

核心: 商業論證本質上不是專案集經理主導,而是發起人或組織某些部門在做。從章程開始,專案集經理才正式登場。

• 章程之前,你可能只是「意向中的」專案集經理,甚至還不是
• 專案集經理是獲得組織授權、可以動用組織資源、領導團隊做專案集的人
• 批准論證不等於立即啟動。兩者通常相隔不久,但本質上是兩件事
• 組織沒資源時就不會頒佈章程;一旦頒佈章程,代表資源一定有
• 商業論證是提出資源需求,證明「投入多少、帶來多少回報」,也就是成本收益分析
• 這些都發生在構建子階段(啟動階段)

🎯 考點: 商業論證的主導者是發起人(sponsor)或組織,不是專案集經理;專案集經理在章程授權時被任命。

§131 規劃:專案集管理計劃完成後才在交付階段啟動元件 (03:52:06)

核心: 章程授權後,專案集經理組建核心團隊開發專案集管理計劃(規劃);整體計劃完成後才開始執行,也就是元件的啟動。在這之前沒有元件。

• 規劃要考慮方方面面,至少十個方面的管理計劃,再加三個(對應績效域的)子計劃,構成整體計劃。子計劃數量見 §47
• 元件是在交付階段才啟動的
• Formulation 字面意思是「形成」,不好理解的話就當成啟動。換這個詞是為了和專案管理的「啟動、規劃、執行」區分

講師原話:「元件的啟動是在這兒,在此之前沒有元件。」

§132 專案組合評審做篩選;元件的授權與商業論證(develop 對 update) (03:53:33)

核心: 專案組合評審是做篩選。交付階段每個元件(專案)要啟動,都要經過專案集指導委員會批准,也要做專案層級的商業論證:之前沒考慮過叫 develop,考慮過就叫 update。

• 專案組合的工作是篩選,符合要求的才進來,被篩掉的就不給資源
• 專案和專案集都需要授權。專案的授權發生在交付階段
• 專案集經理以發起人身份啟動專案,但不能自己做主,需要專案集指導委員會批准
• 元件啟動時也要做商業論證,做的是專案(project)的 business case
• 之前從沒考慮過這個專案:develop a business case
• 專案集論證時曾經考慮過,哪怕一點點:update business case

PMI 術語: Program Steering Committee ↔ 專案集指導委員會 / Develop / Update Business Case

🎯 考點: 元件層級的商業論證,看動詞判斷:前面從未考慮 → develop;前面考慮過 → update。

§133 學員問答:現實中的專案集例子 (03:55:59)

核心: 判斷是不是專案集,看各部分之間有沒有互相影響的關聯關係。

• 公司實務多半統稱「專案」,沒有區分;曼哈頓計劃的 program 也常譯成「計劃」
• 講師的行業例子:一個客戶在全國 31 省都有專案,要權衡主攻哪個省、拿哪些省做交換條件(例如甘肅)。一地的成敗會影響其他地方 → 專案集
• 產品內有多個互相關聯的模組 → 專案集
• 三峽工程、曼哈頓計劃都是專案集,特點是互相影響

§134 商業論證內容:全面的成本收益分析 (03:58:59)

核心: 商業論證這份文件的「形成過程」比文件本身更有意義。成本收益分析是全面分析:財務和非財務、有形和無形、主觀和客觀、量化和不量化都要包括。

• 核心內容是成本收益分析,其他內容大概知道即可
• 目的:證明可行,用於授權,為制定專案集章程提供輸入

PMI 術語: Cost-Benefit Analysis ↔ 成本收益分析 / Tangible / Intangible Benefits ↔ 有形/無形收益

§135 文件順序:戰略計劃 → 商業論證 → 章程 → 管理計劃 (04:00:10)

核心: 組織戰略計劃是商業論證的「輸入」,不是商業論證本身。「正式評估」指商業論證,「選擇和授權」指章程。順序固定不變。

• 組織制定戰略(建立或更新戰略目的和目標),記錄在戰略計劃(SP)裡
• 商業論證要證明這件事和組織戰略目標一致
• 戰略計劃 → 商業論證 → 章程 → 專案集管理計劃,有明確的先後關係

🎯 考點: 四份文件的先後順序固定:SP → BC → Charter → PMP。

§136 商業論證的關鍵作用與成功標準(對比章程) (04:01:37)

核心: 商業論證是決定投資的依據,批准代表高層確認了投資和資源需求(但還沒給)。商業論證和章程都有成功標準:商業論證判斷「商業上是否成功」,章程判斷「目標是否實現」。

• 商業論證描述專案集背後的組織意圖,建立批准投資的正當理由
• 商業論證的成功標準:專案集結束時,判斷商業上是否成功
• 章程的成功標準:專案集結束時,判斷目標有沒有實現
• 例:交付給客戶時滿足章程目標(目標層面成功),但客戶沒多久就停用 → 商業上不成功

🎯 考點: 「商業上是否成功」對應商業論證;「專案集目標是否達成」對應章程。

§137 商業論證可高可細 (04:03:37)

核心: 商業論證通常是高層面的,但也可以是基礎、詳細、完整的,看需要而定。

• 在專案集裡啟動專案時,專案集的商業論證和元件的商業論證都要做一遍
• 專案集商業論證是重新 review 一遍;專案的商業論證要詳細做一遍

講師原話:「它可甜可鹹,取決於你的需要。」

§138 approve = 預留投資,資源還沒到手 (04:04:25)

核心: 專案集商業論證一旦被批准,代表組織為了實現戰略目標「預留」了一筆投資。要動用,還需要正式授權。

• 例:說服了領導,領導說可以給你 20 個人,但還沒給。等組織立項、發任命書以後才能動用
• 做商業論證就是向領導「畫大餅」,說明這件事真的值得做

🎯 考點: 商業論證批准 = 預留(reserve)投資,不是可以使用資源;可以使用要等章程授權。

§139 商業論證的特徵:連接組織戰略目標與專案集目標 (04:05:27)

核心: 商業論證是預期收益的第一次正式說明,並且把組織戰略目標和專案集目標連起來。

• 證明投入這麼多錢是合理的,並針對預期收益評估投資(本質還是成本收益分析)
• 是正式文件,為高層決策提供書面依據
• 專案集目標記錄在章程裡,組織戰略目標記錄在組織戰略計劃裡
• 商業論證就是把兩者聯繫起來的文件,也是啟動專案集的原因、依據和合理性

🎯 考點: 「商業論證連接了組織戰略目標和專案集目標」是考題原型。

§140 專案集章程:authorize,任命專案集經理 (04:07:27)

核心: 章程源自商業論證(商業論證是章程的輸入),是任命和授權專案集經理的文件,規定專案集的範圍和目的,經組織批准後授予資金和權力。

• 商業論證被 approve 後,可能經過指導委員會、HR、PMO 等流程,發佈專案集啟動文件。理論上叫章程,實務上也叫任務書或啟動文件
• 書上說授權給專案集管理團隊,實際上首先是給專案集經理
• 第一個作用:給專案集經理正式的(法律)身份
• 最核心的是授權:有了權利,錢和身份就都有了

PMI 術語: Program Manager ↔ 專案集經理

§141 章程要素:目標以收益體現;元件到交付階段才出現 (04:08:51)

核心: 章程有 13 條要素。最常考的是「專案集目標透過收益體現」和「收益如何達成的策略」。要特別注意:完整的元件清單到交付階段才出現。

• 要再描述一次商業論證中做專案集的理由(背景),以及願景、目標、戰略一致性和範圍
• 收益就是專案集的目標,也就是專案集結束後要交給組織的東西
• 容易混淆:章程裡寫了「元件」,但這時元件根本還沒出來
• 硬要解釋的話:這時的元件只是一開始就指定的零散項目(合規要求、領導指定),不是透過收益分析推導出來的整套
• 考試要注意:所有專案集元件(完整元件清單)都是在交付階段才出現

🎯 考點: 章程最常考的是專案集目標(以收益表達)和收益實現策略。元件清單在交付階段才完整出現,不是在章程或規劃階段。

§142 路線圖在 5th 併入專案集管理計劃 (04:10:59)

核心: 章程裡的時間線基本上就是路線圖。5th 和 4th 最大的差別之一,就是路線圖不再是獨立文件,歸到專案集管理計劃裡了。

• 4th 有一份專門的文件叫路線圖(Program Roadmap)
• 5th 把它歸入 Program Management Plan

⚠ 新版變化: 路線圖從 4th 的獨立文件,變成 5th 專案集管理計劃的組成部分。

§143 章程裡的干係人和治理都只是初步方向 (04:11:39)

核心: 章程中的治理框架、干係人考量、資源需求,都是規劃時開發專案集管理計劃的輸入,只是方向性、不完整的描述。

• 干係人:不是識別專案集所有干係人,而是章程那一刻已出現的重要干係人,包括他們關心什麼,以及如何爭取的粗略策略
• 治理:這時治理結構還沒建立,只是一個推薦的治理結構(伏筆),要到規劃時才轉成完整的治理動作和要求

🎯 考點: 章程中的干係人和治理內容是「初步、方向性」的。完整的干係人識別和治理結構在規劃階段完成。

§144 章程的正式定位 (04:13:02)

核心: 專案集章程正式(formally)表達了組織的願景、使命和預期收益,並定義和組織戰略計劃一致的專案集特定目的和目標(goals / objectives)。

• goals 和 objectives 中文都簡化成「目標」,這些目標必須和組織戰略一致
• 講師把章程的四條特徵放在投影片上,要記住

PMI 術語: Goals / Objectives ↔ 目的/目標

§145 專案集管理計劃:規劃子階段產物,子計劃不是專案層級 (04:13:36)

核心: 專案集管理計劃是規劃子階段的產物,整合各子計劃,為整合和管理元件建立機制和總體方案。這些子計劃是專案集整體層級的,不包括專案層級的計劃。

• 構建子階段加規劃子階段合稱定義階段。講師後面說「規劃階段」時,指的都是子階段
• 子計劃例:範圍、進度、財務(取代成本)、品質、資源、溝通等,用來指導專案集交付
• 總體計劃定了以後,專案層級要按照這個總體方案的要求制定自己的計劃
• 內容很多,不用背,了解即可

🎯 考點: 專案集管理計劃的子計劃都是專案集層級(對整體),不含元件/專案層級的計劃。

§146 路線圖:chronological、graphical、里程碑和決策點 (04:15:20)

核心: 路線圖是專案集管理計劃的主要組成部分,用「時間順序(chronological)」和「圖形方式(graphically)」呈現專案集的預期方向。早期只有里程碑和決策點,沒有元件。

• 關鍵詞 direction(方向)和 path(路徑):告訴別人怎麼走才到終點
• 通常從左到右表示時間流逝
• chronological 這個字一出現,文件只可能是路線圖
• 書上的例子雖然有專案,但做章程、甚至做規劃時元件都還沒出現,要到交付階段才一個一個寫上去
• 早期內容:里程碑(milestone)、決策點(decision point),以及兩者之間的關係
• 這是「違反常識」的難點:規劃時沒有專案,要梳理的是收益實現路徑和依賴關係(講到收益時再展開)

講師原話:「這個詞(chronological)只要一出現,檔案只能是路線圖,不可能是別的。」

PMI 術語: Program Roadmap ↔ 專案集路線圖 / Chronological ↔ 時間順序 / Milestone ↔ 里程碑 / Decision Point ↔ 決策點

🎯 考點: 看到 chronological 或 graphical representation 就選路線圖。早期路線圖內容是里程碑和決策點,不是元件。

§147 路線圖連接什麼?對比商業論證 (04:19:22)

核心: 路線圖連接「組織戰略」和「專案集工作/活動」;商業論證連接「組織戰略目標」和「專案集目標」(以文件來說是戰略計劃和專案集章程)。

• 板書:Organizational Strategy ← Roadmap → Program Activity / Program Work
• 商業論證以內容來說:左邊是組織戰略目標,右邊是專案集目標
• 商業論證以文件來說:左邊是組織戰略計劃,右邊是專案集章程(不是專案章程)
• 路線圖的性質和 4th 一模一樣,只是收進專案集管理計劃
• 這些都很抽象,需要一定的抽象思考能力

🎯 考點: 「連接組織戰略和專案集工作」的是路線圖;「連接組織戰略目標和專案集目標」的是商業論證。這類題全部都考。

§148 路線圖要持續更新 (04:21:30)

核心: 路線圖內容是持續更新的。元件被批准後,要把預計開始和完成時間、執行後的實際啟動和完成時間更新上去。元件的開始和完成是路線圖上最重要的里程碑之一。

• 沒有元件時,上面都是決策點和事件
• 有了元件之後要把專案的狀況反映上去

§149 專案集管理計劃的子計劃:13 變 14 (04:22:31)

核心: 專案集管理計劃是一組(set of)子計劃,不是單一份計劃。原本 13 個,加上路線圖變成 14 個。其中收益管理計劃、干係人爭取計劃、治理計劃各對應一個績效域,特別重要。

• 對應績效域的三個:收益管理計劃、干係人爭取計劃、治理計劃
• 其餘的:範圍、進度、財務(取代成本)、品質、資源、溝通/資訊、風險、採購、變更管理等
• 不需要背,但知道這個結構對理解標準很有幫助
• 路線圖是第五版的變化,考試可能會考它放在哪裡

⚠ 新版變化: 路線圖併入以後,子計劃數量變成 14 個(講師口述;前面 §29 和 §44 附近講的是 13 個或「10 + 3」,說法不一致,要以教材為準)。

§150 環境評估:事業環境因素,無法控制只能適應 (04:24:29)

核心: 環境評估看的是事業環境因素。這些因素的共同點是你沒辦法直接控制,只能適應,而且它們決定了管理水平的上限。

• 對專案集而言,外部因素可能在組織外部,也可能在專案集外、組織內
• 了解環境對制定三份文件很有幫助。例:資金監管影響財務管理計劃,市場資源供給影響資源管理計劃
• 例:匯率和結算貨幣(盧布、當地貨幣)、通脹、歐洲的健康安全環保要求,都會影響目標設定和管理計劃
• 具體因素不用記,知道共同特性就好,重點在工具

PMI 術語: Enterprise Environmental Factors (EEF) ↔ 事業環境因素

§151 環境分析五工具:SWOT 最全面 (04:27:24)

核心: 五個環境分析工具:比較優勢分析、可行性研究、SWOT 分析、假設分析、歷史資訊分析。其中 SWOT 最全面(comprehensive)。

• 比較優勢分析:兩個或以上做比較,找出最好的
• 假設分析:分析假設條件;歷史資訊分析:看我們和環境過去的情況
• SWOT:S/W 是內部,O/T 是外部。內部優勢可以抓住外部機會、抵禦外部威脅;劣勢會帶來威脅,但用得好也可能變成機會,彼此可以轉化
• SWOT 一條橫線把內外分開,所有情況都涵蓋進來,所以最完整
• 工具用來支援制定商業論證、章程、專案集管理計劃

PMI 術語: Comparative Advantage Analysis ↔ 比較優勢分析 / Feasibility Study ↔ 可行性研究 / SWOT Analysis / Assumption Analysis ↔ 假設分析 / Historical Information Analysis ↔ 歷史資訊分析

🎯 考點: 五個工具每一個都要知道意思。題目問「哪個工具考慮最全面」,答 SWOT(comprehensive)。

§152 工具細節:可行性的面向、假設分析、SWOT 補充商業論證 (04:30:05)

核心: 可行性分析有多個面向(經濟、資金、地緣政治/外交)。假設分析是檢查之前的假設還成不成立。SWOT 可以作為可行性研究和商業論證的補充。

• 可行性:經濟上會不會賺錢、有沒有資金支持;地緣政治上可不可行(例:大國關係導致到他國建廠不可行)
• 假設分析:做專案集之前的假定還成立嗎?不成立的話,專案集目標和商業論證都要重新處理和規劃
• 這張表有考點,五個工具加上各自特徵都要記

🎯 考點: 「SWOT 分析技術可以作為可行性研究和商業論證的補充」是考點原句。

§153 風險管理策略在「構建子階段」確定,並驅動風險管理活動 (04:32:09)

核心: 專案集風險管理策略在構建子階段(很早期)就要確定,不是在規劃子階段。策略會驅動(drive)後續的風險管理活動,兩者差別很大。

• 很多人會答「規劃」,這是錯的。是構建子階段,也就是啟動時就要確定
• 風險管理活動(狹義):規劃風險管理、識別、定性分析、定量分析、規劃應對、實施應對、監督風險(約七個)
• 策略(strategy):確定風險管理的原則和方向,不執行具體活動

講師原話:「專案集風險管理策略的確定發生在構建子階段,回答規劃的說明可能沒太留意這個點。」

PMI 術語: Risk Management Strategy ↔ 風險管理策略 / Drive ↔ 驅動

🎯 考點: 題目問「專案集風險管理策略在哪個子階段確定」,答構建子階段(Formulation)。策略驅動風險管理活動,不要把兩者混為一談。

§154 風險管理策略的三件事 (04:34:03)

核心: 風險管理策略包括三件事:(1) 明確風險閾值(臨界值);(2) 做初始的專案集風險評估(整體層面,不是單一風險);(3) 決定風險應對策略(迴避、減輕、提高、轉移、分享等)。

• 這三件事不叫風險管理活動
• 閾值是設定臨界點,碰到臨界點要採取的行動才是風險管理活動
• 這些要在早期和重要干係人先敲定
• 要考慮環境因素,決定專案集的整體策略
• 和戰略一致性的關係:風險是影響專案集達成目標的不確定性,會讓你偏離戰略方向,所以兩者緊密相連
• 早期不要把精力放在識別具體風險上

PMI 術語: Risk Threshold ↔ 風險閾值/臨界值 / Initial Program Risk Assessment ↔ 初始專案集風險評估

🎯 考點: 風險管理策略 = 閾值 + 初始(整體)風險評估 + 應對策略,不做單一風險識別。

§155 風險偏好轉成風險閾值,超過要升級 (04:36:01)

核心: 先了解關鍵干係人和組織的風險偏好(態度),再把偏好轉成可量化的風險閾值(數字)。閾值是授權的天花板,超過就要升級給相應層級決策。

• 例:有些高層一點風險都不接受,這是風險迴避型;整個公司也可能有這種特點
• 偏好是態度,不能直接指導管理,要轉成數字化的閾值,才能在管理過程中比較並決定行動
• 閾值內你可以自行處理,超過就要彙報給高層,由高層決定是否繼續,不同意就告一段落
• 早期就要確定超過閾值要升級到哪一層(總裁還是董事會)
• 風險閾值:組織可接受的變動程度或區間(例:進度最多可以延後一個月)
• 這個階段不做單一風險識別

講師原話:「預值的意思就是超過你的許可權,超過了許可權必須要做決策。」

PMI 術語: Risk Appetite ↔ 風險偏好 / Risk Threshold ↔ 風險閾值

🎯 考點: 偏好(態度、定性)對閾值(數字、定量);超過閾值就升級(escalate)到事先約定的層級。

Part D (04:39:45 - 06:19:15) 綜述

這一段接在戰略一致性績效域(Strategic Alignment)的「專案集風險管理策略」後半,先把風險管理策略的三步驟講完:①確定風險臨界值(Risk Threshold,把風險偏好量化)②做初始風險評估(Initial Risk Assessment,針對風險「類別」,特別是戰略一致性風險)③依風險「等級」訂定總體應對策略,再串到治理框架的強制性與升級。接著帶過 3.6 績效域互動(戰略一致性是其他績效域的基礎,互動不必背),然後進入本章最難的 3.4 收益管理績效域(Benefits Management):收益的定義(gains)、有形/無形收益與合規收益題外話、收益邏輯「分析從右向左、實現從左向右」、五階段(識別→分析與規劃→交付→移交→維持)全貌與它和專案集生命週期「大致對應但不嚴格對應」的關係。下午逐階段展開:收益識別(來源=商業論證+章程,登記到收益登記冊,只定指標名稱)、收益分析與規劃(用 1000 萬營收倒推的例子說明收益依賴關係地圖=收益管理計劃,KPI 的數值與測量方法在此確定並回寫登記冊)、收益管理計劃 vs 路線圖(架構 Architecture vs 結構 Structure)、成本收益曲線,最後進入收益交付(依託元件交付)。

最重要的考點判準: 1. 風險管理策略階段「不識別單一風險」,臨界值、初評、應對策略都是針對類別/等級。 2. 專案集裡的專案(元件)在「收益交付」階段才出現;元件之間的依賴關係來自收益分析。 3. 題目出現「專案集進展(progress)」→ 九成選收益登記冊;記錄「如何實現收益的方法與衡量指標」→ 收益管理計劃。 4. 收益識別只確定 KPI 名稱;KPI 數值與測量方法在分析與規劃階段確定,再回寫登記冊。 5. 收益管理計劃建立專案集「架構」,路線圖定義元件「結構」,兩者要動態保持一致。

§156 風險臨界值:可接受變化的上下限 (04:39:45)

核心: 風險臨界值是把風險偏好量化後的結果,表達組織可接受變化的上下限。

• 提前完成不一定都好:提前太多(例如 6 個月的專案提前半年)也可能超出可接受範圍,所以臨界值有上限也有下限
• 臨界值可以是進度、資金,甚至健康安全等風險衡量值,每家公司不同
• 它反映組織干係人的風險偏好(Risk Appetite):偏好是主觀的,臨界值是客觀(量化)的
• 建立臨界值要在早期完成,不能做到後面才發現高層對專案集風險的接受度,那就太被動了

PMI 術語: Risk Threshold ↔ 風險臨界值(逐字稿誤作「預指/預值」) / Risk Appetite ↔ 風險偏好

§157 臨界值的例子與組織/專案集的承接 (04:41:06)

核心: 組織有臨界值就承接並可修正(不得低於組織標準);組織沒有就自己定義並向上彙報。

• 例子:在風險登記上寫出風險暴露值(Risk Exposure = 機率 Probability × 影響 Impact)的最低/最高水平,形成可接受區間
• 組織有臨界值:偷懶可直接沿用;專業做法是依專案集情況修正,但不應低於組織的臨界值
• 組織沒有:定義一個供專案集內部管理用,同時向上彙報
• 臨界值可定義成高/中/低,也可直接用數字
• 此時面對的是「所有風險或某一類風險」的態度,不是單一風險
• 講師實務例:公司內部的 CRI(Contract Risk Index,合同/商務風險指標),把過去交學費的經驗提煉成可接受值

🎯 考點: 考題通常預設組織已有風險臨界值 → 專案集承接並依情況修正(不低於組織);若無 → 自訂並向上彙報。

§158 初始風險評估:評估類別而非單一風險 (04:43:35)

核心: 初始風險評估在定義階段(尤其構建 Formulation)進行,識別的是風險大類,不是單一具體風險。

• 雖然整個生命週期都做風險管理,但構建階段不確定性最高,所以在(擴大的)定義期間做初始風險評估
• 內容:識別專案集可能遇到的風險及其影響、評估期間與之後可能影響收益實現的風險
• 文字寫「識別」,但這裡指對某一大類風險的總體認識;選「識別單一風險」就錯了
• 初始風險評估最終服務於專案集風險臨界值與策略的確定

PMI 術語: Initial Risk Assessment ↔ 初始風險評估 / Program Formulation ↔ 專案集構建

🎯 考點: 風險管理策略情境中出現「識別單一/具體風險」的選項 → 排除,那是風險管理計劃與風險過程的事。

§159 戰略一致性風險的典型清單 (04:44:55)

核心: 初始風險評估要找出會讓專案集偏離組織戰略的「戰略一致性風險」。

• 專案集目標不支援組織目標(專案集目標在章程 Charter,組織目標在戰略計劃 Strategic Plan)
• 專案集管理計劃沒有貫徹組織戰略意圖
• 專案集計劃不支援上一級的專案組合(Portfolio)
• 組織能力/資源達不到要求就硬啟動專案集
• 設定了根本實現不了的收益(與目標類似,描述角度不同)
• 風險管理策略會影響章程制定:訂目標時不能另起爐灶、不顧組織目標與外部環境

🎯 考點: 「專案集目標在哪」→ 章程;「組織目標在哪」→ 組織戰略計劃。

§160 第三步:依風險等級訂總體應對策略 (04:46:50)

核心: 在專案集開始時,對「每個風險等級」設定應對策略,不是對每個單一風險。

• 經過臨界值、初始評估後,要落實成行動:哪一類/哪一級風險採取什麼策略
• 消極風險五種策略:規避 Avoid、減輕 Mitigate、轉移 Transfer、接受 Accept、升級 Escalate;積極風險也有五種
• 講師提醒:PMBOK 6 才有 Escalate,講師認為部分後續版本與 RMP 漏掉了
• 例:低等級→接受;中等級→減輕;高等級→規避或轉移;「無重大風險」→接受
• 這個階段全是方向、原則、政策、臨界值;具體單一風險的識別交給風險管理計劃

講師原話:「是對每個級別設定策略,而不是對每一個風險來設定策略,這個大家要特別記住,不然答題就會答錯。」

PMI 術語: Escalate ↔ 升級 / Mitigate ↔ 減輕 / Avoid ↔ 規避 / Transfer ↔ 轉移 / Accept ↔ 接受

🎯 考點: 風險管理策略 = 等級對應策略;風險管理計劃 = 具體風險的管理。

§161 策略驅動七個風險管理過程 (04:49:52)

核心: 策略先定大方向,才有後續具體的風險管理活動。

• 風險管理策略一旦建立,就在整個專案集生命週期內驅動風險管理活動
• 活動即熟悉的七個:規劃風險管理、識別風險、定性分析、定量分析、規劃風險應對、實施應對、監督風險
• 策略 = 方向;七個過程 = 具體行為

講師原話:「全是方向、全是原則、全是政策、全是臨界值那種,它不說具體的。」

§162 風險策略與治理框架:強制性與升級 (04:50:35)

核心: 風險策略可作為治理框架的一部分,納入治理的就具有強制性。

• 風險必然有超出專案集經理權限的情況,這時必須升級,由誰批准是規定好的
• 凡納入治理框架的東西一定要強制執行
• 典型具強制性/升級要求的領域:風險、變更(含問題)、質量(低於指標要升級)、採購
• 專案集風險定義:會導致專案集偏離組織戰略方向的事件

講師原話:「只要納入到治理框架裡的東西,那一定是要強制執行的。」

🎯 考點: 超出權限的風險/變更/問題 → 依治理框架升級,不是自行決定。

§163 風險管理策略三步驟總整理 (04:51:56)

核心: 風險管理策略 = 臨界值 → 初始風險評估 → 等級應對策略,過程中搭配多層級風險溝通。

• 第一步:花時間明確組織對此專案集的風險偏好與臨界值(多方協同確定,最低到最高水平的區間)
• 區間內不同位置定性(高中低)或定量,對應到等級
• 第二步:初始風險評估在構建前/構建時開始,對象即 §4 的戰略一致性風險
• 第三步:以前兩步為基礎,確定不同等級的應對策略
• 記住:全程都不是單一風險

§164 3.6 績效域互動:戰略一致性是基礎 (04:54:09)

核心: 績效域互動非常複雜,不必背;只要掌握戰略一致性是治理與其他績效域的基礎。

• 戰略一致性績效域是專案集治理的基礎,確保組織以最佳方式部署資源
• 定義階段隨商業論證、章程、管理計劃一起展開
• 與協同效應、治理、團隊等原則都有聯繫,與其他五個績效域都有協作(系統化思維)
• 每章的「互動」小節瀏覽即可

講師原話:「大家掌握住戰略一致性的定位就好了,它是另外幾個績效域的基礎。」

PMI 術語: Performance Domain ↔ 績效域(逐字稿誤作「績效率」)

§165 3.4 收益管理:專案集裡的專案從何而來 (04:55:50)

核心: 收益管理研究的是專案集如何從收益分析中「構建」出專案,而非憑感覺把專案放進來。

• 「規劃階段沒有專案產生」與常識不同,但這是標準想表達的最佳做法
• 現實常是「覺得有關係就放進來」;標準要求把每個專案對目標的幫助顯性化,增減專案才有依據
• 收益管理位於專案之下更底層:怎麼把專案集裡的專案分辨、設計出來
• 收益管理是對收益實現過程的管理:識別、分析、交付、移交、維持

講師原話:「如果我們能分析出來要增加的這件事情對我們實現目標有哪些幫助,把它顯性化出來,那增加或減少某個專案就變得非常有依據。」

PMI 術語: Benefits Management ↔ 收益管理

§166 收益管理五階段:可以談「階段」的兩處 (04:57:14)

核心: 標準中能談「階段」的只有兩處:專案集生命週期與收益管理。

• 收益管理五階段:識別、分析與規劃、交付、移交、維持
• 它比「活動」更高一個層級,叫階段
• 績效域目的:定義、建立、最佳化、交付、維持專案集收益,大致對應五階段(用詞有差異,知道即可)

PMI 術語: Benefits Identification / Analysis and Planning / Delivery / Transition / Sustainment ↔ 收益識別/分析與規劃/交付/移交(過渡)/維持

§167 收益的定義:gains (04:58:05)

核心: 收益是對接收方和組織有價值、原本沒有的增益(gains)。

• 專案產出可交付物,專案集把可交付物使用或整合後帶來收益
• 設此績效域的核心目的:讓關鍵角色把精力聚焦在收益實現上
• 不要僅聚焦在可交付物或成果(outcome),應聚焦在收益

講師原話:「設定這個績效域的目的,就是讓所有人都來關心收益,而不要僅僅聚焦在可交付和成果上。」

PMI 術語: Gains ↔ 增益 / Deliverables ↔ 可交付物 / Outcomes ↔ 成果

§168 收益管理核心活動 (04:59:44)

核心: 核心活動可用五階段串起,細項包含依賴管理、變更影響分析、戰略一致與移交維持。

• 識別並評估專案集能產生的收益與對組織的價值
• 協調/管理元件(Component)輸出之間的依賴關係;沒有依賴關係的不應出現在專案集中
• 分析變更對收益實現的影響;能增加收益的變更要擁抱
• 管理收益與戰略的一致性
• 關注移交與維持責任順利切換到接收方,甚至超出責任邊界仍持續關注
• 重點放在五個階段更有意義

🎯 考點: 元件之間若毫無依賴關係 → 不應放在同一個專案集。

§169 收益分類與合規收益(題外話) (05:01:43)

核心: 收益有有形/無形之分;合規類專案集的收益是避免罰款、避免停業或被淘汰。

• 合規收益最直接是避免罰款,但那只是小事
• 更嚴重的是不合規會被停止經營、整個行業不讓你生存,甚至國際間合規要求可能消滅一家公司或一個行業
• 合規一定有規則且具強制性;公司內部選擇性要求較接近「內控」,不宜籠統稱合規
• 標準來自美國,所說的合規範圍更廣
• 講師說明這段是題外話,了解即可

§170 收益範例:形而上 vs 形而下 (05:06:19)

核心: 收益的共同點是都不是有形產品;有形產品交給專案管理,收益是可交付物之上的東西。

• 例:降低成本、提升運營效率、產能增加、戰略一致性更好、客戶黏著度提高、市場份額增加
• 有形產品是專案管理關注的(形而下=可交付物),專案集關注形而上的收益
• 競爭優勢可能帶來更好的產品,一落到產品實現就回到專案管理

講師原話:「專案管理關注的是有形產品;有形產品之上、形而上的東西是收益,形而下的是可交付。」

§171 收益邏輯:分析從右向左、實現從左向右 (05:07:29)

核心: 從最終收益倒推該做什麼是收益分析(右→左);照路徑推進是收益實現(左→右)。

• 案例:想提升銷售收入 → 提升客戶滿意度 → 產品與服務更穩定不出錯 → 員工能力提升 → 培訓新工作方式、更好的工具、更簡化的流程
• 交付一個新系統只是表象;要看它帶來的業務變革、能力提升、客戶購買意願
• 專案集聚焦在最終結果,倒推應該做什麼,這就是收益實現分析

講師原話:「實現過程是從左向右,從右向左是分析的過程,倒推著來的。」

🎯 考點: 收益分析方向 = 由最終收益反推(右→左);收益實現 = 左→右。

§172 收益管理全貌與收益識別 (05:09:06)

核心: 識別階段從商業論證開始,與高層確認收益並記錄到收益登記冊。

• 五階段:識別、分析與規劃、交付、移交、維持
• 中文考卷會統一譯為「過渡」(Transition),講師偏好「移交」
• 識別:從商業論證(Business Case)開始識別與論證收益,和高層確認「這個目標算不算收益」
• 確認後的收益要記錄到收益登記冊(Benefits Register),特別重要

PMI 術語: Benefits Register ↔ 收益登記冊 / Business Case ↔ 商業論證 / Transition ↔ 過渡/移交

§173 分析與規劃:從戰略推導、排優先、訂指標 (05:10:11)

核心: 分析收益如何實現、排優先順序、推導度量指標,並寫入收益管理計劃,再整合進專案集管理計劃。

• 收益從組織戰略推導(derive)而來
• 每個收益都要有優先順序,因為實現收益也消耗組織資源
• 每個收益要能衡量 → 推導收益度量指標(metrics/KPI),放在收益管理計劃中
• 收益管理計劃主要告知團隊與管理層「如何以及何時」實現收益
• 收益管理計劃是專案集管理計劃的 14 個子計劃之一,要和進度、財務、資源管理整合

講師原話:「這個計劃要告知所有的團隊成員包括管理層,我如何來實現收益以及什麼時候實現收益。」

PMI 術語: Benefits Management Plan ↔ 收益管理計劃 / Derive ↔ 推導 / Program Management Plan ↔ 專案集管理計劃

§174 收益交付:專案這時才出現 (05:12:24)

核心: 在收益交付階段,才依收益依賴關係識別出要啟動的專案;此前都在做收益分析。

• 課堂互動:專案集靠什麼讓收益出現?最符合標準的答案是「元件交付」(含元件監督)
• 收益是概念、是想要的結果,實現它要在交付階段找到要做的專案
• 每個專案完成可交付物,整合後實現專案集層面的收益
• 收益分析之前從未提過元件;在這個位置把依賴關係中的行為打包成專案一、專案二…

講師原話:「就在此時此刻,才出現了專案集裡的專案這個顆粒度,在此之前都是在做收益的分析。」

🎯 考點: 「專案集的元件何時被識別/啟動」→ 收益交付(對應專案集交付階段的元件授權與規劃)。

§175 為何把收益轉成專案:可交付 ≠ 收益 (05:15:23)

核心: 組織會管專案不會管收益,所以要把抽象收益轉化為一個個專案;但下達目標時要讓專案看到可交付背後的價值。

• 懂專案管理的人容易找,懂收益管理的人難培養
• 價值與收益的層級:組合角度叫價值,專案集角度叫收益
• 例:產品開發完成 = 可交付與專案目標完成,但賣不出去 = 收益目標沒達成

講師原話:「你產品做出來你得能賣出去才行,如果只能把產品做出來你賣不出去,可交付完成了、專案目標完成了,可是收益目標並沒有達到。」

§176 更新登記冊與報告收益 = 爭取干係人 (05:16:43)

核心: 報告收益表面是例行動作,背後是在爭取干係人持續投入與資源。

• 專案開展後收益登記冊要持續更新;迭代式交付時更新更頻繁
• 定期向干係人報告已實現的收益
• 干係人看到期望的結果才會持續投入、更願意給資源
• 收益管理因此與干係人參與、戰略一致性、治理都有關

講師原話:「報告收益表面上是一個例行化的動作,但它背後是有深意的。」

PMI 術語: Stakeholder Engagement ↔ 干係人參與

§177 收益移交:單一收益移交 vs 整體移交 (05:18:01)

核心: 收益有的過程中產生就可交(單一收益移交),有的要等全部完成;最後都要做專案集整體移交。

• 增量式交付:過程中產生的收益可先移交給客戶
• 一次性交付:等所有完成才移交
• 所有收益完成後,還要做專案集整體移交
• 移交內容:持續收益的責任、培訓文件、資料、操作手冊,並培訓接收組織的人員

PMI 術語: Benefits Transition ↔ 收益移交(過渡)

§178 收益維持:接收方長期做、PMO 接手支援 (05:19:10)

核心: 移交後由接收方維持收益;專案集釋放大部分資源,只留少量人關注接收方,並保留經驗教訓。

• 接收方長期持續做;專案集仍在背後支援,建立良好關係利於未來合作
• 此時大量團隊被釋放,保留少量人監看接收方收益實現的情況與跡象
• 組織運營部門要與接收方對接,形成組織級關係
• 回到公司要保存整個專案集期間與收尾的經驗教訓(Lessons Learned)
• 專案集最終完全退出,但組織要有部門把支援收益維持的職能沉澱下來:PMO、售後部門

講師原話:「專案集可能完全退出,但組織一定是有部門把支援接收方做收益維持的這些職能沉澱下來,PMO 就有這個職責。」

🎯 考點: 專案集關閉後誰支援收益維持 → PMO/運營或售後等組織職能部門。

§179 收益五階段與專案集生命週期:大致對應 (05:21:40)

核心: 收益管理五階段可能超越專案集生命週期;兩者大致對應但不嚴格對應。

• 專案集總有關門的一天,但交給客戶的收益可能持續很多年
• 部分收益在過程中已移交;專案集收尾時再做一次整體移交;移交完後的維持期間,專案集仍在運作(經驗教訓、收尾、慶祝)
• 專案集交付階段 ↔ 收益交付對應性較強,但交付期間也可能發生收益移交與再規劃(規劃不是一次做完)
• 收益識別最早在構建階段開始,延續到規劃、交付甚至整個生命週期,重點在前段
• 更早可能在組合管理/高層論證就開始,但超出考試範圍

講師原話:「收益管理的五個階段和專案集生命週期有對應關係,但不是嚴格的對應關係,是大致上的對應關係。」

§180 收益識別:identify 也是「確認」 (05:24:13)

核心: 收益識別除了識別還包含確認;主要來源是商業論證與章程。

• identify 有時譯作「確定」,本階段要識別並確認干係人希望實現的收益
• 來源:商業論證(第一次正式宣告)、章程、干係人想法、組織戰略計劃(較不貼近本專案集)
• 關鍵活動:定義專案集目標(基本就是收益)以及如何衡量
• 識別時只確定衡量指標的「名稱」(如成功率、成本率),具體數值此時不確定
• 把收益要求寫入收益登記冊

講師原話:「在識別的時候只確定指標的名稱,或者指標是什麼;成本率是多少,在這個時候是不確定的。」

🎯 考點: 收益識別 → 只有 KPI 名稱;數值與方法 → 分析與規劃階段。

§181 章程發布 = 收益正式確定;登記冊內容 (05:27:12)

核心: 章程發布代表商業論證已確認,組織要專案集完成的收益在此正式確定並登記。

• 專案集確立之前,高層可能在戰略規劃中就有相關內容(當時還沒有專案集經理甚至發起人)
• 章程需要商業論證支撐,章程發布 = 收益正式確定
• 收益登記冊內容(重要考點):收益清單、收益與元件的對映關係、每個收益的衡量指標、收益負責人
• 登記冊中的測量方法實際上是在下一步(收益管理計劃)確定後回寫的

PMI 術語: Program Charter ↔ 專案集章程 / Benefit Owner ↔ 收益負責人

§182 與干係人確認指標與測量方法:5000 萬的例子 (05:29:31)

核心: 收益名稱與內容要和關鍵干係人確認,並協商「怎麼測才算數」。

• 流程:商業論證 + 戰略計劃 + 章程(主要是前兩份早期文件中的商業論證與章程)
• 專案集目標要領導確認
• 例:銷售目標 5000 萬,簽約就算?還是客戶首筆款入帳才算?
• 若規則是「簽約 + 首筆款到位」,則 500 萬合同簽約當下不算,首筆 100 萬入帳後 500 萬才計入
• 關鍵指標 = 收入;測量方法 = 計算規則,同樣重要

講師原話:「你要和關鍵干係人確認你的指標怎麼測出來才算。」

§183 定性與定量測量:品牌收益的例子 (05:31:59)

核心: 不易量化的收益(如品牌)也要設計可管理的量化指標。

• 收入類指標好量化;品牌影響心智,不好用數字衡量
• 例:高層受邀在重要場合演講算一次品牌活動
• 再加條件:到場人數 20 人以上才算、從頭聽到尾的人數、聽眾身份(無 title 不算)
• 層層加碼就能把定性目標轉為可管理的指標

§184 收益登記冊核心與「progress」考點 (05:33:35)

核心: 收益登記冊雖只記錄收益,但專案集整體進展最重要的內容就是收益。

• 收益登記冊依商業論證、組織戰略計劃與其他相關文件的目標開發,重點在商業論證與章程
• 重要欄位:關鍵指標、收益負責人
• 專案集整體進展、問題在哪 → 看收益登記冊
• 其他活動的「進展」不重要,收益本身就是進展

講師原話:「progress 這個詞只要一出現,那基本上 90% 以上都是收益登記冊了。」

🎯 考點: 題目問「在哪裡查看專案集進展(progress)」→ 收益登記冊。

§185 登記冊樣表與收益整體情況報告 (05:35:37)

核心: 登記冊最重要三欄是收益名稱/描述、負責人與度量指標、預計實現時間。

• 欄位包含編號、名稱、描述、責任人、度量指標、實現時間、當前狀態、類別
• 給高層看的不是登記冊(細節太多),而是收益相關報告/整體情況表(按舉措或收益編號呈現)
• 收益整體情況表不屬考試範圍,知道即可

§186 分析與規劃:為什麼收益還要分析 (05:36:51)

核心: 登記冊確認「要哪些收益」;分析與規劃處理的是「收益如何實現」及其依賴關係與路徑。

• 例:章程給的收益目標 1000 萬營收
• 倒推:客戶 A 600 萬、B 300 萬、C 100 萬(自己的估計)
• 客戶 A:既有產品 X 佔 40% = 240 萬,新產品 Z、Y 各 30% = 180 萬
• 再倒推:新產品需要什麼特性、成本率 → 開發團隊、供應鏈採購、售後要做什麼
• 售後跟不上可能被客戶罰款,收益反被侵蝕
• 這個倒推過程就是收益分析

講師原話:「要想達到這個目標,倒推出要做的一些事,才能支撐我完成這個目標,這個過程就是我們在講的分析。」

§187 規劃:收益依賴關係地圖 = 收益管理計劃 (05:42:14)

核心: 規劃是把收益實現路徑、專案與收益的關係梳理出來;但仍不是啟動元件的時間點。

• 路徑分析出來後,要規劃專案與收益之間的關係
• 規劃 ≠ 啟動專案;啟動元件時就進入收益交付
• 本階段主要產出:整體計劃,核心是收益依賴關係地圖,即收益管理計劃
• 收益管理計劃舊名「收益實現計劃(Benefits Realization Plan)」,名稱更直接

PMI 術語: Benefits Realization Plan ↔ 收益實現計劃(舊稱) / Benefits Dependency Map ↔ 收益依賴關係地圖

§188 關鍵活動:優先順序、依賴網、KPI 回寫 (05:44:08)

核心: 本階段確定收益優先順序、收益間依賴網狀圖,以及 KPI 的數值與衡量方法,並回寫收益登記冊。

• 以支撐力度排序:對目標貢獻最大的(例中客戶 A)優先級最高
• 確定收益之間的依賴關係(網狀圖),這直接影響專案集元件怎麼構建
• 識別階段只確定 KPI 要衡量什麼;真正的數值與衡量方法在這裡確定,再同步回收益登記冊
• 所以收益管理計劃與登記冊都會看到 KPI,但確定時點不同
• 過程中遇到的風險也要登記到收益登記冊

講師原話:「最早先識別 KPI,你要衡量什麼,數值和方法在那都確定不了,它的數值和方法是在這個階段確定的。」

🎯 考點: KPI 數值與測量方法在「收益分析與規劃」階段確定,並更新收益登記冊。

§189 計劃的用途:指導與衡量 (05:46:40)

核心: 收益管理計劃既指導如何做,也用來在執行期間衡量收益實現情況。

• 依賴圖上的百分比是實現機率,不一定準,但需要數字支撐整體梳理
• 收益實現無法 100% 保證,這是專案集與專案的較大區別:影響因素非常多
• 但仍要有指標與計劃作為過程控制依據

講師原話:「它仍然是一種可能性、機率,它不敢百分之百保證,這就是專案集跟專案比較大的區別。」

§190 收益管理計劃內容:如何、何時,是基線文件 (05:47:55)

核心: 收益管理計劃正式記錄實現收益所需的活動、如何以及何時交付給組織,是專案集執行的基線(基礎)文件。

• 例:年底前交 1000 萬營收 → 倒推 A/B/C 客戶各在何時簽多少金額
• 專案集圍繞收益開展,收益做得好專案集就好,所以它被視為基準
• 制定時也要考慮未來移交:可以粗略,但不能完全不考慮
• 計劃包含收益如何、何時實現,以及何時、以何方式移交;重點在如何實現,兼顧移交,維持也可寫入

講師原話:「整個專案集是圍繞著收益來開展,所以我們要衡量的主要內容就是收益。」

§191 計劃四大關鍵內容與兩種 owner (05:50:19)

核心: 四大關鍵:實現方式、衡量方法、收益與元件的關聯、實現收益的責任;另要初步考慮向運營的移交。

• 實現方式:每項收益如何做到(即依賴圖)
• 衡量方法:執行中如何判斷達成與否
• 元件關聯:將元件產出、成果、目標與關鍵結果和收益關聯,並同步寫入登記冊
• 責任:收益管理計劃裡是「負責實現收益的角色」(Benefit Realization Owner);登記冊裡是收益最終能否達成的 owner(Benefit Owner)
• 比喻:你是執行負責人,你的主管是最終責任人
• 向運營移交的規劃此時只是初步考慮;收益管理計劃與收益登記冊都是考試重點

講師原話:「這個地方是負責實現收益的那個人,登記冊裡面的那個角色是對這個收益最終能不能做到的那個責任人。」

PMI 術語: Benefit Owner ↔ 收益負責人(最終責任) / Benefit Realization Owner ↔ 收益實現負責人(執行)

🎯 考點: 區分兩種 owner:登記冊 = 最終責任人;收益管理計劃 = 實現執行者。

§192 收益管理計劃 vs 路線圖:架構 vs 結構 (05:53:03)

核心: 收益管理建立專案集「架構」(內在邏輯),路線圖定義元件「結構」(表面組成),兩者共同內容要動態一致。

• 收益管理計劃出現前,用路線圖向高層展示怎麼做;之後收益管理計劃細得多
• 相同內容(如元件起訖時間)要同步:收益管理計劃規劃出的元件時間更新到路線圖
• 結構 Structure:專案集下有元件 1…N,一眼看到的組成(給專案經理/執行者看)
• 架構 Architecture:收益依賴圖中的內在聯繫;把某些行為圈起來成為專案一、專案二…
• 章程裡沒有元件結構,標準把展示結構的職責給了路線圖(講師認為有點牽強)
• 有架構才有結構;不同人依經驗與判斷劃出的專案組成可能不同,取決於收益分析者的水平

講師原話:「有了架構才有結構。」

PMI 術語: Program Architecture ↔ 專案集架構 / Program Structure ↔ 專案集結構 / Program Roadmap ↔ 專案集路線圖

🎯 考點: 「誰建立專案集架構」→ 收益管理(計劃);「誰定義元件結構/時序」→ 路線圖。

§193 元件依賴關係的來源與動態調整 (05:59:42)

核心: 專案集下元件之間的依賴關係來自對收益的分析;收益關聯不是靜態的,要透過反饋機制調整。

• 這是收益管理最難、也是標準最有價值之處:專案集經理能推演複雜目標的實現路徑,協調專案時才抓得住要領
• 若只是畫好路線圖就往上加專案,沒有收益分析,專案間撞車、目標衝突會很多
• 環境變化、授權變更時,收益關聯也要透過反饋機制調整,結果是專案增加或減少
• 例:客戶 A 今年投資縮減,180 萬不可能 → 上一級把 A 目標由 600 萬調降到 300 萬,缺口找 B/C/D 補
• 專案經理不能自行調自己的目標,上一級才能調整下一級目標

講師原話:「專案集下邊組件的依賴關係,一定是來自於我們對收益的分析和理解。」

🎯 考點: 元件依賴關係從哪來 → 收益分析(收益依賴關係)。

§194 兩份計劃各有側重;減貧例子 (06:04:04)

核心: 路線圖與收益管理計劃都是專案集管理計劃的一部分,前者按時間呈現元件,後者更深層。

• 路線圖:按時間順序、元件之間的依賴
• 收益管理:更深層,與專案集生命週期並行,同樣有階段
• 講義小結:收益管理確定架構(Architecture),路線圖定義結構
• 減貧例子(無法量化的政府目標):從最終收益倒推中間收益、再往前的行動;專案劃分可能跨多條路徑,形成超級複雜的專案
• 看清背後聯繫,才知道哪個點有放大效應、哪個點沒做好會連鎖反應,才能做好協調

§195 考到什麼程度;登記冊 vs 計劃的判別 (06:07:16)

核心: 不會考你畫路徑,只考概念:依賴分析後確定元件,再進入交付;並區分登記冊與計劃。

• 細節不會考讓你識別專案;只要知道依賴分析清楚後確定元件,啟動元件就到交付階段
• 本階段更新登記冊:收益與元件對應、KPI 更確定、衡量方法
• 記錄專案集收益進展 → 首選收益登記冊
• 記錄如何實現收益的方法與測量指標 → 首選收益管理計劃
• 干係人全程參與非常重要

講師原話:「記錄進展的登記冊,記錄方法的管理計劃,就把這兩個文件分開。」

🎯 考點: 進展 → 收益登記冊;方法與衡量 → 收益管理計劃。

§196 收益跟蹤矩陣 (06:09:12)

核心: 可用收益跟蹤矩陣追蹤每個收益由哪個交付、哪個元件(子專案集/專案)承載。

• 管理計劃中的指標用來衡量與評估專案集實現收益的表現,知道概念即可
• 矩陣:子專案集 A、專案 B、C… 對應各收益與交付

§197 成本與收益曲線:淨成本與平衡點 (06:10:03)

核心: 專案集早期以投入為主,收益有滯後效應;收益在交付階段開始產生後淨成本下降,過平衡點後才轉正。

• 初期幾乎全是成本,持續增加到最高點
• 交付階段可交付使用並帶來收益,沖抵成本,淨成本曲線掉頭向下(若是累積成本則會一直上升)
• 收益可能在專案集結束後好幾年才出現;專案集成本可能延續為運營成本
• 投入與收益持平(平衡點)之後,收益才成正值並超過成本

🎯 考點: 圖上看的是「淨成本」;收益在專案集交付階段開始抵銷成本。

§198 回顧:分析的是依賴關係,規劃的是實現路徑 (06:12:33)

核心: 分析 = 收益之間的依賴關係(右→左);規劃 = 收益實現的路徑(左→右)。

• 課堂填空:分析什麼、規劃什麼
• 分析為規劃做準備:先識別 → 分析依賴 → 規劃路徑
• 規劃也涵蓋收益如何交付、移交、維持的方式,但移交規劃只是局部
• 至此知道「怎麼做」與「什麼時候做」,接下來就是做

講師原話:「分析收益之間的依賴關係,從右向左;規劃出收益實現的路徑,從左向右。」

🎯 考點: 收益分析與規劃 → 分析依賴關係、規劃實現路徑。

§199 收益交付:依託元件完成 (06:15:52)

核心: 收益交付是依託元件來完成的:按收益管理計劃啟動、執行、關閉元件以交付預期收益。

• 回到專案集交付階段的三個子階段:元件授權與規劃、元件監督與整合、元件移交與收尾
• 專案從收益實現路徑中圈出來,在交付階段一個個發起
• 核心目的:按收益管理計劃交付預期收益
• 機會、關鍵指標、把進展記錄到登記冊等都是圍繞元件的次要活動
• 元件此起彼伏:一個未完成、下一個已啟動、第三個可能快收尾
• 收益交付階段相對簡單,基本就是按收益管理計劃交付收益

講師原話:「最主要的是收益交付是依託元件來完成。」

PMI 術語: Component Authorization and Planning ↔ 元件授權與規劃 / Component Oversight and Integration ↔ 元件監督與整合 / Component Transition and Closure ↔ 元件移交與收尾

🎯 考點: 收益交付的核心 → 透過啟動、執行、關閉元件來交付收益。

Part E (06:19:18 - 07:51:51) 綜述

這段接續收益管理績效域(Benefits Management Performance Domain),把收益生命週期後三段講完:收益交付(Benefits Delivery)→ 收益移交(Benefits Transition)→ 收益維持(Benefits Sustainment),再進入第二大績效域「干係人爭取」(Stakeholder Engagement)的五個活動:識別、分析、規劃爭取、爭取、溝通。

講課脈絡是:交付階段專案集經理(Program Manager, PgM)的角色從「親手做」轉成「監管與整合」,靠已定義的報告指標向 PMO/發起人/專案集指導委員會(PSC)彙報;執行中的變更以「糾正措施」形式出現,內容就三類:增加元件、終止元件、修訂元件。元件的啟動與關閉是路線圖上的重大里程碑,必須由 PSC 批准。移交部分強調移交計劃最晚在移交前要就緒、最早在收益分析與規劃時就開始考慮,並舉 DBOT、合資建廠、德國鐵橋等例子。干係人部分強調 engage 不是 manage、爭取高於溝通、權力利益方格四象限策略、問題日誌閉環,以及「爭取策略按每一類、溝通策略按每一個」。

最重要的考點判準: 1. 糾正措施=增加/終止/修訂元件,發生在收益交付階段;元件啟動/關閉需 PSC 批准,並同步更新路線圖(計劃值與實際值都要標)。 2. 移交計劃:最早在收益分析規劃時考慮,最晚在移交前必須完成;沒人接手的元件不移交但仍要收尾。 3. 維持階段題目若同時出現「收益維持計劃」與「收益管理計劃」,優先選維持計劃。 4. Stakeholder 搭配 engage、human resource 搭配 manage;PMO 一律是專案集的預設干係人,專案經理不在專案集團隊裡。 5. 溝通是爭取的基礎(heart ≠ 最重要);溝通策略量身定製到每一個人,爭取策略按類別。

§200 收益交付階段:PgM 從執行轉為監管與整合 (06:19:18)

核心: 交付階段大量工作交給元件(專案)經理,PgM 的工作變成「盯著他們做」,也就是監管與整合。

• 識別、分析規劃階段 PgM 做大量工作;到交付階段工作主要交給專案經理/元件來完成
• 對應專案集交付階段三個子階段中的第二個:監管與整合
• 收益交付的目的:監督元件的啟動、執行、移交與關閉;啟動和移交/關閉時 PgM 參與較多,因為要收結果
• 重點不是只看元件的可交付成果,而是看它產生的收益,並以收益的方式整合進專案集

PMI 術語: Benefits Delivery ↔ 收益交付 / Component Oversight and Integration ↔ 元件監管與整合

§201 報告與監控:按已定義格式向治理主體彙報 (06:21:13)

核心: 彙報鏈是 PM 向 PgM 匯報、PgM 整合後再向發起人/PSC/PMO 彙報,格式與指標在規劃時就已定義好。

• 專案經理向專案集經理彙報;專案集經理整合各專案情況,再向發起人(Sponsor)或專案集指導委員會(PSC)彙報
• 上級若有指示:需專案做的由專案經理落實,需 PgM 自己做的自己完成
• 報告和指標早已在專案集管理計劃/收益管理計劃中定義,按固定格式彙報,不是隨時定義
• 持續監督、持續彙報,直到專案集所有應產生的收益都交付出來
• 三個治理主體(PMO、發起人、PSC)透過指標觀察專案集健康度,指標從各元件彙集而來

PMI 術語: Program Steering Committee (PSC) ↔ 專案集指導委員會 / Sponsor ↔ 發起人

§202 交付過程是迭代循環:糾正措施三類 (06:22:42)

核心: 交付過程不會一帆風順,會出現大量變更,形成「增加/叫停/修訂元件」的迭代循環。

• 變更內容:該增加元件就增加、該叫停就叫停、該修訂就修訂,是一個循環過程,不是一次完成
• 過程中會出現大量風險(講師說讀一讀即可)
• 測量指標要與三方(PMO、發起人、PSC)確認好,並持續向他們彙報

🎯 考點: 看到「收益交付階段 + 外部環境變化」→ 想到糾正措施,內容就三類:增加元件、終止元件、修訂既有元件。

§203 考點:增加/變更/終止元件都透過變更請求提出 (06:23:35)

核心: 執行中元件的增加、修訂與終止,都以變更請求(糾正措施)的形式提出,發生在收益交付階段。

• 糾正措施意味著要增加某個元件、停止某個元件,或修正某些元件
• 這三個動作特別注意:發生在專案集收益交付階段;元件級的修改、風險等是其次
• 收益分析規劃與收益交付兩階段互動特別多:交付時出現條件/環境變化帶來變更
• 變更原因:外部環境或整體要求改變,例如抓住機會而增加元件、規避風險而調整整體

PMI 術語: Corrective Action ↔ 糾正措施 / Change Request ↔ 變更請求

🎯 考點: 「增加、終止、修訂元件」這組動作 → 收益交付階段的糾正措施。

§204 收益與元件:可交付成果只是中間產物 (06:25:14)

核心: 元件產生的可交付成果,在專案經理眼裡是結果,在 PgM 眼裡只是中間產物,要經過整合與使用才變成專案集收益。

• 元件產生的收益需要整合到專案集層面
• 可交付成果(deliverable)需要被整合、運用,才能轉化成專案集層面的收益

§205 元件的啟動與關閉是路線圖上的重大里程碑 (06:25:42)

核心: 元件啟動前路線圖只標收益時間點與關鍵里程碑;元件一啟動,其起止時間就必須登記到路線圖上。

• 路線圖上原本只展示收益時間點、關鍵里程碑,不展示尚未啟動元件的起止時間
• 只要有元件啟動,它的時間點必須登記上去;第二個專案來了也一樣
• 專案集中任何元件的開始與完成都是重大事件

PMI 術語: Program Roadmap ↔ 專案集路線圖

§206 元件啟動與關閉必須由 PSC 批准 (06:26:34)

核心: 元件的啟動與關閉都需要專案集指導委員會批准,發起人和 PgM 都不能單獨決定。

• 元件涉及資源、涉及產生的收益和結果,所以必須由最高層級批准才可開始與完成
• 啟動/完成元件時,對應管理計劃要同步修改(如路線圖資訊)——改的是狀態,不是內容
• 元件啟動與關閉不僅是技術活動,更是收益交付的重要標誌:啟動=給專案集創造實現收益的機會;關閉=要拿結果交給專案集
• 元件啟動與關閉一定要更新到專案集路線圖,路線圖在專案集管理計劃中

講師原話:「元件的啟動都需要專案集指導委員會來批准……發起人、專案集經理都不能夠單獨決定。」

🎯 考點: 「誰批准元件啟動/關閉?」→ PSC(專案集指導委員會),不是發起人、不是 PgM。

§207 考場反饋:第五版內容已滲透進考試 (06:28:05)

核心: 當天考完 PgMP 的學員反饋,第五版內容已開始滲透到考試中,題目很靈活。

• 靠刷題帶來的進展比例在降低
• 先理解整套體系再去考試效果更好

⚠ 新版變化: 講師根據考生反饋指出,Standard 5th 的內容已出現在現行考試中,題目靈活度提高。

§208 路線圖要同時標計劃與實際的啟動/關閉 (06:28:43)

核心: 元件啟動與完成在路線圖上有兩組:計劃的啟動/關閉,與實際的啟動/關閉,延誤也要展示出來。

• 計劃啟動點與實際啟動點可能一致,計劃關閉點與實際關閉點可能因延誤而不同,都要標
• 這樣在路線圖上能看出專案集所有元件的狀態
• 專案集管理計劃要與路線圖(尤其是相關計劃)保持同步,尤其涉及元件的開始與完成時

§209 收益與治理:用組織權力保障收益實現 (06:29:27)

核心: 治理是對組織資源與權力的分配,目的在保障收益能按期最大化實現。

• 收益是專案集管理最重要的核心活動,所以要用組織的權力和資源來保證收益完成
• 權力體現在批准、評審、終止、下達命令;有了治理框架,收益管理才能執行到位
• 行使治理權限的角色一定是非常清楚組織戰略的人和部門,站在專案集之外代表組織決策
• 治理的價值:保證戰略一致性、關注價值交付、防止專案集跑偏;在收益審查時賦予相關角色權力,協助建立關鍵績效指標
• 治理框架即治理計劃

講師原話:「治理一句話:治理是為了保障收益能夠按期最大化實現所分配的權力。」

PMI 術語: Governance Framework ↔ 治理框架 / KPI ↔ 關鍵績效指標

§210 收益移交:把收益交給運營方 (06:32:07)

核心: 移交是把專案集創造的收益順利交給接收方(運營方),接收方之後負責維持。

• 從 program 交到運營方,運營的是專案集產生的收益;運營方可以是組織內部或外部
• 接收方要整合協調收益,確定移交的職責與維持的職責
• 沒有好的移交,就不會有好的維持

講師原話:「沒有好的移交就不會有好的維持。」

PMI 術語: Benefits Transition ↔ 收益移交 / Receiving Organization ↔ 接收組織

§211 移交計劃:最早何時考慮、最晚何時就緒 (06:33:01)

核心: 移交前要驗證並關閉產生該收益的元件,並有移交計劃;此計劃最早在收益分析與規劃時就開始考慮,最晚在移交前必須就緒。

• 移交收益之前,要驗證和關閉產生這個收益的元件
• 移交階段是「不得不制定」移交計劃的最晚時間點
• 最早:在收益分析與規劃階段制定收益管理計劃時,就已開始初步考慮移交

講師原話:「(移交階段)是你的最終最晚完成時間,要求你在移交之前這個計劃就緒,這是不能再晚了。」

PMI 術語: Transition Plan ↔ 移交計劃 / Benefits Management Plan ↔ 收益管理計劃

🎯 考點: 問「何時開始考慮移交」→ 收益分析與規劃階段(收益管理計劃中);問「移交計劃最晚何時完成」→ 移交之前。

§212 移交到運營:培訓、手冊、輔導 (06:34:47)

核心: 收益可能移交給外部客戶或內部運維部門,好的移交要事先規劃培訓、手冊、輔導等內容。

• 例:軟體賣給客戶,要提供培訓、操作手冊,甚至一起操作輔導,客戶學會了你才能退出
• 學不會的話,你的工作會無止境地跟下去
• 好的移交在規劃時就要想好;移交前要有完整移交計劃,包含過程文件、培訓、指導,以及系統本身的交付

§213 案例:DBOT 專案與專案集移交的差異 (06:35:48)

核心: DBOT 是先運營後移交;正常專案集是建設完成後先移交、再由接收方運營。

• D=Design(設計整體方案、場地、機房),B=Build(建網路與系統),O=Operate(在客戶許可下代為運營、找客戶收費),T=Transition(達到約定盈利條件才接收)
• 講師親身經歷:運營兩年不一定盈利,不盈利得繼續運營,成本自付,屬極端案例
• 專案集管理中的移交發生在運營之前,接收方(客戶)接手後才運營
• 學了專案集管理,應以收益的形式移交,讓接收方「拎包入住」、拿來就用

講師原話:「如果我們學了專案集管理,你肯定以收益的形式交給他,就是這個東西有價值、可以拿來就用。」

§214 移交計劃的內容:範圍、接收方、測量、維持計劃 (06:38:25)

核心: 移交計劃要定義移交範圍、識別接收組織、測量當時的收益狀態,並與接收方一起制定收益維持計劃。

• 定義移交範圍;識別接收方(即便簽了合同,接收方內部可能是 A 部門、B 部門或多部門)
• 越早知道接收方越好,邀他一起編移交計劃,將來更容易上手
• 移交前要測量專案集當時的狀態,用資料證明已具備移交條件
• 與接收方一起制定收益如何維持的計劃——出現兩份計劃:先移交計劃、後維持計劃
• 要提供有價值的資訊,例如移交港口/醫院時,說明裝了什麼、操作注意事項、何時要升級周邊道路以免物流不暢
• 前面全是準備,準備就緒後才開始執行移交計劃

講師原話:「移交計劃、維持計劃這兩個有先後,先移交後維持。」

PMI 術語: Benefits Sustainment Plan ↔ 收益維持計劃

§215 移交的時間點:元件完成、執行中、專案集結束都可以 (06:41:06)

核心: 移交可在某元件完成後、專案集執行中(部分功能已可用)或整個專案集完成後進行,取決於與接收方的約定。

• 專案集還沒結束,某專案完成就可以開始移交
• 甚至元件未關閉,但部分功能可用,也可開始移交
• 也可整個專案集做完再移交;移交哪些、不移交哪些由雙方約定

§216 例子:合資建廠與航母——移交內容要事前談好 (06:41:40)

核心: 移交什麼(生產線、核心技術、人才培養)要在前期談好,但談好不代表做得到。

• 中國汽車業合資建廠:合作期結束後生產線、核心技術、人才是否移交,都要前期談妥
• 實際上合資很少真正移交核心技術,最後仍要走自主研發
• 航母(瓦良格號)例子:只移交了船體,不給圖紙

§217 中間收益也要移交:內部移交 (06:43:00)

核心: 只為其他元件提供成果、不產生最終收益的元件,也要做內部移交(給其他元件或 PgM),它產生的是中間收益。

• 可由 A 專案移交到 B 專案,或由 A 專案移交到專案集,整合後再交給 B 專案
• 涉及知識傳遞、成果延續,都屬於 transition

PMI 術語: Intermediate Benefits ↔ 中間收益

🎯 考點: 元件只產出中間成果 → 仍需移交(內部移交),不是「不必移交」。

§218 考點:移交時間點與移交關鍵活動 (06:43:45)

核心: 移交可能在元件關閉時、專案集結束時,甚至專案集關閉後很長時間才發生;移交前要檢查績效、驗收標準、文件、風險與資源。

• 時間點:元件關閉(在專案集中間)、專案集結束,或專案正式工作結束之前、專案集關閉後很久都有可能
• 移交前檢查:現在績效是否具備條件、驗收標準是否達成、要移交的文件是否符合合同條件
• 風險是否梳理清楚、要不要移交出去;資源要不要釋放
• 接收方有時會把專案集團隊成員一併要走(例:外包商退出後直接留用其人員)

🎯 考點: 移交的時間點不固定,選項出現「只能在專案集結束時移交」通常是錯的。

§219 接收方多樣:內部、外部、另一個專案集 (06:45:26)

核心: 接收方可能不止一家,要確認誰接收整體或部分收益;有內部移交、外部移交,也可能移交給另一個專案集。

• 內部移交(如中間收益)、外部移交給客戶、移交給組織內其他部門
• 可能移交給另一個專案集,該專案集可能在組織內或其他組織
• 一般移交給運營/運維;特例是接收方沒有運營隊伍,由另一個專案(臨時活動)接手

§220 沒有人要也要收尾 (06:46:32)

核心: 也有不向運營移交的情況(沒人要、專案終止),但不移交不代表不收尾。

• 沒人要時,工作仍要收尾:總結經驗教訓,記錄非正常關閉的原因

講師原話:「沒有人要的時候不移交,不代表不收尾,這個大家記得了。」

🎯 考點: 元件/專案集被終止、無接收方 → 仍執行收尾(經驗教訓、記錄終止原因)。

§221 移交清單:剩餘資金、未關閉風險與合同 (06:47:04)

核心: 移交時要檢查剩餘資金、未關閉風險、未關閉合同;合同與財務必須關閉,剩餘資源退回;遺留風險可轉移給組織內其他部門承接。

• 未關閉合同必須關閉,財務必須關閉,剩餘資源退回
• 影響收益實現的風險若仍存在,要轉移到適當組織;客戶通常只要收益不要風險
• 專案集終將解散,所以由組織指定單位(例如 PMO)接手專案集遺留風險

🎯 考點: 專案集關閉時仍有影響收益的遺留風險、接收方不願承擔 → 轉移給組織內適當部門(如 PMO)管理。

§222 移交圖示:多次移交 (06:48:12)

核心: 元件產生收益後可直接移交給接收方,不必等整個專案集結束;專案集結束時再做一次總移交,所以有多次移交時間點。

• 內部:交給發起人或其他專案;外部:交給客戶
• 專案集真正結束時,整體再做一次總移交

§223 收益維持:接收方開始主導 (06:48:44)

核心: 交出去之後,接收方依據雙方一起制定的收益維持計劃把收益維持下去,接收組織佔主導。

• 責任移轉後仍可繼續關注,用得好未來合作機率更大
• 專案集結束後人都解散了,但可以找到接收組織繼續執行維持活動,確保收益持續產生
• 收益維持計劃可以是獨立文件,也可以是收益管理計劃的一部分

PMI 術語: Benefits Sustainment ↔ 收益維持

§224 做題:維持計劃 vs 收益管理計劃 (06:50:03)

核心: 確定處於維持情境時,選項同時有收益維持計劃與收益管理計劃,優先選收益維持計劃;沒有維持計劃才選收益管理計劃。

• 兩者都對,但維持計劃更精準,因為現在做的就是維持
• 收益管理計劃中也包含告訴接收方如何維持的規定與方法
• 維持計劃在專案集關閉之前一定要制定完畢

講師原話:「這兩個計劃都對的,要優先選擇維持計劃,因為你現在做的事情就是維持。」

🎯 考點: 維持情境 → 首選「收益維持計劃」;選項無此計劃時 → 選「收益管理計劃」。維持計劃須在專案集關閉前完成。

§225 維持中的變革管理:提醒接收方規劃變革 (06:50:57)

核心: 維持涉及的變革發生在接收方一側,專案集不是殺進去幫客戶做內部變革,而是提醒接收方規劃組織、流程上的變革。

• 場景已轉到接收方,替客戶做內部變革很麻煩,通常也不被允許
• 應提醒接收方規劃變革,讓收益在他接手後能持續;否則收益到他的環境中「水土不服」,很快停止

§226 案例:德國鐵橋的維護信 (06:52:03)

核心: 為讓收益長期延續,專案集要替接收方考慮好維護材料、操作文件與人才培養。

• 傳聞(講師說未驗證):德國人在天津或上海建的鐵橋,移交多年後,施工方寫信告知業主該維護了,維護材料就用油紙包著放在某橋墩下
• 除了材料儲備,還有大量操作文件(用多大力量、多少號螺母、哪種扳手)以及提前培訓
• 講師強調這不是核心內容;核心是接收方把收益維持下去

§227 責任歸屬:超出 project 生命週期,但在 program 生命週期內 (06:54:27)

核心: 收益維持的責任在接收方,超出傳統專案生命週期;但專案集仍有義務延續一段時間,支援接收方直到其能自行運營。

• 收益維持具長期性,專案結束後,專案集的人員與服務仍延續一段時間
• 內部、外部接收組織或另一個專案集都可能接收;無論誰接收,收益維護都屬運營類工作
• Standard 的說法:超出傳統專案管理者的生命週期,但可能仍在專案集生命週期之內
• 其餘活動(規劃必要變革、監督自身收益實現)是接收方在做,沒有特別重要的考點

講師原話:「雖然專案結束了,但是專案集的責任在移交這個活動之後,甚至到維持階段仍然保持,有一定的義務去幫助接收方。」

🎯 考點: 維持責任主體=接收組織;但專案集在維持期仍提供支援,直到接收方能完全處理。

§228 收益管理績效域與其他原則、績效域的關係 (06:56:58)

核心: 收益管理與「收益實現」原則、干係人原則相關,與協作、干係人爭取兩績效域聯繫較緊,但實際上六大績效域彼此都有聯繫。

• 移交與維持對應接收方,所以與干係人相關
• Standard 指出與協作績效域、干係人參與績效域聯繫比較緊密
• 簡化記憶:每個績效域都和另外五個績效域緊密相關

⚠ 新版變化: 第五版以八大原則+六大績效域組織,講師提醒各績效域之間互相關聯。

§229 干係人爭取績效域:從 management 到 engagement (06:58:20)

核心: 干係人部分和 PMP 差別不大,主要是用詞變化:從「管理」改為「爭取/參與」(engagement),共五個活動。

• 專案集管理很早就用「爭取」概念,PMBOK 後來也切換到 engagement
• 「爭取」和「參與」講師兩個都用,語境不同,不要機械地認定只有一個翻譯正確

PMI 術語: Stakeholder Engagement ↔ 干係人爭取/參與

⚠ 新版變化: 用詞從 stakeholder management 轉為 stakeholder engagement。

§230 爭取的目的:Foster 支持、降低抵制 (06:59:32)

核心: 干係人爭取的重點在於管理期望與溝通,以培養(foster)干係人的支持、降低抵制;真正的爭取還高於期望管理與溝通。

• 基本手段:管理期望、保持密切溝通
• 高階形態:社交層面接觸、了解個人喜好與理想、一起促成他想做的事,在工作基礎之上建立相互認同與信任
• 考試多考較初級內容,但理解精髓不能只停在那一層

講師原話:「我們這麼做的目的是為了讓他們支持我,不是讓他們反對我。」

PMI 術語: Foster ↔ 培養/促進

§231 專案集干係人的特點:層級更高、衝突更激烈 (07:01:19)

核心: 專案集承接組織戰略目標,干係人層級、權力、影響力更高,訴求更難滿足、衝突更激烈;活動與過程和專案幾乎一樣。

• 唯一不同點:級別更高、影響更大、矛盾更激烈、平衡更困難
• 干係人有內有外、有積極有消極

§232 干係人是動態的;人不能被管理,期望可以 (07:02:01)

核心: 同一干係人在不同階段態度可能不同,也可能出現或退出;人不能被管理,但期望可以被管理。

• 早期支持、中期反對完全可能;權力與影響力也會隨其自身情況變化
• 用 human resource(人力資源)時意味可被管理;用 stakeholder 時不能被管,只能協商、溝通、爭取支持

講師原話:「人是不能被管理的,但是他的期望值可以被管理。」

🎯 考點: 選項用詞判斷:stakeholder 搭配 engage/爭取;human resource 搭配 manage。

§233 專案集干係人環境與預設干係人 (07:03:39)

核心: PgM 的預設重要干係人是發起人、專案經理及其團隊、PMO;專案經理不在專案集團隊裡。

• 專案集干係人層級高、權力利益高,也包括監管層與外部政府、行業協會、商會
• 預設重要干係人:發起人,然後是專案經理和他的團隊
• 專案經理不在專案集團隊中
• 任何時候提到 PMO,都是專案集/PgM 的預設干係人

講師原話:「記住專案經理不在專案集團隊裡,這是他的核心的一個問題。」

🎯 考點: 題目問 PMO 的身份 → 專案集的干係人;專案經理屬於元件團隊,不是專案集團隊成員。

§234 干係人爭取的核心活動:評估、匹配、監督反饋、支援培訓、雙向溝通 (07:04:48)

核心: 要持續評估爭取行動是否有效、依干係人特點匹配爭取活動、監督的是干係人的反饋而非人本身,並堅持雙向溝通。

• 依干係人層級匹配不同的爭取活動(高層與一般人員做法不同)
• 監督的是我們爭取行為是否到位、干係人對我們的反饋;監督事可以,監督人不成立
• 支援與培訓:向團隊、接收方傳遞技能,也是爭取的手段
• 雙向溝通是原則性問題,不要只保持單向

🎯 考點: 「監督干係人」類選項要辨別:監督的是干係人參與/反饋,不是監視人。雙向溝通優於單向。

§235 爭取高於溝通;爭取面臨的阻力 (07:06:24)

核心: 溝通是資訊傳遞;爭取還要透過磋商達成一致,讓干係人真正提供資源支持,才算爭取到位。

• 只溝通、對方不同意 → 爭取不足;達成一致且實際給予資源支持 → 爭取到位
• 專案集要改變很多事,會受到來自個人、變革方面的阻力
• 要充分了解並分析干係人,才能把他們爭取成支持者
• PgM 首先應是變革的倡導者

§236 專案集成員也是干係人:engage vs manage 的搭配 (07:07:50)

核心: 專案集成員也是干係人;當作干係人時用 engage(滿足其要求),當作人力資源時用 manage(使用他)。

• 同一個人,視為干係人時預設要滿足他的要求;視為資源時就可以管理、使用
• 爭取的核心思想:尋求支持、降低對我們和專案集的抵制

§237 五個爭取活動總覽 (07:08:52)

核心: 五個活動依序為識別、分析、規劃爭取、爭取、溝通;前四個邏輯順序很清楚,溝通是最基礎的手段。

• 識別 → 記錄到干係人登記冊;分析 → 結果也記在登記冊
• 規劃 → 不同干係人的爭取策略寫進干係人爭取計劃
• 執行爭取時資訊變化(增減、態度改變)要更新登記冊與爭取計劃
• 溝通基於問題,問題日誌成為基本文件
• 爭取不僅是溝通,更強調把人拉過來支持你

PMI 術語: Stakeholder Register ↔ 干係人登記冊 / Stakeholder Engagement Plan ↔ 干係人爭取計劃 / Issue Log ↔ 問題日誌

§238 識別干係人:系統化、全面識別 (07:10:39)

核心: 受專案集影響、能影響專案集、或自認為受影響的都是干係人;識別要系統化、全面、無死角。

• 干係人邊界其實模糊,但定義清楚:影響、受影響、自認為受影響
• 全面識別不代表全面跟蹤——挑出主要的高頻互動,不重要的不必特別關注
• 登記冊記錄干係人與專案集的關係、影響結果的能力、支持程度等

🎯 考點: 識別階段要「系統化、全面」;管理/互動階段才依優先順序聚焦。

§239 干係人登記冊:敏感資訊要設訪問限制 (07:12:11)

核心: 干係人登記冊含敏感個人資訊,不能對全員公開,必須設定訪問限制;且要經常更新。

• 例如客戶住址、房產、政治傾向、宗教信仰,未經允許不能公開;特殊身份者更要注意
• 原文用 restriction(訪問限制)、sensitive information(敏感資訊),中譯後重點容易消失
• 登記冊範例欄位:姓名、組織內職位、專案集中的角色、權力高低、利益/興趣高低、期望的溝通方式

講師原話:「這個登記冊不能夠對所有人都開放,你要設定適當的保護措施。」

🎯 考點: 干係人登記冊有敏感資訊 → 限制存取(restricted access),不是公開給全體團隊。

§240 識別技術:頭腦風暴、專家判斷、德爾菲 (07:14:18)

核心: 頭腦風暴用於大量、快速、發散地收集干係人;專家判斷/德爾菲法用來識別更重要的干係人。

• 頭腦風暴:發散、自由聯想、不加評判
• 德爾菲法:專家判斷的一種

PMI 術語: Brainstorming ↔ 頭腦風暴 / Expert Judgment ↔ 專家判斷 / Delphi Technique ↔ 德爾菲法

§241 例子:出海企業的關鍵干係人——駐外使館 (07:14:48)

核心: 以專家判斷為例:中資企業出海,不論大小都有一個關鍵干係人——駐外大使館。

• 使館中有負責政府關係、軍隊關係、商貿往來的角色,關鍵時刻能提供重要資訊與便利
• 講師建議做海外專案盡量與駐外使館建立良好關係

§242 登記冊是動態文件;洋蔥圖 (07:16:13)

核心: 干係人登記冊是動態文件,新干係人會出現、舊的會退出,權力利益會變化,要隨時更新。

• 方法:頭腦風暴、德爾菲、洋蔥圖(依關係由近到遠分層)

PMI 術語: Onion Diagram ↔ 洋蔥圖

§243 分析干係人:分類與需求期望 (07:16:42)

核心: 分析是把登記冊中的人、群體、組織分類,並分析其需求期望、影響力與利益,工具常用權力利益方格。

• 分析內容:需求與期望、影響力、專案成敗對他利益的影響、級別、社會地位
• 最基本的分類:內部/外部、積極/消極
• 目的:看清楚對方,知道如何相處、如何爭取

§244 資訊收集方法與優先順序排序 (07:17:31)

核心: 用歷史資訊、個人訪談、焦點小組、問卷調查收集資訊,再對干係人排優先順序,更新到登記冊。

• 時間不能平均分給所有干係人,效率和效果都不好
• 排序後的干係人列表更新進干係人登記冊,工作重心轉到重點干係人

§245 平衡、開放式問題與四個工具 (07:18:22)

核心: 要減輕消極干係人的負面作用、增強積極干係人的貢獻;了解干係人時用開放式問題。

• 不能只關注負面,也不能只關心積極方面
• 開放式問題(「你怎麼看?」)比是非題能收集更多、更有價值的反饋
• 四個工具幾乎都考:問卷調查(干係人多時)、焦點小組(特定主題討論)、個人訪談(one-to-one interview)、歷史資訊

🎯 考點: 干係人數量多 → 問卷調查;特定主題 → 焦點小組;深入個別 → 一對一訪談;收集資訊時優先開放式問題。

§246 權力利益方格:四象限策略 (07:19:31)

核心: 干係人落在哪個象限,爭取策略就隨之確定。

• 高權力高利益:重點管理(積極爭取,manage closely)
• 高權力低利益:令其滿意(keep satisfied)
• 低權力高利益:隨時告知(keep informed)
• 低權力低利益:監督(monitor),了解情況即可

PMI 術語: Power/Interest Grid ↔ 權力利益方格

🎯 考點: 四象限策略要背熟,題目給出權力/利益描述即可直接對應策略。

§247 干係人地圖 vs 權力利益方格 (07:20:30)

核心: 干係人地圖範圍比權力利益方格廣(三到四個維度 vs 兩個維度),適合複雜專案集,可呈現干係人當前與期望支持水平及彼此互動。

• 權力利益方格是干係人地圖的簡化替代版
• 干係人地圖可作為評估工具,協助決定用什麼方法、在什麼時點爭取誰
• 例如最終舉手表決時,和過程中深入討論時,採用的手段不同

PMI 術語: Stakeholder Map ↔ 干係人地圖

🎯 考點: 複雜專案集、需呈現多維度與干係人間互動 → 干係人地圖;簡單兩維 → 權力利益方格。

§248 干係人位置會變:提拔案例與關係連線 (07:22:32)

核心: 干係人位置會變化,策略要隨之調整;干係人地圖還能連出干係人之間的關係,找到爭取的切入點。

• 例:原本低權力低利益的辦事員被提拔後,專案集剛好落在他的管理範圍 → 變成高權力高利益,策略要改
• 地圖上可標同學、好友、不合、常一起吃飯等關係,找到爭取某人的特別方法
• 講師經驗:了解客戶喜好、行為習慣乃至行動路線,以建立聯繫

§249 規劃干係人爭取:策略 vs 計劃 (07:24:38)

核心: 綜合登記冊、干係人地圖、專案集在組織戰略中的地位與環境,產出干係人爭取計劃;該計劃有策略與詳細計劃兩個層次。

• 爭取計劃不是干係人清單,而是基於清單為每個人(早期至少每一類)確定爭取策略
• 第一層:只確定策略(strategy),不排具體行動
• 第二層:需要時排出每天/每週/每月要做什麼,才叫計劃
• 內容主要是指導方針(guideline/insight),說明如何在專案集各元件中爭取干係人

🎯 考點: 干係人爭取計劃可以是策略層的指導方針,也可以是細節層的行動計劃,依專案集需要而定。

§250 衡量爭取效果的三個指標 (07:27:14)

核心: 衡量干係人是否被爭取到,最常見的三個指標:是否出席會議、支持/抵制程度、參會但是否發表意見與表現興趣。

• 干係人爭取計劃最主要提供兩樣東西:如何爭取的方法,以及衡量是否爭取到的指標

🎯 考點: 爭取計劃=爭取方法+衡量指標;出席率、支持度、參與意見都是指標。

§251 案例:海外拓展專案集的高層爭取策略 (07:28:19)

核心: 為不同類別干係人(高層、海外市場部、當地合作夥伴)分析權力利益後定級別與策略,並配上可量化指標。

• 對高層:每月舉行戰略彙報會,讓他深入了解進展並聽取意見,讓他感覺被重視
• 量化指標例:支持度 30 分、參與戰略決策頻率 20 分、資源調配滿意度等(講師說不只四個)
• 指標可用來評估專案集內負責對接高層者的工作,也可讓發起人評估專案集的爭取成效
• 爭取計劃=爭取策略+衡量指標兩項

§252 執行爭取:「充分且適當」不等於平均投入 (07:30:36)

核心: 爭取就是照干係人爭取計劃執行,是貫穿專案集的持續活動;確保所有干係人得到充分且適當的爭取,不代表投入相同時間。

• 重要干係人投入更多時間;策略、方法要匹配干係人身份

§253 案例:專機請最終決策者見董事長 (07:31:01)

核心: 最終決策者遲遲不簽字,安排他從阿聯酋飛回中國與董事長會面才簽約——爭取程度要與干係人身份相匹配。

• 對方認為在最高層、萬眾矚目的情境下談成,代表對專案的重視,交付時雙方會投入更多
• 前提是方案、報價等鋪墊工作都到位;對方不會明講期望,要自己揣摩
• 同樣做法若用在中層身上就明顯不合適

§254 動態更新;第一招:傳遞利益 (07:33:22)

核心: 要持續更新干係人資訊、登記冊、爭取計劃與地圖;教科書指出爭取干係人最好的方法是傳遞利益(他關心的面向的良好進展)。

• 不同干係人對專案集訴求不同;他關注哪方面,就把那方面的良好進展告知他,讓他持續深入參與
• 講師口訣:第一招「訴諸利益」

🎯 考點: 「爭取干係人最好的方法」→ 傳達專案集對其目標/利益的好處。

§255 第二招:溝通、談判(協商)、衝突解決 (07:34:01)

核心: 第二招是一招三式:溝通、談判、衝突解決。多元干係人的專案集可能需要引導式協商(facilitated negotiation)。

• negotiation 譯「談判」語氣強,有時譯「協商」更友好,英文都是同一個詞

PMI 術語: Facilitated Negotiation ↔ 引導式協商/談判 / Conflict Resolution ↔ 衝突解決

§256 管理期望:好壞都講,建立共同期望 (07:35:31)

核心: 讓干係人對專案集有合理期望,彙報時好壞都講,並以章程目標、商業論證收益建立共同的高層級期望。

• 既不過高也不過低;只報喜不報憂會讓期望失真
• 用專案集章程中的目標、商業論證中的收益說服干係人,建立共同認識
• 三招總結:訴諸利益 → 溝通/談判/衝突解決 → 獲得支持、平息抵制

PMI 術語: Program Charter ↔ 專案集章程 / Business Case ↔ 商業論證

§257 補充:雙贏思維與衝突解決五策略 (07:36:23)

核心: 談判有贏贏、贏輸、輸贏、輸輸四種策略;衝突解決有五策略,合作最好,但要依情境選擇,不要一上來就選。

• 衝突解決五策略:強迫、妥協、撤退、緩和、合作
• 合作雖是最好的方法,但不代表適合所有情形

🎯 考點: 衝突解決題不要反射選「合作」,先判斷情境(時間、權力、議題重要性)。

§258 爭取指標:參會頻度下降是警報 (07:37:02)

核心: 指標包括干係人與專案集團隊的互動記錄;干係人參會頻度降低一定要分析背後原因並解決。

• 指標要依干係人對專案集目標的影響、權力與地位設定
• 干係人不來開會不是好現象,不管是放心還是不滿意,都要找出原因
• PgM 可用這些指標判斷團隊成員表現,發起人可用來判斷 PgM 表現

🎯 考點: 關鍵干係人開始缺席會議 → 先分析原因(與其溝通了解),而非忽略或直接升級。

§259 問題日誌:記錄、排序、閉環 (07:38:49)

核心: 干係人提出的問題與關切要記入問題日誌、排優先順序、跟蹤直到閉環,才不會失去干係人信任。

• 問題來源不同(直屬主管、高層客戶),優先順序與處理方法也不同
• 最簡單的形式是電子表格;有更好的工具(AI、雲端工具)就用
• 干係人少用表格即可;多時要有優先排序機制,甚至用更高階的電子化工具

PMI 術語: Issue Log ↔ 問題日誌

§260 問題處理:影響分析,可能轉成風險 (07:40:00)

核心: 每個問題要記錄、排序、跟蹤至關閉並告知結果;處理前先依緊迫性與可能性做影響分析,可能轉為風險的就交給風險管理。

• 順序:記錄 → 排序 → 影響分析 → 處理 → 跟蹤關閉 → 告知
• 問題若可能轉化為風險,就進入風險管理,不再屬於干係人問題管理

§261 溝通:狹義的資訊傳遞 (07:41:11)

核心: 專案集管理(包括 PMP)中的溝通是狹義的,只強調資訊按需求準時送達,不強調對方是否認同或滿意。

• 例:對方要求週一早上八點收到報告,準時給他就完成溝通
• 認可、滿意屬於爭取的範疇
• 優秀溝通者要了解對象的文化背景、組織背景、專業水準、觀點與利益訴求

講師原話:「溝通強調資訊的交換,不強調相互的認同,相互的認同那是在爭取這個概念去談。」

§262 Communication is at the heart:基礎,不是最重要 (07:42:42)

核心: 「溝通是干係人爭取的核心」的「核心」是指基礎;爭取(支持、一致、投入資源)層級比溝通更高。

• 資訊傳遞到位,不代表別人認同、支持你

講師原話:「不用被大家誤解他是最重要的那部分,其實他是最基礎的那一部分。」

PMI 術語: Communication is at the heart of stakeholder engagement ↔ 溝通是干係人爭取的核心(基礎)

§263 資訊載體、透明與情緒 (07:43:39)

核心: 資訊可用文件、語音、電話、郵件等載體;在不涉密前提下盡量透明分享,溝通可建立信任、協調期望、解決衝突。

• 資訊捂著不放,別人會產生不必要的猜測
• 與干係人溝通要關注對方想要什麼,先處理情緒,不是一味用邏輯說服

§264 溝通策略對「每一個人」,爭取策略對「每一類」 (07:44:35)

核心: 溝通策略要為每一個干係人量身定製(crafted for each stakeholder);爭取策略則是按類別(如重點管理)。

• 例:CEO 與 CTO 同屬高權力高利益,爭取策略都是重點管理(manage closely)
• 但溝通不同:CEO 要圖形化的電子報告;CTO 要列印出來的表格與數字
• 語言、格式、內容、詳細程度依人而異,且偏好可能隨工作變化而改變

講師原話:「溝通強調的是對每一個干係人制定他的策略……而爭取不同,爭取是為每一類人,而溝通是對每一個人。」

🎯 考點: 同象限兩位干係人要不同報告格式 → 溝通策略量身定製;爭取策略仍是同一類(重點管理)。

§265 有效溝通策略的考量與溝通記錄 (07:47:35)

核心: 有效溝通策略要考慮干係人偏好、資訊需求、接收能力、文化背景,確保資訊及時準確送達——這只是滿足溝通需求,還不是期望管理。

• 溝通要記錄下來(包括問題與答案),使其被捕捉並發布
• 文件可能要針對不同干係人用不同格式呈現(圖或表、表的欄位順序、紅黃綠燈),客戶常要求按其格式提供

§266 溝通記錄支援決策,也要監控 (07:48:49)

核心: 決策干係人在正確時間獲得足夠資訊,做出正確選擇的機率就高;溝通記錄是典型文件,過程中要監督與控制。

• 溝通前要看登記冊了解干係人特點,為不同干係人定製溝通策略
• 溝通策略 ≠ 爭取策略,兩者要分清

§267 干係人爭取與其他原則/績效域;干係人多樣性 (07:49:46)

核心: 干係人爭取與其他原則、績效域都有聯繫;要盡全力了解干係人的多樣性(內外、積極消極、背景、教育、成長環境)與特定關注點。

• 了解干係人關注點與代表性觀點,才知道如何打交道
• 例:客戶熱愛世界盃/英超,補足球知識就能建立聯繫、拉近關係,再談專案更容易開口
• 多樣化干係人並維持強健關係非常重要