「專案規劃研習營」與後感

【專案管理是一種生活思維】我想很多有心於專案管理的朋友們對此可能有著明顯的記憶，這是Joe與Bryan兩位先進共同於痞客邦建立的部落格，並且有著非常高的點閱率。記得肥蝦當初點閱該部落格，就是看到這句【專案管理是一種生活思維】，因此也才有緣看見兩位大師開辦研習營，在時間得空下，不免蝦血沸騰的報名參加。在6/26-6/27這兩天的活動中肥蝦可說是收穫良多，除了感謝Joe與Bryan的熱心教導與分享，以及大人不計肥蝦過的無禮發言外，也得謝謝其他十五位學員的諒解，以及同組成員Sanders、James與Pei的包容。在台灣目前這塊尚嫌貧脊的專案管理土壤裏，得見更多的朋友對此有著無限的熱情，對於這種跟認證考試課程無關的活動，也有如此多人熱情的參加，以及Joe與Bryan兩位熱心的灌灑，真是讓肥蝦感動滿懷。

肥蝦首先交代一下未與會前對Joe與Bryan的瞭解。記得幾年前在某幾家專案管理補習班師資的名單中已瞻仰過他們兩位的大名，也得知他們是營建工程底。加上肥蝦是故意親赴Joe與Bryan的公司繳錢，因此得以先跟Bryan打了照面(記得對Bryan的第一次印象，肥蝦也是一時傻眼，有點違反了肥蝦的預設，Bryan太"斯文"了！)也初步的瞭解了Joe與Bryan正職工作背後的"金主"，(肥蝦有很多的不良習性，其中有一個便是"大體未動，耳目先行"，出征之前，必定先拜Google大神。)因此6/26到了會場見到了Joe也就不會太意外。

這兩天課程所設計的六個案例，分別對應了專案管理知識體系(Project Management Body of Knowledge, PMBOK)規劃流程的重要程序，引導大家去瞭解何為"Best Practices"與其中程序(process)與要項(item)的真諦。活動則藉由小組活動的互動與彼此間的分享，學習專案成員間為達成既定的目標所必須經歷的共同思考、溝通與協調的過程。因為這六個活動的詳細內容有涉智慧產權，肥蝦僅就活動的名稱，以及肥蝦限於自我經驗與學習，自以為對應到PMBOK的要點與有限感想，與大家一同分享。

(I)活動一：狐狸說：真正重要的事是看不到。

這活動對應到了PMBOK的5.1Collect Requirements，活動的目標是設法去達成5.2Define Scope。

由於肥蝦所屬小組是專案經理的角色，肥蝦從同組成員James的身上看到了年輕時肥蝦的身影。記得以往，肥蝦為了達成目標，努力去思考最佳解，遇事往往先闡述自己的理念與立場，並說服別人贊同自己的看法。而今肥蝦已是身老力衰，以前的活力已不復見，只要方向正確，個人已不再追求所謂的最佳解，而是先行設法尋找滿足專案最低標準的可接受解，再試圖將成員間符合目標的己見串連，建立必要的共識。正所謂：「謀定而後動，知止而有得。」，只要成員肯往目標方向前進，就有時間跟機會爭取最佳解的方法。

(II)活動二：專案管理的基礎建設。

這活動對應PMBOK的5.3Create WBS，以及7.1Estimate Costs與7.2Determine Budget的觀念，活動的目標是設法去建立一個符合專案目標的Work Breakdown Structure，瞭解work package在專案管理的意義與重要性。

對肥蝦來說，這個活動的學習重點是：「在整個專案的過程中，千萬不要忘記專案的目標。」就像Scot Berkun在「讓事情發生」一書中說萬千叮嚀的：「專案管理的挑戰，不僅要在起步時方向正確，還要讓它保持朝向那個方向。」因此規畫WBS的先決要件是，整個團隊已對專案的願景與目標(商業、技術、顧客的交集觀點)有了一致的瞭解與認同。

(III)活動三：你的專案是投資還是投機。

案例活動包含了PMBOK的11.1Plan Risk Management、11.2Identify Risks、11.3Perform Qualitative Risk Analysis與11.5Plan Risk Responses，活動的目標是學習拋開個人固執的偏見，學習尊重團隊成員的看法，經由團隊的腦力激盪，集思廣義建立一個含有機率與衝擊的風險清單與對應的回應計畫。

這是一個有趣的活動，Sanders在此活動中就先提出了一個非常有趣與重要的議題：「什麼才是專案目標以及評量的標準？」但Joe的回應很妙：「由團隊自己認定，這可反應出團隊的價值觀。」在這個活動與成員的互動中，因為成員間以往均不認識，因此對於彼此間的發言均會予以尊重。記得肥蝦以前參與過諸多專案，風險的議題，不是被老闆忽略－都還沒作，哪來這麼多"風險" ，反正案子就是把它作完就對了。－就是資深成員(含肥蝦自己)對於他人所提的意見往往嗤之以鼻－他到底是狀況內，還是狀況外啊？－甚至一些意見於會後(甚至列為公司的金氏記錄)被他人當成笑柄的經驗。

(IV)活動四：笨蛋，問題在資源。

活動案例對應PMBOK的6.1Define Activities、6.2Sequence Activities、6.3Estimate Activity Resources、6.4Estimate Activity Durations、6.5Develop Schedule與7.1Estimate Costs，活動的目標是學習專案間的資源的協調與安排，以及設法追求公司資源的有效利用。

在Eliyahu M. Goldratt所著的「關鍵鏈(Critical Chain)」乙書中，針對專案的衝突與制約提到了四個緩衝的安排－(1)接駁緩衝：針對步驟依存性。(2)資源緩衝：針對資源有限性。(3)瓶頸緩衝：針對必要程序限制性。(4)專案緩衝：針對整體專案性。－這個案例主要在強調學習資源緩衝與專案緩衝的安排。不過肥蝦印象深刻的是，在休息時間與"果凍"及其他幾位同志所談到的Activity、Work package 、Control account 與Project 的Duration陷阱的問題，即是肥蝦以往驗證過Eliyahu M. Goldratt時程估計陷阱的"真理"－ (1)預估時間是根據以往慘痛經驗來制訂，即機率分布曲線的最末端。(2)涉及的管理層愈多，預估時間總數愈大，因為每一階層都會加進各自的安全係數。(3)為防範高層刪減整體完工時間，執行預估者會灌水自保。－因此專案經理要如何得知真正的Duration？在實務上，這當然有很多的"上有政策"，因此當然也有繁多的"下有對策" ，而肥蝦以為惟一解決之道就只有公司與團隊都有良好的專案管理認知與正面文化。

(V)活動五：鐵達尼號的教訓。

這活動對應PMBOK的11.5Plan Risk Responses，此與活動三的目標是相互輝映，學習風險應對計畫對專案時程、成本與品質的影響，依據專案的目標去取得專案風險應對與成本間的trade-off。

就如Joe與Bryan提到的風險因子，與對應的機率，攸關每個專案成員的基本價值觀，藉由風險因子的呈列，以及所選取的風險對策，可以探知每個成員與專案團隊的價值與思考，對於一個專案經理所應具有"知兵"與"知將"的特質要求上，有著莫大的助益。此外，Pei在小組的討論中也提到了Fallback plan(prime response plan不work)以及殘餘風險(residual risks)的觀念。

