Project Planning In 【軟體專案管理】, PMBOK,
CMMI
軟體專案規劃進行的步驟！在探討這議題之前，肥蝦以為要先瞭解專案規劃要做什麼？專案規劃重點就如Scot
Berkun所著"Making Things Happen"(中譯：讓事情發生)第在回答兩個問題：「我們需要做什麼？」「我們要怎麼做？」再進一步簡化，「我們需要做什麼？」可定義為『需求搜集(Collect Requirements)』；「我們要怎麼做？」可視為『設計或指定規格』。光這個What跟How兩字，就是一門非常大的學問，但非常可惜地，如協助進行搜集需求的需求工程(Requirements Engineering)，這在國外已日臻發達的領域，在台灣則還在起步，目前學校或坊間有教授此課程的單位還在少數。在【軟體專案管理】一書中除了在第四章中的第三、四節簡要說明外，也在第八章中的第二節稍有敘述，但相較於其它探討需求工程或軟體系統開發的專門書籍則是明顯不足。
(一)【軟體專案管理】
針對俊峰同學所報告的第三節「專案規劃的步驟及原則」中的七個步驟與九個原則，肥蝦依據個人有限的經驗，將其合併整理如下：
|
步驟次序
|
步驟名稱
|
原則
|
|
步驟一
|
制訂專案計畫的整體目標與策略。
|
(1)目標要清晰且正確。
|
|
步驟二
|
進行外在環境分析與內部分析。
|
(2)規劃過程須透過群體討論方式。
|
|
步驟三
|
制訂一份推動的時程表與工作項目。
|
(2)規劃過程須透過群體討論方式。
(3)建立一套資訊系統作為專案規劃的基礎。
(4)計畫內容必須建立在現有的資源基礎之上。
(5)對於執行計畫項目必須設定最大容忍的風險。
(8)為提升估計的準確性，有必要將複雜的專案做適當細分。
|
|
步驟四
|
研擬一些可行的方案。
|
(2)規劃過程須透過群體討論方式。
(6)重視軟體品質並將它列為最重要的考慮因素。
|
|
步驟五
|
評估與選擇最佳的方案。
|
(2)規劃過程須透過群體討論方式。
(7)重視人力資源管理並做妥善的規劃與運用。
|
|
步驟六
|
撰寫一份詳細的專案計畫書。
|
(9)專案規劃告一段落後，宜採漸進方式做修正工作。
|
|
步驟七
|
呈上級主管核准後公布實施。
|
|
肥蝦以為對目標設定與描述的要求，除了要做到本書對【目標】的描述：「必須將目標與計畫作緊密結合，目標設定應該以具體化且可以達成為最高原則。」之外，個人以為可以參考所謂良好目標的S.M.A.R.T.特質，這SMART可不是書本4.4節Hartman與Ashrafi(2004)所提出的SMART專案規劃方法論。良好目標五個特質的簡單說明如下：
(1)明確(Specific)：即是明確交代出因、事、人、時、地、物。
(2)可量測(Measurable)：明確定義衡量的單位、方法、公式，以及對應的比較標準與Control
chart的範圍。
(3)行動導向(Action-oriented)：這個目標是以行動為本質的，需要用行動去達成的。
(4)實際可行(Realistic)：界定出已有的環境、狀態、資源、能力、技術與限制，以及對於到目的之間的差距達成的機率是合理可接受的。
(5)適時(Timely)有時間性的，並可因應內、外在環境變化及時調整，並且最好有一些明確的反應機制。
(二)PMBOK 2008
【軟體專案管理】的規劃步驟與原則，相對於PMBOK的規劃流程群組，PMBOK 所述是更為完整和有條理。PMBOK 2008年版提出了二十個流程，其程序跨越了所有的知識領域。相關的二十個流程與說明，以及對應的知識領域整理如下表：
|
流程
|
說明
|
所屬知識領域
|
|
5.1Collect
Requirements
|
The
process of defining and documenting stakeholders ' needs to meet the project
objectives.
|
Project
Scope Management
|
|
5.2Define
Scope
|
The
process of developing a detail description of the project and product.
|
Project
Scope Management
|
|
5.3Create
WBS
|
The
process of subdividing project deliverables and project work into small, more
manageable components.
|
Project
Scope Management
|
|
6.1Define
Activities
|
The
process of identifying the specific actions to be performed to produce the
project deliverables.
|
Project
Time Management
|
|
6.2Sequence
Activities
|
The
process of identifying and documenting relationships among the project
activities.
|
Project
Time Management
|
|
6.3Estimate
Activity Resources
|
The
process of estimating the type and quantities of material, people, equipment,
or supplies required to perform each activity.
|
Project
Time Management
|
|
6.4Estimate
Activity Durations
|
The
process of approximating the number of work periods needed to complete
individual activities with estimated resources.
|
Project
Time Management
|
|
6.5Develop
Schedule
|
The
process of analyzing activity sequences, durations, resources requirements,
and schedule constraints to create the project schedule.
|
Project
Time Management
|
|
7.1Estimate
Costs
|
The
process of developing an approximate of the monetary resources needed to
complete project activities.
|
Project
Cost Management
|
|
7.2Determine
Budget
|
The
process of aggregating the estimated costs of individual activities or work
packages to establish an authorized cost baseline.
|
Project
Cost Management
|
|
8.1Plan
Quality
|
The
process of identifying quality requirements and/or standards for the project
and product, and documenting how the project will demonstrate compliance.
|
Project
Quality Management
|
|
9.1Develop
Human Resource Plan
|
The
process of identifying and documenting project roles, responsibilities, and
required skills, reporting relationships, and creating a staffing management
plan.
|
Project
Human Resource Management
|
|
10.2Plan
Communications
|
The
process of determining the project stakeholder information needs and defining
a communication approach.
|
Project
Communications Management
|
|
11.1Plan
Risk Management
|
The
process of defining how to conduct risk management activities for a project.
|
Project
Risk Management
|
|
11.2Identify
Risks
|
The
process of determining which risks may affect the project and document their
characteristics.
|
Project
Risk Management
|
|
11.3Perform
Qualitative Risk Analysis
|
The
process of prioritizing risks for further analysis or action by assessing and
combining their probability of occurrence and impact.
|
Project
Risk Management
|
|
11.4Perform
Quantitative Risk Analysis
|
The
process of numerically analyzing the effect of identified risks on overall
project objects.
|
Project
Risk Management
|
|
11.5Plan
Risk Responses
|
The
process of developing the options and actions to enhance opportunities and to
reduce threats to project objects.
|
Project
Risk Management
|
|
12.1Plan
Procurements
|
The
process of documenting project purchasing decisions, specifying the approach,
and identify potential sellers.
|
Project
Procurement Management
|
|
4.2Develop
Project Management Plan
|
The
process of documenting the actions necessary to define, prepare, integrate,
and coordinate all subsidiary plans.
|
Project
Integration Management
|
初看之下，會以為肥蝦以為上述的流程，其實可以用很口語的一個故事情節來說明。交代故事之前，當然得先交代一下起始流程群組(Initiating Process Group)的4.1 Develop
Project Chart與10.1 Identify Stakeholders。肥蝦在獲得主管的授權下接手了一個專案，因此肥蝦首先就去瞭解公司對此專案的立場？客戶是誰？客戶所屬的業界與市場定位？客戶指派參與專案軟體系統建置的單位、人員與決策者？合約內容(由前往後看三遍，再由後往前看兩遍)？合約中所要購置的資訊系統？該業界間對此系統的一般功能要求？軟體資訊業界中相關系列產品的功能？以上這些都算是起始流程的階段。
緊接著就是正式規劃的開始。搜集需求，要能有效的引導利害關係人的需求，就必須整個團隊對於專案的內容與目標有一個基本的認識，資深的系統分析人員對業務與技術要有所瞭解，專案管理團隊要能明白公司與專案的商業立場。專案的執行方案要在商業(Business)觀點，技術(Technology)觀點，以及顧客(Customer)觀點間求取一個交集與平衡點。接著就是專案團隊要針對需求整體構圖中研擬多個可行方案，並擇一以為建立WBS的策略。接著就可轉交指定負責人員，根據所負責的工作包擬定活動，並回報予專案管理團隊。專案管理團隊應會同工作包負責人員一起建立活動的優先順序與其間的關聯，尤其針對外在或必要的依賴間特別加註與小心。緊接著就是一起概估活動所需使用的資源與工期。專案管理團隊應依據活動所需要的的資源與工期，進行協調與溝通，並估算成本，並且依據專案的執行方案策略準備適當的準備金與緩衝期間，建立專案的時程與成本，專案時程與成本應呈報予公司，公司相關部門會依據現金流量缺口或行政管理加上管理準備成為本案之預算，並且決定專案的時程基準，以為通告所有利害關係人的資訊。在公司設定預算之時，專案團隊應依據專案的需求工作內容、利害關係人的要求與專案成本等諸多限制下，設定本案的品質水準與達成此水準所需要的衡量指標與管理的計畫。屆此，專案的Triple-Constraints + Quality的規劃算是暫告一個段落。
所謂「事在人為」，因此接著就是要處理人的問題。第一當然要設法緊鑼密鼓去找人了！但要找什人？找的人要跟活動如何匹配？如何找人？要如何跟公司人事部門溝通？後續如何培育與管理專案團隊人員？這些當然要先想一想，並寫下計畫。「作人比做事重要！」這中國古智慧對專案管理團隊與專案經理也是首要的工作，既然我們已經從利害關係人搜集到需求，有了這一層的接觸，因此我們對這些人應該有了基本的認識，對於他們的習慣、溝通方式與心中對此專案的期待應該有一些瞭解，既然瞭解，那就要述之於文字，寫下計畫，其中不要忘了隨著專案的進行，一定會有些週遭的人、事、物會不斷的涉入與互動，因此也要說明如何如何去適時更新這個計畫。
風險、風險、風險，有人、有事就有問題，有問題就有風險；有方案策略就有假設跟限制，有假設跟限制就有風險；專案需要時間來完成，時空變遷就有風險。既然專案團隊對於Triple-Constraints + Quality有了一個初步的共識，那大家就說說對於這個專案有什麼看法，對什麼感到擔心、害怕，對什麼抱有期待跟希望，如何試圖去克服、避免或捉取這些未發生之事，如何保持警醒之心專案期間注意防範可能發生之事，那就擬具一個風險的管理計畫，用此為依據，去辨識所有設想的到的風險，描述它，想想何可能的作為。接著將這些風險進行定性的分析與處理，試圖找出原因，並且依據類型、重要性、可能性去分類，排出優先順序，列示處理反應時間的急迫性，以及分析結果的趨勢等資料。定性分析完就接著做定量的分析，利用專家給定或歷史資料演算出的機率、並將可能危害或增益的程度轉換為金錢單位，進行模擬的分析或模型估算，以瞭解專案部分或整體的可能損失或利得。列示出相關可能風險並具以分析後，接著就要設法思考對策，對策可以是避免(利用)、轉移(分享)、減緩(增強)、或者就是鼻子摸著默默接受。
作完了專案的事(Triple-Constraints + Quality)、人(Human Resource + Communications)、以及未來情況變化模擬與因應對策(Risk)的規劃之後，專案管理團隊應就專案內外環境、相對利益與公司政策等原則，決定那些部份需要由外購入，其中重點之一就是藉由向外採購轉移專案的風險，以期盼能減少專案失敗對公司組織或個人的損害。
以上的規劃需要加以統籌與整合，提出相對應的專案管理計畫；但是，專案管理計畫的提出不代表規劃過程就此完畢。在這以上洋洋灑灑的過程中應注意是否有某一規劃活動或區塊流程之內需要反覆的作業，甚至在專案的執行期間也要不斷的回頭審視專案管理計畫，定期/不定期的檢討與更正，甚至進行重規劃的動作。
(三)CMMI-DEV 1.2
什麼是CMMI-DEV呢？這在軟體資訊業耳熟能響的名詞究竟代表了企業或組織具有何種優越的能力呢？肥蝦常聽到的最多反應：「好多的文件！」據內基美隆大學 (Carnegie Mellon University) 的軟體工程學院
(Software Engineering Institute, SEI)在其文件中的說明：「能力成熟度整合模式 (Capability Maturity Model Integration,CMMI)是一個針對產品與服務發展的流程改善成熟度模式。」望文生義，因此其重點在於流程的持續改善。而CMMI-DEV(CMMI-Development)則是利用CMMI 的一組核心流程組件，附加相關流程的方式，擴充成為具有高度共通內容的特定應用模式。而此特定應用模式是為了協助組織改善其產品與服務之發展與維護流程。
能力成熟度整合模式 (Capability
Maturity Model Integration,CMMI)將成熟度區分為五個等級－CMMI Level
1:初始級(Initial)、CMMI Level 2:管理級(Managed)、CMMI Level 3:已定義級(Defined Process)、CMMI Level 4:量化管理級(Quantitatively Managed)、CMMI Level 5:最佳化級(Optimizing)。其中，管理級(Managed)的焦點即在於。
|
成熟度等級
|
焦點
|
流程領域
|
|
初始級(Initial)
|
稱職人員與勇敢作為
|
|
管理級(Managed)
|
基礎專案管理
|
CM - Configuration Management
MA - Measurement and Analysis
PMC - Project Monitoring and Control
PP - Project Planning
PPQA - Process and Product Quality
Assurance
REQM - Requirements Management
SAM - Supplier Agreement Management
|
|
已定義級(Defined
Process)
|
程序標準
|
DAR - Decision Analysis and Resolution
IPM - Integrated Project Management +IPPD
OPD - Organizational Process Definition
+IPPD
OPF - Organizational Process Focus
OT - Organizational Training
PI - Product Integration
RD - Requirements Development
RSKM - Risk Management
TS - Technical Solution
VAL - Validation
VER - Verification
|
|
量化管理級(Quantitatively
Managed)
|
數字管理
|
QPM - Quantitative Project Management
OPP - Organizational Process Performance
|
|
最佳化級(Optimizing)
|
持續流程改善
|
CAR - Causal Analysis and Resolution
OID - Organizational Innovation and
Deployment
|
此處，肥蝦僅就個人的瞭解，說明CMMI成熟度第二級的流程領域中的專案規劃流程。CMMI設定管理級中專案規劃的目的為：「專案規劃(Project Planning,
PP)的目的，在建立並維護用以定義專案活動的計畫。」其領域包括：(1)發展專案計畫。(2)與關鍵人員適當的互動。(3)取得對計畫的承諾。(4)維護專案計畫。其內容涵蓋：「估計工作產品及工作項目之屬性、決定資源需求、協商承諾、產生時程，以及界定和分析專案風險。訂定專案計畫可能需要反覆上述活動。」除了以上的領域與內容外，CMMI-DEV 1.2還特別強調：「專案進行時，專案計畫常因下列情況而須修訂：需求及承諾變更、不準確的估計、矯正措施及流程變更。說明規劃及重新規劃的特定執行方法，包含在本流程領域之內。」這也是相似於PMBOK的觀念，只是PMBOK是在規劃後續的流程群組中去更新(Update)專案管理計畫，但更新專案管理計畫的執行方法也是必須先載明於專案管理計畫之中。
關於CMMI-DEV 1.2表明專案規劃的起始點則與PMBOK的定義類同－「開始於用以定義產品與專案的需求。」而其特定目標及執行方法摘要，整理如下：
|
項次
|
目標/摘要
|
說明
|
|
特定目標1
|
建立估計值
|
建立並維護專案規劃參數的估計值。
|
|
特定執行方法1.1
|
估計專案範圍
|
建立高階的分工結構圖(WBS)，以估計專案的範圍。
|
|
特定執行方法1.2
|
建立工作產品與工作項目屬性的估計值
|
建立並維護工作產品與工作項目屬性的估計值。
|
|
特定執行方法1.3
|
定義專案生命週期
|
定義專案生命週期階段，並據此建立規劃工作的範圍。
|
|
特定執行方法1.4
|
決定工作量與成本的估計值
|
依據估計理由，估計工作產品和工作項目所需之專案工作量和成本。
|
|
特定目標2
|
發展專案計畫
|
建立並維護專案計畫，以做為管理專案的基準。
|
|
特定執行方法2.1
|
建立預算和時程
|
建立並維護專案預算與時程。
|
|
特定執行方法2.2
|
界定專案風險
|
界定並分析專案風險。
|
|
特定執行方法2.3
|
規劃資料管理
|
規劃專案資料的管理。
|
|
特定執行方法2.4
|
規劃專案資源
|
規劃執行專案所需之必要資源。
|
|
特定執行方法2.5
|
規劃所需知識和技能
|
規劃執行專案所需之知識與技能。
|
|
特定執行方法2.6
|
規劃關鍵人員之參與
|
規劃已界定的關鍵人員之參與。
|
|
特定執行方法2.7
|
建立專案計畫
|
建立並維護全盤的專案計畫內容。
|
|
特定目標3
|
取得對計畫的承諾
|
建立並維護對專案計畫的承諾。
|
|
特定執行方法3.1
|
審查影響專案的各種計畫
|
審查影響專案的所有計畫，以瞭解專案承諾。
|
|
特定執行方法3.2
|
調整工作和資源水準
|
調整專案計畫，以反映可用的資源與預估的資源。
|
|
特定執行方法3.3
|
取得計畫承諾
|
從負責執行與支援計畫之相關關鍵人員取得承諾。
|
在上表中，肥蝦以為應該特別說明的是特定目標1：建立估計值。這裡所言的專案規劃參數，範圍比PMBOK 2008中6.4 Estimate Activity Durations、7.1Estimate Costs所言的” Parametric Estimating”的Parametric要大得多。CMMI-DEV 1.2中所設定的專案規劃參數包括了：「專案從事下列活動所需之所有資訊：規劃、組織、用人、督導、協調、報告及預算。」這幾已等於Enterprise Environmental Factors與Organizational
Process Assets(含Lesson Learned)所能找得到的參數。由於CMMI講的是知識的累積與流程的改善，因此專案規劃參數至少必須考慮到：
(1)專案需求，包括產品需求、組織需求、客戶需求及可影響專案的其他需求。
(2)專案範圍。
(3)已界定之工作項目及工作產品。
(4)技術方法。
(5)已選定的專案生命週期模式(例如：瀑布式、漸進式、螺旋式等)。
(6)工作產品與工作項目的屬性(例如：規模大小或複雜度)。
(7)時程。
(8)把工作產品與工作項目屬性轉換成投入工時與成本的模式或歷史性資料。
(9)決定所需材料、技能、工時及成本的方法(模式、資料、演算法)。
以上的考慮要素，幾乎已是規劃專案所要考量的重點了。
綜合【軟體專案管理】, PMBOK, CMMI上對專案規劃的述說與重點，專案規劃的良窳攸關專案的成敗。為使得專案規劃能落實於往後專案的執行與掌控，有利於專案的進展－擬定有一個可行的訂定符合S.M.A.R.T原則的目標；設定專案進行的策略原則；完善的搜集、引導與溝通客戶的需求；儘可能的參考內、外部資訊；建構合適的專案範圍、時程與成本；設定適當的品質標竿；找到對的人做對的事；時時檢視專案的假設、限制與機會；完善因應利害關係人的重要性暨參與度的溝通方式與內容；決定何者為自製與外購？並加以良善的協調與整合－這種種的一切，都必須於專案規劃之時加以審慎考量。
人們雖常說：「計畫趕不上變化！」但這就如狄波諾(Edward de Bono)在其著作【在沒有問題裏找問題】第十講所說的：「計畫的不可靠不能作為忽視它的藉口，而是要視為一種提醒我們計畫不能做得沒彈性的警訊。做計畫時要考量到狀況會改變，同時也得顧及特定狀況會不會持續。重要的是規畫時就要顧慮到彈性和不確定性。」
文章定位：
