工作Delay，應該吸取什麼教訓？（一）

前序：

看標題，大家肯定一心想的是我們工作Delay了，應該吸取什麼教訓。但是今天要告訴大家的是一個由於客戶方的工作原因導致Delay了，我們應該怎麼辦？

這個CASE不是要告訴你誰的責任，而是想告訴大家，Delay了工作不可怕，可怕的是沒有去分析原因，並且改進，那麼下次還會因此Delay。

情境：

某周會上，專案經理談論到最近的工作，由於業主的業務部門負責人配合上的問題，導致需求不能及時和我方確認，我們已經將我們的理解以及對業務處理方法按業務線條進行規劃，並且將資料發送給負責人，但是負責人還沒有反饋。

你可以想象，業主的項目介面人肯定不會馬上承認，肯定要詢問我們什麼時候發送資料給負責人？我們回答了發送資料給負責人以及和項目介面人的時間後，介面人承認該業務負責人確實很忙，能力很強，所以連老總都直接給他派工，導致可能配合不上。

話音未完，接著馬上說：“為什麼你們提交給我們的資料還是Office2007的文檔，我們公司沒有購買2007，只能開啟2003的格式，上次我們已經要求你們給我們2003格式，”

思考一：

1. 給客戶提意見的時候，如何做好充分的準備，在介面人的領導在場的情況，使用者也會盡自己最大的努力給你提意見；
2. 雙方重要的郵件，我們除了郵件，是否應該有手段去確認對方已經收到並且可以開啟檔案，重要的郵件是否應該發完郵件去個電話呢？

情境延伸：

在告知業主可以免費開啟2007文檔，但是以後我們會按約定只提供2003格式的文檔後，我們又接著詢問按我們的理解，我們發送的資料需要負責人多少時間閱讀？專案經理告訴我們大約需要1個小時。

思考二：

1. 發送郵件時，提示使用者需要閱讀的時間，養成使用者閱讀資料的習慣，避免以後5分鐘的文檔使用者也以為需要閱讀1個小時，也沒有看；
2. 較長的文檔，能否通過導讀的方式指引使用者文檔觀看方法，以便讓他快速瞭解需要確認的地方；
3. 較長的文檔，能否將我們還存在疑問或者把握還不是很大的地方標識出來，以便使用者確認 ；

在我們提出我們自己的改進思路後，項目介面人的領導在場，接下來的那一步，不就是要求客戶也要給出改進嗎？

讀者，你會怎麼問客戶的領導？