Ch15 — 新版精講 績效域 治理 協作 與生命週期 (189 min)

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

產製方式: 章節切 2 段交給 2 個 agent 平行逐段精煉, 共 108 個 §N (Part A: §1-51, Part B: §52-108).

Part A (00:00:02 - 01:34:10) 綜述

本段先以幾分鐘收掉「專案集干係人參與(Stakeholder Engagement)」績效域,接著用約一小時完整講完 Standard 5th 的「治理框架(Governance Framework)」績效域,講完後當天下課;第二天上午從 3.7「協作(Collaboration)」績效域開講,講到協作的成功因素與同理心(Empathy)為止。

治理部分依標準的五個模組展開:①定義與目的(治理=權責體系+決策層級+監督機制,是保駕護航的「手段」);②治理層級(組織/組合 → 專案集 → 元件,上對下做決策評審,下對上做報告升級);③ 10 個治理實踐(原 12 個,健康檢查併入評審):治理計劃、與組織願景對齊、批准/認可/定義、監督報告控制、問題與風險、質量、變更、評審、元件啟動與移交、收尾;④ 6 種治理角色(發起人、指導委員會、PMO、專案集經理、專案經理、其他干係人);⑤ 治理框架的設計、裁剪與實施。

協作部分:區分協作(人與人)和協同(事與事);授權是協作的前提;專案集協作圍繞收益與跨元件;左手領導力、右手管理,換來適應性與韌性;影響協作的因素有參與/對齊/複雜性、透明度/協商/文化,以及同理心。

最重要的考點判準: 1. 元件的啟動、增加、減少、移交,以及專案集收尾的開始和結束,都由專案集指導委員會批准。發起人、專案集經理、CCB 在專案集層面的地位都低。 2. 商業論證、專案集章程、專案集管理計劃都由指導委員會最終批准;只有在委員會休會又很緊急時才找發起人。 3. 專案集風險會複合(compound),碰到風險閾值必須升級。 4. 同理心在考題中幾乎 100% 是正確選項的方向。 5. 戰略一致性是北極星(指方向),收益管理是地圖(指路徑)。

§1 干係人參與績效域收尾 (00:00:02)

核心: 干係人參與的核心價值是識別、分析、用策略爭取並溝通高層干係人,從側面保證戰略一致性和收益最大化。

• 有效溝通=切換到對方(客戶、領導)喜歡的風格;即使不喜歡也要練出這個能力
• 跟專案的干係人管理沒有本質差別。差別在於層面高、干係人級別高、利益訴求高、相互衝突多、體量大
• 干係人參與和戰略一致性、收益管理、協作、治理都緊密相連

§2 治理框架績效域導入:名稱與結構 (00:01:43)

核心: 治理是近年熱門趨勢。5th 把這一章改名為「治理框架」,共 5 個模組,第 2~4 模組最重要。

• 趨勢:最近兩年治理題非常多;新版 PMP(PMBOK 8)已把「整合」拿掉、換成「治理」
• 改名:舊版叫 Program Governance(治理管理),新版叫 Governance Framework。講師認為新名稱強調「建立整套治理模式」,比單談治理更具象
• 模組 2:治理實踐從 12 個降為 10 個(取消一個、改變一個、調整一個)
• 模組 3:6 種角色,分別是發起人、指導委員會、PMO、專案集經理、專案經理、其他干係人
• 模組 4:如何設計治理框架,以及如何實施落地

PMI 術語: Governance Framework ↔ 治理框架

⚠ 新版變化: 4th 的 Program Governance 在 5th 改為 Governance Framework 績效域;治理實踐由 12 個減為 10 個。

§3 治理框架的定義:權責、層級、監督 (00:03:11)

核心: 治理框架=建立權力體系 + 決策層級 + 監督機制。凡屬於這三類的事情,都歸入治理。

• 標準定義:確立支援專案集的實踐方法並監督專案集,以滿足組織的戰略與營運目標,同時交付收益
• 權能分配:角色、責任、權力(Roles, Responsibility and Authorization)
• 決策層級:誰來批准、批准什麼層級(Level 1/2/3、總經理層、指導委員會層)
• 監督機制:什麼時候提交什麼報告、過程中由誰執行監督

§4 治理是手段:保駕護航,以及四個治理層級 (00:04:32)

核心: 分配權責、確定層級、建立節奏機制都是「手段」,目的是為專案集實現收益和戰略目標保駕護航。

• 治理為三件事保駕護航:戰略一致、有效決策、監督與支援
• 治理分層:組織治理 → 組合治理 → 專案集治理 → 元件治理。沒學組合也沒關係,可以把組合視為代表組織
• 每一層在自己的領域建立權責體系、決策層級與監督機制:組合治理專案集,專案集治理專案,專案經理治理專案內部

PMI 術語: Component Governance ↔ 元件治理 / Organizational Governance ↔ 組織治理

§5 組織治理 vs 專案集治理 (00:06:16)

核心: 專案集治理可以是框架、功能或流程,用來監督、管理、支援專案集活動,以滿足組織的戰略與營運目標。

• 組織治理是整個公司層面的結構化方法
• 專案集治理用系統化的方法框架,為專案集執行保駕護航
• 形式三選一或並存:框架(framework)、功能(functions)、流程(processes)
• 本頁的例子僅供參考,沒有考點

§6 治理的三大核心功能 (00:07:14)

核心: 治理本質上解決的是「權力問題」。權力是用來保證目標實現的,不是用來展現身份的。

• 功能一:決策有依據、有正式流程與正式授權,確保在正確的決策層級、在授權範圍內及時做出正確決策
• 功能二:確保專案集內提倡的實踐(標準方法論、流程、工具技術)真正被執行;不照做會受到治理層干預
• 功能三:賦予專案集監督的權力。透過持續監督與審查保持戰略一致,並及時處理問題、風險、變更
• 環境越複雜、越不確定,有效又高效的治理流程越關鍵,因為它能讓組織快速做出正確決策,並透過適應性調整持續交付收益

§7 專案集治理必須遵循組織治理 (00:09:44)

核心: 組織已有治理就遵循(可以調整);組織沒有治理就自己建立。

• 專案集內部的治理框架必須遵循組織的要求
• 專業做法:在組織治理框架的範圍內,客製化專案集獨特的治理實踐
• 偷懶的做法:直接套用公司框架

🎯 考點: 情境題問專案集治理怎麼定 → 先遵循組織治理框架,再在其範圍內裁剪/客製化。

§8 治理結構圖:上下雙向,箭頭 B 與 C (00:10:09)

核心: 由上而下是下指令、提要求、監督、做決策;由下而上是做報告、提申請、升級問題/風險/變更、交付成果與能力。

• 結構分三層:組合級(含組織)、專案集級、元件級
• 由上而下:建立政策、要求採用相同實踐、行使監管權、開展控制、整合、決策
• 由下而上:報告、分析、提交請求、升級問題與風險、向上交付結果與能力
• 圖中 B 與 C 的內容一樣,只是代表升級的來源層級不同:B 是專案集 → 組合(或子專案集 → 專案集);C 是專案 → 專案集(或專案 → 子專案集)

§9 PMO 在專案集治理中的位置 (00:12:19)

核心: 考試時記住 PMO 是一個「治理實體」,屬於 6 種治理角色之一。

• 完全屬於專案集的 PMO:代表專案集經理向下行使治理職權,包括建立標準流程與模板、資源管理、合約管理
• 由組合 PMO 下派的專案集 PMO:橫向服務專案集經理,縱向向組合辦公室彙報,形成矩陣式的雙重關係

