2014年12月16日 星期二

自從筆者在2011年7月出版《人人都可以成為PMP大師:國際專案管理師認證寶典(Ⅰ.祕笈篇, Ⅱ.關鍵詞篇, Ⅲ.題庫篇)》套書(ISBN:978-986-86326-2-2,可以到博客來網路書局購買)之後,開闢了華人學習PMP®的一條新道路:從「樹狀結構」線型思維模式轉移到「網狀結構」系統思維模式,獲得許多讀者的共鳴,一致認為這個思維模式的轉移(Paradigm Shift)正是晉升PMP大師的必經之路。

美國專案管理協會PMI® (Project Management Institute)每四年會修訂PMI®專案管理標準,其中以PMBOK® Guide(A Guide to the Project Management Body of Knowledge)最受到業界重視,根據2012年12月最新出版的PMBOK® Guide Fifth Edition(簡稱PMBOKG5)可以看出PMI®編修小組是很用心在修訂專案管理標準,許多在先前第四版(PMBOKG4)錯誤或不適當的地方都做了適度的修正,不過由於校對工作不夠嚴謹,在PMBOKG5中仍然發現許多明顯的圖表錯誤,身為PMBOKG5草案審查員之一(筆者的名字Frank MC Lin列在PMBOKG5第491頁中),本系列文章《PMP大師對PMBOK® Guide第五版的審查意見》就是要來談PMI®編修小組所做的這些改善的影響,同時討論PMBOKG5某些尚未被改正的錯誤。

從2013年7月31日起將正式成為PMP®認證考試命題範圍的PMBOKG5是由10個知識領域和5個流程群組的47個流程所組成,首先介紹PMBOKG5系統架構圖「十五系統圖」,請讀者熟讀,因為在本系列文章中會時常參考到這張圖。



首先來看PMI®編修小組究竟對PMBOK® Guide做了哪些變更?

在PMBOKG5的47個流程中,每個流程都是由輸入項目(I)、工具&技術(TT)和輸出項目(O),也就是ITTO,所組成。基本上,流程的輸入項目(I)和輸出項目(O)應該是文件(名詞),工具&技術(TT)應該是做法(動詞),不過在PMBOKG4中還會看到一些名詞與動詞混用的ITTOs,因此在PMBOKG5中,PMI®編修小組重新針對每一個專案管理流程的ITTOs做了下列6項規定,以確保PMBOKG5之ITTO各個欄位項目的一致性。

1. ITTO基本規則:
● 流程的輸入項目必須是該流程的關鍵文件
● 流程的輸出項目必須是其他流程的輸入項目,除非它是終端輸出項目或是已包含在流程文件中
● 流程的輸入項目必須是其他流程的輸出項目,除非它是來自專案外部

2. 專案文件規則:
● 在ITTO輸入欄中,如果輸入項目是主要專案文件,它必須明列
● 在ITTO輸出欄中,特定專案文件在第一次做為輸出項目時必須明列,之後出現在輸出欄中時會以「專案文件更新」呈現,然後在對應章節中再另加描述

3. 專案管理計畫規則:
● 在ITTO輸入欄中,如果專案管理計畫的子計畫和基準是主要的輸入項目,它必須明列
● 在ITTO輸出欄中,專案管理計畫的子計畫和基準是會以「專案管理計畫更新」呈現,然後在對應章節中再另加描述
● 在ITTO輸入欄中,會產生子計畫的規劃流程,專案管理計畫必須明列
● 在監控流程中,主要的輸入項目必須是「專案管理計畫」,而不是特定的子計畫和基準,輸出項目則是以「專案管理計畫更新」呈現,而不是特定子計畫的更新

4. 流程輸入欄EEF/OPA描述參考規則:
● 當提到EEF/OPA時,應包含對應章節的描述以及2.1.4(OPA)及2.1.5(EEF)的描述

5. 其他一致性規則:
● 一律使用「專案文件更新」和「組織流程資產更新」,而非特定子計畫的更新
● 文件標題不大寫

6. 表列順序規則:
● 輸入欄和輸出欄:專案管理計畫、子計畫和基準先列
○ 專案管理計畫最先,子計畫其次,基準最後
○ 計畫如果是主要輸出項目,必定先列
● 輸入欄WPD/WPI/WPR必列在EEF之緊鄰前一位
● EEF和OPA照此順序列於輸入欄最後
● 工具&技術欄中「會議」永遠列在最後一項
● 輸出欄中的更新項目按照下列順序排列
○ 專案管理計畫更新
○ 專案文件更新
○ 企業環境因素更新
○ 組織流程資產更新

除了上述6項規定之外,PMI®編修小組還做了下列主要的修定:
● PMBOKG5_02:流程名稱與編號的變更
● PMBOKG5_03:知識領域的變更
● PMBOKG5_04:流程群組組件的變更
● PMBOKG5_05:流程群組關係的變更
● PMBOKG5_06:專案資訊模型的變更
● PMBOKG5_07:規劃流程和子計畫的變更

PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_02:流程名稱與編號的變更〉
PMBOK® Guide的流程名稱和編號都是獨一無二的,正好可以做為流程的識別。流程的編碼就是該流程在PMBOK® Guide中出現的章節順序,譬如流程「發展專案許可證」在第4章第1節出現,該流程的編號就是4.1;流程「發展專案管理計畫」在第4章第2節出現,該流程的編號就是4.2;依此類推。
PMBOKG4原有42個流程,PMBOKG5增加為47個流程。PMI ®編修小組在PMBOKG5中,總共新增加5個規劃流程,其中有4個流程:「規劃範圍管理」(流程5.1)、「規劃時程管理」(流程6.1)、「規劃成本管理」(流程7.1)以及「規劃關係人管理」(流程13.2)是用來產生4個子計畫:「範圍管理計畫」、「時程管理計畫」、「成本管理計畫」以及「關係人管理計畫」。



還有一個新增加的流程「控管關係人全心投入」(流程13.4)雖然和產生子計畫無關,卻和PMBOKG5新增的第十三章〈專案關係人管理〉相關,原來PMI ®編修小組除了在第十三章中增加「規劃關係人管理」(流程13.2)之外,還將PMBOKG4第十章原有的「辨識關係人」(PMBOKG4流程10.1)和「管理關係人期望」(PMBOKG4流程10.4)移到第十三章,並調整為「辨識關係人」(流程13.1)和「管理關係人全心投入」(流程13.3),另外再增加 「控管關係人全心投入」(流程13.4),讓第十三章在起案、規劃、執行、監控4個流程群組各有一個流程。

由於PMI ®編修小組將PMBOKG4第十章原有的「辨識關係人」和「管理關係人期望」移到第十三章,因此在PMBOKG5的第十章〈專案溝通管理〉就只保留負責規劃、執行、控管溝通的三個流程,並調整其流程名稱和編號;
1. 名稱從「規劃溝通」改為「規劃溝通管理」(編號從10.2改為10.1)
2. 名稱從「散佈資訊」改為「管理溝通」(編號從10.3改為10.2)
3. 名稱從「報告績效」改為「控管溝通」(編號從10.5改為10.3)

另外,因為PMI ®編修小組在「專案範圍管理」、「專案時程管理」和「專案成本管理」這三個知識領域中,各增加一個流程(流程5.1/6.1/7.1),也就是在PMBOKG5的第四、五、六章各增加一個小節,並將原有章節往後移,因此這三個知識領域原有的流程編號就做了下列調整,其中除了「驗證範圍」(Verify Scope, PMBOKG4流程5.4)改名為「確認範圍」(Validate Scope, PMBOKG5流程5.5)之外,其餘都仍維持原有流程名稱:
一、 規劃流程群組
1. 收集需求(編號從5.1改為5.2)
2. 界定範圍(編號從5.2改為5.3)
3. 產生WBS(編號從5.3改為5.4)
4. 界定活動(編號從6.1改為6.2)
5. 排序活動(編號從6.2改為6.3)
6. 估算活動資源(編號從6.3改為6.4)
7. 估算活動工期(編號從6.4改為6.5)
8. 發展時程(編號從6.5改為6.6)
9. 估算成本(編號從7.1改為7.2)
10. 決定預算(編號從7.2改為7.3)
二、 監控流程群組
1. 驗證範圍改為確認範圍(編號從5.4改為5.5)
2. 控管範圍(編號從5.5改為5.6)
3. 控管時程(編號從6.6改為6.7) 
4. 控管成本(編號從7.3改為7.4)

最後PMI ®編修小組在PMBOKG5中,將規劃流程群組會產生子計畫的流程名稱一律改為「規劃○○管理」,並將監控流程群組的流程名稱都改為「控管○○」,但是仍然維持原有流程編號,需要調整流程名稱的有下列7個流程:
一、 規劃流程群組
1. 流程8.1(名稱從「規劃品質」改為「規劃品質管理」)
2. 流程9.1(名稱從「發展人資計畫」改為「規劃人資管理」)
3. 流程12.1(名稱從「規劃採購」改為「規劃採購管理」)
二、 執行流程群組
1. 流程4.3(名稱從「指揮與管理專案執行」改為「指揮與管理專案工作」)
三、 監控流程群組
1. 流程8.3(名稱從「執行品質控管」改為「控管品質」)
2. 流程11.6(名稱從「監控風險」改為「控管風險」)
3. 流程12.3(名稱從「行政管理採購」改為「控管採購」)



除了變更流程名稱與編號之外,PMI®編修小組還做了哪些修定?


PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_03:知識領域的變更〉
PMBOK® Guide的知識領域(Knowledge Area)代表由完整的觀念、項目和活動所組成的專業領域、專案管理領域或是特定領域,每個知識領域自成一章,每個章節代表一個流程,章節順序就是流程編號。

原本PMBOKG4只有9個知識領域,從第四章至第十二章分別介紹所屬流程;PMI ®編修小組將PMBOKG5擴充為10個知識領域,新增加一個「專案關係人管理」知識領域,並將原本PMBOKG4〈第十章 專案溝通管理〉拆分成PMBOKG5〈第十章 專案溝通管理〉和〈第十三章 專案關係人管理〉兩章,這是因為「專案溝通管理」和「專案關係人管理」是兩個不同的知識領域,溝通需要和關係人需要的管理是專案成功的兩個不同的關鍵因素,兩者一樣重要。這樣的切割有下列好處:
1. 專案管理不只專注在管理不同關係人團體的期望,還要主動地確保在決策和專案活動中,還要專案關係人能夠在適當層級全心投入
2. 和「專案關係人全心投入是專案成功關鍵」的研究結果一致
3. 增強PMBOK® Guide和專案管理標準的一致性
4. 和ISO 21500標準強調關係人管理的想法一致
5. 讓「專案溝通管理」專注在收集、儲存、組織、散佈專案資訊此一溝通活動主要目標

