Ch20 — 新版串講 ECO 2024 考綱逐條精讀 (311 min)

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

產製方式: 章節切 3 段交給 3 個 agent 平行逐段精煉, 共 139 個 §N (Part A: §1-39, Part B: §40-83, Part C: §84-139).

Part A (00:00:04 - 01:44:18) 綜述

本段是新版串講的「考綱精讀」第一部分。講師先交代 ECO 2024 的整體定位:距上一版(2011 版)十三年才更新,改動量小,85-90% 是措辭簡化(例如 in order to → to),真正改變含義的不多;五大領域(Domain)權重沿用,共 72 個 Task,其中專案集生命週期管理(Program Lifecycle Management)最重。名稱上,第一領域從 Strategic Program Management 改為 Strategic Program Alignment(強調雙向對齊),第二領域在 program life cycle 後補上 management。講師特別提醒:考綱和標準第 5 版的用詞不完全一致,5th 新增的內容在考綱中幾乎沒有體現;ECO 雖宣稱以專案集經理視角撰寫,但部分 Task(例如初始評估)發生在專案集經理被任命之前,應理解為「做專案集管理的人」的視角。

接著逐條精讀戰略一致性(SA)全部 11 個 Task:初始評估 → 高層級路線圖 → 財務框架 → 使命描述 → 評估商業論證 → 分析組織/業務戰略得出初步範圍與收益實現計畫 → 財務與非財務收益換資金授權 → 多維度約束評估目標 → 章程批准 → 與營運整合 → 利用變革機會擴大收益。最後回顧 SA,並開始生命週期 LC Task 1(制定章程,ECO 2024 擴充為 11 項內容)與 LC Task 2 的開頭。

最重要的判準:(1) initial/preliminary/high level 一出現就代表「立項前、粗略、大線條」;(2) 經高管發起人(executive sponsor)批准的 high-level roadmap 對專案集是「約束與要求」,不只是參考;(3) SA Task 5 是「評估」商業論證,不是「開發」;(4) 資金授權的前提是承諾財務與非財務收益;(5) 遇到新技術/新機會時,選擇主動抓住以擴大收益的答案,不要因為有風險就放棄。學習方法:考綱是一條條的「格言體」,理解每條的意思就好,不必硬把 Task 之間串成體系。

§1 ECO 2024 總覽:13 年才改一次,多數是措辭簡化 (00:00:17)

核心: ECO 2024(2025 年啟用)取代 2011 版,實質變化不大,大多是描述更清楚、措辭更簡潔。

• 上一版是 2011 版,隔了十三年才更新,更新量相對小,講師認為「甚至可以視為沒有特別大的變化」
• 85%-90% 的改動是措辭調整,最典型的是把 in order to … 簡化成 to …;真正改變含義的比例很低
• 趨勢:PgMP、PfMP 甚至 ACP 都越來越「以考綱為中心」出題;標準約每四年改一版,考綱更新慢得多
• 昨天補講的標準第 5 版新增內容,在考綱中幾乎沒有體現(講師稱之為「很有意思的現象」)

PMI 術語: Examination Content Outline (ECO) ↔ 考試大綱 / 考綱

⚠ 新版變化: ECO 2024 取代 2011 版;標準 5th 的新增內容不等於考綱的考點,備考以考綱為主。

§2 五大領域與名稱變化:Management → Alignment (00:01:32)

核心: 考綱只有五個領域,和標準 5th 的績效域(performance domain)數量不同;領域一、二、四改了名,三、五基本沒變。

• 考綱與標準第 5 版的結構不一樣,不要把兩者的績效域數量畫上等號;考綱就是五個領域
• 領域一:Strategic Program Management → Strategic Program Alignment。alignment 在標準裡一直在講,本質沒變,但更突出雙向對齊:由上往下對齊,也要由下往上對齊
• 領域二:原本只寫 program life cycle,現在加上 management,點出它的本質是「管理」
• 考綱和標準的措辭不完全相同,今天講的是考綱用詞

PMI 術語: Strategic Program Alignment ↔ 戰略專案集一致性 / Program Lifecycle Management ↔ 專案集生命週期管理 / Domain ↔ 領域

⚠ 新版變化: 領域一改名為 Alignment;領域二補上 Management。

§3 權重沿用,72 個 Task 一條一條來 (00:05:01)

核心: 權重和舊版一樣,生命週期管理占比最高;五個領域合計 72 個 Task,今天的目標就是逐條解讀。

• 生命週期管理占比最高(講師說「將近一半」),Task 數也最多;講師在後段明確說是 35 個
• 戰略一致性:11 個 Task
• 戰略一致性的精神:專案集的所有活動都要與組織戰略協調,最直接的是商業論證、章程、路線圖、風險管理策略、環境分析,都要先充分理解組織戰略再落實到管理活動

PMI 術語: Task ↔ 任務

🎯 考點: ECO 2024 權重(已查證):戰略一致性 15% / 生命週期管理 44% / 收益管理 11% / 干係人參與 16% / 治理 14%。

§4 ECO 的視角:不要死扣「專案集經理」,改用「做專案集管理的人」 (00:06:46)

核心: ECO 宣稱以 program manager 視角撰寫(依據角色調研),但約一成的 Task 套在專案集經理身上不合理,應理解為「做專案集管理」的任何角色。

• 九成以上的 Task 用專案集經理的視角理解都沒問題,但有些 Task 會讓人覺得「有點飄」:這動作真的是專案集經理做的嗎?
• 典型例子:SA Task 1「執行初始專案集評估」發生在立項之前,當時組織還沒任命專案集經理(經理是專案集啟動後才任命的)
• 講師建議:把「專案集經理視角」切換成「做專案集管理(management)」視角,甚至不必糾結角色
• ECO 寫的是有一份角色調研(轉錄為「RDSR」,即 role delineation/development survey),但講師認為這個說法不完全對

🎯 考點: 題目描述立項前的評估或分析時,不要因為「當時還沒有專案集經理」就排除選項;重點是「做這件事的管理動作」對不對。

§5 SA Task 1 執行初始專案集評估:initial / preliminary 的含義 (00:09:51)

核心: initial 或 preliminary 一出現,就代表「專案集尚未正式立項、尚未批准之前」的特別粗略的工作。

• Task 1:執行初始專案集評估,做法是定義專案集的目標、要求、風險,以確保與組織戰略計畫、目標、優先順序、願景、使命宣言保持一致
• initial 與 preliminary(紙本講義會出現)都翻成「初始/初步」,指專案集還沒正式立項、沒被批准前做的事,基本上是很粗略的估計
• 評估的時點在章程之前,甚至可視為在商業論證期間;章程才是承載專案集目標的正式文件,這時還沒有
• 目的:提早想清楚未來要承接的目標、組織/客戶/高層的需求、可能的風險,讓目標從一開始就不偏離戰略

PMI 術語: initial program assessment ↔ 初始專案集評估 / preliminary ↔ 初步

🎯 考點: 專案集目標是逐漸明確的,到章程時才以正式、穩定的方式發布,但評估目標的動作要在很早之前就開始。

§6 SA Task 1 用詞辨析:requirement 與 define (00:11:58)

核心: 這裡的 requirement 是一般用語「要求」,不是術語「需求」;define 的本意很正式,在這條裡應理解為「搞清楚」。

• requirement 當術語時應譯為「需求」,但需求通常已經很明確、有大量細節支撐,和「初始」這個詞矛盾;所以本條把它當一般用語(來自客戶、高層的要求)
• define 通常非常正式、嚴肅(以官方方式確定下來),但在本條不那麼強調正式性,意思接近「搞清楚目標、要求、風險」
• 一句話抓重點:記住「組織戰略計畫」這個詞就夠了,確定目標的過程要不斷和組織戰略計畫對齊
• 組織戰略計畫、組織目標、優先順序、願景、使命之間的關係,在影片課第一次課講過,可回頭複習

講師原話:「你確定目標的過程當中,不斷地要和組織戰略計畫去對齊,才能保證你未來真正確定專案集目標的時候是符合戰略一致性的。」

PMI 術語: requirements ↔ 要求(一般用語)/ 需求(術語) / define ↔ 定義、搞清楚 / organizational strategic plan ↔ 組織戰略計畫

§7 考綱的學習方法:格言體,一條是一條 (00:15:25)

核心: 考綱不是成體系的知識,是一條條的「格言體」;理解每條的意思、標出重點即可,不要強行在 Task 之間建立關聯。

• 學考綱和學標準很不一樣:一句話只要理解它的意思就好
• 在講義上把講師圈出的關鍵詞做標記,可以自己寫下理解
• Task 之間的構成邏輯不是體系化的,硬串關聯意義不大;但有延續性時知道就好(例如 Task 1→2→3)
• 為什麼叫「任務」:就是必須完成的事

講師原話:「它就是一條一條的,就像格言式,我把它叫格言體,所以它不強調體系化,但重點要特別突出。」

🎯 考點: 讀 Task 時先抓動詞(perform/establish/define/evaluate…)和受詞(assessment/roadmap/business case…),再看目的(to ensure alignment…)。

§8 SA Task 2 建立高層級路線圖:5th 標準已弱化 roadmap (00:17:06)

核心: 考綱 2024 仍把路線圖當成獨立的 Task,但標準第 5 版已大幅弱化 roadmap 作為獨立文件的地位。

• 標準第 4 版:路線圖從標準到考綱都是非常獨立的文件
• 標準第 5 版:roadmap 這個詞只出現兩三處;路線圖內容可以成為章程或商業論證的一部分,也可以獨立存在
• 講師提醒:不必硬排路線圖在章程之前或之後,第 4 版就因此造成很多做題混淆
• 知道這份文件「要有」就好,但不要強行排順序

講師原話:「到第五版的時候,roadmap 作為一個獨立文件的這種形式,在標準裡已經極大地弱化了。」

PMI 術語: program roadmap ↔ 專案集路線圖

⚠ 新版變化: 4th 中 roadmap 是獨立且重要的文件;5th 標準弱化為章程/商業論證的一部分,但 ECO 2024 仍保留獨立 Task。

🎯 考點: 不要糾結「路線圖在章程前還是後」的排序題;看情境判斷它扮演的角色。

§9 Milestone 的本意:不要和時間綁死 (00:18:51)

核心: 路線圖的基本內容就是里程碑;考試中要把 milestone 和「時間點」脫鉤,里程碑不一定都是時間。

• milestone 本意來自古羅馬:道路每隔一段距離放一塊石頭,標記到了哪、走了多遠(就像國道、省道的里程石)
• 引入管理領域後常帶時間概念(例如季度里程碑 Q1/Q2、每月 15 號)
• 考試裡要把 milestone 和時間剝離:里程碑代表的是「到達某個重要狀態或事件」,不必然是日期

講師原話:「在我們的考試裡邊,大家要把 milestone 和時間的概念剝離開,milestone 可不都是時間。」

PMI 術語: milestone ↔ 里程碑

§10 SA Task 2 用詞辨析:high level、preliminary estimate、estimate vs evaluate (00:20:36)

核心: high level 有「早期、大線條」和「層次高、不可突破」兩層意思;此處兩者兼具:早期、粗放,但要求可能很嚴格。

• high level 解釋一:早期,資訊不完備,只能定到年度甚至年,顆粒度大(不是粗糙,是大線條)
• high level 解釋二:層次高,底下有詳細計畫,但高層級的時間點不能突破
• 本條的 high level 同時包含兩者:早期、層次高、內容粗放;粗放不代表不重要,要求可能很嚴格
• preliminary estimate ↔ 初步估算,再次強調「早期、粗略」
• estimate 譯為「估算」,通常帶數字(時間、何時發生什麼事件);evaluate 譯為「估計/評價」
• 路線圖上的里程碑分兩類:外部(高層)對我們的要求(例如收益交付的大時間節點,是約束)vs. 立項後內部為管理方便自設的里程碑;此 Task 談的是前者

講師原話:「粗放不代表不重要,它可能是顆粒度比較大,但是要求可能很嚴格。」

PMI 術語: high-level ↔ 高層級 / preliminary estimates ↔ 初步估算 / estimate ↔ 估算 / evaluate ↔ 估計、評價

§11 executive sponsor vs senior management (00:24:17)

核心: 路線圖要經 executive sponsor 批准;在 PMI 體系中 executive(高管,C-suite)和 senior management(高層管理者)是兩個不同層級。

• 這時已出現 sponsor 一詞,代表這件事已經相當靠譜,有人願意當發起人
• executive sponsor 中譯常為「執行發起人」,講師認為更好的譯法是「高管發起人」
• executive / the executive:企業高管,CXO、C-suite(C 序列領導)
• senior management / senior manager:高層管理者,級別低於高管
• PMI 系列中這兩個詞有區別,讀題要分清楚

講師原話:「高管和高層管理者還不是一個意思,大家在看 PMI 系列的時候這兩個詞是有區別的。」

PMI 術語: executive sponsor ↔ 高管發起人 / senior management ↔ 高層管理者 / C-suite ↔ C 序列高管

§12 validation 與 approval:高管驗證後批准路線圖 (00:26:17)

核心: 高管發起人要先 validation(核驗內容是否合理)再 approval(批准);可以不親自做,但要透過其他部門或資料核驗。

• validation ↔ 驗證/核驗:確認專案集管理團隊(或早期籌備團隊)提供的路線圖內容是否合理
• 驗證不一定本人親自做,可找其他部門、資料來核驗
• 路線圖要反覆和關鍵干係人確認,最後由高管發起人批准
• 批准的依據可以是討論,也可以是用數字、資料證明合理

講師原話:「他要去驗證一下,他找別的地方的資料或找別的部門的很多人幫他來核驗……一旦他批准了以後,approval roadmap。」

PMI 術語: validation ↔ 驗證 / approval ↔ 批准

§13 經批准的 high-level roadmap = 指導性文件 + 約束 (00:26:47)

核心: 高層批准的 high-level roadmap 對後續專案集是必須遵守的約束與要求,不只是「不知道怎麼做時翻來看」的參考。

• 講師課堂提問:高層批准的 roadmap 對專案集是什麼性質?答案:指導性文件,更精確地說是約束/要求
• 它是早期高階管理層對專案集的要求或期望;後續章程的目標、主進度計畫、收益實現計畫,都能在這裡找到約束點
• 「指導性」容易被理解為參考,實際要強烈得多:除了何時交付什麼結果,還提出很多要求

講師原話:「高層一批准,就成為了我們的指導性文件……它對我們來講是一個約束,或者叫要求。」

🎯 考點: 題目若說「高管發起人已批准高層級路線圖」,後續規劃要以它為約束,不能自行更改高層里程碑。

§14 high-level roadmap 與專案集內部 roadmap 的分層 (00:29:20)

核心: 進入規劃後,專案集經理要把 high-level roadmap 細化;高層定的里程碑「定死不能改」,自設的小里程碑則是向下約束執行團隊的管理手段。

• 例:高層批准的 HL roadmap 有 milestone 1、milestone 2 兩個大節點
• 專案集內部為確保這兩個節點達成,增設小里程碑、關口、checkpoint
• 自設里程碑向上是確保高層里程碑達成的管理手段,向下成為 project manager 與執行團隊的約束條件與指導性要求
• 內部細化的那份就不能再叫 high-level roadmap;high level 這個前綴一定要分清楚

講師原話:「他首先要把 high level roadmap 的要求定死在你的這個里程碑上,都不能改的,因為是高層給你的要求;剩下這些小的里程碑是我們設定的,是給下面用的。」

§15 SA Task 3 定義 high-level roadmap 與建立財務框架 (00:32:31)