§10 治理四動作:批准、評審、簽署、監督 (00:13:54)

核心: 所有治理行為都離不開四個動作:批准、評審、簽署、監督。

• 組合向下管專案集,專案集(指導委員會)向下管專案,一層管一層
• 由上而下是決策和評審;由下而上是彙報、請示、升級
• 擴展來看,治理為戰略一致性提供權力基礎、為收益交付提供保障、為干係人參與提供最佳實踐、為生命週期的關口評審提供權力基礎

PMI 術語: approve ↔ 批准 / review ↔ 評審 / endorsement ↔ 簽署、背書 / monitor ↔ 監督

§11 十個治理實踐總覽 (00:15:13)

核心: 10 個治理實踐是治理框架的核心內容:治理計劃、與組織願景/目標對齊、批准/認可/定義、監督/報告/控制、問題與風險、變更、質量、評審(含關口評審)、元件啟動與移交、收尾。

• 問題、風險、變更、質量是標準特別強調的四類強制治理對象
• 關口評審要規定好:誰參與、要提供什麼材料、多久內要做出決策
• 元件啟動需要指導委員會批准,不是發起人,也不是專案集經理。這在標準和考試中都是確定的
• 收尾也是治理實踐:沒有批准就不能收尾。好比打仗,沒讓你打掃戰場就不能自己打掃

⚠ 新版變化: 由 12 個減為 10 個,健康檢查(health check)不再獨立,併入評審。

§12 實踐 1:專案集治理計劃 (00:17:29)

核心: 治理框架必須寫成書面的治理計劃(Governance Plan),通常是專案集管理計劃的一部分。

• 內容:規定專案集治理框架的功能、流程、權責分配與決策層級,也就是誰做什麼、遵循什麼流程
• 可以獨立成文件,但通常放在專案集管理計劃裡
• 大體穩定,但要動態調整。框架結構變動(例如 4 層改 3 層)或角色換人,都要及時通知相關干係人

PMI 術語: Program Governance Plan ↔ 專案集治理計劃

§13 治理計劃是合規依據 (00:18:54)

核心: 治理計劃要在整個專案集生命週期中被反覆引用,用來證明專案集合乎既定治理,也就是「合規」。

• 有了規定就要照做。不照做,用稽核(audit)查得出來
• 約束力有層次:專案集治理計劃 < 公司級政策(例如質量政策)< 國家層面要求,層級越高越嚴

§14 實踐 2:治理框架與組織願景/目標 (00:20:04)

核心: 組織的願景與目標驅動專案集的戰略任務,治理也要從這裡出發,確保各自職權範圍內的治理支援組織目標。

• 治理框架可以看成「從管理計劃剝離出來」的部分,專門規定誰行使什麼權力、決策怎麼做出
• 一種新管理方法剛引入時不被認可。一旦背後有高層意志和授權,不想做也得做,這些行為就成了治理實踐

§15 用報銷流程理解治理框架 (00:21:56)

核心: 一條規則定義「角色、層級、怎麼做」,就是治理規則;整套審批層級體系就是治理框架。

• 例子:報銷要直屬主管首簽 → 上一級確認 → 超過 10 萬由副總裁以上審批,這套三級審批就是治理框架
• 套到專案集:每個專案(元件)的啟動必須由專案集指導委員會批准;不涉及元件的專案內小變更交給專案的 CCB 批准
• 這樣形成組織內完整的權責體系,就是治理框架

§16 實踐 3:批准、認可、定義的責任 (00:23:23)

核心: 誰有權批准什麼,要白紙黑字寫下來。「核實」不等於「批准」,批准之後事情才算定案。

• 核實只是核對事情的真實性;批准是最終拍板
• 專案集方法與計劃由專案集指導委員會批准;在它之前,發起人(sponsor)必須先批准
• 批准可以發生在任何時候,包括資源使用、元件啟動方式

🎯 考點: 專案集商業論證與專案集章程的最終批准者 = 專案集指導委員會。

§17 發起人的定位與獨自批准的時機 (00:25:02)

核心: 專案集管理中,發起人和專案集經理的地位都比較低,幾乎所有重大決策都由指導委員會做出。這和專案管理不同,專案的發起人權力很大。

• 發起人可以單獨行使批准權的情境:題目說指導委員會休會,而事情又很緊急
• 收尾前驗證收益實現情況,專案集經理可以找發起人;但真正進入收尾的批准仍由指導委員會做出
• 批准責任要分工、分層,重大事項都歸指導委員會

🎯 考點: 題幹沒提委員會休會/緊急 → 選指導委員會;提到休會又緊急 → 才選發起人。

§18 資金提供方的批准權 (00:26:31)

核心: 誰出錢,誰就有權做相應的批准。外部資金要簽協議,監管更嚴格。

• 內部資金:不由單一角色決定,而是 CFO、COO、CEO 等一組人共同決策,避免單點出問題
• 外部資金:指導委員會要和外部資金提供方簽署協議,有法律保障也有法律要求;出資方會主張權利
• 資金用途有強制限制,例如營運資金不能拿去做投資,運用時有法規和內部規定要遵守

§19 三份必須由指導委員會批准的文件 (00:28:27)

核心: 專案集商業論證、專案集章程、專案集管理計劃,批准非常嚴格明確,必須由指導委員會批准。

🎯 考點: 問這三份文件誰批准 → 專案集指導委員會。

§20 實踐 4:監督、報告與控制 (00:28:50)

核心: 績效管理框架由治理參與者負責設定。績效評價要有法定權威,不是誰都能評。

• 參與者提出績效框架方案,經管理層確認後,在框架下做評價
• 標準化的報告與控制流程讓組織能正式監控、評估專案集狀態
• 標準化流程通常由 PMO 推動。可以採用組織通用的流程,也可以在組織要求下自訂

§21 實踐 5:問題與風險治理 (00:30:23)

核心: 專案集風險會複合(compound),是乘法甚至指數級,不是各元件風險的加總。因此要在治理中規定升級規則。

• 有雪崩、連鎖效應,好壞都會放大,所以風險決策與應對手段的批准要嚴格規定
• 規定好什麼級別必須升級、什麼級別在本層處理,分內部升級與外部升級兩個方向
• 升級的指標是風險閾值:專案集啟動時要花大量時間了解組織與關鍵干係人可接受的風險區間,碰到閾值就必須升級,不能自行決策

PMI 術語: compound risk ↔ 複合風險 / risk threshold ↔ 風險閾值 / escalation ↔ 升級

🎯 考點: 風險觸及閾值 → 依治理規定升級,而不是專案集經理自行處理。

§22 質量治理 (00:32:35)

核心: 質量要求在專案集層面制定,在元件層面執行;元件的質量要求不能低於專案集要求。

• 質量管理計劃的規定和條件在專案集層級訂定,通常在元件層面落地,所以元件層也要治理

§23 變更治理:元件增減只有指導委員會能批 (00:33:17)

核心: 專案集的變更顆粒度是「元件」。增加或減少元件,一律由專案集指導委員會批准。

• 專案中:不影響基準由專案經理審批,影響基準由 CCB 審批
• 專案集中:發起人、專案集經理、CCB 定位都偏低,最高的是指導委員會
• 指導委員會負責定義專案集經理可以獨立批准的變更類型;不涉及元件增減的才可能授權給專案集經理,元件層面基本不會下放

🎯 考點: 增加或減少元件誰批 → 專案集指導委員會,不選發起人、專案集經理或 CCB。

§24 元件啟動與移交、評審與健康檢查 (00:35:10)

核心: 元件的啟動和關閉(移交屬於關閉)都要指導委員會批准;治理評審指關鍵決策點,也就是關口(gate)上的評審。

