上次在 阿婆問路與天期預估的進階版 的最後提到，若你考量到人性的弱點後，你會發現無論是樂觀預估或是悲觀預估，專案最後產生延遲的狀況都不會改變。 所以我在文章最後丟出一個問題：「如果預估的樂觀與否跟專案能否順利完成沒有正相關，那作為一個PM到底該怎麼辦呢？」 :D

這篇就要來談談我的看法。

我不敢說我下面這觀點是100%正確，但這麼多年下來，我的經驗是：「專案的預估無論如何都只是一種參考。 事情沒有做之前，就算是找那領域最有經驗的人來預估，也只是某種【受過訓練的猜測】。」 換言之，既然是猜測就必然有不準之處，所以無論預估的當事人是樂觀還是悲觀，其實都不能把專案的成敗單純的壓在「預估正確」這件事情上。

雖然有一些人的見解是覺得，如果預估不準確，我們就應該提升準確率。 可是我的觀點是，提升準確率就跟預估明天的天氣一樣有其極限，而且通常必須來自於長期的經驗與歷史資料的統計。 如果一個公司從來沒有做過類似的事情，也從來沒有留存歷史資料的話，那一開始要預估準確不就無解了？ 總不可能所有想做專案的團隊，先得去累積30年的工作經驗吧…

此外，預估準確與否跟有沒有辦法把專案好好帶完，也未必有這麼高的正相關。 當然預估準確率若高，對於PM來說確實輕鬆很多。 可是預估準確率不高時，其實也還是有辦法逐步精進。

我這麼多年覺得最好用的方法，就是專案的負責人，應該要在專案開始前，花時間把整個專案工期展開，以完成一份包含【範疇】+【工作與時間】+ 【資源需求】的Schedule。 雖然這無法解決預估不準確的問題，可是可以從另一個層面來解決【時程衝突】、【範疇變更】、【工作進度落差】、【資源狀況變動】、以及【預估差異】等等的問題。

可是，怎麼叫做「從另一個層面」來解決呢？ 意思是說，我們不要鑽牛角尖在個別工作的預估正確度，而可以拉高層級從整體層面來平衡單一工作的影響。

因為預估既然都有主觀性，一個專案也必然涉及很多人並做很多工作，除非公司有著非常偏頗的KPI，不然樂觀以及悲觀某種程度很多時候是相互抵銷的。 而且專案成敗的重點通常也不在於單一工作的時間，而在於【總時間的互相關聯】。

所以當你若能把所有工作、工作的順序、工作的時間預估都以一個視覺的方式呈現出來，所有的利害關係人就都能看到【整個專案全貌】。

但為何要看整個專案全貌呢？ 在於你能清楚地呈現專案全貌時，彼此協調較容易。 舉例而言，老闆總共只給你三個月的專案期程。 你問了各分工部門各自的工作預估下，大家都說他的工作很難各要20天。 結果頭尾連結接續起來，你發現這專案根本需要9個月才做得完。 你若讓技術人員個別工作跟你談，你可能根本別想做任何調整。 可是若你開個會，把相關人員都找來(包含老闆)，把時程打出來給大家看，請大家一起協調怎麼調整9個月的專案期程，也就能直接把討論的層次拉高，而不用在每個工作上個別打混仗了。

(上圖，簡單的專案網圖。 紅色是要徑，要縮短專案時間，就優先討論這些工作的時間是否合理。)

這時候常常技術人員之間就會開始大喊：「這種難度的專案怎麼可能需要九個月？ 如果全部都我來做的話，只需要2個月耶。 啊，你看看，那個A部門預估太誇張了啦。 明明那個XX工作可以同時併行啊，為何不多派一組人來做？」 如果真的時間需要這麼誇張，大家都在一起時也可以視覺化的解釋給老闆聽，為何九個月才是最合理的。 總之，把大家邀在一起，並給予一個可以清楚看到全貌的時程，這樣討論才能聚焦。

以上是面對普遍悲觀時，我通常選擇的作法。

(上圖，超過上萬筆工作的專案網圖。 我們常常有機會參與這種極度複雜的專案。 可是當工作數量超過幾千筆時，你要一個一個找人協調，或是期待每個工作都預估正確，這是幾乎不可能的事情。 所以作為一個PM，更需要在開案前就把全貌展開來給所有相關人員看到。)

