Mar. 18, 2020

好的開始是成功的一半，好的結束才是成功的全部

        專案的結案管理既然如此的重要，很多人也意識到了，但實施的結果，卻是一場無奈的大拜拜而已。在大家都忙碌的時候，這樣的活動很容易讓成員產生應付與逃避的想法，對於Lesson learning根本起不了任何作用，反而浪費更多的資源做一些沒有用的文書工作。那要如何結案，才不至於變成一場拜拜式的形式化活動呢？今天就以本篇文章作系列的終結。

        首先公司應該把結案管理列入程序中，做為一個正式的專案活動，而非額外的工作。一般常把此部分列為額外的工作，一旦碰到一些瑣事，自然被犧牲的就是此一部份。

        其次要確定這個活動結束後會有那些的產出(Why & Whar)，因為這個部分越明確的話，目的就越清楚與同仁的認同感也越高。最重要的是不會天馬行空，不知所云。

        再來就是要如何進行(How to)。一個好的結案檢討，必須有很充分的數據與準備，更需要有嚴密的管理程序，才不致於做虛功。所以會議的程序必須明確。

        當然如何撰寫結案報告也關係著結案審查的品質，能夠寫出Know How而不只是一個行事曆，點出有價值的資訊與學習的重點，是追求的目標。此部分做得好將會成為一份專案文檔(Project Profile)，屬於技術情報管理的一環，應該妥善管理之。

        最後是實施過成程的控管與細節。其中包拓時間的安排(長度與時機)、與會人員、主持人、會議場所、會議議程、結論整理與資料彙總與管理。

        今天我們就花點時間仔細的把此部分談個清楚。

        專案的結案時機：首先，專案結案的時間應該安排在何時實施、要花多少時間來比較洽當、地點選在哪裡比較好等等，都是第一個面臨的問題。看似容易，其實不好搞。

        時機：一般專案何時結束，幾乎都沒有一個很明確的節點。專案成員到了專案的後期，幾乎都只有待命應召而已，根本不會花時間為專案多做一點貢獻。這是多專案管理很普遍的現像，絕對不要把成員的此種行為指為不負責任或是本位等等。如果公司沒有一個明確的專案管理規程，一般結案時機是很模糊的，此時專案經理人必須就整個進度的進展狀況，決定一個時點，提前通知利害關係人，(最主要的是專案委託者)，以便騰出時間來參與專案的結案。選擇的時機最好在專案的時程都走完後的一到兩個星期後舉行。給一點時間讓成員整理專案的結案報告，但也不要拖太長，因為夜長夢多，況且很多的數據拖久了後會遺失。再說成員不是沒事只做你的專案，如果手頭上還有專案在跑，這點時間恐怕是不可避免。

        時間：一個普通的專案或許一天就夠了，但如果規模比較大、或是產品開發專案，牽涉到層面比較廣的話，個人建議最好準備兩天的時間。很多人會說好忙，根本騰不出時間，這就看公司對專案結案的重視程度而定，無法一概而論。兩天的目的是要讓Lesson learning能夠落實，沒有足夠的時間會像是在報告一些過程一樣，船過水無痕，那就可惜了。一個半年或是一年的專案，騰不出兩天來是說不過去的，因為這兩天可能為企業未來的專案省下兩個月的工時也說不定。至於經營層很忙的話，可以在結論的第二天參加就可以了。

        地點：個人的經驗與建議是拉到外面，不要在公司裡頭。原因很簡單，會受到業務的干擾，而且那是無可避免的。再說利用結案的機會，把成員帶到一個山明水秀的地方，某種程度是可以舒緩專案過程中帶來的壓力與怨氣，是最好的沉澱機會。如果公司預算許可(建議專案經理人在專案規劃時就把這筆預算編進去)的話，甚至找個休閒區或是到海外去一趟都值得。

        會議室安排：專案的結案報告要分幾段進行，其中有討論、有腦力激盪以及報告的部分，所以在會議室的安排上也必須有點考量。在小組討論的時候，以圓桌會議的方式，讓每個人都能互相看到每一個人的臉孔為佳。如果專案進行過程，有很多的衝突發生過，那空間或許加大些會比較好。至於最後總結報告的時候，能夠以U字行的安排，讓主持人(專案委託者)與利害關係人都能與專案成員面對著面的報告，是一種關心與尊重的表現。每個成員在前面做簡報，應該事先都有一些書面資料的準備，比較能夠讓參與者充分理解內容。

        會議程序與主持人：要讓Review會有效的話，會議主持人以一個中間立場的人來負責的話，會有意想不到的效果。主持人要負責幾點程序的控制任務，主要為：

        1. 確保檢討會的內容不離題

        2. 確保會議裡沒有人身攻擊的衝突情事(讓批評或是檢討具有建設性)

        3. 確保計畫的項目都能確實涵蓋進去

        4. 讓專案成員都能平等與均等的參與討論

        5. 有效的控制時間與進度

        會議記錄：要讓結案的東西產生效益，會議記錄是讓資訊透明化、情報共享的一個重要手段。可以用一點顏色管理或是符號來加深討論的活潑。

        接下來的重點就是要討論的與報告的內容，這部分才是主角。

        要讓結案報告有生命，並能成為企業的無形資產，先決條件是Review report的撰寫技巧。一個好的Project report，除了業務結果報告外，最重要的是這個過程中碰到了哪些問題，這些問題一定有好的、與不好的。好的問題發生的時候到底是甚麼原因帶來的，這些原因能不能成為企業內部的一些參考準則，以收標竿學習之效；至於不好的地方，絕對有很多系統上、管理上或是人為上還有改善的部分，這些元素如果能夠找出來，列入到專案管理辦法裡面，往後的類似問題就可以大幅度的減少，那才是Review的真正意義。否則如果只要盡行進度報告，那根本不需要浪費時間，只要由PM把報告整理好，向層峰做個書面報告不就得了。Review的意義是讓每個人透過檢討來沉澱，從沉澱的過程，提出每個人的一些經驗作為知識分享的平台，讓企業的知識庫形成一個持續改善與再發防止的寶庫。

        要達到此一目的，報告的內容就必須有點要求，否則很容易流於形式。專案的結案報告內容到底要涵蓋哪些東西呢？要如何報告才會有效？接下來就來談談此一部分。

        專案結案報告的內涵必須涵蓋幾個部分，簡單說明如下：

        1. 專案的時程與資源的運用情形檢討：此部分包括日程表的實際執行狀況、資源的需求評估、資源分配、資源運用狀況，最重要的是從與目標的差異資訊中，檢討差異的原因與當時處理的方法。檢討充分的話，可以從差異分析中看到很多計畫中或是執行面的一些待改善部分，這些都是未來專案執行上的可貴改善素材。要掌握差異分析的要領，最簡單的方法就是把目標值與實績不吻合的項目，全部列出來，再個別的分析原因。

          原因分析如果沒有掌握要領，很容易出現把一些現象當原因的情況發生，譬如說：常會看到資源不足、技術能力不足、或是目標定義不清楚等等的原因出現，其實這些都不是原因，這些只能算是現象而已，掌握這些現象是無濟於事的，因為這些現象無法就此下對策。

        要從現像找出要因，可以用五個Why原則來探討。如：目標為何(Why1？)無法確定？因為專案需求沒有討論清楚；那為何(Why2？)需求無法討論清楚？對專案的認知不足：為何(Why3？)高層對專案的認知不足？經驗法則讓高層忽略程序的意義；當問到第三個Why的時候，各位應該可以看到，原因已慢慢浮現。以第三個Why？問出來的結果，絕對比現象更接近事實的問題核心，此時再來談改善對策，就更接近有效的問題解決階段。也就是當檢討後，針對此一現象，提出建立一個專案管理程序，才是對下個專案有用的建議，否則只是看到一些打高空的東西，要不就是一些虛晃一招、徒呼無奈的口頭檢討，對專案的成長是沒有任何幫助的。

        2. 檢討分析：把一些做得好與做得不夠好的部分抽出，進行深度分析。做得好的部分或許比較容易上手，但也不要太大意，否則弄到最後，只看到一些報喜不報憂的報告，那就可惜了。

        3. 檢討分析的時候，切記不要讓成員感覺到好像要秋後算帳，那就大事不妙了，因為當成員認為檢討會影響考績時，很多的東西就出不來了，此點要特別小心。

        也有很多的管理者總認為做得好的就不用強調，把做得不好的部分拿出來檢討才是重點。這種觀念似是而非，而且對專案管理會有不好的後遺症。第一，平白喪失了很多經驗傳承與標竿學習的機會；第二，平白丟掉一個讓成員自我激勵的機會；第三，管理的環境只看到黑暗的一面，不利於建構一個積極、開朗的組織文化。

        讓成員把做得好的部分，深入剖析為何做得好，有助於成功經驗的沉澱與自我激勵。每件事情做得好，必定有一些條件與內涵，把這些條件與內涵整理出來，可以作為一個企業新人或是後進很好的工作指引(Job Guide)。如果不談論此一部分，那不就是浪費了寶貴的經驗學習了嗎？所以此部分也是重要的一環。

        其次比較不好做的部分應該是做得不夠好的部分。此部分在分析時，受到秋後算帳或是面子哲學等等因素的干擾，會讓成員無法深入且平心靜氣的進行剖析。更因為很多的問題不見得都是出現在功能專業上，界面問題相對得更常見於問題的本身，所以很容易流入他責的檢討，而讓自己輕易的拖身，這是最需要避免的事情。如果檢討報告都只看到他責的問題，那這份報告的意義大致上都消失了，因為報告內容大概只會看到攻擊與卸責的文字，對Lesson learning是沒有任何的意義的。

        此部分在檢討的過程，可以依循三個步驟來整理問題，依序是問題出在哪裡？是什麼原因造成的？當時有那些警告訊息出現？把這些問題釐清後，再談談未來要避免類似問題發生，該如何做？

        整理這些問題也有很多方法可以運用，一般最常見的就是腦力激盪法、KJ法與心智圖法(Mind Map)。要讓檢討會有效的發揮，事前的準備工作也是必要的，所以檢討報告給於一到兩周的準備期也就是這樣的用意。

        在整理專案過程做得好(Good point)與做得不夠好(No Good point)的時候，難免有時會有一些不同的觀點出現，甚至會出現衝突的情況。但這是好事，因為我們檢討的目的就是要從不同的觀點中，看到差異，在從差異中求取平衡與有效的解。

        專案結案報告雖然重要，但看到很多的人都在結案報告完了後，就把報告當作文件歸檔了事，再也見不到天日了。如果這種情形出現在貴公司裡，那會讓同仁感覺到就是一場拜拜，以後再也不會用心的去整理報告。再說好不容易整理出來的一些可以改善與借鏡的經驗，也就束之高閣了，平白喪失了經驗傳承的機會。

        要避免這樣的情事發生，就必須有跟催與行動方案，把結案報告的記錄轉化成為行動方案，分門別類加以管理，讓知識加值，形成一套技術情報管理(知識管理)的寶庫。對於有立即可用的部分，可以透過專案事務局的整理，直接給於後來的專案參考，融入專案計畫中；對於必須動到規程或是組織運作的部分，也必須有一些行動方案出現，才可能發揮效果。所以報告完後，專案歸建，經驗傳承與改善才剛開始。

        整個專案到此做一個終結，經營者該在結束後給成員一個獎賞，好好大喝、大唱、開一個慶功宴。

        整個專案管理的文章總算告一個段落，接下去要談什麼主題？還在醞釀中，各位看官如果有好的建議，請不吝賜教。謝謝！