核心: ECO 2024 新增「財務框架(financial framework)」:早期要先說清楚錢從哪來、何時來、如何支出。

• 路線圖部分和 Task 2 一樣;新增的是 financial framework(財務框架/財務管理框架)
• 重大專案集要先把錢說清楚:路線圖定了里程碑,但錢怎麼來、從誰那來、何時到、按什麼方式支出?
• 在標準第 4 版的專案集財務管理中,financial management plan 之前就有 financial framework,出處在此
• 內容:資金來源(自有、融資:銀行或其他金融機構);各年度預計消耗;保證 cash flow in 與 cash flow out 能運轉
• 例:需要一千萬,資金來源可能找到兩三千萬;支出有時間性;財務框架做不到每月每週,但至少到季度或年度

講師原話:「錢從哪來、有幾個源頭要搞清楚,有的是自有資金,有的是融資……我得保證 cash flow in、cash flow out 能夠運行起來。」

PMI 術語: financial framework ↔ 財務框架 / cash flow ↔ 現金流

⚠ 新版變化: financial framework 是 ECO 2024 Task 3 的新增內容。

§16 financing vs financial management;HL roadmap + 財務框架 = 早期基準 (00:35:16)

核心: 財務框架是完整但框架性的;之後的財務管理計畫顆粒度更細。HL roadmap 加財務框架,構成專案集最早期的高層級基準。

• 財務框架之後會發展為財務管理計畫,顆粒度更細;執行中若資金來源到不了位,要補充新的來源
• financing ↔ 融資(找錢);financial management ↔ 財務/會計管理(管錢),兩者都要在開始時想明白
• 有了 HL roadmap + financial framework,就為後續定義、規劃、執行建立了基準(這個基準也是 high level 的)
• 「有了基線大家才會幹事,沒有基線執行團隊是不會做事的」
• 這個動作很可能不是專案集經理做的,當時專案集可能還沒被批准
• Task 描述說「定義、規劃、執行」並不完整(還有收尾也會用到),任務描述簡潔但不一定嚴謹,不必較真

講師原話:「任務的描述簡潔,但是不一定很嚴謹,那就不要在這上面去較真,但它重點特別突出。」

PMI 術語: financing ↔ 融資 / financial management ↔ 財務管理 / baseline ↔ 基準

§17 SA Task 4 定義專案集使命描述:使命從哪來 (00:38:33)

核心: 透過評估干係人的關切與期望來定義專案集使命,從而確立專案集方向;本條揭示:專案集使命的本質是重要干係人對專案集的期望。

• 講師把 mission statement 譯為「使命描述/使命陳述」:用一兩句話把使命講清楚
• 課堂提問:使命怎麼來?學員答「來自願景」,沒錯:願景定義未來某種狀態,使命是為此付出努力、採取方法(例如「為中華之崛起而讀書」「讓天下沒有難做的生意」)
• 廣義來源:戰略、願景、路線圖設定的方向都是正確來源
• 但本條講的是另一個本質:使命不是自由發揮,而是關鍵干係人對你的期望(比喻:首長拍拍你的肩說全軍就靠你了)
• 願景、戰略、roadmap 本身也都是高層、關鍵干係人的想法,最後都落到重要干係人身上

講師原話:「專案集的使命描述,就是干係人的期望,他期望你做的,不是我們自己自由發揮。」

PMI 術語: mission statement ↔ 使命描述 / vision ↔ 願景

🎯 考點: 題目問「如何定義專案集使命」,答案方向是評估(關鍵)干係人的關切與期望。

§18 concerns vs expectations;vision、mission、roadmap、strategy 的層次 (00:42:37)

核心: 期望(expectations)是正向的,關切(concerns)偏擔憂;兩者都要評估。vision、mission、roadmap、strategy 都能指方向,但層次與性質不同。

• expectations:心心念念期望的、美好的東西
• concerns:擔憂、擔心類(像新聞裡「中方嚴重關切」),不能只看期望,也要看他擔心什麼
• 要想辦法多接觸高層干係人,了解他們的想法,好的壞的都要
• 層次:vision > mission,兩者都是「上層建築」;vision 通常是名詞性描述(終點在哪),mission 通常是動詞性/動名詞描述(強調動作)
• roadmap:帶時間維度、劃出一條路徑(說「計畫」不太恰當,計畫太細)
• strategy(策略):比願景、使命低,是方向性的做法(迂迴還是直接出擊、農村包圍城市…),比 plan 粗略很多

講師原話:「vision 通常是名詞性的描述,mission 通常是動詞性的描述,或者叫動名詞的描述,roadmap 通常是要帶時間維度的。」

PMI 術語: stakeholder concerns ↔ 干係人關切 / stakeholder expectations ↔ 干係人期望 / strategy ↔ 策略

§19 SA Task 5 評估專案集商業論證:是 evaluate 不是 develop (00:48:39)

核心: 本條是評估商業論證,不是開發;商業論證要先有人做好,這裡做評估、評審與批准,評估者不是專案集經理。

• 商業論證是立項前特別重要的步驟,也是考試重點
• 評估者肯定不是專案集經理(專案集經理反而是被評估的對象之一,而且當時可能還沒出現)
• business case 在業界有「文件/報告/動作」之爭;在 PMI 體系既指論證動作的名詞,也指這份文件
• 評估商業論證,用來制定、驗證、評估專案集的目標、優先順序、可行性、準備度,以及與組織戰略計畫的一致性
• 重要性極高,甚至比專案集章程更受高層/投資方關注

講師原話:「大家記住,這是叫評估商業論證,不是開發商業論證,之前得有人做好,然後到這個任務我們要評估。」

PMI 術語: business case ↔ 商業論證(也會譯為「業務論證」) / evaluate ↔ 評估

🎯 考點: 看到 evaluate the business case,要對應「論證已完成、現在審查」;不要選「開始撰寫商業論證」。

§20 商業論證的內容:CBA、目標來源、組織準備度 (00:50:39)

核心: 商業論證的核心是成本收益分析(CBA),它是專案集目標的來源;章程把論證的結論「寫死」成正式目標。

• 內容:市場分析、成本收益分析,論證做這件事會有哪些收益與價值、付出什麼代價、市場與競爭對手情況、公司資金情況
• 最核心的是 CBA(Cost-Benefit Analysis):投這麼多錢能不能回報、可不可行、能不能接受
• 目標演進:初始評估(Task 1)→ 商業論證進一步確認 → 章程正式寫下並「焊死」
• 用途:確認目標、確認在組織優先事項中的位置、可行性、組織準備度(人員、資金、環境是否準備好,內涵很寬)
• 商業論證說服高層接受這件事、告訴高層為什麼一定要立項;高層認可後,章程寫下目標

講師原話:「目標哪來呢?從商業論證的分析結論當中來,從最初的初始評估當中來,一步一步走到這。」

PMI 術語: cost-benefit analysis (CBA) ↔ 成本收益分析 / readiness ↔ 準備度 / feasibility ↔ 可行性

§21 評估商業論證的兩個作用:驗證內容與對齊戰略,可能給出 No (00:54:50)

核心: 評估商業論證一方面驗證內容是否正確合理(作為目標來源),一方面核實它對組織戰略的貢獻;結論可能是 No,專案集就不再往下走。

• 評估的結論是 yes、no 或某種程度,依據是對組織戰略的貢獻(組織戰略寫在組織戰略計畫裡)
• 既驗證內容的合理性,也核實論證的過程、資料、結論
• 很可能在這一步就給出 no 的結論,不必再走下去

講師原話:「很有可能在這就給一個 no 的結論,就不用再走下去了。」

🎯 考點: 商業論證評估不通過,專案集可以在立項前終止;這是正確的治理行為,不是失敗。

§22 SA Task 6 分析組織戰略與業務戰略:三層戰略 (00:55:55)

核心: organizational strategy(公司/組織戰略)和 business strategy(業務戰略)是兩個戰略層級,不是同義詞翻譯差異;下面還有職能戰略。

• 講師把 business strategy 由「商業戰略」改譯為「業務戰略」以統一用語
• 第一層:公司戰略 corporate strategy(對應 company/corporate,題目中的 organizational strategy 就是這一層)
• 第二層:業務戰略 business strategy(對應 business unit / business group,即事業部、事業群 BU/BG)
• 第三層:職能戰略 functional strategy,為配合公司與業務戰略的達成,在職能領域(例如供應鏈:備三年貨還是零庫存)採取的策略
• 本條要分析組織戰略、業務戰略、內外部影響因素,以及專案集驅動因素(program drivers)的可用資訊

講師原話:「這個詞大家千萬不要把它理解為是翻譯上的一個問題,實際上它是一個戰略的層級。」

PMI 術語: organizational strategy ↔ 組織戰略 / business strategy ↔ 業務戰略 / functional strategy ↔ 職能戰略 / program drivers ↔ 專案集驅動因素

§23 SA Task 6 方法與產出:市場分析 + 高層級 CBA → 初步範圍說明 + 收益實現計畫 (00:58:51)

核心: 用市場分析和高層級成本收益分析,識別並量化干係人期望實現的收益,進而制定初步的專案集範圍說明和收益實現計畫。

• 工具:market analysis(諮詢機構的市場研究、競爭對手、市場需求、價格、勞動力成本、國與國的競爭)和高層級 cost-benefit analysis
• 干係人期望在這裡變具體:不是泛泛的期望,而是對專案集要實現什麼收益的量化期望
• 產出一:preliminary program scope statement,初步、非常粗略的專案集範圍
• 產出二:benefits realization plan,此時也是粗略的,可視為 roadmap 的進一步計畫,仍是高層對專案集的要求(源自干係人期望);收益管理領域會再看到它
• 收益實現計畫比 roadmap 細緻一些;本條與前面的 Task 有概念重疊,實際是在為章程與專案集管理計畫做準備(管理計畫要圍繞收益實現展開)

講師原話:「它不是泛泛的期望,而是他對我專案集要實現什麼收益的量化的期望,其實就是把收益要量化出來。」

PMI 術語: market analysis ↔ 市場分析 / preliminary program scope statement ↔ 初步專案集範圍說明 / benefits realization plan ↔ 收益實現計畫

§24 SA Task 7 估算財務框架與非財務收益,換取資金授權 (01:03:35)

核心: 收益要同時考慮財務收益和非財務收益;管理層依專案集能帶來的總體收益決定是否給予資金。

• 前面 Task 3 是財務框架;本條擴充:財務框架要涵蓋整個專案集的 financial 與 non-financial 收益
• 商業論證已通過,接下來要把資金問題想得更清楚:投入多少資源、何時需要什麼資源,才能獲得哪些財務與非財務收益
• 想清楚了資金才會批下來並持續到位;財務管理不完全在發起人控制中,發起人負責找錢,撥付還受組織資金管理政策約束
• 非財務收益容易被忽略,千萬不要忽略

講師原話:「管理層會根據我們的總體收益情況,來決定給予我專案集資金的支援。」

PMI 術語: financial benefits ↔ 財務收益 / non-financial benefits ↔ 非財務收益 / funding authorization ↔ 資金授權

§25 資金驅動元件優先順序:專案集 vs 專案組合的排序邏輯 (01:05:45)

核心: 有了資金依據,專案集內的元件才能排優先順序;專案組合按戰略支持度「簡單粗暴」排序,專案集還要考慮元件間的依賴關係。

• 依資金估算、收益估算和資金管理要求,決定哪個元件(component within program)優先保障資金
• 對組織戰略、專案集戰略與目標支持度越高,優先順序越高,資金越要優先保障
• 專案組合管理:排序取決於與組合及公司戰略的匹配度,誰支持越多就給誰資源,不關心元件內部聯繫(那是專案集經理的事)
• 專案集管理:除了重要程度,還要理解元件間的依賴關係,排序的技術要求高得多

講師原話:「組合管理是比較簡單粗暴的,誰支持我的戰略程度越高我就給你資源……專案集內部的優先順序排序是技術要求非常高的,因為它要了解依賴關係。」

PMI 術語: component ↔ 元件 / interdependencies ↔ 依賴關係 / prioritization ↔ 優先順序排序

🎯 考點: 專案集層級的元件排序題,除了戰略貢獻,還要看依賴關係;只看戰略支持度的是專案組合思維。

§26 SA Task 7 關鍵詞:收益承諾 → 財務框架 → 資金授權 (01:08:47)

核心: 獲得資金的前提是向高層承諾財務與非財務收益;有了財務框架,財務人員才能保證資金何時進、何時出。

• 第一個關鍵詞:承諾。沒有向組織承諾收益,就不會配備資金
• 第二個關鍵詞:財務框架(cash flow in / cash flow out);資金來源由發起人協調,資金管理由組織財務部門配合
• 專案集經理不必是財務專業,但要有豐富的財務管理經驗、了解財務工作模式:不做預算拿不到錢,不拿預期收益去要錢也不行
• 不同角色關注財務的角度不同:財務人員看撥付節奏與資金需求,專案經理關心用錢時專案集能否及時提供
• 資金和資源就像注入專案集的能量,驅動元件排序與整個專案集運轉

講師原話:「你得有承諾,非財務收益和財務收益分別是什麼,給組織高層承諾,承諾完之後你才有資金的保障。」

§27 「授權」的分量:從畫大餅到拿到保險櫃鑰匙 (01:11:15)

核心: 商業論證階段的成本收益都只是預計,沒有真正給錢;資金授權才是把「保險櫃鑰匙」交到你手上。

• 專案集管理者要建立並評估(評審、驗證)財務框架的可行性,並說明會帶來的收益
• 商業論證通過只代表組織認可、願意給錢,錢還沒到手;論證通過的事拿到財務那裡,也不一定立刻撥款,還有規則
• 授權前:全是分析、可行性、估計、「畫大餅」;授權後:鑰匙在你手上,可以開保險箱拿錢
• 組織非常現實:看不到預期的成果與承諾,錢不會給你用

講師原話:「前面全是分析、全是可行性,在這是真正把那把金鑰匙給到你,可以開保險箱拿錢的意思。」

PMI 術語: authorization ↔ 授權

🎯 考點: 區分「商業論證批准」(認可可行)和「資金授權」(實際可動用資金),兩者是不同時點。

§28 SA Task 8 評估專案集目標的多維度約束 (01:13:10)

核心: 評估專案集目標是否合理可行,不能只看財務與野心,要平衡外部監管法律、社會影響、可持續性、跨文化、政治氣候、道德關切等多種因素。

• 這時才開始評估專案集目標(其實就是在為章程做準備);前面評估的是商業論證和財務框架
• 列出的約束不必專門背,重點是:目標的確定要平衡非常多的因素
• 監管與法律:新能源、電力、文旅、基礎設施、AI 等專案集,立法與監管變化快,對公司再重要(例如占年度經營目標 30%)也要符合外部要求
• 地域與文化:在組織內可行不代表在社會上可行;在中國可行不代表在其他國家可行;南北、東西文化不同
• 政治氣候與國際關係;資金若來自世界銀行或外國,會要求可持續性,沒有可持續性就拿不到投資

講師原話:「在組織內可行,在社會上不一定可行;在中國可行,在其他地方可能不一定可行。」

PMI 術語: regulatory ↔ 監管 / sustainability ↔ 可持續性 / cultural ↔ 文化 / political climate ↔ 政治氣候 / ethical concerns ↔ 道德關切

§29 多維度約束續:干係人一致性與交付能力(晶片例) (01:17:11)

核心: 還要考慮各方干係人(政府、客戶、供應商、合作夥伴、競爭對手、監管)是否一致,以及「有錢也做不出來」的技術與交付能力限制。

