資訊完整度與決策有效性

資訊完整度太低，一直是過去在 P 公司不斷發生的問題。由於資訊不足，導致大部分的決策都像是在瞎子摸象的情況下作出來的。剛好有某人說問題的發生原因可能是 A，大家就朝 A 方向解決，過了一陣子發現沒什麼用，就再猜一個原因 B，所有人就再朝 B 方向努力。通常最後的結果是，所有能猜的原因都猜得差不多了，但問題還是沒解決，大家也師老兵疲，連再繼續猜的力氣都沒了。這個現象恐怖的地方在於：解決問題通常不是一個人解決，而是一組人解決，要凝聚一組人的力量本來就不容易，但要破壞一組人的信心卻是簡單的不得了，只要當中一有人信心動搖，就會像病毒擴散一樣，一發不可收拾。所以，不作決策則已，一但作了決策，就要一舉中的。春秋時代曹劌論戰所說，一鼓作氣，再而衰，三而竭，就是這個道理。
在前幾篇文章中 (這一篇和這一篇) 有提到 C 公司現在遇到的最大問題或是最需要解決的問題是技術部門的結案速度大幅下降，我也已把解決這個問題當成是目前最重要的工作項目。但問題是，該如何解決？或者問，造成這個問題的原因是什麼？我們總得先知道問題的本質，才好找解決方法。經過三天的訪談，聽到的原因很多，例如，客戶會要求工程變更、客戶會對工程師作不合理的要求、硬體採購會延遲交貨、外包商的進度延遲、以及工程師的技術能力不足等等，但如果仔細問，那到底哪一種原因發生的頻率最頻繁？或是哪一種影響對交期的衝擊最大？麻煩了，沒人有把握。因為小公司的資源有限，不可能同時對每個可能原因都投入資源，因此，回答上述兩個問題，就變成一個很重要的工作。
為了回答這兩個問題，例行性的資訊蒐集就變得是必要的工作，唯有在資訊被完整蒐集的情況之下，我們才有可能進行統計與分析，找出問題的本質，並加以解決之。那要如何讓技術專案部門的夥伴們能夠做到例行性的資訊蒐集工作呢？答案就是專案日報及定期的專案日報檢討會議。專案負責人填寫日報，再由一專案管理者統一將各式問題通報給各相關負責負責解決的夥伴們知道，另外，專案管理者亦須負責整理並分析數據，找出導致專案結案速度不夠快的原因，並協助技術夥伴們解決。然後，在專案日報檢討會議上，專案管理的負責人可提出各式統計數據，讓專案負責人了解問題所在，並集思廣益共同找出解決方案。
由於最初的發想是為了要找出結案速度不夠快的原因，因此這份日報的設計最好就只要能夠讓夥伴們提出每天遇到的問題即可，其他的資訊蒐集就不用急著作，而且在設計上必須讓夥伴們容易填寫，不會增加太多的工作負擔，等到大家都習慣了填寫日報，再考慮置入其他資訊蒐集項目。
當然，請專案工程師寫日報不單單只為了蒐集資訊、找出問題，還會有一些其他衍伸出來的好處。例如，所有問題的解決者分派都可以在最短的時間內處理完，這個時間就是一天。另外，某些問題或許會造成交期上的延誤，公司有責任在最短時間內告知客戶，這個時間也是一天。另外，如果某些問題不是專案執行者本身可以掌控的，而且有可能會讓後續的專案工作無法執行，專案管理者也可以立即決定是不是要安排其他的專案工作來填補這段空下來的時間。
執行了專案日報是不是就可以保證結案速度可以提升，答案是不確定。但有一點可以確定的是，如果這件事不作，要讓結案速度提升，要嘛很難，要嘛就是要投入大規模資源才有可能做到。