還有一個體會和大家分享：千萬不要覺得對方的領導（中層幹部）是應該配合你工作的，特別是一些國營單位，多一事不如少一事，他幹嗎要幫你？我的經驗是：對方領導如果沒有拿你的事情作為內部鬥爭的武器而從中作梗（當然，他針對的不一定是你），那已經是算合作的了，記住，他不搗亂就是幫你忙了。
作為項目經理，其實腦子裡就是幾樣東西：做哪些事情、做到什麼程度、怎么交貨、手上的資源以及各個事情的優先權。所謂多快好省那是人類的夢想，這四個方面都是相互矛盾的，屬於典型的又要馬兒跑，又要馬兒不吃草的類型。一般說來，項目經理在考慮問題的輕重緩急方面，往往是把快放在第一位，各方領導都會給你最後期限，所以保進度是第一位的；省是第二位的，企業的根本目的是盈利，如果收入不能增加的話，至少費用要控制住；好是第三位的，沒辦法，誰都想精益求精，但是，沒有強大的資源保障，質量只好先犧牲了；最後是多，客戶的要求源源不斷，如何降低客戶的期望值，把項目控制在一個合適的範圍內，讓客戶從理想回到現實也是項目經理的分內工作。
驗收前，除了做好文檔工作，即可交付成果以外，多花時間搞清楚客戶的做事情流程是很重要的事情，一個公司做事情必定有流程，所以搞清楚流程十分關鍵。比如驗收、付款這些你極其關心的事情，客戶那邊的流程是怎么樣的，誰牽頭組織、哪些人參加，要什麼檔案、走什麼程式、哪些人簽字、最後出什麼文檔等等，都要搞清楚，特別要事先分析和打聽哪個環節容易卡殼，做好事先的準備。
我對驗收最大的體會就是舉證問題。即千萬不要讓客戶這么想：你必須有證據證明你的系統是沒問題的。這樣你就沒戲了，微軟那么多天才，做了個windows還天天打補丁，要你的程式沒問題，既不可能，你也沒辦法拿出證據。你要讓客戶明白，所謂驗收，就是我按照測試文檔的測試用例跑一遍，結果和預期結果一致就應該算通過了，而且還容許有一些小錯誤留在驗收後改正，他可以對測試用例提意見。所以，驗收前雙方要確認測試計畫和測試用例。如果他認為系統不符合要求，那么他應該舉證，證明這個系統和最初設計相背離的。所以，參考法律概念，千萬不要舉證倒置。另外，認為系統完美了才能驗收的想法也是錯誤的，軟體開發契約里一定要註明驗收以後維護期的費用問題，否則，客戶擔心一旦驗收就得不到你們的支持，自然不配合驗收，那么，你這個項目經理就很難交功課了。
最後，我想談談如何評價項目經理的績效的問題，我認為，項目經理有以下幾個檔次：
*最差的項目經理：項目過程中總是出現意外，然後自己又解決不了，結果成為烈士；
*二流的項目經理：項目也經常出現意外，但是他一馬當先，奮勇向前，解決了一個又一個問題，最後，勉強算把項目結束了，獲得了領導的一致好評；
*一流的項目經理：平時很少見他做具體的事情，整天找人聊天，然後就是寫報告、做計畫，最後項目順利結束，整個過程平淡無奇；
項目管理到底是一門科學還是一門藝術呢？所謂科學就是經過反覆論證，輸入和輸出有必然規律的東西，種瓜得瓜；而藝術就是思想火花的閃耀，主要靠靈感。項目管理這個東西，據一個前輩說，在國外是科學，80%是有規律可循的；在國內是藝術，主要靠個人魅力、感染能力等東西。看明白了pmbok，學會了一些做事情的方式，只是搞懂了那個20%的科學的東西，還有80%的空間，屬於見仁見智的領域了。所以，加強很多方面的個人能力，如練就出色溝通能力、提升自己的個人魅力對於項目經理來說是多么重要啊，無論是對內還是對外。作為一個一流的專業人士，在順利讓客戶簽字的同時，如何讓自己的領導知道你的價值，這也是體現自己能力的一種途徑。