案例_Special Session：五大流程群組與專案控制
案例_Waterfall Software Development：瀑布式開發、階段審查與上市速度衝突
案例_Extreme Programming：極限程式設計、反覆式開發與持續回饋
案例_Do you ZBB?：零基預算法、優先順序與利害關係人期待
| 核心主題 | 主要觀點／概念 | 實務或理論意義 | 重要條件／限制／延伸 |
|---|---|---|---|
| 流程群組 | 啟動、規畫、執行、監控與控制、結案彼此重疊且可反覆進行 | 提供專案由授權、規畫、執行到控制與結束的管理架構 | 流程群組不等同知識領域，也不是只能線性出現一次 |
| 瀑布式／階段審查 | 每一開發階段需完成需求、文件與正式審查／簽核後才能前進 | 提高紀律、可追溯性與設計審查品質 | 規格衝突或後期才發現錯誤，會造成等待、重工與上市速度壓力 |
| 反覆式／極限程式設計 | 以小型使用者故事、短任務、持續整合、自動化測試、結對程式設計與持續回饋推進 | 提高對需求變動與市場回饋的反應速度 | 需要高度紀律、顧客／產品端持續參與與良好的測試基礎設施 |
| 監控與控制 | 監控負責蒐集與報告績效資料；控制利用資料縮小計畫與實際差異；評估則判斷品質與效果 | 讓偏差與風險能及早被辨識與修正 | 報告過度繁複、不同系統不一致，或規畫與監控脫節都會降低效果 |
| 優先排序／ZBB | 以有限時間與資源建立優先清單與零基預算線，並與主管及利害關係人持續溝通 | 把策略與目標轉成可執行的資源承諾 | 優先順序需動態更新；缺乏回饋會使績效期待失真 |
第3章包含 4個議題型案例，以不同情境說明專案管理流程與方法：Special Session 整理五大流程群組；Waterfall Software Development 檢視瀑布式的順序開發與階段審查；Extreme Programming 展示反覆式軟體開發；Do you ZBB? 則把資源優先排序與個人承諾連結起來。
Special Session 強調，啟動、規畫、執行、監控與控制、結案不是知識領域，也不是完全線性的五個階段。案例把專案章程、工作分解結構（WBS）、各類計畫、風險監控、實獲值分析（EVA）、控制報告與專案終止放進同一流程邏輯，說明不同知識領域會在多個流程群組中被使用。
Renegade 要求每個軟體開發階段都通過正式最終審查（Final Walkthrough, FWT）與離開條件，確保需求、文件與設計審查完整。相對代價是：若系統分析師、開發人員或測試人員在不同階段發現規格問題，專案就必須停下來等待解決與核准，使正式控制直接轉化為時程風險。
在 eFusion，舊方法過度複雜且速度太慢，極限程式設計（XP）改用小型使用者故事、短任務、結對程式設計、持續整合、自動化測試與每日回饋。範疇與優先順序可以在故事開始前持續調整，專案速度與測試結果則提供進度與品質可視性。原書同時指出，開發方法改善無法自動解決根本商業問題，例如低使用率背後的市場因素。
兩個軟體案例形成清楚對照：瀑布式方法依正式審查與階段簽核控制；XP 則把測試、每日站立會議、速度指標與持續整合嵌入日常工作。兩者都需要控制，但控制的時間點、細緻程度與回饋頻率完全不同。
Do you ZBB? 把零基預算法（Zero-Based Budgeting, ZBB）作為優先排序與產能管理方法：先列出專案／交付成果與所需投入，再依組織目標排序，劃出資源界線，和主管確認並告知利害關係人。Bob 的案例進一步顯示，優先排序若缺少持續溝通，會演變成承諾落空與績效管理衝突。