PMBOKG5的〈第十章 專案溝通管理〉就只保留負責規劃、執行、控管溝通的三個流程,也就是:「規劃溝通管理」(流程10.1)、「管理溝通」(流程10.2)、「控管溝通」(流程10.3);而在新增加的〈第十三章 專案關係人管理〉中,除了將PMBOKG4原有的「辨識關係人」(PMBOKG4流程10.1)和「管理關係人期望」(PMBOKG4流程10.4)調整為「辨識關係人」(流程13.1)和「管理關係人全心投入」(流程13.3之外,還增加了二個新流程;如此一來,PMBOKG5的〈第十三章 專案關係人管理〉共有4個流程:「辨識關係人」(流程13.1)、「規劃關係人管理」(流程13.2)、「管理關係人全心投入」(流程13.3)、「控管關係人全心投入」(流程13.4),「專案關係人管理」知識領域就更具一致性和完整性。



若是不分流程群組,PMBOKG5的47個流程所分屬的10個知識領域如下:
1. 專案整合管理知識領域(6個流程)
A. 發展專案許可證(流程4.1) 
B. 發展專案管理計畫(流程4.2)
C. 指揮與管理專案工作(流程4.3)
D. 監控專案工作(流程4.4) 
E. 執行整合變更控管(流程4.5)
F. 結束專案或階段(流程4.6) 

2. 專案範圍管理知識領域(6個流程)
A. 規劃範圍管理(流程5.1) 
B. 收集需求(流程5.2)
C. 界定範圍(流程5.3)
D. 產生WBS(流程5.4)
E. 確認範圍(流程5.5)
F. 控管範圍(流程5.6)

3. 專案時程管理知識領域(7個流程)
A. 規劃時程管理(流程6.1)
B. 界定活動(流程6.2)
C. 排序活動(流程6.3)
D. 估算活動資源(流程6.4)
E. 估算活動工期(流程6.5)
F. 發展時程(流程6.6)
G. 控管時程(流程6.7)

4. 專案成本管理知識領域(4個流程)
A. 規劃成本管理(流程7.1)
B. 估算成本(流程7.2)
C. 決定預算(流程7.3)
D. 控管成本(流程7.4)

5. 專案品質管理知識領域(3個流程)
A. 規劃品質管理(流程8.1)
B. 執行品質保證(流程8.2)
C. 控管品質(流程8.3)

6. 專案人資管理知識領域(4個流程)
A. 規劃人資管理(流程9.1)
B. 籌組專案團隊(流程9.2)
C. 發展專案團隊(流程9.3)
D. 管理專案團隊(流程9.4)

7. 專案溝通管理知識領域(3個流程)
A. 規劃溝通管理(流程10.1)
B. 管理溝通(流程10.2)
C. 控管溝通(流程10.3)

8. 專案風險管理知識領域(6個流程)
A. 規劃風險管理(流程11.1) 
B. 辨識風險(流程11.2)
C. 執行定性風險分析(流程11.3)
D. 執行定量風險分析(流程11.4)
E. 規劃風險回應(流程11.5)
F. 控管風險(流程11.6) 

9. 專案採購管理知識領域(4個流程)
A. 規劃採購管理(流程12.1)
B. 執行採購(流程12.2)
C. 控管採購(流程12.3)
D. 結束採購(流程12.4)

10. 專案關係人管理知識領域(4個流程)
A. 辨識關係人(流程13.1)
B. 規劃關係人管理(流程13.2) 
C. 管理關係人全心投入(流程13.3)
D. 控管關係人全心投入(流程13.4)

除了變更知識領域之外,PMI®編修小組還做了哪些修定?
PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_04:流程群組組件的變更〉
無論專案生命週期的簡繁,任何專案的專案管理都需要反覆執行「起案(I)」、「規劃(P)」、「執行(E)」、「監控(M)」、「結案(C)」等五類流程,這就是PMBOK® Guide所定義的專案管理五大流程群組(Process Group)。PMBOK® Guide的「流程群組」和應用領域或產業焦點無關,看似獨立卻彼此互動頻繁,個別的流程群組或流程通常在專案完成之前會被反覆執行,並在流程群組內或流程群組之間作互動,這些互動會因專案而異,其執行的順序也不盡相同。

PMI®編修小組在PMBOKG5中增加了一個知識領域,並將流程個數增加到47個,不過仍然保留PMBOKG4原有的5個流程群組,若是不分知識領域,PMBOKG5的47個流程所屬的流程群組分佈如下:
1. 起案流程群組(2個流程)
A. 發展專案許可證(流程4.1) 
B. 辨識關係人(流程13.1)

2. 規劃流程群組(24個流程)
A. 發展專案管理計畫(流程4.2)
B. 規劃範圍管理(流程5.1) 
C. 收集需求(流程5.2)
D. 界定範圍(流程5.3)
E. 產生WBS(流程5.4)
F. 規劃時程管理(流程6.1)
G. 界定活動(流程6.2)
H. 排序活動(流程6.3)
I. 估算活動資源(流程6.4)
J. 估算活動工期(流程6.5)
K. 發展時程(流程6.6)
L. 規劃成本管理(流程7.1)
M. 估算成本(流程7.2)
N. 決定預算(流程7.3)
O. 規劃品質管理(流程8.1)
P. 規劃人資管理(流程9.1)
Q. 規劃溝通管理(流程10.1)
R. 規劃風險管理(流程11.1) 
S. 辨識風險(流程11.2)
T. 執行定性風險分析(流程11.3)
U. 執行定量風險分析(流程11.4)
V. 規劃風險回應(流程11.5)
W. 規劃採購管理(流程12.1)
X. 規劃關係人管理(流程13.2) 

3. 執行流程群組(8個流程)
A. 指揮與管理專案工作(流程4.3)
B. 執行品質保證(流程8.2)
C. 籌組專案團隊(流程9.2)
D. 發展專案團隊(流程9.3)
E. 管理專案團隊(流程9.4)
F. 管理溝通(流程10.2) 
G. 執行採購(流程12.2)
H. 管理關係人全心投入(流程13.3)

4. 監控流程群組(11個流程)
A. 監控專案工作(流程4.4) 
B. 執行整合變更控管(流程4.5)
C. 確認範圍(流程5.5)
D. 控管範圍(流程5.6)
E. 控管時程(流程6.7) 
F. 控管成本(流程7.4)
G. 控管品質(流程8.3)
H. 控管溝通(流程10.3)
I. 控管風險(流程11.6) 
J. 控管採購(流程12.3)
K. 控管關係人全心投入(流程13.4)

5. 結案流程群組(2個流程)
A. 結束專案或階段(流程4.6) 
B. 結束採購(流程12.4)

記得在〈PMBOKG5_02:流程名稱與編號的變更〉曾經提到『PMI ®編修小組在PMBOKG5中,將規劃流程群組會產生子計畫的流程名稱一律改為「規劃○○管理」,並將監控流程群組的流程名稱都改為「控管○○」』,本文中就可以清楚地看到在規劃流程群組中,流程5.1/6.1/7.1/8.1/9.1/10.1/11.1/12.1以及13.2的名稱都是「規劃○○管理」,而在監控流程群組中,流程5.6/6.7/7.4/8.3/10.3/11.6/12.3 以及13.4的名稱都是「控管○○」。

除了變更流程群組的組成之外,PMI®編修小組還對流程群組之間的關係做了哪些修定?



PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_05:流程群組關係的變更〉


流程群組並不是專案生命週期的階段。專案生命週期任何一個階段(如;可行性分析或系統分析)都有可能包含所有「起案(I)」、「規劃(P)」、「執行(E)」、「監控(M)」、「結案(C)」5個流程群組的反覆流程活動,專案管理的反覆特性讓流程群組的流程在專案生命週期各個階段中被重覆使用,因此能否掌握這些流程群組之間的關係就變成專案管理成敗的關鍵因素。


雖然PMBOKG5保留PMBOKG4原有的5個流程群組,不過由於流程群組的組件內容變更了,因此PMBOKG5這5個流程群組之間的關係也做了些微調整。下圖中對流程群組之間和特定關係人的基本資料流和互動做了簡介,流程群組之間的資料流代表某一流程群組的某流程的輸出項目變成另一流程群組的某流程的輸入項目。不過這張圖是PMBOKG5所有圖中錯誤最多的一張圖,不知是PMI®編修小組的疏忽,還是美編插圖人員的誤植?不過在談這張圖的錯誤之前,筆者先來介紹PMBOKG5的5個流程群組:



1. 起案流程群組(Initiating Process Group)包含界定新專案或現有專案新階段,並且獲得贊助人之授權,以便起動專案或專案階段所需執行的流程。在這些起案流程中,起始範圍已經界定,初步財務支援也已獲得承諾,並且已辨識可能會影響專案結果的關鍵內部和外部關係人(Stakeholders)。專案若是尚未指派專案經理人,此時應該是指派專案經理人,並且授權專案經理人使用組織資源於專案上的最好時機。起案流程群組的主要目的就是要讓關係人的期望和專案目標趨於一致,讓關係人了解專案的範圍和目的,同時了解他們對專案的參與將如何確保他們的期望能夠被實現。起案流程群組協助設定專案的願景(也就是專案需要完成的目標)。

2. 規劃流程群組(Planning Process Group)包含建立專案工作範圍、界定與修訂目標、以及發展達成這些目標所需執行的流程。規劃流程群組發展執行專案所需要的「專案管理計畫」(Project Management Plan)和「專案文件」(Project Documents),對範圍、時間、成本、品質、人資、溝通、風險、採購以及關係人各層面做出規範,各個流程的互動會因專案性質而異。專案團隊應該鼓勵所有關鍵關係人,踴躍參加專案管理計畫和專案文件的發展。由於專案管理複雜的天性必須採用反覆回饋以進行額外的分析,甚至是額外的規劃;專案執行過程所引起的變更是以逐步詳盡的方式進行的,隨著專案的資訊逐漸被收集和了解,專案就需要做進一步規劃,因此專案管理規劃流程群組的流程也會一再的被執行。而由已核准的專案變更所做的更新,更會對專案管理計畫和專案文件產生重大影響,這些文件的更新能使達成既定專案範圍所需的時程、成本以及資源需求更加精確。規劃流程群組最大的效益是同時描繪成功完成專案或階段所需要的戰略和戰術,以及行動和路徑。如果規劃流程群組管理得好的話,就會較容易獲得關係人支持與全心投入。

3. 執行流程群組(Executing Process Group)由完成專案管理計畫中既定工作,以滿足專案規範所需執行的流程所組成。此流程群組涉及協調人員和資源、管理關係人全心投入、並且按照專案管理計畫整合和執行專案活動。專案執行結果可能需要對計畫或基準做更新,變更活動工期或資源可用性,產生不預期的風險;這些變動會對專案管理計畫和專案文件產生影響,可能帶動變更申請;已核准的變更申請會修訂專案管理計畫和專案文件,甚至會重建新基準;專案大部份的預算會花費在執行流程群組。

4. 監控流程群組(Monitoring and Controlling Process Group)包含追蹤及審查專案進展和績效,辨識所需要的任何專案管理計畫變更,以及起動必要變更所需執行的流程。度量和分析專案績效是採定期或在適當事件或執行出問題時實施,以辨識執行現況和專案管理計畫的差異;監控流程群組控管變更並針對可能問題建議矯正和預防措施,並根據專案管理計畫和專案績效度量基準來監督專案活動之進行,只允許已核准的變更被建置。監控流程群組不只監控流程群組本身的工作,還監控整個專案工作。

5. 結案流程群組(Closing Process Group)包含總結所有專案管理流程群組活動,以便正式完成專案、階段或合約義務所需執行的流程。結案流程群組一旦完成,驗證所有流程群組已界定的流程都已完成,準備好結束專案或階段,並正式宣告完成專案或階段。結案流程群組也會正式宣告半途而廢,或因故取消或中止的專案提前結束。

了解每個流程群組的意涵和功能之後,現在可以來看這張代表流程群組關係的圖到底錯在哪?

首先,PMBOKG5第53頁和第421頁(出現2次)的這張圖,根本就是把PMBOKG4第42頁的圖照樣搬過來,然後只將從「專案起始人或贊助人」到「起案流程群組」的第三個資料項目,從「Contract(合約)」改為「Agreements(協議)」。如果PMI®編修小組對PMBOKG4在流程群組關係上的變更只是這麼單純,筆者也不必大費周章地介紹這張圖了。

這張圖錯誤的地方還真不少,筆者目前抽不出時間重繪,只能用說的了。本文先提2個較嚴重的錯誤。

第1個錯誤
從「企業/組織」和「顧客」這2個外部實體流向「規劃流程群組」的資料項目「Teaming agreements(合夥協議,TA)」。說到「合夥協議」,這是原本只出現在PMBOKG4流程12.1和12.2的輸入項目,PMI®編修小組在PMBOKG5已經將它移除,所以不應該再出現,代表此一關係從「企業/組織」和「顧客」到「規劃流程群組」的箭號應一併去除。同樣理由,從「執行流程群組」流向「賣方」外部實體的資料項目「Procurement contract award(採購合約授予,PCA)」已經被PMI®編修小組移除,所以不應該再出現。詳細情形必須留到筆者稍後針對個別流程的審查意見之流程12.2(〈PMBOKG5_41:流程12.2的修訂與勘誤〉)才能揭曉,如果讀者想知道從「執行流程群組」流向「賣方」外部實體的資料項目是什麼,PMI®編修小組在流程12.2中是加上「Selected sellers(入選賣方,SS)」。

第2個錯誤
從「起案流程群組」流向「規劃流程群組」的兩個資料項目「關係人登記簿」和「關係人管理策略」,由於PMI®編修小組在PMBOKG5已經將「關係人管理策略」移除,所以不應該再出現。另外,由於原本在PMBOKG4中,「關係人管理策略」是唯一能從「起案流程群組」的流程10.1「辨識關係人」流到「執行流程群組」的流程10.4「管理關係人期望」,既然PMI®編修小組已經將「關係人管理策略」移除,已就是已經移除從「起案流程群組」到「執行流程群組」的唯一資料流關係,因此代表此一關係從「起案流程群組」到「執行流程群組」的箭號應一併去除。

除了變更流程群組關係之外,PMI®編修小組還做了哪些修定?



PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_06:專案資訊模型的變更〉

PMBOKG4原本的專案資訊模型是兩層式的,分為工作績效資訊(Work Performance Information,WPI)和工作績效度量(Work Performance Measurements,WPM);不過由於不明原因,錯把資訊(Information)當作資料(Data)使用,也就是把執行流程4.3「指揮與管理專案工作」的輸出項目稱為「工作績效資訊」(應該是「工作績效資料」才對)。


幸好PMI ®編修小組遵照知識管理DIKW(資料、資訊、知識、智慧)模型的慣例,將PMBOKG4的兩層式資訊模型改為PMBOKG5的三層式,改分為工作績效資料(Work Performance Data,WPD)、工作績效資訊(WPI)、工作績效報告(Work Performance Reports,WPR),其中:
1. 工作績效資料(WPD)是指執行專案工作活動所辨識的原始觀察和度量,例如:實際完工比、品質技術績效度量
2. 工作績效資訊(WPI)是指控管流程所收集的績效資料,例如:交付項目狀況、變更申請執行狀況
3. 工作績效報告(WPR)是指專案文件中有關產生決策、引發議題之工作績效資訊的實體或電子呈現,例如:狀態報告、備忘錄



如此一來,新的資料模型在執行和控管流程的輸出項目和輸出項目就具一致性與明白性。說明如下:

首先,「執行流程群組」之流程4.3「指揮與管理專案工作」的輸出項目「工作績效資料(WPD)」會流向「監控流程群組」之「確認範圍」(流程5.5)、「控管範圍」(流程5.6)、「控管時程」(流程6.7)、「控管成本」(流程7.4)、「控管品質」(流程8.3)、「控管溝通」(流程10.3)、「控管風險」(流程11.6)、「控管採購」(流程12.3)、「控管關係人全心投入」(流程13.4)等9個流程,各自產生同一個輸出項目「工作績效資訊(WPI)」。

接著,這9個控管流程的輸出項目「工作績效資訊(WPI)」都會流向「監控流程群組」之「監控專案工作」(流程4.4),產生輸出項目「工作績效報告(WPR)」。

然後,流程4.4「監控專案工作」的輸出項目「工作績效報告(WPR)」會流向「執行流程群組」之「管理專案團隊」(流程9.4)、「管理溝通」(流程10.2),以及「監控流程群組」之「執行整合變更控管」(流程4.5)、「控管風險」(流程11.6)、「控管採購」(流程12.3)等5個流程。

最後,這5個流程都會有輸出項目「專案管理計畫更新」流向流程4.2「發展專案管理計畫」以及輸出項目「專案文件更新」流向專案文件;另外除了流程10.2「管理溝通」和流程4.5「執行整合變更控管」之外,其他3個流程的輸出項目「變更申請」都會流向流程4.5「執行整合變更控管」。

除了變更專案資訊模型之外,PMI®編修小組還做了哪些修定?

PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_07:規劃流程和子計畫的變更〉

有些人老是把「計畫趕不上變化,變化抵不上老闆一句話」當作不做專案計畫(Project Plan)的藉口或理由,其實這都是因為不了解專案管理;專案計畫是立案之前用來向贊助人提案用的,等專案成立後,還必須有專案管理計畫(Project Management Plan);專案管理計畫不同於專案計畫,是會隨著專案的進行做必要的修正與更新。PMBOK® Guide的專案管理計畫是由子計畫(Subsidiary Plan)和基準(Baseline)所組成,這些子計畫和基準都會由規劃流程產生,並在執行與監控流程中被更新。



照道理每個子計畫都應該由某個流程產生,不過在PMBOKG4中,「專案範圍管理」、「專案時程管理」和「專案成本管理」這三個知識領域並沒有任何流程可以產生「範圍管理計畫」、「時程管理計畫」、「成本管理計畫」這3個子計畫。

為了讓各個子計畫和專案管理計畫的一致性,讓每一個知識領域都有一個規劃流程來產生子計畫,PMI ®編修小組除了將PMBOKG4原有5個規劃流程的名稱調整為「規劃品質管理」(流程8.1)、「規劃人資管理」(流程9.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)以及「規劃採購管理」(流程12.1),並在PMBOKG5增加4個規劃流程:「規劃範圍管理」(流程5.1)、「規劃時程管理」(流程6.1)、「規劃成本管理」(流程7.1)以及「規劃關係人管理」(流程13.2),如此一來,這9個規劃流程就會分別產生下列11個子計畫:
1. 範圍管理計畫(流程 5.1輸出項目)
2. 需求管理計畫(流程 5.1輸出項目)
3. 時程管理計畫(流程 6.1輸出項目)
4. 成本管理計畫(流程 7.1輸出項目)
5. 品質管理計畫(流程 8.1輸出項目)
6. 流程改善計畫(流程 8.1輸出項目)
7. 人資管理計畫(流程 9.1輸出項目)
8. 溝通管理計畫(流程 10.1輸出項目)
9. 風險管理計畫(流程 11.1輸出項目)
10. 採購管理計畫(流程 12.1輸出項目)
11. 關係人管理計畫(流程 13.2輸出項目)

組成專案管理計畫還有3個基準,其來源如下:
1. 範圍基準(流程 5.4輸出項目)
2. 時程基準(流程 6.6輸出項目)
3. 成本基準(流程 7.3輸出項目)

PMI ®編修小組還新訂了專案管理計畫規則:
1. 在ITTO輸入欄中,如果專案管理計畫的子計畫和基準是主要的輸入項目,它必須明列
2. 在ITTO輸出欄中,專案管理計畫的子計畫和基準是會以「專案管理計畫更新」呈現,然後在對應章節中再另加描述
3. 在ITTO輸入欄中,會產生子計畫的規劃流程,專案管理計畫必須明列
4. 在監控流程中,主要的輸入項目必須是「專案管理計畫」,而不是特定的子計畫和基準,輸出項目則是以「專案管理計畫更新」呈現,而不是特定子計畫的更新

PMI®編修小組對PMBOKG5的主要修定已經介紹完了,接下來繼續要看PMBOKG5每一個流程的修訂與一些尚未被改正的錯誤。

PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_08:PMBOKG5各流程的修訂與勘誤〉

筆者前7篇審查意見談的都是PMI®編修小組對PMBOKG5的貢獻,接下來要按照執行「起案(I)」、「規劃(P)」、「執行(E)」、「監控(M)」、「結案(C)」的順序,針對每一個流程尚未被改正的錯誤進行審查。基本上,PMBOKG5大部份都是圖表的錯誤,而且絕大部份式編排和校對的疏忽,並不能全怪在PMI®編修小組頭上,在這裡還是要對辛苦的PMI®編修小組致敬。


PMBOKG4只有42個流程,PMBOKG5總共有47個流程,筆者從下一篇起,會按照5大流程群組的順序,逐一介紹PMBOKG5每個流程的修訂細節以及一些尚未被PMI ®編修小組改正的錯誤,並在每個流程附上筆者新版的解碼圖;如果讀者已經購買筆者在2011年7月針對PMBOKG4所出版的《人人都可以成為PMP大師:國際專案管理師認證寶典(Ⅰ.祕笈篇, Ⅱ.關鍵詞篇, Ⅲ.題庫篇)》套書(ISBN:978-986-86326-2-2,可以到博客來網路書局購買),只要再收集這47張解碼圖,根本不需要再看PMBOKG5,就可以參加PMI®舉辦的2013年7月31日以後的新版PMP®認證考試:

起案流程群組(2個流程)
PMBOKG5_09:流程4.1的修訂與勘誤
PMBOKG5_10:流程13.1的修訂與勘誤

規劃流程群組(24個流程)
PMBOKG5_11:流程4.2的修訂與勘誤
PMBOKG5_12:流程5.1的修訂與勘誤
PMBOKG5_13:流程5.2的修訂與勘誤
PMBOKG5_14:流程5.3的修訂與勘誤
PMBOKG5_15:流程5.4的修訂與勘誤
PMBOKG5_16:流程6.1的修訂與勘誤
PMBOKG5_17:流程6.2的修訂與勘誤
PMBOKG5_18:流程6.3的修訂與勘誤
PMBOKG5_19:流程6.4的修訂與勘誤
PMBOKG5_20:流程6.5的修訂與勘誤
PMBOKG5_21:流程6.6的修訂與勘誤
PMBOKG5_22:流程7.1的修訂與勘誤
PMBOKG5_23:流程7.2的修訂與勘誤
PMBOKG5_24:流程7.3的修訂與勘誤
PMBOKG5_25:流程8.1的修訂與勘誤
PMBOKG5_26:流程9.1的修訂與勘誤
PMBOKG5_27:流程10.1的修訂與勘誤
PMBOKG5_28:流程11.1的修訂與勘誤
PMBOKG5_29:流程11.2的修訂與勘誤
PMBOKG5_30:流程11.3的修訂與勘誤
PMBOKG5_31:流程11.4的修訂與勘誤
PMBOKG5_32:流程11.5的修訂與勘誤
PMBOKG5_33:流程12.1的修訂與勘誤
PMBOKG5_34:流程13.2的修訂與勘誤

執行流程群組(8個流程)
PMBOKG5_35:流程4.3的修訂與勘誤
PMBOKG5_36:流程8.2的修訂與勘誤
PMBOKG5_37:流程9.2的修訂與勘誤
PMBOKG5_38:流程9.3的修訂與勘誤
PMBOKG5_39:流程9.4的修訂與勘誤
PMBOKG5_40:流程10.2的修訂與勘誤
PMBOKG5_41:流程12.2的修訂與勘誤
PMBOKG5_42:流程13.3的修訂與勘誤

監控流程群組(11個流程)
PMBOKG5_43:流程4.4的修訂與勘誤
PMBOKG5_44:流程4.5的修訂與勘誤
PMBOKG5_45:流程5.5的修訂與勘誤
PMBOKG5_46:流程5.6的修訂與勘誤
PMBOKG5_47:流程6.7的修訂與勘誤
PMBOKG5_48:流程7.4的修訂與勘誤
PMBOKG5_49:流程8.3的修訂與勘誤
PMBOKG5_50:流程10.3的修訂與勘誤
PMBOKG5_51:流程11.6的修訂與勘誤
PMBOKG5_52:流程12.3的修訂與勘誤
PMBOKG5_53:流程13.4的修訂與勘誤

結案流程群組(2個流程)
PMBOKG5_54:流程4.6的修訂與勘誤
PMBOKG5_55:流程12.4的修訂與勘誤


PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_09:流程4.1的修訂與勘誤〉

為什麼筆者不按照書本章節順序來審查PMBOKG5,而是要按照五大流程群組順序呢?原來PMI®在2010年底曾經出版《A User’s Manual to the PMBOK® Guide》(以下簡稱「使用手冊」),宣告學習PMBOK® Guide不能按照書本章節順序,也就是九大知識領域的順序,正確學習PMBOK® Guide的方法必須按照五大流程群組順序,難怪很多讀者看不懂PMBOK® Guide,原來是學習方法不對。「使用手冊」的出版等於是PMI®自打嘴巴:哪有人先出一本學習指南,然後再出一本「使用手冊」,來告訴讀者如何使用先前那本學習指南PMBOK® Guide?不過PMI®知過能改的態度還是值得讚賞。


針對新出版的「使用手冊」所提出的流程群組思維模式,筆者特別將2009年6月出版的《新PMP聖經密碼》重新編排,並分成三冊──秘笈篇、關鍵詞篇、題庫篇,重新於2011年7月出版《人人都可以成為PMP大師:國際專案管理師認證寶典(Ⅰ.祕笈篇, Ⅱ.關鍵詞篇, Ⅲ.題庫篇)》套書(ISBN:978-986-86326-2-2,可以到博客來網路書局購買),繼《新PMP聖經密碼》從「樹狀結構思維模式」轉移成「網狀結構思維模式」之後,《人人都可以成為PMP大師》更將繼續帶領讀者從「知識領域思維模式」轉移至「流程群組思維模式」,徹徹底底解開所有隱藏在PMBOK® Guide背後的秘密。

筆者在《新PMP聖經密碼》一書中,爲了解開PMBOKG4的ITTO圖資料流的密碼,創造了「專案文件」、「天線」、「地線」、「箭號」等四個「解碼符號」:



我們把這些解碼符號套在流程的ITTO圖I欄和O欄上。其中,
1. 專案文件可以出現在I欄中任何一個輸入項目之前或或O欄中任何一個輸出項目之後,前者代表該輸入項目是從專案文件流過來,後者代表該輸出項目將會流向專案文件。
2. 天線只能出現在I欄中的任何一個輸入項目之前,代表該項目不是來自其他流程的輸出項目,而是來自(1)企業/組織、(2)專案發起人/贊助人或(3)賣方(代表天線符號的三種類型)。
3. 地線只能出現在O欄中的任何一個輸出項目之後,代表該項目不會再流向其他流程作為輸入項目,而是會流向(1)企業/組織、(2)顧客或(3)賣方(代表地線符號的三種類型)。
4. 箭號可以出現在I欄中任何一個輸入項目之前或或O欄中任何一個輸出項目之後,前者代表該輸入項目是由其他流程的輸出項目流過來,前面若有數字,代表從多少個流程流過來;後者代表該輸出項目會流向其他流程作為輸入項目,後面若跟隨數字,代表會流向多少個流程。

這四個「解碼符號」可以結合ITTO/DFD圖,適用於任何一版的PMBOK® Guide,若是把它加在PMBOKG5上,更是如虎添翼。因此筆者在每個流程的修訂與勘誤之後,都會附上新版的解碼圖,好讓新讀者更能掌握該流程與其他流程的互動關係。

天線分為實線、點線和虛線三類:
1. 天線1(實線)出現在I欄,代表該輸入項目是來自企業/組織。 
2. 天線2(點線)出現在I欄,代表該輸入項目是來自專案發起人/贊助人。
3. 天線3(虛線)出現在I欄,代表該輸入項目是來自賣方。



地線分為實線、點線和虛線三類:
1. 地線1(實線)出現在O欄,代表該輸出項目會流向企業/組織。 
2. 地線2(點線)出現在O欄,代表該輸出項目會流向顧客。
3. 地線3(虛線)出現在O欄,代表該輸出項目會流向賣方。



箭號分為實線、點線和虛線三類,共有下列四種組合方式:
1. 箭號1(實線) 若出現在I欄,代表該輸入項目是來自同一知識領域之流程;若出現在O欄,則代表該輸出項目會流向同一知識領域的流程。
2. 箭號2(點線) 若出現在I欄,代表該輸入項目是來自不同知識領域之流程;若出現在O欄,則代表該輸出項目會流向不同知識領域的流程。
3. 箭號3(虛線) 若出現在I欄,代表該輸入項目是來自整合知識領域之流程;若出現在O欄,則代表該輸出項目會流向整合知識領域流程。
4. 箭號1+箭號2(實線+點線) 若出現在I欄,代表該輸入項目前一部分是來自同一知識領域的流程,後一部分是來自不同知識領域之流程,通常箭號前面會有兩個數字(m,n) ,分別代表前後箭號之流程個數;若出現在O欄,則代表該輸出項目前一部分會流向同一知識領域的流程,後一部分會流向不同知識領域的流程,通常箭號後面會跟隨兩個數字(m,n),分別代表前後箭號之流程個數。 m代表來自或流向m個同一知識領域的流程,n代表來自或流向n個不同知識領域的流程。



介紹完「解碼符號」之後,開始進入正題;流程4.1「發展專案許可證」(Develop Project Charter)屬於起案流程群組,在PMBOKG4和PMBOKG5中差異不大,此流程最大效益在於提供專案一個明確的起點和終點,為專案建立正式記錄,讓資深管理人可以正式接受專案和承諾專案所需資源。其唯一的輸出項目「專案許可證」建立專案發起單位和執行單位的合夥關係,在PMBOKG4中,它只會流向「發展專案管理計畫」(流程4.2)、「收集需求」(流程5.1)、「界定範圍」(流程5.2)、「辨識關係人」(流程10.1) 等4個流程。

不過由於在PMBOKG5中,新增加「規劃範圍管理」(流程5.1)、「規劃時程管理」(流程6.1)、「規劃成本管理」(流程7.1)三個規劃流程,並且調整「收集需求」、「界定範圍」和「辨識關係人」三個流程的編號依次為5.2、5.3和13.1。

如此一來,在PMBOKG5中,流程4.1「發展專案許可證」的輸出項目「專案許可證」會流向下列8個流程:「發展專案管理計畫」(流程4.2)、「規劃範圍管理」(流程5.1)、「收集需求」(流程5.2)、「界定範圍」(流程5.3)、「規劃時程管理」(流程6.1)、「規劃成本管理」(流程7.1)、「規劃風險管理」(流程11.1)、「辨識關係人」(流程13.1)。

仔細算一下,原有在PMBOKG4中,「專案許可證」所流向的4個流程加上PMBOKG5中,新增加3個流程,應該只有7個流程,為何在PMBOKG5中,「專案許可證」會流向8個流程呢?換句話說,為何「專案許可證」會流向「規劃風險管理」(流程11.1)呢?

這是因為在PMBOKG5中,「專案許可證」已經包含高階的範圍、時程、成本和風險相關資料,流程11.1「規劃風險管理」的輸入項目有「專案許可證」也是無可厚非的,「專案許可證」包含下列12項:
1. 專案目的或理由
2. 可度量目標和相關成功準則
3. 高階需求 
4. 假設與制約(新增)
5. 高階專案說明及界限
6. 高階風險
7. 里程碑時程摘要
8. 預算摘要
9. 關係人清單(新增)
10. 專案之核准需求
11. 所指派的專案經理人、職責與職權 
12. 專案許可證授權者之姓名與職責 

另外回頭來看輸入項目,由於內部專案起案時都是以口頭或書面協議行之,並不一定會有合約,因此PMI®編修小組以較廣義的輸入項目「Agreements(協議)」取代流程4.1「發展專案許可證」原有的輸入項目「Contract(合約)」。基本上,合約就是一種協議。

最後我們來看流程4.1「發展專案許可證」的兩張圖表:ITTO圖和DFD圖。



在ITTO圖中,流程4.1共有5項輸入、2項工具&技術、1項輸出。5個藍色輸入項目——「專案工作說明」、「案由」、「協議」、「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」和「促進技術」代表會被其他流程重複使用;唯一的黑色輸出項目——「專案許可證」代表流向其他流程。



在DFD圖中,流程4.1的5個輸入項目只會集中在2條箭號上;流程4.1的1個輸出項目會分散在8條箭號上。這是因為流程4.1這5個輸入項目是來自不同的外部實體:一是來自「專案發起人/贊助人」的「專案工作說明」、「案由」和「協議」,另一個是來自「企業/組織的「企業環境因素」和「組織流程資產」;流程4.1的輸出項目「專案許可證」會流向「發展專案管理計畫」(流程4.2)、「規劃範圍管理」(流程5.1)、「收集需求」(流程5.2)、「界定範圍」(流程5.3)、「規劃時程管理」(流程6.1)、「規劃成本管理」(流程7.1)、「規劃風險管理」(流程11.1)、「辨識關係人」(流程13.1)等8個流程。

透過上述的「專案文件」、「天線」、「地線」、「箭號」等四個「解碼符號」,就可以將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程4.1是第一個流程,它的5個輸入項目都不是來自其他流程(此處特別用藍色字體做區別,若是來自流程則保持黑色字體),因此在每個輸入項目之前都要加上天線,以表示該項目不是來自其他流程的輸出項目。為了區隔其來源的不同,因此以點線天線實線天線,分別代表源自「專案發起人/贊助人」和「企業/組織」。

至於流程4.1唯一的輸出項目「專案許可證」則會流向8個流程(4.2/5.1/5.2/5.3/6.1/7.1/11.1/13.1),本來只要在該輸出項目之後,加上一條箭號以及數字8,就可以代表該輸出項目會流向8個流程,不過從DFD圖中可以發現這8個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字8改為「1,7」,以代表該輸出項目會流向1個與流程4.1相同知識領域的流程(4.2),以及其他7個與流程4.1不同知識領域的流程(5.1/5.2/5.3/6.1/7.1/11.1/13.1)。

整體來說,PMI®編修小組對流程4.1「發展專案許可證」的修正是OK的。同樣屬於起案流程群組還有另一個流程「辨識關係人」(流程13.1),是否有PMI®編修小組尚未改正的錯誤呢?

PMI®編修小組將PMBOKG5擴充為10個知識領域,新增加一個「專案關係人管理」知識領域,並將原本PMBOKG4〈第十章 專案溝通管理〉拆分成PMBOKG5〈第十章 專案溝通管理〉和〈第十三章 專案關係人管理〉兩章。PMI®編修小組除了在PMBOKG5中增加「規劃關係人管理」(流程13.2)之外,還將PMBOKG4原有的「辨識關係人」(PMBOKG4流程10.1)和「管理關係人期望」(PMBOKG4流程10.4)調整為「辨識關係人」(流程13.1)和「管理關係人全心投入」(流程13.3),另外還增加 「控管關係人全心投入」(流程13.4)。

在PMBOKG5中,流程13.1「辨識關係人」也是屬於起案流程群組,是負責辨識所有會受專案決策、活動或結果影響,或者會影響專案決策、活動或結果的個人、團體或組織,並且分析與記載與他們的興趣、參與程度、相依關係和對專案成功的潛在影響之相關資訊的流程。唯一的輸出項目「關係人登記簿」(Stakeholder Register)會流向下列7個流程:「規劃關係人管理」(流程13.2)、「收集需求」(流程5.2)、「規劃品質管理」(流程8.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)、「辨識風險」(流程11.2)、「規劃採購管理」(流程12.1)。

專案關係人是指所有會受專案決策、活動或結果影響,或者會影響專案決策、活動或結果的個人、團體或組織,在PMBOKG5中,PMI®編修小組特別強調專案關係人參與專案計畫編制的重要,因此在PMBOKG5中,「關係人登記簿」會流向:「規劃品質管理」(流程8.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)和「規劃採購管理」(流程12.1)和「規劃關係人管理」(流程13.2) 等5個產生子計畫的流程。



在ITTO圖中,流程13.1共有4項輸入、3項工具&技術、1項輸出。2個黑色輸入項目——「專案許可證」和「採購文件」代表來自其他流程;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」和「會議」代表會被其他流程重複使用;唯一的黑色輸出項目——「關係人登記簿」代表流向其他流程。



在DFD圖中,流程13.1的4個輸入項目只會集中在3條箭號上;流程13.1的1個輸出項目會分散在7條箭號上。這是因為流程13.1這4個輸入項目是來自不同的流程和外部實體:一是來自流程4.1的「專案許可證」,一是來自流程12.1的「專案許可證」,另二個是來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程13.1的輸出項目「關係人登記簿」則會流向「規劃關係人管理」(流程13.2)、「收集需求」(流程5.2)、「規劃品質管理」(流程8.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)、「辨識風險」(流程11.2)、「規劃採購管理」(流程12.1)等7個流程。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者只要透過上述的「專案文件」、「天線」、「地線」、「箭號」等四個「解碼符號」,就可以將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程13.1的4個輸入項目中有2項不是來自其他流程(此處特別用藍色字體做區別,若是來自流程則保持黑色字體),因此在這2項輸入項目之前要加上天線,以表示該2個項目不是來自其他流程。

至於流程13.1唯一的輸出項目「關係人登記簿」則會流向7個流程(13.2/5.2/ 8.1/10.1/11.1/11.2/12.1),本來只要在該輸出項目之後,加上一條箭號以及數字7,就可以代表該輸出項目會流向7個流程,不過從DFD圖中可以發現這7個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字7改為「1,6」,以代表該輸出項目會流向1個與流程13.1相同知識領域的流程(13.2),以及其他6個與流程13.1不同知識領域的流程(5.2/ 8.1/10.1/11.1/11.2/12.1)。

審查過起案流程群組的2個流程,整體來說,PMI®編修小組對流程4.1「發展專案許可證」和流程13.1「辨識關係人」的修正是OK的。下一篇起進入規劃流程群組,規劃流程群組第1個流程「發展專案管理計畫」(流程4.2),是否有PMI®編修小組尚未改正的錯誤呢?



PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_10:流程13.1的修訂與勘誤〉



在PMBOKG4中,屬於起案流程群組的流程10.1「辨識關係人」(Identify Stakeholders)只會流向「規劃溝通」(PMBOKG4流程10.2)、「管理關係人期望」(PMBOKG4流程10.4)、「收集需求」(PMBOKG4流程5.1)、「規劃品質」(PMBOKG4流程8.1)、「辨識風險」(PMBOKG4流程11.2)等5個流程。




PMI®編修小組將PMBOKG5擴充為10個知識領域,新增加一個「專案關係人管理」知識領域,並將原本PMBOKG4〈第十章 專案溝通管理〉拆分成PMBOKG5〈第十章 專案溝通管理〉和〈第十三章 專案關係人管理〉兩章。PMI®編修小組除了在PMBOKG5中增加「規劃關係人管理」(流程13.2)之外,還將PMBOKG4原有的「辨識關係人」(PMBOKG4流程10.1)和「管理關係人期望」(PMBOKG4流程10.4)調整為「辨識關係人」(流程13.1)和「管理關係人全心投入」(流程13.3),另外還增加 「控管關係人全心投入」(流程13.4)。

在PMBOKG5中,流程13.1「辨識關係人」也是屬於起案流程群組,是負責辨識所有會受專案決策、活動或結果影響,或者會影響專案決策、活動或結果的個人、團體或組織,並且分析與記載與他們的興趣、參與程度、相依關係和對專案成功的潛在影響之相關資訊的流程。唯一的輸出項目「關係人登記簿」(Stakeholder Register)會流向下列7個流程:「規劃關係人管理」(流程13.2)、「收集需求」(流程5.2)、「規劃品質管理」(流程8.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)、「辨識風險」(流程11.2)、「規劃採購管理」(流程12.1)。

專案關係人是指所有會受專案決策、活動或結果影響,或者會影響專案決策、活動或結果的個人、團體或組織,在PMBOKG5中,PMI®編修小組特別強調專案關係人參與專案計畫編制的重要,因此在PMBOKG5中,「關係人登記簿」會流向:「規劃品質管理」(流程8.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)和「規劃採購管理」(流程12.1)和「規劃關係人管理」(流程13.2) 等5個產生子計畫的流程。



在ITTO圖中,流程13.1共有4項輸入、3項工具&技術、1項輸出。2個黑色輸入項目——「專案許可證」和「採購文件」代表來自其他流程;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」和「會議」代表會被其他流程重複使用;唯一的黑色輸出項目——「關係人登記簿」代表流向其他流程。



在DFD圖中,流程13.1的4個輸入項目只會集中在3條箭號上;流程13.1的1個輸出項目會分散在7條箭號上。這是因為流程13.1這4個輸入項目是來自不同的流程和外部實體:一是來自流程4.1的「專案許可證」,一是來自流程12.1的「專案許可證」,另二個是來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程13.1的輸出項目「關係人登記簿」則會流向「規劃關係人管理」(流程13.2)、「收集需求」(流程5.2)、「規劃品質管理」(流程8.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)、「辨識風險」(流程11.2)、「規劃採購管理」(流程12.1)等7個流程。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者只要透過上述的「專案文件」、「天線」、「地線」、「箭號」等四個「解碼符號」,就可以將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程13.1的4個輸入項目中有2項不是來自其他流程(此處特別用藍色字體做區別,若是來自流程則保持黑色字體),因此在這2項輸入項目之前要加上天線,以表示該2個項目不是來自其他流程。

至於流程13.1唯一的輸出項目「關係人登記簿」則會流向7個流程(13.2/5.2/ 8.1/10.1/11.1/11.2/12.1),本來只要在該輸出項目之後,加上一條箭號以及數字7,就可以代表該輸出項目會流向7個流程,不過從DFD圖中可以發現這7個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字7改為「1,6」,以代表該輸出項目會流向1個與流程13.1相同知識領域的流程(13.2),以及其他6個與流程13.1不同知識領域的流程(5.2/ 8.1/10.1/11.1/11.2/12.1)。

審查過起案流程群組的2個流程,整體來說,PMI®編修小組對流程4.1「發展專案許可證」和流程13.1「辨識關係人」的修正是OK的。下一篇起進入規劃流程群組,規劃流程群組第1個流程「發展專案管理計畫」(流程4.2),是否有PMI®編修小組尚未改正的錯誤呢?



PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_11:流程4.2的修訂與勘誤〉

流程4.2「發展專案管理計畫」(Develop Project Management Plan)是規劃流程群組第一個流程,負責界定、準備以及協調所有子計畫,並將它們整合成為專案管理計畫。流程4.2唯一的輸出項目「專案管理計畫」界定專案如何執行、監控與結案,其內容會因應用領域和專案複雜度而異。




原本在PMBOKG4中,為了製造「專案管理計畫」只會流向執行流程、監控流程和結案流程所有20個流程的假象,不得不先把所有會流向執行流程、監控流程和結案流程的子計畫通通先彙總到流程4.2「發展專案管理計畫」成為「專案管理計畫」之後,再由流程4.2轉流向執行流程、監控流程和結案流程。筆者當時在《人人都可以成為PMP大師:國際專案管理師認證寶典(Ⅰ.祕笈篇, Ⅱ.關鍵詞篇, Ⅲ.題庫篇)》套書(ISBN:978-986-86326-2-2,可以到博客來網路書局購買)中,只好將這種由流程4.2轉手的工程稱為「過水機制」。

PMI®編修小組在PMBOKG5中,打破此一假象,重新制定下列專案管理計畫規則:
1. 在ITTO輸入欄中,如果專案管理計畫的子計畫和基準是主要的輸入項目,它必須明列。
2. 在ITTO輸出欄中,專案管理計畫的子計畫和基準是會以「專案管理計畫更新」呈現,然後在對應章節中再另加描述。
3. 在ITTO輸入欄中,會產生子計畫的規劃流程,專案管理計畫必須明列。
4. 在監控流程中,主要的輸入項目必須是「專案管理計畫」,而不是特定的子計畫和基準,輸出項目則是以「專案管理計畫更新」呈現,而不是特定子計畫的更新。

此項新規定讓做為流程輸入項目之「專案管理計畫」和輸出項目之「專案管理計畫更新」有了較合理一致的解釋。我們先來看流程4.2的ITTO圖和DFD圖:



在ITTO圖中,流程4.2共有4項輸入、2項工具&技術、1項輸出。2個黑色輸入項目——「專案許可證」和「其他流程的輸出」代表來自其他流程;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」和「促進技術」代表會被其他流程重複使用;唯一的黑色輸出項目——「專案管理計畫」代表流向其他流程。



在DFD圖中,流程4.2的4個輸入項目只會集中在3條箭號上;流程4.2的1個輸出項目會分散在23條箭號(此圖只畫了21條)上。這是因為流程4.2這4個輸入項目是來自不同的流程和外部實體:一是來自流程4.1的「專案許可證」,一是來自其他流程的「其他流程的輸出」,另二個是來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程4.2的輸出項目「專案管理計畫」則會流向23個流程。

在DFD圖中,PMI®編修小組已經將「其他流程的輸出」展開為「溝通管理計畫」、「成本管理計畫」、「人資管理計畫」、「採購管理計畫」、「流程改善計畫」、「品質管理計畫」、「需求管理計畫」、「風險管理計畫」、「時程管理計畫」、「範圍管理計畫」、「關係人管理計畫」、「成本基準」、「時程基準」、「範圍基準」、「專案管理計畫更新」等15項,這些由「其他流程的輸出」的11個子計畫和3個基準正好構成專案管理計畫:
1. 範圍管理計畫(流程 5.1輸出項目)
2. 需求管理計畫(流程 5.1輸出項目)
3. 範圍基準(流程 5.4輸出項目)
4. 時程管理計畫(流程 6.1輸出項目)
5. 時程基準(流程 6.6輸出項目)
6. 成本管理計畫(流程 7.1輸出項目)
7. 成本基準(流程 7.3輸出項目)
8. 品質管理計畫(流程 8.1輸出項目)
9. 流程改善計畫(流程 8.1輸出項目)
10. 人資管理計畫(流程 9.1輸出項目)
11. 溝通管理計畫(流程 10.1輸出項目)
12. 風險管理計畫(流程 11.1輸出項目)
13. 採購管理計畫(流程 12.1輸出項目)
14. 關係人管理計畫(流程 13.2輸出項目)

至於流程4.2的輸出項目「專案管理計畫」則會流向下列23個流程:
A. 9個規劃階段(P)流程:「規劃範圍管理」(流程5.1)、「規劃時程管理」(流程6.1)、「規劃成本管理」(流程7.1)、「規劃品質管理」(流程8.1)、「規劃人資管理」(流程9.1)、「規劃溝通管理」(流程10.1)、「規劃風險管理」(流程11.1)、「規劃採購管理」(流程12.1)、「規劃關係人管理」(流程13.2)
B. 1個執行階段(E)流程:「指揮與管理專案工作」(流程4.3)
C. 11個監控階段(M)流程:「監控專案工作」(流程4.4)、「執行整合變更控管」(流程4.5)、「確認範圍」(流程5.5)、「控管範圍」(流程5.6)、「控管時程」(流程6.7)、「控管成本」(流程7.4)、「控管品質」(流程8.3)、「控管溝通」(流程10.3)、「控管風險」(流程11.6)、「控管採購」(流程12.3)、「控管關係人全心投入」(流程13.4)。
D. 2個結案階段(C)流程:「結束專案或階段」(流程4.6)、「結束採購」(流程12.4)

上圖(摘自PMBOKG5第73頁)的輸出項目少了「確認範圍」(流程5.5)和「控管品質」(流程8.3),PMI®編修小組應不致於如此胡塗,應該是美編排版錯誤。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程4.2的4個輸入項目中有2項不是來自其他流程(此處特別用藍色字體做區別,若是來自流程則保持黑色字體),因此在這2項輸入項目之前要加上天線,以表示該2個項目不是來自其他流程。在解碼圖中筆者已經將「其他流程的輸出」展開後的所有15項明列在I欄。

流程4.2唯一的輸出項目「專案管理計畫」會流向23個流程,本來只要在該輸出項目之後,加上一條箭號以及數字23,就可以代表該輸出項目會流向23個流程,不過從DFD圖中可以發現這23個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字23改為「4,19」,以代表該輸出項目會流向4個與流程4.2相同知識領域的流程(4.3/4.4/4.5/4.6),以及其他19個與流程4.2不同知識領域的流程(5.1/6.1/7.1/8.1/9.1/10.1/11.1/12.1/13.2/5.5/5.6/6.7/7.4/8.3/10.3/11.6/12.3/13.4/12.4)。

流程4.2是PMBOKG5最重要的流程,大多數規劃流程都會產生子計畫流向流程4.2,執行流程和監控流程也會有輸出項目「專案管理計畫更新」流向流程4.2,流程4.2唯一的輸出項目「專案管理計畫」也會流向規劃流程、執行流程、監控流程和結案流程,幾乎所有流程都和流程4.2有互動。整體來說,除了DFD圖的錯誤之外,PMI®編修小組對流程4.2「發展專案管理計畫」的修正讓「專案管理計畫」在整個系統中較有完整和一致性。下一篇將審查規劃流程群組第2個流程「規劃範圍管理」(流程5.1),是否有PMI®編修小組尚未改正的錯誤呢?


PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_12:流程5.1的修訂與勘誤〉
PMI®編修小組在PMBOKG5「專案範圍管理知識領域」中新增加流程5.1「規劃範圍管理」(Plan Scope Management),並且將該知識領域原有的「收集需求」、「界定範圍」、「產生WBS」、「驗證範圍」和「控管範圍」五個流程的編號,依次調整為5.2、5.3、5.4、5.5和5.6(當然「驗證範圍」的流程名稱也改為「確認範圍」)。
在PMBOKG5中,流程5.1「規劃範圍管理」屬於規劃流程群組,負責產生記載如何界定、確認和控管專案範圍的範圍管理計畫,有2個輸出項目「需求管理計畫」和「範圍管理計畫」;不過在PMBOKG4中,「範圍管理計畫」是由「專案範圍管理知識領域」的隱性流程(PMBOKG4稱之為5.0)所產生的隱性計畫,而「範圍管理計畫」則是由「收集需求」(PMBOKG4的流程5.1)所產生。



在ITTO圖中,流程5.1共有4項輸入、2項工具&技術、2項輸出。2個黑色輸入項目——「專案管理計畫」和「專案許可證」代表來自其他流程;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」和「會議」代表會被其他流程重複使用;2個紫色輸出項目——「需求管理計畫」和「範圍管理計畫」代表會流向其他流程的子計畫。



在DFD圖中,流程5.1的4個輸入項目只會集中在3條箭號上;流程5.1的2個輸出項目會分散在4條箭號上。這是因為流程5.1這4個輸入項目是來自不同的流程和外部實體:一是來自流程4.2的「專案管理計畫」,一是來自流程4.1的「專案許可證」,另二個是來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程5.1的輸出項目「需求管理計畫」只會流向「收集需求」(流程5.2),另外一個輸出項目「範圍管理計畫」則會流向「收集需求」(流程5.2)、「界定範圍」(流程5.3)、「產生WBS」(流程5.4)。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程5.1的4個輸入項目中有2項不是來自其他流程(此處特別用藍色字體做區別,若是來自流程則保持黑色字體),因此在這2項輸入項目之前要加上天線,以表示該2個項目不是來自其他流程。

至於流程5.1的2個輸出項目,其中一個輸出項目「需求管理計畫」只會流向「收集需求」(流程5.2),因此只要在該輸出項目之後,加上一條實線箭號,代表該輸出項目會流向1個與流程5.1相同知識領域的流程(5.2);另外一個輸出項目「範圍管理計畫」則會流向「收集需求」(流程5.2)、「界定範圍」(流程5.3)、「產生WBS」(流程5.4),因此只要在該輸出項目之後,加上一條實線箭號以及數字3,代表該輸出項目會流向3個與流程5.1相同知識領域的流程(5.2/5.3/5.4)。

整體來說,PMI®編修小組在PMBOKG5「專案範圍管理知識領域」中新增加流程5.1「規劃範圍管理」的修正是OK的。下一篇將審查規劃流程群組第3個流程「收集需求」(流程5.2),是否有PMI®編修小組尚未改正的錯誤呢?



PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_13:流程5.2的修訂與勘誤〉


由於PMI®編修小組在PMBOKG5「專案範圍管理知識領域」中新增加流程5.1「規劃範圍管理」,因此原本在PMBOKG4中的流程5.1「收集需求」(Collect Requirements) 在PMBOKG5中就變成流程5.2。



在PMBOKG5中,流程5.2「收集需求」屬於規劃流程群組,負責規劃、界定和記載關係人需要和需求,以求符合專案目標。流程5.2「收集需求」有2個輸出項目,其中一項「需求文件檔」會流向下列6個流程:「規劃品質管理」(流程8.1)、「規劃採購管理」(流程12.1)、「界定範圍」(流程5.3)、「產生WBS」(流程5.4)、「確認範圍」(流程5.5)、「控管範圍」(流程5.6);另外一項「需求追溯表」會流向下列2個流程:「確認範圍」(流程5.5)、「控管範圍」(流程5.6)。



在ITTO圖中,流程5.2共有5項輸入、11項工具&技術、2項輸出。3個紫色輸入項目——「範圍管理計畫」、「需求管理計畫」和「關係人管理計畫」代表來自其他流程的子計畫;2個黑色輸入項目——「專案許可證」和「關係人登記簿」代表來自其他流程;藍色工具&技術項目——「促進研習會」、「團體決策技術」和「標竿法」代表會被其他流程重複使用;2個黑色輸出項目——「需求文件檔」和「需求追溯表」代表會流向其他流程。



在DFD圖中,流程5.2的5個輸入項目只會集中在4條箭號上;流程5.2的2個輸出項目會分散在8條箭號上。這是因為流程5.2這5個輸入項目是來自不同的流程:來自流程4.1的「專案許可證」,來自流程13.1的「關係人登記簿」,來自流程5.1的「需求管理計畫」和「範圍管理計畫」,來自流程13.2的「關係人管理計畫」;而流程5.2的輸出項目「需求文件檔」會流向下列6個流程:「規劃品質管理」(流程8.1)、「規劃採購管理」(流程12.1)、「界定範圍」(流程5.3)、「產生WBS」(流程5.4)、「確認範圍」(流程5.5)、「控管範圍」(流程5.6);另外一個輸出項目「需求追溯表」只會流向下列2個流程:「確認範圍」(流程5.5)、「控管範圍」(流程5.6)。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程5.2的5個輸入項目中有3項是來自其他流程的子計畫(此處特別用紫色字體做區別,若只是來自流程則保持黑色字體),這3項子計畫其中2項「範圍管理計畫」和「需求管理計畫」之前要加上實線箭號,以表示該2個項目是來自與流程5.2相同知識領域的流程(5.1),另一項「關係人管理計畫」之前要加上點線箭號,以表示該項目是來自與流程5.2不同知識領域的流程(13.2)。

至於流程5.2的2個輸出項目,其中一個輸出項目「需求文件檔」只會流向下列6個流程:「規劃品質管理」(流程8.1)、「規劃採購管理」(流程12.1)、「界定範圍」(流程5.3)、「產生WBS」(流程5.4)、「確認範圍」(流程5.5)、「控管範圍」(流程5.6),本來只要在該輸出項目之後,加上一條箭號以及數字6,就可以代表該輸出項目會流向6個流程,不過從DFD圖中可以發現這6個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字6改為「4,2」,以代表該輸出項目會流向4個與流程5.2相同知識領域的流程(5.3/5.4/5.5/5.6),以及其他2個與流程5.2不同知識領域的流程(8.1/12.1);另外一個輸出項目「需求追溯表」則會流向「確認範圍」(流程5.5)和「控管範圍」(流程5.6),因此只要在該輸出項目之後,加上一條實線箭號以及數字2,代表該輸出項目會流向2個與流程5.2相同知識領域的流程(5.5/5.6)。

整體來說,PMI®編修小組對流程5.2「收集需求」的修正是OK的。下一篇將審查規劃流程群組第4個流程「界定範圍」(流程5.3),是否有PMI®編修小組尚未改正的錯誤呢?


PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_14:流程5.3的修訂與勘誤〉

由於PMI®編修小組在PMBOKG5「專案範圍管理知識領域」中新增加流程5.1「規劃範圍管理」,因此原本在PMBOKG4中的流程5.2「界定範圍」(Define Scope)在PMBOKG5中就變成流程5.3。

在PMBOKG5中,流程5.3「界定範圍」屬於規劃流程群組,負責發展專案和產品的詳細描述。流程5.3「界定範圍」有2個輸出項目,其中一項「專案文件更新」會流向外部實體「專案文件」;另外一項「專案範圍說明」會流向下列4個流程:「產生WBS」(流程5.4)、「排序活動」(流程6.3)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6)。



