Ch16 — 新版精講 生命週期子階段 整合管理與支援活動 (230 min)

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

產製方式: 章節切 3 段交給 3 個 agent 平行逐段精煉, 共 130 個 §N (Part A: §1-42, Part B: §43-76, Part C: §77-130).

Part A (00:00:08 - 01:19:19) 綜述

本段承接 Standard for Program Management 5th 第 3 章「專案集生命週期」(Program Life Cycle),從定義階段的專案集管理計劃如何指導元件計劃講起,接著完整走過交付階段(Program Delivery Phase)的三個子階段——元件授權與規劃、元件監督與整合、元件移交與收尾,再講收尾階段(Program Closure Phase)的六個動作與五個收尾活動,最後收束第 3 章六大績效域,並切入第 4 章「專案集管理活動」:整合管理 5 個核心活動(core activities)與定義/交付/收尾三階段的支援活動(supporting activities)。講課脈絡以「站在專案集經理(Program Manager)而非專案經理的位置」反覆提問,糾正學員把專案集活動理解成「管到元件內部」的偏差。

最重要的考點判準: 1. 規劃階段沒有元件啟動;元件在交付階段才一個一個被授權,授權條件早在規劃子階段寫進專案集治理計劃;每個元件授權前要再做一次商業論證(必要非充分條件)。 2. 授權前的「多階段工作」本質是收益規劃(收益識別、分析規劃、收益依賴地圖、路線圖),收益規劃 = 專案集的 architecture;元件數量 = structure。 3. 移交(業務)→收尾(管理);開始移交、移交完成、開始收尾、收尾完成都要依治理計劃批准;所有元件收尾後專案集才能啟動收尾,且須指導委員會正式批准。 4. 元件必須在專案集收尾前全部關閉,但收益不一定要全部實現——以 criteria 預先約定「預期收益」(expected/intended benefits)。 5. 第 4 章所有活動都是專案集整體層面、跨元件的管理,不嵌入元件內部(以財務管理為例)。

§1 專案集管理計劃指導元件計劃;PMBOK 8 計劃結構 3+3+1 (00:00:08)

核心: 專案層面的計劃是依據專案集層面已制定的總體計劃來制定的;規劃階段時元件計劃尚不存在。

• 舊 PMBOK 的專案計劃是十大知識領域(範圍、進度、品質、資源、溝通、風險、採購、干係人…)一一對應的子計劃。
• PMBOK 第 8 版改為「3+3+1」結構:治理(績效域)+ 範圍、進度、財務 + 資源、風險、干係人。
• 專案集規劃與元件層面的關係:專案集總體計劃 → 影響/指導元件各自計劃的制定。
• 規劃階段時元件連啟動都還沒啟動,所以還沒有專案計劃;此計劃目的是保證專案集的執行。

⚠ 新版變化: PMBOK 8 計劃結構已非十大知識領域,而是治理 + 3 + 3 的績效域結構。

§2 交付階段 = 專案集實現收益的階段,名稱去掉「收益」 (00:01:28)

核心: 專案集交付階段(Program Delivery Phase)是啟動元件、由元件產出成果、專案集整合成果以達成收益目標的階段。

• 第 3 版/第 4 版稱「專案集收益交付階段」(Program Benefits Delivery),5th 去掉「收益」二字。
• 講師認為去得好:交付重點是收益但不僅僅是收益,也避免和收益管理績效域過度重疊。
• 運作邏輯:啟動元件 → 元件完成可交付物/成果 → 專案集整合元件成果 → 達成專案集收益預期/目標。

PMI 術語: Program Delivery Phase ↔ 專案集交付階段 / Program Benefits Delivery ↔ 專案集收益交付(舊名)

⚠ 新版變化: 階段名由「Program Benefits Delivery」改為「Program Delivery」。

§3 交付階段專案集團隊做協調;計劃跨元件、過程非線性 (00:02:44)

核心: 交付階段專案集管理團隊主要做協調,所用的每一份計劃都是跨元件應用的,不針對某一個專案。

• 協調手段 = 專案集各項計劃 + 專案集團隊一起管。
• 流程:專案集管理計劃影響元件目標與計劃 → 元件產生預期結果 → 專案集整合 → 交付專案集收益與目標。
• 這個過程有大量迭代與交疊,是非線性關係。

§4 交付三子階段;專案集經理在做監督、整合、授權 (00:03:51)

核心: 交付階段才開始陸續出現元件的規劃、執行、關閉;專案集經理的角色是授權、監督、整合,並主導元件的移交與收尾。

• 三子階段:元件授權與規劃、元件監督與整合、元件移交與收尾。
• 專案集經理:監督 + 整合 + 授權;元件移交收尾的實際工作由專案經理做,但專案集經理要「主導/關注」。
• 理解定位:專案集是「高高在上」的,不下沉做專案的事。

§5 元件漸進浮現;專案集經理與專案經理協同 (00:04:40)

核心: 專案集具有顯著不確定性,規劃時不可能清楚全部元件,交付階段也不能一開始知道所有元件,元件是陸續一個一個發起的。

• 交付階段的資訊比規劃階段清楚很多,但仍是漸進明確的。
• 元件啟動 → 專案經理出現 → 專案集經理與專案經理配合,完成兩層級管理的協作協同。
• 專案經理負責以一致、協調的方式管理元件——「一致」是向上與專案集一致。

§6 交付階段的結束條件由專案集治理設定 (00:05:51)

核心: 交付階段何時算完成,由專案集治理層(governance)確定的條件決定;確定後才啟動專案集收尾階段。

• 關閉條件 = 結束條件(exit criteria)。
• 定條件的是治理主體,不是專案集經理自己。

PMI 術語: Exit Criteria ↔ 結束/關閉條件 / Program Governance ↔ 專案集治理

§7 元件授權與規劃:專案集經理是元件的發起人 (00:06:22)

核心: 元件授權由專案集經理主導,對元件而言專案集經理就是發起人;規劃則參與但不過度參與。

• 不是叫你「殺下去」替每個專案做規劃。
• 授權後專案啟動;專案集經理授權 → 監督其規劃(可參與)→ 規劃完成後大部分是專案經理的事:按期彙報、有問題升級。
• 下一子階段才變成「元件的監督與整合」。
• 特別強調:你現在的角色站在專案之外看元件。

🎯 考點: 題目問專案集經理在元件授權/規劃時該做什麼 → 選「依準則授權、監督/影響元件規劃」,不選「親自制定專案計劃」。

§8 授權準則:每個元件都要有商業論證(必要非充分) (00:07:44)

核心: 元件授權要依組織設定的準則(criteria);每個元件啟動前都要制定並通過自己的商業論證,商業論證是必要條件。

• criteria 可譯為準則或條件,達到才可以啟動。
• 沒同意商業論證之前,連啟動機會都沒有。
• 即使商業論證被批准,實務上也可能章程沒被批准而不啟動;但標準與考試中不太會出現「商業論證批准了卻不啟動」的情境。

PMI 術語: Authorization Criteria ↔ 授權準則 / Business Case ↔ 商業論證

🎯 考點: 元件啟動的前提一定是商業論證獲批;考試情境中商業論證通過 ≈ 進入章程授權。

§9 授權準則要事先寫進專案集治理計劃 (00:08:49)

核心: 授權準則與條件應在專案集規劃子階段就寫進專案集治理計劃,而不是元件要授權時才臨時決定。

• 專案集治理計劃(program governance plan)是專案集管理計劃的子計劃。
• 治理框架 = 治理計劃;條件不是專案集經理自己決定,而是與關鍵干係人確認。
• 在大家達成一致的計劃之下行使權力,專案集經理執行就「非常絲滑」。
• 治理計劃為元件授權提供明確流程指導與條件。

🎯 考點: 「元件授權該依據什麼?」→ 專案集治理計劃中預先約定的準則;「何時定?」→ 規劃子階段。

§10 授權前的「多個階段」是什麼?——收益規劃 (00:10:05)

核心: 授權前經過的多個階段,確保元件支持專案集成果並與組織戰略、日常營運一致;站在專案集經理角度,這些前置工作主要是收益的規劃。

• 講師提問,學員答案逐一排除:戰略計劃輸入、可行性調查(接近)、選專案經理(太晚,商業論證時還沒有專案經理)、治理框架(管理角度,非業務主線)、元件識別(不好)、路線圖(有點相關)、SWOT/專案集章程(更早,屬啟動/定義)。
• 正解:規劃階段的收益識別、收益分析與規劃、收益依賴關係地圖(benefits dependency map)、收益管理計劃、收益路線圖/專案集路線圖。
• 有了收益規劃,才清楚將啟動的元件對專案集收益目標的貢獻邏輯。

🎯 考點: 元件「為何值得啟動/如何支持專案集成果」的依據 → 回溯到收益規劃(收益依賴地圖、路線圖),而非 SWOT 或章程。

§11 臨啟動再做一次商業論證;architecture 與 structure (00:15:28)

核心: 交付階段啟動任一元件時都要再做一次商業論證,因為越接近啟動資訊越詳細;收益規劃是專案集的 architecture,元件組成是 structure。

• 規劃階段沒有元件啟動的根本邏輯在此,但準備工作(收益規劃)已充分鋪墊。
• 元件被批准/授權後,要把啟動時間點更新到路線圖;元件陸續授權後,路線圖就呈現整個專案集的結構。
• Structure = 專案集下有多少個專案;Architecture = 收益的邏輯。
• 能連起來就不會把交付階段理解偏——你在做專案集管理,不是專案管理。

PMI 術語: Program Architecture ↔ 專案集架構(收益邏輯)/ Program Structure ↔ 專案集結構(元件組成)/ Program Roadmap ↔ 專案集路線圖

🎯 考點: 元件被授權啟動 → 更新專案集路線圖。

§12 授權前活動與元件章程 (00:18:15)

核心: 授權前活動包括需求分析、可行性分析、元件論證、元件計劃;論證完成並批准後才有元件章程。

• 前面所有動作都在證明「將啟動的元件值得做」,管理層批准、給資源、授權 → 才到元件章程。
• 章程之前做的都是元件的商業論證。
• 授權:站在專案角度是「專案啟動」,站在專案集角度是「專案集給元件授權」。

§13 元件管理計劃要與專案集管理計劃對齊,不是全部塞進來 (00:18:56)

核心: 元件管理計劃要與專案集管理計劃對齊並驗證,只把主要結論放進專案集管理計劃的「目錄」,而非整份納入。

• 批准後專案經理帶團隊完成專案管理計劃;多個元件陸續進入規劃。
• 專案集管理計劃在元件啟動前已存在,但較寬泛、是框架,細節不多。
• 元件計劃要滿足專案集管理計劃的規定;整合 ≠ 把每份元件計劃都放進來(沒必要且不正確),因部分權限已分給專案經理。
• 專案集經理不參與專案細節,但要對元件「制定計劃」這個行為發揮影響力,否則執行會偏離。

🎯 考點: 元件計劃與專案集計劃的關係 = 對齊(alignment)+ 驗證 + 摘要整合;專案集經理在元件規劃時的重點是確保對齊。

§14 元件也要有移交/維持/運營計劃;移交的是可交付物 (00:21:31)

核心: 元件層面也要制定移交、維持、運營計劃,但元件移交的是可交付物而非收益;收益責任在專案集,不在專案經理。

• 專案集經理會對專案經理提出更高要求:不能只關注可交付物,還要一起關注收益情況,並提出可交付物未來如何應用與使用的想法。
• 但專案集整體收益的責任不在專案經理層面。
• 規劃層面先完成計劃的整合,執行時再做執行的整合(此時元件仍在啟動與規劃)。

🎯 考點: 元件(專案)經理對可交付物負責;專案集經理對收益負責。

§15 元件監督與整合:專案經理在執行,專案集整合輸出 (00:22:57)

核心: 「元件監督與整合」是專案集經理視角的命名;同一時期專案經理在依已對齊的專案管理計劃「執行並產生輸出」,輸出交給專案集整合。

• 三小節(講師口述 3.8.2.1~3)都是站在專案集經理角度命名的。
• 講師提問「站在專案經理角度這段在做什麼?」→ 「配合」方向對但不精準,正解是「執行」(且帶輸出)。
• 專案計劃先前已與專案集計劃對齊,專案目標經專案集經理批准(上一子階段)。
• 整合兩種形式:①A 專案結果給 B 專案(專案集經理干預 A 的產出時間與方式以配合 B);②元件輸出直接整合進專案集收益/成果。

§16 元件團隊回報狀態;專案集經理協調,甚至啟動新元件做整合 (00:26:20)