• 干係人面:政府、客戶、供應商、合作夥伴、競爭對手、國家監管、國際考量;考慮清楚才知道是否與重要干係人一致
• 交付能力:目標吸引人、資金充沛,但技術達不到仍無法交付;例如晶片生產,有錢也買不到光刻機
• 專案經理接到任務完成就好,專案集經理要想得多得多;所以專案集經理在組織中很稀缺,通常是中高層,需要全局意識與解決問題的能力

講師原話:「資金多,沒有技術你也仍然做不到。」

§30 SA Task 9 向領導層呈現章程並取得正式批准 (01:19:36)

核心: 把目標、所需資源、約束、假設、邊界、收益策略、重要干係人放進章程,向組織領導層 present,取得正式批准與授權;章程發布是專案集正式啟動的標誌。

• 向高層要把目標確定下來,把所需資源、約束、假設、邊界、收益策略、重要干係人寫進章程
• present ↔ 展示、呈現:向組織領導層展示章程,讓管理層正式批准,獲得專案集的正式授權
• 前面的 Task 都是準備工作;這一步才是真正啟動,標誌是章程發布,並確定專案集經理
• 比喻:專案集經理拿到「保險櫃的鑰匙」加上「虎符」:可以調錢、調糧、調人;在此之前都是評估、分析、溝通、協商

講師原話:「前邊所有的都是準備工作,在這兒是真正要啟動這個專案集,啟動的標誌呢就是章程的發布。」

PMI 術語: program charter ↔ 專案集章程 / present ↔ 呈現 / formal authorization ↔ 正式授權

⚠ 新版變化: 章程內容在 2011 版考綱中寫得很粗略;ECO 2024 把它展開為 11 項(放在生命週期 LC Task 1),大致與標準相匹配,講師稱之為本次考綱最大的變化之一。

§31 章程 = 軍令狀 = 專案集的憲法;initiate vs initial (01:22:06)

核心: 章程寫明成本、進度(重大里程碑)、收益,是專案集的「軍令狀」;對高層而言它不是 high level 文件,對專案集而言卻是憲法。

• 章程最重要的內容(不完整列舉):成本、進度、收益:結束後交回什麼、何時達成哪些重大里程碑、花多少錢
• 寫進章程的內容仍是 high level,但「high level 對誰說」:對組織高層而言章程根本不算 high level;對專案集經理和專案集本身而言,章程就是憲法、任命狀(有什麼權力、交回什麼結果、遵循哪些原則)
• 這些內容不是此時才決定,而是經過初步分析、風險判斷、商業論證一路走來
• 用詞辨析:前面的 initial 是「初步」;這裡的動詞 initiate(相關詞 initialize 初始化、initiating 啟動)是正式啟動的意思,專案集真的要開幹

講師原話:「專案集章程就相當於整個專案集的憲法、任命狀,你有什麼權力,你要給我交回來什麼結果。」

PMI 術語: initial ↔ 初步 / initiate ↔ 啟動

§32 SA Task 10 識別專案集活動與營運活動的整合機會 (01:24:18)

核心: 在專案集全程(定義、交付、收尾)持續識別、評估把專案集活動與組織營運活動整合的機會,以在組織內或跨組織協調、整合收益。

• 本條與前面沒有邏輯連續性,單獨看
• 啟動/規劃 → 定義;執行/監控 → 交付;收尾 → 收尾;可用這三組詞對應生命週期
• program activities 已包含專案集內部的營運活動、核心活動與支援活動;這裡的 operational activities 指組織層面的營運(接收專案集收益的部門,可能是內部或外部組織)
• 目的:過程中有營運支撐,移交時營運接得住,接手後讓收益持續發展
• 需要整合的面向(舉例,不必背):人力資源、技能、設施、財務/資金/資產、流程與系統

講師原話:「你不是一個獨立王國,要和組織的內部和組織外部的各個層面要協調。」

PMI 術語: integration opportunities ↔ 整合機會 / operational activities ↔ 營運活動 / program activities ↔ 專案集活動

§33 SA Task 10 精神:收益最大化與移交營運 (01:27:35)

核心: 專案集經理要在組織內及跨組織協調,整合專案集收益,原則是收益最大化;收益最終交給組織、由營運維持。

• 前面已給了授權、資金、財務框架、目標;執行過程(定義 + 交付 + 收尾)中要抓住機會、理解需求、整合收益
• 收益最終要交給組織,由組織營運來維持
• 講師評價:本條很寬泛,考得不多

講師原話:「這個任務很泛,考的也不是很多,這是很寬泛的一個任務。」

§34 SA Task 11 利用變革機會最大化收益:exploit 與 change 的辨析 (01:29:00)

核心: 抓住一切可擴大收益的機會;exploit 譯「開拓」(主動創造機會)比「利用」(機會已存在)高度更高;change 依情境可譯變化、變革、變更。

• exploit:譯「開拓」= 創造機會;譯「利用」= 機會已經存在;兩種譯法在中文裡高度不同
• change 有三種譯法:變化、變革、變更,在這裡都適用;戰略層面多年難得一遇的叫變革性,甚至革命性(但「革命」有專屬詞 revolution)
• 要開拓並利用能改變現狀的機會來擴大收益

講師原話:「只要能擴大收益,我們都要去抓住它。」

PMI 術語: exploit ↔ 開拓、利用 / change ↔ 變化、變革、變更 / benefits realization ↔ 收益實現

🎯 考點: 題目說「有新技術可以節省時間但可能帶來風險」,答案選主動採用、積極爭取的選項;有風險很正常,不能因為有風險就不爭取(風險另行管理)。

§35 SA 11 個 Task 回顧 (01:30:59)

核心: SA 的主線是「立項前評估 → 路線圖與財務框架 → 使命 → 商業論證 → 戰略分析 → 收益換資金 → 約束評估 → 章程批准 → 營運整合 → 開拓變革機會」,11 條中至少 8 條在章程之前。

• T1 初始評估:很寬泛,評估目標、要求、風險,與組織戰略、願景保持一致;這時還不確定是不是專案集,常叫 initiative(舉措,也可譯倡議、提議),即初步想法,論證可不可行
• T2 路線圖:大體時間安排,高層確定後成為對專案集的要求;可能是高層或戰略部門做的
• T3 財務框架:資金怎麼來、怎麼花,給一個管理框架
• T4 使命:確定專案集使命
• T5 評估商業論證:承接組織的什麼戰略任務、對應什麼收益、要花多少錢、可不可行
• T6 分析組織戰略與業務戰略:確保方向一致,確定初步範圍說明與高層級收益實現計畫
• T7 進一步評估財務框架的可行性,保證資金到位與支出,同時重視非財務收益
• T8 確定目標時多角度考慮多方限制;T9 領導層批准,專案集正式啟動;T10 執行中找機會整合;T11 擴大收益實現
• 戰略一致性的 Task 比較分散,一條一條理解即可

講師原話:「initiative 翻譯成舉措……反正就是一個初步的想法,論證一下可不可行。」

PMI 術語: initiative ↔ 舉措、倡議

§36 LC Task 1 制定專案集章程:ECO 2024 擴充 11 項內容 (01:34:33)

核心: 生命週期管理共 35 個 Task,第一個就是制定章程;ECO 2024 最大的任務變化是章程內容變細(列出 11 項),但方向沒變。

• 章程 11 項不必死背,大致與標準中章程的內容對得上
• Task 描述:制定專案集章程,利用所有干係人的輸入,啟動並設計專案集及其收益,實現戰略一致性
• 列出的內容:專案集範圍、假設條件、約束條件、高層級風險、高層級收益及其實現(收益就是目標的另一種說法)、時間安排(很像 roadmap)、關鍵干係人、成果、資源分配,以及將專案集與商業論證對接的條款
• 放進章程的內容,都會成為專案集要向組織交付的東西或對專案集的約束
• 高層級收益是總的、寬泛的總目標,之後要在收益管理領域分解為收益分解結構/收益依賴地圖

講師原話:「這次考綱的變化,任務變化比較大的就是這個,它變化大是內容變細,方向並沒變。」

PMI 術語: program charter ↔ 專案集章程 / assumptions ↔ 假設條件 / constraints ↔ 約束條件 / high-level risks ↔ 高層級風險

⚠ 新版變化: 2011 版考綱的章程內容只有寥寥幾條;ECO 2024 展開為 11 項。

§37 章程 vs 商業論證;資源與授權;所有干係人的輸入 (01:37:31)

核心: 商業論證是分析資料、過程與結論;章程把結論放進來作為要實現的目標。批准章程就要給資源與權力。

• 兩份文件最大的區別:商業論證 = 分析資料 + 過程 + 結論;章程 = 把結論當作目標確認下來
• 組織批准章程,就要給資源、給權力(授權做什麼)、給要求與範圍
• 「利用所有干係人的輸入」不是把所有意見照抄進來,而是了解所有干係人的想法後,決定放什麼

講師原話:「商業論證是我們的分析資料、過程、結論,而章程是把結論放進來,作為我們的目標存在的。」

🎯 考點: 選項區分「商業論證」與「章程」時,看它是論證可不可行(商業論證)還是正式確認目標與授權(章程)。

§38 design program 是什麼意思:從總體收益分析出元件結構 (01:38:42)

核心: 「設計專案集」= 設計專案集包含哪些元件、元件間的結構;方法是從總體收益往回分析中間收益與依賴關係,這是整個標準最核心的知識。

• 原文 initiate and design program and program benefits(講師指出原文用詞有重複)
• 課堂提問「design program 是什麼意思」:學員答「專案集要包括哪些元件的初步想法」,講師肯定方向
• 元件真正確定是很久以後的交付階段;此時只是啟動,只有粗略想法,但已開始考慮
• 元件怎麼來?從總體收益出發:要實現哪些中間收益、中間收益和總體收益的依賴關係、要達到中間收益之前要做什麼,經過這整套分析才能設計出元件
• 這就是收益依賴關係分析(收益分析),從章程這一步就開始了

講師原話:「設計專案集實際上就是設計專案集到底有多少元件,設計元件之間的結構是怎麼樣的。」

PMI 術語: design program ↔ 設計專案集 / intermediate benefits ↔ 中間收益 / benefits dependency analysis ↔ 收益依賴分析

🎯 考點: 專案集元件從哪來?答「從總體收益分解(收益依賴分析)推導」,不是先列專案再湊成專案集。

§39 章程是起點:對誰而言;high-level benefits and their realization (01:42:41)

核心: 章程是專案集立項後的起點,但對高階管理層而言,大量工作(SA 11 個 Task 中至少 8 個)已在章程前完成。

• 「立項」之前有大量工作:SA 的 11 個 Task 中至少 8 個是在章程出現前做的
• 對專案集經理與成員來說,章程是起點;從這裡開始考慮專案集的成果與要實現的收益怎麼做到
• 英文 high-level benefits and their realization:their 指收益,即收益該怎麼實現要有總體想法,暗示收益依賴關係分析從這裡開始
• 簡記:LC Task 1 = 一份文件叫章程;LC Task 2 = 一份文件叫專案集範圍說明書(本段在此結束,下接 Part B)

講師原話:「前面講了 11 個,其中至少有 8 個都是在章程出現之前我們做的動作。」

PMI 術語: program scope statement ↔ 專案集範圍說明書

Part B (01:44:23 - 03:26:22) 綜述

這段接續上一段,從生命週期領域(Program Life Cycle Management, LC,ECO 2024 佔 44%)Task 2 的範圍說明書講起,一路逐條精讀到 Task 25 的偏差與趨勢分析(後段在 Task 25 中途結束)。Task 1–6 屬啟動/構建(formulation),Task 7–15 是規劃(planning),Task 16 起進入交付(delivery)。講師的主軸是「英文原文用詞辨析」:roadmap 有沒有 high-level 定語、criteria 與 standard 的差別、constituent projects 等於 component、alignment(目標對齊)和 consistency(行為統一)的差別、training/coaching/mentoring 的遞進關係,以及 audit(審過程)和 inspection(驗結果)的差別。

最重要的考點判準: 1. 路線圖輸入的 historical information 指的是過去其他專案集的資料,不是當前的 WBS。 2. RAM 是專案集經理分工給核心團隊用的;專案經理是透過章程任命的。大部分資源應該消耗在專案層面。 3. 專案集為元件定 KPI(由 PMO/核心團隊協助,並向 sponsor/指導委員會報告);專案集本身的成功標準則由 sponsor/指導委員會訂定。 4. 5 個專案用了 5 套 PMIS 時,答案是「統一」。專案集績效報告也不等於各專案資料相加,要整合跨專案的共通、交叉與抵銷部分。 5. 元件收尾要經指導委員會確認,批准的前提是可交付物完成,不是收益。專案集經理是以審計(audit)過程與貢獻度來管專案經理,不直接插手可交付物。

§40 LC Task 2:把戰略目標轉成專案集範圍說明書(舉例) (01:44:23)

核心: 範圍說明書(scope statement)把抽象的戰略目標,轉寫成「要做哪些工作」的敘述性文件。

• 前一份文件是章程(charter),這一份叫 scope statement,也有人通稱為 program scope description。
• 相對組織的戰略目標,它已經是細化後的結果;但對專案集內部而言,它仍是高層級(high-level)文件。
• 例子:戰略目標是「A 產品市佔率提升 3 個百分點」,這同時也是一種收益的表達。
• 轉成範圍說明書時要具體化:一年內在 ABCD 四區,把 A 產品升級為新版本,賣 2,000 台可帶來 +1%;舊版本賣給老客戶 5,000 台可帶來 +1.5%。與此相關的所有工作就是專案集的範圍。
• 範圍說明書要回答兩件事:要達成這個目標包含哪些內容,以及需要做哪些事。

PMI 術語: Program Scope Statement ↔ 專案集範圍說明書 / Program Scope Description ↔ 專案集範圍描述

§41 Task 2 的方法:敘述性文件,與 sponsor/指導委員會「協商」 (01:47:15)

核心: 範圍說明書是敘述性的(statement、description)。界定範圍時,要和 sponsor 與指導委員會溝通協商,確認範圍是否合宜、是否準確。

• statement、description 這兩個詞都指文字性的敘述。
• 光靠自己的專業能力不夠,還要找關鍵干係人確認範圍界定得對不對。
• 協商對象是發起人(sponsor)和指導委員會(steering committee)。
• 辨析:原文的 negotiation 在這裡應理解成「溝通/協商」,不是談判桌上互相拿籌碼交換的那種談判。
• 目的是把抽象的總體目標轉成敘述,讓更多人看得懂。

PMI 術語: Negotiation ↔ 協商(此處非談判) / Steering Committee ↔ 指導委員會

§42 LC Task 3 制定路線圖:有沒有 high-level 定語,是區分關鍵 (01:48:40)

核心: 戰略域的路線圖前面掛著 high-level 這個定語,指章程批准前的粗略框架。LC Task 3 的路線圖沒有這個定語,是章程批准後的細化版。

• 講師問學員:這裡的路線圖和前面講的有何不同?答案就在「定語」。
• 有 high-level 的那份是粗略、框架性的,產生於專案集批准之前。
• 這裡的 Task 3 發生在章程已批准、構建已結束之後,路線圖必須細化。
• 這既是考試技巧,也是讀標準時的閱讀理解技巧。

🎯 考點: 題目出現 high-level roadmap,對應的是戰略域、章程批准前。沒有定語、強調細化的 roadmap,對應的是 LC 構建/規劃期。

§43 Task 3:里程碑鎖死,中間加檢查點,向上說明、向下管理 (01:50:21)

