項目經(jīng)理應嚴格遵循"為公司創(chuàng)造利潤,為客戶創(chuàng)造價值,為員工創(chuàng)造機會"。項目經(jīng)理關鍵在于對老板，對客戶，對合作伙伴，團隊成員的溝通把握好"度"。以下是我的幾點積累，如有不妥之處，煩請指正。

一、讓老板知道，信息系統(tǒng)的項目是比較獨特的、漸進的，是項較復雜的工程

信息系統(tǒng)項目,它不是硬件產(chǎn)品。具有相對可見的、固定的屬性。正因為它的可定制性強，才具有活力。一旦接觸，就要作好打持久戰(zhàn)的準備，公司所有資源要優(yōu)先供項目組利用。項目推遲驗收，客戶需求頻繁變更也是一個重大原因。一個公司的成功與否，很大程度上取決于對項目的管理是否得當。

二、作好項目范圍和項目目標控制

項目范圍一定要用規(guī)范的文檔描述?？蛻舸蠖嗍怯每陬^描述他們心中所想，而且是相當臨散的,尤其是政務項目，他們可能寫公文很在行，但是要他把需求用文字有條理的表達出來。一句話很難，就算他們提出來了,也已經(jīng)是幾周之后了。

再者項目范圍不清晰，隨著項目的進展,項目組所有人員的工作熱情很容易被拖垮，雙方都覺得項目越作越大，嚴重超出開始的范圍、超出計劃完成日期。今天這個功能不完善,明天那個要細化。日子一久，開發(fā)工程師都有點懷疑自己的能力了。最好是注明是第幾期工程，項目范圍和目標提出來了，同時在文檔中注明，如超出此項目范圍的作何處理。

一定要客戶方使用的業(yè)務科室和客戶領導簽字?；蛟S有這種情況出現(xiàn)，客戶方有推脫的理由不方便簽字，那么請說服他，這是公司的項目流程和規(guī)定。

三、嚴格控制客戶需求變更，告訴他并不是所有的變更都必須實現(xiàn)和能實現(xiàn)

客戶是上帝,不可否認。項目最終是給客戶方使用的。我們是否發(fā)現(xiàn)，有時客戶提的需求有點奇異，有點脫離實際,或者說暫且實現(xiàn)成本很大。那么你要堅定些，告訴他們.如按照他所做會如何如何,會帶來有成本、進度、質量相關實際的問題。給他們這樣的感覺，我們是系統(tǒng)解決方案提供者，關注的全局的,關鍵性的，必要性問題的解決。何況微軟還有補丁呢？

對他們的需求我們實行的方針是:"全部記錄，全部評估和控制，部分實施，全部驗收"

四、要讓客戶提供相關的負責人，整些必須的"整"事情

在實際中，有些客戶只知道把想要的東西說出來，然后要求完成日期，到時候要用上。之后好象與他無關。客戶方很可能是業(yè)務科室的工作人員,畢竟他們有自己的日常工作。

有的溝通要深入到客戶部門之間，最好由客戶方出面，或帶領。我曾遇到過這種情況，客戶竟然要求我們公司替他們把工業(yè)區(qū)的數(shù)據(jù)采集到系統(tǒng)中去，竟然推脫說自己手上還有其它事、與高新辦那邊不熟，初次就要我們自己去找。政府職能部門之間都不好打交道,難道你開發(fā)公司會更好地處理這些瑣事？

那么，勇敢地告訴他，在上次項目啟動會議上，他們領導已發(fā)表了他在項目中的職責。并告知他你的實際工作難處。相信他很難再猶豫和推脫了。

五、讓開發(fā)工程師"走出去",充分理解調研，面對客戶溝通

千萬不要認為，調研是浪費時間，調研如果方便的話，帶上女同事(嘿....嘿....別小看女同事哦)和開發(fā)工程師。我不贊成，調研人員中只有項目經(jīng)理和需求分析人員兩種角色。調研中的問題，要生成分析報告。并能根據(jù)調研內容，迅速提出重點和難點,及關鍵性的問題。這樣開發(fā)工程師是會將大部分精力放在重點模塊上，會更好地細化關鍵性的模塊。