此時肥蝦的小組可能就是Joe在網誌上所寫的：「有一小組分享了很多PM政治力學…」的那一組。真得是「萬方有罪，罪在肥蝦！」肥蝦真是來此教壞"正直"與"善良"的國家棟樑，「專案在人，惟達目標，只有溝通。」這個是檯面上的，公司跟專案組織都是人的組合體，所謂：「人不為己是要遭天譴的！」sponsor、專案經理、客戶…誰都想從專案中獲利，或者減少損害，因此如何良善進行有形與"無形"，口頭與"實質"上的溝通，是專案經理的首要工作。記得肥蝦以前在也說過：「老闆、或業務、或專案成員在CUSTOMER/USER中沒信用，案子還有辦法成功；若是專案經理在CUSTOMER/USER心中沒信用，那案子是非敗不可(當然前提是你一直待在專案到結束，是你所追求的成功條件之一。)」因此專案經理可以當"狗"，但一定要當個可以被人信賴的"狗"，否則真得會作的"連狗都不如"。

(VI)活動六：巴別塔的神話。

這活動對應了PMBOK的10.2Plan Communications、5.3Create WBS(5.3.2.1Decomposition)與4.2Develop Project Management Plan，此活動目標是學習溝通，分解Scope，以及統一標準在專案中的重要性。另外一提，就是"手要巧"，肥蝦這粗手肥指的，真得只會壞事，還好組員有Pei這如此手巧心細、冰清玉潔的女子，就好像我女兒所說的密蜂姐姐一般(神雕俠侶的喔!)，不然真得研討會就沒完沒了了(巴別塔蓋不起來！)。

肥蝦在會中對此是分享了一點個人小小的看法：「一個專案的成功，除了好的PM外，也要能與PM有一定默契且能力強的成員。」意思就是說：「專案經理在專案中，一定要去設法營造一個核心小組，不惜攏絡、巴結、吐舌頭…甚至恐嚇，就是要去捉到幾個願意幫你，且有著一定默契的中流砥柱。」此外，我想這所謂：「無人在朝，莫作官。」的真義是common sense，不知道也沒辦法了。

整體而言，Joe與Bryan辦得活動非常成功，也深富專案管理教育的意義，參與活動除了可瞭解專案管理的要旨外，也交到了不同產業的朋友，真是讓肥蝦獲益匪淺。會後肥蝦雖然寫了一點建議(就是一點啦)：「專案經理在專案中所進行的溝通、作為與決策，都是在壓力下進行的，建議增加壓力的成份。」專案經理就如那大明王朝所說的"媳婦"一樣，在「上有(惡)雜唸公婆，下有嗷嗷待哺的成群兒女，間有個打懶(打老婆)丈夫」，在這些重重壓力下，如何操扶一家，真得是不容易呀!不過這在壓力下進行專案管理的案例還是在較長天期或進階的研討會下進行，免得沒人來參加Joe與Bryan所舉辦如此良好的研討會，那肥蝦可就是千古罪人了！

再一次，肥蝦得感謝一同參與研討會的15位朋友，以及如此不汲汲於與他人計較名利，不把專案管理當成應付基測國中英語課本教的老師，願意與大家一起交流分享的熱心Joe與Bryan。在肥蝦學習專案管理一路上，有幸遇到此次研討會認識的朋友們，以及小歆(bbs.pm-i-study.net壇主)、Matt(遠景的專案管理老師)、Honda、信輝、Erin、…，以及未曾謀面的雲翔、Foolboy、…，和未來一定會相遇的專案管理同好(肥蝦會努力花錢參加不同課程與活動的！)，相信台灣的專案管理還是有光明未來的。

最後，用Scot Berkun在「讓事情發生」中的一句話，總結肥蝦在此次Joe與Bryan所舉辦研討會的學習心得－「規劃提供了機會檢閱決策、揭露假設、並釐清人們和組織之間的協定。」

※肥蝦的公司同事說：「這是他少數沒有聽到肥蝦參加IT, BI, Economics, PM…相關的研討會或活動後回來"瞧"的一個。」

如何融會貫通PMBOK的T&T(續)