核心: 高層面的里程碑(MS1、MS2)已經鎖死,不能討價還價。專案集經理要在中間補上小節點與檢查點。

• 前期確定的 milestone 和 high-level 要求是「一定要做到」的約束,不能拿來改。
• 細化方式:在大里程碑之間加檢查點、次級里程碑或補充要求。
• 向上:向高層說明我用什麼方式保證整份路線圖能被滿足。
• 向下:用這些節點管理下面的元件。

§44 Task 3 的輸入:goals & objectives、applicable historical information、available resources (01:51:00)

核心: 原文寫的 historical information 指的是過去其他專案集的資料與資產,不是本專案集的 WBS,因為這時 WBS 還沒產生。

• 利用專案集的 goals and objectives(目的與目標)細化路線圖,這點容易理解。
• applicable historical information:過去曾做過、可參考的專案集文件與資產。
• 講師提醒這個 historical 的定語常被忽略。如果誤以為是本專案的 WBS,就無法解釋「WBS 還沒產生,怎麼能拿來做路線圖」。
• 有了路線圖,執行過程才能確保與組織戰略一致。

講師原話:「這個地方是有考題的,經常會出……你理解為是過去的專案,不是你當前那個。」

🎯 考點: 制定路線圖的輸入出現「歷史資訊」時,反射成「組織過程資產/過去專案集經驗」,不是本專案集的 WBS。

§45 Task 3 的作用:用路線圖管理干係人期望 (01:52:23)

核心: 細化後的路線圖讓大家都知道專案集要照什麼節奏走,所以它也是管理干係人(sponsor、指導委員會)期望的工具。

• high-level 里程碑細化成專案集層面的路線圖後,大家看到的是同一套節奏。
• 管理的期望主要是發起人與指導委員會的。他們批准了路線圖,就代表雙方已達成共識。
• 之後他們對專案集的期望,就會以這份路線圖為準。

講師原話:「他只要我做了他批准了,那意味著大家達成了一致意見……接下來他對我的專案期望,是不是就會受到我的這個路線圖的影響。」

§46 LC Task 4 責任分配矩陣:識別角色並分配到人 (01:53:31)

核心: Task 4 開始分工。用 RAM 識別專案集需要的角色,再把角色分配給具體的人。

• RAM(Responsibility Assignment Matrix)是常考點;講師提到的 RACI(轉錄作 RSA)是 RAM 的一種具體形式。
• 識別角色的意思是:專案集管理團隊要不要設收益經理?要不要設品質管理經理、風險管理經理?
• 決定好角色後,再把這些角色分配到具體的人身上。
• 這樣建構出來的,是專案集的核心管理團隊。

講師原話:「要不要設定一個專案級的收益經理……這就叫識別角色,並把這些角色分配到具體的人身上去。」

PMI 術語: RAM ↔ 責任分配矩陣 / RACI ↔ RAM 的一種形式

§47 RAM 只分工到核心團隊;專案經理由章程任命 (01:54:34)

核心: RAM 是專案集經理給專案集核心團隊(core team)分工用的。專案經理不是透過 RAM 分派工作,而是由章程任命。

• 專案集核心團隊是專案集經理身邊的人:品質、風險、專案集 PMO 等。這些人都不是專案經理。
• 專案經理在再下一層,透過元件章程獲得任命與授權。
• RAM 也用來劃清專案集資源和專案資源的界線,專案資源在專案集之下。
• 這種分層也呼應前一天講的「分層」概念。

講師原話:「ram 是專案級經理給專案級核心團隊、core team 做分工的。」

🎯 考點: 選項說「用 RAM 給專案經理分配工作」是錯的。專案經理是透過元件授權(章程)任命的。

§48 分工本身就是治理:跨元件的事要升級上來 (01:56:02)

核心: 把責任按專案集與專案分層,並界定升級規則(什麼程度要升級),本身就是一種治理行為。

• 上層是專案集,下層是專案,兩者之間有灰色地帶,所以要界定界線劃在哪裡。
• 跨元件的事情必須升級到專案集。專案內部、未達一定嚴重程度的問題,在專案層面自行解決。
• 嚴重到什麼程度才升級,可以事先協商好。
• 也有一種簡單粗暴的做法:專案的事全部交給專案經理,一律不升級。這是專案集經理的權利,但不一定好,問題嚴重卻不升級,專案集就會失控。

講師原話:「跨元件的事情必須升上來,這就是一個治理機制。」

§49 大量資源應消耗在專案層面;專案集做的是協調 (01:57:32)

核心: 管理良好的專案集,大部分資源消耗在專案層面,而不是專案集層面。

• 講師問學員:標準上有一句話,資源應該主要消耗在哪個層面?
• 答案是專案層面。專案集層面本身是「空的」,真正的工作與收益都在專案層面完成。
• 專案集做的大多是協調(coordination)與管理類工作,目的是提升專案層面的效率。
• 這裡說的資源也包括人力。

講師原話:「不應該把大量資源消耗在我的專案級層面,因為專案級是空的,真正的工作是在專案層面完成的。」

🎯 考點: 問資源配置重心時選「元件/專案層面」。專案集層面主要負責協調。

§50 LC Task 5 用詞辨析:standard measurement criteria(標準化的測量指標) (01:59:24)

核心: 中文版把 criteria 和 standard 都翻成「標準」,講師把 criteria 改譯為「指標」來區分。standard 在這裡是形容詞,意思是「規範、統一、可衡量的」。

• 原文是 standard measurement criteria。criteria 是複數,單數是 criterion,指的是多個指標。
• standard 是形容詞,意思是「標準化的」:每個指標都要有統一、規範、可衡量的形式。
• 講師提醒:回去看講義時,會看到他把 criteria 譯成「指標」,而不是「標準」。

講師原話:「criteria 這個本身是個複數……standard 這是個形容詞,標準的、標準化的。」

PMI 術語: Criteria / Criterion ↔ 指標(複數/單數) / Standard (adj.) ↔ 標準化的

§51 啟動/規劃期就要定指標:指標是基準的一部分 (02:00:53)

核心: 在專案集啟動與規劃時就要確定測量指標。沒有指標,後面就無法評判、評估與監督執行情況。

• 指標通常是基準(baseline)的一部分。
• 有了基準,才能判斷進展是好是壞、是超前還是落後。

講師原話:「沒有指標你後面就沒有辦法評判,沒有辦法評估和監督你的執行到底做的怎麼樣,所以指標通常是基準的一部分。」

§52 Task 5 原文:constituent projects 等於 component;requirements & expectations (02:01:25)

核心: ECO 2024 寫的是 constituent projects(組成專案集的專案),意思就是元件(component)。任務內容是分析跨元件干係人的需求與期望,為所有元件定義成功指標。

• constitute 是「組成」的意思,constituent projects 就是 component。
• 2011 版只寫 project,容易誤解成任何專案,所以新版加了這個字。講師認為這個修改沒有特別意義。
• 原文的 requirements and expectations,分別對應需求與期望。
• 這個任務的意思是:專案集經理為下面的專案定義成功指標,也就是大家熟悉的 KPI。

講師原話:「constitute 是組成的部分的意思,這個詞往往經常叫 component。」

⚠ 新版變化: ECO 2024 用 constituent projects 取代 2011 版的 project,語意等同 component。

§53 誰幫誰定指標:一級給下一級定 (02:02:18)

核心: Task 5 是專案集經理為元件定 KPI,由 PMO/核心團隊協助,結果要向 sponsor 和指導委員會報告。專案集本身的成功標準(寫在章程裡)由 sponsor 或指導委員會訂定。

• 講師問學員:這個 task 是專案集為專案定 KPI,那誰來定衡量專案集成功的指標?答案是 sponsor 或專案集指導委員會,成功標準寫在章程中。
• 原則是高一級給下一級定指標,所以專案集經理給專案定指標是合理的。
• 協助專案集經理定指標的是 PMO 或核心團隊。
• 指導委員會也會參與:向下訂定的指標要報告給 sponsor 與指導委員會,讓他們確認方向和專案集一致。
• 層級越高的人,越關注與更上層目標的一致性。

講師原話:「就更高一級的給更下一級的設定指標,那專案級經理給專案經理設指標是不是非常合理?」

🎯 考點: 「專案集經理為元件定成功指標,誰協助?」選 PMO/核心團隊。「專案集的成功標準由誰定?」選 sponsor/指導委員會。

§54 專案集經理就是專案層面的 sponsor;指標用來監控 (02:05:48)

核心: 對元件來說,專案集經理就是專案層面的 sponsor。上一層同理,專案集的 sponsor 往往是專案組合經理,旁邊有專案組合 PMO 與核心團隊。

• 題目如果沒問「誰協助」,答案就是專案集經理自己定,因為他是專案層面的 sponsor。
• 上層 sponsor 也不是一個人做:要嘛由專案集經理擬好呈報批准,要嘛由他身邊的人馬(例如組織層 PMO)協助。
• 指標用途:監督與控制專案集內所有元件的成功情況,方向是向下。
• 分析跨元件干係人需求(核心團隊、關鍵客戶等)只是次要資訊,核心是「定指標,否則過程沒法管」。

講師原話:「program manager 就是專案層面的發起人。」

§55 LC Task 6 召開啟動會:讓組織熟悉專案集,提高支持機率 (02:07:07)

核心: 專案集啟動會(kick-off meeting)是一個公開事件,讓組織內其他相關的人熟悉這個專案集,藉此提高他們支持的機率。

• 啟動會與關鍵干係人一起召開。講師說啟動會有兩個作用,原文只提到其中一個:讓組織內其他人熟悉專案集。
• 原文用 familiarize,也就是讓人熟悉、了解。
• 西方的邏輯是:透過大張旗鼓、外顯的方式讓更多人了解專案集,支持率自然提高。
• 講師提到在華人文化裡,可能只找關鍵人小範圍開會,但考試要理解西方的邏輯。
• 公開前期準備的內容有利於爭取干係人「買帳」,尤其是原本就想幫忙的人。

講師原話:「這個任務大家要理解,它是召開會議,就把它變成了一個公開事件,讓更多組織內的其他干係人了解我的專案集。」

PMI 術語: Kick-off Meeting ↔ 啟動會 / Familiarize ↔ 使熟悉

§56 啟動到此結束;LC Task 7 詳細範圍說明書(範圍說明書三態) (02:09:10)

核心: Task 1–6 相當於啟動(構建),Task 7 進入規劃。範圍說明書有三個狀態:preliminary/high-level、scope statement、detailed。

• 2011 版考綱把生命週期分成五個子部分:啟動、規劃、執行、監控、收尾。
• 範圍說明書三態:① preliminary program scope statement(high-level);② 專案集範圍說明書(Task 2);③ 詳細範圍說明書(Task 7,detailed level scope)。
• 細化時要納入專案集願景、內外部目標等變數,細化到足以支撐詳細規劃的程度。
• 原文列出的那幾項不必花時間背,核心就是「範圍說明書要進一步細化」。
• 講師說這三者本質上是用詞層級的差別(high-level statement of work → scope statement → detailed),實務上的細節差異會更明顯。

講師原話:「細化到可以支撐我做詳細規劃的程度。」

⚠ 新版變化: 2011 版用五子域(啟動/規劃/執行/監控/收尾)切分;新版改用三階段(定義/交付/收尾),但講師仍用五子域幫助理解任務順序。

§57 LC Task 8 制定 PWBS:只到專案層,不介入專案內部 WBS (02:11:55)

核心: 有了詳細範圍說明書,就能制定專案集 WBS(PWBS)。它的第一層是 Program,第二層是各個 Project。專案內部的 WBS 留給專案經理。

• PWBS 在考試和複習材料裡經常出現。原文的意思是透過 PWBS 確定規劃,並分配專案集的任務與可交付物。
• 專案以下的 WBS 屬於專案層面,專案集經理不要介入,至少不要介入太多,空間留給專案經理。
• 專案的來源是收益分析。
• PWBS 是漸進明細的動態文件:現在只有一個架構,等交付階段各元件啟動、論證完成後還要更新。

講師原話:「那個是專案層面之內,專案集經理不要介入……空間留給專案經理就行了。」

PMI 術語: PWBS (Program WBS) ↔ 專案集工作分解結構

§58 LC Task 9 專案集管理計劃與進度表:roadmap 加 BRP 加工成 schedule (02:13:40)

核心: 有了 WBS,就開始建立專案集管理計劃(由多個子計劃構成)。專案集進度表則由路線圖、收益實現計劃(BRP)以及元件層的資訊加工而成。

• 專案集管理計劃由十幾個子計劃構成。講師說第四版是 13 個,第五版他沒數,數字不重要。
• 子計劃包括品質、進度、財務、干係人爭取等。進度管理計劃(schedule management plan)是其中之一。
• 收益實現計劃(benefit realization plan)聚焦收益,路線圖(roadmap)聚焦重大里程碑,兩者都屬高層面。
• 專案集進度表(schedule)聚焦專案集的活動:放入收益相關內容、重大里程碑活動,以及向下的工作安排,例如各專案進度表的最高層資訊。

講師原話:「benefit realization plan 聚焦在收益上,road map 聚焦在重大的里程碑上,而我們的專案級的 schedule 是關於專案級的活動。」

PMI 術語: Program Management Plan ↔ 專案集管理計劃 / Benefits Realization Plan ↔ 收益實現計劃 / Program Schedule ↔ 專案集進度表

§59 Task 9 解讀:管理計劃提供方法,進度表提供時間;計劃指導執行 (02:16:03)

核心: 管理計劃告訴你「怎麼做」,進度表告訴你「什麼時間做什麼、做哪個專案」。計劃用來指導執行,執行結果和計劃對比就能找出偏差。

• 原文舉了例子:整合元件(專案層)計劃,建立專案集計劃。
• 有了管理計劃和進度表,執行期才有依據。執行叫 execution。
• 計劃加進度表如果符合目標與高層要求,照著管就不會跑偏。

講師原話:「計劃是用來指導執行的……執行的情況和計劃的情況做對比,我們就可以識別出偏差了。」

§60 LC Task 10 最佳化專案集管理計劃 (02:18:17)

核心: 計劃不是一次就定型。執行中發現計劃不完整,或外部環境改變時,都要透過識別、審查、平衡資源需求來最佳化計劃。

• 需要調整的原因有兩種:計劃本身不完整、不嚴謹;或外部環境變了。
• 原文是 optimize program management plan。
• 目的是確保使用的是最優或當時最可行的計劃,提升效率,並讓專案集計劃與元件計劃之間最大程度協同。

講師原話:「確保我們用的計劃是最優的那個,或者當時最可行的那個。」

§61 LC Task 11 規劃期建立 PMIS:治理工具,答「統一」 (02:19:19)

核心: 規劃期一定要建立專案集管理資訊系統(PMIS)。它是治理工具,目的是讓所有資訊源頭統一。

• PMIS 讓資訊的收集、儲存、發布乃至銷毀,都用同一套體系,這對組織來說是治理行為。
• PMIS 不只是 IT、數位或 AI 系統,也包括資訊管理的規劃、政策、流程與制度。
• 它要根據治理框架選擇工具與流程,用來共享知識、管理智慧財產與文件。
• 資訊源頭一致、規則一致,協同效應才會更好,最終服務於收益實現。

講師原話:「思路是得統一,至於用什麼樣的,那大家協商去確定,考到這個點上就夠了。」

PMI 術語: PMIS ↔ 專案集管理資訊系統

🎯 考點: 「專案集下 5 個專案各用不同 PMIS,專案集經理該怎麼做?」答案是統一。不是指定 A 或 B,而是協商出一套統一的系統。

