專案管理過程攻略——送給初為專案經理的朋友

在說專案管理問題的之前，有必要溫習下有關專案管理的一些基本知識，瞭解了這些基本的東西，應該有助於我們去理解專案協調工作都要做哪些事情。
關於專案的定義：專案是為完成某一獨特的產品和服務所做的一次性努力。
一次性——專案有明確的開始時間和結束時間。當專案目標已經實現，或因專案目標不能實現而專案被終止時，就意味著專案的結束。
獨特性——專案所創造的產品或服務與已有的相似產品或服務相比較，在有些方面有明顯的差別。專案要完成的是以前未曾作過的工作，所以它是獨特的。
關於專案管理的定義： 專案管理是在專案活動中運用知識、技能、工具和技術，以滿足和超過專案干係人對專案的需求和期望。專案管理就是把各種資源應用於專案，以實現專案的目標。
專案管理是一個綜合類的學科，涉及多種知識領域：
專案範圍管理
專案時間管理
專案成本管理
專案質量管理
專案人力資源管理
專案溝通管理
專案風險管理
專案採購管理
專案綜合管理
專案具有明確的目標，且是一個一次性的活動過程，所以專案經理的任務就是去排程資源利用相應的管理手段去完成專案，滿足或者超過專案“干係人”對專案的預期和希望。
那 麼“專案干係人”就是專案經理在專案過程中始終要去關注的一些人，因為專案最終的成敗，專案的過程都與這些人有關係，甚至這些人就能決定一個專案的命運。 還有一點我們必需承認：只要有組織就有政治。哪怕組織再小，只要能夠稱為“組織”，那麼這個組織中一定存在著政治。所以，專案經理在專案開始階段一定要識 別專案干係人並能察覺干係人之間的政治關係以及你執行這個專案的組織內的政治關係。當明確的找出了專案干係人並識別了其中的政治關係，那麼專案經理就可以 在這些人中間根據需要展開協調工作了。
這是專案協調的最重要的部分，也就是使用者協調工作。
我們必需承認在專案實施公司內部由於資源分配等問題，專案經理有必要也必需就這些問題在公司內部展開協調工作，這是專案協調中的內部協調工作。
在專案組內部對於任務分配、工作分工等問題，專案經理同樣要進行專案組內部協調工作，有時候，這個協調工作甚至比使用者協調工作更棘手、更難以操作。
在 專案開始階段，一般我們都用過一次會議來明確專案的計劃等等東西。在這個會議中，同樣會成立一個“專案管理委員會”之類的臨時機構，這個機構的人員一般由 雙方專案經理、高層領導等人員組成，主要目地就是有人能夠在專案出現關鍵問題的時候能夠商議和決策。不過話說回來，這個委員會一般都是虛無縹緲的，基本就 是一個空架子，很少有專案真的靠這個機構來管理問題（雙方高層領導如果整天陷入專案中事務性的工作，這個專案恐怕也懸了。），基本還是靠雙方PM來協調， 或者出現具體問題找分管領導協商解決。
不管怎樣，這個“委員會”之類的組織中的使用者，顯然都是這個專案的“干係人”，不是干係人我想他不會答應去 進這個委員會。那麼這是PM們識別出來的第一批“干係人”。還有誰是“干係人”呢？一般來說，主任級別的使用者都是我們不能忽略的，尤其是檢修、執行、經 營、物資這幾個部門的一把手（用電力專案冠軍客戶組成為例）。
下面說下有關政治的問題。我們不能指望一個企業一團和氣，企業內部存在2個以上的“ 陣營”是司空見慣的。一般來說企業內部分管你這個專案的領導都是一個副廠或者總工之類的領導。不管是誰管這個專案，作為PM你還是首先想辦法弄清楚這個企 業高層之間微妙的關係比較好。知道關你這個專案的領導，在那個陣營有哪些對手、和哪些人關係好，下面哪些中層“是他的人”，這在PM日後進行專案運作和項 目協調是很關鍵的。
作為廠級領導，即使看起來分管的是經營、生產或者是總工甚至是管後勤、三產的，並沒有進入“委員會”，作為PM，最好把他們都列入“干係人”來管理比較好。
來，回頭總結下。
首先找到干係人，簡單的說對於電力專案來說，從廠長開始的廠級領導到關鍵部門的一把手，再加上使用者PM，這些都是專案干係人。
第二步，快速弄清楚企業的政治環境。這事情說起來容易，真要弄清楚還真不好辦。因為這本來就是敏感的事情，誰願意給你說清楚啊。我曾經在專案開始的時候去問這些問題，人家的回答：我們廠的事情，給你說三天三夜你也弄不清楚。

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