自從上週肥蝦不慚的發表了自己以對應於PMBOK架構的Tools and Techniques整合瞭解法之後，有幾位朋友紛紛鼓勵我繼續TT分類的工作。肥蝦不得不再三解釋：「此觀念其實是因為肥蝦已經年老體胖，對於記憶性的背頌已是力有未逮，因此當初於閱覽PMBOK之際，所想出的笨方法。」因此就如上篇所強調的：「這Infrastructure是一個概括性的輪廓，TT的六個分類也不是絕對區別。???協助在有限的時間之下，減少所耗費的精力，通過PMP的考試。」方法是藉由TT的屬性設法跟Process連結，強調理解的能力，而不是記憶。目標僅只是強調通過考試，而不是拿高分。只是後來在不斷充實自我的專案管理技能與知識之時，發現這架構也有可取的一面。
以下，肥蝦就稍為將－判斷、分析、估算、圖化、計算、檢核－這六個TT分類的內容與項目，加以概括的說明。以免讓朋友們誤以為肥蝦真的是一個只會【唬爛】的Franklin。不過說真格的，肥蝦是定義TT的六個分類是針對實作的部份，真正完整的架構應該是如下圖啦！(被激的吐出來了)
就如PMBOK所闡述的專案管理的progressive elaboration特性，以及PMBOK對每種工具和技術的基本說明，對應到個人以往有限的經驗與知識，當然再配合點肥蝦的【唬爛】功力，把六個分類進行自我擴展的解釋，而其目的不外是設法減少分類的類別，以便於融入至PMBOK的五大流程。但是因為溝通(包含對利害關係人、專案團隊)的工具和技術，就是人家所謂的「專案管理百分之九十的時間都在溝通。」印證肥蝦個人的淺薄經驗，溝通的進行可說貫穿整體的專案流程，因此把它們單獨獨立出來。
肥蝦對於六個類別的解釋與Tools and Techniques如下表，還請各位看倌不要以嚴謹的定義看待肥蝦的分類。
類別 解釋
判斷 人為主觀的認知，憑藉特定人已有的經驗、知識、技能，進行專案目標的釐清與統整的工作。
分析 應用理論的架構與工具，將【判斷】所得的資料，進一步進行專案目標與內涵的確認。
估算 利用數量化工具與模型，將專案內涵進一步予以量化的概估。
圖化 利用圖形工具，根據量化資料予以圖形表示。
計算 利用特定數學公式，進行運算後得出專案的過去、現在、未來可能的狀態。
檢核 重點在於根據特定的標準，驗證專案特定或整合的狀態。
根據以上的TT，加上唬爛為促進的動力，推使專案往完成目標邁進。
以下分別說明工具和技術類別的重點與包含項目，但必須再次強調：「這僅是肥蝦自我理解的方法。」
(一)判斷類
在整合知識領域(第四章)，都要有專案全貌的去思考。此外，需求因人而生，也需要有人去滿足需求。專案經理必須以經驗、知識、技能，進行判斷，因此如何找到對的人(第十章)，問到對的話(第五章)，知道要的基本要求(第八章)，判別可能的風險(第十一章)，再設法找到對的人去完成(第九章)，
4.1.2.1 Expert Judgment
10.1.2.1 Stakeholder Analysis
10.1.2.2 Expert Judgment
4.2.2.1 Expert Judgment
5.1.2.1 Interviews
5.1.2.2 Focus Groups
5.1.2.3 Facilitated Workshops
5.1.2.4 Group Creativity Techniques
5.1.2.5 Group Decision Making Techniques
5.1.2.6 Questionnaires and Surveys
5.1.2.7 Observations
5.2.2.1 Expert Judgment
5.2.2.4 Facilitated Workshops
6.1.2.4 Expert Judgment
6.3.2.1 Expert Judgment
6.4.2.1 Expert Judgment
7.1.2.1 Expert Judgment
7.2.2.3 Expert Judgment
8.1.2.8 Proprietary Quality Management Methodologies
8.1.2.9 Additional Quality Planning Tools
9.1.2.2 Networking
9.1.2.3 Organizational Theory
11.2.2.7 Expert Judgment
11.3.2.6 Expert Judgment
11.4.2.3 Expert Judgment
11.5.2.4 Expert Judgment
12.1.2.2 Expert Judgment
4.3.2.1 Expert Judgment
9.2.2.1 Pre-Assignment
9.2.2.3 Acquisition
9.2.2.4 Virtual Teams
9.3.2.5 Co-Location
12.2.2.4 Expert Judgment
12.2.2.6 Internet Search
4.4.2.1 Expert Judgment
4.5.2.1 Expert Judgment
4.6.2.1 Expert Judgment
(二)分析類
分析的重點就在設法把判斷轉換為實際可執行的專案管理計畫，因此除了第四章整合知識領域不會有之外，其他各知識領域都會有，在五大程序中主要落在planning程序大類。此外，專案的執行結果也必須用分析進一步了解專案的狀態－範圍、時間、成本、風險－並將分析結果呈現給利害關係人。
5.1.2.8 Prototypes
5.2.2.2 Product Analysis
5.2.2.3 Alternatives Identification
5.3.2.1 Decomposition
6.1.2.1 Decomposition
6.1.2.2 Rolling Wave Planning
6.1.2.3 Templates
6.2.2.2 Dependency Determination
6.2.2.3 Applying Leads and Lags
6.2.2.4 Schedule Network Templates
6.3.2.2 Alternatives Analysis
6.4.2.5 Reserve Analysis
6.5.2.1 Schedule Network Analysis
6.5.2.2 Critical Path Method
6.5.2.3 Critical Chain Method
6.5.2.5 What-If Scenario Analysis
6.5.2.6 Applying Leads and Lags
6.5.2.7 Schedule Compression
7.1.2.6 Reserve Analysis
7.1.2.9 Vendor Bid Analysis
7.2.2.2 Reserve Analysis
8.1.2.1 Cost-Benefit Analysis
8.1.2.4 Benchmarking
8.1.2.5 Design of Experiments
8.1.2.6 Statistical Sampling
9.1.2.1 Organization Charts and Position Descriptions
10.2.2.1 Communications Requirements Analysis
11.1.2.1 Planning Meetings and Analysis
11.2.2.1 Documentation Reviews
11.2.2.2 Information Gathering Techniques
11.2.2.3 Checklist analysis
11.2.2.4 Assumptions Analysis
11.2.2.6 SWOT analysis
11.3.2.1 Risk Probability and Impact Assessment
11.3.2.2 Probability and Impact Matrix
11.3.2.3 Risk Data Quality Assessment
11.3.2.4 Risk Categorization
11.3.2.5 Risk Urgency Assessment
11.4.2.2 Quantitative Risk Analysis and Modeling Techniques
12.1.2.1 Make-or-Buy Analysis
12.1.2.3 Contract Types
8.2.2.3 Process Analysis
12.2.2.2 Proposal Evaluation Techniques
5.5.2.1 Variance Analysis
6.6.2.2 Variance Analysis
6.6.2.5 What-If Scenario Analysis
7.3.2.5 Variance Analysis
10.5.2.1 Variance Analysis
11.6.2.3 Variance and Trend Analysis
11.6.2.5 Reserve Analysis
(三)估算類
分析完後當然就要進一步根據分析結果，考量所需要的時間跟成本(必須提醒您品質是要花錢的，風險更是要花錢的。)
6.3.2.3 Published Estimating Data
6.3.2.4 Bottom-Up Estimating
6.3.2.5 Project Management Software
6.4.2.2 Analogous Estimating
6.4.2.3 Parametric Estimating
6.4.2.4 Three-Point Estimates
6.5.2.4 Resource Leveling
6.5.2.8 Scheduling Tool
7.1.2.2 Analogous Estimating
7.1.2.3 Parametric Estimating
7.1.2.4 Bottom-Up Estimating
7.1.2.5 Three-Point Estimates
7.1.2.7 Cost of Quality
7.1.2.8 Project Management Estimating Software
7.2.2.1 Cost Aggregation
7.2.2.4 Historical Relationships
8.1.2.2 Cost of Quality
11.5.2.1 Strategies for Negative Risks or Threats
11.5.2.2 Strategies for Positive Risks or Opportunities
11.5.2.3 Contingent Response Strategy
12.2.2.3 Independent Estimates
6.6.2.4 Resource Leveling
(四)圖化類
人說「文不如表，表不如圖。」因此以圖形顯示專案的估算與進度，才能顯示出專案經理的價值。(附帶一點，PMBOK的圖化工具重點落在Project schedule network diagram跟品質管控的部份。)
6.2.2.1 Precedence Diagramming Method
8.1.2.3 Control Charts
8.1.2.7 Flowcharting
11.2.2.5 Diagramming Techniques
8.3.2.1 Cause And Effect Diagram
8.3.2.2 Control Charts
8.3.2.3 Flowcharting
8.3.2.4 Histrogram
8.3.2.5 Pareto Chart
8.3.2.6 Run Chart
8.3.2.7 Scatter Diagram
(五)計算類
莫忘earned value可是PMI大力吹捧的以金錢表示專案狀態、進度、預測與風險管控的計算工具，計算的結果當然要給利害關係人看囉！
7.3.2.1 Earned Value Management
7.3.2.2 Forecasting
7.3.2.3 To-Complete Performance Index
10.5.2.2 Forecasting Methods
11.6.2.4 Technical Performance Measurement
(六)檢核類
檢核當然就是Monitoring and Controlling的重要工具了！
4.3.2.2 Project Management Information System
8.2.2.1 Plan Quality and Perform Quality Control Tools and Techniques
8.2.2.2 Quality Audits
9.4.2.4 Issue Log
5.4.2.1 Inspection
6.6.2.1 Performance Reviews
6.6.2.3 Project Management Software
6.6.2.6 Adjusting Leads and Lags
6.6.2.7 Schedule Compression
6.6.2.8 Scheduling Tool
7.3.2.4 Performance Reviews
7.3.2.6 Project Management Software
8.3.2.8 Statistical Sampling
8.3.2.9 Inspection
8.3.2.10 Approved Change Requests Review
10.5.2.4 Reporting System
11.6.2.1 Risk Reassessment
11.6.2.2 Risk Audits
11.6.2.6 Status Meetings
12.3.2.1 Contract Change Control System
12.3.2.2 Procurement Performance Reviews
12.3.2.3 Inspections and Audits
12.3.2.4 Performance Reporting
12.3.2.5 Payment Systems
12.3.2.6 Claims Administration
12.3.2.7 Records Management System
4.5.2.2 Change Control Meetings
12.4.2.1 Procurement Audits
12.4.2.2 Negotiated Settlements
12.4.2.3 Records Management System
再加上唬爛一類：唬爛的先決條件是要知道唬爛的對象，對象的種類包含利害關係人(第十章)，專案團隊成員(第九章)，外包協力廠商(第九章)。
7.2.2.5 Funding Limit Reconciliation
10.2.2.2 Communications Technology
10.2.2.3 Communication Models
10.2.2.4 Communication Methods
11.4.2.1 Data Gathering and Representation Techniques
9.2.2.2 Negotiation
9.3.2.1 Interpersonal Skills
9.3.2.2 Training
9.3.2.3 Team-Building Activities
9.3.2.4 Ground Rules
9.3.2.6 Recognition and Rewards
9.4.2.1 Observation and Conversation
9.4.2.2 Project Performance Appraisals
9.4.2.3 Conflict Management
9.4.2.5 Interpersonal Skills
10.3.2.1 Communication Methods
10.3.2.2 Information Distribution Tools
10.4.2.1 Communication Methods
10.4.2.2 Interpersonal Skills
10.4.2.3 Management Skills
12.2.2.1 Bidder Conferences
12.2.2.5 Advertising
12.2.2.7 Procurement Negotiations
10.5.2.3 Communication Methods
以上是基於自己的體會，初淺的作了TT分類，若再加上對每個Process的目地，想想可能需要的工具，依肥蝦的經驗，TT項目在一眼中可判別落在那一個Process的正確率有九十%或以上，反正PMP的考試全部都是選擇題，又是單選，因此理解比背誦，在應付考題上會有更大的成功機率。

