作者：Ray Sheen

每個專案不同，但你都能、也都應該從剛做完的事中學習。

為何要正式做 lessons-learned#

設有專案管理辦公室（PMO）的公司，通常把教訓回顧——又稱 postmortem 或 after-action review——納入每個專案的正式收尾流程。

沒有 PMO 的公司則多以非正式分享進行，趁成員聚會閒聊時帶過。不論哪種方式，重點是要在記憶猶新時把學到的東西捕捉下來。

兩個對比範例#

正面：作者剛帶完一個僅數月的小專案，團隊隨即聚餐慶祝，當場談「對的事」與「錯的事」。對話精彩、下個專案會更好。回辦公室後，作者與另一位成員把教訓記入專案資料夾。

反面：在某 Fortune 500 公司任工程部主管時，部分專案長達三年，核心團隊一定會在過程中換人。一場新產品上市後的回顧會中，只剩一位當初啟動專案的人在場——而她也已調任。在事後諸葛之下大家能看出原始計畫的錯誤，卻無從還原當時的事件與思路，因為大家不在場。

從那以後，作者對長期專案改用新做法：每個階段結束就蒐集教訓，而非等專案結束。

這帶來雙重好處：

• 團隊能清楚回憶並準確分析剛發生的事
• 教訓能更早被融入後續階段

四步驟回顧流程#

1. 評估商業案（Business case）#

第一個問題：「專案是否兌現了當初承諾的結果？」

這不是評估團隊「做工」的好壞，而是評估專案是否達到核可流程裡所釐清的高層期望——以及那些目標是否真的可達。

專案被批准是基於預期效益（銷售成長、成本下降、週期改善、瑕疵降低、產能擴大等）：

• 預期效益實現了嗎？
• 沒實現的話，原始假設與正當化邏輯是否本來就不正確？

認真檢視這些並把結論分享給發起人，能改善組織**「選對專案」與「設定務實章程目標」的能力**。設有 PMO 時，PMO 通常負責把這些教訓融入啟動流程。

2. 評估專案計畫（Project plan）#

第二個問題：「計畫對於這個目標與商業情境是否合理且合適？」

審視幾件事：

• 是否漏列必要活動？是否包含不必要活動？
• 各活動的成本與時程估算是否反映當時的商業與技術情境？緩衝是否合理？
• 初始風險評估：哪些風險沒被預見？哪些被低估？應對方式是否充足？
• 團隊與利害關係人溝通實踐：更新與資訊交換的機會是否足夠？對話是否在對的時機與對的人發生？決策是否及時？

3. 評估專案管理方法論（Methodology）#

第三個問題：「組織的專案管理程序與系統是否有助益？」

關注：

• 公司有沒有既定的程序、範本、檢核表？
• 即使有，內容是否夠新、夠相關？
• 規定的審查與管制點是否合適？
• 專案管理資訊系統在傳達計畫與狀態給所有人時，是否好用？

教訓往往會體現在公司的專案管理程序與系統裡。

範例：作者顧問一家中型代工廠時，驚訝發現他們所有業務都是專案制，卻沒有集中化的專案管理程序——只是雇用有經驗的 PM 後就放手。

結果是：「搖滾巨星」式的 PM 文化、做法毫無一致性。新進專案成員必須學新一套排程、預算、回報技巧；同時參與多個專案的人要支援多套（常互相衝突）的會議與報告格式，造成大量返工。

公司後來成立 PMO，三到四個月內建立了統一、簡化的規劃與執行程序。

4. 評估個人績效（Individuals’ performance）#

第四個問題：「我需要給團隊成員什麼回饋（好或壞）？該對他們的主管說什麼？」

即使組織沒正式要求，對所有核心成員都做這一步。

作者的做法：請全團隊一起指出彼此中的「超級英雄」——這既能公開強化「貢獻最多」的價值，又淡化「PM 偏心」的印象。表現不佳的成員則個別溝通。當然，績效評估的具體做法須依當地人資慣例。

確保教訓真正改變未來#

教訓回顧能促進持續改善，但作者經驗：這類報告幾乎沒人會讀。

別把希望寄託在「塞進專案資料夾的文件」上。

真正的做法：把教訓轉成行動項清單——交給 PMO 或下一位 PM，務必融入下一個專案。

立刻把洞察用起來：更新檢核表、調整審查流程、做任何必要的調整——在下個專案啟動前。

Ray Sheen 教授並顧問專案與流程管理，逾 25 年領導國防、產品開發、製造、IT 等領域專案的經驗，並曾在 GE Electrical Distribution 業務部執掌專案管理辦公室。