專案計劃的重要性是質毋庸贅述的，而在我們的專案中，它究竟又起了什麼樣的作用呢？

談到專案計劃，不得不從計劃編制的依據說起。以我自己的理解來看，專案計劃誕生的簡要流程應該是：

根據RFQ/RFP編制整體的專案規劃，在專案規劃中對於專案做出明確的定義。專案的定義包括：目標、範圍描述、進度要求、專案階段定義、關鍵任務及里程碑等。
參照專案規劃中的進度要求，對專案的整體目標及關鍵任務進行工作分解，生成WBS。
依據WBS編制專案整體計劃，在計劃中加入人力資源、工具、裝置等資訊。當然，還需要定義專案日曆，資源費率等相關資料。

從整體計劃中派生滾動計劃，滾動計劃可以根據經驗和實際要求定義為W/W+n的周計劃。W相對固定，W+n根據W的執行情況適當調整。接下來就是計劃的執行了，如果一切順利，你會實施一個成功的專案。

可是，事實是這樣嗎？！有緣看到這些文字的朋友們，你們是在Enjoy這樣的一個過程嗎？不幸的是我看到的很多專案並不如此。

不知下面的場景大家是不是有所經歷，

Sales為了拿下單子，不切實際的答應客戶的“無理”要求，包括範圍、交付期等。負責實施的PM在接收專案後，發現目標根本不能在期限內達成，甚至無法達成。PM以及專案團隊中的其他成員開始埋怨Sales沒有事先與他們進行充分的溝通。雖然在專案前期，PM或其他負責專案交付的人員，可能有機會與客戶進行溝通，但如大家所知，他們和客戶的意見在大多數情況下不是能夠達到完全一致的。差異總會存在，或多或少。當客戶堅持的情況下，決策的天平會傾向哪邊呢？最後，PM被迫接受錯誤的決定，去實現客戶的“夢”。一旦專案開工，專案經理只有強忍著心中的痠痛，做著自己都不相信的專案計劃，去迎接更猛烈的暴風雨。

在這種情況下，專案經理如果不能透過有效溝通說服客戶和老闆，切合實際的編制專案計劃並付諸實施，專案前景堪憂。

Tip:把問題說出來，並設法解決。早期的時候，你可能會很痛苦，可是如果把問題捂到後期，專案會死，你也會死，而且你死的比專案更難看。

寫完上面的片段，發散地想到專案計劃編制中專案經理自身的問題。一個簡單的例子，很多專案經理都會用MS Project來編制專案計劃，卻不肯花時間多學一些專案管理的方法論和軟體使用的知識。把Project當Excel來用，只簡單的編制任務列表和進度計劃，不定義里程碑，不定義前置任務，不建立基準計劃。真不知道他們如何利用工具對專案做到有效的跟蹤和控制。下面是一個令人髮指的Grant圖，供大家參考。

最後，把自己對於計劃編制的一些理解分享給朋友們，希望有所幫助。

以目標為導向，認真進行工作分解；
計劃是為了實施服務的，不要為了計劃做計劃；
充分溝通，編制切實可行的計劃；
注意對於計劃的跟蹤和調整，建立基準是必要的。
注意積累經驗，計劃的編制離不了經驗 [@more@]

專案計劃——看上去很美（轉）

相關文章