如何融會貫通PMBOK的T&T

昨日肥蝦與MATT 、小歆、EVA、BEN，齊約在鍋大爺大快朵頤一番，想想這滿桌肥滋滋的肉，吃入蝦口之後，血壓真是即刻破表。唉！不過這關於肥蝦自身不知檢點的問題是暫且不表，席中MATT提到了一個PMP準備考試的問題，倒是蠻有趣的。

MATT說很多大師會要求學生背好PMBOK 42 Processes的ITTO的Data Flow Char考試就沒問題。而肥蝦自己倒是跟MATT有志一同，現在第四版PMP的考題都是以情境題為主，死背可不是必上的保證囉！想當初肥蝦在構思PMP的複習教材資料之時便不再強調"死記"，而是從PMBOK的第一、二、三前半章入手，先說明整個專案管理的Underlying ，接著以專案管理的Flow貫通42 Processes Input與Output，最後再以專案管理工具與技術的自身特性，嵌入了42 Processes的Flow，完整交代了PMBOK的Infrastructure。肥蝦不敢自誇這種方式是獨一無二、全球首創，但是對沒有時間的上班族與記憶能力弱於理解能力的學員，我想應該還蠻合用的，當學員瞭解了PMBOK的全貌，再多看幾次，認真做些題目，很多該背的東西，也不用特別記憶就錄入腦袋了。

以下肥蝦就概略的闡述個人如何整理與歸納專案管理工具與技術(TT)的特性，並進一步嵌入專案管理42 Processes的主軸，當然完整介紹是需要花點時間的，而且肥蝦也不可掠人之美呀。

PMBOK內明文記載的TT共有179個，扣除了重複的，也有130個，這光瞭解每個TT的目標與概說，就要花費不少時間，更遑論是每個TT的詳細內容與操作指引了。因此肥蝦是將TT以：(一)綜觀與局部。(二)質性與量性。以專案管理計畫的progressive elaboration特性，界定TT的使用是由綜觀到局部，由質性到量性的趨勢，大約劃分了－判斷、分析、估算、圖化、計算、檢核－六個TT分類，再配合IPEMC的五大流程特性，而嵌入到42 Processes之中。

肥蝦基於自己的認識繪製了如上圖的PMBOK Infrastructure：當然這Infrastructure是一個概括性的輪廓，TT的六個分類也不是絕對區別。因為此Infrastructure圖形的目的，只是期盼藉由圖化式的基礎描述，進一步幫助學員在閱覽42個Process的目標暨內涵，以及對應的ITTO之時能不忘全貌，加深學員的印象，協助學員在有限的時間之下，減少所耗費的精力，通過PMP的考試。

論專案的價格與成本

－兼論為什麼很多的資深專案經理無法通過PMP考試？－

這陣子肥蝦忙著規畫新案，世新的課業與社區管委會主委的工作，加上血壓也疑似因為前次輸尿管結石處理不當，一直偏高，因此這陣子這可說是心力交瘁，讀書會不得不暫停，一些心中想紓發的感想，也沒有時間述之於文字，只能空在那裏。好不容易，一些急迫的工作暫時告一段落，因此再次動動蝦螯，將前陣子參與公司內部其他部門的專案管理研討會的心得感想繕打出來。

這次研討會起因於另一部門經理使用公費送該部門的同仁參加有關專案管理相關的課程，因此這些同仁就必須於課程結束後向其他同仁簡報該課程的精華與心得。肥蝦有幸得予參加該研討會，在研討會的整體過程中有一非常資深的專案經理不斷質疑PMI的專案管理知識體系，尤其對於專案的報價與專案的成本，有著強烈的質問，伊認為專案經理要能考量公司的內外環境，提出相當精準的專案價格，並以同一資訊系統專案，在名稱與範圍相差不多，為何IBM的報價與一些小公司的報價可以差上數倍甚至數十倍為例子，要求簡報的同仁說明。

在這場研討會中，肥蝦不禁想到市場上對PMP的諸多質疑之一：「為什麼很多的資深專案經理無法通過PMP考試？」

肥蝦個人以為，因為早期臺灣的專案管理環境並沒有一套稍具完整知識架構的專案管理理論，現今大多資深的專案經理很多都是早期的超級程式設計師，或是專案行政人員，或是業務人員轉任。因此在對專案的認知上，就是以自我的經驗與前輩的傳承為依據，但也是因為受制於自身經驗的跼限性，資深專案經理在專案參與的過程中不免以偏概全，甚至無法釐清業務經理與專案經理之間應有的分際，所以肥蝦大都可從資深專案經理在專案管理的作為中，八九不離十的猜測出伊等的出身背景。

肥蝦並不是輕視或是有任何不敬的態度來檢視這些資深的前輩，而是設法用一個例子來說明專案的價格與成本間的不同考量，進一步說明肥蝦心中以為業務經理與專案經理的差別。

先從PMBOK的理論說起，在整本「專案管理知識體系指南」中並為明文提到專案的報價應要如何計算，而是說明如何謹慎考量與建構成本或預算(在第七章專案成本管理)；書中若是提到攸關價格的部分，則是提告供應商的價格(在第七章專案成本管理)與採購的合約價格(在第十二章專案採購管理)。因此專案管理的著眼點還是在於專案成本的有效分析、估量、掌理與監控。而專案成本的分解圖，最有名的就是RITA的成本架構圖。

接著肥蝦要說明的是專案的訂價。專案的價格，個人以為應從行銷與經濟的觀點來看待專案的報價。在經濟學中強調產品的價格(Price)來自於價值(Value)和成本(Cost)和市場中的供給與需求。在價值方面可以細分為如產品價值、服務價值、個人價值、形象價值。在成本上則可區別為金錢成本、時間成本、精力成本及心理成本等等。在市場的供給與需求上，個體經濟學的觀點，廠商的供給函數可由成本函數進一步導出，並為一對一的對應關係，以及市場的結構－完全境爭、寡佔、獨佔；需求函數則可由效用(消費者的價值認定)推導而出。但在市場這一面向，肥蝦以為應該再加入行銷的觀點切入。行銷從以廠商觀點的4P理論(Product產品, Price價格, Place通路, Promotion促銷)，到跟客戶互動的5C(Customer客戶, Cost成本, Convenience便利, Communication溝通, Community社群)，到顧客導向的4R(Relativity關聯, Reaction反應, Relation關係, Retribution反饋)，其所反映行銷中對於價格的考量，並非單純化的僅是成本與價值，而是進一步把客戶的持續經營也納入思考之中。