§62 LC Task 12 專案層未解決問題的升級機制 (02:21:45)

核心: 針對專案層面未解決的問題(project-level issues)建立監控與升級機制,確保專案層解決不了的問題能升級到專案集。

• 「未解決」可能是能力解決不了,也可能是超出權限。
• 原文的意思是建章立制,不只問題,風險也一樣。
• 行動路線要符合專案集的約束與目標,也就是遵循事先達成的共識。
• 專案層的問題同樣會影響專案集目標與收益的實現。

講師原話:「我們要針對專案層面的問題建立一個升級機制,確保專案層面解決不了的問題升級上來。」

§63 升級鏈一路到公司,問題總會被「關閉」 (02:23:02)

核心: 升級鏈依序是專案、專案集、sponsor/指導委員會、專案組合、公司。最後總會選一種方式關閉問題:處理掉、不管它,或承擔後果。

• 專案集層面的問題升級,屬於治理域的內容。
• 到了公司層面還解決不了,就到此為止,把問題或風險關閉。
• Task 12 的一句話理解:建立專案層向專案集層的升級機制,確保專案層未解決的問題不會懸空。

講師原話:「確保專案層面未解決的問題不會懸空。」

§64 LC Task 13 收益管理計劃:新版統一成一份,底下分三個子計劃 (02:24:18)

核心: 新版把收益實現、移交、維持統一到一份收益管理計劃(benefits management plan)之下,再細分為實現計劃(過程中用)、移交計劃(移交時用)、維持計劃(移交後用)。

• 下午開場時講師提到:總共 72 個 task,目前講了 25 個(講師口述)。
• 舊版的移交計劃、維持計劃各自獨立,沒有統一到收益管理計劃;這一版統一了。
• 收益管理計劃描述的是收益從識別、交付、移交到維持的整合過程。
• 所有和收益相關的計劃,統稱為收益管理計劃。

講師原話:「簡單理解就是所有跟收益有關的計劃都統稱為收益管理計劃。」

⚠ 新版變化: ECO 2024 把收益移交計劃與維持計劃統一收進「收益管理計劃」。

§65 Task 13 的 exit criteria:準出、准入是階段的右側與左側 (02:25:38)

核心: 退出標準(exit criteria)又稱出口標準、準出標準。從實現階段進入移交階段、從移交階段進入營運階段之前,都要驗證是否達到這個標準。

• 原文的意思是:透過定義退出標準來制定收益管理計劃。計劃裡不只有準出標準,也有准入標準。
• 專案集結束、要從專案集狀態轉入營運狀態時,也要有標準。
• 原文提到的 administrative(行政收尾)、commercial(商務)、contractual obligations(合約義務),講師說可以先不管。
• 准入是「達到什麼條件才讓你進來」,準出是「達到什麼條件才讓你走」。兩者是同一個關口的兩側(左側與右側)。

講師原話:「如果有多個階段的話,每個階段之前進入下一個階段,這個叫退出標準,也叫出口標準,也叫準出標準。」

PMI 術語: Exit Criteria ↔ 退出/出口/準出標準 / Entry Criteria ↔ 准入標準 / Administrative Closure ↔ 行政收尾 / Obligations ↔ 義務

§66 LC Task 14 KPI:五大績效域交叉重疊,所以任務看起來重複 (02:28:43)

核心: Task 14 和前面的指標任務看起來重複,原因是五大績效域彼此交叉。以生命週期為主線時,任何時刻都會牽涉戰略、收益、治理與干係人。

• 五大領域:戰略一致性(Strategic Alignment, SA)、生命週期(Program Life Cycle Management)、收益管理(Benefits Management)、治理(Governance)、干係人爭取(Stakeholder Engagement)。
• 例如 KPI 用來判斷是否滿足要求,本身就有治理的意涵。治理一定和合規、控制、決策、權力有關。
• 所以下午的內容會和上午有重疊。

講師原話:「如果我以生命週期為一條主線的話,任何一個時刻,我都會涉及到戰略一致性的概念、收益管理的概念、治理的概念和相關方爭取的概念。」

§67 Task 14 用分解/映射技術在規劃子階段制定 KPI (02:30:51)

核心: 在規劃子階段,用分解(decomposition)或映射(mapping)技術制定 KPI,供執行與監督階段使用。

• 原文告訴你方法:decomposition 或 mapping。
• KPI 用來衡量專案集是否達到預期的要求與品質,所以和品質體系、治理有關,涵蓋品質、問題、風險。
• 三階段是定義(definition)、交付(delivery)、收尾(closure/close-out)。
• 定義階段等於構建(formulation,又稱啟動)加規劃(planning,又稱準備 preparing)。KPI 在規劃子階段制定。
• 原文後半的 scope and quality management system 不是重點。重點是確定專案集的指標體系。

講師原話:「他在規劃階段要制定用於執行和監督階段的績效指標,這個績效指標如果沒有,你的執行怎麼樣是沒有辦法評判的。」

PMI 術語: Decomposition ↔ 分解 / Mapping ↔ 映射 / Formulation ↔ 構建 / Definition / Delivery / Closure ↔ 定義/交付/收尾

§68 分解 vs 映射:映射在分解之外多了「指向性」(以 BSC 為例) (02:33:32)

核心: 分解是把上一級 KPI 由大拆小;映射包含分解,再加上「指向性」,也就是把指標對應到特定類別。

• 指標(KPI)之上是目標(objective, O)。把目標拆成指標有兩種方法。
• 分解法:把大的拆成小的,把高層次分成低層次。
• 映射法:以平衡計分卡(BSC)為例,財務、客戶、流程、學習成長四個類別各自對應一系列指標。這段轉錄只辨識出財務、流程、個人成長三類。
• 講師說這部分知道就好,不用深究。

講師原話:「映射的概念……它包括了分解的概念在其中,另外增加了一個指向性。」

PMI 術語: BSC (Balanced Scorecard) ↔ 平衡計分卡 / Objective ↔ 目標

§69 LC Task 15 監控人力資源、合約激勵:incentive vs motivation (02:36:35)

核心: Task 15 跳到團隊管理:監控專案集與專案角色的人力資源,尋找提升團隊積極性的機會,並進行合約談判,以達成或超越收益目標。

• 講師認為這個 task「有點跳脫」,講的是團隊建設(team building)。
• 原文是 monitor human resources from program and project roles。講師認為這裡改成「規劃」比較貼切。
• 做法包括薪酬激勵體系、職涯發展計劃,讓成員覺得有前途、有回報。
• 用詞辨析:incentive 是外在激勵,例如獎金、榮譽;motivation 是激發內在動機。
• 目的落在達成或超越收益實現目標。

講師原話:「incentive 激勵,獎金屬於這一類……motivation 叫激發,激發你內在的動機。」

PMI 術語: Incentive ↔ (外在)激勵 / Motivation ↔ (內在)動機激發

§70 LC Task 16 進入交付:特許(charter)元件,給人、給權、給資源 (02:39:19)

核心: 從 Task 16 起進入交付階段。專案集透過指派專案經理、分配資源,特許並啟動元件來達成目標。沒有元件,專案集只是空殼。

• 專案集的收益,來自元件完成可交付物並整合後的結果。
• charter 當名詞是「章程」,當動詞是「特許、批准」;initiate 是「啟動」。
• 專案集如果只有人在上面指手畫腳、沒有專案執行,就什麼也做不成。
• 發起專案時要給人(專案經理)、給權(原文沒提)、給資源與資金(前面任務提過 financial)。

講師原話:「沒有專案的時候專案集就是空殼子。」

PMI 術語: Charter (v.) ↔ 特許/批准 / Initiate ↔ 啟動

§71 LC Task 17 部署治理框架:consistency(行為統一) vs alignment(目標對齊) (02:41:29)

核心: 這裡的「一致性」原文是 consistency,指專案集內部行為與規則從前到後統一。戰略域的 alignment 指目標上下對齊。兩者中文都譯成「一致性」,但意思不同。

• alignment 是目標層面的雙向對齊:戰略向下拆成目標,目標向上對齊戰略。
• consistency 講的是行為與規則的統一性:大家用相同的規矩、相同的工具、相同的流程。
• 原文說透過部署治理框架與 uniform standards 達成。這裡的 standard 是「規範」的意思,不是指標。
• 治理具有強制性,沒有強制性就不能叫治理。PMIS 等基礎設施也支撐這種一致性。
• 規則統一、行為統一、資訊源頭統一,專案集的決策才會更明智(informed decision)。

講師原話:「這個一致性指的是統一性,而前面講的那個一致性叫 alignment,是對齊的意思。」

PMI 術語: Consistency ↔ 一致性(行為/規則統一) / Alignment ↔ 對齊(目標方向一致) / Uniform Standards ↔ 統一規範

🎯 考點: 看到 alignment 就想「戰略與目標方向」;看到 consistency 就想「治理框架帶來的做法統一」。

§72 協同 + LC Task 18 建立溝通回饋機制,萃取經驗教訓 (02:44:52)

核心: 除了資訊統一、決策統一,還要溝通統一:建立溝通計劃、回饋計劃與報告流程(reporting process),捕捉整個專案集期間的經驗教訓。

• 這呼應前一天講的協同:專案組合、專案集、專案要步調一致、方法一致。
• 專案集底下有了元件,就成了一個大兵團,需要回饋渠道。
• 成功的叫經驗,失敗的叫教訓。都要回饋到專案集層面,讓團隊與組織學習,不再踩同樣的坑。
• 原文用 feedback,也就是閉環:凡事有交代,件件有著落。
• 這套機制不會自然形成,要由專案集經理主動建立。

講師原話:「建立一個反饋渠道,讓摔過的跟頭都不要再摔了。」

PMI 術語: Feedback ↔ 回饋 / Reporting Process ↔ 報告流程 / Lessons Learned ↔ 經驗教訓

§73 LC Task 19 領導人力資源職能:training → coaching → mentoring 遞進 (02:47:17)

核心: Task 19 把 Task 15 規劃好的激勵與發展落地,透過培訓、教練、輔導與認可來領導人力資源職能。這三個詞有遞進關係。

• Task 15 偏向規劃與方向,Task 19 是執行落地。原文的動詞是 implement and lead。
• training(培訓)是從 0 到 1,原本不會,學會了。
• coaching(教練)是從 1 到 10,原本會但做得不好,讓你做得更好。
• mentoring(輔導,mentor 是導師)處理的是心態:能力已具備,但覺得事情沒意義、身心疲憊。輔導解決的是個人狀態。
• 三者合起來,讓團隊技能更熟練、心態更好。

講師原話:「training 是從 0 到 1 的改變,coaching 是從 1 到 10 的提升……mentor 解決的是你的狀態,個人狀態不好的時候叫輔導。」

PMI 術語: Training / Coaching / Mentoring ↔ 培訓/教練/輔導

🎯 考點: 成員「不會」選 training;「會但做不好」選 coaching;「能力足但動力或心態低落」選 mentoring。

§74 認可(recognizing):提升歸屬感與投入,專案集經理是「非典型 HR」 (02:50:32)

核心: 認可(recognizing)是公開表揚或給予榮譽,能大幅激發內在動力,提升歸屬感與參與度。專案集經理要具備「非典型 HR」的素養。

• 講師舉例:有團隊帶頭人私下要求很嚴格,但在更高層領導面前大力誇獎自己的成員,這對成員很有價值。講師也說,平時就這樣做會更好。
• 規劃(Task 15)加上執行(培訓、教練、輔導、認可),就是在做人力資源管理。
• 專案集經理要做非典型財務人員的財務管理、非典型 HR 的人力資源管理:不必專業,但要有基本素養。
• 原文目的:improve team engagement and achieve commitment to the program goals。
• 帶團隊只施壓不夠,要想方設法激勵。

講師原話:「帶團隊的人是要想方設法激勵大家,只施加壓力是不夠的。」

PMI 術語: Recognition ↔ 認可 / Team Engagement ↔ 團隊投入

§75 LC Task 20 依專案管理計劃審查專案經理的績效 (02:53:21)

核心: 專案集經理靠督促專案經理來達成自己的目標。審查不能空口無憑,要拿專案原定的計劃來評判專案經理的表現。

• 原文用 review,涵蓋評判、檢查、稽核。
• 依據是原先制定的專案計劃。專案經理偏離時,就拿計劃指出差在哪裡。
• 目的是最大化專案經理對專案集目標的貢獻,而專案集目標由專案集經理承擔。
• 一句話:專案集經理盯著專案經理把活幹好,也就是靠別人來做自己的事。

講師原話:「我們審查專案經理,得拿專案計劃來看。」

§76 LC Task 21 執行專案集管理計劃並審計結果:指標來自目標,目標來自戰略 (02:55:43)

核心: 交付階段就是用規劃期定好的工具與計劃執行,並把產生的結果(results)拿來和專案集管理計劃(KPI)比對審計,確保專案集成果與組織戰略對齊、交付預期收益。

• 原文的層次感很強:先要有成果,成果要和戰略對齊,才談得上交付收益。
• 結果和計劃比對的動作,就是監督(monitor):比較實際與計劃的偏差。
• 講師問學員:指標從哪來?答案是專案集目標,而目標來自組織戰略,三者在同一條線上。
• 審計時要和 KPI 比。符合指標,就代表目標可能實現,也就代表與戰略對齊。成果再演化就是收益。
• 一句話:一邊做一邊看,照計劃執行,也照計劃審計和監督。

講師原話:「一個是按照計劃執行,一個是按照計劃審計……滿足了指標要求就帶來了戰略對齊的效果。」

§77 用詞辨析:audit 審過程、inspection 驗結果 (03:01:23)

核心: Task 21 只用 auditing,沒用 inspection。審計(audit)審的是過程是否合規;檢查(inspection)看的是結果是否符合要求。

• 講師丟問題給學員:為什麼這裡用 audit 而不用 inspect?有三位同學回應。學員的答案「都是由上到下、都看結果」沒錯,但沒說到關鍵差別。
• 過馬路的例子:闖紅燈也安全過了馬路,從結果(inspection)看沒問題;但從過程(audit)看,這是重大不合規。
• inspect 主要檢查結果符不符合要求,auditing 主要看過程做得符不符合要求。
• 講師說 PMP 課程就該教這個區別,很多人沒注意到。

講師原話:「審計審的是過程的合規性……inspect 主要檢查的是結果符不符合要求,auditing 主要看過程你做的符不符合要求。」

PMI 術語: Audit ↔ 審計(過程合規) / Inspection ↔ 檢查(結果符合度)

🎯 考點: 專案集層的動詞多半是 audit,對象是過程與對收益的貢獻。inspect 可交付物是專案層的事。

§78 專案集經理不插手可交付物:看過程績效、看對收益的貢獻度(coordination) (03:05:55)

核心: 專案集經理不干預專案可交付物的產生,那是專案經理的工作。他關注的是過程績效,以及可交付物對專案集收益的貢獻度。

• 回看 Task 20:原文是 review performance,不是 review project managers' results。performance 指的是過程表現。
• Task 21 的 auditing results,指的是「有沒有遵循要求」的過程結果,不是可交付物層面的結果。
• 專案集經理不是不關心可交付物,而是更關心可交付物對專案集收益的貢獻度。貢獻度往往是無形的。
• 專案集語境多半出現審計、績效、收益、價值,很少出現 deliverable;出現時也只是對專案經理說的。
• 對專案經理提要求時,要把收益要求轉成可交付物要求,因為專案經理擅長的是產出 deliverables。
• 專案集經理伸手太深進專案,重心就會偏離,專案經理也會無所適從。標準定義用的是 coordination,不是 management。