• 專案集的變更很多就是「提議啟動元件」或「提議關閉元件」
• 關口評審通過後才能進入下一階段,沒評審前不允許往下走
• 健康檢查(health check):在兩個決策點之間進行,評估持續績效與收益實現/維持的進展。可以由專案集經理自行設定,寫進治理計劃
• 評審結果是通過或否決;否決可能導致元件甚至整個專案集終止

⚠ 新版變化: 健康檢查原本是獨立的治理實踐,5th 併入評審。

§25 實踐:專案集收尾是一個「時間段」 (00:37:25)

核心: 收尾是一段時間,不是一個時間點。收尾的開始(啟動批准)和結束(確認)都要指導委員會決策。

• 評估收尾條件是否滿足,不滿足就不準進入收尾;收尾動作沒做完也不準宣告結束
• 收尾的條件與流程要寫進專案集治理計劃

🎯 考點: 能不能開始收尾、何時結束收尾 → 都要指導委員會批准。

§26 啟動收尾的原因與收尾程序 (00:38:58)

核心: 不管是正常還是非正常終止,收尾程序(procedure)都要完整履行,特別是經驗教訓。

• 原因一:組織戰略改變,專案集不再需要,不論處在什麼狀態都要收尾
• 原因二:戰略沒變,但專案集已不可能達成收益
• 原因三:正常完成,不再具備繼續的價值
• 非正常終止也要總結失敗原因(3.8 會詳講)
• 移交要經過批准才能進行;最終專案集報告要由治理參與者(指導委員會或發起人)確認才算數

§27 治理計劃的關鍵內容 (00:40:30)

核心: 治理計劃一定要寫明誰負責(responsible)、誰擔責(accountable)、權力授權給了誰,以及治理相關會議。

• 治理會議包括關口評審、健康檢查、稽核,都要排進治理計劃
• 講師提醒:後面那張把 10 個實踐圖形化的頁面裡有考點,不要跳過

PMI 術語: accountability ↔ 擔責 / responsibility ↔ 負責

§28 治理角色:治理與管理的分工 (00:41:37)

核心: 治理角色在專案集治理與專案集管理之間建立協作關係。治理多半做決策,管理多半做執行,中間有灰色地帶。

• 不是最高層級的角色,一定兼有管理成分;最高層幾乎只定規則、做決策
• 專案集指導委員會是專案集層面的最高決策機構
• 專案集經理執行六大績效域的工作,專案經理在五大過程組、十大知識領域內實施工作

講師原話:「專案集指導委員會,它是最高決策機構,記住啊,專案集層面的最高決策機構。」

⚠ 新版變化: 講師提醒把投影片上的「五大績效域」改成「六大」。

§29 學員提問:簽約協議與資金 (00:43:07)

核心: 簽約協議與資金是 5th 首次出現的內容;依標準的描述,只有指導委員會可以簽約,專案集經理不行。

• 專案集經理是臨時身份,不宜承擔有法律擔保的簽約行為
• 治理是貫穿全程的,不分階段;生命週期的「構建」和「規劃」才是並列的階段
• 簽約時機:構建(啟動)時確定資金來源並簽協議;規劃時發現資金不足,可以引入外部資金再簽;執行中也可能有新資金加入

⚠ 新版變化: 簽署資金協議是 5th 新出現的情況。

§30 角色 1:專案集發起人 (00:44:48)

核心: 發起人通常擔任指導委員會主席。他提供組織資源,並對專案集的成敗負最終責任;但委員會是集體決策,主席不能一人決定。

• 是組織內有一定級別的人,代表指導委員會行使日常管理責任,推動組織變革以確保專案集交付
• 特質:領導力、敢決策、能影響他人、向上溝通與向下管理能力強
• 考點集中在「提供資源」和「負最終責任」兩點

PMI 術語: Program Sponsor ↔ 專案集發起人

§31 角色 2:專案集指導委員會 (00:46:24)

核心: 所有重大決策都由指導委員會集體做出,包括定義和實施治理實踐;成員為高管層。

• 委員會負責定義並實施適當的治理實踐,治理方法與框架最終由它集體批准
• Executive level(高管,C-level)和 senior management level(高階管理層,例如 VP、總監)用詞有別,但不必特別區分
• 小型組織可能由一位高管個人承擔委員會的責任,但標準不提倡
• 要記的就是:元件啟動與完成、專案集的啟動與收尾,都由委員會批准

PMI 術語: Program Steering Committee ↔ 專案集指導委員會

§32 角色 3:專案集管理辦公室 PMO (00:49:27)

核心: 指導委員會「決定」治理實踐,PMO「推動」治理實踐落地,重點是治理流程的標準化與監督合規。

• 促進資源、方法論、工具的共享;必須由懂專案集或組合管理的專業人員擔任
• 合規範圍由內到外:專案集自訂規則 → 組織強制要求 → 行業、國家、國際規範。越往外層級越高、約束越嚴(例如合約管理要符合外部採購要求)
• PMO 職能可授權給中高層 manager/director,或直接給專案集經理;沒人時專案集經理自己就是 PMO

§33 PMO 的多種形式與 COE (00:51:32)

核心: PMO 有企業級、戰略級、轉型 PMO、VMO、卓越中心(COE)等形式。COE 偏能力建設,行政和業務事務較少。

• COE:建構個人能力與組織流程成熟度,對外展現公司形象,對內打造核心能力;定位高、細節少
• 一般 PMO:管具體專案的過程與管理

PMI 術語: Center of Excellence (COE) ↔ 卓越中心

§34 角色 4、5:專案集經理與專案經理的雙重身份 (00:52:43)

核心: 專案集經理經授權(指導委員會 → 發起人 → 專案集經理)代表委員會做決策,但只限於被授權的範圍。批准元件啟動通常不授權給他。

• 職責:建立並評估治理框架(由 PMO 協助),框架由指導委員會批准;監看遵守情況,與委員會互動
• 雙重身份:專案集經理制定的規則要上級確認,避免既當裁判又當運動員。所以他既是治理者,也是執行者
• 專案經理向上是被專案集治理的對象,對內則行使自己的治理權,同樣是治理與管理合一

🎯 考點: 專案集經理只能做被授權的決策;元件啟動不在他的授權範圍內。

§35 授權水平與其他干係人 (00:54:52)

核心: 專案集經理的授權水平取決於經驗與專案集的複雜度,但複雜和高風險也可能反而讓授權變小。

• 經驗越豐富授權越多;複雜度高、風險高時,可能要升級到集團層面的專家判斷,授權反而縮小
• 其他干係人:組合經理(擔任發起人時按發起人的角色分配)、職能代表、產品負責人、營運經理(承接移交),了解即可

§36 治理框架的設計與實施:裁剪 (00:55:41)

核心: 治理是關於管理的管理。設計從識別治理參與者與建立治理實踐開始,10 個實踐要依行業裁剪。

• 裁剪時要考慮:戰略一致性、干係人參與、收益實現,並適當使用工具
• 可以增加或刪減實踐,由專案集自行決定

講師原話:「治理決定了管理。有一句話說的蠻好,治理是關於管理的管理。」

§37 設計考量因素與「不當治理比沒治理更糟」 (00:57:13)

核心: 不適當的治理可能比沒有治理產生更多問題;治理框架要隨生命週期階段調整。

• 設計因素:立法環境、層級要求、戰略重要性、失敗風險、變更頻率等。考試不是重點,瀏覽即可
• 不當治理會產生虛假的對齊感,反而讓事情變差
• 不同階段對治理的要求不同,各治理實踐的重要性也隨階段變化
• 延伸閱讀:PMI《Governance of Portfolios, Programs, and Projects: A Practice Guide》
• 治理框架也要持續優化

