軟體專案管理第五週課程心得-PP vs. PMP

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 【軟體專案管理】, PMBOK, CMMI”－說明。

(1)專案計畫(Project Plan)

(A)【軟體專案管理】

項次	項目
1	導論
1.1	計畫目標
1.2	作業範圍
1.3	計畫內容摘要
1.4	參考文件
2	專案計畫的工作內容
2.1	專案計畫的工作內容說明
2.2	工作計畫與工作項目
2.3	交付的產品項目與日期
2.4	發展時程與管制點
2.5	風險評估與因應的對策
2.6	開發方法論、技術與工具
3	專案的資源估計
3.1	專案的組織
3.2	人力需求與成本估計
3.3	硬體、軟體的需求與成本估計
3.4	外包商的資源需求與成本估計
4	相關計畫
4.1	品質計畫
4.2	型態管理計畫
4.3	整合計畫
5	附錄
5.1	外包的專案計畫
5.2	其他規定與限制

(B) PMBOK 2000

項次	項目
1	Project Charter.
2	A description of the project management approach or strategy.
3	Scope Statement
4	Baseline scope document
5	Cost estimates, schedule, responsibility assignments for each deliverable.
6	Performance measurement baselines for technical scope, schedule, cost.
7	Major milestones and target dates for each.
8	Key or required staff and their expected cost(effort).
9	Risk management plan
10	Subsidiary management plans
10.1	Scope management plan
10.2	Schedule management plan
10.3	Cost management plan
10.4	Quality management plan
10.5	Staffing management plan
10.6	Communications management plan
10.7	Risk response plan
10.8	Procurement management plan
11	Open issues and pending decisions.

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

(A)IEEE 1058-1998

章節	項目
1	概觀
1.1	專案摘要
1.1.1	目的、範圍與目標
1.1.2	假設與限制條件
1.1.3	專案交付項目
1.1.4	期程與預算摘要
1.2	軟體專案管理計畫的沿革
2	參考資料
3	定義
4	專案組織
4.1	對外溝通管道
4.2	內部架構
4.3	角色與職責
5	管理流程規劃
5.1	專案啟動規劃
5.1.1	預估規劃
5.1.2	人力規劃
5.1.3	資源籌獲規劃
5.1.4	專案人員訓練規劃
5.2	工作規劃
5.2.1	工作項目
5.2.2	時程規劃
5.2.3	資源規劃
5.2.4	預算規劃
5.3	管制規劃
5.3.1	需求管制規劃
5.3.2	時程管制規劃
5.3.3	預算管制規劃
5.3.4	品質管制規劃
5.3.5	回報規劃
5.3.6	度量資料蒐集規劃
5.4	風險管理規劃
5.5	專案結案規劃
6	技術流程規劃
6.1	流程模型
6.2	方法、工具與技術
6.3	基礎建設規劃
6.4	產品接收規劃
7	支援流程規劃
7.1	構型管理規劃
7.2	驗證與確認規劃
7.3	文件作業規劃
7.4	品質保證規劃
7.5	審查與稽核規劃
7.6	問題解決規劃
7.7	下包商管理規劃
7.8	流程改善規劃
8	附帶事項規劃
	附錄
	索引

(B)PMBOK 2008

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

專案管理計畫 (Project Management Plan)
項次	項目		PMBOK章節
1	Change management plan		4.2.3
2	Configuration management plan		4.2.3
3	Scope management plan		5.0
4	Requirements management plan		5.1
5	Schedule management plan		6.0
6	Cost management plan		7.0
7	Quality management plan		8.1
8	Process improvement plan		8.2
9	Human resources plan		9.1
10	Communications management plan		10.2
11	Risk management plan		11.1
12	Procurement management plan		12.1
13	Scope baseline -Project scope statement -WBS -WBS dictionary		5.3 5.2 5.3 5.3
14	Schedule baseline		6.5
15	Cost performance baseline		7.2
專案文件集 (Project Documents)
項次	項目	流程群組	PMBOK章節
1	Stakeholder requirements (Requirements Documentations)	P	5.1
2	Assumptions log (Sub item of Project document)	P,M	11.2.1
3	Project statement of work	I	4.1.1
4	Project charter	I	4.1.3
5	Work performance information	E	4.3.3
6	Requirements traceability matrix	P	5.1.3
7	Activity list	P	6.1.3
8	Activity attributes	P	6.1.3
9	Milestone list	P	6.1.3
10	Activity cost estimates	P	6.3.3
11	Resource breakdown structure	P	6.3.3
12	Activity resource requirements	P	6.3.3
13	Activity duration estimates	P	6.4.3
14	Basis of estimates	P	7.1.3
15	Project funding requirements	P	7.2.3
16	Budget forecasts	M	7.3.3
17	Work performance measurements	M	5.5.3;6.6.3;7.3.3
18	Quality checklists	P	8.1.3
19	Quality metrics	P	8.1.3
20	Quality control measurements	M	8.3.3
21	Responsibility assignment matrix	P	9.1.2
22	Project organizational structure (Project organization charts) (Sub item of Human resource plan)	P	9.1.3
23	Roles and responsibilities (Project organization charts) (Sub item of Human resource plan)	P	9.1.3
24	Resource calendars	E	9.2.3;12.2.3
25	Team performance assessments	E	9.3.3
26	Stakeholder analysis	I	10.1.2
27	Stakeholder register	I	10.1.3
28	Stakeholder management strategy	I	10.1.3
29	Issue log	E	9.4.2;10.4.1
30	Change log	E	10.4.1
31	Performance reports	M	10.5.3
32	Risk register	P	11.2.3
33	Teaming agreements	P,E	12.1.1;12.2.1
34	Source selection criteria	P	12.1.3
35	Procurement documents (Procurement documentation)	P,M	12.1.3 (12.3.3)
36	Qualified sellers list	E	12.2.1
37	Seller proposals	E	12.2.1
38	Contracts (Procurement contract award)	I,P E	4.1.1;7.2.1;12.2.3

從以上的列表，可以看見從專案計畫到專案管理計畫，其所涵蓋的範圍更為擴大，也更為嚴謹！其實一接觸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 基於公司所設定本專案的可支出金額下，對應工作項目所需支出的花費，因應專案管理活動的支出費用，以及因應風險所預留的金額。

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