核心: 元件團隊向專案集經理提供狀態資訊,專案集經理協調各元件依核准計劃以一致方式執行;必要時可啟動一個新元件專門管理其他元件的整合工作。

• 專案集經理四項職責:協調各元件、確保依原核准計劃執行、協調元件間協作、處理衝突與配合關係。
• 可啟動新專案/任命一位專案經理替其做元件間日常管理與整合,類似「副的(Deputy) Program Manager」,但屬元件層級角色。
• 這句容易被忽略;目的在讓專案集整體收益最大化。
• 上報狀態:進度、成本、問題、風險、變更。

🎯 考點: 「專案集可以設立一個元件專門負責整合其他元件」是標準中的合法選項。

§17 專案集管理的核心價值 = 整合多個元件產出 (00:28:11)

核心: 專案集管理的核心價值在於整合多個元件的產出,實現單一元件無法獨立實現的收益。

• A 的產出對 B 有作用 → 協調 A、B 的時間節奏與達成結果。
• 整合每個元件對專案集的貢獻;有的直接服務整體目標,有的要過渡(A→B→C→再整合到專案集)。
• 不做整合,「要你(專案集經理)何用」。

講師原話:「核心價值就是要在於整合多個元件的產出……以實現單個元件無法獨立實現的收益。」

🎯 考點: 專案集存在的理由 = 元件整合所產生的綜效收益(synergy)。

§18 元件移交與收尾:移交偏業務、收尾偏管理 (00:29:15)

核心: 元件關閉分為移交(業務:交出真正價值)與收尾(管理:關閉內部事務);元件將可交付物移交給營運或接收職能。

• 接收職能常是專案集經理(即元件層面的發起人),在其監督下進入組織運維部門或直接交客戶。
• 舊 PMBOK 專案經理交了產品就不管;PMBOK 8 開始強調專案經理也要關心收益與價值,專案集管理早已有此思想。
• 確保元件在關閉所有活動前收益能得到實現;對專案經理而言是可交付物,專案集更關心收益是否實現。

⚠ 新版變化: PMBOK 8 強調專案經理也要關注收益與價值。

§19 移交與收尾每一步都要批准,並更新路線圖 (00:30:52)

核心: 元件開始移交、移交完成、開始收尾、收尾完成都要經批准,批准流程早已定在治理計劃中;元件收尾後更新路線圖。

• 未批准前元件不能開始移交;移交活動未被確認前移交不能結束;移交結束才進入收尾。
• 收尾多為管理動作:專案文件、資源、財務帳是否關閉。
• 路線圖在元件啟動與結束時都要更新(狀態與結束時間點)。
• 元件收尾批准通常由專案集治理主體或專案集經理依授權矩陣(授權分級分層)按流程批准。

🎯 考點: 元件收尾 → 依治理計劃取得批准 + 更新專案集路線圖。

§20 專案集收尾階段:所有元件收尾後,經指導委員會批准才啟動 (00:32:34)

核心: 先元件收尾,所有元件收尾完成後專案集收尾才可啟動;啟動專案集收尾要經專案集指導委員會正式批准。

• 發起人可在指導委員會批准前做 review,但最終批准由指導委員會。
• 設此階段的目的:讓收尾在受控範圍內,不能草草收尾、不了了之。

PMI 術語: Program Closure Phase ↔ 專案集收尾階段 / Program Steering Committee ↔ 專案集指導委員會

🎯 考點: 「元件尚未全部關閉卻想啟動專案集收尾」→ 不行;「誰批准專案集收尾」→ 指導委員會(治理主體)。

§21 收尾包含移交與維持;專案集移交 > 收益移交 (00:33:26)

核心: 收尾是大名詞,包含移交(transition,也譯過渡)與維持(sustainment);維持通常專指收益,移交則較寬。

• 移交不僅是收益(雖最重要),還包括文件、資源、責任等的移交。
• 單說「專案集移交」概念大於「收益移交」。
• 以受控方式正式關閉專案集;移交不成功,維持就無法成功(交出殘缺不全的東西,維持非常艱難)。

PMI 術語: Transition ↔ 移交/過渡 / Sustainment ↔ 維持

§22 收尾第一步:獲得批准;釋放與移交資源 (00:34:54)

核心: 專案集收尾的第一個動作一定是取得指導委員會正式批准;其餘動作並列無明顯先後,但都必須完成。

• 批准關閉 = 批准收尾。比喻:司令官沒下令,不能打掃戰場、不能撤離。
• 資源移交/釋放:資源回到來處,或移交給接收方(如部分團隊成員直接到運營方);也含設備、物資,人力資源最核心。
• 資源的重新分配不由當前專案集經理決定,而由資源管理方決定。

講師原話:「沒有這個命令之前,不準開始專案集收尾的活動。」

§23 移交責任(O&M)與移交風險管理責任 (00:36:35)

核心: 最主要的責任移交是收益實現與維持的責任,交給運營團隊;未關閉風險要連同風險管理責任移交給接收方,接收方不接受時由專案集所在組織的運營部門承接。

• 接收方可能是同組織、其他組織、其他專案/企業或客戶,但工作性質都變成例行化的運營(O&M = Operation + Maintenance)。
• 移交風險實為移交風險管理的責任;移交再完整也有不確定性,open 狀態的風險要交代清楚,影響也隨之轉移。
• 特殊情況:接收方只收收益、不收風險 → 專案集一方保留,因專案集要解散,交給所在組織的運營部門處置。

🎯 考點: 接收方拒收風險 → 不是專案集經理繼續扛,而是交由執行組織(專案集所屬組織)的運營部門。

§24 文件歸檔、最終報告;進入與結束收尾都要有條件 (00:38:59)

核心: 文件一部分移交接收方、一部分歸檔;要有專案集最終報告;進入收尾與確認收尾完成都需滿足條件並獲批准。

• 第六個動作:專案集最終報告(final program report)。
• 滿足特定標準,或決定終止專案集時,專案集才能啟動收尾。
• 收尾的開始與結束都叫「關閉」,都需批准。

PMI 術語: Final Program Report ↔ 專案集最終報告

🎯 考點: 專案集也可能因「決定終止」而進入收尾,同樣須批准。

§25 五個專案集收尾活動;財務收尾與採購收尾 (00:40:18)

核心: 專案集收尾活動的準確名稱:財務收尾、資訊歸檔與移交、採購收尾、資源移交、風險管理移交(講師稱共五個)。

• 「過程」在標準裡等同於「活動」;這些是專案集活動的準確名稱,第 4 章會再講。
• 財務收尾:結算所有財務義務,剩餘資金歸還資金來源組織,最終做財務審計與總體彙報。
• 採購收尾:完成所有採購合同收尾、處理未完事項、關閉與供應商的合同關係;盯著供應商完成其義務,我方義務自己完成,均有正式手續。
• 採購收尾與財務收尾緊密相關(先付清應付款)。

PMI 術語: Program Financial Closure ↔ 專案集財務收尾 / Program Information Archiving and Transition ↔ 資訊歸檔與移交 / Program Procurement Closure ↔ 採購收尾 / Program Resource Transition ↔ 資源移交 / Program Risk Management Transition ↔ 風險管理移交

🎯 考點: 收尾活動名稱要能辨識;剩餘資金 → 歸還資金來源。

§26 風險管理移交:剩餘風險、更新版風險登記冊 (00:41:58)

核心: 移交收益同時披露相關及未來可能發生的風險,接收方同意則接收;不同意則專案集與所在組織承擔風險管理責任。

• 移交內容:剩餘風險(residual risks)、更新版風險登記冊、風險管理歷史文件。
• 所在組織的風險登記冊也要更新,遇到的風險成為組織過程資產(OPA)。

§27 資訊歸檔與移交:經驗教訓轉為組織過程資產 (00:42:46)

核心: 專案集所有管理文件要歸集,一部分移交接收方,一部分交所在組織存檔(專案集解散後組織架構不在),並把經驗教訓沉澱為組織過程資產。

• 整理檔案還不夠,要更新組織知識庫。

🎯 考點: 收尾時經驗教訓 → 組織過程資產/知識庫,因專案集組織即將不存在。

§28 資源移交與向運營移交維持責任(業務主線) (00:43:46)

核心: 資源移交含團隊解散、人與物移交接收方、剩餘資源歸還或重新分配;而把收益的運營/維持責任移交給運營方,是收尾中唯一的業務主線,其餘都是管理主線。

• 接收方可能連人、方法論、工具都要,需在移交計劃中確定。
• 運營團隊接管專案集產出與收益,確保收益持續實現(內部或外部)。

講師原話:「這個其實是最本質……這是業務主線的。剩下大家看這些全部都是管理主線的。」

🎯 考點: 收尾最重要的是收益維持責任移交給運營;財務/採購/資訊/資源/風險屬管理收尾。

§29 生命週期與原則、績效域的互動 (00:45:16)

核心: 生命週期與所有原則、所有績效域都有關係,其中關聯度最高的三個原則是收益實現、協同(synergy)、治理。

• 收益實現:移交與接收都圍繞收益。
• 協同:接收方與我方同步、元件之間及元件與專案集的整合。
• 治理:由治理賦予權力,確保生命週期按節奏推進。
• 生命週期與其他五個績效域互動:每階段都有收益管理、協作、治理、干係人爭取(stakeholder engagement)、戰略對齊的動作;此部分不是重點,讀一下即可。

PMI 術語: Benefits Realization ↔ 收益實現 / Synergy ↔ 協同

§30 生命週期結構總結:定義 2、交付 3、收尾 1(實為 2) (00:47:03)

核心: 定義階段一分為二(商業論證+章程/專案集管理計劃),交付階段一分為三且交疊,收尾階段表面一個實際兩個(移交與關閉)。

• 定義:①專案集構建(商業論證、章程)②專案集規劃(專案集管理計劃)。
• 交付三子階段非順序而是交疊:元件授權與規劃、元件監督與整合、元件移交與收尾。
• 收尾:移交(transition,先移交收益)→ 專案集團隊做收尾(closure);但答題時視為一個階段。
• 生命週期是考試重點之一。

🎯 考點: 交付子階段是交疊(overlapping)而非線性;收尾答題時當一個階段。

§31 第 3 章收束:六大績效域 = 2 + 3 + 1 (00:48:12)

核心: 六大績效域是管好專案集的六個抓手:戰略對齊 + 收益管理為核心(2),治理、干係人爭取、生命週期(3),再加新增的協作(1)。

• 協作較抽象,指大家配合起來。
• 六個兩兩互動,任一個都與其他五個有互動。
• 戰略對齊是基礎、早期最重要(開始時要明確方向);收益是結束後體現的價值。「戰略提供方向,收益提供方法」。
• 治理提供權力分配、決策方法、管控層次與模式。

⚠ 新版變化: 5th 新增「協作」績效域。

§32 第 4 章結構:整合管理(核心活動)vs 支援活動 (00:50:40)

核心: 整合管理的 5 個活動稱為核心活動(core activities);定義、交付、收尾三階段所有活動合稱支援活動(supporting activities);兩者是指導(總分)關係而非包含關係。

• 第 4 章內容瑣碎,附錄另列各活動;結構有不一致處(有的階段列全部活動,有的只列核心活動),初讀不必糾結。
• 核心活動統領/指揮支援活動,支援活動反過來支撐核心活動完成。
• 「總分」不是總包括分,而是總指導分。
• 收尾活動 5 個;整合管理也 5 個。

PMI 術語: Core Activities ↔ 核心活動 / Supporting Activities ↔ 支援活動 / Program Integration Management ↔ 專案集整合管理

🎯 考點: 整合管理 = 核心活動;階段活動 = 支援活動;關係 = 指導而非包含。

§33 第 4 章所有活動都在專案集整體層面——以財務管理為例 (00:55:27)

核心: 第 4 章所有活動(整合 + 支援)都是在專案集整體層面、跨元件做管理,不嵌入專案集下的專案內部。

• 講師提問:「管理專案集財務」是管到每個元件,還是整體層面?→ 整體層面。
• PMBOK 8 也把「成本管理」改為「財務管理」:預算、成本管理、成本控制、財務核算。
• 專案集最終報告要彙總總支出、總收益。
• 專案財務由專案經理管(可設專案財務經理);專案集財務由專案集經理管(核心團隊可設專案集財務經理)。答「財務部」不好——那是職能部門,需符合其政策並與之(及客戶、監管方)打交道。
• PMO 有點像,但大部分時候 PMO 與財務管理關係不大。

講師原話:「管理專案集財務,只是在專案集整體層面,不嵌入到專案內部……它是在上面,橫劃在上面去做管理的。」