🎯 考點: 選項出現「加更多治理/控制」時要小心,過度或不當的治理不是好答案;治理要適配生命週期與情境。

§38 與其他原則/績效域的互動、治理計劃與管理計劃的關係 (00:59:07)

核心: 六大績效域兩兩相互嵌入;治理原則、變更原則、團隊之團隊原則與治理框架的關聯度最高。

• 治理的核心作用:為專案集實施提供監督、權力和資源。讓委員會參與決策不是為了放慢速度,而是為了降低風險、強化戰略一致、讓收益實現最大化
• 目標是建立權責清晰、決策升級結構化的框架
• 專案集治理計劃是專案集管理計劃的一部分

§39 協作績效域導入:協作 vs 協同 (01:00:46)

核心: 協作(Collaboration)是 5th 新增的績效域。協作指人與人之間;協同(Synergy)偏向事與事、節奏與節奏。

• 用來區分協作績效域和原則裡的「協同」
• 本績效域分 5 個模組,第 2~4 模組是核心

⚠ 新版變化: 3.7 協作是 Standard 5th 新增的績效域。

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

§40 協作的定義與授權前提 (01:02:20)

核心: 協作要求專案集經理建立並維護跨干係人(內部和外部)的協同效應;前提是授權專案集領導者與團隊。

• 協作=步調一致、方法相同、節奏相同、遵守共同規則與協議,重點在「人」
• 授權有兩層:①組織高層授權給發起人、指導委員會、專案集經理;②他們再向下授權給團隊
• 授權意味著信任、認可專業能力,出了問題願意一起承擔
• 沒有充分授權,人人等命令,會逐級衰減、慢半拍,協同就產生不了

講師原話:「PMI 這些標準背後有個預設的規則:每個人都是願意自主自發去做事的人,他缺的是授權。有了授權,剩下一切都不是問題。你可以做這種假設來做題。」

🎯 考點: 做題預設人性向善、能自主;情境中卡關時,優先選「授權、賦能」,不要選懷疑或控制人的選項。

§41 專案集協作 vs 專案協作、團隊之團隊 (01:05:34)

核心: 專案協作圍繞可交付成果;專案集協作關注收益與跨元件,干係人層級高、數量多、影響大,難度遠高於專案。

• 協作是手段,目的是收益最大化、收益可持續
• 要建立和維護團隊之團隊(team of teams),也就是人際關係網路
• 用詞:networking(西方的人際網路)比 connection 更貼切,中文的「關係」(relationship)最傳神

PMI 術語: Team of Teams ↔ 團隊之團隊 / networking ↔ 人際網路

§42 支援整合、適應性韌性與成功要素 (01:07:38)

核心: 協作位於其他五大績效域的外圍,讓所有績效域配合順暢,從而帶來適應性與韌性。

• 大家都有自主性時,面對不確定性和外部衝擊,只要核心不變,就能在治理要求之外自主應對:高度授權加高度自主,背後靠治理兜底
• 關鍵成功要素:跨團隊/跨組織溝通的保障機制、基本分工、平衡與對齊各元件不同但互相關聯的需求
• 兩個固定不變的東西:戰略方向(戰略一致性)和收益最大化且可持續

§43 戰略是北極星/指南針,收益是地圖 (01:09:44)

核心: 戰略一致性像北極星、指南針,只給方向不給路徑;收益管理像地圖,告訴你每一步怎麼走、哪裡轉彎、哪裡掉頭。

• 路上可以繞彎、遇到障礙,但方向不能變;戰略一變,你就要跟著變
• 要用最短路徑達成目標

講師原話:「戰略提供了那個北極星的位置,就像我們的指南針一樣,它指向的是方向,但它不給你指出路徑來;而收益管理為什麼叫地圖呢?地圖給我們指出每一步該怎麼走。」

§44 左手領導力、右手管理 → 適應性與韌性 (01:11:14)

核心: 協作要靠軟性的領導力和剛性的管理兩手並用,才能取得專案集所需的適應性與韌性,應對組織和組合環境中的戰略變革。

• 管理偏要求,建立在不完全信任的基礎上(計劃、目標、時間點);領導力偏提倡、影響,建立在高度信任的基礎上;兩者要平衡
• 適應性(adaptability):外界變化時能調整;韌性(resilience):受到衝擊後能迅速恢復
• 邏輯鏈:協作 ← 授權 ← 信任(有條件)← 領導力加管理

PMI 術語: Adaptability ↔ 適應性 / Resilience ↔ 韌性

§45 協作的層次:組織 → 組合 → 專案集內部 (01:13:07)

核心: 協作要在三個層次順暢配合:專案集與組合(及組織)之間、組合與組織之間、專案集內部。

• 組織變革管理需要協作;專案集影響面大,通常和戰略層面相關

§46 協作因素 1:參與/爭取(Engagement) (01:14:18)

核心: 第一組協作因素是參與、對齊、複雜性(Engagement, Alignment and Complexity)。參與的驅動原則是團隊之團隊和干係人原則。

• 爭取與參與是同一件事的兩面:從專案集經理主動的角度說是爭取,從干係人的角度說是參與
• 前提是理解目標、期望與預期成果,否則拿什麼去爭取別人
• 溝通是爭取的主要工具,但只是最基礎的一層(PMBOK 語境中的溝通指資訊交換與傳遞)
• 爭取做得不好的後果:干係人失去興趣,正面干係人的影響尤其大

🎯 考點: 溝通不等於參與。溝通只是爭取干係人的基礎手段,參與的層次更高。

§47 協作因素 2:一致性/對齊(Alignment) (01:17:48)

核心: 對齊是協作的核心原因。戰略一致性只是一致性的一種,其餘還有收益與結果、交付物與成果等多方向的對齊。

• 一致性指雙方或多方在期望、做法、收益是否符合需求等方面達成共識,至少能理解、能相信
• 有了參與(爭取)和對齊,協作才可能發生

§48 協作因素 3:複雜性 → 把不確定性轉化為風險 (01:19:44)

核心: 不是有了複雜性才協作,而是因為複雜性存在,所以需要充分協作、群策群力。

• 複雜的工作一個人或少數人難以理解,即使頂尖人物也難以完全理解,所以要擴大集體應對複雜性的能力;但人一多,人際關係本身也會變複雜
• 複雜系統像蝴蝶效應,不可預測、無法百分之百掌控,只能讓它相對受控
• 要盡最大努力把完全不可知的不確定性(unknown-unknowns),轉化為可管理的已知未知風險(known-unknowns,約占 80~90%)
• 要透過探索協同效應(協同指事,協作指干係人),把複雜性適度納入管控

PMI 術語: known-unknowns ↔ 已知未知 / unknown-unknowns ↔ 未知未知

§49 協作因素:透明度、協商、文化 (01:25:09)

核心: 第二組協作因素是透明度、協商、文化。沒有透明就難以配合,沒有協商就難以形成共識,文化是長遠的支撐。

• 透明度(transparency):共享資料、行為、報告、溝通方式,讓大家看得見
• 協商(consultation):溝通後確定大家都認同的結果,強調動作
• 文化:透明、願意協商、參與度高、目標一致、正視複雜性的組織文化,協作最容易出現
• 考試掌握這些因素的大意即可

PMI 術語: Transparency ↔ 透明度 / Consultation ↔ 協商、諮詢

§50 協作因素:同理心(Empathy) (01:27:02)

