專案管理_假的Lession Learn

在一般專案結束之後 , 也會進行 Lession Learn ,
看看可以學到些甚麼教訓(做錯的事) 或是經驗(作對的事) ,
不論要學到甚麼 , 都必須要誠實的面對問題 , 才能發現真正的問題所在


但是我要說的是在專案的過程中 , 就應該不斷的檢視與檢討 ,
而不是等到專案結束的時候才來進行Lession Learn...
當專案發生進度延宕 , 廠商一再提出相同的作法 , 而一延再延的時候
正確的作法應該是找出真正的問題所在 , 針對真正的問題所在去解決

但是因為在職場上 , 很多人不願意誠實的面對問題 ,
不願意面對問題 , 採用相同的錯誤作法 , 只會讓錯誤一再重複發生


當進度落後時 , 可以採行幾個方式去檢查 , 可能的問題所在
a.請廠商提出他們的專案成員組織文件 , 看一下 , 有多少人 ,角色為何 , 每個角色負責的工作為何 ,
  再去抽樣詢問廠商的專案成員 , 看看他們是否都知道自己所負責的角色為何?  應該負責的工作為何?
  實例: 曾經看過廠商的PM完全沒有這樣的文件紀錄 , 然後抽問廠商的專案成員 ,
            廠商的專案成員完全不知道自己要負責那項工作事項,
           
            在經過我直接詢問廠商PM寫下廠商的專案成員組織文件後 , 明顯的發現廠商的人力嚴重不足 ,
            廠商PM才開始進行人力的interview, 這個時候已經過了3個月

b.確認一下廠商的專案是否上下游可以銜接一致
  上下游可以銜接一致 , 舉例來說就是下游的所需要輸入就是上游的產出  , 如果下游需要 A 當作輸入 , 但是上游完全沒有產生 A 當作產出
 這時候你就可以確定廠商的上下游沒有銜接一致 ,
 沒有銜接一致會有甚麼問題?
 如果你的專案的許多區塊可以是完全獨立沒有關聯的 , 哪就沒有關係,
 但是你的專案想要平行開發許多區塊 , 但是又沒有先找出關鍵點(諸多區塊會相依使用的那個重點區塊 , 如果沒有先作 ,後續的區塊可能會有問題)


另外一個很重要的問題 , 當廠商的進度一延再延 , 完全沒有完成的產出時 ,

停下吧 , 千萬不要再跟廠商說: "你自己說 , 你自己排 WBS , 舖出一個可以做的到的時程"
如果廠商真的沒有問題 , 他自己怎麼會一延再延 , 東西出不來 ,


千萬不要這樣作 , 因為這樣不能解決問題 ,
應該請廠商提出他們對自己的狀態與問題的檢視與檢討 ,
如果廠商認為他們完全沒問題 , 那大概這個專案也差不多完了 ,
為什麼?
專案一定是有問題 , 才會一延再延 , 完全沒有產出 ,
但是廠商又認為自己沒問題 ,
沒問題的問題 , 才是最可怕的大問題 ,

廠商連自己錯在哪裡 , 哪裡有問題都弄不清楚 , 你說不可怕嗎?

在廠商沒有真正的認知到自己的問題出在哪裡之前 , 請千萬不要再叫廠商自己去舖 WBS 與排時程了
(如果他沒問題 , 又怎會修改了 n 版的 WBS 與時程 , 仍然沒有半點產出 , n 大於 10 )
(這種作法 , 用台語的俗諺說 , 叫: , 請鬼開藥單)


專案管理的課程中 , 有提到 Milestone , 我聽過的一種說法是 ,
Milestone 是 Kill Point ,
意思是每一個Milestone都會是用來審視與決定專案是否要Kill 或是繼續往下走的決定...


如果廠商不斷的延誤 , 連第一個 Milestone 都沒完成 , 已經過了專案預定的完成時間 , (意思就是 100% 延誤 ) , PM還決定要繼續給廠商機會的 , 那就有問題了....