⚠ 新版變化: PMBOK 8 由「專案成本管理」改為「專案財務管理」。

🎯 考點: 選項若讓專案集經理直接管控元件內部預算細節 → 通常錯;專案集層面管理的是跨元件與整體的財務。

§34 專案集與專案的介面:灰色地帶要先界定 (01:00:48)

核心: 整合管理是「協調和管理各元件」,不是管到元件內部;專案集與專案之間有灰色地帶,需先界定權責,界定後不侵犯對方權利。

• 介面寬鬆 → 大部分交給專案經理;介面窄 → 專案集管得多。
• 該彙報升級的才升級,不該的就不必請示,否則效率低下。
• 以財務為例,但此框架適用所有領域。

🎯 考點: 專案集經理尊重授權邊界,不越權干預元件內部決策。

§35 整合管理的目標與關鍵決策 (01:02:20)

核心: 整合管理在資源、決策、變更上做元件間的協調、協作、協同;凡跨元件或在所有專案之外影響全局的工作,都屬專案集層面。

• 不是物理劃分:涉及兩三個專案之間的事,就是專案集層面工作。
• 工作具循環性(重複)與迭代性(每次有新內容)。
• 關鍵決策在整合管理完成:確定優先順序、風險升級、變更升級、資源配置、元件間依賴關係管理。

🎯 考點: 元件間資源衝突、依賴、優先順序、升級的風險/變更 → 專案集整合管理層面決策。

§36 整合管理五個核心活動 (01:04:29)

核心: 五個核心活動:①專案集基礎設施開發 ②專案集交付管理 ③專案集績效管理 ④收益管理 ⑤專案集變更(與維持規劃)活動。

• 「專案集交付」是階段名稱,「專案集交付管理」是活動名稱,要分清。
• 收益管理活動非常大,涵蓋內容多。
• 除整合活動外都叫支援活動。

PMI 術語: Program Infrastructure Development ↔ 專案集基礎設施開發 / Program Delivery Management ↔ 專案集交付管理 / Program Performance Management ↔ 專案集績效管理

🎯 考點: 看到「交付管理」= 活動;「交付階段」= 生命週期階段。

§37 專案集基礎設施開發:團隊、工具、治理結構、流程 (01:05:21)

核心: 基礎設施(infrastructure)是專案集經理管理專案集的一套手段,要自己搭建:團隊、工具(PMIS)、治理結構/治理計劃、管理流程。

• 解決專案集內部怎麼決策、誰負責、依什麼判斷、流程、工具、和誰一起做。
• 專案集核心團隊(program team)屬基礎設施;PMIS 平台(現已 AI 化)也是,「工欲善其事必先利其器」。
• 工具與團隊是最重要、最顯性化的部分。
• 5th 加入治理結構(決策體制、機制、層級)講師認為很好,因它不被工具/團隊涵蓋;流程多已電子化嵌入工具。
• 專案集經理可建立專案集內部的 PMO(不是組織的 PMO),也屬基礎設施。

⚠ 新版變化: 5th 把治理結構/治理計劃明確納入基礎設施。

🎯 考點: 專案集內部 PMO、PMIS、核心團隊、治理結構 → 都屬基礎設施開發。

§38 交付管理 vs 收益管理:元件必須關閉,收益不一定全實現 (01:07:55)

核心: 交付管理聚焦元件顆粒度,收益管理聚焦收益;元件必須在專案集收尾前全部關閉,但收益在專案集收尾前可以不完全實現,透過 criteria 預先約定「預期收益」。

• 交付管理與交付階段工作高度重合,差在一個是生命週期劃分、一個是具體活動。
• 交付管理與收益管理(識別、分析規劃、交付、移交收益)有大量交叉,需區分。
• 學員答「元件是交付收益的載體」沒錯,但要知道區別。
• 約定:哪些收益收尾前要實現、哪些收尾後多長時間實現、哪些過程中必須實現——統稱預期收益(expected / intended benefits),由專案集與接收方商定。

講師原話:「元件必須在專案集啟動收尾之前全部都要完成收尾……收益在專案集收尾之前可以不完全實現,也可以都要實現,所以它是不一定的。」

PMI 術語: Expected Benefits / Intended Benefits ↔ 預期收益

🎯 考點: 「專案集收尾時部分收益尚未實現」→ 若已在收尾準則中約定,可正常收尾並移交維持責任;但「元件尚未關閉」→ 不能啟動專案集收尾。

§39 交付管理是收益的必要非充分條件 (01:15:07)

核心: 交付管理是面向元件的活動(監督、整合、最佳化、管理),確保元件按計劃交付;元件按計劃交付是實現收益的必要非充分條件。

• 元件只對可交付物負責;可交付物背後與元件間的聯繫是專案集經理的責任。
• 不能對專案提出收益要求,除非該收益以可交付物形式存在於專案經理負責範圍內。

🎯 考點: 元件都準時交付 ≠ 收益已實現;收益整合責任在專案集經理。

§40 收益管理活動 ≈ 整個收益管理績效域 (01:16:01)

核心: 收益管理活動涵蓋收益管理全過程(識別、分析與規劃、交付≈實現、移交與維持),與收益管理績效域高度重疊。

• 講師認為命名不太好,但似無更好方法;第 4 版類似名稱「確保專案集收益的實現和維持」也不完整。
• 收益是整合管理層面最主要工作之一,但不只它:還有績效管理、元件層面的交付管理、前期基礎設施開發、後期變更與維持。

§41 專案集績效管理:計劃 vs 執行的偏差 (01:17:20)

核心: 績效管理框架本質上就是專案集管理計劃;執行中不斷以計劃測量執行、分析偏差並傳播績效資訊(報告、進展)。

• 用來追蹤專案集在達成目標路上經歷了什麼,在時間顆粒度上展示出來。
• 績效 = 計劃(plan/planning)與執行(execute/execution)對比的偏差(零、正、負)及其相對關係,即 performance(表現)。

PMI 術語: Performance ↔ 績效/表現 / Variance ↔ 偏差

§42 專案集變更與維持規劃(開頭) (01:19:15)

核心: 第五個核心活動為專案集變更(與維持)規劃,在戰略層面管理變更(本段僅開頭,內容續接 Part B)。

Part B (01:19:21 - 02:35:09) 綜述

本段從整合活動收尾(監控元件變更 vs 戰略層面變更、交付管理與基礎設施管理最常考)切入,接著建立「支援活動(Supporting Activities)」的總體架構:十個方面(範圍、進度、財務、質量、資源、溝通、風險、採購 + 變更、資訊管理),由整合活動(Core Activity)統籌。之後講師依生命週期逐段彙總:定義階段的「構建(Formulation)」子階段活動一律以「評估/估算」開頭,目的是產出商業論證與專案集章程以獲批准;「規劃(Planning)」子階段活動一律以「規劃」開頭,目的是產出專案集管理計劃(14 個子計劃);交付階段活動以「管理」開頭,是執行 + 監控的集合體。中段花大量篇幅釐清「目標(Objective)vs 基準(Baseline)」:構建談目標、規劃談基準,專案集成功以收益實現衡量,不以基線衡量。後段逐一講交付階段的支援活動:變更(元件增減、依收益貢獻而非績效)、溝通(含元件、最終服務決策)、財務(funding/現金流 vs 成本控制)、資訊(artifact)、採購(為所有元件定標準、集中採購)、質量(審計過程 vs 檢查可交付物)、資源(依優先級 + 依賴關係分配)。

最重要的判準:①專案集成功看收益/目標,不看基線績效;②構建=評估/估算→BC+章程,規劃=規劃→管理計劃;③交付階段的指導文件是專案集管理計劃,不是章程;④元件增減依「對收益的貢獻」而非績效;⑤移交計劃由移交方與接收方共同制定。

§43 整合活動收尾:兩層次的變更與五活動關係 (01:19:21)

核心: 專案集變更分兩層:執行中的元件變更請求,與戰略層面的外部宏觀大規模變化;變更讓整個管理形成閉環。

• 「監控專案集元件進展中的變更」= 過程中的 change request(與計劃不一致、受環境影響而不得不修改)
• 「在戰略層面管理變更」= 外部宏觀、大規模的變化
• 變更機制確保組織標準化的專案管理實踐與治理框架運作:提交 → 批准 → 執行,迴圈閉環
• 五個整合活動彼此相互關聯且互補

PMI 術語: Change Request ↔ 變更請求 / Component ↔ 元件

§44 最常考:基礎設施與交付管理;「交付」vs「交付管理」 (01:20:08)

核心: 五個整合活動中考最多的是「專案集基礎設施管理」與「專案集交付管理」;「專案集交付」是階段名,「專案集交付管理」才是活動。

• 專案集交付管理關注的是元件層面
• 單說「專案集交付(Program Delivery)」= 生命週期階段名稱
• 說「專案集交付管理(Program Delivery Management)」= 一個活動(activity)
• 題目看到這兩個詞要分清是在講階段還是活動

PMI 術語: Program Infrastructure Management ↔ 專案集基礎設施管理 / Program Delivery Management ↔ 專案集交付管理

🎯 考點: 基礎設施管理與交付管理是整合活動中出題最多的兩個;「交付」=階段、「交付管理」=活動。

§45 支援活動的十個方面與核心/支援關係 (01:20:47)

核心: 支援活動涵蓋十個方面(類似十大知識領域),由整合活動(核心活動)統籌。

• 十個方面:範圍、進度、財務(取代成本)、質量、資源、溝通、風險、採購 + 變更 + 資訊管理
• 相關方(干係人)不在其中:已升級為一個績效域(Stakeholder Engagement 屬 Performance Domain)
• 變更在原 PMBOK 體系不是知識領域;資訊管理原本與溝通放一起,專案集中獨立出來 → 十個中八個是熟悉的
• 講師表格中刻意不列整合活動與階段的對應,因標準書中五個整合活動與階段對應寫得較亂,建議單獨看
• 整合管理活動 = 核心活動(core activity);其餘 = 支援活動(supporting activity)

PMI 術語: Supporting Activities ↔ 支援活動 / Core Activity ↔ 核心活動 / Program Financial Management ↔ 專案集財務管理

⚠ 新版變化: 成本→財務;干係人不再是支援活動之一,已升級為績效域;變更與資訊管理獨立成支援活動領域。

§46 定義階段彙總:構建子階段做什麼 (01:23:01)

核心: 構建子階段產出兩個關鍵文件——商業論證與專案集章程;做高層級的範圍、風險、成本評估、戰略一致性與替代方案。

• 生命週期 + 活動相關題目考試佔比仍高(四成多),但活動多而分散
• 定義階段 = 構建(Formulation)+ 規劃(Planning)兩個子階段
• 構建重點(講師要求畫下來):高層級的範圍、風險、成本(舊版此處為資源)
• 考慮戰略一致性(strategic alignment),因要論證並確定章程
• 不確定性高 → 要有多種方案 = 替代方案(alternatives)
• 投影片用語「確定商業論證/制定詳細交付計劃」不夠規範,應理解為補充章程、細化管理計劃

PMI 術語: Program Formulation ↔ 專案集構建 / Program Business Case ↔ 專案集商業論證 / Program Charter ↔ 專案集章程 / Strategic Alignment ↔ 戰略一致性

🎯 考點: 構建子階段 = 高層級範圍/風險/成本 + 戰略一致性 + 替代方案 → 產出 BC 與章程。

§47 規劃子階段:組織結構與 14 個子計劃 (01:24:19)

核心: 規劃子階段建立專案集組織(團隊)與專案集管理計劃(含 14 個子計劃)。

• 「專案集組織結構」= 管理團隊(你的團隊)
• 「專案集結構」= 專案集下面的元件,兩者不要混淆
• 關鍵文件:專案集管理計劃 + 子計劃,共 14 個

PMI 術語: Program Organization ↔ 專案集組織 / Program Management Plan ↔ 專案集管理計劃

§48 專案集成功不以基線衡量 (01:24:47)

核心: 基線在規劃時建立,目標在構建時建立;專案集成功以目標(收益)衡量,不以基線衡量。

• 專案層面的基線 = 範圍、進度、成本基準(質量可算在內),由規劃產生的測量指標構成
• 專案集層面的基線概念正逐漸淡化
• 目標是構建時建立,在 BC / 章程中;基線是規劃時建立,在計劃層面
• 這個說法對專案也適用:專案目標在專案章程裡

PMI 術語: Baseline ↔ 基線/基準 / Objective ↔ 目標