在ITTO圖中,流程5.3共有4項輸入、4項工具&技術、2項輸出。1個紫色輸入項目——「範圍管理計畫」代表來自其他流程的子計畫;2個黑色輸入項目——「專案許可證」和「需求文件檔」代表來自其他流程;藍色輸入項目——「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」和「促進研習會」代表會被其他流程重複使用;2個輸出項目——「專案文件更新」會流向外部實體;「專案範圍說明」會流向其他流程。



在DFD圖中,流程5.3的4個輸入項目會分散在4條箭號上;流程5.3的2個輸出項目會分散在5條箭號上。這是因為流程5.3這4個輸入項目是來自不同的流程和外部實體:來自流程4.1的「專案許可證」,來自流程5.1的「範圍管理計畫」,來自流程5.2的「需求文件檔」,來自「企業/組織」的「組織流程資產」;而流程5.3有2個輸出項目:「專案文件更新」會流向外部實體「專案文件」;「專案範圍說明」會流向下列4個流程:「產生WBS」(流程5.4)、「排序活動」(流程6.3) 、「估算活動工期」(流程6.5)、「發展時程」(流程6.6)。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程5.3的4個輸入項目中有1項是來自其他流程的子計畫「範圍管理計畫」(此處特別用紫色字體做區別,若是來自流程則保持黑色字體)之前要加上實線箭號,以表示該項目是來自與流程5.3相同知識領域的流程(5.1),有1項不是來自其他流程(此處特別用藍色字體做區別),因此在這項輸入項目之前要加上天線,以表示該項目不是來自其他流程。

