許多推理/警匪劇中都會有這樣的橋段：目擊者向警方描述嫌犯的樣貌，旁邊的畫家先大致描繪粗略輪廓，然後目擊者會說出：眼睛要小一點，下巴要更尖一點，這裡有鬍渣等等訊息，畫家再逐步微調修正，最後完成一幅嫌疑犯的畫像！

多數人一輩子沒機會經歷這樣的場景，但「如何把大腦中的印象逐步具象化，再幫助他人理解」這樣的動作，我們倒是常常做！在公司裡我們會提出企劃案，讓老闆或客戶理解我們的做法；平常我們規劃旅遊，也知道要事先確認時間與國家，再逐步把旅館確定、景點確定，最後連每餐要吃甚麼、買甚麼也都一步步定下來。

上述這樣由粗略到細緻，由大框架到詳盡內容的漸進式過程，其實就是專案管理中「疊代」的意涵。（其實女生上妝也是一樣的過程，一層層疊上去，越疊越神奇呀！）

專案原本就是獨特性，一次性，原創性的產出，一開始就精準掌握全貌是非常困難的，所以且戰且走、逐步完善才比較合理。不少專案管理的初學者，因為學習到很多厲害的專案規畫知識（排程、資源、成本、要徑），就誤以為專案一開始得訂出一個縝密的計畫，隨後只要照表操課就成了！其實這並不符合真實的狀況。

「疊代」中有「重疊」也有「替代」，團隊一邊執行專案，一邊會發現新的狀況，也會獲得新的資訊，往往會發現原來的計畫不中用了，這時候最合理的反應，自然是重新制定更新更好的計畫。這個「新計劃」在時間與範疇上往往會跟原本計畫「重疊」，而且會被用來「替代」掉原本的舊計畫。就像剛剛提到的警方畫家，會不斷根據目擊者的情報修修改改，最終才成為通緝犯的畫像。

我們很難要求目擊者一次就把嫌疑犯的長相說清楚，很多時候他們得先看到畫家勾勒的「初稿」，才有辦法說出「眼睛再小一點、下巴再尖一點」這樣的建議。畢竟人腦無法像照相機能把腦中景象直接輸出。這也就是為什麼，很多主管或客戶沒辦法一開始講清楚他要甚麼，得等到員工提出初步的成果時，才要求改這兒改那兒，一大堆意見。我知道這對員工來說是一種折磨，但老實說也不能全怪老闆，誰叫人的大腦能力有限，而專案原本就是大家都沒做過的挑戰嘛！

所以對於有志從事專案工作的人來說，與其妄想主管客戶能一次把需求說清楚，不如鍛鍊自己「疊代的能力」還比較實際！這裡我可以分享兩個過去在工作上的經驗給各位參考。

1. 高鐵專案的雙周計畫表

年輕時參與台灣高鐵建設，是我第一次以正規的方法實踐專案管理，打下了不錯的基礎。其中印象很深的一段經驗，就是每周都要製作「雙周進度/規劃表」。

工程建設除了人力資金規模龐大外，現場的變數也不少。就算開工前團隊排了很詳細的時程表（例如我曾替高鐵台中車站工程製作前期計畫，列出了超過1萬個工作項目，夠詳細了吧？但其實還是不夠），真正動工仍會遇到奇奇怪怪的問題。例如當年有個工地，怪手到現場一挖，發現地底下有重要歷史遺跡，結果馬上停工請相關單位來調查，拖了好幾個月才繼續復工，當然後續所有工作都要重新安排，但這也是沒辦法的事。

所以在實務上，我們雖然會在開工前制定一個整體的時程計畫（稱作Master Schedule），但光靠這份大時程來執行絕對是不夠的。每周還是要針對現況擬定「雙周計畫表」。