講師原話:「他更關心的是專案產生的可交付物,對我專案級的收益目標的貢獻度。」

PMI 術語: Coordination ↔ 協調(專案集管理定義用詞) / Deliverables ↔ 可交付物

🎯 考點: 選項如果是專案集經理直接介入、檢查某專案的可交付物細節,通常是錯的。正確方向是協調、整合可交付物、促進收益實現。

§79 審計依據:專案集管理計劃(含元件計劃的高層部分),也審計專案集團隊自己 (03:11:30)

核心: 審計依據是專案集管理計劃:十多個子計劃,加上元件計劃的高層部分(不是全部搬進來)。審計對象不只專案經理,也包括專案集管理團隊自己的跨專案工作。

• 子計劃包括範圍、進度、成本、品質、資源、溝通、風險、採購、資訊管理、變更管理等,講師說共 13 個。
• 元件(專案)計劃的整合不是全部照搬,只取重要部分,形成專案集層的基準。
• 審查專案經理:用專案集管理計劃的總體部分,加上專案自己的細節計劃。
• 審查專案集管理團隊:用專案集管理計劃中跨元件的品質、風險、溝通等計劃。因為跨專案協調做得怎樣,不能問專案經理。
• 最終目的是確保專案集成果(本質是收益)和戰略對齊。

講師原話:「專案級經理拿著專案級管理計劃加專案層面的計劃一起來審查專案經理。」

§80 LC Task 22 專案集績效報告 ≠ 各專案資料相加 (03:15:56)

核心: 專案集報告要整合專案層資料和專案集層資料,向上報告給 sponsor 與指導委員會。報告不等於各專案資料的加總,還要說明跨專案的共通、交叉、相互抵銷的部分。

• 向上報告時,不能只有專案集整體資料,也要包含每個專案的資料。這點經常考。
• 考試語境常把專案集和專案分成兩個層次。這呼應上午講的資源分隔:少量資源在專案集層,大量在專案層。
• 講師問學員:Program Performance Report 等於專案 A+B+C+D 的資料放在一起嗎?答案是錯的。
• 如果只是相加,那就叫 multiple projects 管理,不叫 program。有些東西一產生就在專案集總體層面。

講師原話:「所有專案的資料加在一起,不應該百分之百等於你專案級……如果都是單獨相加,那就不叫 program,那只能叫 multiple projects 管理。」

PMI 術語: Program Performance Report ↔ 專案集績效報告

🎯 考點: 專案集報告要兩者都有:各元件資料,加上專案集層的整合性資訊(交互作用、協同、抵銷)。

§81 LC Task 23 評估專案集狀態:和 22 是同一件事的不同角度 (03:19:57)

核心: Task 22 講把資料整合起來,Task 23 講這些資料代表的專案集狀態(status):拿資料和計劃比較來監控,並維持專案集資訊是最新的。

• 用詞提醒:「專案集整體」一定包括所有元件;單說「專案集」時要看上下文,可能專指上層部分。
• 專案集的狀態要把專案資料和專案集資料合在一起,才是完整的狀態報告。

講師原話:「一說專案級整體,這個特別強調,一定是包括所有的;一說專案級……它可能專指的是上面這個部分。」

§82 LC Task 24 批准元件收尾:指導委員會確認,前提是可交付物完成 (03:21:52)

核心: 專案集下的元件收尾必須經過批准,由指導委員會最終確認。批准的前提條件是可交付物完成,不是收益。

• 單一專案(PMP 語境)的關閉由發起人批准。在專案集背景下,元件收尾要由指導委員會確認。
• 專案經理不對收益負責,只對專案可交付物的完成負責。
• 原文寫的是確保範圍符合功能要求,講師說這個說法有點怪,不必管。
• 講師說 Task 24 考得很多:被誰批准、批准什麼、條件是什麼。

講師原話:「批准組件收尾的前提條件是可交付物,這個大家記住,這不是收益。」

🎯 考點: 元件收尾的判準是可交付物完成、移交達標,批准方是指導委員會。看到「收益實現後才能關閉元件」的選項要警覺。

§83 LC Task 25 分析偏差與趨勢:actual 和 forecast 對比計劃 (03:24:00)

核心: Task 25 回到專案集層面。狀態是客觀呈現;偏差是現在和計劃比;趨勢是根據歷次偏差預測未來。兩者的基礎都是把實際值(actual)和預測值(forecast)拿來和計劃值比較。

• 沒提到專案時,預設說的就是專案集層。
• 原文是 comparing actual and forecast to planned values,也就是比較過去、現在和未來。
• 基準就是計劃與指標。偏差是當下的,當下的狀態由過去的資料決定。
• 偏差有規律,才能預測趨勢;沒有規律就無法預測。
• 發現偏差就採取糾正措施,預見趨勢就能提前因應(這段逐字稿在這裡中斷)。

講師原話:「偏差是和計劃比較,趨勢是和過去的所有偏差比較,未來會怎麼樣。」

PMI 術語: Variance ↔ 偏差 / Trend ↔ 趨勢 / Actual / Forecast / Planned Values ↔ 實際值/預測值/計劃值

Part C (03:26:25 - 05:11:17) 綜述

本段是「新版串講 — ECO 2024 考綱逐條精讀」的後半,約 105 分鐘。前 30 分鐘把生命週期管理(Program Life Cycle Management,ECO 2024 權重 44%)剩下的 Task 25-35 講完:監控後用糾正措施更新計劃、program-level issues、以「有利於收益實現」為原則的變更、program 風險的定義(不影響收益就不是 program 風險、合規不是風險、機率 100% 是問題不是風險)、Risk/Issue/Change 三者互相轉化但「看題目用哪個詞就套哪套流程」、績效報告與狀態報告的區別、收尾(Closure = Transition + Close-out)必須經治理批准、後評審與經驗教訓的三層用途。接著投影 ECO 2024 對比 2011 版,說明 35 個生命週期 Task 可按「構建 1-6 / 規劃 7-15 / 執行 16-24 / 監控 25-30 / 收尾 31-35」理解。

之後依序精讀三個領域:收益管理(Benefits Management,11%)8 個 Task(收益管理計劃 = 實現 + 移交 + 維持,三大基準、Synergy 協同 vs 同步、Benefits Register vs Status Report vs Performance Report、移交計劃要接收方一起制定);干係人爭取(Stakeholder Engagement,16%)7 個 Task(名稱從 management 改為 engagement、Stakeholder Matrix = 登記冊、negotiate 宜譯「協商」、visibility、溝通渠道偏好、as necessary 納入風險計劃、foster 關係);治理(Governance,14%)11 個 Task(standards & structure、program structure vs program management structure、consistency vs alignment、階段關口 = 治理的「氣口」、governance authority/body、KPI 的五領域視角、PMIS、風險上呈治理委員會、escalation 到 proper level、經驗教訓庫、監督業務環境、整合管理計劃與運營對齊)。最後帶過核心知識技能與考試趨勢。(戰略一致性 15% 不在本段。)

最重要的判準:①program 層面的變更/風險一律以「收益實現」為判準;②Risk/Issue/Change 看題目關鍵字選對應流程;③收尾必先獲治理批准且元件先收尾;④團隊看 Benefits Register、外部干係人看 Status/Performance Report;⑤只要出現 escalation policies and procedures、phase gate、approval,就是治理題。

§84 LCM Task 25-26 監控後更新計劃、納入糾正措施 (03:26:25)

核心: 經批准的糾正措施(corrective action)就成為新計劃的一部分,必須執行;計劃更新後資源要重新配置。

• Task 23 看狀態、Task 25 看偏差與對未來的判斷,Task 26 自然接上:發現計劃不夠好或資訊過時,就用現況資訊「更新」program 管理計劃
• 偏差出現 → 糾正行為 → 把糾正措施寫進計劃,成為未來執行依據
• 糾正措施「只要被批准」,就是計劃的一步,必須執行
• 新計劃後資源有釋放也有佔用,要重新規劃,確保釋放出來的資源被有效使用
• Program 目標與收益幾乎可以劃等號:program 目標基本上以收益的形式呈現

PMI 術語: Corrective Action ↔ 糾正措施 / Program Management Plan ↔ 專案集管理計劃

§85 LCM Task 27 Program-level issues 專案集層級的問題 (03:28:16)

核心: 專案集也會「自己」產生問題,要在 program 層面以一系列行動處理,不用下放到專案。

• 專案層解決不了的問題會升級上來;典型是跨專案問題:跨專案的人力、財務、技術、進度問題
• 「透過識別和選擇符合範圍、約束和目標的行動路線」這段修飾語意義不大,重點是:program 層級的問題要管好
• 原文用詞 program level issues;行動路線(course of action)指在 program 層面開展的一系列行動,直接在 program 層處理掉

§86 不是跨專案的 program 問題與分界線 (03:29:53)

核心: 有些問題一產生就在 program 層面,不是從下面升級或跨專案而來;要分清問題歸屬。

• 例 1:program 層面的目標被改變,是由上而下影響,不叫「跨專案」而是 program 級
• 例 2:原定財務框架裡直接給 program 層用(不是給元件用)的一筆資金不到位
• 三種歸屬:專案層問題交專案經理;跨專案問題交 program 層;本質就是 program 層的問題,program 層自己處理
• 第四種:本屬專案層,但超過約定的門檻(program 與專案之間劃的分界線)時必須升級到 program 層處理;有些是事先約定,有些是性質決定

🎯 考點: 判斷問題由誰處理時,先看問題影響範圍與既定的升級門檻:只影響單一專案且未超門檻 → PM;跨專案或超門檻 → PgM。

§87 LCM Task 28 變更:以有利於收益實現為原則 (03:32:28)

核心: Program 層的變更不是「控制變更」,而是「基於收益」主動變更;影響評估後依治理框架層級獲得批准。

• 依變更管理計劃管理變更即可
• Program 層最簡單的變更是元件的增加、減少、叫停、終止
• 另一大類涉及 program 級的範圍、進度、成本,一樣走變更流程,但原則改變:要從有利於收益實現的角度處理
• 只要對收益有用,就要主動做變更,不再是被動控制
• 要做影響評估,再依治理框架(事先約定決策要走幾級)取得批准

🎯 考點: Program 範圍/進度/成本變更題 → 選「評估對收益的影響」並依治理框架送批的選項;不要選「為守住基準而拒絕變更」。

§88 Program 風險:不影響收益就不是 program 風險 (03:34:59)

核心: Program 風險一定是影響收益實現(即 program 目標)的不確定性;不影響收益的就不是你的 program 風險。

• 講師先拋問題:風險若不影響 program 收益要不要管?答案:它根本不算 program 風險
• 在 PMI 體系下,風險一定是影響目標的不確定事件,這種當然要管

§89 合規不是風險 (03:36:09)

核心: 合規(compliance)的規則都是事先明確的,本身是「必須做到的事」;只有「滿足合規的能力不足」才是風險。

• 在 PMI 體系中,合規首先不該當成風險看
• 規則全是確定的 → 沒有不確定性 → 不是風險
• 「可能做不到、不一定完全做到」這種描述,才算風險
• 這是理論層面的區分,現實中常混用

講師原話:「合規本身並不是風險,因為它全是確定的;我們在滿足合規的過程當中能力可能不足,才叫風險。」

PMI 術語: Risk ↔ 風險 / Compliance ↔ 合規

🎯 考點: 選項把「法規要求」當作風險登記處理 → 通常不對;合規要求應直接遵守/規劃落實。

§90 風險的要素是不確定性;100% 發生的叫問題 (03:37:53)

核心: 風險必有不確定性,最基本兩個維度是機率的不確定與影響的不確定;機率 100%、影響確定的事件是問題(issue)。

• 例:發生機率 100%、影響確定是 50 萬 → 不叫風險,叫問題
• 這是特例;現實中幾乎沒有 100% 的事,所以風險概念很廣
• 區分問題與風險時,就靠「有沒有不確定性」這一條

講師原話:「它肯定會發生,而且影響就是 50 萬,這種事情不叫風險……這種叫問題,因為它沒有不確定性。」

§91 Risk / Issue / Change 互相轉化,看題目用詞選流程 (03:39:29)

核心: 三者會互相轉化,但考試只看題目用的是哪個詞,就套那套管理流程選答案。

• 問題沒處理好會引發風險;風險要素確定後轉為問題;變化可能帶有風險或問題屬性,風險和問題也會帶來變更
• Risk:識別 → 定性/定量分析 → 應對規劃 → 實施應對 → 監督;PMBOK 第 6 版之前是 7 個風險過程,另有 3 步、5 步的版本來自《風險管理標準》(The Standard for Risk Management)與實踐指南
• Issue:識別問題 → 分析問題 → 解決問題
• Change:提出變更請求 → 分析影響 → 給出方案 → 審批(批准到哪個層級)→ 採取行動並更新計劃
• 風險依風險管理計劃、問題依問題管理計劃(沒有就依 program 管理計劃)、變更依變更管理計劃
• 不能把 change 寫成 CR:CR 是變更請求(Change Request)

講師原話:「他們之間雖然轉化很複雜,但你看題目當中給的是哪個詞,你就要選它對應的答案。」

🎯 考點: 題幹寫 risk → 選風險流程的下一步;寫 issue → 問題流程;寫 change → 變更流程。不要被「其實它已經轉化」的推理帶偏。

§92 LCM Task 31 績效報告 vs 狀態報告 (03:42:57)

核心: 績效報告是比較實際值與計劃值、含偏差與趨勢預測的高層次報告;狀態報告只陳述客觀數字。

• 「分析報告」這個詞有沒有都可以,重點是做報告
• 全是偏差 → 偏差報告;全是預測 → 預測報告;合起來的共名 = program 績效報告
• 狀態報告(status report)強調陳述客觀數字與資料;績效報告/績效分析報告層次較高,含過去偏差、當前狀態與未來預測
• 報告資料來自:基礎資料、對比分析、趨勢預測

PMI 術語: Performance Report ↔ 績效報告 / Status Report ↔ 狀態報告

§93 LCM Task 33 收尾須經治理框架批准 (03:44:32)

核心: Program 不能不了了之,收尾也要經治理批准後才能開始。

• 從績效報告開始其實就進入收尾階段;現實中叫結項報告,其中一部分就是整體結論性的績效分析報告
• 比喻:戰鬥結束,首長下令後才能打掃戰場;program 收尾同樣需批准
• 收尾內容 ECO 沒講、標準有提:行政收尾、採購收尾、風險收尾、財務收尾
• ECO 擔心的是 program 一結束團隊就解散;應有正式收尾動作
• 一說「治理」,就與批准和權力有關

講師原話:「專案集是不能夠不了了之的,得要進行收尾。」

🎯 考點: 收尾題的第一步通常是「取得治理機構/指導委員會的收尾批准」,不是直接解散團隊。

§94 Closure = Transition + Close-out (03:46:40)

核心: 收尾階段(closure)可理解為兩個子動作:移交(transition,交出去)與關閉(close-out,關門)。

• Closure 本意是「階段」,下分兩個子階段;新標準已不再這樣明說,但這樣理解更透徹
• Transition 強調交出去:從 program 交到接收方/運營
• Close-out 強調關門:交走之後回到 program 把該做的事做完
• 講師說教材譯成「收尾」不夠好,應譯為「移交和關閉」

PMI 術語: Program Closure ↔ 專案集收尾 / Transition ↔ 移交、過渡 / Close-out ↔ 關閉

§95 元件先收尾;持續活動移交給職能組織 (03:47:50)