核心: 同理心幾乎沒有工具可用,要靠人本身,是 AI 難以取代的能力;在考題中幾乎都是正確選項的方向。

• 透明、協商都有工具,同理心只能靠站在對方角度理解其感受;人生閱歷、知識、情感越豐富,越容易產生同理心
• 審美、領導力、共情是目前 AI 無法取代的
• 標準只說專案集經理應利用同理心為專案集創造支援,並未深入定義

講師原話:「從我的經驗來講,這個詞基本是百分之百全是正面的,沒有負面的東西。也就是說考試出現它作為正確選項的比例是極高的。」

🎯 考點: 選項出現「同理心/共情/站在對方角度理解」→ 高機率是正確答案。

§51 同理心兩要點:超越機器執行、感知價值 (01:30:46)

核心: 同理心包含兩點:①超越機器式執行,成功不只靠嚴格執行;②感知價值,而價值的判斷者是高層或客戶。

• 不能把人當工具人。要能感知專案集對組織的重要性,同時兼顧自己、團隊、專案集、組織
• 感知(perception)本身是主觀的,存在於人身上
• 呼應 PMI MORE 戰略,M = Manage Perspectives(管理認知)
• 感知到價值,是能夠實現價值的前提
• 同理心是協作最重要的基礎

PMI 術語: Perceived Value ↔ 感知價值 / Manage Perspectives ↔ 管理認知(MORE 框架)

Part B (01:34:15 - 03:08:46) 綜述

這段把第 5 版新增的「協作績效域(Collaboration)」講完,再進入「生命週期管理績效域(3.8 Program Life Cycle Management)」,最後細講定義階段的構建(Formulation)與規劃(Planning)子階段。前半部依序講三種協作:3.7.1 的干係人情感連結(定期收集回饋、透明分享、慶祝、化解疑慮、肯定貢獻);3.7.2 收益與規劃價值交付之間的協作(組織→組合→program 逐層建立價值要素;價值有形/無形、量化/定性;program 用「收益」交付價值,成果是 project 層級的東西;規劃價值是持續變革,不是一次性;主動平衡 vs 被動平衡);3.7.3 program 元件與活動之間的協作(協作鏈=價值鏈=戰略分解路徑;PgM 要在元件需求與 program 整體之間取得平衡;跨專案的問題、風險、變更不論大小一律升級)。講師也坦白評論:協作績效域寫得抽象,將來可能退回「原則」;最具代表性的績效域是戰略一致性、收益、治理。後半部的生命週期:定義(構建+規劃)、交付、收尾(移交+關閉),三個階段實際上互相重疊、迭代。考點判準:①授權=章程,商業論證是章程的輸入;②sponsor 和 PgM 在構建子階段確定,program 團隊和 PMO 在規劃子階段確定;③章程批准後才進入規劃;④所有元件收尾後 program 才能收尾,收尾五動作是資源釋放、資訊歸檔、財務關閉、風險管理責任移交、採購結束;⑤交付階段的整合主線是把元件可交付成果整合成收益;⑥管理計劃有 14 個子計劃,新增路線圖,但沒有協作計劃。

§52 協作的情感面:感知干係人的感受 (01:34:15)

核心: 協作的前提是感知各干係人(stakeholder)的感受,自己的感受只是次要的;還要培養對組織價值的認知。

• 要追蹤的是各方干係人的感知,PgM 自己的感知只是次要的部分
• 這裡講的是「做事」情境下的情緒和心理感知,不是私人感情;沒有感知就無法共情
• 價值以組織為主:先弄清楚組織認為的價值是什麼,再談 program 的目標與戰略意義
• 對齊價值認知之後,才有情感連結和心理共鳴,協作才做得起來

§53 建立情感連結的六個實踐 (01:35:38)

核心: 建立情感連結的實踐清單很容易考:定期收集回饋、透明分享進展、慶祝成功、化解疑慮、強調每位貢獻者的價值。

• 定期收集回饋:客觀、具體的行動
• 透明分享 program 進展
• 慶祝(celebration):慶祝成功和小成就,能把團隊凝聚起來
• 解決疑慮與擔憂
• 強調每個貢獻者的價值,哪怕只是一點點貢獻
• 成功的協作不只是執行流程(理性、客觀),更是凝聚人心(感性、主觀);現在越來越強調後者

🎯 考點: 情境題問「如何促進協作或干係人承諾」→ 優先選收集回饋、透明分享、慶祝、肯定貢獻這類動作。

§54 情緒價值不可取代 (01:37:00)

核心: 讓干係人感受到 program 的價值,才能激發真正的承諾和投入。

• 講師個人觀點:AI 會取代大部分基本工作,能提供情緒價值和心理價值的能力幾乎無法被取代

§55 3.7.2 收益與規劃價值交付的協作 (01:37:13)

核心: 「規劃價值」是一個動作;program 聚焦收益,組織要的是價值,兩者要協作對齊。

• 收益是 program 交付的目標;規劃價值是事先計畫好怎麼交付價值
• 要花大量時間了解組織對價值的期望
• program 以「收益」的形式為組織貢獻價值

PMI 術語: Planning Value Delivery ↔ 規劃價值交付 / Purpose ↔ 宗旨

§56 逐層建立 program 的價值要素 (01:38:38)

核心: 把組織和組合層面的價值期望提煉成 program 的價值要素,讓收益能被有效規劃和實現。

• 價值從組織→專案組合(portfolio)→program 一層一層建立起來
• program 價值要素包括價值觀、目標、目標的評價方式、可衡量的成果,要細化到這一層

§57 價值的定義:有形/無形 × 量化/定性 (01:39:32)

核心: program 價值是有形與無形、量化與定性收益的總和。

• 第一組詞:量化 vs 定性(quantifiable / qualitative)
• 第二組詞:有形 vs 無形(tangible / intangible)
• 價值的形式不只有收益,還可能是可交付成果(最初級的形態)、成果(outcome)、收益,也包括 program 團隊的能力與產能(capacity)
• 簡單理解:可交付成果是價值的一種形式,收益也是價值的一種表現形式

PMI 術語: Tangible / Intangible ↔ 有形/無形 / Quantifiable / Qualitative ↔ 量化/定性 / Capacity ↔ 產能

§58 價值交付系統 (01:41:16)

核心: 價值交付系統是組織從願景、使命到戰略、組合、program、project、運營協作產生價值的整套體系,program 是其中一部分。

• 和剛發布的 PMBOK 第 8 版講的價值交付系統是同一個概念
• 這個系統要消耗組織資源,以達成戰略、使命和願景

PMI 術語: Value Delivery System ↔ 價值交付系統

§59 program 用「收益」而非「成果」交付價值 (01:41:49)

核心: 標準原文寫「program 透過一系列成果實現價值交付」,講師認為應該讀成「透過一系列收益」,因為成果屬於 project 層級。

• 鏈條:project 產生可交付成果 → 使用可交付成果產生成果 → 再提煉成收益
• 講師說翻譯本身沒錯,是英文原文需要優化

🎯 考點: 層級對應:project 對應可交付成果和成果(outcome),program 對應收益(benefit),組合/組織對應價值。

§60 組織與組合層面的價值規劃 = 戰略規劃分解 (01:42:24)

核心: 價值規劃的目的是實現組織的願景、使命和戰略目標;戰略分解就是為 program 設定目標,也就是收益。

• 價值規劃其實就是戰略規劃,只是說法更抽象
• 與戰略一致的收益實現,才算價值
• 可以簡化成:戰略目標分解 → 確定 program 目標 → program 目標以收益表示

§61 收益管理定義元件間的依賴關係 (01:43:45)