這份雙周計畫表有甚麼內容呢？舉例來說，假設專案進行到第三周（W3）的第一天，「雙周計畫表」中會顯示上一周（W2）的實際進度，以及下兩周（W3、W4）的預計工作。所以事實上「雙周計畫表」其實橫跨至少三周（W2、W3、W4）的時間。以此類推，當專案進行到第四周時，雙周計畫表就會有W3的真實進度，以及W4和W5的預計工作，同樣涵蓋三周（W3、W4、W5）。這裡你會發現，W4的預計工作在第三周與第四周的時候都被計畫了一遍，通常第四周時所做的計畫會更嚴密，等於較新的W4計畫「疊加」並「取代」了較早的W4計畫，實踐了專案計畫的「疊代」。

我時常比喻做專案很像在黑夜裡開車，上路前我們有個大致上的目標與路線，但實際開車前方一片黑，唯有靠車頭燈照亮前方30-40米的路線，雖然無法照亮整條路，但還是能幫助我們抵達目的地！

2. 紐約市環保署的漸進式改善

這個例子則說明了我當時如何用「疊代」的觀念，幫紐約市環境保護署（NYCDEP）成功建立新的專案管理制度。

當時我面對的是一個極度欠缺專案管理的機構，我很清楚知道，如果想要一步到位讓他們導入所有的功能絕對會失敗收場。更關鍵的是，他們的高階主管花了大錢請我們顧問來，一定急著想看到成果。我必須盡快把初步的成效拿出來（縱使不完美），才有可能滿足客戶需求，後面的預算也才可能撥下來。

一個完整的專案控管流程，應該包含時間、資源、成本、品質與風險等等。但我們沒有那麼多時間，因此我說服了客戶，其他的先放一邊，先把所有專案的時程排出來，而且不排太細節的任務，僅針對每個專案的關鍵里程碑進行控管。

學過要徑的讀友應該會知道，正確控管里程碑的方法應該是從要徑計算出每個里程碑的計畫完成時間。但當時客戶甚麼資料都沒有，更別說要徑。因此我決定，只請各專案的專案經理用Excel表直接把每個里程碑的預估完成日期給我，沒有細節的任務、要徑都沒關係，先求有再說！

收集到所有里程碑的日期資料後，我把它們全部整合進一個大資料庫，同時將數百個專案，每個專案的里程碑進度做成報表秀給客戶看（共計上千個里程碑）。這雖然是Qicky and Dirty的方法，但紐約市環保署的主管非常開心，因為從未有人把單位裡所有的專案一覽無遺地呈現在他們面前，還能看出是否延誤，能在三個星期內做到這樣的成果他們非常滿意，後面當然繼續支持我們的案子了！

先馳得點後，我才帶領我的團隊，慢慢地把欠缺的資料補起來，這過程中，新建立的資料常常也會「疊加」或是「取代」上一階段建立的資料，但我發現客戶通常不會在意這些，他們只在意整個專案有沒有越來越透明，越來越準確。

後記

我回到台灣之後，曾有位客戶委託我幫他進行專案輔導，因為當時案子太多所以婉謝，他們於是雇用了一位外商背景的經理人來協助進行專案改善，並且要這位新的經理人來跟我請益。

在電話裡我跟這位經理人分享了我在紐約的經驗，建議他採用漸進式地「疊代」，千萬別想一步登天。但這位經理人十分不以為然，一直強調正確的專案管理就一定要兼顧時程、資源、成本，甚至要導入實獲值法（一種專案進度的量化法），如果只填個里程碑日期那老闆何必請他來呢？後來的發展果然不出所料，他花費了將近一年的時間，讓公司一群不懂專案管理的員工疲於奔命，最後老闆也失去耐心，因為一直沒有「看的到的成果」出現，這位經理人後來也就自請離職，相當可惜！

上面這個故事告訴我們兩件事情：當我們面對不確定的未來時，雖然「疊代」看似走一步算一步，少了一氣呵成的流暢感，但很有可能反到是最務實的方法；至於那位不願意疊代的經理人則時常提醒我，有時候用有效的方法，達成團隊最佳的結果，要比「刻意用絢麗的方式，證明自己很專業」來的更實際也更重要！