場景：

自公司成立以來，以往由業主方召開的專案初驗會議，都未發生過專案初驗上出現問題。我一直認為，中國人的從眾心理一般都挺嚴重的，加上我們對專案質量的認識以及對專案管理的重視，就沒有碰過一回結論為：初驗不通過的初驗會。

這次，這樣的事情都給我趕上了，剛聽到部門經理Z講的時候，我都覺得有點不可思議！你能理解嗎？因為會議之前，同事Z告訴我他得參加專案S初驗會，我還非常堅定地告訴他沒有什麼必要，既然現在有專案經理P在管理專案，就讓P去全權負責初驗會議，我當時還對Z說，我和你打賭，你去不去初驗結果都一樣是通過。

分析：

事實的結果給我們來個當頭棒喝，至少看來我前面的判斷太過自負了，而且還犯了經驗主義的錯誤

1. 我方初驗會議的準備工作不足，前面存在資料質量的問題，也由於我們的Bug，導致初驗會議上，C部門提出問題嚴重；而這個Bug的修訂，由於我方在之前進行修復時對Bug進行Impact Analyze時，發生遺漏，導致修復了一個地方，遺漏修復另一個地方；
2. 與介面方專案經理W的溝通、準備不足，本來以往有Bug，做為初驗的整改項進行後續的修復則可，沒有想到介面方詢問C部門意見時，問能否驗收，C部門說那不行，如果W問能否做為整改項，可能就驗收了！

我瞭解後，我將我的觀點告訴Z，

1. 我們不要埋怨介面方專案經理W，他這樣詢問確實是正確的，也是符合規定的。我經歷的專案驗收會，組織方是要分兩次詢問，第一次是詢問是否可以驗收，第二次才是詢問還有什麼遺漏問題
   ，這才是慣例；
2. 從我們自身去找原因，才能將壞事情變成好事情；這是教育我們部門、專案組，包括我的好機會，請專案經理P和成員好好自我分析，將分析情況、經驗給大家通報，不是批評，而是讓整個部門從中學習；
3. 我們同事容易在工作中只看到業主方的IT介面人，而忽視了整個系統的所有相關干係部門。這種情況應該是事實，試想一下，在從眾心理嚴重的中國社會，這麼多部門的代表一起開會討論，要站出來反對，本來就是一個需要勇氣的，要不我們前面確實太忽略了該部門的利益，要不就是我們就是在前面的服務過程中得罪了該部門，這個需要P和專案組他們好好細緻分析一下；
4. 從前段時間系統投產以來，專案經理P發出的每日系統監控報告看，確實我們沒有收到這樣的預警，在說明問題的時候，很多時候是報告其他系統的資料質量導致問題，並沒有提及我們Bug導致的影響
   ，從這個角度上講，也是一個報喜不報憂的假象，混淆了管理者的判斷的同時，也可能給相關部門的代表人帶來誤解：明明系統的問題你們都不說；
5. 我在前面的培訓過是有講過，一個IT系統要有生命力，一定是要照顧到IT系統的所有使用群落，一個系統如果只考慮到管理者的利益，而忽略操作者的利益，這樣的系統即使領導說好，也很難長久！這是一個活生生的案例教程；

要將這種意識在部門和專案組中加強再教育，專案管理崗位的同事，本來就需要具備平衡多個合作方、各個崗位、各個角色的能力；需求和顧問崗位的同事，更是需要直面這樣的挑戰下，進行使用者引導；技術崗位的同事，對這樣的問題認識也是比較有限的，對一線操作人員的便利性考慮少，特別是這種BI的專案，總覺得讓一線再多添點領導需要的資料並不算是什麼問題，都需要好好反思。

各位同事，我們做過挺多IT系統，雖然沒有一個是失敗的，但是我們必須肯定，有不少IT系統曾經曇花一現。公司想成為一個百年老店，我們想做為一個成功的諮詢方、設計者、建設者，想多年後還能自豪地告訴你的同事、客戶、下屬：“這個系統我多年前參與，到現在還在投產使用”，那麼這個一個案例不就值得我們細緻分析和分享嗎！