至於流程5.3的2個輸出項目,其中一個輸出項目「專案範圍說明」會流向下列4個流程:「產生WBS」(流程5.4)、「排序活動」(流程6.3) 、「估算活動工期」(流程6.5)、「發展時程」(流程6.6),本來只要在該輸出項目之後,加上一條箭號以及數字4,就可以代表該輸出項目會流向4個流程,不過從DFD圖中可以發現這4個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字4改為「1,3」,以代表該輸出項目會流向1個與流程5.3相同知識領域的流程(5.4),以及其他3個與流程5.3不同知識領域的流程(6.3/6.5/6.6)。另外一項「專案文件更新」則會流向外部實體「專案文件」,因此在該輸出項目之後,加上代表「專案文件」的符號。

整體來說,PMI®編修小組對流程5.3「界定範圍」的修正是OK的。下一篇將審查規劃流程群組第5個流程「產生WBS」(流程5.4),是否有PMI®編修小組尚未改正的錯誤呢?

PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_15:流程5.4的修訂與勘誤〉

由於PMI®編修小組在PMBOKG5「專案範圍管理知識領域」中新增加流程5.1「規劃範圍管理」,因此原本在PMBOKG4中的流程5.3「產生WBS」(Create WBS)在PMBOKG5中就變成流程5.4。


