項目的實施工作，何以謂之成功？由于軟件產品的特殊性，決定了這種項目的成功標準是很難被量化的，驗收缺少清晰的數字指標。對于客戶而言，在一個合同里面獲得最大的管理價值，包含最廣泛的業務應用，是他們對成功的看法；而在供應商眼里，項目就是項目，早日驗收早日回款，是他們追求的目標。雙方立場的差異，導致項目在進行中會出現各種情況影響到項目的驗收。如何減少分歧，按期完成項目，就成為了項目組最大的挑戰。

    一般來說，我認為項目的實施需要遵照以下方針：加強溝通，精細計劃，全力推行，利用資源，隨機應變。

    怎么解釋呢？“加強溝通”，溝通是應該占據項目組成員最多時間的工作。他們不光要跟客戶溝通，還要跟后方的銷售人員、開發人員、測試人員多交流，以及包括了項目組內部的信息交換。實施人員應該是信息的中轉和匯總的樞紐，獲得的信息量越大，項目現狀就越透明，對后續工作的把握就越大。PMBOK中提到，一個項目經理有90％的時間都是在溝通上，可見這項工作的重要性。
“精細計劃”，這個需要考驗PM的功力。一個合理的計劃，是項目能夠成功的先決條件。PM要最大化了解項目的相關信息，包括資源、風險、客戶特點等等，然后制定出一個適合項目特征，甲乙雙方都有能力去實施的計劃，并界定出項目邊界和里程碑。從這一刻起，就要為項目的最終驗收開始努力。

    “全力推行”，指的是項目小組成員要明確以驗收為中心，計劃是準繩的目標，想方設法去按照計劃推動項目的開展。這個過程中肯定會出現各種各樣的狀況，也是項目最復雜，頭緒最亂的時候。運用各種手段，來全力保障計劃的按期執行甚至提前進行，是項目組所有成員的職責。

    “利用資源”，資源是什么？只要一切有利于項目推進，有利于最終驗收的人、財、物，甚至氣候、政治動態等等，都是資源。例如說甲乙雙方的高層領導是資源，一臺大內存的測試PC是資源，哪怕即將來臨的雨季也是資源。項目經理要善于考慮可以利用的資源，敢于申請資源，然后把它用在項目所需要的地方，來解決一切干擾項目進度的問題。

    “隨機應變”，沒有到來的時間里總是充滿了未知的因素，有不少是風險管理中無法預料的事情。這個時候該怎么處理，處理的后果會產生什么影響，還有沒有更合適的辦法。。。。。。都在考驗PM。這就需要PM運用其綜合能力，包括經驗、技術能力、個人性格等，臨時來找到有效的解決意見。

    以上談到了項目實施的主要方針，我們再來看幾個真實的案例，從中進一步理解。

    案例一：

    某PM所做的一個局級OA項目，經過前期的工作以后已經進入了試運行階段，情況良好，正準備驗收。這時機關上調來了一個常務副局長，他提出OA中缺少勞資管理的功能，需要補上。PM并沒有馬上允諾或拒絕，而是找甲方關系較好的人員作了了解，原來此領導原來是主管人事出身，只對這塊比較有發言權。PM就找到了這位副局長，提出要為他專門做兩張報表，能夠從既有數據中進行人事相關信息的分析。領導很高興，也不再強求需要專門的勞資管理模塊。項目進度因而幾乎沒有受到影響，最終順利驗收。
 
    分析：

    OA和HRM有關系么？顯然差別很大。但是客戶是不能隨便得罪的，尤其是一個剛上任有實權的二把手。這個時候要思考領導提出此需求的原因。新官上任，一般要燒幾把火，一個正在進行中的項目當然要留下他的個人烙印。所以說，其實他真正的需求不在于搞勞資管理，畢竟這一塊業務以后也不歸他主管，其主要目的還是為了樹立威信。了解了這一點就好辦了，給他兩張“量身定做”的報表，既能體現他的個人意志，又表達了對他的尊重，最關鍵的是開發工作量很小。這個事件中，PM的及時溝通和思考決策，起到了決定性的作用。

    案例二：

    某CRM項目，已經到了試運行階段，原計劃下周二驗收。這時PM得知對方主管領導下周三要出國考察，想到對方可能沒有心思準備驗收的工作，便與對方溝通后把驗收時間改到領導回國以后。卻不料領導考察了國外的先進管理思想以后，回來決定大幅修改自己的業務管理模式，原有的CRM內容因此有大半失去作用。項目幾乎等于要重頭再來一次。

    分析：

    重視計劃永遠是正確的，甚至要想辦法讓條件成熟的后續工作提前開始。這個案例中的PM就犯了錯誤。領導要出國，沒心思召開驗收會是正常的。但是PM應該有很多辦法來促成項目的及時驗收。例如說找各業務主管對各模塊分別書面簽字驗收，然后只需要領導最后簽字確認即可。或者找公司領導匯報，爭取一筆資金，找個名目通過SALES交給領導（通常情況下項目都有回扣點數），同時談談馬上驗收的事宜。反正是在計劃安排的時間內，這種順水人情領導當然樂意。而且，對于領導去做業務考察這件事，PM居然沒有聯想到跟自己項目業務的關聯，敏感度太低。