🎯 考點: 判斷專案集成敗 → 看是否達成目標/收益,不是看有沒有照計劃、是否在基線內。

§49 目標管理 vs 指標管理;收益實現能力 (01:26:22)

核心: 基準管理是基於指標(績效)的管理,專案集成功是基於目標的管理;計劃執行再好,沒達到目標也不算成功。

• 傳統專案管理聚焦:有沒有超範圍、超進度、超成本
• PMBOK 第八版已改為關注價值,價值位置在 BC / 章程(目標層)
• 績效 = 計劃與執行的對比(基於基準);成功 = 是否達到目標
• 標準原文:專案集成功依組織從專案集成果中實現收益的能力來衡量
• 講師唸標準結論:「專案集管理計劃是參考性文件,應被設為受管理的基線」,並補一句「這個參考文件就是基線類的」——計劃當參考+受控基線用,但成功不以符合基線判定(講師說非本考試重點)。逐字稿前後文已核對,原話確為「應被」

⚠ 新版變化: PMBOK 8 把專案的成功觀點轉向價值,與專案集「以目標/收益衡量」一致。

§50 構建活動規律:評估/估算開頭、皆為 high level (01:28:38)

核心: 凡活動名稱以「評估」或「估算」開頭者,都屬構建子階段。

• 構建活動共十個,對應十個方面
• 可量化(成本、資源)用「估算(estimate)」;其餘用「評估(assessment)」
• 共性:大致、不夠準確,但沒有這個數就更無目的 → 全部是初始級別(high level)
• 不需要很多細緻工作,但要評估各方面會出現哪些現象/情況

PMI 術語: Assess ↔ 評估 / Estimate ↔ 估算

🎯 考點: 活動名「評估 XX / 估算 XX」→ 構建子階段;「規劃 XX」→ 規劃子階段;「管理 XX」→ 交付階段。

§51 提問:十個評估/估算活動是為了什麼 (01:30:06)

核心: 十個構建活動都是為了產出商業論證與專案集章程,而這兩文件是為了獲得專案集批准。

• 學員答「識別元件」→ 不夠準,元件還太早
• 答「獲得專案集批准」→ 對,但不夠具象
• 答「支援核心活動」→ 方向也對
• 最具體的答案:評估結果、方法、假設條件支撐 BC 與章程的生成 → 用以獲得批准
• 學員答 baseline → 錯

§52 Baseline vs Objective:OKR 比喻 (01:32:12)

核心: 構建階段談目標(O),規劃階段談基準(KR/KPI);目標對應結果,指標對應過程(績效)。

• 基準 = 指標 + 計劃,KPI 在基準這一層
• OKR 比喻:O = 目標(構建);KR = 指標/基準(規劃)
• 目標 ↔ 結果:說的是開頭與結束,不太關心過程
• 指標 ↔ 過程:過程做得如何 = performance(績效)
• 實務常混用,但 PMI 體系中「目標/結果」與「指標/過程/績效」是不同概念

講師原話:「構建階段談的是目標,規劃階段談的才是基準。」

PMI 術語: Performance ↔ 績效 / Outcome ↔ 結果 / KPI ↔ 關鍵績效指標

🎯 考點: 選項把章程/BC 稱為 baseline → 錯;baseline 屬規劃產出的管理計劃層。

§53 構建活動確定的是目標;支援 → 核心 → 兩文件 (01:34:27)

核心: 十個構建活動確定專案集目標而非基準;BC 與章程不叫基準文件。

• 專案層面的範圍/進度/成本基準用於過程管理;專案目標在專案章程裡——PMI 所有文件都是此規律
• 評估動作 + 結論 → 支撐 BC 與章程,否則兩文件不靠譜
• 支援活動支撐核心活動,核心活動統籌支援活動,最終產出兩文件
• 講師表中整合活動留空:構建階段的整合活動在第三版曾有名稱,現已無

⚠ 新版變化: 構建階段原本(第三版)有對應的整合活動名稱,現已取消。

§54 構建流程:戰略計劃 → 估算 → BC/章程 → 治理批准 (01:36:03)

核心: 組織戰略計劃提供原始輸入,初步評估/估算支撐 BC 與章程,交治理層批准;BC 在前、章程在後。

• 戰略指導 = 組織戰略計劃
• BC + 章程交給治理層批准 → 通過才下達章程、啟動專案集
• BC 沒通過 → 專案集根本不會被啟動

🎯 考點: 順序 = 戰略計劃 → BC → 章程;BC 未獲批則不會有章程。

§55 規劃活動:目的是專案集管理計劃 (01:36:45)

核心: 規劃開頭的十個活動都屬規劃子階段,為建立基線相關文件,最終都體現在專案集管理計劃上。

• 名稱以「規劃」開頭即屬規劃子階段,不用質疑
• 目的:為了基線——更完整說,是基線相關文件與建立基線的所有活動
• 學員答「章程」→ 錯,章程是上一階段產出,且章程不叫基線也不叫基準
• 所有規劃努力 → 生成專案集管理計劃

講師原話:「所有這些努力,都是為了生成專案集管理計劃。」

§56 構建活動一對一對應規劃活動 (01:38:33)

核心: 每個規劃活動前面都有一個對應的評估/估算活動,前者是後者的輸入;所有評估/估算活動的輸入是戰略計劃 + 環境評估。

• 例:規劃專案集財務管理(含成本估算、財務框架)← 估算專案集初始成本
• 規劃溝通管理 ← 評估溝通管理;規劃變更管理 ← 評估變更管理;規劃採購管理 ← 評估採購管理
• 所有評估/估算的輸入:組織戰略計劃 + 對外部環境的了解(戰略一致性中的環境評估)

PMI 術語: Environmental Assessment ↔ 環境評估

§57 14 個子計劃與專案集組織 (01:40:10)

核心: 十個規劃活動產出 10 個子計劃,另 4 個為路線圖、干係人參與計劃、收益管理計劃、治理計劃,合計 14 個。

• 規劃階段要定義專案集組織 = 核心團隊 = 也稱專案集基礎設施
• 專案集管理計劃來自三個文件:戰略計劃、BC、章程(BC 與章程最明顯)
• 講師觀點:戰略計劃應先輸入 BC 與章程,再由兩者輸入管理計劃,較合邏輯
• 規劃財務管理(含三個合併內容)是重點,之後單獨講

PMI 術語: Program Roadmap ↔ 專案集路線圖 / Stakeholder Engagement Plan ↔ 干係人參與計劃 / Benefits Management Plan ↔ 收益管理計劃 / Governance Plan ↔ 治理計劃

🎯 考點: 14 子計劃 = 10 個支援領域子計劃 + 路線圖 + 干係人參與 + 收益管理 + 治理。

§58 規劃圖解讀:核心統領、雙向迭代 (01:41:28)

核心: 在專案集整合(核心)活動統領下開展規劃,規劃比估算更細;雙向箭頭表示計劃制定反覆迭代。

• 所有規劃活動以章程與 BC 為輸入
• 每個規劃活動另有一個前序評估/估算活動提供初始估算(如評估採購管理 → 規劃採購管理)
• 「專案集構建評估與估算」斷句:構建 = 子階段;評估/估算 = 該階段活動名稱特點
• 此圖為幫助理解,講師明說不會考

§59 交付階段:管理開頭 = 執行 + 監控 (01:44:09)

核心: 交付階段活動以「管理」開頭,以執行為主、內含監控,是執行 + 監控的集合體。

• 管理專案集變更、管理專案集資訊…皆以「管理」開頭
• 質量例外:叫「保證和控制專案集質量」,因質量領域體系成型比專案管理早,保留原用詞;理解為管理質量也可,但別只理解為質量保證
• 三大階段:定義(對應專案的啟動 I + 規劃 P)、交付(執行 E + 監控 C)、收尾
• 名稱雖叫 management,實際包含 monitor and control

PMI 術語: Program Delivery ↔ 專案集交付 / Monitoring and Controlling ↔ 監控

§60 交付階段的指導文件是管理計劃,不是章程 (01:46:24)

核心: 「提供專案集指導」指的是專案集管理計劃;章程只確定目標,指導規劃,不能指導執行。

• 交付階段定義:協調和管理專案集實際交付所需的支援活動與流程(十個方面)
• 學員答「章程」→ 不準
• 專案、專案集、專案組合章程皆同理:章程確定目標 → 指導規劃 → 規劃產出管理計劃 → 管理計劃指導執行
• 中間透過整合活動統籌

講師原話:「章程只是確定目標的,目標沒有辦法來指導我們過程的執行和管理。」

🎯 考點: 交付階段指導執行的文件 = 專案集管理計劃(上一階段產出),選章程是陷阱。

§61 交付階段的核心活動:專案集交付管理 (01:48:58)

核心: 交付階段唯一的核心(整合)活動是專案集交付管理,整合財務、溝通等各支援活動使其步調一致。

• 想像完整建制:團隊中有人管變更、溝通、採購,專案集經理執行交付管理來整合這些人的工作
• 現實不會有這麼完整建制,但用來理解知識有效
• 支援活動全部由專案集核心團隊執行(包括 PMO)

PMI 術語: PMO ↔ 專案集管理辦公室 / Program Core Team ↔ 專案集核心團隊

§62 專案集財務經理管哪一層?灰色地帶與授權 (01:51:29)

核心: 專案集核心團隊的角色管的是專案集整體層面,與元件層面角色之間有可界定的分工介面,不插手細節。

• 學到這裡常誤以為是在管元件;實際管的是專案集整體層
• 專案集與專案之間有灰色地帶,依具體專案集決定誰管
• 例:專案集進度經理授權度高 → 只管元件開始/完成時間;授權度低 → 連中間里程碑都管
• 介面可向下移,但原則上不允許管到特別細的層面
• 講師說此圖不會考,但對理解標準體系很有價值

講師原話:「專案集經理不要插手專案層面太多。」

§63 第四章結構:三個交付整合活動 + 支援活動 (01:54:25)

核心: 交付階段先講整合活動(管理專案集交付、管理專案集績效、維持收益與移交),再講支援活動,從管理專案集變更開始。

• 第四章結構不完整:有的階段每個活動都講,有的只有框架
• 三個整合活動中最重要的是第一個:專案集交付管理(4.4.1)

§64 管理專案集交付:元件啟動批准與優先級重排 (01:55:34)

核心: 交付管理重點是元件的啟動與收尾;新元件須經專案集指導委員會依規則批准,進來後要重新劃定所有元件優先級。

• 移交 + 收尾合稱元件收尾(component closure)
• 專案經理提出新元件請求 → 向專案集指導委員會申請;委員會依組織/治理規則批准,不是隨意
• 若已有 4 個元件在執行,第 5 個進來 → 優先級需重排,可能後來居上排第一,也可能卡在中間
• 原因:專案集資源不充沛,新元件可能影響其他元件 → 確保資源不夠時調配原則明確
• 元件增減屬變更管理;完成使命的元件 → 移交 → 收尾

講師原話:「新啟動的元件會影響其他的四個,所以要重新劃定優先級。」

PMI 術語: Program Steering Committee ↔ 專案集指導委員會 / Component Authorization ↔ 元件授權 / Component Transition and Closure ↔ 元件移交與收尾

🎯 考點: 新元件獲批加入 → 立即重評所有元件優先級(資源調配原則)。

§65 管理專案集績效:基於基準、框架在規劃時定 (01:58:49)

核心: 專案集績效 = 執行與管理計劃(基準)的偏差,不是基於目標、章程或 BC;績效框架與 KPI 在規劃時確定。

• 觀察、對比、測量、分析計劃 vs 實際,再傳播資訊給該給的人,支持資料驅動的治理
• 績效:超前、落後或剛好——都是相對於管理計劃
• 「確定 KPI / 設計績效框架」其實是規劃階段完成的
• 傳播需定好方式、內容、時間、頻率、對象;設定 KPI 閾值與預警機制
• 要素:進度、成本、質量、收益實現情況

PMI 術語: Performance Measurement Baseline ↔ 績效測量基準 / Threshold ↔ 閾值

🎯 考點: 看到「專案集績效」→ 對照管理計劃/基準;看到「專案集成功」→ 對照目標/收益。

§66 維持收益與移交專案集:移交計劃雙方共同制定 (02:00:59)

核心: 在專案集層面面向元件管理收益維持與移交;移交計劃要由移交方與接收方團隊一起制定。

• 有些元件在交付階段就已產生收益、甚至完成移交
• 收益與溝通是兩個需「由下往上」收集的特殊領域
• 包括將收益管理職責移交給運營或其他實體;移交成功才有可能維持好收益
• 移交計劃:時間點、內容;移交資產、知識、責任,最主要是收益
• 重要三點:①完整文件 ②接收方團隊參與共同制定計劃 ③培訓——手把手把 A 會的教給 B
• 接收方可能不想參與,但仍盡量拉進來,真正交接後才能做好