在PMBOKG5中,流程5.4「產生WBS」屬於規劃流程群組,負責將專案交付項目和專案工作再進一步細分為較小、較容易管理的組件。流程5.4「產生WBS」有2個輸出項目,其中一項「專案文件更新」會流向外部實體「專案文件」;另外一項「範圍基準」會流向下列7個流程:「確認範圍」(流程5.5)、「發展專案管理計畫」(流程4.2)、「界定活動」(流程6.2)、「估算成本」(流程7.2)、「決定預算」(流程7.3)、「辨識風險」(流程11.2)、「執行定性風險分析」(流程11.3)。



在ITTO圖中,流程5.4共有5項輸入、2項工具&技術、2項輸出。1個紫色輸入項目——「範圍管理計畫」代表來自其他流程的子計畫;2個黑色輸入項目——「專案範圍說明」和「需求文件檔」代表來自其他流程;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「分解法」和「專家判斷」代表會被其他流程重複使用;2個輸出項目——「專案文件更新」會流向外部實體;「範圍基準」會流向其他流程。



在DFD圖中,流程5.4的5個輸入項目只會集中在4條箭號上;流程5.4的2個輸出項目會分散在8條箭號上。這是因為流程5.4這5個輸入項目是來自不同的流程和外部實體:一是來自流程5.1的「範圍管理計畫」,一是來自流程5.3的「專案範圍說明」,一是來自流程5.2的「需求文件檔」,另二個是來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程5.4的輸出項目有2個輸出項目,其中一項「專案文件更新」會流向外部實體「專案文件」;另外一項「範圍基準」會流向下列7個流程:「確認範圍」(流程5.5)、「發展專案管理計畫」(流程4.2)、「界定活動」(流程6.2)、「估算成本」(流程7.2)、「決定預算」(流程7.3)、「辨識風險」(流程11.2)、「執行定性風險分析」(流程11.3)。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程5.4的5個輸入項目中有1項是來自其他流程的子計畫「範圍管理計畫」(此處特別用紫色字體做區別,若是來自流程則保持黑色字體)之前要加上實線箭號,以表示該項目是來自與流程5.4相同知識領域的流程(5.1),1項是來自流程5.1的「範圍管理計畫」,1項是來自流程5.3的「專案範圍說明」,這2項之前都要加上實線箭號,以表示該項目是來自與流程5.4相同知識領域的流程(5.1/5.3),另有2項不是來自其他流程(此處特別用藍色字體做區別),因此在這2項輸入項目之前要加上天線,以表示該2個項目不是來自其他流程。