核心: 元件不是一開始就有的,而是先分析收益及其依賴關係(收益依賴地圖),再依此形成元件架構。

• 收益依賴關係地圖為元件的確定提供底層總體架構(architecture)
• 元件既然由收益依賴關係推導出來,彼此自然有相互依賴關係

PMI 術語: Benefits Dependency Map ↔ 收益依賴關係地圖 / Architecture ↔ 總體架構

§62 協作計劃:應該有,但不在子計劃清單裡 (01:44:25)

核心: 標準提到用來優化價值的協作計劃,但它不在 program 管理計劃的 14 個子計劃裡。

• 講師說這件事應該做(要捕捉協同效應),但協作計劃很難定義,真的寫不出來
• 跨領域、元件之間、元件管理者與干係人之間都要協作,收益實現過程中的配合要事先規劃
• 講師說「知道一下就好」

🎯 考點: 問 program 管理計劃有哪些子計劃 → 沒有協作計劃(Collaboration Plan)。

§63 規劃價值是持續的變革過程 (01:45:48)

核心: 價值交付的規劃不是一次性的活動,會隨收益期望和收益實現的變化而調整。

• 戰略不變,內部也可能迭代;外部環境變了更要調整
• 例:干係人原本期望不高,後來期望很高 → 協作規劃要調整
• 例:原定 33% 市占率很容易達成 → 管理層可能把目標提高到 35%
• 團隊與干係人的協作水平,會影響目標達成的機率

§64 PgM 主導協作、識別依賴關係 (01:47:39)

核心: program 經理是協作的主導者和主責人;規劃時要事先識別相互依賴關係,抓住協同效應。

• 相互理解後,元件的規劃比較容易達成共識
• 相互依賴(interdependency)主要指本質的、內在的、不以主觀意志轉移的依賴;主觀強加的不算

PMI 術語: Interdependency ↔ 相互依賴關係

§65 主動平衡 vs 被動平衡 (01:49:17)

核心: 主動平衡是事先發現、事先行動;被動平衡是事情發生後再調整。兩者都需要。

• 主動平衡:管理 program 節奏,主動規劃收益計劃、收益實現與總體戰略
• 被動平衡:書上只講壞處;講師補充好處是不必事先做大量工作,符合敏捷精神
• 主動規劃不可能想到所有情況,所以一定還要被動應對

§66 精益、價值鏈與跨治理結構協作 (01:50:00)

核心: program 層級要用精益(lean)的方式和價值鏈上的各團隊協作;治理結果為規劃與更新提供決策框架。

• 精益:不斷優化,去除冗餘
• 價值鏈:價值需求 → 創造 → 實現 → 分配 → 評價
• 要支援各團隊的計劃,讓它們和 program 計劃結合
• 跨治理結構協作:自己的權限範圍、別人的權限範圍、雙方之間的灰色地帶都要處理
• 講師判斷:協作很抽象,題目不好出,考試不會太難

PMI 術語: Lean ↔ 精益 / Value Chain ↔ 價值鏈

§67 3.7.3 program 元件與活動的協作:協作鏈 (01:51:55)

核心: 「program 活動」是專有術語,指整合活動和支援活動;協作鏈是組織目標 → 組合目標 → program 目標 → 元件 → 可交付成果。

• 回顧:3.7.2 講收益(收益管理績效域)和規劃價值交付(組織層級價值交付系統)之間的協作
• 3.7.3 講活動之間、團隊之間、人與人之間的配合
• 標準寫「預期收益和成果」,講師說「成果」兩字可以去掉

PMI 術語: Program Activities ↔ program 活動(整合與支援活動)

§68 協作鏈 = 價值鏈 = 戰略分解路徑 (01:54:08)

核心: 願景/使命/價值觀 → 戰略 → 組合 → program → project 這條鏈,往下是戰略分解,往上是可交付成果 → 收益 → 價值,既是協作鏈也是價值鏈。

• project 產出可交付成果 → program 整合成收益 → 組合整合成價值 → 回到戰略

§69 PgM 平衡元件需求與 program 整體 (01:54:57)

核心: PgM 的核心責任是平衡各元件的個別需求與 program 整體需求,最終目標是 program 成功;必要時可以犧牲個別元件。

• 極端情況下,個別 project 失敗也要保住 program 成功
• 比喻:能力很強卻破壞團隊協作的人,為了整體可以主動移出團隊
• 有時候主動放棄某些元件,不一定是被動的

🎯 考點: 元件利益與 program 整體利益衝突 → 以 program 整體收益為準。

§70 PgM 的監督職責與收益可見性 (01:56:55)

核心: PgM 要監督平衡的結果,並透過治理框架、溝通流程解決問題,同時讓更高層看得到 program 的收益。

• 平衡元件與活動只是手段,最終要保證的結果是收益出現

§71 元件層級協作:PM 只顧自己的 project (01:57:46)

核心: 從下往上看,元件目標可能和 program 目標衝突;PM 透過自己的生命週期追求自己的成功,不一定會考慮其他 project 或 program 整體。

• PM 不為別人的成功負責,這是人性,也是 PM 的正確定位
• PgM 要看到這個差異,用治理規則處理

§72 跨專案的問題、風險、變更一律升級 (01:59:01)

核心: 跨專案的問題、風險和變更,不論大小都要升級到 program 層級,不能下放給 project 自己處理。

• 下放的話,很可能犧牲 program 整體利益,因為各 PM 只關注自己的 project 目標
• PgM 應該在治理規則裡明定這一條

🎯 考點: 情境題出現「影響兩個以上元件」→ 升級到 program 層級處理(PgM 或治理委員會),不要讓 PM 私下協調解決。

§73 project 層協作:內部 vs 跨專案的界線 (01:59:56)

核心: project 內部的協作 program 不宜過度介入,跨專案的才介入;治理規則要區分「project 內部」和「project 之間」。

• program 可以參與制定 project 層的協作規則,定好後交給 project 執行
• program 協作仍要遵循漸進明細(progressive elaboration),適當做業務分析和系統分析,用有效的變更控制管理範圍和需求基準
• 各元件可以用不同方法,但 PgM 在上層要做好平衡與協調;只看局部可能損害整體目標

PMI 術語: Progressive Elaboration ↔ 漸進明細

§74 節奏與系統思維:局部 vs 整體 (02:01:23)

核心: 內外部因素會打亂節奏,協作就會失焦;PgM 要同時看「元件與元件」和「元件與 program」兩個方向。

• 比喻:長跑的節奏和呼吸
• 系統思維:局部與局部的關係、局部與整體的關係

§75 協作與原則、其他績效域的互動 (02:03:12)

核心: 協作和所有原則、所有績效域都有關,標準只列出關聯度最高的幾個原則(以「協同」原則最高)。

• 協作是績效域;協同、治理、團隊是原則
• 標準沒列出來的,也要理解成有關係

§76 協作的核心要素 (02:04:09)

核心: 協作的核心要素多半是人際技能(主動溝通、建設性溝通),加上組織層面的實踐(透明度、風險管理、信任與尊重、融入 program 所有其他要素),還有多元化思維。

PMI 術語: Constructive Communication ↔ 建設性溝通

§77 講師評論:協作績效域還不成熟 (02:04:37)

核心: 協作是第 5 版新增的績效域,但寫得偏主觀、偏原則,缺少具體過程;講師判斷將來可能退回原則。

• 圖示:協作位在其他五個績效域中間,代表五個績效域要互相配合
• 第 4 版有五大績效域,第 5 版增加協作,變成六大
• 協作也包括和第三方合作夥伴的協作