講師原話:「在制定移交計劃的時候,是 A 方加 B 方一起來制定這個移交計劃。」

PMI 術語: Benefits Sustainment ↔ 收益維持 / Program Transition ↔ 專案集移交 / Transition Plan ↔ 移交計劃

🎯 考點: 移交題 → 選「接收方(運營)團隊與專案集團隊共同制定移交計劃」+ 文件 + 培訓。

§67 管理專案集變更:元件增減,依收益貢獻而非績效 (02:05:06)

核心: 專案集層的變更主要是元件的增加、減少與修改(啟動與關閉),判斷依據是元件對收益的貢獻,不是其績效。

• 不是微觀的基準變更(PMP 的糾正、預防、缺陷補救、更新);是戰略層面的增減
• 交付階段的大前提:主要工作就是啟動元件並使其順利完成
• 關閉可能正常也可能非正常;叫停的典型原因:對專案集收益實現已無貢獻
• 專案經理困惑「我照計劃執行、沒超進度成本,為什麼被停?」→ 方向錯了,效率越高越背離目標
• 類比:崗位是否保留不看勤奮,「勤奮苦勞在價值面前一文不值」

講師原話:「方向錯了,你的效率越高,說明你背離目標的情況越嚴重。」

🎯 考點: 元件績效良好但已不支撐收益 → 正確做法是叫停/關閉(經治理批准),不是因績效好而保留。

§68 管理專案集溝通:兩個例外領域含元件、資訊一致性 (02:10:01)

核心: 一般說「專案集」只指上層架構;溝通(含績效報告)與收益是兩個例外,一說就包含元件。

• 專案集收益 = 總體 + 局部;績效報告屬溝通,也連整體帶局部
• 變更雖談元件,但是在專案集層下達啟動/結束的命令,不是內部管理
• 內容:資訊生成(狀態報告一定納入元件資訊)、分發(對象寫在溝通管理計劃)、儲存(供最後移交)
• 元件溝通協調機制:關注跨元件之間溝通是否順暢、標準是否統一
• 一致性問題:不同團隊彙報同一專案資訊不一致 → 資訊來源統一(從資訊系統提取,不准手動編輯)
• 這同時屬於溝通、基礎設施與治理的內容

🎯 考點: 多個元件報告數據衝突 → 建立單一資訊來源/統一系統提取。

§69 溝通最重要的用途:支持決策 (02:13:10)

核心: 溝通表面是傳遞資訊,最重要的用途是提供管理層與治理做決策,因此屬治理範圍。

• 學員答:戰略(太寬)、透明(是性質不是目的)、認同、滿足 sponsor 期望、信任、爭取資源、獲得支持——方向都可以
• 講師答案:資訊/報告用來給管理層做決策,重要程度立即提升
• 管理層因此要求資訊客觀、可靠、可驗證
• 節點、關口(gate)提供的報告都是用來決策的
• 講師說明此為超出標準的延伸

講師原話:「重要的溝通,全是用來做決策的。」

§70 管理專案集財務:funding 與現金流,不只是成本控制 (02:16:29)

核心: 專案集經理要與發起人一起管資金來源、何時進來、何時支出(cash flow in/out),這才叫財務管理;成本控制只是其中一環。

• 包括預算跟蹤、成本控制與預測、預算更新、資金申請與分配
• 成本管理 = 給定預算內控制支出,範圍狹窄
• 專案集需依各元件何時需要多少錢規劃資金(funding)
• 支出項:基礎設施維護、團隊成員、分包商、元件
• 專案不用關心錢從哪來(沒錢就不做),專案集要關心 → 改名「財務」的重大背景

講師原話:「有了錢之後,你對錢的支出加以管控,這個才叫成本控制。」

PMI 術語: Funding ↔ 資金 / Cash Flow ↔ 現金流

⚠ 新版變化: 專案集以「財務管理」取代「成本管理」。

🎯 考點: 專案集財務的獨特點 = 資金來源與時程(funding),不只預算內控制成本。

§71 財務:規劃 vs 交付各做什麼 (02:18:44)

核心: 預算制定在規劃財務管理完成;交付階段只管資金來源、申請、分配、合同付款、預算跟蹤。

• 構建:估算專案集初始成本
• 規劃:專案集成本估算(更細)+ 財務框架 + 財務管理計劃
• 交付:資金怎麼來、怎麼用、先給哪個元件、哪些支出優先、對分包商如何支付

🎯 考點: 「制定預算」→ 規劃;「跟蹤預算/分配資金」→ 交付。

§72 管理專案集資訊 vs 溝通 (02:20:18)

核心: 資訊管理強調有形載體(文件、artifact)怎麼存起來;溝通強調動作(怎麼做起來)。

• 資訊 = 內容:文件、經驗教訓、資訊產品
• 包括收集、接收、組織、儲存
• 專案集文件量大:章程、管理計劃、報告、登記冊需分門別類便於檢索
• 鏈路:評估 → 規劃 → 管理

PMI 術語: Artifact ↔ 工件 / Lessons Learned ↔ 經驗教訓

§73 管理專案集採購:為所有元件定標準、集中採購 (02:22:30)

核心: 專案集採購為「所有(或同一類)元件」制定標準,元件可自訂但不得低於標準;集中採購是現行好做法。

• 問題:採購標準是對所有元件適用,還是為每個元件個別設定?→ 前者,分層分級管理
• 元件標準可比專案集更嚴格,不可更低
• 合格賣方清單(類似短名單):只能向清單內供應商採購
• 預先協商的合同:通用合同模板,條款已部分限定,仍需溝通
• 一攬子採購(框架 + 訂單):專案集定框架,各元件下訂單
• 集中採購:降低風險與成本、協調需求、量大議價;可在 PMO 設供應商/合同管理角色

PMI 術語: Qualified Seller List ↔ 合格賣方清單 / Pre-negotiated Contract ↔ 預先協商合同 / Blanket Purchase Agreement ↔ 一攬子採購協議

🎯 考點: 專案集採購的角色 = 跨元件統一標準/框架,不深入替每個元件做採購。

§74 保證和控制專案集質量:審計 vs 檢查 (02:27:04)

核心: 質量保證面向過程,工具是審計;質量控制面向可交付物(結果),工具是檢查(inspection)。

• QA 在 PMP 屬執行過程組,QC 屬監控過程組 → 本活動兼具執行與監控
• QA:定期(也可隨機)質量審計,評估過程是否符合標準,為持續改進提供基礎
• QC:關注可交付物
• check = 通俗說法;inspection = 專業的 QC 工具
• 實際上 QA 也看批次結果,但考試不會考到這麼深
• 常見工具:檢查表、控制圖、魚骨圖、帕累托圖等,考試不專考工具

講師原話:「質量控制的工具叫檢查,檢查對象是可交付物;質量保證的工具叫審計,審計對象是過程。」

PMI 術語: Quality Assurance ↔ 質量保證 / Quality Control ↔ 質量控制 / Audit ↔ 審計 / Inspection ↔ 檢查

🎯 考點: 對過程 → 審計(QA);對可交付物 → 檢查(QC)。

§75 管理專案集資源:依優先級分配(收益貢獻) (02:29:55)

核心: 專案集資源管理不只是分配,而是依元件優先級分配,優先級取決於對專案集收益/目標的貢獻度。

• 講師點明此處出題通常較難、經常考
• 包括爭取、審批、分配,含平衡與協調(balance / coordination)
• 分配依據:元件優先級;「收益最大化」也對,但中間隔一層邏輯鏈
• 對專案集收益/目標貢獻度越高 → 優先級越高 → 優先分配
• 分配給元件後,元件內部管理不干預

🎯 考點: 資源衝突題 → 依元件優先級(收益貢獻度)分配,不是平均分或先到先得。

§76 元件依賴關係影響資源分配 (02:32:38)

核心: 專案集與專案組合元件最大差別之一是專案集元件間有依賴關係;分配資源先看優先級,再看依賴關係,再結合兩者。

• 講師說第五版有些內容可能被忽略或寫得不明顯,此點重要程度最高
• 依賴關係與優先級互相影響;理解標準時建議:談優先級時先把依賴關係放一邊
• 例:A、B、C 三專案,A 貢獻 80%、B 15%、C 5%,資源只夠兩個 → A 優先級最高(本段逐字稿至此結束,例子後續在下一 part)

講師原話:「我到底先給 A 還是先給 B?先看優先級,再看依賴關係,然後要把這兩個結合在一起。」

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

🎯 考點: 專案集元件有依賴關係(專案組合元件不一定有)→ 分配資源要綜合優先級 + 依賴關係。

Part C (02:35:09 - 03:50:17) 綜述

這一段是三天精講的最後一段，接著講交付階段的支援活動（Program Delivery Phase Supporting Activities），講完後整段講收尾階段（Program Closure Phase），最後很快帶過附錄 X1 的評估/規劃類活動，並給出研讀建議。脈絡分三塊：(1) 交付階段的三項管理活動：管理專案集資源（優先順序之外還要管依賴關係）、管理專案集風險（元件間依賴關係會引發連鎖放大的風險，抓住機會就是 1+1>2 增量收益的來源）、管理專案集進度（管的是高層級元件起止加專案集層的協調活動，主進度計劃很接近路線圖）、管理專案集範圍（範圍不再是重點，變更可以擁抱甚至主動追求，Program WBS 只拆到元件層）；(2) 收尾階段六項活動：收尾專案集（整合活動）、財務收尾、資訊存檔與移交、採購收尾、資源移交（釋放）、風險移交；(3) 附錄的評估/規劃活動與研讀順序。

最重要的考點判準： 1. 資源分配先看優先順序，再看依賴關係：被依賴的元件（C）就算優先順序低，也得先拿資源。 2. 專案集成功與否不用基準（baseline）判斷，而是把「結果」跟商業論證、組織/戰略目標比；按計劃執行不是重點，抓到老鼠才是好貓。 3. 收尾的啟動條件是所有元件已完成或終止，而且已開始交付收益；收尾由指導委員會（Steering Committee）批准；收尾的指導文件是專案集管理計劃，最終報告（Final Report）是收尾的輸出，不是收尾的條件。 4. 最終報告常考的三項內容是經驗教訓、收尾原因、客戶批准證明；它是治理計劃要求的必要文件。 5. 殘餘風險要告知接收方，並移交到組織風險登記冊；接收方不接手時，由組織層 PMO 接手管理。

§77 資源分配：優先順序 vs 依賴關係 (02:35:09)

核心: 先用戰略貢獻度定優先順序，但專案集內的資源分配一定要再疊加依賴關係判斷；被依賴的元件必須先拿到資源。

• 優先順序依「對戰略的貢獻度」排：A 第一、B 第二、C 第三，A 一定先拿資源
• 只看優先順序的話，剩下的資源只夠給一個時給 B
• 但如果 B 的開始條件之一是 C 先完成，這是依賴關係，不是優先順序關係：不讓 C 完成，B 再重要也開始不了，所以資源要先給 C
• 更複雜的情況：B 依賴 C 完成、A 也需要 C 的輸出，資源只夠一個時也不能給 A，要給 C
• 專案集管資源的思路跟專案組合（portfolio）不完全一樣：專案集元件之間的依賴關係可能超級複雜

PMI 術語: Dependency ↔ 依賴關係 / Prioritization ↔ 優先順序排序

🎯 考點: 題目給「資源只夠一個元件」的情境時，先排優先順序，再檢查依賴關係；被其他高優先元件依賴的前置元件先拿資源。

§78 管理專案集資源的內涵 (02:36:58)

核心: 專案集經理管資源，除了調配和分配，還要管依賴關係（約束）；元件之間依賴關係特別明顯，所以對專案集經理的要求很高。

• 四個重點：資源需求、對專案集目標的貢獻度、關鍵（稀缺）資源的識別、資源約束管理（也可以叫依賴關係管理）
• 資源類型不只有人力資源，還有物質資源、財務資源、技術資源
• 優先順序大家都知道要管，但千萬不要忘記依賴關係

PMI 術語: Scarce Resources ↔ 稀缺資源 / Resource Constraints ↔ 資源約束

§79 資源管理生命週期各活動的歸屬 (02:38:00)

核心: 資源管理全生命週期分屬三個活動：規劃屬於「規劃資源管理」，獲取/分配/監控/最佳化屬於「管理專案集資源」，釋放屬於收尾階段的「專案集資源移交（釋放）」。