我們每個人的理解不一樣,開發(fā)工程師更關注的編碼的技巧和功能的實現(xiàn)。開發(fā)工程師代表，參與調研可以很好地保證調研是指導開發(fā)，更好地的避免出現(xiàn)業(yè)務需求和開發(fā)脫節(jié)。再者讓他們切實感覺用戶的所說，所想。讓他們也了解下原來有時客戶需求表達的不清晰和多變性。平時并不是需求分析人員和調研員故意為難開發(fā)工程師。這樣比你天天喊提高產(chǎn)品質量,站在用戶角度換位思考強多了。

六、作好實施準備，先"跑"為"贏"

系統(tǒng)開發(fā)好了，功能完善了，你能說成功了？是否會出現(xiàn)系統(tǒng)開發(fā)好了，掛在那里,卻無人問津，無相關數(shù)據(jù)采集制度等等。讓客戶方項目阻礙者落下話柄？

系統(tǒng)好了，要人用呀，相信只有用了，才能體現(xiàn)系統(tǒng)的價值和公司的信譽度。也只有系統(tǒng)用了，才能體現(xiàn)你作為項目經(jīng)理的價值。因此要想法設法，盡一切可能讓客戶先把數(shù)據(jù)采集上來。數(shù)據(jù)上來了，主動權就掌握在咱手里了。之后的種種修改，不再是系統(tǒng)的功能不完善了。更重要的是公司里，老板會認為你之前所作的各種變更和修改是有意義的。切莫要把所有功能都細化，抱著等先完善好了，再上線采集數(shù)據(jù)的心態(tài)。這樣成功的可能性很小，甚至有可能直到你離開之日，系統(tǒng)功能還在作差不多的修改，里面卻因沒有客戶的業(yè)務數(shù)據(jù)作支撐而變得毫無意義。

很多不大不小的項目，缺少實施方法論。我見過很多軟件公司。就只有業(yè)務員和軟件工程師兩中角色，沒有專門的實施工程師?？赡茼椖啃〔挥X得，項目稍上一點規(guī)模，問題就暴露了。俗話說"三分開發(fā)，七分實施"呀。

建議當系統(tǒng)大部分功能經(jīng)過測試就可以了，先跑起來吧。一些小修改，非關鍵性目標的，在"跑后"再作為升級處理。這樣即使某些功能不夠細化,你能可以放心的對客戶和老板說項目達到預期目標了，甚至可以說成功了。

七、關于在開發(fā)過程中的用戶征求意見會議

項目經(jīng)理或開發(fā)公司方負責人一定要掌握會議進展的主動權。但凡有客戶方參加的項目會議，介紹完系統(tǒng)之后，客戶方領導往往會發(fā)表意見，有的是與系統(tǒng)功能有關，有的可能是涉及客戶方各職能部門的管理機制，工作流程，甚至是工作上的繁瑣。連春晚都眾口難調呀。記住,跑題了，及時把話題拉回來,在這些發(fā)表意見中不排除有阻礙項目者的高論。

會議不能太長,凡是與信息系統(tǒng)有關的會議,主題切莫離開中心思想"你們開發(fā)的系統(tǒng)是什么,能為他們干什么，是怎么體現(xiàn)和優(yōu)化他們實際的業(yè)務流程"勿需太多地用演示帳戶，操作開發(fā)的信息系統(tǒng)。他們討論的時間不能太長（控制在四十分鐘左右）。會議結束后，要第一時間內整理出會議報告，最好是開會時，有專人現(xiàn)場作Word文檔?，F(xiàn)場簽完名后，才讓他們拍屁股走人。

會議記錄之后，回到公司召集項目組所有成員及客戶方的支持者，對會議記錄中相關問題作出評估和控制，最后生產(chǎn)客戶需求變更評估和控制文檔。

存檔(三份,一份交于客戶確認，一份交于公司商務部，當然自己得留份底。到時候老板過問進度，也好有個交代呀)。（It168）