核心: 要先經批准,且所有元件收尾完畢,才能啟動 program 層收尾;維持收益的責任交給接收方。

• 有些元件要到 program 收尾時才結束,也得分先後:元件先收尾,再 program 收尾
• 收尾內容:管理收尾(PMIS 資料)、文件歸檔、收集經驗教訓、把持續活動移交給職能組織
• 原文 ongoing operational sustainability、functional organization:實指運營部門,也稱收益接收方、預期受益方
• 交出去後,由接收方負責收益持續產生;program 團隊回來做文件與經驗教訓歸檔、未關閉的風險交給客戶、沒用完的錢交回投資組織

🎯 考點: 「所有元件都已關閉」+「獲得批准」是 program 收尾的前提。

§96 LCM Task 34 後評審會議 (03:50:10)

核心: 後評審(post-review / 後評估)透過展示 program 績效報告捕獲經驗教訓。

• ECO 說在收尾時完成;但國際標準與現行做法是 program 結束、收尾完才做
• 以會議形式,由 program 團隊彙報整體情況
• 經驗教訓來源:報告中記錄的(大部分)+ 會上參與方審查後提出的,原文動詞是「捕獲」(capture)
• 講師提到後評估是覆盤的一種形式;program 結束後的覆盤叫總體覆盤

§97 經驗教訓的三層用途 (03:51:52)

核心: 經驗教訓用途由低到高:歸檔入庫 → 供新 program 參考避免踩坑 → 永久提升組織能力。

• 第一層:歸檔到經驗教訓知識庫(這是動作)
• 第二層:給新來的 PgM 或新 program 使用,避免再摔跟頭、再踩坑
• 最高層:永久提升整個組織的能力,讓能力往更高水平躍遷
• 從 program 角度:不走彎路,組織能力也在做 program 的過程中提升

講師原話:「它最終是為了提升整個組織。」

🎯 考點: 問經驗教訓的「最終目的」→ 選「提升組織能力/組織改進」,層次高於「歸檔」或「供未來專案參考」。

§98 LCM Task 35 經驗教訓與最佳實踐入庫 (03:53:56)

核心: Task 35 是 Task 34 的升級:把經驗教訓與最佳實踐入庫,為組織帶來改進。

• 最佳實踐 = 做得好的經驗;教訓 = 做得不好的
• 用途:為未來新 program 提供參考,並帶來組織提升與改進
• 35 以 34 為前提;但後評審會只是捕獲經驗教訓的「一種場合」,過程中的大量總結才是完整來源

§99 ECO 2024 vs 2011 對照:35 個生命週期 Task 的五段結構 (03:55:12)

核心: 新考綱叫「生命週期管理」、舊考綱叫「生命週期」,都是 35 個 Task;新版不再分階段,但仍可按構建/規劃/執行/監控/收尾理解。

• Task 1-6:構建(program 不說啟動,說構建 formulation)
• Task 7-15:規劃
• Task 16-24:執行;例如 charter and initiate constituent components by assigning project managers。Program 的執行主要由元件承擔,program 層做跨專案協調
• Task 25-30:監控(從分析開始)
• Task 31-35:收尾
• 新舊版的變化不用管,2024 版是要馬上用的;真要研究,變化背後反映的是趨勢

⚠ 新版變化: 生命週期領域名稱由 Program Life Cycle 改為 Program Life Cycle Management,Task 不再按階段標示,但順序仍大致對應五段。

🎯 考點: 讀到某個 LCM Task 時,先依編號定位它屬於哪一段,更容易判斷題目情境的「當下階段」。

§100 BEN Task 1 收益管理計劃與測量指標;三大基準 (04:00:15)

核心: 收益管理是 program 管理最核心、最有代表性的部分;收益管理計劃 = 收益實現計劃 + 移交計劃 + 維持計劃,連同測量指標構成基準。

• 考綱前後有不一致:用「收益管理計劃」更好,因為先實現、再移交、再維持
• 測量標準 = 測量收益實現好壞的指標(metrics)
• 收益實現計劃 + 測量指標 = 基準
• Program 三大基準:①路線圖;②財務管理計劃(也稱財務框架);③收益管理計劃(含實現、移交、維持,重點在實現計劃)
• 所有基準都需要重要干係人批准,主要是發起人(sponsor)和指導委員會(steering committee)

PMI 術語: Benefits Management Plan ↔ 收益管理計劃 / Benefits Realization Plan ↔ 收益實現計劃 / Metrics ↔ 指標 / Roadmap ↔ 路線圖 / Financial Framework ↔ 財務框架

🎯 考點: Program 三大基準 = 路線圖 + 財務管理計劃(財務框架)+ 收益管理計劃;基準由 sponsor/指導委員會批准。

§101 BEN Task 2 識別並利用協同效應(Synergy) (04:03:25)

核心: Synergy 是「協同」不是嚴格的「同步」:各元件踩在同一節奏上即可;發現協同後要更新收益實現計劃並送干係人批准。

• 協同必涉及多個元素:program 與專案之間(上下)、元件與元件之間(下下)
• 同步在技術上指嚴格同時發生;協同像樂團演奏,鋼琴、小提琴、大提琴不必同時開始,有獨奏有合奏,只要在旋律節奏上就是協同
• 元件之間的協同透過上層協調,這叫 coordination
• 發現協同效應與效率後要充分利用,產生最大收益 → 更新收益實現計劃中的方法
• 收益管理計劃是基準文件,所以要告知干係人,而且要經他們批准;基準管理非常嚴格,它是大家共識的基礎

講師原話:「只要都在節奏上那就叫協同,跟同步還是有點區別的。」

PMI 術語: Synergy ↔ 協同效應 / Coordination ↔ 協調 / Efficiency ↔ 效率

§102 BEN Task 3 制定收益維持計劃 (04:05:56)

核心: 移交出去不代表不管:交給接收方時,要一併給一份如何讓收益持續產生的維持計劃(扶上馬再送一程)。

• 中間本應還有移交;維持計劃針對收益交給接收方之後
• 最晚在交付的同時,要給接收方「如何維持收益」的安排
• 流程、措施、指標、工具這些細項不用背
• PgM 既管過程中的實現,也管移交過程(要有移交計劃),還管移交後的維持

講師原話:「你不能說移交出去你就不管了,移交出去你還是要管的。」

PMI 術語: Benefits Sustainment Plan ↔ 收益維持計劃

§103 BEN Task 4 監控指標並採取措施 (04:07:30)

核心: 用收益實現計劃(放寬點說,收益管理計劃)中預設的指標監督,目的是發現偏差,偏差過大就糾正,確保收益如期實現。

• 指標在前面的計劃中已設定
• 監督 → 發現偏差 → 偏差過大採取糾正措施
• 過程中確保收益能如期實現

§104 BEN Task 5 驗證收尾、移交與整合(Integration) (04:08:11)

核心: 收尾時要驗證收益是否真的實現;原文把「維持」換成 integration,指 program 成果要融入接收方現有流程才能持續。

• 照理移交後應是接收方「維持」,但 ECO 換了詞叫 integration
• Transition = 移交/過渡;Integration = 把 program 需要的工作和接收方現有流程、做事方法融合在一起
• Program 成果是接收方原本沒有的,接收之後要調整業務流程與管理模式,才能維持 program 產生的收益
• 「整合」就是把新東西嵌入接收方的業務流程

講師原話:「專案集新的東西要揉到、融到、結合到或者嵌入到你現有的接收方的業務流程,才能夠保證專案集收益在你接手以後能夠繼續維持。」

PMI 術語: Transition ↔ 移交 / Integration ↔ 整合(融入運營)

⚠ 新版變化: ECO 2024 用 integration 描述移交後的收益融入,概念上對應舊說法的「維持」。

§105 BEN Task 6 Benefits Register 記錄 program 進展;三種報告分工 (04:10:29)

核心: Program 的進展就是收益的實現情況;團隊內看 Benefits Register,對外部干係人要另編 Status Report,要求更高就做 Performance Report。

• 原文 Maintain Benefits Register and Record Program Progress,講師強調這個詞組很重要
• Program 工作很多,但最核心是收益實現情況 = program 進展
• 團隊成員想了解進展 → 收益登記冊是最佳選擇,不需另編,大家都熟悉
• 給外部相關干係人 → 從登記冊提取資訊編成專門的狀態報告(status report)
• 不只呈現當前狀態,還要呈現偏差與趨勢 → 績效報告(performance report),層次最高
• 一叫「報告」,層面就比較高,不是一般人看的;status 是最基礎的報告
• 向干係人呈現報告要遵循溝通計劃(安排什麼時間、什麼形式、向什麼人呈現資訊)

講師原話:「選擇題大家要注意:Status 是最基礎的,但它也是報告;Performance Report 肯定是報告,但層面很高;團隊成員用 Benefits Register 就可以了。」

PMI 術語: Benefits Register ↔ 收益登記冊 / Status Report ↔ 狀態報告 / Performance Report ↔ 績效報告 / Communications Management Plan ↔ 溝通管理計劃

🎯 考點: 「團隊成員想看 program 進展」→ Benefits Register;「高層/外部干係人要看偏差與預測」→ Performance Report;「只要客觀現況」→ Status Report。

§106 BEN Task 7 因應不確定性分析並更新實現與維持計劃 (04:13:37)

核心: 執行過程中遇到干擾或障礙,收益實現計劃與維持計劃要被迫調整或用最優方法迭代;更新基準要與干係人溝通確認。

• 兩個計劃:收益實現計劃、收益維持計劃,加上移交(過渡)計劃,合稱收益管理計劃
• 調整的兩種情形:被迫改變;或發現更新、更優的方法而迭代
• 過程中可能需要糾正或預防,原文提到「以確定是否採取糾正措施」
• 改的是基準文件 → 要與干係人溝通與確認

§107 BEN Task 8 移交計劃:要和接收方一起制定 (04:14:51)

核心: 移交(過渡)計劃規劃從 program 手中交到運營手中;接收方(運營方)要參與共同制定,確保在對方那邊可行。

• 三計劃:benefits realization plan + 收益移交計劃(transition)+ benefits sustainment plan,合稱收益管理計劃;講師自寫的縮寫不是正式術語
• 移交計劃也叫過渡計劃,是交接時把事情安排妥當
• 不要關起門自己做完再交給對方;要接收方一起制定,確保時間點與工作安排對方能接受(例如不能挑對方最忙時移交)
• 移交做好,維持才可行;維持最好是「發揚光大」,至少要維持下去

講師原話:「應該是接收方,也叫運營方,與我們一起來制定這個移交計劃,保證我們制定的移交計劃在接收方那是可行的。」

🎯 考點: 移交計劃的正確做法 = 與運營/接收方共同制定;選「PgM 獨立完成後交給運營」是錯的。

§108 五個績效域並行,側重隨生命週期變化 (04:17:15)

核心: 以生命週期為軸,任何時點都要同時考慮戰略一致性、收益管理、干係人爭取、治理;但不同時期影響力有側重。

• 早期:戰略一致性作用最大(定方向);治理影響也大(早期大量決策評估);干係人很重要(早期決策由關鍵干係人做,其意願影響走向、期望與風險觀);收益管理作用稍弱
• 隨著進入規劃、執行,戰略一致性仍不可偏離,但其他領域作用上升
• 每個點都有四到五個方向;若講標準(5th),還多一個協作(collaboration)績效域
• 治理可寫作 Governance Management

⚠ 新版變化: 考綱(ECO 2024)是五個領域;標準第 5 版另有協作(collaboration)相關的績效域。

§109 收益識別最早出現在商業論證 (04:20:37)

核心: 在 program 生命週期內,收益識別最早出現在商業論證(business case);更早的組織戰略計劃與初始分析在生命週期之外。

• 收益管理領域的 Task 直接從計劃開始,識別其實在戰略一致性領域
• 收益登記冊最早的內容來自商業論證
• 生命週期之外更早有初始分析與評估、組織戰略計劃(strategic plan,是商業論證的輸入),主導者是 sponsor
• 商業論證 + 章程(charter)+ 路線圖都在這之後;章程之後才有 PgM
• 收益管理 Task 順序回顧:制定計劃(移交、維持前都要獲批)→ 過程中糾偏 → 收尾驗證收益 → 登記冊記錄過程 → 需要時更新計劃 → 制定移交計劃;記不住就按順序排

講師原話:「專案集生命週期當中第一份正式出現專案集需要交付的收益的檔案就叫商業論證。」

🎯 考點: 「收益最早在哪個文件被識別」→ 商業論證(生命週期內);組織戰略計劃是其輸入,屬生命週期外。

§110 STK 領域名稱:management → engagement (04:24:48)

核心: 考綱從 Stakeholder Management 改為 Stakeholder Engagement,與標準一致。

• 2011 到 2024 這 13 年間,標準早已改為 stakeholder engagement,考綱一直停留在 stakeholder management,現在終於跟上

⚠ 新版變化: ECO 2024 領域名稱 = Stakeholder Engagement(干係人爭取/參與)。

§111 STK Task 1 識別干係人:誰負責識別 (04:25:17)

核心: 識別可以很早就開始;program 啟動前主要是發起人,而更早還沒有發起人時由組織(如戰略管理部門)識別。

• 學員答「發起人」是很好的答案,但發起人不是唯一的
• 在組織戰略計劃的雛形階段甚至還沒有發起人,此時由發起組織負責
• 干係人包括發起人、指導委員會,以及比發起人更早了解此事的人
• 發起人、PgM 被任命後,組織把過去研討的參與者等資訊交給他們,記錄到登記冊

§112 Stakeholder Matrix = 干係人登記冊 (04:27:45)

核心: 原文 stakeholder matrix 本質上就是干係人登記冊(多行多列的表),記錄干係人對 program 的立場(期望、支持、反對等)。

• 考試要知道這個詞的意思:matrix 就是登記表
• 「立場」是很寬泛的詞:期望、支持、反對等資訊

PMI 術語: Stakeholder Matrix ↔ 干係人矩陣(= 干係人登記冊 Stakeholder Register)

§113 STK Task 2 分析干係人並制定參與計劃;engagement 的譯法 (04:28:42)

核心: 識別 → 分析 → 計劃 → 按計劃爭取;engagement 站在我方主動時譯「爭取」較準確,站在對方則是「參與」。

• 分析工具留意:曾參與相關工作者的個人經驗、訪談、透過已知干係人找出未知干係人、組織過程資產(OPA)
• 分析的結論是干係人參與計劃(也叫爭取計劃)
• 沒有干係人會自動自發積極參與,需要我們做大量工作:用利益、用 program 收益吸引,說明對他的好處,或降低他的抵制與負面情緒

講師原話:「engage 如果站在我們是主體,我們要主動地去爭取它,翻譯成爭取更能準確表達它的意思。」

PMI 術語: Stakeholder Engagement Plan ↔ 干係人參與(爭取)計劃 / Organizational Process Assets ↔ 組織過程資產

§114 權力利益方格 (04:30:46)

核心: 權力/利益方格是最經典的干係人分析工具。

• 雙高(高權力高利益)→ 重點管理
• 雙低 → 監督:他不找我我不找他,他想問時給資訊即可
• 另兩格(一高一低)前一天已講

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

§115 STK Task 3 溝通、談判、衝突解決;negotiate 宜譯「協商」 (04:31:39)

核心: 爭取干係人的三件套是溝通、談判、衝突解決;考綱只寫了 negotiate,所以考題最常見 negotiate。