• 全生命週期：資源規劃 → 獲取 → 分配 → 監控 → 最佳化 → 釋放
• 「管理專案集資源」只直接對應中間四項：獲取、分配、監控、最佳化
• 資源規劃屬於上一個過程（規劃資源管理，從資源管理整體角度講）
• 資源釋放是收尾階段一個獨立的活動，不在管理資源裡

🎯 考點: 問「釋放資源屬於哪個活動」時答收尾階段的資源移交/釋放活動，不要選管理專案集資源。

§80 管理專案集風險的範圍 (02:39:26)

核心: 「管理專案集風險」主要指風險出現後的應對執行與監控；規劃屬於前面的規劃活動，風險移交屬於收尾。

• 風險管理全流程：識別 → 分析 → 規劃應對 → 實施應對 → 監控
• 管理專案集風險：規劃拿出去、收尾移交也拿出去，剩下執行和監控，內容涵蓋識別、評估、應對、監控
• 講師提醒：標準這塊概念描述模糊，第四版、第三版都有這個問題

⚠ 新版變化: 講師認為第 5 版延續了第 3、4 版的問題，「管理專案集風險」的邊界沒有理清楚。

§81 元件依賴關係引發連鎖放大的風險 (02:40:41)

核心: 元件之間的依賴關係本身會引發專案集層級的風險，而且有連鎖效應；風險是中性詞，威脅會被放大，機會也會被放大。

• A 犯了錯，B 可能把它無限放大，因為 B 和 C 之間還有依賴關係
• 依賴關係管得好，機會和收益也會跟著放大，所以是雙向的
• 正面風險叫機會（opportunity），負面風險叫威脅（threat）
• 威脅沒管好，會在專案集錯綜複雜的網路關係裡產生負面連鎖反應
• 機會沒抓到，頂多是沒有收益，但不會有損失

講師原話：「元件之間的依賴關係會引發專案級層面的風險，它會有級聯效應。」

PMI 術語: Opportunity ↔ 機會 / Threat ↔ 威脅 / Cascading effect ↔ 連鎖（級聯）效應

§82 依賴關係是 1+1>2 增量收益的來源 (02:43:34)

核心: 專案集「1+1>2」的增量收益就來自依賴關係；依賴關係是整個專案集管理底層的連結點。

• 專案集經理工作的表面性質是「協調元件」
• 元件是從分析收益與依賴關係後定義、構建出來的，所以元件構建在收益之間的依賴關係之上
• 管好收益之間的依賴關係，才能管好元件之間的依賴關係；面對機會時，同樣投入一分資源能換回十分收益
• 只在專案之間協調是表層，第一層是收益；看不到收益背後的聯繫，協調做不到水準

講師原話：「專案級經理真正的功夫和本事，就在於看到背後的依賴關係和聯繫，然後把專案級收益最大化。」

§83 引爆點與資源作為手段 (02:45:29)

核心: 看出依賴關係就能找到「引爆點」；資源是手段，看到機會就壓上資源放大收益，碰到威脅就投入資源封堵、避免連鎖效應。

• 知道現在這麼做，會撬動幾個階段之後的暴增，這就是引爆點，背後講的就是依賴關係
• 資源跟依賴關係連在一起：機會出現立即投入資源，帶來放大效應
• 這是專案集管理的難處，也是含金量所在

講師原話：「我一看這有了機會，資源立馬壓過來，然後資源投入之後，立馬帶來了放大效應。」

§84 管理專案集進度：管元件之間的依賴 (02:45:55)

核心: 專案集層的進度管理管的是元件，排進度時要考慮元件之間 FS/SS/FF/SF 的邏輯關係，所以進度管理同樣受依賴關係影響。

• 排進度最基本的是元件之間的 FS、SS、FF、SF 四種關係
• 規劃時把專案集進度排好，執行時依專案集進度計劃做日常管理
• 「定義活動的里程碑、確定活動之間的依賴關係」中的「活動」應理解為元件層面：ABC 元件之間的關係、每個元件的持續時間、在主進度計劃上的位置

講師原話：「專案級層面的進度管理，管的仍然是元件之間的關係。」

PMI 術語: Finish-to-Start (FS) / Start-to-Start (SS) / Finish-to-Finish (FF) / Start-to-Finish (SF)

§85 進度、資源、依賴關係三者緊密相關 (02:47:18)

核心: 進度管理、資源管理、依賴關係管理緊密相關；排在前面但資源不到位，一樣執行不了，還會連鎖影響後面的專案。

• 進度排好了還要匹配上資源，不然會引起連鎖反應
• 依賴關係在某些局部概念中又被稱為因果關係

講師原話：「所以進度管理、資源管理和依賴關係管理緊密相關。」

§86 進度規劃 vs 進度控制 (02:47:48)

核心: 進度規劃屬於上一個（規劃）活動，進度控制屬於「管理專案集進度」；進度正常與否都要出進度報告。

• 管理專案集進度就是按進度計劃執行，實際上管的是元件按時開始、按時完成
• 一旦出現偏差就進行控制，所以進度控制屬於這個活動
• 不論進度正常或不正常，都會有進度報告

講師原話：「進度規劃屬於上一個活動，進度控制屬於現在這個活動。」

§87 核心目標：按時產生收益 (02:48:29)

核心: 專案集進度管理的目標是讓專案集按時產生收益；追蹤和監控所有高層級元件與專案集活動的開始、結束時間，有變化就及時更新主進度計劃。

• 標準原文是「按時產生所需的收益和能力」，講師建議記成「按時產生收益」
• 關鍵詞：高層級元件、專案集活動，兩者的起止時間都在管理範圍
• 出現變化時，及時更新專案集主進度計劃（Program Master Schedule）

講師原話：「把能力去掉，按時產生收益。」

PMI 術語: Program Master Schedule ↔ 專案集主進度計劃

§88 元件層 vs 專案集活動層的進度 (02:49:34)

核心: 專案集進度管理同時管兩層：元件層面（各專案何時開始、何時完成）和專案集活動層面（專案集經理做的協調類活動）。

• 框架：A 是專案集層面的活動，B 是各元件（專案）
• 「高層級元件的開始和結束時間」指 B：A 元件、B 元件什麼時候開始、什麼時候完成
• 專案集活動本身也有要開展的動作，例如「管理專案集進度」本身就是一個專案集活動
• 「高層級元件」跟「專案」並列時，元件大多指專案；寫成「所有高層級元件活動」時，元件同時包含 A 和 B

講師原話：「專案級的進度管理，一來是要管元件層面的進度，二來是要管專案級活動層面的進度。」

§89 Program Components 三大類 (02:51:30)

核心: 專案集元件（program components）有三類：專案、子專案集、其他活動；「其他活動」就是本章講的專案集活動（核心活動和支援活動）。

• 三類元件：專案（project）、子專案集（subsidiary program）、其他專案集活動
• 其他活動包括核心活動和支援活動
• 邏輯上是嵌套的：「管理專案集進度」本身是一個專案集活動，它要管的是專案集裡所有的活動和元件

講師原話：「它下面的元件有三大類：一類叫專案，一類叫子專案級，還有一類叫其他活動。」

PMI 術語: Program Components ↔ 專案集元件 / Subsidiary Program ↔ 子專案集 / Other Program Related Activities ↔ 其他專案集相關活動

§90 專案集層協調活動也要進主進度計劃 (02:52:39)

核心: 元件的主體（majority）是專案，但專案集層面的協調類活動也要人做、要花時間、要耗資源，所以也要列進專案集進度計劃。

• A 類都是專案集層面跨元件、跨專案的協調活動
• B 類大量是以專案或子專案集形態存在，專案是主體
• 標準一直強調「所有」高層級的元件和專案集活動的起止時間，這句話很容易被忽略
• 元件之間有聯繫，所以複雜度超級高，甚至要靠電腦工具才排得出來

講師原話：「在專案級層面也有一些協調類的活動，這些活動也應該進入你的專案級進度計劃裡去。」

🎯 考點: 專案集主進度計劃的內容 = 所有高層級元件 + 專案集層活動的起止時間，不要漏掉專案集層的協調活動。

§91 進度控制：偏差、根因與「高層級」的含義 (02:54:22)

核心: 進度控制 = 執行計劃 → 追蹤實際進度 → 跟計劃比對找偏差 → 找出偏差原因（會重複出現的原因要處理）→ 必要時修改計劃。

• 「高層級」指只看元件的開始節點和完成節點，過程不管
• 如果把階段關口（gate）等內部節點都放進來，層級就不夠高了，因為階段關口是專案自己管的
• 不得不調整時就改計劃

講師原話：「高層級其實是有含義的，指的就是開始跟完成的節點，過程我不管。」

§92 主進度計劃與路線圖的邊界 (02:55:29)

核心: 專案集主進度計劃和路線圖（roadmap）的邊界比較模糊；只列元件起止、不管過程時，它更像路線圖。

• 主進度計劃尤其在只列元件起止時，很像路線圖
• 還要出狀態報告，告訴重要干係人每個元件的進度狀態和整個專案集的狀態
• 偏差大時要釐清處理

講師原話：「主進度計劃和路線圖的邊界不清楚，是比較模糊的，它有點像路線圖的意思了。」

PMI 術語: Roadmap ↔ 路線圖 / Status Report ↔ 狀態報告

§93 管理專案集範圍：範圍不再是重點 (02:56:01)

核心: 管理專案集範圍就是執行範圍、看是否超出範圍，但在專案集裡範圍超不超問題不大，只要收益最大化，範圍可以增也可以減。

• 範圍規劃、範圍評估在前面；這裡是過程中的範圍管理（範圍控制）
• 核心目標：隨專案集發展向前演進，管好範圍；捕獲、評估範圍變更請求，決定處理方式，更新專案集範圍說明書和 WBS
• 要點一：專案集範圍管理沒那麼重要，但基本概念都在，範圍說明書、WBS 都存在
• 要點二：專案集的目標（收益）才是管理重點，範圍不是不能突破的東西；範圍的重要性已被收益管理取代

講師原話：「只要讓我的目標收益達到最大，我的範圍可以增減。」

PMI 術語: Program Scope Statement ↔ 專案集範圍說明書 / Program WBS (PWBS) ↔ 專案集工作分解結構

§94 專案集對變更的態度：擁抱、主動追求 (02:57:45)

核心: 只要變更對收益實現有正貢獻，專案集就擁抱甚至主動追求變更，因為目標是收益最大化，而不是範圍不超出邊界。

• 範圍定義在範圍規劃；範圍控制（捕獲變更、發現變化、調整）在這個活動
• 擴大範圍或縮小範圍，只要讓收益最大化都可以被允許，至少不是一開始就否決
• 這已經不是傳統專案管理守住範圍的邏輯

講師原話：「只要這個變更對我的專案級的收益實現有正貢獻，我就要主動追求變更。」

🎯 考點: 選項中出現「拒絕/避免範圍變更」通常是專案思維；專案集題應評估變更對收益的貢獻，有正貢獻就接受。

§95 Program WBS 只拆到元件層 (02:58:36)

核心: 專案集也有範圍說明書和 WBS，但 Program WBS 只拆到元件層，最多到元件的第二層，不包含專案的工作包。

• 實際存在的邏輯結構是：專案集 → 元件 → 工作包 → 活動
• 專案集算第 0 層，第 1 層是元件清單，第 2 層是元件的再分（例如按階段分），到這裡就夠了
• 不要再往下分解，不要包含專案的工作包

講師原話：「我們的專案級的 WBS，大家記住這一結論就行了，只到元件這個層面。」

🎯 考點: 問 PWBS 分解到哪一層時，答元件層（頂多元件的第二層），工作包是專案經理的事。

§96 交付階段收束，進入收尾階段六項活動 (03:00:02)

核心: 標準對交付階段和收尾階段的活動都逐一展開講，但構建和規劃階段只給了框架；收尾階段有 6 項活動，其中 1 項是整合活動，5 項是支援活動。

• 講師批評書的結構還需要優化：構建/規劃只講整體架構，交付/收尾每個活動都講
• 收尾 6 項活動：收尾專案集（整合層面）、專案集財務收尾、專案集資訊存檔與移交、專案集採購收尾、專案集資源移交、專案集風險管理移交
• 所有活動的總體目標：保證專案集正常結束，把資源、風險等全部做收尾

講師原話：「這是專案級的整合活動，剩下的這五個是支援活動。」

PMI 術語: Program Closure Phase ↔ 專案集收尾階段 / Program Closeout ↔ 收尾專案集

