房地產項目管理軟件
當前位置：工程項目OA系統(tǒng) > 房地產OA系統(tǒng) > 相關系統(tǒng) > 房地產項目管理軟件
項目管理過程攻略——送給初為項目經(jīng)理的朋友
這篇文章是本人在某論壇中應大家需求連載的一篇關于項目整個執(zhí)行過程中項目經(jīng)理需要注意和關注的問題的介紹，現(xiàn)整理后發(fā)表于本站，歡迎大家點評。
在說項目管理問題的之前，有必要溫習下有關項目管理的一些基本知識，了解了這些基本的東西，應該有助于我們去理解項目協(xié)調工作都要做哪些事情。
關于項目的定義：項目是為完成某一獨特的產品和服務所做的一次性努力。
一次性——項目有明確的開始時間和結束時間。當項目目標已經(jīng)實現(xiàn)，或因項目目標不能實現(xiàn)而項目被終止時，就意味著項目的結束。
獨特性——項目所創(chuàng)造的產品或服務與已有的相似產品或服務相比較，在有些方面有明顯的差別。項目要完成的是以前未曾作過的工作，所以它是獨特的。
關于項目管理的定義： 項目管理是在項目活動中運用知識、技能、工具和技術，以滿足和超過項目干系人對項目的需求和期望。項目管理就是把各種資源應用于項目，以實現(xiàn)項目的目標。
項目管理是一個綜合類的學科，涉及多種知識領域：
項目范圍管理
項目時間管理
項目成本管理
項目質量管理
項目人力資源管理
項目溝通管理
項目風險管理
項目采購管理
項目綜合管理
項目具有明確的目標，且是一個一次性的活動過程，所以項目經(jīng)理的任務就是去調度資源利用相應的管理手段去完成項目，滿足或者超過項目“干系人”對項目的預期和希望。
那么“項目干系人”就是項目經(jīng)理在項目過程中始終要去關注的一些人，因為項目最終的成敗，項目的過程都與這些人有關系，甚至這些人就能決定一個項目的命運。還有一點我們必需承認：只要有組織就有政治。哪怕組織再小，只要能夠稱為“組織”，那么這個組織中一定存在著政治。所以，項目經(jīng)理在項目開始階段一定要識別項目干系人并能察覺干系人之間的政治關系以及你執(zhí)行這個項目的組織內的政治關系。當明確的找出了項目干系人并識別了其中的政治關系，那么項目經(jīng)理就可以在這些人中間根據(jù)需要展開協(xié)調工作了。
這是項目協(xié)調的最重要的部分，也就是用戶協(xié)調工作。
我們必需承認在項目實施公司內部由于資源分配等問題，項目經(jīng)理有必要也必需就這些問題在公司內部展開協(xié)調工作，這是項目協(xié)調中的內部協(xié)調工作。
在項目組內部對于任務分配、工作分工等問題，項目經(jīng)理同樣要進行項目組內部協(xié)調工作，有時候，這個協(xié)調工作甚至比用戶協(xié)調工作更棘手、更難以操作。
在項目開始階段，一般我們都用過一次會議來明確項目的計劃等等東西。在這個會議中，同樣會成立一個“項目管理委員會”之類的臨時機構，這個機構的人員一般由雙方項目經(jīng)理、高層領導等人員組成，主要目地就是有人能夠在項目出現(xiàn)關鍵問題的時候能夠商議和決策。不過話說回來，這個委員會一般都是虛無縹緲的，基本就是一個空架子，很少有項目真的靠這個機構來管理問題（雙方高層領導如果整天陷入項目中事務性的工作，這個項目恐怕也懸了。），基本還是靠雙方PM來協(xié)調，或者出現(xiàn)具體問題找分管領導協(xié)商解決。
不管怎樣，這個“委員會”之類的組織中的用戶，顯然都是這個項目的“干系人”，不是干系人我想他不會答應去進這個委員會。那么這是PM們識別出來的第一批“干系人”。還有誰是“干系人”呢？一般來說，主任級別的用戶都是我們不能忽略的，尤其是檢修、運行、經(jīng)營、物資這幾個部門的一把手（用電力項目冠軍客戶組成為例）。
下面說下有關政治的問題。我們不能指望一個企業(yè)一團和氣，企業(yè)內部存在2個以上的“陣營”是司空見慣的。一般來說企業(yè)內部分管你這個項目的領導都是一個副廠或者總工之類的領導。不管是誰管這個項目，作為PM你還是首先想辦法弄清楚這個企業(yè)高層之間微妙的關系比較好。知道關你這個項目的領導，在那個陣營有哪些對手、和哪些人關系好，下面哪些中層“是他的人”，這在PM日后進行項目運作和項目協(xié)調是很關鍵的。
作為廠級領導，即使看起來分管的是經(jīng)營、生產或者是總工甚至是管后勤、三產的，并沒有進入“委員會”，作為PM，最好把他們都列入“干系人”來管理比較好。
來，回頭總結下。
首先找到干系人，簡單的說對于電力項目來說，從廠長開始的廠級領導到關鍵部門的一把手，再加上用戶PM，這些都是項目干系人。
第二步，快速弄清楚企業(yè)的政治環(huán)境。這事情說起來容易，真要弄清楚還真不好辦。因為這本來就是敏感的事情，誰愿意給你說清楚啊。我曾經(jīng)在項目開始的時候去問這些問題，人家的回答：我們廠的事情，給你說三天三夜你也弄不清楚。
這里給大家說幾個技巧：
1、和用戶PM快速搞好關系。項目剛開始，大家沒有沖突只有美好的愿景，PM之間搞好關系這個是比較容易的。和他關系好了，通過他的嘴慢慢了解一些信息。
2、在與中層聊天時可以拿同樣的問題都問一遍，從他們的答案中去找到暗示。
3、給高層匯報工作的時候，可以問“這事請要不要再給×總（×廠長）匯報下？”聽聽對方口氣。
4、問問項目的銷售經(jīng)理，中標是找的誰幫忙的。這些人不用說將來都是可以幫助你的人。再問問他，投標對手的后臺都是誰。這些人不用說，你就時刻小心他們給你坑吧。
關于客戶協(xié)調的第一步，弄清對象、理清關系就說這么多吧。
隨著項目的開工，PM會很快弄清楚項目干系人都是誰，企業(yè)的政治情況也大致了解了。那么首先要做的三個重要工作就是：
項目計劃的協(xié)調
需求調研的安排
基礎數(shù)據(jù)的采集
項目經(jīng)理的項目協(xié)調工作從此就開始了。這個時候的協(xié)調工作還是比較簡單的，（原因明顯：沒有矛盾嘛）主要是些講道理的說服工作。說服用戶配合你的基礎數(shù)據(jù)采集這是一個大事，也是重要的事情。這個時候把道理、需求、日后的應用效果說清楚了，讓用戶有了對這工作的認識和不太大的期望（期望太高就要出事了?。赡軙浜系暮靡稽c。做為PM最好能夠說服用戶成立臨時的脫產的數(shù)據(jù)采集小組（但是對于目前的新建電廠的人力情況看，這個基本沒指望，但對于老廠完全可以這么要求，至少要辦脫產。），這樣才能保證效率和數(shù)據(jù)的可用性。
對于需求調研，想對顧問們說句話：任何一個流程不要只聽一個負責任的描述和解釋，否則你就會面臨日后需求調整的可能性。舉個例子，對于物資流程，不能只聽負責物資的采購或者經(jīng)營部門的領導和具體辦事人的需求，更要聽聽倉儲、檢修甚至總工、生產廠長、經(jīng)營廠長的想法和要求。對于信息化這個工作，每個人的出發(fā)點、認識、目地都是不同的，做為顧問一個事情多問問多看看只有好處。
為了日后工作開展起來方便順利，建議PM利用需求調研的時間充分的和企業(yè)各個層面進行業(yè)務交流和個人交流（從我了解目前國內幾個EAM實施公司的情況看，PM貌似都沒有這么多時間做這個事情，但是，我仍然建議PM們花時間下去和你們認為“沒什么可以交流的”這些用戶們多吹吹牛。）。一方面可以協(xié)助顧問進行需求調研，一方面混個眼熟、套點交情，日后有事情了，起碼人家知道你是做什么的，叫什么。我做一個項目的時候，曾經(jīng)用了一個月時間，每天杯子里放好茶葉，裝2包煙就四處游蕩去了。和我認為必要的人：干系人、關鍵用戶等去聊天，吹牛。對于需求不明確的地方，帶著顧問去，幫顧問問清楚了，我繼續(xù)吹牛。這些時間的浪費，保證了我在項目后期可以去直接協(xié)調用戶之間的問題，用戶PM協(xié)調不開的事情，我去游說一番都能搞定?；仡^看看那時候抽的煙、浪費的時間是不是都賺回來了？
這就是我要說的客戶協(xié)調的第一方面：廣泛打交道，混個臉熟。在混臉熟的過程，這些人的脾氣、愛好、說話做事方法PM們應該都能摸透了。那么以后遇到事情去協(xié)調，改怎么說話、說什么話不就心中有數(shù)了？
當然了，這樣的泛泛之交不能解決所有問題，對于客戶協(xié)調的第二方面就是關注重點用戶。具體的做法還是多交流。但是對于這些人來說，不就是混眼熟這么低要求了。對于他們PM最重要的是撲捉到他們對于這個項目的真實看法。（這話一點不荒唐，表明支持，實際上不希望項目成功的人大有人在。）這些出于用戶內心的對于項目的觀點、看法，是PM們日后決定項目走向、在關鍵問題上做出判斷的重要依據(jù)。
我曾經(jīng)就遇到這樣的事情：用戶直接建議我說，D經(jīng)理，你還是做做領導的工作把項目驗收了算了。上面曾經(jīng)要求我們上過一套系統(tǒng)，我們就隨便找了一家做了個程序，等上面來檢查，就開機讓看看畫面，里面連數(shù)據(jù)都沒有。我們不想用軟件，現(xiàn)在就挺好。就這樣的用戶心態(tài)，能配合你做好項目？可怕不。當然了，我還是可以再吹一個牛，上周和這個項目的用戶PM聊天的時候還提到這個部門，他說沒想到當年那么不配合的部門，現(xiàn)在用系統(tǒng)用的最好。我說我也沒想到。但是，用戶PM不知道我在他不知道的情況下做了多少工作。（當然，由于他們的存在，項目進度那是不樂觀的。）
有的放矢，總是不會錯的。
客戶協(xié)調的第三個層面就是和企業(yè)高層打交道了。這可能也是PM們最不知道怎么辦的事情。和別的干系人打交道可以用時間戰(zhàn)術、人海戰(zhàn)術，慢慢耗，耗也能耗出結果來。但是，領導們絕對沒有時間陪你天天吹牛。和領導們的交流，主要是按“有事啟奏、無事退朝”的原則來辦。有事，不是說是點事情就要去他哪里問清楚，找領導就是要批量一次性解決問題。所以，見領導前提前充分準備是很必要的：準備文檔（文檔要簡潔、重點突出，不要太厚），準備時間（領導很忙，不要你好不容易進門了，人家3分鐘后有會，給你來一句：你放這吧，我回頭看看給你答復。），準備怎么表達（說話要講究藝術，和領導溝通尤其如此。我覺得……、我建議……、廠里最好要求……最后結果都可能不一樣的。）
再分享點心得吧。見廠級領導，首先和廠辦主任（總經(jīng)理工作部之類了）搞好關系，去他哪里打聽領導們的動向，最好讓他幫你預約下（要是預約了就要守時）。提前準備好文檔，最好按照你能預估的結果來寫東西，談攏了讓領導直接簽發(fā)……這多爽啊。根據(jù)要談的內容，考慮好先后順序，很多時候前面的事情沒有談攏，后面的事情就不要提了，提了也沒用。順序弄明白了之后就開始擺沙盤吧，在腦袋里面設想你怎么提問題、要求，人家可能給你的答復，你再怎么討價還價……我堅信，沒有談判天才，只有有準備的談判天才。
好了，到現(xiàn)在，和三類用戶怎么打交道我們都明白了。下面就是遇到具體問題的具體協(xié)調手法了。
這里要插一句，PM們不要指望有事情了再去找誰誰誰溝通、協(xié)調，這基本都是很困難的。反正一個項目周期也不短，你也沒法預計以后要找誰，不如先浪費點時間下去。
前面已經(jīng)說清楚了PM進行客戶協(xié)調的最重要的東西，就是在問題發(fā)生之前和用戶多交流、多溝通。人與人之間有了一定的情感基礎，談起棘手的問題來能好一點。
隨著項目的深入展開，PM們面對的最多的問題大致有以下幾種：
1、進度計劃得不到執(zhí)行，項目開始延期；
2、用戶理由很多，總是不配合工作；
3、需求變更；
4、資源不足，人手不夠；
5、長期出差，項目組成員開始煩躁；
6、用戶PM由于項目的種種問題，開始郁悶，將邪火發(fā)到項目組成員身上；
7、PM身兼數(shù)職，無法全心進行項目管理，項目組成員開始各自為陣；
面對這些問題，PM們改怎么辦呢？一個問題一問題處理吧，還能怎么辦？
1、項目開始延期，這問題太普遍，普遍的大家都覺得正常。但是做為PM還是要分析，導致項目計劃延期的原因，至少在你的項目月報中要說清楚你的項目為什么延期吧？上面總結的2、3、4基本上都是項目延期的普遍原因。對于項目計劃延期問題，建議PM們和用戶PM做好溝通工作，屬于用戶方的問題要給他說清楚，必要的可以形成書面的東西給他。
2、這個問題最頭疼。人家每個人都貌似很忙，沒空配合你的事情，你怎么辦?。砍Ｒ?guī)方案，針對問題開項目協(xié)調會，通過會議解決這個問題。當然了，開會之前PM們需要做哪些事情，我在上一個帖子中對于開會有專門的說明，這里不再羅嗦。如果前期的吹牛工作做的比較好，那么這時候用戶PM通過官方手段無法協(xié)調的事情，你可以去試試看直接和那些用戶溝通下，說不定你就說服人家配合你了。第三個辦法，直接找廠領導，擺事實講道理，讓他來協(xié)調（找的領導一定要是“自己人”，找錯人了不要怪我出餿注意。）
3、需求變更，痛苦的事情。在這個帖子開頭的時候提過需求調研的過程中建議大家一個問題多問幾個人，就是為了防止大面積的需求變更。真的事情來了，也不要罵娘了，罵了也不能讓用戶不改啊。需求變更問題，是個很大的話題，也不好說清楚具體怎么操作，才能解決問題。說說我對于這個問題的幾個觀點吧。
A、面對需求變更，不要在第一時間發(fā)表任何看法。先把問題聽清楚，然后“站在用戶的角度去考慮為什么用戶要這樣要求”。
B、從用戶角度考慮清楚為什么這么要求了，再回頭看看原來的需求是怎么提的，偏差在哪里，是需要配工作流還是需要客戶化程序還是技術上實現(xiàn)困難或者干脆就是不能實現(xiàn)。
C、有一個觀點大家可以試著理解（純粹個人觀點，不同意要么扔磚頭要么笑笑算了）：管理都是有出發(fā)點、管理的手段以及管理的目地的。其實每個業(yè)務流程就是為了實現(xiàn)管理目地的一種管理手段，那么對于需要變更的需求，我們可以從管理的本質上來分析問題。如果說現(xiàn)有的東西和管理的目地不沖突只是在手段上有差異，那么我們可以和用戶商量這個差異是否可以換第三種方案來實現(xiàn)，這樣用戶的需求能滿足，我的程序修改內容最少。
需要說明的是，這樣的處理方法一般都是在處理需要程序規(guī)模性的修改的時候采用的（咱當年是做國產自主開發(fā)產品實施的，這樣的事情太多，于是就自己找了一個處理這個矛盾的套路。），而且，如果決定和用戶去這樣研究問題，那么一定要保證你首先是一個合格的顧問——你要把用戶的需求、業(yè)務本質都吃透了，才能和用戶去研究變通的方案。
D、如果你站在用戶的角度分析了，得出的結論是修改，那么就去改吧；如果仍然覺得不需要修改，那么現(xiàn)在可以和用去商量這個問題了。記住，你分析改不改的理由千萬不要是：工作量、技術問題、人手不夠、以后再說……一定要站在用戶立場去分析問題，最后讓他自己得出你要的結論，這是最理想的結果。
4、內部協(xié)調的問題終于出現(xiàn)了，目前電力市場火爆EAM同樣火爆，基本每個公司都面臨人少項目多的問題，那么內部進行資源（人力資源）的爭奪不可避免。做為PM向上級領導爭取資源的時候，我的建議是：分析事實、計劃、進度、目標以及你爭取的資源完對成這個計劃實現(xiàn)你的目標的影響。
5、PM做為公司指定的“項目的總經(jīng)理”以外，更是項目組的老大哥。在做好項目的同時，更要關心關心手下的兄弟們。我的觀點是，做為PM不是技術牛比就是顧問牛比，在項目組收入也應該是在前面的，那么就大方點，公司不報銷就自己請客吧（或者AA），沒事大家出去活動活動，放松下心情。做項目遠離家人、朋友而且天天加班很辛苦，如果PM再無法讓大家快樂起來，也是一件麻煩的事情。
6、用戶PM在項目的某個階段發(fā)邪火，PM們都遇到過吧。這個問題就一句話：有什么事情你給我說就好了，項目組的兄弟們很辛苦了，再錯都不要再罵他們，有火對我來。
7、這是技術當家的PM最容易遇到的問題，隨著項目的深入，任務分配下去就開始各忙各的，做為PM也不過多去過問，最后問題發(fā)生了就遲了（想起來雪上情人的一個關于項目組人員辭職的問題，關于這個問題，他的失職再怎么說也不過分 ）。不能說告誡，只能說建議各位技術出事并且同時在項目中做技術活的PM們，至少每天回宿舍要抽半小時時間和每個人溝通下，如果形成每日的宿舍項目例會那是更好不過了。
前面說到了PM在項目過程中會遇到的協(xié)調的問題，以及簡單的處理方法。當然了，做為PM誰也不希望項目中天天都是需要協(xié)調的事情，都希望項目在一個正常的軌道上穩(wěn)步前進。那么如何給項目一個正常的軌道呢？
可以考慮在項目開始階段做下面這些事情：
a、對于項目進度計劃的三級管理
三級管理是這樣一個模式：長期里程碑、重點工作計劃＋中期工作內容計劃＋短期具體操作計劃。這樣的計劃是一級對一級的解釋與細化，這樣就可以將一個漫長的項目過程通過合理的切割與組織，變成可以操作與控制的過程。通過短期計劃的滾動編排，可以很容易發(fā)現(xiàn)項目存在的重點問題與急需解決影響進度的問題。
通過這樣一個由粗到細，再由細反饋到粗的項目計劃管理過程，做為項目高層管理者可以很輕松的得到有關項目進度的真實情況和存在問題。
對于三級計劃的周期個兒建議：項目整體、月、周。
b、項目報告與項目例會制度
EAM項目周期不算太短的，那么PM們不要指望靠腦袋將項目中所有的事情都記在腦袋里面。通過階段的做為項目小組官方發(fā)布的文件，將項目中的進度、成果和問題進行記錄、發(fā)布是很重要的。
做為PM最重要的一個能力就是去“釋放”問題，否則，所有問題都壓在你身上，你再?！聊阋矔粔嚎?。那么，在項目開始階段就和用戶明確項目例會制度吧，有事情在會議中說清楚。
建議：在正常情況下實施方項目組每周都有內部報告，發(fā)布對象就是雙方項目組。整個項目官方的報告每月一個，對于特殊時期（上線過程，需求過程等）可以每周一個官方的報告。
例會可以跟著報告走。但是為了配合順利，最好一周一次小規(guī)模的雙方項目組例會，每月的例會需要邀請雙方高層項目管理者（項目管理小組的領導）參加（現(xiàn)實的問題就是實施方的高層管理者會每月參加嗎？）。
c、需求管理策略
誰也不希望需求變化，更不希望同樣的一件事情，三個用戶給了你三個“必需按我的要求來修改”的需求。對于這種你往左他往右的需求，可能是PM和顧問們最頭疼的事情。很可能就是今天改過去明天該回來。
當項目確定了項目《需求報告》或者《項目解決方案》后，雙方項目經(jīng)理可以坐下來明確一個可控、可追溯的需求管理方案，保證所有的需求變更都是“有人承擔責任的”。
沒有規(guī)矩不成方圓，在項目開始階段明確了計劃管理、工作管理和需求管理的方法，我想PM后期需要去協(xié)調的工作會少很多的。
前面說了項目開始要注意的東西，協(xié)調過程中的一些事情，以及如何給項目一個合理、有效的軌道讓用戶能夠配合實施方PM的工作，讓項目在友好和合作的氛圍中前進。隨著時間的推移和實施的深入，項目自然會到了需要準備驗收的時候。
今天就說說有關項目驗收的問題吧。
項目何時驗收、如何驗收這可能是PM們被直接領導、老板們問的最多的問題，也是很多PM們很頭疼的問題：用戶平時配合的挺好，怎么一說準備驗收了，什么都不好了，什么都要等等再說了……借口多的很，就是不配合你驗收。諸如此類的事情，在項目驗收過程都可能遇到。不驗收用戶不給錢，公司催死PM；要驗收用戶提了一堆問題，PM難死公司……面對驗收工作，PM們該如何展開操作呢？
從個人一貫對于項目驗收的理解來看，PM去操作項目驗收工作是沒有什么標準方法的。雖然項目驗收的標準程序很多，很多地方都能看到：各類驗收步驟、各類功能驗證、各類文檔、各類測試報告、各類手冊、功能清單……別的地方都能看到的東西，所以這些不是我想說的。有標準的東西都是可循的、可以量化的，這些東西只要花點時間下去，都能準備完成。真正帶給我們項目驗收的壓力的東西是那些非量化的東西：這個那個功能不符合要求、使用不方便；承諾的某某功能沒有實現(xiàn)；與合同、投標文件對比還有×××功能沒有實現(xiàn)（這些功能很可能是售前、銷售為了拿單子不管死活的寫上去的。）；系統(tǒng)才上線×個月問題還沒有暴露，再等×個月驗收也不遲……這些東西PM們該如何應對呢？
在繼續(xù)開始之前，要說明一個問題。
關于項目，我們可以去追求完美，但是考慮到給我們發(fā)工資的老板的心情，所以，在研究項目驗收這個問題的時候，讓我們先把做個完美的項目這個念頭扔到別的地方，重點去關心如何讓一個項目在大家都能接受的底線之上去驗收。
事實上，項目驗收應該從PM接到項目的第一天，從看招標文件、投標文件、技術協(xié)議那天就開始準備。道理很簡單：PM之后做的所有工作就是要完成這個項目，所以從這天開始PM就要為項目驗收而準備。
看招標文件、投標文件、技術協(xié)議不是去弄明白要做什么事情，而是要“清楚的知道那些用戶要求的東西、公司承諾的東西、合同里寫清楚的東西，在事實上是無法實現(xiàn)或者在成本分析中實現(xiàn)這些東西是不劃算的”。這些東西PM要明確的把他們從這三份合同相關的文件中識別出來，然后去和銷售經(jīng)理、售前顧問聊聊，看看這些東西都是怎么跑到合同或者標書里面去的，那些是可以去考慮回避的，那些是用戶很關心，需要去考慮實現(xiàn)的。
行了，弄清楚這些事情之后，組織好你的小組成員和顧問，把這些東西說清楚，考慮好需求調研的時候對這些問題采用何種方式去調研之后，可以著手準備項目啟動會（第一次設計聯(lián)絡會）了。
其實，做項目的過程，就是去將那三個文件（再羅嗦一次：招標文件、投標文件、技術協(xié)議）逐漸衰減的過程，當PM所擔心的問題都“合理”的衰減了（合理是很重要的，有時候老板們會用一些“粗魯”的方法解決問題，表面看暫時解決問題，事實上后遺癥很厲害。），那么項目也可以驗收了。但愿這個表述，大家能理解。
PM如果能抓清楚影響項目未來發(fā)展和驗收的主要問題，那么就需要在前面講的協(xié)調、溝通過程（就是我說的吹牛過程，鑒于大家的理解有誤，我改正為協(xié)調、溝通）中一點一點去把握用戶對這些問題的心態(tài)和想法，然后加以誘導和說服。感覺條件具備的時候去選擇一個合理的方式去將這些心中的石頭釋放掉。
有那些合理的方式呢？
會議顯然是首選了。需要考慮清楚的就是會議的主題是什么，不要傻傻的去開有關功能、需求變更為主題的會哦，這會嚇到用戶的。關于開會的問題前面也說了很多，就不多說了。需要注意的就是選好主題，然后把你想實現(xiàn)的事情合理的安排進去，并討論通過。
第二選擇就是個別溝通了。每個功能點總有核心用戶部門的，那么就去和這些部門的領導去溝通、協(xié)調吧。
還有第三種好辦法嗎？那就是希望用戶不要提這些問題了。但是誰能保證他現(xiàn)在不提，你準備驗收的時候不提呢？裝傻，不是好辦法。還是主動去排雷比較好，免的炸的時候你很慘。
把那些麻煩的需求都合理的處理了，那么面對驗收我們還要做什么？
分布驗收，分模塊驗收是個比較好的策略。古話說一口吃不成胖子嘛，那就慢慢吃吧。分步、分模塊驗收從用戶心理來說壓力相對較小，就是一個模塊，驗收了你也跑不了，給你簽字的可能性很大。當然了，事情都是兩面的。分模塊驗收是容易，那么需要考慮以下問題：
a、模塊驗收了，用戶來新的需求，做還是不做？
b、模塊驗收的功能顯然不會是三個文件規(guī)定的全部東西，如何保證在總體驗收的時候用戶不和你回頭算舊帳？
說個一家之言：做電力項目，只要錢沒拿到手之前，所有的簽字都是假的，千萬不要以為簽字了就萬事大吉了。曾經(jīng)有PM向我說：怎么能這樣，原來都簽字了，現(xiàn)在怎么又變了，怎么簽了字都不算？我說：你怎么辦？去他辦公室哭能解決問題不？
c、簽字驗收的人，對于項目的最終驗收是否具備絕對的發(fā)言權？人家弄個副主任給你簽模塊驗收，等最后發(fā)飆的時候主任去，一句：模塊驗收的事情我不知道，我今天提的問題你們必需做到，要不我不簽字驗收，誰要驗收誰去簽字。能氣的你想把你的IBM扔過去。
不管怎樣，事情做的差不多了，項目也超期了，總是要驗收的。
上面那個兄弟說了，提前吹風是很重要的。這小風慢慢的吹，一個人一個人的吹，爭取在吹風的時候把問題都提前了解清楚，然后找合理的理由去說服吧。
現(xiàn)在能不能驗收了？估計還是比較懸吧？總有不好擺平的用戶的，跟你叫上勁了也不是什么奇怪的事情。那么就上下活動，團結可以團結的力量，判斷清楚問題和形勢后開個驗收預備會吧。
你不給我驗收，那么我要求開個預備會“誠懇”并且“認真”的聽用戶的意見和問題，并給出一個解決問題的時間表，在這個時間表內，誰不配合、誰不能完成任務都要有相應的處理辦法。我曾經(jīng)利用中午吃飯的時間和電廠一把手聊天，除了沒說項目的事情，聊了很多話題，還記得有：應用數(shù)學是什么專業(yè)，能做什么；拉普拉斯方程；電網(wǎng)潮流計算；電廠主輔分離好不好；他們電廠有沒有必要成立檢修公司……。一直聊到下午上班，然后跟到辦公室跟他談預備會的事情，最后要了他一句話：開會的時候我肯定最后發(fā)言，你說什么我強調什么，怎樣？
開會的時候，廠長還多說了一句話：“人家D經(jīng)理在這邊很久了，也很辛苦，我認為他們的工作很有成績，今天人家也拿出最后的驗收計劃了，態(tài)度非常好。今天我還要說的就是，那個部門不配合××公司技術人員，導致計劃不能完成，到了時間你們那個主任不簽字，我來簽字驗收，驗收完了我再找你算帳?！甭犃诉@話，心里那個爽啊。當天沒有加班，晚上喊小組兄弟們出去喝酒。
個人認為，預備會是個比較好的處理方法。行了，預備會也開了，問題都說清楚了，能不能驗收了？
答案是還有可能出什么鬼問題導致用戶提出來不驗收，對于老PM，遇到這樣的問題不奇怪吧。怎么辦呢？相信通過前期的溝通什么的，PM對用戶的心里底線應該都能把握了，而且前面你也做了這么多工作了。就差最后一點了，不解決不急死人??？
備忘吧！我都做了這么多事情了，最后這一點你還擔心我不做？但是，說好的要驗收??！總要讓我給公司一個交代啊？而且，沒按時驗收，你（用戶PM）這不也算沒完成工作啊？要不咱各退一步，你給我驗收了，我驗收報告后面給你附個備忘錄，我答應你做的都寫里面去。
事情做到這份了，PM們項目驗收了沒有？
總結篇
通過一個項目從頭到尾整個過程的簡單解釋，希望新的PM及技術轉型的PM們能夠從中間得到點自己需要的東西。也算我沒有白花這么多時間去打字。
寫了不少，回頭再來提煉下：
項目開始階段，分析清楚合同相關文件很重要，從中間發(fā)現(xiàn)以后需要注意的“特殊”功能要求；
在項目開始階段和用戶明確項目的管理體系：報告、例會、需求變更等；
排一個比你覺得能實現(xiàn)的計劃周期壓縮20％的總體計劃；
根據(jù)自己的能力和優(yōu)勢選擇一個理想的介入項目的方法：或者高調（這個不是太好玩）、或者認真、或者技術很好、或者理解行業(yè)需求……
開始階段，多和用戶溝通，不一定要有問題才去找用戶，電廠的主管們大多時間還是教多的，多接觸接觸是好事；
剛開始的項目報告一定要言之有物，能客觀反應問題（是用戶的就指出來，是自己的錯誤也老實寫上去），讓用戶領導覺得可以通過這樣的形式了解項目情況，并愿意參加例會；
滾動計劃一定要準確，不要滾來滾去，事情總完成不了，會導致用戶對于你計劃能力和做事能力的懷疑；
排雷工作早點做，不要等驗收前3個月才想起來；
PM就是PM，不要再去做技術高手，對小組兄弟多些指導，少做點具體事情，多花點時間去考慮項目整體的事情；
對于驗收，不要一根筋的去考慮，做多種方案準備，然后考慮清楚后再和用戶去談；
最后，關心項目組兄弟們的生活，人性化點。
在說項目管理問題的之前，有必要溫習下有關項目管理的一些基本知識，了解了這些基本的東西，應該有助于我們去理解項目協(xié)調工作都要做哪些事情。
關于項目的定義：項目是為完成某一獨特的產品和服務所做的一次性努力。
一次性——項目有明確的開始時間和結束時間。當項目目標已經(jīng)實現(xiàn)，或因項目目標不能實現(xiàn)而項目被終止時，就意味著項目的結束。
獨特性——項目所創(chuàng)造的產品或服務與已有的相似產品或服務相比較，在有些方面有明顯的差別。項目要完成的是以前未曾作過的工作，所以它是獨特的。
關于項目管理的定義： 項目管理是在項目活動中運用知識、技能、工具和技術，以滿足和超過項目干系人對項目的需求和期望。項目管理就是把各種資源應用于項目，以實現(xiàn)項目的目標。
項目管理是一個綜合類的學科，涉及多種知識領域：
項目范圍管理
項目時間管理
項目成本管理
項目質量管理
項目人力資源管理
項目溝通管理
項目風險管理
項目采購管理
項目綜合管理
項目具有明確的目標，且是一個一次性的活動過程，所以項目經(jīng)理的任務就是去調度資源利用相應的管理手段去完成項目，滿足或者超過項目“干系人”對項目的預期和希望。
那么“項目干系人”就是項目經(jīng)理在項目過程中始終要去關注的一些人，因為項目最終的成敗，項目的過程都與這些人有關系，甚至這些人就能決定一個項目的命運。還有一點我們必需承認：只要有組織就有政治。哪怕組織再小，只要能夠稱為“組織”，那么這個組織中一定存在著政治。所以，項目經(jīng)理在項目開始階段一定要識別項目干系人并能察覺干系人之間的政治關系以及你執(zhí)行這個項目的組織內的政治關系。當明確的找出了項目干系人并識別了其中的政治關系，那么項目經(jīng)理就可以在這些人中間根據(jù)需要展開協(xié)調工作了。
這是項目協(xié)調的最重要的部分，也就是用戶協(xié)調工作。
我們必需承認在項目實施公司內部由于資源分配等問題，項目經(jīng)理有必要也必需就這些問題在公司內部展開協(xié)調工作，這是項目協(xié)調中的內部協(xié)調工作。
在項目組內部對于任務分配、工作分工等問題，項目經(jīng)理同樣要進行項目組內部協(xié)調工作，有時候，這個協(xié)調工作甚至比用戶協(xié)調工作更棘手、更難以操作。
在項目開始階段，一般我們都用過一次會議來明確項目的計劃等等東西。在這個會議中，同樣會成立一個“項目管理委員會”之類的臨時機構，這個機構的人員一般由雙方項目經(jīng)理、高層領導等人員組成，主要目地就是有人能夠在項目出現(xiàn)關鍵問題的時候能夠商議和決策。不過話說回來，這個委員會一般都是虛無縹緲的，基本就是一個空架子，很少有項目真的靠這個機構來管理問題（雙方高層領導如果整天陷入項目中事務性的工作，這個項目恐怕也懸了。），基本還是靠雙方PM來協(xié)調，或者出現(xiàn)具體問題找分管領導協(xié)商解決。
不管怎樣，這個“委員會”之類的組織中的用戶，顯然都是這個項目的“干系人”，不是干系人我想他不會答應去進這個委員會。那么這是PM們識別出來的第一批“干系人”。還有誰是“干系人”呢？一般來說，主任級別的用戶都是我們不能忽略的，尤其是檢修、運行、經(jīng)營、物資這幾個部門的一把手（用電力項目冠軍客戶組成為例）。
下面說下有關政治的問題。我們不能指望一個企業(yè)一團和氣，企業(yè)內部存在2個以上的“陣營”是司空見慣的。一般來說企業(yè)內部分管你這個項目的領導都是一個副廠或者總工之類的領導。不管是誰管這個項目，作為PM你還是首先想辦法弄清楚這個企業(yè)高層之間微妙的關系比較好。知道關你這個項目的領導，在那個陣營有哪些對手、和哪些人關系好，下面哪些中層“是他的人”，這在PM日后進行項目運作和項目協(xié)調是很關鍵的。
作為廠級領導，即使看起來分管的是經(jīng)營、生產或者是總工甚至是管后勤、三產的，并沒有進入“委員會”，作為PM，最好把他們都列入“干系人”來管理比較好。
來，回頭總結下。
首先找到干系人，簡單的說對于電力項目來說，從廠長開始的廠級領導到關鍵部門的一把手，再加上用戶PM，這些都是項目干系人。
第二步，快速弄清楚企業(yè)的政治環(huán)境。這事情說起來容易，真要弄清楚還真不好辦。因為這本來就是敏感的事情，誰愿意給你說清楚啊。我曾經(jīng)在項目開始的時候去問這些問題，人家的回答：我們廠的事情，給你說三天三夜你也弄不清楚。
這里給大家說幾個技巧：
1、和用戶PM快速搞好關系。項目剛開始，大家沒有沖突只有美好的愿景，PM之間搞好關系這個是比較容易的。和他關系好了，通過他的嘴慢慢了解一些信息。
2、在與中層聊天時可以拿同樣的問題都問一遍，從他們的答案中去找到暗示。
3、給高層匯報工作的時候，可以問“這事請要不要再給×總（×廠長）匯報下？”聽聽對方口氣。
4、問問項目的銷售經(jīng)理，中標是找的誰幫忙的。這些人不用說將來都是可以幫助你的人。再問問他，投標對手的后臺都是誰。這些人不用說，你就時刻小心他們給你坑吧。
關于客戶協(xié)調的第一步，弄清對象、理清關系就說這么多吧。
隨著項目的開工，PM會很快弄清楚項目干系人都是誰，企業(yè)的政治情況也大致了解了。那么首先要做的三個重要工作就是：
項目計劃的協(xié)調
需求調研的安排
基礎數(shù)據(jù)的采集
項目經(jīng)理的項目協(xié)調工作從此就開始了。這個時候的協(xié)調工作還是比較簡單的，（原因明顯：沒有矛盾嘛）主要是些講道理的說服工作。說服用戶配合你的基礎數(shù)據(jù)采集這是一個大事，也是重要的事情。這個時候把道理、需求、日后的應用效果說清楚了，讓用戶有了對這工作的認識和不太大的期望（期望太高就要出事了?。赡軙浜系暮靡稽c。做為PM最好能夠說服用戶成立臨時的脫產的數(shù)據(jù)采集小組（但是對于目前的新建電廠的人力情況看，這個基本沒指望，但對于老廠完全可以這么要求，至少要辦脫產。），這樣才能保證效率和數(shù)據(jù)的可用性。
對于需求調研，想對顧問們說句話：任何一個流程不要只聽一個負責任的描述和解釋，否則你就會面臨日后需求調整的可能性。舉個例子，對于物資流程，不能只聽負責物資的采購或者經(jīng)營部門的領導和具體辦事人的需求，更要聽聽倉儲、檢修甚至總工、生產廠長、經(jīng)營廠長的想法和要求。對于信息化這個工作，每個人的出發(fā)點、認識、目地都是不同的，做為顧問一個事情多問問多看看只有好處。
為了日后工作開展起來方便順利，建議PM利用需求調研的時間充分的和企業(yè)各個層面進行業(yè)務交流和個人交流（從我了解目前國內幾個EAM實施公司的情況看，PM貌似都沒有這么多時間做這個事情，但是，我仍然建議PM們花時間下去和你們認為“沒什么可以交流的”這些用戶們多吹吹牛。）。一方面可以協(xié)助顧問進行需求調研，一方面混個眼熟、套點交情，日后有事情了，起碼人家知道你是做什么的，叫什么。我做一個項目的時候，曾經(jīng)用了一個月時間，每天杯子里放好茶葉，裝2包煙就四處游蕩去了。和我認為必要的人：干系人、關鍵用戶等去聊天，吹牛。對于需求不明確的地方，帶著顧問去，幫顧問問清楚了，我繼續(xù)吹牛。這些時間的浪費，保證了我在項目后期可以去直接協(xié)調用戶之間的問題，用戶PM協(xié)調不開的事情，我去游說一番都能搞定?；仡^看看那時候抽的煙、浪費的時間是不是都賺回來了？
這就是我要說的客戶協(xié)調的第一方面：廣泛打交道，混個臉熟。在混臉熟的過程，這些人的脾氣、愛好、說話做事方法PM們應該都能摸透了。那么以后遇到事情去協(xié)調，改怎么說話、說什么話不就心中有數(shù)了？
當然了，這樣的泛泛之交不能解決所有問題，對于客戶協(xié)調的第二方面就是關注重點用戶。具體的做法還是多交流。但是對于這些人來說，不就是混眼熟這么低要求了。對于他們PM最重要的是撲捉到他們對于這個項目的真實看法。（這話一點不荒唐，表明支持，實際上不希望項目成功的人大有人在。）這些出于用戶內心的對于項目的觀點、看法，是PM們日后決定項目走向、在關鍵問題上做出判斷的重要依據(jù)。
我曾經(jīng)就遇到這樣的事情：用戶直接建議我說，D經(jīng)理，你還是做做領導的工作把項目驗收了算了。上面曾經(jīng)要求我們上過一套系統(tǒng)，我們就隨便找了一家做了個程序，等上面來檢查，就開機讓看看畫面，里面連數(shù)據(jù)都沒有。我們不想用軟件，現(xiàn)在就挺好。就這樣的用戶心態(tài)，能配合你做好項目？可怕不。當然了，我還是可以再吹一個牛，上周和這個項目的用戶PM聊天的時候還提到這個部門，他說沒想到當年那么不配合的部門，現(xiàn)在用系統(tǒng)用的最好。我說我也沒想到。但是，用戶PM不知道我在他不知道的情況下做了多少工作。（當然，由于他們的存在，項目進度那是不樂觀的。）
有的放矢，總是不會錯的。
客戶協(xié)調的第三個層面就是和企業(yè)高層打交道了。這可能也是PM們最不知道怎么辦的事情。和別的干系人打交道可以用時間戰(zhàn)術、人海戰(zhàn)術，慢慢耗，耗也能耗出結果來。但是，領導們絕對沒有時間陪你天天吹牛。和領導們的交流，主要是按“有事啟奏、無事退朝”的原則來辦。有事，不是說是點事情就要去他哪里問清楚，找領導就是要批量一次性解決問題。所以，見領導前提前充分準備是很必要的：準備文檔（文檔要簡潔、重點突出，不要太厚），準備時間（領導很忙，不要你好不容易進門了，人家3分鐘后有會，給你來一句：你放這吧，我回頭看看給你答復。），準備怎么表達（說話要講究藝術，和領導溝通尤其如此。我覺得……、我建議……、廠里最好要求……最后結果都可能不一樣的。）
再分享點心得吧。見廠級領導，首先和廠辦主任（總經(jīng)理工作部之類了）搞好關系，去他哪里打聽領導們的動向，最好讓他幫你預約下（要是預約了就要守時）。提前準備好文檔，最好按照你能預估的結果來寫東西，談攏了讓領導直接簽發(fā)……這多爽啊。根據(jù)要談的內容，考慮好先后順序，很多時候前面的事情沒有談攏，后面的事情就不要提了，提了也沒用。順序弄明白了之后就開始擺沙盤吧，在腦袋里面設想你怎么提問題、要求，人家可能給你的答復，你再怎么討價還價……我堅信，沒有談判天才，只有有準備的談判天才。
好了，到現(xiàn)在，和三類用戶怎么打交道我們都明白了。下面就是遇到具體問題的具體協(xié)調手法了。
這里要插一句，PM們不要指望有事情了再去找誰誰誰溝通、協(xié)調，這基本都是很困難的。反正一個項目周期也不短，你也沒法預計以后要找誰，不如先浪費點時間下去。
前面已經(jīng)說清楚了PM進行客戶協(xié)調的最重要的東西，就是在問題發(fā)生之前和用戶多交流、多溝通。人與人之間有了一定的情感基礎，談起棘手的問題來能好一點。
隨著項目的深入展開，PM們面對的最多的問題大致有以下幾種：
1、進度計劃得不到執(zhí)行，項目開始延期；
2、用戶理由很多，總是不配合工作；
3、需求變更；
4、資源不足，人手不夠；
5、長期出差，項目組成員開始煩躁；
6、用戶PM由于項目的種種問題，開始郁悶，將邪火發(fā)到項目組成員身上；
7、PM身兼數(shù)職，無法全心進行項目管理，項目組成員開始各自為陣；
面對這些問題，PM們改怎么辦呢？一個問題一問題處理吧，還能怎么辦？
1、項目開始延期，這問題太普遍，普遍的大家都覺得正常。但是做為PM還是要分析，導致項目計劃延期的原因，至少在你的項目月報中要說清楚你的項目為什么延期吧？上面總結的2、3、4基本上都是項目延期的普遍原因。對于項目計劃延期問題，建議PM們和用戶PM做好溝通工作，屬于用戶方的問題要給他說清楚，必要的可以形成書面的東西給他。
2、這個問題最頭疼。人家每個人都貌似很忙，沒空配合你的事情，你怎么辦?。砍Ｒ?guī)方案，針對問題開項目協(xié)調會，通過會議解決這個問題。當然了，開會之前PM們需要做哪些事情，我在上一個帖子中對于開會有專門的說明，這里不再羅嗦。如果前期的吹牛工作做的比較好，那么這時候用戶PM通過官方手段無法協(xié)調的事情，你可以去試試看直接和那些用戶溝通下，說不定你就說服人家配合你了。第三個辦法，直接找廠領導，擺事實講道理，讓他來協(xié)調（找的領導一定要是“自己人”，找錯人了不要怪我出餿注意。）
3、需求變更，痛苦的事情。在這個帖子開頭的時候提過需求調研的過程中建議大家一個問題多問幾個人，就是為了防止大面積的需求變更。真的事情來了，也不要罵娘了，罵了也不能讓用戶不改啊。需求變更問題，是個很大的話題，也不好說清楚具體怎么操作，才能解決問題。說說我對于這個問題的幾個觀點吧。
A、面對需求變更，不要在第一時間發(fā)表任何看法。先把問題聽清楚，然后“站在用戶的角度去考慮為什么用戶要這樣要求”。
B、從用戶角度考慮清楚為什么這么要求了，再回頭看看原來的需求是怎么提的，偏差在哪里，是需要配工作流還是需要客戶化程序還是技術上實現(xiàn)困難或者干脆就是不能實現(xiàn)。
C、有一個觀點大家可以試著理解（純粹個人觀點，不同意要么扔磚頭要么笑笑算了）：管理都是有出發(fā)點、管理的手段以及管理的目地的。其實每個業(yè)務流程就是為了實現(xiàn)管理目地的一種管理手段，那么對于需要變更的需求，我們可以從管理的本質上來分析問題。如果說現(xiàn)有的東西和管理的目地不沖突只是在手段上有差異，那么我們可以和用戶商量這個差異是否可以換第三種方案來實現(xiàn)，這樣用戶的需求能滿足，我的程序修改內容最少。
需要說明的是，這樣的處理方法一般都是在處理需要程序規(guī)模性的修改的時候采用的（咱當年是做國產自主開發(fā)產品實施的，這樣的事情太多，于是就自己找了一個處理這個矛盾的套路。），而且，如果決定和用戶去這樣研究問題，那么一定要保證你首先是一個合格的顧問——你要把用戶的需求、業(yè)務本質都吃透了，才能和用戶去研究變通的方案。
D、如果你站在用戶的角度分析了，得出的結論是修改，那么就去改吧；如果仍然覺得不需要修改，那么現(xiàn)在可以和用去商量這個問題了。記住，你分析改不改的理由千萬不要是：工作量、技術問題、人手不夠、以后再說……一定要站在用戶立場去分析問題，最后讓他自己得出你要的結論，這是最理想的結果。
4、內部協(xié)調的問題終于出現(xiàn)了，目前電力市場火爆EAM同樣火爆，基本每個公司都面臨人少項目多的問題，那么內部進行資源（人力資源）的爭奪不可避免。做為PM向上級領導爭取資源的時候，我的建議是：分析事實、計劃、進度、目標以及你爭取的資源完對成這個計劃實現(xiàn)你的目標的影響。
5、PM做為公司指定的“項目的總經(jīng)理”以外，更是項目組的老大哥。在做好項目的同時，更要關心關心手下的兄弟們。我的觀點是，做為PM不是技術牛比就是顧問牛比，在項目組收入也應該是在前面的，那么就大方點，公司不報銷就自己請客吧（或者AA），沒事大家出去活動活動，放松下心情。做項目遠離家人、朋友而且天天加班很辛苦，如果PM再無法讓大家快樂起來，也是一件麻煩的事情。
6、用戶PM在項目的某個階段發(fā)邪火，PM們都遇到過吧。這個問題就一句話：有什么事情你給我說就好了，項目組的兄弟們很辛苦了，再錯都不要再罵他們，有火對我來。
7、這是技術當家的PM最容易遇到的問題，隨著項目的深入，任務分配下去就開始各忙各的，做為PM也不過多去過問，最后問題發(fā)生了就遲了（想起來雪上情人的一個關于項目組人員辭職的問題，關于這個問題，他的失職再怎么說也不過分 ）。不能說告誡，只能說建議各位技術出事并且同時在項目中做技術活的PM們，至少每天回宿舍要抽半小時時間和每個人溝通下，如果形成每日的宿舍項目例會那是更好不過了。
前面說到了PM在項目過程中會遇到的協(xié)調的問題，以及簡單的處理方法。當然了，做為PM誰也不希望項目中天天都是需要協(xié)調的事情，都希望項目在一個正常的軌道上穩(wěn)步前進。那么如何給項目一個正常的軌道呢？
可以考慮在項目開始階段做下面這些事情：
a、對于項目進度計劃的三級管理
三級管理是這樣一個模式：長期里程碑、重點工作計劃＋中期工作內容計劃＋短期具體操作計劃。這樣的計劃是一級對一級的解釋與細化，這樣就可以將一個漫長的項目過程通過合理的切割與組織，變成可以操作與控制的過程。通過短期計劃的滾動編排，可以很容易發(fā)現(xiàn)項目存在的重點問題與急需解決影響進度的問題。
通過這樣一個由粗到細，再由細反饋到粗的項目計劃管理過程，做為項目高層管理者可以很輕松的得到有關項目進度的真實情況和存在問題。
對于三級計劃的周期個兒建議：項目整體、月、周。
b、項目報告與項目例會制度
EAM項目周期不算太短的，那么PM們不要指望靠腦袋將項目中所有的事情都記在腦袋里面。通過階段的做為項目小組官方發(fā)布的文件，將項目中的進度、成果和問題進行記錄、發(fā)布是很重要的。
做為PM最重要的一個能力就是去“釋放”問題，否則，所有問題都壓在你身上，你再?！聊阋矔粔嚎?。那么，在項目開始階段就和用戶明確項目例會制度吧，有事情在會議中說清楚。
建議：在正常情況下實施方項目組每周都有內部報告，發(fā)布對象就是雙方項目組。整個項目官方的報告每月一個，對于特殊時期（上線過程，需求過程等）可以每周一個官方的報告。
例會可以跟著報告走。但是為了配合順利，最好一周一次小規(guī)模的雙方項目組例會，每月的例會需要邀請雙方高層項目管理者（項目管理小組的領導）參加（現(xiàn)實的問題就是實施方的高層管理者會每月參加嗎？）。
c、需求管理策略
誰也不希望需求變化，更不希望同樣的一件事情，三個用戶給了你三個“必需按我的要求來修改”的需求。對于這種你往左他往右的需求，可能是PM和顧問們最頭疼的事情。很可能就是今天改過去明天該回來。
當項目確定了項目《需求報告》或者《項目解決方案》后，雙方項目經(jīng)理可以坐下來明確一個可控、可追溯的需求管理方案，保證所有的需求變更都是“有人承擔責任的”。
沒有規(guī)矩不成方圓，在項目開始階段明確了計劃管理、工作管理和需求管理的方法，我想PM后期需要去協(xié)調的工作會少很多的。
前面說了項目開始要注意的東西，協(xié)調過程中的一些事情，以及如何給項目一個合理、有效的軌道讓用戶能夠配合實施方PM的工作，讓項目在友好和合作的氛圍中前進。隨著時間的推移和實施的深入，項目自然會到了需要準備驗收的時候。
今天就說說有關項目驗收的問題吧。
項目何時驗收、如何驗收這可能是PM們被直接領導、老板們問的最多的問題，也是很多PM們很頭疼的問題：用戶平時配合的挺好，怎么一說準備驗收了，什么都不好了，什么都要等等再說了……借口多的很，就是不配合你驗收。諸如此類的事情，在項目驗收過程都可能遇到。不驗收用戶不給錢，公司催死PM；要驗收用戶提了一堆問題，PM難死公司……面對驗收工作，PM們該如何展開操作呢？
從個人一貫對于項目驗收的理解來看，PM去操作項目驗收工作是沒有什么標準方法的。雖然項目驗收的標準程序很多，很多地方都能看到：各類驗收步驟、各類功能驗證、各類文檔、各類測試報告、各類手冊、功能清單……別的地方都能看到的東西，所以這些不是我想說的。有標準的東西都是可循的、可以量化的，這些東西只要花點時間下去，都能準備完成。真正帶給我們項目驗收的壓力的東西是那些非量化的東西：這個那個功能不符合要求、使用不方便；承諾的某某功能沒有實現(xiàn)；與合同、投標文件對比還有×××功能沒有實現(xiàn)（這些功能很可能是售前、銷售為了拿單子不管死活的寫上去的。）；系統(tǒng)才上線×個月問題還沒有暴露，再等×個月驗收也不遲……這些東西PM們該如何應對呢？
在繼續(xù)開始之前，要說明一個問題。
關于項目，我們可以去追求完美，但是考慮到給我們發(fā)工資的老板的心情，所以，在研究項目驗收這個問題的時候，讓我們先把做個完美的項目這個念頭扔到別的地方，重點去關心如何讓一個項目在大家都能接受的底線之上去驗收。
事實上，項目驗收應該從PM接到項目的第一天，從看招標文件、投標文件、技術協(xié)議那天就開始準備。道理很簡單：PM之后做的所有工作就是要完成這個項目，所以從這天開始PM就要為項目驗收而準備。
看招標文件、投標文件、技術協(xié)議不是去弄明白要做什么事情，而是要“清楚的知道那些用戶要求的東西、公司承諾的東西、合同里寫清楚的東西，在事實上是無法實現(xiàn)或者在成本分析中實現(xiàn)這些東西是不劃算的”。這些東西PM要明確的把他們從這三份合同相關的文件中識別出來，然后去和銷售經(jīng)理、售前顧問聊聊，看看這些東西都是怎么跑到合同或者標書里面去的，那些是可以去考慮回避的，那些是用戶很關心，需要去考慮實現(xiàn)的。
行了，弄清楚這些事情之后，組織好你的小組成員和顧問，把這些東西說清楚，考慮好需求調研的時候對這些問題采用何種方式去調研之后，可以著手準備項目啟動會（第一次設計聯(lián)絡會）了。
其實，做項目的過程，就是去將那三個文件（再羅嗦一次：招標文件、投標文件、技術協(xié)議）逐漸衰減的過程，當PM所擔心的問題都“合理”的衰減了（合理是很重要的，有時候老板們會用一些“粗魯”的方法解決問題，表面看暫時解決問題，事實上后遺癥很厲害。），那么項目也可以驗收了。但愿這個表述，大家能理解。
PM如果能抓清楚影響項目未來發(fā)展和驗收的主要問題，那么就需要在前面講的協(xié)調、溝通過程（就是我說的吹牛過程，鑒于大家的理解有誤，我改正為協(xié)調、溝通）中一點一點去把握用戶對這些問題的心態(tài)和想法，然后加以誘導和說服。感覺條件具備的時候去選擇一個合理的方式去將這些心中的石頭釋放掉。
有那些合理的方式呢？
會議顯然是首選了。需要考慮清楚的就是會議的主題是什么，不要傻傻的去開有關功能、需求變更為主題的會哦，這會嚇到用戶的。關于開會的問題前面也說了很多，就不多說了。需要注意的就是選好主題，然后把你想實現(xiàn)的事情合理的安排進去，并討論通過。
第二選擇就是個別溝通了。每個功能點總有核心用戶部門的，那么就去和這些部門的領導去溝通、協(xié)調吧。
還有第三種好辦法嗎？那就是希望用戶不要提這些問題了。但是誰能保證他現(xiàn)在不提，你準備驗收的時候不提呢？裝傻，不是好辦法。還是主動去排雷比較好，免的炸的時候你很慘。
把那些麻煩的需求都合理的處理了，那么面對驗收我們還要做什么？
分布驗收，分模塊驗收是個比較好的策略。古話說一口吃不成胖子嘛，那就慢慢吃吧。分步、分模塊驗收從用戶心理來說壓力相對較小，就是一個模塊，驗收了你也跑不了，給你簽字的可能性很大。當然了，事情都是兩面的。分模塊驗收是容易，那么需要考慮以下問題：
a、模塊驗收了，用戶來新的需求，做還是不做？
b、模塊驗收的功能顯然不會是三個文件規(guī)定的全部東西，如何保證在總體驗收的時候用戶不和你回頭算舊帳？
說個一家之言：做電力項目，只要錢沒拿到手之前，所有的簽字都是假的，千萬不要以為簽字了就萬事大吉了。曾經(jīng)有PM向我說：怎么能這樣，原來都簽字了，現(xiàn)在怎么又變了，怎么簽了字都不算？我說：你怎么辦？去他辦公室哭能解決問題不？
c、簽字驗收的人，對于項目的最終驗收是否具備絕對的發(fā)言權？人家弄個副主任給你簽模塊驗收，等最后發(fā)飆的時候主任去，一句：模塊驗收的事情我不知道，我今天提的問題你們必需做到，要不我不簽字驗收，誰要驗收誰去簽字。能氣的你想把你的IBM扔過去。
不管怎樣，事情做的差不多了，項目也超期了，總是要驗收的。
上面那個兄弟說了，提前吹風是很重要的。這小風慢慢的吹，一個人一個人的吹，爭取在吹風的時候把問題都提前了解清楚，然后找合理的理由去說服吧。
現(xiàn)在能不能驗收了？估計還是比較懸吧？總有不好擺平的用戶的，跟你叫上勁了也不是什么奇怪的事情。那么就上下活動，團結可以團結的力量，判斷清楚問題和形勢后開個驗收預備會吧。
你不給我驗收，那么我要求開個預備會“誠懇”并且“認真”的聽用戶的意見和問題，并給出一個解決問題的時間表，在這個時間表內，誰不配合、誰不能完成任務都要有相應的處理辦法。我曾經(jīng)利用中午吃飯的時間和電廠一把手聊天，除了沒說項目的事情，聊了很多話題，還記得有：應用數(shù)學是什么專業(yè)，能做什么；拉普拉斯方程；電網(wǎng)潮流計算；電廠主輔分離好不好；他們電廠有沒有必要成立檢修公司……。一直聊到下午上班，然后跟到辦公室跟他談預備會的事情，最后要了他一句話：開會的時候我肯定最后發(fā)言，你說什么我強調什么，怎樣？
開會的時候，廠長還多說了一句話：“人家D經(jīng)理在這邊很久了，也很辛苦，我認為他們的工作很有成績，今天人家也拿出最后的驗收計劃了，態(tài)度非常好。今天我還要說的就是，那個部門不配合××公司技術人員，導致計劃不能完成，到了時間你們那個主任不簽字，我來簽字驗收，驗收完了我再找你算帳?！甭犃诉@話，心里那個爽啊。當天沒有加班，晚上喊小組兄弟們出去喝酒。
個人認為，預備會是個比較好的處理方法。行了，預備會也開了，問題都說清楚了，能不能驗收了？
答案是還有可能出什么鬼問題導致用戶提出來不驗收，對于老PM，遇到這樣的問題不奇怪吧。怎么辦呢？相信通過前期的溝通什么的，PM對用戶的心里底線應該都能把握了，而且前面你也做了這么多工作了。就差最后一點了，不解決不急死人??？
備忘吧！我都做了這么多事情了，最后這一點你還擔心我不做？但是，說好的要驗收??！總要讓我給公司一個交代啊？而且，沒按時驗收，你（用戶PM）這不也算沒完成工作啊？要不咱各退一步，你給我驗收了，我驗收報告后面給你附個備忘錄，我答應你做的都寫里面去。
事情做到這份了，PM們項目驗收了沒有？
總結篇
通過一個項目從頭到尾整個過程的簡單解釋，希望新的PM及技術轉型的PM們能夠從中間得到點自己需要的東西。也算我沒有白花這么多時間去打字。
寫了不少，回頭再來提煉下：
項目開始階段，分析清楚合同相關文件很重要，從中間發(fā)現(xiàn)以后需要注意的“特殊”功能要求；
在項目開始階段和用戶明確項目的管理體系：報告、例會、需求變更等；
排一個比你覺得能實現(xiàn)的計劃周期壓縮20％的總體計劃；
根據(jù)自己的能力和優(yōu)勢選擇一個理想的介入項目的方法：或者高調（這個不是太好玩）、或者認真、或者技術很好、或者理解行業(yè)需求……
開始階段，多和用戶溝通，不一定要有問題才去找用戶，電廠的主管們大多時間還是教多的，多接觸接觸是好事；
剛開始的項目報告一定要言之有物，能客觀反應問題（是用戶的就指出來，是自己的錯誤也老實寫上去），讓用戶領導覺得可以通過這樣的形式了解項目情況，并愿意參加例會；
滾動計劃一定要準確，不要滾來滾去，事情總完成不了，會導致用戶對于你計劃能力和做事能力的懷疑；
排雷工作早點做，不要等驗收前3個月才想起來；
PM就是PM，不要再去做技術高手，對小組兄弟多些指導，少做點具體事情，多花點時間去考慮項目整體的事情；
對于驗收，不要一根筋的去考慮，做多種方案準備，然后考慮清楚后再和用戶去談；
最后，關心項目組兄弟們的生活，人性化點。