軟體專案管理第八週課程心得之一_Project M&C in PMBOK, CMMI
第五組志偉同學在介紹第七章監督與控制第一節導論之時，列示了書本上對於專案控制的定義－「比較、分析實際專案進度與規劃專案進度的差異，進而評估可能的備選方案，並且採取必要的行動。」針對專案監督與控制的定義，肥蝦對於書本的定義竊為過於含混，雖然標明了監控在於比較分析專案(管理)計畫所設定的基準(Baselines)與實際進行作業狀況的差異；但是對於其他必要的活動述及甚少，僅說明了：「進而評估可能的備選方案，並且採取必要的行動。」實在非常的不明確。因此，以下就Monitoring and Controlling在PMBOK與CMMI-DEV的說明中加以進一步說明。
在PMBOK 2008年版中的3.6節對於專案的監督與控制有著簡要的說明，而該程序群組中則包含了42個PMBOK所定義流程中的10個。此外，在CMMI-DEV Version 1.2管理級(Managed)中的專案管理中也強調了專案監控(PMC - Project Monitoring and Control)的流程與目標。因此，肥蝦將手中現有PMBOK與CMMI-DEV的資料與認知摘要如后，並且簡要說明對於兩者的異同，最後則重點的說明肥蝦的心得。
(1)PMBOK 2008
(I)Monitoring and Controlling Process Group
英文敘述為：「The Monitoring and Controlling Process Group consists of those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.」另外也說在該監控程序群組中也包含了：(i)Controlling changes and recommending preventive action in anticipation of possible problem。(ii)Monitoring the ongoing project activities against the project management plan and the project performance baseline。(iii)Influencing the factors that could circumvent integrated change control so only approved changes are implemented。
(II)Monitoring and Controlling Processes
|
項次 |
項目 |
說明 |
|
1 |
Monitor and Control Project Work |
The process of tracking, reviewing, and regulating the progress to meet the performance objectives defined in the project management plan. |
|
2 |
Verify Scope |
The process of formalizing acceptance of the completed project deliverables. Reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance. |
|
3 |
Control Scope |
The process of monitoring the status of the project and product scope and managing changes to the scope baseline. |
|
4 |
Control Schedule |
The process of monitoring the status of the project to update project progress and managing changes to the schedule baseline. |
|
5 |
Control Costs |
The process of monitoring the status of the project to update the project budget and managing changes to the cost baseline. |
|
6 |
Perform Quality Control |
The process of monitoring and recording results of executing the quality activities to access performance and recommend necessary changes. |
|
7 |
Report Performance |
The process of collecting and distributing performance information, including status reports, progress measurements, and forecasts. |
|
8 |
Monitor and Control Risks |
The process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout project. |
|
9 |
Administer Procurements |
The process of managing procurement relationships, monitoring contract performance, and making changes and corrections as need. |
|
10 |
Perform Integrated Change Control |
The process of reviewing all change requests, approving changes, and managing changes to the deliverables, organizational process assets, project documents, and the project management plan. |
(2)CMMI-DEV 1.2
對專案監控的定義如下：
(I)目的：
在瞭解專案進度，以便在專案執行績效嚴重偏離專案計畫時，可採取適當的矯正措施。
(II)簡介
CMMI對於專案監控的說明主要區分為四個主要區塊：
(i)對照的基準：文件化的專案計畫是監控各項活動、溝通狀態及採取矯正措施的基礎。
(ii)進度的說明：專案進度主要決定於工作產品、工作屬性、工作量，以及成本的實際值與規定於里程碑或專案時程之控制階層或分工結構圖(WBS)之規劃值的比較結果。
(iii)偏差的作為：當執行績效重大偏離原訂計畫時，適當的能見度可促使採取及時的矯正措施。
(iv)作為的分類：所採取的矯正措施可能需要重新進行專案規劃，而重新規劃可能包括修訂原計畫、訂定新的協議，或在現行計畫中增加額外的降低活動。
(III)特定目標及執行方法摘要
|
項次 |
目標/摘要 |
說明 |
|
特定目標1 |
依計畫監控專案 |
依專案計畫監控專案實際執行績效與進度。 |
|
特定執行方法1.1 |
監控專案規劃之各項參數 |
依專案計畫監控專案規劃參數之實際值。 |
|
特定執行方法1.2 |
監控承諾事項 |
依專案計畫監控所界定的承諾。 |
|
特定執行方法1.3 |
監控專案風險 |
依專案計畫監控所界定的風險。 |
|
特定執行方法1.4 |
監控資料管理 |
依專案計畫監控專案資料的管理。 |
|
特定執行方法1.5 |
監控關鍵人員的參與 |
依專案計畫監控關鍵人員的參與。 |
|
特定執行方法1.6 |
進行進度審查 |
定期審查專案的進度、執行績效及議題。 |
|
特定執行方法1.7 |
進行里程碑審查 |
於專案里程碑，審查專案的完成情形及執行結果。 |
|
特定目標2 |
管理矯正措施直到結案 |
當專案的執行績效或結果重大偏離計畫時，管理矯正措施直到結案。 |
|
特定執行方法2.1 |
分析議題 |
蒐集與分析議題，並決定採取必要的矯正措施以解決議題。 |
|
特定執行方法2.2 |
採取矯正措施 |
對界定的議題，採取矯正措施。 |
|
特定執行方法2.3 |
管理矯正措施 |
管理矯正措施直到結案。 |
其中專案規劃參數的定義為：構成專案進度與執行績效的代表性指標，它包含工作產品與工作項目、成本、工作量、時程等屬性。工作產品與工作項目的屬性包含如規模大小、複雜度、重量、形狀、安裝或功能等。
(3) PMBOK 2008 versus. CMMI-DEV 1.2
PMBOK 2008所載的監控程序群組包括了九大知識領域的整合、範圍、時程、成本、品質、溝通、風險與外購八個領域，獨缺了人力資源；十個程序中，整合有兩項，範圍有兩項。PMBOK
2004之時，其監控程序群組有十二個程序，多出的兩個程序分別為人力資源中的管理專案團隊，以及溝通中的管理利害關係人，現在已移往執行程序群組，可說更加符合一般專案的現狀。
相對於PMBOK 2008，CMMI-DEV的說明內容，其實也差異不大。專案規劃參數也多屬於範圍、時程、成本、品質的範疇之內；監控關鍵人員的參與，也是著重在利害關係人的參與程度，而非專案的執行團隊；監控專案風險也對等於PMBOK的Monitor and Control Risks；資料管理的監控也可以類比那PMBOK的專案管理計畫跟專案文件集。只是CMMI-DEV在進度的審查上特別強調區別定期與里程碑的審查時點；並且在特定目標2，特別說明當觀察到的實際值偏離規劃值時所要採行的矯正作業，以及議題的解決與處理。
CMMI-DEV的矯正措施，在PMBOK 2004中則相對定義了(i)Corrective Action。(ii) Preventive Action。(iii) Defect Repair。(iv) Request Changes。依據事前與事後、規劃時的不當、執行時的錯誤、需求或者環境的變異，分別有更正、預防、錯誤修正、需求變更等作為。這些作為從建議、核准、實施到追蹤，也要有一個適當的作業與監控的程序，至於措施的影響分類，依據Redo的起點區分為Rework、Replan、Restart。
(4)肥蝦心得
在做了專案的規劃之後，大家當然都是一心期盼能照本宣科，在規劃的時間、成本與品質要求內完成規劃的事項。但是就如思考大師Edward
de Bono在【在沒有問題裡找問題】的第十講中所言的：「計畫是依照現實狀況及推斷當下潮流而擬定的，在快速運轉的世界裡，計畫幾乎總會有失誤。」所以「計畫的不可靠不能作為忽視它的藉口，而是要視為一種提醒我們計畫不能做得沒彈性的警訊。做計畫時要考量到狀況會改變，同時也得顧及特定狀況會不會持續。重要的是規畫時就要顧慮到彈性和不確定性。」
PMBOK與CMMI所強調的監控績效，其實大多都是專案的整體性數值或資料，因此在審視之時必須對於數值的定義、指標的屬性(先驗、同步、後驗)、範圍、假設與限制、資料來源…等有一個清楚與完整的瞭解，甚至就如PMI大力鼓吹的EVM中的CV(成本差異，Cost
Variance)與SV(時程差異，Schedule
Variance)，專案經理也不可就一眼認定它們分別代表成本與時程的狀況，也必須審慎的瞭解背後的原因，諸如是當初規劃之時的假設與限制已產生重大變化、或者是因為隱含其中的因素於當初之時未能明辨，…等等整體與組成的個別要素，專案經理都需要時時謹慎小心。除了參數的正確性與一致性，參數的衡量方法最好還能具備以下四點特性：(i)評量方法應誘導系統各部分做出對系統整體有益的事。(ii)評量方法應引導管理人員注意需要注意的地方。(iii)捉取真實現況。(iv)知悉關鍵路徑。
綜合地來說，專案監控就是要將現行的專案狀態對照規劃的目標。因此除了有效掌握現實資料外，對於原先所設定的目標是否已經內外在環境而有變動也要時刻注意；對於監控使用參數的正確性與一致性，也要加以審慎監控。如果目標與現狀之間出現了原先專案管理計畫中所認定的known-unknown風險，則要採取適當的對應作為，如果發生了意想不到的意外(unknown-unknown風險)，也要設法快速鑑別、確認、分析、評估，採取使用預備金或者中止專案…等作法，以期確保有效達成本專案所設定的目標，就是圖中肥蝦所畫的M也要顧及那Initiating之時Contract、Business
Case等所設定的專案初衷。