拯救失控專案:談管理機制導入前必要的診斷

拯救失控專案:談管理機制導入前必要的診斷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。