⚠ 新版變化: 第 5 版新增協作績效域(Collaboration),從 4th 的五大績效域變成六大。

§78 協作 vs 協同;PMBOK 8 原則與績效域不重複 (02:07:20)

核心: 協作=Collaboration(績效域),協同=Synergy(原則);有效協作帶來 1+1>2 的協同效應。

• 標準原話:協作不是孤立存在的,和所有原則與績效域緊密相關
• PMBOK 8 改版的原則之一是「原則和績效域要分開、不重複」;因此 program 標準既有協同原則又有協作績效域,未來可能成為討論議題

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

⚠ 新版變化: PMBOK 第 8 版剛發布,改版原則是原則與績效域不重複。

§79 最具代表性的績效域:戰略、收益、治理 (02:09:19)

核心: program 管理最具代表性的是戰略一致性、收益管理,再加上治理。

• 干係人:方法和過程跟 project 的干係人管理沒有本質差異
• 生命週期:和第 4 版沒有太大變化,仍在啟動、規劃、執行、監控、收尾的框架下
• 治理:建立治理結構和體系(層級、誰決定、依據什麼決定、出問題怎麼處理),是和戰略、收益不同方向的新東西
• 讀書時把時間花在戰略和收益上,生命週期只是把這些事放到各階段執行

§80 講師的理解:協同在工作模式,協作在干係人 (02:12:54)

核心: 講師的自洽邏輯是:協同(synergy)主要指工作模式,協作(collaboration)主要指干係人之間;協作其實分散融在其他五個績效域裡。

• 協作的內容一部分在治理、干係人、收益、生命週期、戰略裡,六大績效域互相巢狀
• 把協作獨立出來反而寫得單薄,當作各領域的底色可能更好

§81 3.8 生命週期:最容易理解的績效域 (02:14:38)

核心: 生命週期按時間線性展開,符合一般人的認知,難度比協作低很多;先線性學會,再理解它是循環往復的。

• 維度比喻:人能理解三維加時間;協作像更高的抽象維度,所以難懂
• 學習順序:先當成單線程學清楚每個階段的重心,再理解循環
• 結構:概述 + 三大階段 + 與其他績效域的互動

§82 以生命週期為主線串起六大績效域 (02:17:38)

核心: 以生命週期(Program Life Cycle Management)為橫軸,戰略、收益、治理、干係人、協作都在各階段發生,彼此交織。

• 六大績效域:Strategy、Benefits、Governance、Collaboration、Life Cycle、Stakeholder

§83 標準演進史與「cycle」的意涵 (02:19:08)

核心: 第 1 版用績效域框架,第 2 版改回 ITTO,第 3 版又回到績效域,第 4、5 版延續;生命週期一直是基本維度。

• 第 5 版對第 4 版的改變:增加幾個原則,加入協作績效域,框架基本不變
• 預測型不一定是循環;但 program 每一步都可能在下一階段開始後回頭執行前一階段的工作(持續定義 → 交付 → 再定義)
• 一旦運轉起來,每個階段都含有另外兩個階段的要素

⚠ 新版變化: 第 5 版仍沿用第 3、4 版的績效域框架,新增原則和協作績效域。

§84 定義階段「定義」的是什麼 (02:20:55)

核心: 生命週期績效域的主要內容是定義、交付、收尾三個階段;定義階段定義的是 program 本身(目標、商業論證、元件產生的底層架構)。

• 元件在交付階段才出現,但元件的底層規劃(收益部分講的 architecture)在定義階段就完成了

§85 生命週期確保一致性:局內人與局外人 (02:22:29)

核心: 生命週期在組織戰略目標與各元件之間提供必要的一致性;program 與元件是分層的,PgM 要有局內人和局外人兩種視角。

• 標準行文常把 program 與元件刻意分開,「元件」指下層群體,「program」指上層管理組織
• 局外人:元件遇到再大的困難,只要沒達到升級條件,PgM 就不插手
• 局內人:向上匯報時必須把元件情況彙總進去,元件不能直接向組合或組織匯報
• 變更、問題、風險、品質、收益:只涉及單一元件且不影響收益 → 元件自己處理;跨元件 → 必須升級

🎯 考點: 匯報一律經 PgM 彙總向上;處理問題時,沒達到升級條件就交給元件自行處理。

§86 program 的特徵與一致流程 (02:27:19)

核心: program 的不確定性、變更、複雜度和相互依賴比 project 多;program 管理要建立通用且一致的流程來統一管理元件。

• 三階段「有時會重疊、具迭代性」,講師說實務上幾乎都重疊

§87 與 project 相似:定義 = 啟動 + 規劃 (02:28:11)

核心: program 定義階段分構建(Formulation)和規劃(Planning)兩個子階段,對應 project 的啟動和規劃。

• 框架是舊知識,內容有新東西
• 第 3 版以前用的詞是 Initiation,Formulation 相當於啟動

PMI 術語: Formulation ↔ 構建 / Planning ↔ 規劃

§88 與 project 的不同:協調、複雜度、持續時間 (02:30:09)

核心: project 交付是做事;program 交付是協調各 project 做事,價值在於讓元件配合產生 1+1>2。

• 複雜度遠高於單一 project;持續時間不同
• 考試題目多在定義階段和收尾階段,交付階段的工作大多由 project 完成
• 收尾隱含移交和關閉兩個子階段,第 3 版是明確的兩個子階段,現在考試不這樣考

🎯 考點: 考題比重以定義階段和收尾階段居多。

§89 交付階段三子階段:授權規劃、監管整合、移交關閉 (02:31:42)

核心: 交付階段:元件授權與規劃 → 元件監管(oversight)與整合 → 元件移交與關閉,對應 project 的啟動到收尾。

• 授權元件,讓元件自己規劃,PgM 適度參與
• project 計劃要由 program 層批准,批准後 PgM 的工作就是監督和整合

PMI 術語: Oversight and Integration ↔ 監管與整合

§90 交付階段整合什麼:元件成果 → 收益 (02:32:45)

核心: 交付階段整合的主線是把元件產出的可交付成果整合到 program 層級,轉化成收益。

• 第一種:元件可交付成果直接貢獻 program 目標 → 直接整合成收益
• 第二種:A 專案的可交付成果要給需要它的 B 專案,B 的產出才是收益所需 → 跨專案整合
• 整合依賴關係、計劃、決策依據也算,但不是主線

🎯 考點: 交付階段的「整合」= 把元件成果整合成收益(含跨專案移交);一般性的管理整合是次要答案。

§91 元件移交與關閉;所有元件結束才進入 program 收尾 (02:36:28)

核心: 元件收尾前先把成果移交給 program,再自行總結經驗教訓、關閉;所有元件都結束,program 才進入收尾。

• 整合發生在過程中(project 還沒結束);移交發生在 project 快結束時
• 進入 program 收尾的必要條件之一:所有元件(project)都已收尾,不是所有收益都已實現

🎯 考點: program 收尾前提 = 所有元件都已關閉。

§92 program 收尾:形式移交 vs 本質移交;收尾五動作 (02:37:52)

核心: program 收尾時,移交可能只是形式上的(收益在過程中已交付完),也可能是形式加本質移交;之後執行管理主線的五個關閉動作。

• 形式移交:儀式性、程序性的批准、證明、文件
• 管理主線五動作:①資源釋放 ②資訊/文件歸檔 ③財務關閉 ④風險管理責任移交 ⑤採購結束
• 風險移交指的是把風險管理責任交給運營

🎯 考點: 收尾五動作是考試重點:資源釋放、資訊歸檔、財務關閉、風險管理責任移交、採購關閉。

