IT肥蝦-經濟&科技&專案管理

Project Plan Versus Project Management Plan

 【軟體專案管理】(林信惠、黃明祥、王文良合著的)4.5專案計畫書一節，僅說明：「軟體專案計畫書是進行軟體專案規劃的主要結果，因此它代表大部分從事於專案規劃人員的意見與共識。」接著便參考”The Software Project Manager’s Handbook: Principles that work at work”(Phillips, 1998)說明專案計畫書至少應包含的項目。

書本此處並未說明專案計畫書的本質，若對應到4.1節導論，也只說：「規劃(Planning)是針對未來的工作發展出一系列可執行的方案，並提供一個合理估計資源、成本、時程的架構(framework)。」因此若整合起來，專案計畫在本書中或可定義為：「專案規劃人員針對未來的工作所發展出的一系列可執行方案與對應所合理估計資源、成本、時程架構(framework)的意見與共識。」

而專案計畫在其他規範的定義上，如CMMI-DEV v1.2中專案計畫則為：「來描述控制專案的全盤計畫。」 PMBOK 2000年版定義Project Plan為一：「a formal, approved document used to manage project execution.」其主要的作用為：

(1)指導專案執行。(Guide project execution.)

(2)記載專案規劃的假設。(Document project planning assumptions.)

(3)記載專案規劃決策所依據的替代選項。(Document project planning decisions regarding alternatives chosen.)

(4)助於利害關係人間的溝通。(Facilitate communication among stakeholders.)

(5)定義關鍵管理檢視的內容、範圍與時程。(Define key management reviews as to content, extent, timing.)

(6)提供進度衡量與專案控制的基準。(Provide a baseline for progress measurement and project control.)

但是，PMBOK的2004年版後，卻將Project Plan改為Project Management Plan，其定義為：「A formal, approved document that defines how the project is executed, monitored, and controlled.」。另外，報告的筱雯同學所提供IEEE的資料實為IEEE 1058-1998，”IEEE Standard for Software Project Management Plans”，其中所描述之要件名稱為軟體專案管理計畫，而非專案計畫。(現今該標準也已被IEEE 16326-2009，” Systems and software engineering -- Life cycle processes -- Project management”所取代。)

以下則進一步比較【軟體專案管理】、PMBOK 2000的專案計畫內容項目，以及IEEE 1058-1998與PMBOK 2008所述說專案管理計畫的內容要項。

※由於CMMI-DEV v1.2所述為專案規劃流程的特定目標及執行方法摘要，因此另寫專文－”Project Planning In 【軟體專案管理】, CMMI, PMBOK”－說明。

(1)專案計畫(Project Plan)

(A)【軟體專案管理】

(B) PMBOK 2000

(2)專案管理計畫(Project Management Plan)

(A)IEEE 1058-1998

(B)PMBOK 2008

不同於PMBOK先前的版本，2008年版特別提出了專案文件集(Project Documents)。該版以為專案的規劃流程群組除了產出專案管理計畫(Project Management Plan)外，也產生了專案文件集(Project Documents)，以為專案執行作業過程之依據，並依實際情況、適時、經正式程序，加以適當修正。其中，專案管理計畫包括共有三個基準與十二個子計畫；專案文件集則有三十八種文件類別。

從以上的列表，可以看見從專案計畫到專案管理計畫，其所涵蓋的範圍更為擴大，也更為嚴謹！其實一接觸PMBOK 2000之時，讓人非常容易對其中專案計畫的定義與其內容要項感到十分的迷惑。既然專案計畫的主要目的是要作為專案進行的指引、促進與監管的依據，那麼原則上就應該包含九個知識領域，並且要確實記載後續實作、監控與結案的作業綱要。除了定義What、When、Who、Where之外，也因說明Why、How甚至提及相關的Hints與Properties，就是所謂的5W+3H+P。因此肥蝦私下以為這也是後續PMBOK將Project Plan改為Project Management Plan，並且在2008年版中進一步闡述專案文件集的原因。

【軟體專案管理】一書參考Phillips而列示的專案計畫要項，僅是著重在專案的What、When、Who、Where，以及軟體開發的Properties，對應於相關的知識領域落只是強調所謂的triple constraints(Scope、Schedule、Cost)，以及影響三要素的quality與風險要素。這就現今的觀點而言，已是稍嫌薄弱，同樣參考Phillips的IEEE 1058-1998規範就遠較為完整，除了增加專案度量的基準與方法外，也增加了溝通等重要議題，但是IEEE還是於2009推出IEEE 16326-2009規範加以取代。

專案管理計畫雖然規範日詳，但在實務作業上，就如筱雯同學所提供伊於工作中該公司所規範的專案管理計畫範本一般。大多數的公司或團體，還是把專案管理計畫設定成死板板的樣貌，雖然都以專案軟體開發的流程設定工作的項目與對應的產出，但從其中完全看不出How！專案的規畫與實作都需要有所謂的策略與戰術，而非只有硬梆梆的要項。專案管理雖有其一定的程序與要求，但重點應該要描述出專案的執行策略，以及該策略所依據的假設與限制，相對地，這些假設與限制也是專案風險的主要來源。如果一個專案計畫或管理計畫，完全看不出該專案的作業策略，個人以為這是一個非常失敗的專案管理計畫。

此外，專案計畫既為指導專案執行所憑所據，那麼就應該要定期的review，並且依據實況進行修正與變更！而非將僅它當成一個規劃階段的產物，在專案其它階段就將它供在神桌之上。專案計畫或專案管理計畫應要如PMBOK所述，是要定期的檢討，並為每次專案管理會議中報告與討論的重點之一，其內容應該要根據專案內外環境的變化，立基於專案利害關係人共識的因應策略，以及專案實際上所為的調整變化，加以詳實的記載，作為專案持續期間的工作、溝通與管控基本，如此也方能作為往後專案的參考資料，即所謂的lessons learned。

針對專案與專案管理，以及專案計畫與專案管理計畫進行清楚的區別，建議讀者可參考肥蝦之前所撰寫的”Project跟Project Management的異同”。
如要真的要切實區別專案計畫與專案管理計畫的區別，就個人的觀點，依其對應的5W+3H+P，可分別加以概述如下：
(一)專案計劃書的重點：
(1)Why為什麼有這個專案。
(2)What專案所要達成策略目標的內容。
(3)When此專案在公司策略的要求上，應該要何時完成，或者每個重要時點。
(4)Who公司內部的主導部門。
(5)Properties 專案所要遵循使用公司現有的管理機制與工具。
(6)Hints 本專案可引進其它專案或利益的伏筆。
(7)How much 基於公司效益成本分析中的可支出金額，以及因應現金缺口與整體環境需要保留的資金。
(二)專案管理計劃所述的主要會集中如何達成專案的策略目標與要求：
(1)How執行專案的方法與戰略依循。
(2)What組成專案要求的成份內容。
(3)When在專案策略期限下的執行時程。
(4)Who專案工作的實際負責、執行與監控人員(小組)。
(5)Where每項專案工作的作業地點。
(6)Why每項專案工作的發展原因與使用工具的原因。
(7)Properties 專案軟體開發所使用的開發以及版本、型態管理工具。
(8)How much 基於公司所設定本專案的可支出金額下，對應工作項目所需支出的花費，因應專案管理活動的支出費用，以及因應風險所預留的金額。

以上是肥蝦於課堂上的心得，還請各位  先進們多予指教！