因此對於專案的成本與專案的價格，是何種關係？業務經理與專案經理的思考面向應該如何分野？

肥蝦以一個簡要的圖形表示兩者間的關係：

專案經理應該是考慮特定專案的縱深面向，提出成本，並加上管理階層所提出的管理預備金(Management Reserve)提出預算；業務經理則以顧客持續經營與顧客的導向從4R到5C到4P，加以結合專案經理所提出的成本與預算，擬定出具有競爭力，最符合公司整體利益的價格。進一步，業務經理應從專案價格的觀點對專案成本的影響與專案經理進行溝通，經由彼此間的溝通協商，設定一個平衡的專案成本。

所以專案成本不等於專案報價，業務經理以廣度為考量，專案經理以深度為考量，但最終兩位經理間所要追求的一個平衡的專案預算，以及一個符合公司最大整體利益的價格，專案經理則戮力追求成本與預算的掌控。
為什麼很多的資深專案經理無法通過PMP考試？」肥蝦以為：並不是資深專案經理不夠聰慧，也不是資深專案經理的經驗不重要，更不是PMP的考試脫離了實務，或者是我們現有的經驗無法符合所謂的"國際"觀念。其中可能的答案之一恐怕是：資深專案經理在接觸之時是以自身經驗去批判PMBOK，而不是設法把PMBOK溶入到自身的經驗，導致應試之時，對於情境題目是以批判PMBOK的心態作答，以致與PMI所設想的立足點相差太大。

PMBOK的應用－【賣辣椒的女人】

自從肥蝦通過PMP考試後，在工作職場中總有不少長官或朋友常會問的問題就是：「如何把PMBOK的流程應用到專案中?」

大哉問！說真格得，PMBOK的流程從2000年的39個，到2004年的44個，至目前的42個，若加上每個流程的輸入與產出，如何應用到實際的工作中，這已是一個非常的難題，那就更遑論那眾多的工具了。

如何把專案管理知識體系應用到實際的專案，甚至生活中呢？是不是通過所謂的PMP考試，就是一個稱職的專案經理？是不是在特定行業或特定的個案中，是一個良好的專案經理，就代表他永遠都是一個稱職的專案經理呢？

肥蝦我個人的答案是否定的！書就只是書，工具就只是工具，Lessons Learned就只是Lessons Learned，這都是死的，就算PMBOK會四年調整一次，那又代表它能把所有攸關專案管理的常識、知識與特質，清楚描述嗎？

重點還是在專案經理自身的修為、信心與態度，書是死的、考試是死的、而人是活的！因此如何活用、適用、量用、衍用這些死知識，才是專案經理應強加鍛鍊的功課！

肥蝦在網路上看到此篇【賣辣椒的女人】，足以說明肥蝦心中對PMP證照與PMBOK的心態－「生活中的智慧可以被寫成書，但你不能簡單地照著書上寫的智慧去生活，因為生活只能是鮮活而靈動的！不要在智慧中夾雜著傲慢，不要使謙虛缺乏智慧。」


【賣辣椒的女人】

賣辣椒的人，恐怕經常會碰到這樣一個眾所周知的問題，

那就是不斷會有買主問「你這辣椒辣嗎？」
不好回答。答「辣」吧，也許買辣椒的人是個怕辣的，

立刻走人；答「不辣」吧，也許買辣椒的人是個喜吃辣的，生意還是做不成。

當然解決的辦法也眾所周知的經典，那就是把辣椒分成兩堆，

吃辣與不吃辣的各選所需，這是書上說的。
我一天沒事，就站在一個賣辣椒婦女的三輪車旁，

看她是怎樣解決這個二律背反難題的。

趁著眼前沒有買主，我自作聰明地對她說：
「你把辣椒分成兩堆吧，有人要辣的你就跟他說這堆是，

要不辣的你就給他說那堆是。」
沒想到賣辣椒的婦女卻只笑了笑，輕聲說：「用不著！」
說著就來了一個買主，問的果然是那句老話「辣椒辣嗎？」

賣辣椒的婦女很肯定地告訴他：「顏色深的辣，顏色淺的不辣！」
買主信以為真，挑好辣椒付過錢，滿意地走了。

也不知今天是怎麼回事，大部分人都是買不辣的，

不一會兒，顏色淺的辣椒所剩無幾了。
我於是又說：「把剩下的辣椒分成兩堆吧！不然就不好賣了！」

然而，賣辣椒的婦女仍是笑著搖搖頭，

說；「用不著！」又一個買主來了，問：「辣椒辣嗎？」

賣辣椒的婦女看了一眼自己的辣椒，信口答到：「長的辣，短的不辣！」

果然，買主就按照她的分類標準開始挑起來。

這一輪的結果是，長辣椒很快告罄。看著剩下的都是深顏色的短辣椒，

我沒有再說話，心想：這回看你還有什麼說法？

沒想到，當又一個買主問「辣椒辣嗎」的時候，

賣辣椒的婦女信心十足地回答：「硬皮的辣，軟皮的不辣！」

我暗暗佩服，可不是嘛，被太陽曬了半天，確實有很多辣椒因失水變得軟綿綿了。
賣辣椒的婦女賣完辣椒，臨走時對我說：

「你說的那個辦法賣辣椒的人都知道，而我的辦法只有我自己知道！」



我忽然有所頓悟：

生活中的智慧可以被寫成書，

但你不能簡單地照著書上寫的智慧去生活，因為生活只能是鮮活而靈動的！

不要在智慧中夾雜著傲慢，不要使謙虛缺乏智慧。

串連PMBOK IV的思維模式－個人心得

肥蝦這幾日來整理了PMBOK IV的內容,自己想了以下的方式去串連PMBOK IV各章節!

(1)組織活動與專案：區別出組織活動中專案的本質。
-作業與專案
-部門經理與專案經理

(2)組織目標層級與專案：明瞭專案與組織的關聯性。
-Portfolio、Program、Project

(3)組織架構與專案：專案成立的基準原點。
-Organizational Structure

(4)影響專案的外在因素：專案的限制與資源。
-Enterprise Environmental Factors
-Organizational Process Assets

(5)專案參與者的角色：專案的人為互動與責任。
-The category of stakeholders

(6)專案創造的價值：專案成立的價值。
-Project Life Cycle
-Product & Project (Product, service, or result)
-From Product Scope Description to Final Product ,Service, or result

(7)專案文件：專案活動的基準與記錄。
-Project Management Plan
-Project Documents

(8)PMBOK的程序與互動：專案流程的運作。
-9 Knowledge Domains & 5 Process Groups
-42 processes
-throughout the project
-iterative
-Change Requests

(9)PMBOK的工具：專案可參考使用的工具。
-估算工具
-量化工具
-圖形工具
-合約型態
-Cost of Quality

肥蝦目前是利用上述九個區塊架構出PMBOK IV！

不知各位是如何去閱讀PMBOK IV，探討PMBOK的核心精神與應用!

風險鑑別與管理工具-VIRT簡介

