甘特圖或許是多數PM最常製作的一張圖表，但是有多少人會在專案執行的過程中，持續透過這份資料追蹤、更新時程? 又或者有多少人能從當中看出潛在風險、並適時調整專案步伐呢?PM進行專案時程估算時，常常會犯以下幾個錯誤：

1. 任務拆解過粗，未與團隊取得共識

根據PMBOK所述，一個任務工作包最好不要超過80個工時，不過這只是理想上的建議，實務上估算工時是一件非常困難的事，特別對於軟體開發而言。所謂80個工時，最主要的意涵在於工作切包的合理性，避免大小不一的工作包，造成進度追蹤過程的困難度。假如規劃階段的工作切包不夠精確，在執行階段勢必會被展開成更多的子工作項、多出更多預期外的時程，這便是造成專案無法如期完成的主因之一。

如何讓工作包的切分更精確呢? 最好的方法是讓團隊成員提早加入任務規劃的行列，進行系統分析。

系統分析的目的在於，將執行細則尚不明確的專案目標(可能只有商務邏輯)，展開成具體的、結構化的描述。例如一個以女性為TA的購物網站需要建構何種規格的資料庫? 從登入、挑選購物清單到結帳，過程需要串接哪些不同的認證機制?

盡可能將專案所需的資源、工作，透過團隊合作拼湊完整，然後再將其分類、切包。團隊成員參與展開工作包的好處，在於不同的人可以提供不同的經驗，同一項任務可能會有更多元的解法，也可能發現潛在的風險，除此之外，既然工作項目是團隊一同展開的結果，屆時進行分工時，也能省去往來溝通的時間成本。

2. 只條列項目與工期，未能釐清任務關聯性

拆解任務只是第一項工作，但工作間彼此會有關聯性，也可能會有跨部門協作的議題，以購物網站為例，結帳的過程可能包含帳號核對、金流管理、購物紀錄等不同的工作包，假設評估工時分別為60、80、45小時，但總工時卻不一定是60+80+45=185，還必須考量不同單元的串接、跨部門的資源配置，將這些前置、後處理、等待的時間全部納入之後，才會是一個專案時程的全貌。掌握全貌後，才能針對不合理或期望改善的地方著手調整。

繪製甘特圖，或者填寫專案時程表，老實說是苦工一件，但苦過之後，會讓專案更加明朗。

去年我曾經接手一個超乎預期完成日半年的專案，該案為屬於公司內部的重要專案之一，是一個網路平台的架構重整，投入的資源亦不少，但上線日期從4月、6月、10月一路往後遞延，不但成了各PM眼中的燙手山芋，還讓外單位對專案產生了不信任感。10月份組織改組，我和另外兩位技術主管接手後，開始針對專案範疇進行地毯式的盤點，後來發現專案當初會一直延宕的原因，除了已知的技術難度之外，最大的原因其實是沒有仔細估算過時程，當高層主管們提出期望的完成時間，PM僅評估團隊被分配的工作任務項，沒有考量跨單位資源，便承諾如期完工，沒想到老闆的認知的完成=上線，PM的標準則是完成開發，中間還有驗收、修改、跨單位整合...等議題，一來一往就差了兩三個月的時間。

重整後，我們提出較有把握的上線日期，並明確定義開發完成日、驗收日、上線日等不同階段的里程碑，當老闆要求縮短時程的時候，我和技術主管們也具體回報可能的連鎖反應，最後老闆也認同了我們提案的版本，讓專案重回正軌，如期(新的時程)上線。能夠完成這項艱困的任務，並非我們用了什麼高深的管理技巧，而是我們很認份地，扎實地重新執行了最基本的盤點工作，並讓複雜的關聯展開在時程表內。

3. 未記錄變更、未更新進度，失去參考價值

在繪製甘特圖的時候，最麻煩的就是專案工作項彼此交錯複雜的關係，而且往往改一個小地方，就會連動好幾個項目，因此多數的甘特圖表往往只用在期初專案審核，接下來就是靠PM的協調能力一招打天下! 專案小或者有經驗的PM或許還能應付，但若是遇上大型專案，不把那些盤根錯節的項次給搞清楚，星星之火何時會燎原便很難預知了。

以我前述的案子為例，為了讓我和技術主管間有共同的認知，我們各自管理了一份專案時程表，他的那一份主要是IT項目展開，我的這一份則是全案(包含外單位、行政事務)的展開，我的某一階層展開則是他的任務源頭，因此當IT完成了某部分工作，我便能掌握進度。

總括來說，一份好的甘特圖覺得能夠替專案管理帶來正向的幫助，絕不只是作為向sponsor報告的文書作業，而如何讓死板板的文件資料發揮其功效，其實最大的關鍵不在於撰寫的技巧，而是札實去完成每一件應做的專管任務，並對於每一件文件的目的有充分理解，才不會陷入枯燥行政作業的迴圈。

本文轉貼自：電影與生活中的管理學（原文連結）