可是，若大家都很樂觀呢？

明明你覺得大家開出來的時間怎麼短的讓人吃驚？ 但你跟技術人員再三確認，大家卻都堅稱這是對的。 這時候又該怎麼辦呢？ 你去質疑別人，別人覺得你技術沒他懂、想法負面、你也沒辦法證明別人的預估太樂觀，這時候吵鬧除了徒增爭議外，沒甚麼好處。 可是你若不處理，後面問題一直爆，大家都攤攤手說「一堆沒預期到的問題發生了」。 當事人或許可以推罪，可是作為PM往往還是跑不掉。

我的做法會是，一樣要先把大家的預估都問來，然後也一樣把整個專案期程展開，把完整的Schedule排出來。 如果規劃能排到專案的【需完期限】內，那就先跟各方確認，並把這時間劃定成【專案的Baseline】。

再來，等專案正式進行時，我會定期收集各工作的【實際進度】(包含工作開始完成日，以及資源投入量)，把這些都呈現在Schedule上以便跟預估比對。

(上圖。 甘特圖上的藍線是進度線，下方的欄位是工作中三個人員的預計及實際投入狀況。 Budgeted Units是原來預估的工時；Actual Units是實際的工時。 收集這些，就可以透過EVM的方式來幫我推算後續的趨勢)

假設每週跟新進度一次，那只需要三到四週的時間，專案的【趨勢】就會很清楚地呈現。

舉例而言，若某個部門的預估在專案開始後，其中80%的工作透入量都跟預估差很多(實際「人日」都比預估的「人日」高的多)，那很明顯就是一開始的預估偏樂觀。

偏樂觀也沒問題，只是後面的預估作為PM大概就不能指望，就得做些【保守的折算】。 如果大家有讀過PMBOK(或考過PMP)，應該會記得Earned Value的章節中有介紹CPI以及EAV的公式不是嗎？ 老師應該都有教EAC(Estimate at Completion)怎麼算吧？ (提示 : 公式是 : AC + (BAC-EV)/CPI )

只是老師有解釋為何要用CPI來當分母嗎？ 很多老師只是教你背起來吧？ 但實際上CPI代表的就是【效率的落差】(有興趣的，我這議題可以另外寫一篇)。 所以透過CPI來調整，就能拿目前的實際投入來推估後面還有多慘。 雖然還是不可能100%精準，但隨著時間推進、隨著工作面逐漸展開，收集來的資料都會讓後面的預估有更高的參考基準！ 就算其他人還是樂觀以對，但你手上已經有另一份劇本了….

(上圖，透過EV、及AC來推估專案後續的人力投入狀況。 橘色是預估完成時的人力投入狀況。 必要時也可以顯示原始預估，來呈現兩條線的差異。)

所以，當你能有一份完整的Schedule，基本上你已經準備好來對抗別人樂觀以及悲觀的預估了。 此外，有一份完整的Schedule，你也能以此有系統的累積「歷史資料」。 雖然歷史資料對未來還是沒辦法起到百分之百的預估效力，但最少隨著手上資料越來越多，你也越有機會跟技術者討論時程。 無論是提醒風險，是質疑過度保守的預估，都能從這邊作為起點。

此外，有歷史資料以及完整的排程在手上，你也可以有系統的學習，可以透過手上資料避免其他成員的疏漏，更可以讓自己在討論時更聚焦。 我覺得這是一個PM，絕對不能輕忽的馬步，也是好壞PM很大的一個做事差異。

後記

做過幾年專案的人都知道，預估唯有到工作做完那天，才是100%肯定的。 所以做為一個PM，不要把專案成敗完全壓在別人的預估上。

我碰過一些PM或是老闆，會認為「既然你說了，你就是必得做到」。 但這認知除了造成恐怖氣氛外，反而容易讓成員不願意【在過程中反應問題】。 雖然小誤差可以逼著他們加班吞下，可是大問題若無法提早知道，等最後爆出來後，受傷的往往也還是管理者(包含老闆自己)。

所以，一個好的PM(以及主管)，其實應該花很多時間「視覺化整個專案變動」。 如此，才能知道在甚麼地方可以輕鬆以對，在甚麼地方得趕快採取行動。 進對迴旋都有依據，那才能事半功倍的好好把時間與心力都放在對的議題上。