「Visual Ishikawa Risk Technique(VIRT) - An Approach to Risk Management」讀後心得
原文網址：http://www.pmi.org/Resources/Pages/Risk-Management.aspx

專案的本質就是【不確定】，因此如何管理、辨識、分析、回應與監控專案的不確定因素，對於專案的成敗有著非常密切的影響！在PMBOK Guide 2008的第十一章風險管理程序群組中列了六個管理程序－11.1 Plan risk management; 11.2 Identify risks; 11.3 Perform qualitative risk analysis; 11.4 Perform quantitative risk analysis; 11.5 Plan risk response plans; 11.6 Monitor and control risks－在鑑別風險程序所產生的risk register，持續地於整個專案生命週期扮演非常重要的角色，需要不斷的追蹤、更新與新增。

在肥蝦個人從事專案的經驗中，很少有專案團隊會專注於風險的管理。一來，是因為專案經理已經花費大量的精力，在滿足緊迫的時程與嚴苛的成本金額要求。二來，風險有點虛幻，因為還沒發生，所以很難擁有實際的感受與急迫感。三來，風險管理的工具，大多感覺太理論了，與現實的專案實際狀況好像有些脫節。

以往，肥蝦自己在整理風險因子列表，會先檢視專案的相關文件(如：合約、RFP、建議書…)；接著詢問已有經驗的同事。再來就是憑藉相關的會議與自己的認知進行分析。在PMBOK Guide 11.2 Identify Risks也提出的七項工具－Documentation review; Information gathering techniques; Checklist analysis; Assumptions analysis; Diagramming techniques; SWOT analysis; Expert judgment。

在鑑別風險因素的程序中，肥蝦個人的慣常作法：(1)先進行SWOT的分析區分出幾個風險類型群組。(2)根據每個風險類型群組思考可能的潛在問題(其實肥蝦之前很少考慮到機會)。(3)思考每個風險間可能存在的關聯性。(4)建立風險清單，標明序號、等級、風險類別、風險項目與內容、負責人、狀態、登錄日期與備註。

但肥蝦遭遇最大的問題是溝通，因為風險清單是以表列與文字的方式呈現，所以很難讓團隊成員或長官瞭解整個風險的架構跟全貌。一旦逐一就每個風險因子進行討論，常會陷入「見樹不見林」的窘境。僅針對每個風險項目深入討論，有時所提出的意見會牽扯到其它的風險因子；但是在缺乏整體架構的討論基礎下，有時會產生太過或不及的回應與處理方式。

Rubin Jen於PMI網站所發表的－「Visual Ishikawa Risk Technique(VIRT) - An Approach to Risk Management」說明了一個風險管理的圖形工具(VIRT)。文章也闡述了風險管理的基本概念－【Risk management should not be performed in isolation and must be performed as a group, while being championed by the project manager.】，以及使用VIRT的步驟－(1)建立風險分解結構(Create the RBS)。(2)鑑別專案失敗要點(Identify Points of Failure)。(3)鑑別顯著的障礙(Identify Significant Obstacles)。(4)分解專案失敗要點至風險細項(Decompose Points of Failure to Detailed Risks)。(5)完成後續的風險管理活動(Complete Following Risk Management Activities)。(6)運用至持續狀態報告與重複狀態顯示(Apply to Ongoing Status Reports and Recurring Status Presentations)。

Visual Ishikawa Risk Technique(VIRT)是一個以圖形呈現與分類風險因子的工具。以圖形陳列出高階的風險群組與風險因子，在依據每個高階的風險因子，繼續探究其下的相關風險要項，其間用實線描繪出風險因素間直接的關聯性，如此可以呈現出一個風險的整體架構，也易讓人具有完整的印象。

肥蝦深覺VIRT是一個不錯的鑑別、追蹤與重新檢視風險的好工具。以肥蝦個人的愚見：如果再以虛線描述之間的不同群組或類別間風險因素的互動，如此將更能助益於之後的風險回應計劃的討論與建構。本文所展現的圖形，即是肥蝦個人稍加修改過的圖形表示法。但是麻煩的是會把圖形弄得非常複雜，因此肥蝦利用MS Visio的圖層屬性去分層表示以保持圖形的明確性與可見性。

本文附屬的圖片，所表現的是肥蝦近來負責內部研發專案的風險清單中的部份項目轉化為VIRT的樣貌。黑框藍底的方塊表示可能導致整個專案失敗的Failure point；紅色橢圓表示主要的風險要素；褐色方框表示次要的風險要素。

其中肥蝦以綠色的虛線表示不同Failure point下風險要素間的邏輯相關，如【外面訓練課程不符合實際需求】與【三個月內完成第一階段雛型】，以及【內部研發成本限制】三者之間也有緊密的互動；【跨部門合作溝通】與【組織部門間成本計價】也有密切的關係。這些關聯的風險因素在後續進行風險質性分析與量性分析，以及擬定回應計劃，都會存在TRADE-OFF或相關性的依存關係。

以上是肥蝦的個人淺見，還請 各位先進不吝指教！

推薦微軟的一位技術經理的程式開發專案管理專欄

昨日有幸與一位微軟的技術經理-周旺暾先生見面，看著他名片上的PMP標識，因此上去台灣的MSDN看看，結果到他所撰寫的程式開發專案管理！

雖然專欄內的篇數不多(僅有三篇)時間也稍嫌久遠，但文章的內容非常不錯！
1.成功開發團隊的八項特質 (2005 年 3 月)
2.軟體架構師的成功秘訣 (2005 年 1 月)※第二篇應該是【程式開發工作的時程預估】。
3.談程式開發專案進度管控 (2004 年 12 月)
大家可以上網參考！
http://www.microsoft.com/taiwan/msdn/columns/PMP/default.htm

肥蝦對於【成功開發團隊的八項特質】乙文最有感觸！近來負責的研發專案，由於團隊成員缺乏一個成長與激勵自我的態度，在溝通與願景的凝聚上困難重重！
特別把八項特質列述於下，以供肥蝦與各位先進一同勉勵與參考！
1.促進開放的溝通
2.為共同的願景工作
3.授權給團隊成員
4.建立明確責任並共同負責
5.專注於提供商業價值
6.為了變動, 隨時保持最佳的彈性
7.投資於品質
8.從經驗中獲得學習

題目在精，不在多；解答在求打通任脈，而不是背答案。

肥蝦我喜歡回應好友們關於PMP題目的疑問，因為一方面可以助人外，最主要還是能清楚的明白自己的成長，以及PM觀念與邏輯的融會。

但是近來發現一些有趣的地方與自己的觀念，提出來予大家討論與溝通！

最近我週遭的朋友或網友喜歡上網或到處去搜集題目，花了很多的時間在作題目！但對於題目的來源，以及答案的正確性，似有不求甚解的現象。

朋友們作了很多我以前沒作過的題目，但對於他們拿著答錯的問題，或相關聯性的問題來討論之時，最直接回應：「答案就是這麼寫的！」

一聽到這個回應，肥蝦就想到曾在IT邦幫忙看到一些IT人對於PMP不屑的原因之一：就在於台灣把PMP當作考試，而不是知識。

朋友們拿著回答錯的題目來討論，直接開頭就問：「為什麼是這個答案!」肥蝦起初都是一臉茫然，因為如果友人是說：「他這個答案好奇怪，因為我認為...。」我都會非常高興！因為肥蝦可以明瞭不同人對於同一個題目的想法跟思考模式，我一直認為PMI所推出考試的目的不在讓別人通過考試；而在把較佳的專案管理模式與思維推廣到每個人的心中！