• 考綱只出現 negotiate,所以考試經常出現它,較少出現 conflict management
• 講師認為 negotiate 譯「協商」更好:「談判」讓人想到桌前你來我往交換,這裡更多是溝通、協商
• 動作是溝通協商,方法在干係人參與(爭取)計劃裡;按計劃進行
• 例:知道某人重要,也知道他在 program 中能得到什麼收益 → 向他陳述收益以獲得支持

PMI 術語: Negotiate ↔ 協商(教材譯談判) / Conflict Management ↔ 衝突管理

§116 設定清晰期望與驗收標準:收益與干係人的交集在 KPI (04:33:14)

核心: 收益的驗收標準可與收益指標(KPI)是同一個東西;讓重要干係人參與制定 KPI,能大幅提高其對目標的認可。

• 收益領域以收益為主線,干係人領域以干係人為主線,最終交集都落在關鍵指標
• 收益指標要和重要干係人一起確定;他們參與或認可了,對目標的認同就大幅提升
• 多彙報、一起協商定下衡量收益的 KPI,他們就會贊同並擁護這些指標
• 這是爭取干係人參與 program 的重要手段

🎯 考點: 干係人對收益有分歧/支持度低 → 選「與干係人協商確定收益的驗收標準/KPI」。

§117 STK Task 4 維持 program 的可見性(Visibility) (04:34:39)

核心: 有計劃有手段但不讓人看到,別人就覺得不靠譜;保持可見性可以維持乃至增強干係人支持。

• 讓干係人能在平台等處看到 program 情況
• 報喜不報憂、故意隔離資訊,都不利於獲得支持
• 可見性也與治理有關:治理要求資料唯一、統一、可見、可傳遞

PMI 術語: Visibility ↔ 可見性

§118 STK Task 5 定義並維持溝通方式與渠道 (04:36:01)

核心: 不同干係人對溝通頻率與形式有不同偏好,要分別定義並維持,但前提是符合安全與合規。

• 頻率:按天、按月、按季
• 形式:郵件、列印放桌上、口頭彙報、個人社交軟體、公司平台等
• 前提是安全合規:不能把 program 核心資料放到社交媒體
• 與可見性相關聯,做好可讓支持持續

§119 STK Task 6 評估干係人識別的風險,必要時納入風險計劃 (04:37:36)

核心: 干係人(這裡通常指 program 團隊以外的人)識別出的收益相關風險要評估;原文 as necessary,代表重要的才納入 program 風險管理計劃。

• 收益達成過程會遇到不確定因素;若是干係人識別出來的,要給予高度重視
• 這裡的「干係人」通常指團隊外的人;廣義來說風險都是干係人識別的
• 原文 as necessary(必要時)耐人尋味:不必要的就不放進去
• 外部無關緊要者提的風險要先評估,重要、有必要的才納入,使其進入正式工作範疇

🎯 考點: 外部干係人提出風險 → 先評估,再決定是否納入風險管理計劃;不是直接全部加入,也不是忽略。

§120 STK Task 7 Foster 發展並培養干係人關係 (04:38:55)

核心: Foster 比「維護」層次更高,是把關係培養到穩固、長期、信任(甚至不迴避社會關係),以改善溝通、獲得支持。

• 原文用 foster(講師口誤念成 faster)= 培養,像長出根、枝繁葉茂
• 把干係人培養成鐵桿支持者
• 熟悉、信任、長期穩定的關係 → 溝通順暢,少波動
• 不迴避建立工作以外的社會關係,如成為朋友、社群互助

PMI 術語: Foster ↔ 培養 / Relationship ↔ 關係

§121 干係人 7 個 Task 回顧 (04:40:30)

核心: 識別(入登記冊)→ 分析(制定參與計劃)→ 按計劃爭取(溝通/談判/衝突解決)→ 可見性 → 溝通渠道 → 干係人識別的風險 → 培養關係。

• 看不到 program 的干係人(黑盒子)會選擇中立、遠離或疏遠
• 溝通偏好:語言、文字、書面、正式、非正式
• 識別出的風險必要時納入風險管理計劃,進入正式工作範疇
• 關係建好,支持大幅提升

§122 GOV Task 1 建立治理標準與結構 (04:42:44)

核心: 治理先要建立標準與結構;依據是行業最佳實踐(強監管行業需遵循外部要求)或組織自身標準。

• 組織常見要求:建 program 的前提是治理結構至少三層,例如指導委員會 + program 核心團隊 + 專案團隊
• 三層:決策層(戰略層)、管理層、執行層
• structure 可譯「架構」
• 標準包括用什麼工具、什麼財務要求、什麼彙報,都屬治理範圍

§123 Program structure vs Program management structure;reporting 譯「彙報」 (04:44:30)

核心: Program management structure 是「人」的管理架構;program structure 是 program 與其專案/元件之間的層級架構,兩者不同。

• Management structure = 管理結構,指人的架構
• Program structure = program 與專案之間的層級架構
• 治理簡單理解 = 權責分配 + 統一的彙報路徑
• Reporting 譯「彙報」比「報告」好:彙報體現上下級、內外、高低關係
• Standard = 規則、政策、制度;structure = 管理層級;有了它們才能安排分工、部署治理行為

PMI 術語: Program Structure ↔ 專案集結構 / Program Management Structure ↔ 專案集管理(人員)結構 / Reporting ↔ 彙報

🎯 考點: 題目問「誰向誰彙報、權責如何分配」→ program management structure;問「program 下有哪些元件、如何分層」→ program structure。

§124 Efficiency & Consistency vs Strategic Alignment (04:45:51)

核心: 治理追求的「一致性」是 consistency(前後一致、動作一致、要求一致),不同於戰略領域的 alignment(對齊)。

• 有了標準與結構,才能推動 program 下各專案的 efficiency 與 consistency
• 戰略一致性 = strategic alignment;規則/動作統一 = consistency
• 有了治理架構與規則,大家行動一致,program 目標更可期

PMI 術語: Consistency ↔ 一致性(統一) / Strategic Alignment ↔ 戰略一致性(對齊) / Efficiency ↔ 效率

§125 GOV Task 2 選擇治理框架:政策、程序、標準 (04:46:37)

核心: 在 PMI 標準中,治理框架由政策、程序、標準構成;program 治理必須符合組織的治理要求,program 不是獨立王國。

• 各公司可另放角色職責、戰略等,但 PMI 指的是政策 + 程序 + 標準
• Program 規劃、執行、收尾都要符合組織治理結構
• Program 之上要有來自各部門代表的決策委員會
• 記不住就記標題:選一個既符合 program 個性、又符合組織治理要求的架構

講師原話:「專案集再重要,它也不是個獨立王國,它需要有更高層面組織的參與。」

PMI 術語: Governance Framework ↔ 治理框架 / Policies, Procedures, Standards ↔ 政策、程序、標準

§126 GOV Task 3 階段關口:給組織治理留的「氣口」 (04:48:31)

核心: 階段關口(phase gate)是組織治理介入 program 的約定時點;在此做決策、監督、控制、彙報,這些詞都屬治理。

• 關口審查看績效;績效好也可能不往下走
• 像圍棋的「氣口」:你不給組織機會,它也會想辦法干預,不如事先約定何時干預,過程中不用管
• 關口要做決策、監督、控制、報告/彙報 → 誰看報告、誰做報告、誰監督、誰控制、誰決策,本身就是治理實踐
• 標準第 4 版有 12 個治理實踐,第 5 版有 10 個(只是合併),其中都有階段關口

⚠ 新版變化: 治理實踐由第 4 版 12 個合併為第 5 版 10 個,階段關口仍在其中。

§127 關口審查 → 獲得下一階段授權 (04:50:12)

核心: 關口把 program 截至當下的狀態呈給治理主體評審;同意即取得下一階段的授權(authorization)與批准,否則 program 到此為止。

• Authorization(授權)與 approval(批准)在此意思相近:不批准就沒有授權
• 要做好兩件事:設好關口,並把關口的事做到位
• 對 PgM 而言,program 的關口是自己被稽核的時點;專案的關口,PgM 則是審查人

🎯 考點: Program 關口 = PgM 被審;元件(專案)關口 = PgM 當審查者。

§128 Governance authority / body 與三層治理主體、審批權 (04:51:39)

核心: 治理機構泛指與治理相關的各層級;原文用 governance authority 強調經組織授權的權力本身,也有用 governance body(治理主體)。

• 三層:program 指導委員會(最高)→ program 管理核心團隊(core team,含 PMO)→ 專案經理及其團隊
• Authority 指整體,具體哪一層看上下文
• 增加或減少元件:最終審批權在指導委員會,PgM 沒有
• Program 層進度、範圍、成本等變更:指導委員會可授權 PgM 終審
• 專案內部的則由 PgM 與 PM 約定

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

🎯 考點: 增減元件 → 指導委員會核准;program 範圍/進度/成本的一般變更 → 可能已授權 PgM 決定,看題目給的授權。

§129 GOV Task 4 評估 KPI:同一個 KPI 在三個領域的角度 (04:53:26)

核心: KPI 在收益、干係人、生命週期、治理都出現,角度不同;站在治理角度,KPI 用來做判斷,判斷即決策。

• 收益管理:KPI 衡量收益完成情況
• 干係人:KPI 要與干係人溝通協商確認
• 生命週期:監督就是用計劃的指標看執行
• 治理:用 KPI 評估整個 program 狀態以做決策;此 Task 與生命週期某 Task 重疊

§130 用五個績效域(加協作)理解任一概念 (04:55:01)

核心: 任何 program 活動都可以從五個領域(SA、BM、SE、Governance、Life Cycle)分析,這是標準的貢獻;新版再加協作(collaboration)。

• 五領域:Strategic Alignment、Benefits Management、Stakeholder Engagement、Governance Management、Life Cycle Management
• 隨便拿一個活動都可以從五方面分析,只是側重不同
• KPI 與 collaboration:KPI 讓大家基於統一標準分工協作
• 越後面的 Task 越容易,因為情形前面都出現過了

§131 GOV Task 5 開發或利用 PMIS (04:57:21)

核心: PMIS 整合財務、採購、工作量、團隊合作、業務、法務等流程,讓資料收集分析與彙報更有效,增強一致性、支撐治理。

• 可結合數位轉型(digital transformation)與 AI 方法
• 有系統後資料收集更簡單、分析更有效率,結論與判斷更利於治理
• 原文可用 alignment 或 consistency:治理要解決的是大家遵循相同規則
• 向干係人溝通 program 資訊 = 彙報,彙報代表層級關係,與治理相關

PMI 術語: PMIS (Program Management Information System) ↔ 專案集管理資訊系統

§132 GOV Task 6 定期評估影響戰略目標的風險,呈治理委員會批准 (04:58:51)

核心: 新增或既有風險只要影響戰略目標(落到 program 即收益目標),就要更新風險管理計劃並呈治理委員會批准;只要涉及批准就跟治理有關。

• 原文:regularly evaluate new and existing risks that impact strategic objectives to present an updated risk management plan to the governance board for approval
• 治理實踐(舊版 12、新版 10)中,風險、問題、變更都是治理要特別關注的
• 問題何時升級、風險如何處理、變更在什麼情況下怎麼處理,都與治理緊密相關

🎯 考點: 影響戰略目標的風險 → 更新風險管理計劃 → 送治理委員會(governance board)批准。

§133 GOV Task 7 建立升級政策與程序,確保在恰當層級處理 (05:00:40)

核心: Risk、issue、change(以及品質、範圍等)都要有升級程序,確保需要決策時都有對應的授權主體;只要看到 escalation policies and procedures,就是治理。

• 不能出現沒人管、沒人決策的情形,保證 program 規範有序
• 原文 establish escalation policies and procedures to ensure risks are handled at a proper level;講師強調 handle 與 appropriate/proper
• 恰當層級:完全下放 → 出大事上面不知道;完全不下放 → 上面工作積壓、下面等待延誤決策
• 可能的選擇:問題、風險、變更的最終決策權不下放;進度、範圍等微觀變化大部分下放
• 標準不規定具體做法,只要求設定恰當,不能因決策緩慢或層級不合理降低效率

講師原話:「Establish escalation policies and procedures,這是個術語,只要出現這個術語,記住一定是和治理有關的。」

PMI 術語: Escalation ↔ 升級 / Policies and Procedures ↔ 政策與程序

§134 GOV Task 8 建立資訊資源庫(Repository) (05:02:56)

核心: 把過程中的經驗教訓、流程與文件收集保存成資訊庫,支持組織最佳實踐。

• 目的與前面相同:防止新 program 踩坑、提升組織能力

§135 GOV Task 9 識別並應用經驗教訓 (05:03:25)

核心: Task 8 是入庫,Task 9 是「用」:用過去的經驗於當前 program,同時識別本 program 的經驗,為組織未來工作提供幫助。

• 描述與生命週期收尾的 Task(34、35)很像,可對照看

§136 GOV Task 10 監督業務環境變化(monitor ≠ monitor and control) (05:04:14)

核心: 治理藉組織權力與分工監督外部業務環境變化,為 program 提供重要輸入;一致性不能只看內部,也要看外部。

• 原文 monitor:講師指出譯「監控」差一點,因為少了 control;加上 control(monitor and control)才是監控,這裡是觀察、監督
• 環境變化會使 program 的功能性需求改變(如需要更多人力、更多供應鏈投入),治理要配合或設計機制滿足
• 最終確保 program 始終與戰略目標一致

PMI 術語: Monitor ↔ 監督 / Monitor and Control ↔ 監控

§137 GOV Task 11 Program 整合管理計劃:與運營對齊 (05:05:39)

核心: 並沒有一份叫「整合管理計劃」的專門文件,它指 program 所有計劃融合、無衝突;並要與運營銜接(alignment),尤其維持計劃是為運營制定的。

• 整合後,program 內所有計劃要有一致性
• 移交(過渡)計劃與維持計劃都在 program 執行期間制定,但維持計劃是給運營用的,要考慮與接收方/運營方的連接統一 → alignment
• 這樣 program 執行與未來的移交、維持才不脫節;integration = 合在一起、銜接
• 大循環:戰略目標為 program 提供輸入 → program 執行 → 收益移交運營 → 運營讓收益最大化 → 回頭檢視戰略目標是否達成
• 講師說 72 個任務至此講完

PMI 術語: Program Integration Management Plan ↔ 專案集整合管理計劃 / Alignment ↔ 對齊

§138 ECO 列出的核心知識與技能 (05:08:07)

核心: 考綱列出的知識與技能不是課程重點,知道概念即可。

• 收益衡量與分析技術
• 變革管理:Kotter 八步法、Satir 變革曲線、ADKAR 模型
• 合同談判與管理(談判 = 用我能付出的換我想要的)
• 情商、衝突解決五策略
• 成本收益分析 CBA、NPV、ROI
• 領導力理論:Tuckman 團隊發展階段、情境領導、僕人式領導
• 技能:向高層彙報與演示、虛擬團隊管理、期望管理、分析與系統思維、資源管理、說服與影響力

§139 考試趨勢與學習建議 (05:10:05)

核心: 講師判斷:新考綱切換後,考題會轉向以考綱為主;2011 版內容仍要學,熟悉 2024 版有助更新知識。

• 不熟 2024 版其實不太影響考試,因為 2011 版也要學;學過 2011 版再看 2024 版很有幫助
• 講師判斷 6 月考試延續舊風格,之後(如 9 月)切換到新考綱,轉向以考綱為主的出題方式,趨勢會明顯
• 收尾建議:看課程、看書、練題

⚠ 新版變化: 本段錄於新考綱切換前(講師說「6 月考試」),Freddie 2026-11-02 考試應已適用 ECO 2024 新考綱。