§97 收尾目標：釋放資源 + 移交到日常運營 (03:01:12)

核心: 收尾活動的目標是釋放資源，並確保剩餘的專案集輸出和資產「過渡（transition）」到組織的日常運營。過渡就是移交。

• 移交的接收方可以是另外的組織，不一定跟專案集在同一個組織
• 六項活動中，前面幾項（收尾專案集、財務、資訊、採購）都是整體層面的

講師原話：「過渡、移交是一個詞，移交到組織的日常運營活動裡去。」

PMI 術語: Transition ↔ 過渡/移交 / Operations ↔ 運營

§98 收尾的啟動條件：元件完成 + 已開始交付收益 (03:02:09)

核心: 專案集收尾始於所有元件已交付輸出（正式完成收尾），而且專案集已開始交付預期收益，兩個條件要同時滿足。

• 啟動條件事先就要約定好
• 元件的完成指正式完成，也就是元件收尾結束以後
• 收尾包含兩個動作：移交（T）和關閉
• 移交總得有東西可交，要麼是元件，要麼是收益；什麼都沒有就「收了個寂寞」

講師原話：「專案集收尾活動始於專案集的元件已交付所有輸出，且專案集已開始交付預計收益之時。」

🎯 考點: 收尾前提：所有元件已完成（或終止），且收益已開始交付；元件未完成就不能啟動專案集收尾。

§99 「釋放資源」太低：真正的目標是收益移交 (03:03:24)

核心: 標準把收尾目標寫成「釋放資源」，講師認為高度不夠；業務主線是把收益交給接收方，管理動作才是把資源釋放回組織。

• 業務角度：把結果（收益）交出去
• 管理角度：趕緊把資源釋放給組織，讓組織去做更多專案
• 標準寫「移交專案集輸出」不夠準確，應該是「移交專案集收益」

講師原話：「他的目標是把我們專案級產生的收益，交到接收方那去。」

§100 文件與資料資產：客戶不要，組織也要保存 (03:04:24)

核心: 過程中產生的文件、資料庫等資產，接收方（客戶）不要時，組織自己也要接手保存，成為組織過程資產。

• 資產主要是文件資料；客戶不要時，要移交給所在組織的運營部門保存
• 也有客戶連過程文件都要：設計圖紙、會議紀要、會上的結論和決策
• 收尾的核心是收益移交，另外還有資源釋放和過程文檔儲存

講師原話：「如果客戶不要，我們自己要把它保存，這是我們的組織過程資產。」

PMI 術語: Organizational Process Assets (OPA) ↔ 組織過程資產

§101 收尾在生命週期的位置：先移交再關閉 (03:06:21)

核心: 收尾是生命週期第三階段（定義、交付、收尾），標誌專案集正式結束並轉入運營，是專案集和運營的銜接點；銜接分兩步，先移交再關閉。

• 收尾專案集這個活動跟收尾階段高度重合，不用多講
• 大收尾 = 移交 + 關閉；關閉主要是內部管理動作，移交主要是業務動作（收益是最核心的部分）
• 五大支援活動：財務、文件資訊、採購、資源、風險管理

講師原話：「大收尾裡面包括移交加關閉，關閉主要指的是我們內部的管理動作。」

§102 收尾的指導文件：專案集管理計劃 (03:07:30)

核心: 決策批准收尾後才開始收尾；指導收尾的文件最佳答案是專案集管理計劃（沒有單獨的「專案集收尾計劃」）；最終報告是收尾的輸出，不是指導文件。

• 專案集管理計劃包含執行、監督、收尾各方面該怎麼做，前面講的十個方面中這五個在收尾時更重要
• 收益管理計劃屬於專案集管理計劃的一部分，指導收益如何移交（講師認為標準括號中的「維持」應去掉）
• 最終報告是收尾完成後的總體彙總，不用來指導如何收尾

講師原話：「因為沒有一個專門的計劃叫專案級收尾計劃，所以回答專案級管理計劃，這個答案應該是最好的。」

🎯 考點: 「依據哪份文件做專案集收尾」選專案集管理計劃；最終報告是輸出。

§103 收尾的整合活動與移交清單漏了收益 (03:09:16)

核心: 在收尾階段出現、整合其餘五項的核心活動是「收尾專案集（Program Closeout）」，它屬於專案集整合管理的五項之一；標準列的移交內容（文件、資產、資源）漏了最重要的收益。

• 移交給組織運營的內容：專案集文件類資產和資源，講師補上「收益」
• 收益沒交付，光有文件資料就沒有太多價值；收益交了，文件資料才重要
• 名稱前後不一致：收尾專案集可分成「移交和維持」或「移交和關閉」，講師說會再查證是不是翻譯錯誤或疏漏

講師原話：「如果你最重要的收益沒有完成，光有這些，那就沒有太多價值。」

§104 正常關閉 vs 提前終止 (03:12:22)

核心: 專案集收尾有兩種：正常關閉（按計劃到時候收尾）和提前終止（還沒到時候，但已沒有可能實現收益）；未達收尾條件不能啟動收尾。

• 收尾有前置條件，沒達到前不能啟動
• 提前終止：時間沒到但條件已不具備，已無法再實現專案集收益
• 標準寫「專案集因章程完成而關閉」，講師解讀：章程一頭定目標，收尾一尾看結果

講師原話：「提前終止是沒到時候，但是條件已經不具備了，你已經沒有可能再實現專案級的收益。」

PMI 術語: Normal Closure ↔ 正常關閉 / Early Termination ↔ 提前終止

§105 啟動↔收尾＝目標↔結果，不是績效管理 (03:13:01)

核心: 啟動定目標、收尾驗結果，兩者對比是目標管理/結果導向；中間的規劃、執行、監控才是過程，用計劃、基準、KPI 管績效。

• 收尾依據專案集管理計劃做，但驗證的是「結果 vs 章程中確認的目標」
• 黑貓白貓抓到老鼠就是好貓：怎麼抓不關心，只看有沒有抓到
• 過程：計劃、基準、計劃與實際對比叫績效，管績效的核心工具是 KPI
• 啟動/收尾：目標 vs 結果，不叫績效管理，叫目標管理或結果導向
• 「因章程完成而關閉」應理解為章程中明確的目標達成才關閉

講師原話：「我不管黑貓白貓，抓住老鼠就是好貓，你怎麼抓住我並不關心，我關心的是你抓到了沒抓到。」

§106 正常關閉：目標＝預期收益，可部分實現 (03:15:15)

核心: 正常關閉 = 專案集達到預定目標並成功實現預期收益；如果事先約定收益可以部分在收尾時實現、大部分在運營後實現，仍然可以關閉。

• 目標在開始時被定義為收益：開始叫目標（預期收益），實現後叫收益（結果）
• 結果（result）包括收益、價值、可交付成果
• 收益不一定要在結束時全部實現，有約定就可以；沒約定、沒達到就不能關閉

講師原話：「你只要約定了，這個時候仍然可以讓你關閉，讓你收尾了。」

§107 提前終止的三個層次 (03:16:25)

核心: 提前終止的情況有三層：外界變化不再需要專案集或預見無法實現收益、組織戰略方向調整、戰略沒變但商業論證的假設條件大幅改變。

• 外界變化、不再需要這個專案集，或已預見無法實現，可以提前關閉
• 組織戰略方向調整，原來依舊戰略選出的專案集沒必要存在
• 商業論證變化：戰略沒變，但商業論證裡的假設條件發生很大變化

講師原話：「這個專案級沒必要存在。」

§108 專案集成功標準：結果 vs 商業論證／組織目標，不看基準 (03:17:09)

核心: 專案集成功與否不用基準判斷，而是把專案集的實際結果跟商業論證、組織/戰略目標比；沒按計劃執行但結果達到目標要求，也算成功。

• 標準列三項：商業論證、成果（講師認為應叫「結果」）、組織目標/戰略目標
• 基準只代表按計劃執行的程度，不是成功標準
• 章程的目標來自組織戰略目標；商業論證的商業需求、組織戰略目標，都是判定結果是否成功的依據
• 不是用專案集管理計劃判定成功；在專案集裡談基準是比較低層次的做法，要談收益和戰略

講師原話：「你沒有按計劃執行，但最終結果達到了目標的要求，你也是成功的，這個是專案級跟專案特別大的不同。」

🎯 考點: 專案集成功 = 結果符合商業論證與組織戰略目標（收益）；選項若以「是否符合基準/按計劃」為判準，是專案思維。

§109 收尾的必要條件與「條件 vs 活動」區別 (03:20:21)

核心: 啟動專案集收尾的必要條件是所有元件都已完成或終止、專案層所有活動都已關閉；資源釋放是收尾的活動之一，不是進入收尾的條件。

• 三個條件中最重要的是兩個：元件完成或終止、活動關閉
• 資源釋放是收尾活動；元件完成、合同完成是進入收尾的條件，兩者不同

講師原話：「資源釋放實際上是我們收尾的活動之一，元件完成、合同完成是我們進入收尾的條件。」

§110 指導委員會批准收尾與最終報告內容 (03:20:55)

核心: 正式關閉由專案集指導委員會（指定團體）批准，考試時基本都是指導委員會；收尾過程要產出最終專案集報告（Final Report），常考內容是經驗教訓、收尾原因、客戶批准證明。

• 指定團體或個人也可以是發起人，但考試基本選指導委員會
• 最終報告必記三項：成功與失敗的經驗教訓、收尾的原因、客戶批准的證明文件
• 其他了解即可：收益如何移交、財務情況、收尾前的驗收與前提條件

講師原話：「在考試的時候，基本都是指導委員會，他來批准，你才可以開始收尾。」

PMI 術語: Program Steering Committee ↔ 專案集指導委員會 / Final Program Report ↔ 最終專案集報告

🎯 考點: 誰批准專案集關閉 → 指導委員會；最終報告內容 → 經驗教訓、收尾原因、客戶批准證明。

§111 最終報告屬於治理計劃，必須編製但不是收尾條件 (03:22:04)

核心: 最終報告是治理計劃的一部分，標準寫「可能需要」，實際上是必須；它是收尾的內容（輸出），不是收尾的條件。

• 記錄內容：經驗教訓、成功與失敗、未來改進領域、收尾原因、客戶是否批准、執行中的財務與績效情況
• 目的：一是必要文件，二是給組織未來做類似專案集提供經驗教訓、好做法、踩過的坑、獲取收益的好方法
• 收尾不是依靠最終報告裡的要求來做

講師原話：「最終報告不是我們收尾的條件，它是收尾的內容。」

PMI 術語: Governance Plan ↔ 治理計劃 / Lessons Learned ↔ 經驗教訓

§112 專案集財務收尾 (03:23:20)

核心: 財務收尾要關閉元件層和專案集層的帳戶（不再有資金進出）、幫接收方估算維持收益的成本、處理殘留活動，並把剩餘資金返還給出資組織。

• 帳戶關閉：元件層、專案集層的帳戶都關閉
• 維持成本估算：幫接收方算出持續維持收益每年的投入與收益，讓接收方容易上手
• 殘留活動：許多成本在運營維護期間發生，但仍有一些需要專案集團隊持續監督的殘留活動
• 剩餘資金要返還給出資組織（sponsoring organization），錢從哪裡來就還到哪裡去

講師原話：「賬戶上還趴著一些錢，要還回去，返還給出資組織。」

PMI 術語: Sponsoring Organization ↔ 出資組織 / Sustainment ↔ 維持

§113 財務移交完成的三個條件 (03:25:12)

核心: 財務移交完成要三件事都做到：告訴接收方維持收益需要的資金預算、收益已真正交付給接收方、維護活動已經開始。

• 持續管理可以交給運營組織，也可以交給後續的專案集（resulting program，宜譯為「後續/最終的專案集」）
• 交給另一個專案集的情況不常見，基本上都是交給運營組織
• 三個條件都做到，財務責任才算平穩過渡

講師原話：「這三個都做到了，才能說財務移交完成。」

§114 專案集資訊存檔與移交 (03:26:07)

核心: 資訊存檔與移交是把資料、資訊、文件歸檔或移交，部分屬於法律法規要求；國際慣例專案關閉後資料至少保存 5 年（5 到 10 年），講師說應該不考。

• 國際類專案的文件保存是硬性條件，電子文件有延長趨勢
• 存檔支援後續運營：出狀況時可以回溯當時發生了什麼
• 給未來類似專案集翻閱、找經驗教訓

講師原話：「五年國際慣例，就是你的專案關閉完之後，你的資料儲存五年。」

§115 存檔活動、知識轉移與經驗教訓 (03:27:31)

