讓項目計劃“活”起來

一些的項目計劃，在執行的過程被抛棄了，它們看不到項目完工的一天，項目經理和項目成員也是以懷疑項目計劃的價值。

現代項目管理流派很多，據說已經超過30多種，被應用在IT項目管理中的耳熟能祥的有：國際項目管理協會IPMA的ICB知識體系（對應IPMP認證），美國項目管理協會PMI的PMBOK知識體系（對應PMP認證），以及PMI在2003年釋出的OPM3模型，英國OGC的PRINCE2方法論，另外，涉及項目管理領域的其他流派有，ISO10006項目管理品質指南，美國梅倫大學SEI的CMMI中的項目管理域，還有就是我們的國家标準那一套，等等。我們簡直處于标準的海洋！可怕的問題是，我們都還不太會遊泳。今天，讨論一下在軟體項目管理中，項目管理的問題之一------項目計劃的問題。

1.項目經理的計劃之惑。

（1）“計劃”之數量龐大。PMBOK要求有9類管理計劃，分别是：大的項目管理計劃，從屬的有範圍管理計劃、進度管理計劃、成本管理計劃、品質管理計劃、人員管理計劃、溝通管理計劃、風險管理計劃、采購管理計劃。CMMI相關要求的管理計劃有：項目計劃、項目內建管理計劃、風險管理計劃、評審計劃、溝通計劃、人力資源計劃、資源計劃、品質保證計劃、度量計劃，另外跟工程相關的有配置管理計劃、驗證與測試計劃、需求管理計劃等。加起來也有10幾個。把它們合并同類項之後，也有差不多10個計劃。搞清楚這些計劃之間的輸入輸出關系、影響關系、變更關系，以及如何把握計劃的粒度和層次，如何選擇制定計劃的工具，如何獲得計劃的一緻了解等等，這些問題對一個年輕的項目經理或者剛剛從技術崗位轉崗到項目經理的新人來說，無疑是非常頭痛的事情。

（2）“計劃”之閉門造車。很多情況下，項目經理把工作任務分解等同于項目計劃，認為項目任務分下去了，計劃也就完成了。于是，他們很快地根據生命周期模型分解出工作包，然後安排了時間順序。項目計劃就算完成了。這樣做有太多的假設：你假設了你一個人就了解了項目該做的全部工作，忽略了項目組成員可能提出來的技術風險需要的準備工作，而這個工作恰恰在關鍵路徑上。你假設了測試部門可以按時委派一組測試團隊到你的項目組，忽略了資源競争和沖突常常發生。你假設了每個工作包的工作量評估的八九不離十，而忽略你的主觀性。你假設了你對團隊的絕對的上司，而忽略了你的資深設計人員暗流湧動地跳槽計劃。你假設了上級會無條件地支援你，而忽略了上級也有上級的難處。你假設了計劃模闆告訴了你應該做的所有的事情，忽略了計劃模闆也許對你的項目不太适用。你還假設了一切事情都會順利進行，等等。你的最大的假設就是：項目計劃是你一個人的事情。這當然導緻閉門造車。這樣造出來的計劃看上去特别的“完美”，但它一定是缺乏“免疫力”的，經不起項目的風吹雨打。

（3）“計劃”之計劃。許多項目經理同時認為，計劃就是寫計劃文檔。其實，計劃文檔不過是計劃過程的産出。我們不能直接沖着結果去。一個有項目幹系人參與、項目團隊成員協作的項目計劃過程是值得我們去執行的。項目經理也要為這個過程計劃計劃。

（4）“計劃”之成本和效率。如果計劃過程需要時間、需要不同的人參與，那麼，是不是計劃的成本太高了？一些項目經理有這樣的想法。看看吧，如果你的項目規模不小、周期不短，好好地計劃計劃是非常值得的，不用猴急。有兩句古語你明白就是了：磨刀不誤砍材工。凡是預則立，不預則廢。

2.如何讓計劃“活”起來。

（1）“孕育”是決定計劃“先天能力”的關鍵。

一個計劃在出來之前，好好地研究研究，不斷地考量考量，看看曆史項目的執行記錄，找找類似項目的可取之處，有助于杜絕别人的錯誤在你這裡重演。項目啟動之前後，項目經理要關注各路項目幹系人的期望是否已經了解清楚了。如果哪個幹系人沒發現，如果他的期望被遺漏，項目的目标一定不能圓滿完成。項目經理要關注影響項目成功的幾個關鍵因素。如果這些關鍵因素沒找到，項目的計劃一定無法涵蓋與此相比對的工作包（比如：對關鍵開發人員缺失的忽視，導緻招募工作計劃被遺漏）。項目經理要關注客戶對需求的明确程度，不明确的需求可能蘊藏着返工風險或者項目範圍失控風險。如此等等。通過這些反複地質疑，不斷地識别出來各種可能的不确定因素，孕育出宏觀的對策，使得項目的計劃不僅滿足基本管理的要求，更重要的是滿足這個特定項目的特殊要求。