至於流程5.4的2個輸出項目,其中一個輸出項目「範圍基準」會流向下列7個流程:「確認範圍」(流程5.5)、「發展專案管理計畫」(流程4.2)、「界定活動」(流程6.2)、「估算成本」(流程7.2)、「決定預算」(流程7.3)、「辨識風險」(流程11.2)、「執行定性風險分析」(流程11.3)。本來只要在該輸出項目之後,加上一條箭號以及數字7,就可以代表該輸出項目會流向7個流程,不過從DFD圖中可以發現這7個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字7改為「1,6」,以代表該輸出項目會流向1個與流程5.4相同知識領域的流程(5.5),以及其他6個與流程5.4不同知識領域的流程(4.2/6.2/7.2/7.3/11.2/11.3);另外一項「專案文件更新」則會流向外部實體「專案文件」,因此在該輸出項目之後,加上代表「專案文件」的符號。

眼明的讀者會注意到流程5.4的輸出項目「範圍基準」會流向「發展專案管理計畫」(流程4.2)。為什麼?讓我們重新檢視流程4.2的DFD圖的輸入項目「其他流程的輸出」:



讀者發現不只是流程5.4的輸出項目「範圍基準」會流向「發展專案管理計畫」(流程4.2),其他所有包含在「其他流程的輸出」的基準和子計畫都應該如此。因此在重新審查流程5.1「規劃範圍管理」的DFD圖之後,筆者發現了一個缺乏一致性的錯誤:



