Manage project knowledge effectively and no longer worry about staff turnover or retirement waves!
知識管理（KM, knowledge management）是近幾年很夯的話題，許多企業積極推動知識管理背後的動機，主要是為專案經驗傳承與永續發展，對於面臨退休潮的企業或是人力異動頻繁的組織，如何把前人的經驗留下並讓後人無縫接軌，始終是一大挑戰。而專案都有結束的時候，不知大家都是怎麼保存專案的知識資產呢？
這幾年輔導不少企業進行研發專案管理，但發現會做的不會說、會說的不願意寫，這樣的情形比比皆是，造成企業內部知識管理無法落實。也許有人會說，我們有文件啊，我們都會寫結案報告作為組織流程資產。沒錯，結案報告當然要寫，而且越詳實越好，但好不容易經歷辛苦的專案奮戰，不少人最後就抱著「能過關」的低標心態在寫結案報告，遑論鉅細靡遺地紀錄專案過程的大小事了。
專案文件，例如計畫書、進度報告、各項交付物、以及結案報告等等，這些原本就會做，而且也會經過相關審核，所以大多數人會將這些文件納入知識庫（文件庫），這也是最容易做到的，但請大家也要思考或是回顧一下，這些文件的再利用率有多高呢？畢竟只收不用，也是一種資源的浪費。
但除了專案文件以外，個人認為最能具體呈現專案歷程也最能反應專案經驗的知識資產有兩類：
第一類是問題清單(Issue Log)
如果每件事都只需要照著計畫書按表操課，那專案成功率應該要很高才對，但為何總是聽到數不盡的專案苦水呢？就是因為突發狀況太多了，所以對於問題、異常或例外的處理能力，才能夠充分展現一個專案團隊的實力。而這些問題、異常或例外的紀錄就是Issue Log。Issue Log有兩個用途，一是追蹤列管(Tracking)、二是追溯省思(Tracing)，追蹤列管顧名思義，就是追蹤每個問題的處理情形，以確保它有被及時妥善地處理，而追溯省思則是記錄每個問題的來龍去脈，找出真正問題發生的原因並避免日後再發。所以Issue Log絕對不能只是押個日期或記個狀態而已，而要能充分滿足上述兩個功能，這樣當日後其他專案遇到問題時，歷史專案的Issue Log才能有所助益。
第二類則是通聯過程
試想航空器為什麼有黑盒子，而黑盒子又紀錄了些什麼？同樣的，一個專案的通聯過程，可以幫助我們抽絲剝繭地找出這個專案從開始到結束，中間到底發生過什麼事、又是怎麼處理的。所以如果說專案的最大知識庫，其實就是LINE的聊天紀錄跟所有的email，大家也就無須訝異了。但LINE聊天紀錄實在太多太雜了，所以一般而言，重要的事情不會只在LINE說說而已，後續正式一點的就會再發個文，而非正式一點的則會補個email。問題來了，email的寄件者與收件者可以是專案的任何人，那要怎麼把每個人的信箱彙整起來變成一個整合的大知識庫呢？要做好這件事就有賴專案成員平常做資料整理與記錄的工作習慣，否則相信事後整理是誰都不想去碰的，更不用說要從何存取專案成員的個人信箱了。
十多年前我自創了一個名詞PKM (Project Knowledge Management)，希望大家不要為PM而PM或是為KM而KM，在平常做專案管理(PM)的同時，就「順道」把知識管理(KM)做好，這樣不僅省事，也才是PKM的真諦。最重要的是能夠將專案的寶貴經驗完整且有效地傳承下去。
近期文章