§93 生命週期概覽回顧 (02:40:07)

核心: 構建時確定目標和論證;規劃時把目標分解成收益實現路徑(收益依賴地圖),還沒有元件;交付時才啟動元件並分配資源。

• 交付時:授權 → project 自行規劃(PgM 適度參與)→ 執行(監督、整合)→ 移交和收尾
• 全部 project 做完後,program 再整體移交和收尾(業務主線 + 管理主線)

§94 階段關係總表:各階段主要產出 (02:42:21)

核心: 定義階段產出商業論證、program 章程、program 路線圖(放進管理計劃);交付階段執行管理計劃、實現收益;收尾階段是業務主線移交加管理主線關閉。

• 講師說這一頁非常重要,需要記

§95 定義階段:授權 = 章程,商業論證是輸入 (02:43:43)

核心: 「授權」落在文件上就是章程;制定章程最重要的輸入是商業論證。

• 問「授權 program 對應哪份文件」→ 章程是第一選項;只有選項裡沒有章程時才選商業論證
• 授權 program 屬於構建子階段;制定 program 管理計劃屬於規劃子階段

講師原話:「一旦有章程,章程絕對是第一選項,關於授權這件事。」

🎯 考點: 授權(authorize)→ 章程(Program Charter);章程的輸入 → 商業論證(Business Case)。

§96 定義階段主要活動;批准 vs 授權 (02:45:32)

核心: 主要活動:確定目標並定義預期收益(兩者幾乎劃等號)→ 尋求 program 批准(治理機構正式授權)→ 制定管理計劃。

• 兩份文件並列比較時:「批准」比較適合商業論證,「授權」比較適合章程
• 批准中包含資源的實際分配 → 章程;只是同意文件中的資源需求 → 商業論證
• 路線圖現在放在管理計劃裡

🎯 考點: 題目同時出現商業論證和章程時,看是否「給資源/正式授權」來區分。

§97 組合內的批准;各角色確定的時點 (02:47:36)

核心: program 若在組合之下,由組合批准商業論證和章程;sponsor 和 PgM 在構建子階段確定,program 團隊(核心團隊、PMO)在規劃子階段確定。

• 三個角色都在定義階段確定,但子階段不同
• 章程正式批准之後才能進入規劃

🎯 考點: sponsor/PgM → 構建子階段;program core team/PMO → 規劃子階段。

§98 構建子階段:sponsor 與 PgM (02:49:41)

核心: 構建子階段對應啟動,文件是商業論證加章程,人是發起人加 PgM。

• PgM 直接向發起人負責,發起人才向組織負責;發起人之上還有 program 指導委員會
• 發起人主要找錢、找人,找到在台前做事的 PgM;PgM 帶領構建工作

🎯 考點: PgM 的匯報與責任對象是 sponsor。

§99 構建子階段六項活動;初始風險評估 = 了解風險偏好 (02:51:05)

核心: 構建活動:初步範圍研究、初步資源估算、初步成本估算、初始風險評估、範圍進度品質等考量、制定章程和商業論證。

• 初始風險評估不是具體的風險識別,而是了解組織的風險偏好(risk appetite)
• 資源估算若和成本分開列,就是指錢以外的資源

🎯 考點: 構建階段的「初始風險評估」→ 了解組織風險偏好,不是做詳細風險登記。

§100 章程裡有沒有里程碑?有高層時間線 (02:52:07)

核心: 章程裡有高層級(high-level)的時間線,可以理解成里程碑,是 program 路線圖最早的樣子。

• 里程碑一詞最好對應路線圖(roadmap),但不專屬路線圖
• 路線圖不再是構建子階段的獨立文件,已併入管理計劃

⚠ 新版變化: 第 5 版路線圖不再是獨立文件,改為 program 管理計劃的子計劃之一(第 4 版是獨立文件)。

§101 正式授權 PgM;批准 ≠ 授權 (02:53:55)

核心: 正式授權包括授權 PgM;未獲批准是商業論證沒通過,未獲授權是論證通過了但沒有啟動許可(例如沒有資源)。

• program 在啟動期間被叫停並不少見

🎯 考點: 商業論證批准不等於 program 啟動;沒有章程授權,就不能起跑。

§102 規劃子階段:章程批准觸發;建立治理結構 (02:55:10)

核心: 規劃子階段的觸發條件是章程批准;這個階段建立治理結構(管理團隊、規則、權責、PMO、治理模型、治理計劃)。

• 考題可能用 phase/subphase 字樣
• 規劃階段的「初始組織」指 program 管理團隊;最初始的 sponsor 和 PgM 在構建時已確定

🎯 考點: 進入規劃的觸發點 = 章程批准;program 管理團隊和 PMO 屬於治理結構,在規劃時建立。

§103 program 管理團隊 vs 執行團隊;PM 不在 program 團隊內 (02:56:59)

核心: 講師為了應考而區分:program 層的團隊做管理和協調,執行工作由元件團隊完成;元件的 PM 不屬於 program 管理團隊。

• 標準本身沒有這組概念的區分,這是講師的教學框架
• program 層級的執行全是管理和協調類工作,技術和業務工作靠元件

🎯 考點: 「PM 是否屬於 program 管理團隊」→ 不屬於。

§104 規劃階段有沒有元件?考試當作沒有 (03:00:11)

核心: 實務上規劃時可能已有部分元件,但應考時當作規劃階段沒有元件,元件在交付階段才產生。

§105 初始 program 組織是哪個範圍 (03:01:51)

核心: 「初始 program 組織」只指 program 層(A),包括 PgM、sponsor、指導委員會,規劃時再加入 program 團隊和 PMO,沒有 PM。

• 只有向上匯報時,「program」才包括元件;其他情況說 program 就指上層
• 開發 program 管理計劃由這個團隊完成,PM 不參與;元件逐一啟動後才進入交付,規劃和交付是重疊、迭代的

§106 program 管理計劃:14 個子計劃 (03:04:30)

核心: program 管理計劃共 14 個子計劃(原本 13 個,新增 program 路線圖);其中 3 個來自績效域(收益管理、治理、干係人參與),另外 11 個是單獨領域。

• 協作、生命週期、戰略績效域沒有對應的管理計劃
• 單獨領域包括變更、溝通、財務、資訊、採購……範圍等
• 協作績效域提到協作計劃,但沒有列入子計劃

⚠ 新版變化: 子計劃從 13 個變成 14 個,新增路線圖(Program Roadmap)。

🎯 考點: 14 個子計劃 = 3 個績效域計劃(收益/治理/干係人參與)+ 各單獨領域計劃 + 路線圖;沒有協作計劃。(講師口述「3 + 11 + 路線圖」,加起來和總數 14 對不上,要以標準原文為準)

§107 program 層計劃指導 project 層計劃 (03:06:39)

核心: 這些子計劃是 program 層級的計劃,由 PgM 帶領的 program 管理團隊開發;元件啟動、PM 出現後,用這些計劃指導 project 制定對應的計劃。

• program 計劃剛開發時還沒有元件,要把 program 當成一個總體,先定好溝通、變更、財務等
• 元件計劃完成後整合進 program 計劃

§108 PMBOK 8 的 project 層結構 (03:07:48)

核心: PMBOK 第 8 版的 project 層結構是「治理 + 範圍、進度、財務 + 資源、風險、干係人」(3+3+1),已經和 PMP 舊版知識領域大不相同。

• project 會依據 program 層已制定的總體計劃,制定 project 層的計劃

⚠ 新版變化: PMBOK 8 把治理也列為績效域,結構改成治理 + 範圍/進度/財務 + 資源/風險/干係人。