在流程5.1「規劃範圍管理」DFD圖中2個輸出項目「需求管理計畫」和「範圍管理計畫」都未流向「發展專案管理計畫」(流程4.2),因此必須從這2個輸出項目各拉一條箭號到流程4.2。如此一來,流程5.1「規劃範圍管理」的解碼圖就必須修正為:



流程5.1的2個輸出項目,「需求管理計畫」會流向「收集需求」(流程5.2)和「發展專案管理計畫」(流程4.2),本來只要在該輸出項目之後,加上一條實線箭號以及數字2,就可以代表該輸出項目會流向2個流程,不過由於這2個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,並將數字2改為「1,1」,以代表該輸出項目會流向1個與流程5.1相同知識領域的流程(5.2),以及其他1個與流程5.1不同知識領域的流程(4.2)。另外一個輸出項目「範圍管理計畫」會流向「收集需求」(流程5.2)、「界定範圍」(流程5.3)、「產生WBS」(流程5.4)和「發展專案管理計畫」(流程4.2),本來只要在該輸出項目之後,加上一條實線箭號以及數字4,就可以代表該輸出項目會流向4個流程,不過由於這4個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,並將數字4改為「3,1」,以代表該輸出項目會流向3個與流程5.1相同知識領域的流程(5.2/5.3/5.4),以及其他1個與流程5.1不同知識領域的流程(4.2)。