案例三：

    一個PDM項目，需求調研已經完畢，正處于開發階段。這時客戶提出想把PDM和常用的三維設計軟件PRO/E進行集成，實現兩套軟件的數據交互。根據PM的經驗和技術人員的反饋來看，這個集成的難度相當大。但PM卻一口答應下來，然后向客戶提出需要對方配合的工作：請客戶方找PRO/E公司，以大客戶的身份要求PRO/E提供所需的數據接口。但是進行這種洽談的話，用戶需要提供正版序列號。實際上這家公司所用的PRO/E全是盜版，領導為此猶豫不決。PM更進一步地提出讓他們干脆采買幾套正版，不過即使是一套正版，價格也在80萬以上。權衡再三，最終客戶還是主動放棄了這個需求。

    分析：

    出現超出開發能力但又符合項目邊界的需求是項目中最讓人頭疼的問題。這種事情一旦解決不好，很容易讓客戶對供應商的水平產生懷疑，雙方合作產生裂痕，進而影響驗收。這個案例中的PM相當懂得隨機應變，他答應客戶去做這個需求其實是張空頭支票。但是通過巧妙的處理方式，最終的結果卻是需求被主動放棄，而且客戶對PM的好感增加。不過采用這樣的辦法是有風險的，只有事先作好調查，心里有較大把握，才能付諸實施。

    案例四：

    某企業即將上馬一個ERP項目。由于以前該企業曾經有一次實施ERP失敗的經歷，所以這次的新項目讓企業相關部門感到緊張，誰也不想碰這個攤子，一致主張低調啟動項目。但是供應商的PM卻力主召開一個隆重的啟動大會，在得到企業方主要領導的支持后，又找公司高層出面，請到了對方企業的上級主管到會，還在會上宣讀了以各個業務部門骨干為成員，某領導為組長的項目實施小組名單。在害怕項目失敗的壓力下，小組的各成員和責任領導戰戰兢兢，盡力配合好實施的每一處工作，還團結一致消除企業內部的雜音，爭取早日驗收早日完事。這個項目果然進行得異常順利，在規定時間內達到了各項功能指標，通過驗收。

    分析：

    信息系統對于很多企業而言，都不是離開它就干不了事的東西。所以客戶中出現散漫或者抵觸對待項目的情況比比皆是。這個時候最好的辦法就是把客戶跟自己捆在一條船上。在這個案例中PM很強勢，他首先說服了對方領導調配各個主要骨干來參加項目組，然后又讓對方的上級主管知曉此事來暗地施加壓力。這種情況下的項目干系人，唯一的想法恐怕就是安全過關，能用就行。既然抓住了企業中最能說上話的業務骨干，又降低了他們的心理期望值。這樣的項目，不驗收都難。

    案例五：

    某PM主導一個工廠的技術改造項目。天天和項目組成員一起泡在對方的車間里，和對方技術人員面對面交流。經過幾個月的埋頭苦干，逐步完善了系統，最終達到了可以驗收的地步。這時PM去找對方的總工提出召開驗收會。總工大吃一驚：“你們事情做完了？做到什么程度了？我怎么不知道？”于是總工又找來主要的幾個負責人，開會了解情況。雖然系統已經可以滿足對方的需求，但是既然領導專門開會，當屬下的自然要憋出幾個新想法來。再加上總工的個人意見，這個項目又出現了較大的需求變化，進度被迫延遲了。

    分析：

    做項目切忌“埋頭苦干”。當PM很需要會做表面工作。日請示月匯報，這樣才能讓領導重視。不管客戶上級主管有沒有時間或者興趣了解項目狀況，該做的日報、周報、月報、階段性報告。。。。。。一定要按期遞交到領導的案頭，就算對方不看，也混個臉熟。而且做了些什么事情，都是有記錄可查的。如果領導不清楚情況，哪怕下面的具體辦事人員再認可，對項目也沒有太大的作用。