肥蝦近來在看唐納德．高斯與傑拉爾德．溫伯格寫的"從需求到設計(Exploring Requirements: Quality Before Design)"一書，書中主要提到如何去正確認知使用者的需求，如何以適當的方法與工具釐清溝通者間的"語意曖昧"。

這就拿一次與我家兩位小孩溝通的狀況。我說：「一杯思樂冰$10，您們買兩杯，那爸爸給您們$50，那7-11的姐姐要找給爸爸多少錢？」大女兒接口說出：「$30！」，但小女兒馬上反口說：「不對，是$0！」看著她們兩個低頭私語地進去7-11，我跟我內人去水果攤買個水果。過了一會出來後兩個異口同聲地說：「那7-11的姐姐找給爸爸$0！」我看著她們手上只有兩杯思樂冰，沒有別的!結果姐姐說：因為(1)那7-11的姐姐給她們$30(2)而她們決定不把$30給爸爸=>所以結論是：「那7-11的姐姐找給爸爸$0！」

這對專案管理來說也是一個好的例子！當我們在專案中不管在作溝通或者需求搜集，常會犯的一個毛病：就是認為對方應該要懂的，或對方應該要舉一反三。其實整個活動的流程是有兩個步驟的，我已經先預設了我的假設(她們拿到錢就會給我)！這個假設不就也是風險所在嗎?

肥蝦當初雖不是以非常高分通過PMP，但我在意的是準備考試的過程！我是否瞭解PMBOK的邏輯，在題目的選擇上儘量是在精不在多！因此我只作課程中老師提供的題目，以及RITA每章後面的題目！

因為我個人對於題目的認知是：「題目在精，不在多；解答在求打通任脈，而不是背答案。」肥蝦是發現一些友人已經可以一瞄到題目的一句話馬上就知道答案的地步，但真正在管理或參與專案之時有所謂的最佳或標準答案嗎?現實的環境不是一道四選一的考題模擬的出來的。

對於自己以往作答錯誤的題目，會將其先記入於控管的EXCEL表格中，然後到PMBOK、或RITA、或網站、或其他參考書籍找資料！至於上網問問題，也會把自己的想法或思考寫出來，希望獲得的解答是弄通我思考的邏輯，而不是要答案然後去記他。
肥蝦舉一個我以前問問題的寫法：
=======================================================================
Question : The product audit should NOT contain:
A.Project baseline and current project status.
B.Audit methodology.
C.Future change recommendations.
D.Corrective actions

正確答案是D
在TT中有明確audit有quality audits(8.2),risk audits(11.6),inspections and audits(12.5),procurement audits(12.6)。其它有帶到audit字眼的有inspection,configuration management system。其中有明確提到有audit of product應該只有configuration management system。但PMBOK中並未明確說明product audit。
個人以為答案A與B是無庸置疑的！所以就C跟D中選擇的話，個人選C。
因為在PMBOK第190頁QA的Recommended corrective actions有提到corrective action is an action that is recommended immediately as a result of quality assurance activities, such as audits and process analysis.
另外對於答案C個人覺得"future"這個字眼似乎不太適當
=======================================================================

現在呢！肥蝦知道答案為什麼是D了！
因為product audit參考的是Approved Corrective actions，決不會是直接就是Corrective actions！產出的也應該是Recommended Corrective actions也不會直接就去執行Corrective actions！

雖然有人以為這題目在玩文字遊戲，但對肥蝦個人而言，我更深的體認到一句俗諺：「不在其位不謀其政。」這句話在專案管理的應用意義！

以往(甚至現在)在參與專案的過程中，常會覺得為什麼那個人那麼差勁！明明事態就是這麼顯明，就是要這樣作，他為什麼不作！然後就越俎代庖。後續上事態的發展，如果作對了！也許長官會稱讚您，但對專案成員的互動上就有了不良的影響！如果作錯了，那就更不用說了！

專案管理的學習是無止境的，PMP的考試只是其中的一個里程碑，重要的是把這所有學到的一切融入個人的工作與生活中，我想這才不會讓人瞧不起PMP這張證照！

MBA乎？PMP乎？-兩種管理"專業人材"之我見

就業市場一度上紛紛擾擾，很多人在討論企業管理與專案管理孰重孰輕？就筆者自己的觀點：拋開商業利益的糾葛，其實兩者之間並不違背，而且是相輔相成，並且是糾葛難分的！

一般我們都將企業管理概分為：產(生產)、銷(行銷)、人(組織)、發(研發)、財(財務)，現在很多人又把資訊管理列入；而專案管理則區分為：九大領域：整合、範圍、時間、成本、品質、人力資源、溝通、風險、外購，以及五大程序：起始、規劃、執行、監視與控制、結束。

其間的異同何在? 其實這是一個很大的議題，筆者僅能以自己觀點管中窺天，分享自己的看法。
筆者試著從架構面、功能面、執行面來說明為何兩者間無法切割與區分的原因；最後則試舉一例加以說明。

(一)性質面
(1)長度(時間性)：企業強調的是永續經營；專案追求一定時間內完成。

(2)廣度(全面性)：企業管理的目的是追求企業在不確定的環境中追求成長茁壯；專案管理是要求因應不確定內外環境，追求明確的目標。

(3)深度(周密性)：企業管理首要是確立企業使命，設定企業目標，發展策略，擬定戰略；專案管理是在達成目標的基礎上，遵從戰略的指導，因地制宜的擬定執行計劃。

(4)精確(驗證性)：企業使命一般是無法衡量的，目標與策略的驗證一般可能為廣泛性的數字指標，如：營業額、市佔率、稅前(後)純益、獲利率、股東報酬率…。戰略與計劃則應有非常明確的指標，如：客人流動率、坪效、到訪率、實獲值…。

(二)功能面：
就個人對企業管理的初淺知織，針對企業永續經營的目的作了如下的企業思考與行動的功能結構層級。
(1)使命(Mission)：企業在全球社會中所要扮演的角色。

(2)目標(Target)：企業在使命的驅使下，所要達到的預期成果，可再細分為短、中、長期目標。

(3)策略(Strategy)：為達成目標，因應內外環境的限制與挑戰，整合內外部資源，所訂定的認知地圖。

(4)戰術(Tactic)：在認知地圖的引領下，取得局部領域優勢的可實行方案。

(5)作業計劃(Executive Plan)：執行特定方案的細部執行步驟。

(6)作業程序(Executive Procedure)：執行日常經營活動的執行步驟。

針對已上的企業經營思考與行動的層級，專案的定義在那裏呢？
根據PMBOK 2008對專案的定義：臨時性的(Temporary)，產出獨特產品、服務、或結果(Unique product, service, or result)。因此一般將專案鎖定在作業計劃(Executive Plan)的層級。

但讀者若跳脫臨時性的(Temporary)的特定跼限，以PMBOK對臨時性的(Temporary)的定義：明確的起始與結束時間(definite beginning and end) 則依據結構中對目標的說明，如企業能進一步把短、中、長期明確界定期間(如：一年、五年、十年)，在明確的期間，達成特定目標，這不就是專案的定義嗎？因此在PMBOK 2008的第八頁圖1-1Protfolio, Program, and Project Management Interactions 所表示的三個層級不就正好對應的策略(Strategy) 、戰術(Tactic) 與作業計劃(Executive Plan) 。