（2）“優生”是計劃可行性的保障。

       當項目經理通過前期對項目環境和項目特點的宏觀了解之後，這個時候，就可以開始制定項目計劃了。前面說過，項目經理不能抱着閉門造車的想法開始項目計劃的制定。一定要遵從項目計劃的方法論，安排好制定計劃的工作序列、人員參與、技術工具、輸出成果等環節。（特别是集結大家的智慧，讓計劃也流淌着大家的心血，這樣的話，執行起來，大家的抗拒心理也就沒有了。底層的計劃尤其如此。）

    首先把項目生命周期模型和産品生命周期模型的複合起來，建立項目的過程模型。确定最高層次的項目階段和裡程碑。一般來講，層次越高的計劃穩定性越好、指導性越強、生命力也最持久。

    第二步，根據項目的特點，對拟使用給項目的計劃進行裁剪與合并，确定計劃的優先級和重要性差別。項目經理不可能在所有的工作上平均配置設定管理精力，必須區分重點和非重點領域，進而對應重點性不同的計劃。比如說：項目不涉及外購構件或裝置，那麼裁減掉采購計劃。項目的團隊是從上一個項目整體繼承過來的，并且兩個項目技術領域一緻，那麼人力資源計劃就可以非重點考慮。等等。這樣下來，計劃的數量就會較少，不同計劃的工作量也會所有差別。

    第三步，關鍵團隊成員一起識别項目的任務以及任務間的關系，建立高層的WBS，并把關鍵任務包含進去。這是一個關鍵的步驟，決定着計劃的可執行性和穩定性。如果WBS分解太細，那麼執行起來月曆的變動可能性就越大，導緻計劃與執行不一緻，失去指導性。如果太粗，項目跟蹤起來風險就大。取得平衡很重要，慢慢在實踐中體會吧。

    接下來，進行成本和進度估計。這裡邊有很多方法論、技術和工具的應用。專業地做好這一步工作，確定資源到任務的配置設定是合适的。

   最後，為項目假設和風險準備足夠的管理預留，并確定需要的時候可以得到。管理預留的價值是為那些無法确定工作量的特殊任務給它的執行者提供“意外”的資源和時間。比如：某個技術預研，并不知道該花多少時間。另一個價值是在裡程碑處，或者其他任何你認為需要的時間的河任務上，提供時間緩沖和處理應急的機會。

   這一系列規範的、充分參與的工作之後，一定帶來一個“優生”的計劃。

（3）把“計劃”放到項目中去“鍛煉”。

    許多計劃經不起項目的執行，一執行就出問題。其實問題沒那麼複雜。首先不要做這樣的計劃：“12日結束需求分析，13日開始系統設計，...15日結束詳細設計，16日開始編碼實作。”這樣的計劃沒有階段間的管理預留，一旦前面出問題，可能會引起連鎖反應，導緻項目計劃失去意義，影響大家對計劃的信任。如果很不幸你做了這樣的計劃，那我告訴你怎麼辦。在執行過程中提前趕工，給後面擠出管理緩沖時間。我常常看到當項目延時了，項目經理痛苦的調整項目的Schedule，工作量很大。為什麼？還是沒有管理預留。這就是把計劃做得太“死”，結果導緻計劃本身不能适應變化。項目經理要不斷地評估計劃的可行性，發現計劃的不足，修正計劃的缺陷，確定計劃的适度寬松。

（4）讓“計劃”适應“變化”。

    既然項目的變化是一個普遍現象，那麼怎麼應對呢？如何使得你的計劃适應它的變化呢？如何處理突發事件對項目計劃的影響呢？新的風險，新的變更，新的缺陷，等等這些問題在你不留意的時候，它總會出現。怎麼辦呢？如果管理預留已經黔驢技窮了，那麼，有兩個方法可以處理。一是，不要把自己的團隊變成外部事件的應激響應者。外部一有請求或刺激，你就馬上做出反應，這是不對的。項目經理要明确地知道，自己才是項目的指揮棒，不是外部的客戶或者某種權力。這是權利和義務均等的原則。賦予你義務的同時，你也要擁有相應的權利。比如：決定權。對于那些新的需求要敢于拒絕和延期。對于變更，要在不影響任務執行和不造成集體返工的前提下，有限接受，小範圍調整進度。如果變更影響很大，那麼必然導緻計劃的變更。這就是第二個方法：提出計劃變更。計劃變更一般都基于項目外部環境的大的變化和新的重大缺陷或風險的發現，是以，這是不可預知的，應該向上級提出新的資源、工期和成本請求。變更後的計劃就可以繼續指導新的工作了，就可以适應新的變化了。

   最後，強調一點，管理成本存在一些不可預知的成本，這些要不斷地通過項目實踐獲得經驗值。