核心: 存檔活動包括記錄、整理元件文件、知識轉移；最主要的是經驗教訓和知識轉移，不能做完一個專案集就把經驗丟掉。

• 專案集知識和過程文件要交給接收組織，幫助它維持收益
• 也要給自己組織存檔，或給客戶等干係人使用
• 專案集經理可以用來評估專案集績效（覆盤、後評價），資料來自績效評估記錄、團隊觀察與記錄
• 也支援最終報告的編製

講師原話：「我們不能做完一個專案或者專案級就把經驗丟掉了，那下次你在做的時候，仍然會踩坑。」

PMI 術語: Knowledge Transfer ↔ 知識轉移

§116 專案集採購收尾 (03:28:45)

核心: 採購收尾站在甲方（買方）角度：乙方可交付已完成、我方款項已付清、沒有未解決的爭議、索賠、申訴，任何一條沒完成都不能收尾。

• 一看乙方是否做完，二看自己是否付完錢，三看是否還有爭議、索賠、未解決問題
• 合同可以提前終止：甲方可以主張終止並給予補償；乙方不能主動解除合同，否則要承擔法律責任
• 專案集提前終止時，必須管理所有活躍（active）合同，讓它們都進入非活躍狀態，責任、義務、付款、爭議、索賠全部了結
• 目的是避免專案集關閉、團隊解散後還有一堆問題找不到人

講師原話：「甲方可以對乙方提出來主張，我要收尾，你需要什麼樣的補償我可以給你，但乙方不能主張。」

PMI 術語: Claims ↔ 索賠 / Procurement Closure ↔ 採購收尾

§117 專案集資源移交（釋放） (03:30:21)

核心: 資源移交其實就是釋放：專案集不再佔用的物質與人力資源要盡快釋放回組織，讓組織重新分配、創造更多價值。

• 資源是組織最重要的資產，被佔用就無法用到別處
• 可能涉及團隊成員與資金的重新分配或重新指派
• 團隊成員重新分派雖不是專案集經理的責任，但收尾階段組織與專案集要同時考慮

講師原話：「資源是組織最重要的資產，如果你被佔用，它就沒有辦法用到別的地方去。」

§118 元件級資源再分配與批准 (03:31:36)

核心: 標準說元件資源可以移交給執行中的另一個元件或另一個專案集；講師指出這只會發生在元件收尾而專案集未收尾時，專案集已收尾就應釋放回組織；資源移交需要指導委員會批准。

• 正常順序：元件資源釋放回專案集，專案集再釋放回組織
• 元件收尾、專案集未收尾時，A 專案釋放的資源可以給 B、C
• 資源移交由指導委員會批准
• 重新分配策略：評估資源技能、決定由哪些專案接收、何時釋放、文件轉移，重點是前三條

講師原話：「因為專案級都收尾了，你哪還會有另外執行的一個元件呢？」

🎯 考點: 資源移交/釋放需要指導委員會批准。

§119 資源移交的結果 (03:33:07)

核心: 資源移交後的結果有：資源重新可用、實物資產（辦公場所、場地）歸還公司或出售處置後資金回籠、相關租賃或採購合同終止、設備設施與物資再利用。

• 不再租賃，合同就終止，跟採購收尾有關聯
• 材料再使用：設備設施、物資

講師原話：「出售之後資金回籠，再回給組織。」

§120 專案集風險管理移交 (03:33:51)

核心: 專案集關閉時仍可能有殘餘風險會破壞接收組織實現收益，必須告知接收方並移交管理責任；風險要加入「組織風險登記冊」，接收方接手就由接收方管，不接就交給組織層常設部門（例如組織 PMO）。

• 兩件事：風險本身的告知、管理責任的移交
• 至少要把風險登記冊的資訊記錄好，交給接收方
• 風險及相關資訊要加入組織的風險登記冊（不再是專案集層面的風險登記冊），由接收組織或專案集所在組織持續監督管理
• 接收方不接時，在組織內找部門接手，例如 organizational PMO，因為它是常設部門

講師原話：「如果接收方不接，那你專案級層面要在組織找到一個部門來把它接下來。」

PMI 術語: Residual Risk ↔ 殘餘風險 / Organizational Risk Register ↔ 組織風險登記冊 / Organizational PMO ↔ 組織層 PMO

🎯 考點: 收尾時尚未處理完的風險：告知接收方 → 移入組織風險登記冊 → 由接收方或組織 PMO 持續監控，不能隨專案集關閉而消失。

§121 附錄 X1：基礎設施開發與評估類活動 (03:36:05)

核心: 附錄把構建與規劃階段的活動集中列出（正文只講框架），要正文加附錄才完整；專案集基礎設施開發被列為獨立活動，要點是核心團隊加 PMO。

• 專案集基礎設施開發：包括元件、PM、團隊、PMO 等
• 評估活動 = 構建子階段的動作，約 10 個；規劃活動也約 10 個
• 交付和收尾的活動已在正文逐一講過
• 變更評估：看變更來自外部還是內部條件
• 溝通評估：構建時還沒執行，對未來溝通情況做大致判斷；細節不用看太多，知道每個過程做什麼就好

講師原話：「前面的加上附錄的，才是一個完整的東西。」

PMI 術語: Program Infrastructure Development ↔ 專案集基礎設施開發

§122 初始成本估算 ROM (03:38:36)

核心: 初始成本估算是支撐商業論證和章程最重要的數字之一，目的是早期財務決策和立項依據，精度到粗略量級估算（ROM）即可；到規劃階段要更精確。

• ROM 精度：逐字稿語音辨識不清楚，PMI 慣用值是 -25% 到 +75%
• 規劃階段的估算要提高到確定性估算等級（逐字稿不清楚，PMI 慣用約 -5% 到 +10%）
• 資訊管理評估：對文件管理工作量做大致判斷

講師原話：「初始估算，目的是在早期為財務做決策用的，你得有一個大數。」

PMI 術語: Rough Order of Magnitude (ROM) ↔ 粗略量級估算

§123 採購、品質、資源、風險、時間、範圍的初始評估 (03:39:30)

核心: 構建階段還要對採購、品質、資源、風險、時間、範圍做初始評估；其中初始風險評估最重要的是判斷組織的風險偏好與風險臨界值。

• 採購：是否需要、什麼情境（例如 PPP、EPC 專案），了解即可
• 品質：品質要求、約束、合規要求，以及品質成本分類（預防成本、評估成本、失敗成本）
• 資源總需求的估算方法：自下而上（WBS 彙總）、類比（自上而下）、三點估算、專家判斷
• 資源類型：人力、物資、設備設施、技術軟體（財務單獨拎出來）
• 初始風險評估：組織風險偏好、風險臨界值
• 整體時間估算：用來制定路線圖或章程中的時間線；範圍初始評估了解即可

講師原話：「最主要的要判斷一下組織的風險偏好以及風險的臨界值。」

PMI 術語: Risk Appetite ↔ 風險偏好 / Risk Threshold ↔ 風險臨界值 / Cost of Quality ↔ 品質成本

§124 規劃類活動：管理計劃與基準、溝通規劃、成本估算 (03:41:09)

核心: 評估類活動用來生成目標、界定專案集的合理性；規劃類活動用來產出管理計劃和基準，用來管過程。評估有幾個，規劃就有幾個。

• 溝通規劃：方式、工具、頻率、載體、對象、格式、負責人，規劃好後執行與監督才有依據
• 成本估算：比初始估算更詳細，可用三點估算、參數估算等；附錄內容重要程度次之

講師原話：「前面的估算是用來生成我的目標，界定我的這個專案級的合理性。」

§125 財務框架與財務管理計劃 (03:42:13)

核心: 財務框架（Financial Framework，也叫融資框架）的重點是資金怎麼來，這是以往學習沒有的；財務管理計劃是財務框架的細化，包含預算基線。

• 資金模型：集中管理、分散管理等，講師整理成四種（包括專案集與元件資金同一家公司出資、資金與管理來自不同公司）
• 籌資責任在發起人，專案集經理沒有這個權利和能力
• 財務管理計劃包含預算基線；一出現基線就是對過程的管理
• 國際專案還涉及匯率、通膨、地緣與金融局勢風險，不用想太複雜

講師原話：「正因為加入了資金怎麼來、來源在哪，所以它才叫財務框架，也叫融資框架。」

PMI 術語: Program Financial Framework ↔ 專案集財務框架 / Program Financial Management Plan ↔ 專案集財務管理計劃

🎯 考點: 財務框架 = 資金來源（責任在發起人）；財務管理計劃 = 財務框架的細化（含預算基線）。

§126 採購規劃、合同類型與品質規劃 (03:43:56)

核心: 採購規劃決定買什麼、何時買（自製或外購分析）、合同類型；品質規劃定標準與 QA/QC 方法，執行 QA/QC 在交付階段。

• 合同三大類：固定價格類、成本補償類、工料（T&M）類，細分約七八種，考試不會考太細
• 品質規劃：品質標準、合規指標，以及 QA、QC 的方法
• 規劃時是定 QA/QC 方法，不是執行；交付階段的品質活動叫「品質保證與品質控制」，不叫管理品質

講師原話：「不是執行 QA 和執行 QC，執行 QA 和 QC 是在我們專案交付的那個階段做的。」

PMI 術語: Make-or-Buy Analysis ↔ 自製或外購分析 / Time and Material (T&M) ↔ 工料合同 / Quality Assurance / Quality Control ↔ 品質保證/品質控制

§127 資源規劃與風險管理規劃 (03:45:00)

核心: 資源管理的規劃在規劃階段完成（評估技能、能力不足就培養、自有不足就招聘、租賃、採購或外包）；風險管理規劃以初始風險評估和「戰略一致性」中的風險管理策略為輸入。

• 資源：自己能滿足的叫自有資源，不能滿足的透過招聘、租賃、採購、外包取得
• 風險管理計劃內容：識別、定性與定量分析、規劃應對、執行應對、監督風險
• 風險管理策略（在戰略一致性講）是風險管理規劃的輸入
• 風險登記冊、殘餘風險、次生風險、龍捲風圖等在專案集講得少，PMP 講得多

講師原話：「風險管理策略對風險管理計劃規劃來講是輸入。」

PMI 術語: Program Risk Management Strategy ↔ 專案集風險管理策略 / Secondary Risk ↔ 次生風險

§128 進度規劃與範圍規劃 (03:46:28)

核心: 專案集進度規劃以元件為顆粒度：先看優先順序再看依賴關係，安排各專案起訖與關鍵里程碑；主進度計劃很接近路線圖，但比路線圖細，又不如專案進度計劃詳細。

• 路線圖層級最高，主進度計劃次之，專案進度計劃最細
• 範圍管理規劃包含專案集範圍說明書和 WBS 兩份文件；專案集有這兩份文件，只是不重要

講師原話：「大家千萬不要認為專案級上面沒有範圍說明書、沒有 WBS，有的，但它不重要。」

🎯 考點: 專案集層級細緻度：路線圖 > 主進度計劃 > 專案進度計劃（由粗到細）。

§129 專案集報告 vs 最終報告；預算與元件撥付 (03:47:22)

核心: 「專案集報告（Program Reporting）」是執行中傳遞資訊的活動，屬於資訊/溝通管理；「最終報告」是收尾的輸出。專案集預算是所有元件與專案集成本彙總、權衡後經批准的基準，再加應急儲備和管理儲備。

• 專案集預算是財務管理計劃中最重要的內容，因為它是基準
• 預算分兩層：專案集層面、元件層面
• 元件撥付計劃：專案集把錢撥給元件，用於團隊與供應商（跟合同管理有關）
• 專案集預算從整體確定後分配給各元件；元件的成本估算受專案集給的數字限制

講師原話：「專案級的最終報告是一個輸出，而專案級報告，這是一個過程，或者叫活動。」

PMI 術語: Program Reporting ↔ 專案集報告（活動） / Contingency Reserve ↔ 應急儲備 / Management Reserve ↔ 管理儲備

🎯 考點: 區分 Program Reporting（執行中的溝通活動）與 Final Program Report（收尾輸出）。

§130 研讀順序建議與三天精講收尾 (03:49:23)

核心: 研讀標準要由高到低：先看第一、二章（原則），再看第三章（績效域，框架），最後看第四章與附錄（活動）；不建議倒著看。

• 層級越前面越高，往後越細
• 只看活動會很輕鬆，但沒有整體概念
• 後續串講會再回顧整體內容與考試大綱（ECO）的核心邏輯

講師原話：「你看活動看得很輕鬆，但是整體概念是沒有的。」