(三)執行面
企業管理有六個面向(領域)－生產管理、行銷、組織管理、研發、財務管理、資訊管理；在專案的九大領域中的整合與外購不是就要生產產出，與購入生產過程中需要的產品、服務、或結果，這不是跟生產管理的部分理論雷同。因此筆者依據專案九大領域，排列了一個需要應用到企管六大領域專業知識的對應表。
(1)整合：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(2)範圍：生產管理、行銷、資訊管理。
(3)時間：生產管理、資訊管理。
(4)成本：生產管理、財務管理、資訊管理。
(5)品質：生產管理、資訊管理。
(6)人力資源：組織管理。
(7)溝通：行銷、組織管理。
(8)風險：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(9)外購：生產管理、財務管理。
因此一個專案的執行，需要仰賴企管六大領域相關的執行理論與技能。

(四)舉例
ABC有機食品商，立志成為社會中每個家庭的安全、健康的補給站(使命)，因此立定了為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」因此總經理擬定了行銷策略與生產策略。在戰術上可能選定人口八十萬以上的都會區為集中戰場，利用宅配與網路的通路，以達到市佔率30%；為強化產品優勢，可能希望建置中央供應站或中央廚房，提供五十樣以上的天然食品。
同樣地我們也可將為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」設為一個專案許可證(Project Charter) ，進行一個大型專案(或可稱為Portfolio)－臨時性(為期三年)，獨特結果(提供50種天然食品，給1萬個家庭)。

肥蝦的專案"瞎"日誌-"計劃永遠趕不上變化"之權宜措施(Workaround Plan)

肥蝦這幾日可說是心亂如麻，案子的進度也是零進度。記得在專案管理課程或相關的書籍中，對於風險的處理與對應的應變計劃的規劃邏輯，可說已是相當完善。加以肥蝦自己也有十年的專案經驗，不管是內部研發、產品引入或是產品客製化，所能先行設想到的可能風險，雖不敢說百分之百，也能捉個七八十。
想想WMONEY系統的啟動(Kickoff)會議距今也三週了，當初所考慮到的可能主要風險與應對措失，如：

(一)風險項目:1
(二)風險等級:8
(三)風險名稱:缺乏dotNET 3.5完整的瞭解
(四)風險內容:對WPF,WCF,WF缺乏一定的瞭解在建構系統時將無法達成效率性、可擴展性。
(五)風險負責人:肥蝦
(六)風險應變計劃:(1)請協理詢求臺灣微軟的協助。(2)考慮雇請技術顧問。
(七)風險回應/日期:
(八)關聯風險:
(九)風險類型:技術風險
(十)其它:

(一)風險項目:2
(二)風險等級:7
(三)風險名稱:與現有端末元件的整合
(四)風險內容:現有系統中現有的端末元件是否能直接使用或需配合新架構改寫。
(五)風險負責人:韓舊都
(六)風險應變計劃:(1)研究現有端末元件程式碼。(2)詢求外部既有資源。
(七)風險回應/日期:
(八)關聯風險:(風險項目1)
(九)風險類型:技術風險
(十)其它:

(一)風險項目:3
(二)風險等級:4
(三)風險名稱:現有dotNet開發人力資源不足
(四)風險內容:現有人力專長多在Java與VB6.0，且人員不多。
(五)風險負責人:阿強機器人
(六)風險應變計劃:(1)詢求公司其他部門的人力資源。(2)詢求外部人力資源。
(七)風險回應/日期:
(八)關聯風險:
(九)風險類型:技術風險
(十)其它:

等等...。
在PMBOK 2008也提到對Unknown-Unknown風險可以提列管理準備(management reserves)，對Known-Unknown風險可以依據負面、正面、偶然事件的應對策略─負面：避免、轉移、減緩、接受；正面：利用、分享、提高、接受；偶然事件：(Contingency Responses)可能性應變計劃。如果真得不能事先預估，還有一個WORKAROUND(權宜措施)，這個權宜措施就要看專案管理的經驗與專案經理對內外環境的熟悉度而定了。

在這樣的邏輯下，本來肥蝦認為本案雖然先天不足，但仍可靠後天的努力來克服。但、但...
肥蝦千想萬想也沒想到....
韓舊都病了！反正key resource，生病一下、休個假...什麼的，是常有的，還不至影響大局，反正當初就有估些buffer在！

但是、但是，韓舊都是"腦幹出血"！未來還是一片未知！每天大家耳鬢廝磨的同事，一下子肥蝦也無法適應！腦中一片空白！

現在要叫肥蝦一下提出甚麼權宜措施，是真的一下也不知道！沒錯，在工作上可以先行設法切割韓舊都所負責項目的關聯程度、要求補人、或者暫緩進度...。在一些書上都說要有備援人選，但在臺灣的環境中，這談何容易！備援人選對一個專案團隊、甚至公司，都是奢侈品！

真得，在台灣作IT軟體產業本土開發廠商蠻悲哀的！同事們也是求神拜佛的，尋求所有可能的資源來幫助舊都。肥蝦也只能乞求上天開開眼，心中只希望韓舊都能渡過此劫！

肥蝦的專案"瞎"日誌-明確簡要的需求書(Requirements Document)

需求書肥蝦沒有寫過幾次(因為我大多在vendor side)，但是看過很多次了。正是所謂「沒看過豬走路，至少也吃過豬肉。」因為此次是內部研發的專案，肥蝦必須自己擬定需求書，以為後續專案執行的依據。而且既然是內部使用，就必須要明確、可驗證、可追蹤。

一般需求書會分為十一個段落，但可依實際的狀況與需要刪減。以下簡要說明了肥蝦心目中一般標準的需求書範本：
(一)前言(Business need or opportunity)：描述公司現在所處情境的分析、公司策略與採行此專案的原因。

(二)目的(Business and project objects)：執行專案後所欲達成的目標。

(三)現有環境架構(existed environment)：描述現有的實體環境，與既有的週遭軟、硬體設備。

(四)功能面的需求(Functional requirements)：商業流程所需要的操作面與管理面的作業要求。

(五)非功能面的需求(Non-functional requirements)：作業的效能、資訊安全、備份、備援與回復作業要求等項目。

(六)品質要求(Quality requirements)：可分為程序跟產品兩大部份。在程序上，如：對人員、技術的要求。在產品上，如：文件、設計、程式碼、測試的要求。基本上會針對容錯度、可用性、可靠性、完整性、可擴充性、可驗證性、安全性…等，提出一個明確的標準。如針對系統回應的時間，MTBF(mean time between failure)，MTTR(mean time to repair)等設定一個區間。

(七)驗收/評鑑標準(Acceptance Criteria)：此部份可列出一個功能面定性的checklist或定量的metrics。

(八)指導原則(Guiding principles)：如公司內控規章、程式開發/編碼準則、網路作業安全規範等，內外部的相關法規與依據。

(九)影響分析(Impacts to other organizational areas and other entities inside or outside the organization)：對既有公司內部作業單位、業務單位、研發單位、管理單位、內控與會計單位；外部的股東、既有客戶等的衝擊與影響。

(十)支援與訓練需求(Support and training requirements)：後續上系統的作業支援、維護的要求，以及系統轉移所必要的教育訓練需求。

(十一)需求的假設與限制(Requirement assumptions and constraints)：假設的部份主要來自未來商業發展應用的需求，以及市場競爭立基點；限制則為來自合約上時程與金額的限制。

根據以上的肥蝦的認知，肥蝦花了一天終於寫好了近二十頁的需求書，準備提交給John協理。


文章定位：