某天其他部門的同事跑來詢問我 : 「聽說你們的專案執行得不錯，可以給我們WBS參考嗎?」起初我有點一頭霧水，一問之下才知道原來是主管的指示，要他們前來取經，而且特別指名要看WBS。

據我所知，他們的專案範疇大、協作單位多，一直以來是個燙手山芋，卻又是公司轉型階段不得不執行的任務。雖然和我之前的專案有些相似之處，但畢竟團隊不同，產品的屬性也有差異，想用同一招打天下頗有難度，於是我開始思考，專案管理強調的Lessons Learned (經驗傳承) 精神，要如何落實? 專案要如何診斷缺乏的是什麼? 才能從過往的經驗中挖取適當的養分。

我試著想像那位同事收到的指令，應該是過去幾次的會議中，他們沒有報告明確的任務目標，也沒有事先的風險預警，當專案遇到問題遲滯不前時，主管第一時間便聯想到曾經也遇過類似問題，但後來卻克服的我們，而由於我們的WBS及相關文件相對清楚，主管自然而然就提出「去參考他們的WBS文件」這種看似很明確，卻充滿陷阱的提議。

為何說是陷阱? 因為專案若無法對症下藥就一股腦兒導入各種管理文件，不但無法解決問題，還可能影響專案進行，甚至產生錯誤的資訊，使得管理者無法辨識正確的問題。因此，我認為在挖掘其他專案的經驗之前，應該要先確認幾個議題 :

1. 執行問題還是管理問題?

專案管理能處理的面向，當然就是管理層面的問題，若是技術限制、外部環境影響，不應該期望透過專案管理的手法而有重大的改善，專案管理或許能使複雜的技術問題，透過WBS的拆解邏輯，歸納到適當的時間、人員身上去執行，同時也因釐清任務之間的關係，能事先進行風險應變，將問題減小，但核心的技術問題仍舊存在，必須被透明化、據實以報，並且定時監控最新的發展，直到它被解決為止。

我曾有個經驗是負責一項平台整合的專案，由於剛接手時，專案正處於時程延遲、人力不足的情況，我和同案的PM同事經過不少努力、與利害關係人溝通後，調整了時程、資源配置，也整理了一些管理文件，讓主管們可以安心追蹤專案的現況。

就在一切看似扭轉的同時，工程師們認為更久之前為了追趕時程，做了許多疊床架屋的設計，不得不提出「系統重構」的提案，使得專案又要重新進行時程與資源的評估。這些就是屬於躲在管理層面之下，不容易看見的執行問題。

2. 範疇，時間，或是成本?

一般而言，專案有三個最基本且相互影響的要素，分別為「範疇」、「時間」與「成本」，任何一個面向的改變，都可能影響到另外兩者。

有時候完工時間不斷延遲，可能和範疇不斷變動或膨脹有關，試想，當工程師好不容易開發出符合需求的套件時，卻被要求增加新的功能，他接下來要做的事，可能包括回頭修改資料的傳遞限制量、系統的乘載量、穩定度，以及數不清的連鎖反應，任務絕對不是只有「增加兩個功能」這麼簡單。如果變更的結果被視為「延遲交付」看待，那麼後續再怎麼調整WBS，任務再怎麼拆解、分工，只會被導向更多的加班、更多的人力投入而已。

專案管理所使用的文件，例如時程表、風險監控表等，必須是隨時間而被更新的，很多人製作文件、表單都只有一次性，也就是專案規劃階段，或導入文件管理的那一刻。

但由於時空背景不同，風險的能見度也會不同，如果一直用過去的視角觀看專案，自然就看不見現在或未來可能發生的問題。

再者，專案管理涵蓋多個知識領域(整合、範疇、時程、成本、品質、溝通……等)，每次都想包山包海並不切實際，若能在文件管理的機制導入前，先行診斷目前專案幾個重大問題的可能根因，未來在導入階段也較能針對問題加強管理，並且監控這些潛在風險的變化，如此一來，才能真正發揮專案管理的成效。

3. 真心求教抑或虛應故事?

在我提出的案例裡，是由主管發起的導入行為，被指定的專案負責人是否有足夠的認知，導入專案的文件管理機制能帶來什麼幫助? 或是不能改變什麼結果? 如果團隊成員本身有習慣的協作方式，短時間內要做出改變並不容易。特別是這種進行到一半的專案，團隊可能有更棘手的議題正在處理中，根本無暇分心改變自己做事或溝通的方法。

因此，整個專案團隊從上(包含sponsor)到下是否有心放下過往已失敗的現實，好好花點時間盤點專案的缺失，反而才是後續是否成功的關鍵。反之，若只是抱著虛應故事的心態，做點表面功夫取悅主管(製作精美的WBS和新的時程表，順便感謝一下主管英明的建議)，那麼過不了多久，專案還是會被打回原形。

總結來說，導致專案失控(或即將失控)的變因很多，在決定從管理面向改善之前，建議先為專案進行上述基本的診斷，後續的解決方案才好對症下藥去擬定。倘若你不幸是這個專案的負責人，請務必向上管理你的主管，確保他也全力支持專案接下來要進行的調整與改變，畢竟任何的改變都需要時間適應及發酵。