Lesson learning

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)的時候,難免有時會有一些不同的觀點出現,甚至會出現衝突的情況。但這是好事,因為我們檢討的目的就是要從不同的觀點中,看到差異,在從差異中求取平衡與有效的解。

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

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

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

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