整體來說,PMI®編修小組對流程5.4「產生WBS」的修正是OK的。下一篇將會運用『所有的基準和子計畫都應該流向「發展專案管理計畫」(流程4.2)』的一致原則來審查規劃流程群組第6個流程「收集需求」(流程6.1),是否有PMI®編修小組尚未改正的錯誤呢?


PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_16:流程6.1的修訂與勘誤〉


MI®編修小組在PMBOKG5「專案時程管理知識領域」中新增加流程6.1「規劃時程管理」(Plan Schedule Management),並且將該知識領域原有的「界定活動」、「排序活動」、「估算活動資源」、「估算活動工期」、「發展時程」和「控管時程」六個流程的編號,依次調整為6.2、6.3、6.4、6.5、6.6和6.7。


在PMBOKG5中,流程6.1「規劃時程管理」屬於規劃流程群組,負責針對專案時程之規劃、發展、管理、執行和控管,建立政策、程序和文件檔。唯一的輸出項目「時程管理計畫」,會流向下列7個流程:「界定活動」(流程6.2)、「排序活動」(流程6.3)、「估算活動資源」(流程6.4)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6) 、「辨識風險」(流程11.2)、「執行定量風險分析」(流程11.4)。在PMBOKG4中,「時程管理計畫」是由「專案時程管理知識領域」的隱性流程(PMBOKG4稱之為6.0)所產生的隱性計畫。



在ITTO圖中,流程6.1共有4項輸入、3項工具&技術、1項輸出。2個黑色輸入項目——「專案管理計畫」和「專案許可證」代表來自其他流程;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「專家判斷」、「分析技術」和「會議」代表會被其他流程重複使用;紫色輸出項目——「時程管理計畫」代表會流向其他流程的子計畫。



在上一篇〈PMBOKG5_15:流程5.4的修訂與勘誤〉最後,筆者提到要以『所有的基準和子計畫都應該流向「發展專案管理計畫」(流程4.2)』的一致原則來審查流程6.1的輸出項目「時程管理計畫」是否有流向「發展專案管理計畫」(流程4.2)。仔細一看果真漏掉了,因此必須從輸出項目「時程管理計畫」拉一條箭號到流程4.2。如此一來,流程6.1的4個輸入項目只會集中在3條箭號上;流程6.1的輸出項目會分散在8條箭號(原先只有7條)上。這是因為流程6.1這4個輸入項目是來自不同的流程和外部實體:一是來自流程4.2的「專案管理計畫」,一是來自流程4.1的「專案許可證」,另二個是來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程6.1的輸出項目「時程管理計畫」會流向下列8個流程:「界定活動」(流程6.2)、「排序活動」(流程6.3)、「估算活動資源」(流程6.4)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6)、「辨識風險」(流程11.2)、「執行定量風險分析」(流程11.4)、「發展專案管理計畫」(流程4.2)。

請注意,流程6.1和流程4.2之的反覆漸進展現了專案管理「逐步詳盡」的特性:流程6.1的輸出項目「時程管理計畫」會流向「發展專案管理計畫」(流程4.2)做為輸入項目「其他流程的輸出」的子項,而流程4.2藉由「其他流程的輸出」所產生的輸出項目「專案管理計畫」則又會流向流程6.1做為輸入項目。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



在流程6.1的4個輸入項目中:「專案管理計畫」和「專案許可證」之前要加上虛線箭號,以表示該項目是分別來自整合知識領域的流程(4.2/4.1);「企業環境因素」和「組織流程資產」之前要加上實線天線,以表示該2個項目來自「企業/組織」。

至於流程6.1的輸出項目「時程管理計畫」會流向下列8個流程:「界定活動」(流程6.2)、「排序活動」(流程6.3)、「估算活動資源」(流程6.4)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6) 、「辨識風險」(流程11.2)、「執行定量風險分析」(流程11.4)、「發展專案管理計畫」(流程4.2),本來只要在該輸出項目之後,加上一條箭號以及數字8,就可以代表該輸出項目會流向8個流程,不過從DFD圖中可以發現這8個流程並不屬於同一個知識領域,因此必須將箭號再加以區分為實線+點線,且將數字8改為「5,3」,以代表該輸出項目會流向5個與流程6.1相同知識領域的流程(6.2/6.3/6.4/6.5/6.6),以及其他3個與流程6.1不同知識領域的流程(11.2/11.4/4.2)。

整體來說,除了違背『所有的基準和子計畫都應該流向「發展專案管理計畫」(流程4.2)』的一致原則之外,PMI®編修小組在PMBOKG5「專案時程管理知識領域」中新增加流程6.1「規劃時程管理」的修正是OK的。下一篇將審查規劃流程群組第7個流程「界定活動」(流程6.2),是否有PMI®編修小組尚未改正的錯誤呢?





PMP大師對PMBOK® Guide第五版的審查意見〈PMBOKG5_17:流程6.2的修訂與勘誤〉



由於PMI®編修小組在PMBOKG5「專案時程管理知識領域」中新增加流程6.1「規劃時程管理」,因此原本在PMBOKG4中的流程6.1「界定活動」(Define Activities) 在PMBOKG5中就變成流程6.2。



在PMBOKG5中,流程6.2「界定活動」屬於規劃流程群組,負責辨識及記載產生專案交付項目所需執行的特定活動。流程6.2「界定活動」有3個輸出項目:「里程碑清單」會流向「排序活動」(流程6.3);「活動清單」和「活動屬性」會同時流向下列4個流程:「排序活動」(流程6.3)、「估算活動資源」(流程6.4)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6)。

在繼續審查流程6.2「界定活動」,筆者再對『所有的基準和子計畫都應該流向「發展專案管理計畫」(流程4.2)』的一致原則提出進一步說明,首先要回到〈PMBOKG5_11:流程4.2的修訂與勘誤〉,先將流程4.2的解碼圖調整為:



先來看輸入項目「其他流程的輸出」的第12/13/14個子項(分別是「成本基準」、「時程基準」和「範圍基準」),之前都有點線箭號,代表會來自與「發展專案管理計畫」(流程4.2)不同知識領域的流程(5.4/6.6/7.3);再看輸入項目「其他流程的輸出」的第15個子項「專案管理計畫更新」之前有實線+點線,及數字「3,16」,代表「專案管理計畫更新」會來自3個與「發展專案管理計畫」(流程4.2)相同知識領域的流程(4.3/4.4/4.5)以及16個與「發展專案管理計畫」(流程4.2)不同知識領域的流程(6.6/11.5/8.2/9.2/9.4/10.2/12.2/13.3/5.6/6.7/7.4/8.3/10.3/11.6/12.3/13.4),其他11個子項則分別來自流程(5.1(2)/6.1/7.1/8.1(2)/9.1/10.1/11.1/12.1/13.2)。問題是:PMI®編修小組在PMBOKG5修訂時並未周全顧慮到一致性,以致於造成前述的4個子項(「成本基準」、「時程基準」、「範圍基準」、「專案管理計畫更新」)都可以在對應流程的DFD圖中找到對應的輸出項目流向「發展專案管理計畫」(流程4.2),唯獨在會產生子計畫的9個流程(5.1/6.1/7.1/8.1/9.1/10.1/11.1/12.1/13.2) 找不到對應的輸出項目流向「發展專案管理計畫」(流程4.2),為了顧全PMBOKG5的一致性,筆者在審查這9個流程時,都會一一校審勘誤。

回頭來看流程6.2「界定活動」的ITTO圖:



在ITTO圖中,流程6.2共有4項輸入、3項工具&技術、3項輸出。2個紫色輸入項目——「時程管理計畫」和「範圍基準」代表來自其他流程的子計畫;2個藍色輸入項目——「企業環境因素」和「組織流程資產」代表來自外部實體;藍色工具&技術項目——「分解法」和「專家判斷」代表會被其他流程重複使用;3個黑色輸出項目——「活動清單」、「活動屬性」和「里程碑清單」代表會流向其他流程。



在DFD圖中,流程6.2的4個輸入項目會分散在3條箭號上;流程6.2的3個輸出項目會分散在5條箭號上。這是因為流程6.2這4個輸入項目是來自不同的流程和外部實體:來自流程6.1的「時程管理計畫」和流程5.4的「範圍基準」,以及來自「企業/組織」的「企業環境因素」和「組織流程資產」;而流程6.2有3個輸出項目:「里程碑清單」會流向「排序活動」(流程6.3);「活動清單」和「活動屬性」會同時流向下列4個流程:「排序活動」(流程6.3)、「估算活動資源」(流程6.4)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6)。

ITTO圖和DFD圖若分開看,只知其一不知其二。讀者必須透過「解碼符號」,將ITTO圖和DFD圖整合成如下的解碼圖:



由於流程6.2的4個輸入項目中有2項是來自其他流程的子計畫或基準(此處特別用紫色字體做區別,若只是來自流程則保持黑色字體),子計畫「時程管理計畫」之前要加上實線箭號,以表示該項目是來自與流程6.2相同知識領域的流程(6.1),基準「範圍基準」之前要加上點線箭號,以表示該項目是來自與流程6.2不同知識領域的流程(5.4);2項不是來自其他流程(此處特別用藍色字體做區別),之前要加上實線天線,以表示該2個項目是來自「企業/組織」。

至於流程6.2的3個輸出項目:「里程碑清單」會流向「排序活動」(流程6.3),因此只要在該輸出項目之後,加上一條實線箭號,代表該輸出項目會流向1個與流程6.2相同知識領域的流程(6.3);「活動清單」和「活動屬性」會同時流向下列4個流程:「排序活動」(流程6.3)、「估算活動資源」(流程6.4)、「估算活動工期」(流程6.5)、「發展時程」(流程6.6),本來只要在這2個輸出項目之後,各加上一條箭號以及數字4,就可以代表該輸出項目會流向4個流程,不過從DFD圖中可以發現這4個流程完全相同,因此另外用一條垂直短線聯結這2條箭號,代表這2個輸出項目都會流向4個與流程6.2相同知識領域的流程(6.3/6.4/6.5/6.6)。

整體來說,PMI®編修小組對6.2「界定活動」的修正是OK的。下一篇將審查規劃流程群組第8個流程「排序活動」(流程6.3),是否有PMI®編修小組尚未改正的錯誤呢?