「自傘自度還是上帝之手」讀後心得

－兼論科學人雜誌第90期「市場與計劃，缺一不可」－

「自傘自度還是上帝之手」是我閱讀陳沖先生專著的第二本，記得第一本「法國狼與貓頭鷹」是前年於客戶端進行一個專案之時，與我合作的user推鑒我閱讀的。在那個案子我所學甚多，與我合作的users更是讓我受益良多。

陳沖先生，記得在我擔任立委助理之時與他有數面之緣。當時即感覺他的金融實務與財金法律知識非常紮實；但卻隱約感覺此人有點恃才傲物。在觀看這「自傘自度還是上帝之手」之時，感覺上也許是幾次宦途浮沈，展閱他的文章之後，發現他的意見寬容了許多。正巧前日也翻閱了科學人雜誌第90期薩克斯(Jeffrey D. Sachs)先生的專欄－「市場與計劃，缺一不可」發覺兩者在理念之間，有些異曲同工之妙，因此特寫此篇心得以記錄個人的感想。

我於就讀經濟學碩士之時，指導教授的專長在於【發展經濟學】，因此攻讀碩士之時，也修了一年政治研究所所開設的【政治經濟學】課程。這兩個學門均主要在探討經濟環境中，市場與制度這兩個支柱，但彼此間的觀點與立場卻有一定的差異。

就我個人初淺的認知，發展經濟學基本上是尊重市場經濟(看不見的手/上帝的手)的功效，但為弭補市場機能的不足或缺限，則須加以良善規劃的制度(政府管制/那把傘)；而政研所的政治經濟學，感覺上比較偏向政府政策與制度的重要性，經濟就是人為的活動，因此需要加以適當的管制，市場的機能很多時候，只會讓現況脫離了發展的目標與途徑。也許有些讀者感覺：「這只不過是孰重孰輕的問題罷了！」，就我個人的思維與架構來說，卻是非比尋常！

以往個人認為，市場如同流水一般－水往低處流，市場逐利而行；那政策與制度，就如那堤堰一般，藉由增加成本或設定成本，讓水往人們設想的路徑流去，但一旦過於強迫，常會導致堤毀人亡的慘劇發生。近來隨著肥蝦自我工作與社會經驗的成長，深覺任一現象的背後大多有著糾葛難分的事因。各種原因間影響的比重或有深淺，其間的互動關係可能曖昧未明。因此為達成目標、解決問題，就如陳沖先生所言：「政策既定，如何執行？又如何避免副作用？就必須有所配套！」(金管會的好棋，page 109-110)，也如那薩克斯(Jeffrey D. Sachs)先生所言：「不論公私部門，任何大規模的行動要成功，市場與計劃兩者缺一不可。」

在現今之中，市場與計劃兩者之間兩者實無法切割，各位可查看「六法全書」的厚度，就可知道政府的制度何其繁多與重要；參看每日的股市交易，就可知多少人忙於追逐利潤。因此任一現象或問題的背後，影響因素可能是已存在的法令，也可能是市場趨利的誘因，也可能是人性的一時不易變更的固有偏好。而要解決問題就如同pareto法則(80/20法則)，我們僅能就最重要的成因去設法改進。

就如同在【誰是火箭專家】乙文中所說，美國次貸風暴的源頭是：Rocket scientists、Rating agencies、Regulators；而在【原來是國王之手】所認為解決金融風暴的好方法，首推英國的是針對流動性問題，並連結至市場利率的SLS(特別流動性規劃)。陳沖先生的此言深得我心，也給了吾等警語，就同專案經理在設法解決問題達成專案目標一樣，在面對繁多頭痛的病徵之時，如何針砭主要病因，規劃與執行解決之道。

此外在【樓梯間的欄杆】乙文中，作者也以票據法為例，說明經濟方法才是解決經濟問題的有效方式。法制就如同那樓梯間的欄杆，不見得用得到，修法僅是在欄杆上精雕細刻；但如要人不跌倒，重要的還是那樓梯必須拾階平穩。這讓肥蝦想起「愛上經濟」(中譯本經濟新潮社出版)這本書中男主角山姆所言：「伊小時，政府強迫要他家在樓上露台裝設鐵欄杆，政府意圖扮演父母一般的角色，確忘了民眾們應自我培養自己應有的風險與效益間取捨的態度。」這次金融風暴，不管是民眾購買連動債的損害，或者銀行的損失，其主要癥結，不就在於民眾或銀行缺乏自我負責的風險意識，以及應有的管理風險的態度。

台灣金融主管單位積極要求金融業者應該要KYC(Know your customer)，在購買衍生性新商品前，購買者須填寫或回答一定格式的問卷。因此，肥蝦以為政府已設定相關的法規與制度，因此執法重點應在誰逾越了欄杆，而不是如在【誰是火箭專家】陳先生所說：「不懂的商品，別再碰了！」而是設法將商品的資訊公開化與透明化，並建立每人應有的風險意識。

如果有人願意當風險愛好者，又何必去禁止他呢？金融市場之所以發展，不正是這世界上存在了風險中立、愛好與趨避的各色人等嗎？真正重要的是：不如藉由制度與市場的結合。政府可藉由制度，要求具有更多資源的一方，強迫其發佈相關的資訊，再經由市場去解讀與評價，達到一定的目的；並設法把人民當個成人看待，應讓伊培養自我承擔風險的態度。政府主要將功能與角色，應放在那些沒傘可自度之人。對於有傘自度者，推廣風險自負的正當心態，嚴懲翻牆越梯之徒，如此，個人以為才有可能將台灣推向一個區域的金融中心。

利潤與風險實為一體的兩面，追求利益當得承受風險，因此追求多大的利得就得看自我能承受多大的風險。這就如同專案管理一般，專案經理與團隊的要責之一，不就在風險的辨識、衡量、專人專責、監控、報告，以及設法找出風險背後的主因，設法防範於事前，並密切與連貫的連結至公司的風險承受度。

6.3 Estimate activity resources不用Project Scope Statement?

有一位朋友在閱讀PMBOK IV的專案時間管理的規劃程序之時，問了一個問題：「為什麼6.2 Sequence Activities，6.4 Estimate Activity Durations，6.5 Develop Schedule要用到Project Scope Statement，而6.3 Estimate activity resources卻不用呢？」

肥蝦非常欣賞該友人準備PMP考試的心態－去思考PMBOK的邏輯與流程，而不是去背考題！－因為肥蝦一直認為一個欠缺邏輯思考能力的人，恐難擔任專案管理乙職。在肥蝦將當初個人的回應整理如下，希望獲得更多先進的指教！

肥蝦以為在思考Project Time Planning Processes之時應先注意三點：
(一)Activity與Work package的差別：
在PMBOK IV page 426中對Activity的定義是：「A component of work performed during the course of a project.」；而對Work package的定義是：「A deliverable or project work compinent at the lowest level of each branch of the work breakdown structure.」。因此就專案管理的角度而言最小的控管單位是Work package，而Activity是要完成Work package所要進行的活動項目。

(二)五個time planning processes中的關係：
在PMBOK IV page 47的圖3-8中有關Project time management的圖形。

在此圖中，顯示了這五個time planning processes中的關係是彼此兩兩相關的，並不是單向順序的推演。而其中的關鍵是何者呢？就是每個process output的project document update所列示的內容－其中最主要的就是Activity Attributes。

(三)Schedule與activity的區別
第三點可說是由前兩點推演而來，6.1到6.4均設在設法估量適當與合理的活動項目，以其每個activity之間的關係、資源與活動期間；而schedule則是以整個project的角度去思考，並有非常大的可能再進一步去調整每個activity。

而為了解答「為什麼6.3 Estimate activity resources不用Project Scope Statement」肥蝦認為可從二個立基點─Project Scope Statement、Time Management Processes─去串連思考。
(一)首先瞭解Project Scope Statement的由來與目的。
Project Scope Statement是5.2的產出, 參考了project charter跟requirements documentation跟Organizational Process Assets後的產出。

Project Scope Statement主要包含的內容項目有：
1. Product scope description
2. Product acceptance criteria
3. Project deliverables
4. Project exclusions
5. Project constraints
6. Project assumptions

因此我們可以看到Project Scope Statement是把要Business的Product轉換為Project重要過程文件！對於專案範圍中什麼要交付，什麼不作，專案的前提與限制，均有了較明確的說明！

(二) Time Planning Processes的目的。
6.1 define activities: The process of identifying the specific actions to be performed to produce the project deliverables.

6.2 sequence activities: The process of identifying and documenting relationships among the project activities.

6.3 estimate activity resources: The process of estimating the type and quantities of material, people, equipment, or supplies required to perform each activity.

6.4 estimate activity durations: The process of approximating the number of work periods needed to complete individual activities with estimated resources.

6.5 develop schedule: The process of analyzing activity sequences, durations, resources requirements, and schedule constraints to create the project schedule.

(三)串連的思考
6.1 define activities:因為activity是從work package再分解，所以必需參考scope baseline。而是scope baseline包含Project Scope Statement、WBS、WBS Dictionary，因此6.1 define activities也要使用Project Scope Statement。

6.2 sequence activities: 接著必須針對每個活動的特性與一些限制，來安排其間的順序。此處參考PSS是怕發生見樹不見林的問題，所以只要Project Scope Statement，而WBS跟WBSD可以視為轉化融入到Activity List跟Activity Attributes了。

6.3 estimate activity resources:是要估計每個Activity所需要的人、物、料、設備的種類與數量，重點是放在每個Activity，而著眼點是組織對資源提供的限制，所以對整體專案的範圍、限制、前提，已不是重點。另外，請注意6.2有一個output：Project Document Updates，它可會視情況需要更新了Activity List跟Activity Attributes，還有Risk register。

6.4 estimate activity durations:是要估計每個活動所需要的活動期間，此處為何還要參考Project Scope Statement?
因為6.3僅是估計每個活動所需要人、物料、設備的種類與質量，那每個活動要作多久呢？如果資源沒有問題，當然就直接估計出工時；但是Project Scope是要完成所交付專案產出的所有活動，比如一個Work Package會有那些活動必須在那時完成的限制，那些活動必須配合管理活動期間(如每週、月的報告)...這些活動的期間估計就必須參考由Project Character與Requirements Documentation而來的Project Scope Statement。
其實妳可以把它單純的想成有些活動的期間必須配合合約、 買方的要求等限制！比如：買方可能會要求會議的前兩天，必須傳送會議的agenda，那這些準備會議準備活動的期間就會受到限制！
此外，不要把6.3到6.4是one way的喔！每個活動之間會有互動的。如果6.4activity的duration無法滿足Project Scope Statement的要求，也可以回頭經由增加這個activity的resource.來減少activity的duration。

6.5 develop schedule:因為要訂出專案的時程，那當然Project Scope Statement所記錄的時程限制等資料就是非常重要的。

因此在6.1到6.5的Time Planning的過程中，除了6.3在估計每個活動所需要的資源外，其餘都是要參考Project Scope Statement的。而6.3的目的是根據Activity List跟Activity Attributes去對應組織的資源狀況(Resource Calendars、Enterprise Environment Factors、Organizational Process Assets)。

在PMBOK IV的Project Time Management中有一個肥蝦認為PMBOK IV與III最大的差別在於圖6-2所列舉的scheduling method，scheduling tool，scheduling model。在PMBOK IV對於scheduling method與scheduling model並沒有清楚的交代－僅有提到scheduling methodology－而scheduling tool在6.5.2.8與6.6.2.8的說明是一個自動的排程工具，根據時程的資料進一步產生活動的起迄日期。但如果我們回頭參考PMBOK III對scheduling model的說明，第四版可說利用此圖把schedule model作了更清楚的描述，所謂的scheduling model可說是包含特定的時程方法論、排程工具，以及專案中有關時程的訊息而成。但是圖中的e.g. CPM的說明圖形應該是說明scheduling method而不是scheduling tool。

以和為貴的整體問題解決法-「問題不能拆開來看」讀後感想

本書是日本TOC(Theory of Constraints)理論大師－岸良裕司－所撰寫的TOC(Theory of Constraints)的思考流程(Think Process)，以「整體最適」的觀點，尋求雙贏的最佳解決問題的方法，時報文化於2009年出版。
本書立基於限制理論TOC(Theory of Constraints)的基本理念：「人類天性是善良的；事物本質是簡單的。」；而「人」是糾結問題(繫鈴)與解決問題(解鈴)關鍵；而解決之道在於突破錯誤的假設，建立有邏輯性的正確假設，進而利用正確的假設形成正面的企業文化。最終的希望在於希望讀者不要以局部最適的解決問題方法，導致無盡衍生的問題；而是要以整體最適的思考去達成雙贏的結果。
本書提供了五個工具樹圖、兩個圖形及一個地圖，提供予下列解決問題的步驟：(1)如何去改變：擬聚共識；(2)要改變什麼：界定核心問題、化解衝突；(3)改變成什麼：確認目標、防範可能風險；(4)如何造成改變：建立中繼目標，確立執行順序。
以下分別說明其間的關係：

(1)如何去改變？
=>策略與戰術樹(S&T-Strategy & Tactics Tree)：運用整體最適方法，集結眾人之力的策略戰術執行法。

(2)要改變什麼？
=>撥雲見日圖/衝突圖(Clouds)：讓彼此形成共識的對立消除法。
=>現狀樹(CRT-Current Reality Tree)：找出問題關聯性的現況掌握法。

(3)改變成什麼！
=>未來樹(FRT-Future Reality Tree)：改變現況創造未來的未來構思法。
=>負面分枝(NBr-Negative Branch Reservations)：預測「不良效應」盡早防範。

(4)如何造成改變。
=>條件樹(PRT-Prerequisite Tree)：專注於中繼目標的目標達成法。
=>轉換樹(TrT-Transition Tree)：鍛鍊洞燭機先能力的執行順序確立法。

此外，書中強調了解決問題之道：「尊他、重己、時宜、妙策」的重要思維：
(i)尊他－自己設法滿足對方的要求。
以「體諒」為基礎的作法，察覺他內心的真正需求，並予以尊重。

(ii)重己－檢視自己的需求是否符合對方的行動。
以「給對方面子」為基礎的作法，希望自己的需求，能符合對方行動。

(iii)時宜－按時間與場合，分別採用雙方作法。
透過確立時間與場合，或許就是發現對立其實不存在的契機。

(iv)妙策－去尋求「改變」與「不變」之外的第三妙策。
跳脫對立點，從並立點，回頭思考解決問題的方法。

在順序上，肥蝦以為最佳的應用方式為：
(1)以策略與戰術樹建立與分享共同的願景與目標。

(2)以現況樹，區別不良症狀(病症)與真正的問題(病因)，找出核心問題。

(3)以撥雲見日圖，化解彼此的對立與衝突，達成共識。

(4)以未來樹圖，呈現達成策略與戰術圖的願景與目標的美好景象群。

(5)利用負面分枝思考每一個美好景象可能造成的負面效果，以期防範於未然。

(6)使用條件樹，建立達成終極目標的中繼目標，構思達成目標的完整路徑圖。

(7)轉而以轉換樹，思考達成中繼目標的明確作業程序。

其中，現況樹、未來樹、條件樹、轉換樹，四者均應與策略與戰術樹緊密的連結，隨時以零基思考的模式，思考終極目標的正當性與需求性。此外，負面分枝所擬定的預防目標應納入條件樹的中繼目標。
整體架夠構就如書後封面所繪製的TOC解決問題森林地圖。

此外，本書均環繞在「人」的中心上。「人為城牆，人為城堡」，所有目標的達成，問題的解決，均有賴有共識的人們一起努力克服。因此書中所引的山本五十六的名言：「不做給對方看、不說給對方聽、不讓對方嘗試、不誇獎對方、人則不為所動。」實可做為本書結尾的最佳註腳。惟有不強加自己的主觀意識於他人身上，尊重他人的立場與需求，時時謹記以「好處兩點，好還要更好處一點。」想著別人與自己的優點，方能建構一個以和為貴的正面企業與專案組織的氛圍。

串連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的核心精神與應用!

會寫程式就是會做專案嗎？

肥蝦之前和最近都遇到一些朋友，他們對於不具有程式能力的專案經理會有一定的排斥。在軟體開發業界，程式撰寫能力被一直認為是專案成功的必備條件。目前也由於很多公司主導專案的專案經理都是從以往的技術人員出身，因此也反相的認為程式撰寫能力是專案成功的惟一條件。

在如此交互作用下，導致目前市場上很多以技術專業自居的專業人士，在專案團隊內會有意無意地輕視"專業"專案經理，導致專案經理的主要職責之一：「創造與維護專案團隊的正面氛圍」非常不易作到。

在PMI網站上的有下列一道考題：
To be a good project manager, how much do you have to know about the industry or business that you are serving?
A. It is more important to have a good project management foundation than to know the business.
B. Each business is so different, in-depth knowledge in the field is key to a successful project.
C. Organizational politics drive project success, so focus on your ability to sway management.
D. Project success is random, so all you can do is work with the skill sets you have.

PMI網站，Barbee Davis, MA, PHR, PMP,所公布的答案是A。各位讀者可上去看伊的說明(網址：http://www.pmi.org/eNews/Post/2008_09-12/QQ_ToBeGoodPM_HowMuchToKnowAboutBusinessYourServing.html) ，Barbee Davis從大中小型專案來分析為何專案經理的專案管理知識、技能與能力，比商業的瞭解、認知重要。

就考試的立場而言，肥蝦認可Barbee Davis的解說，以PMI立場，專案管理能力一定是比產業專業知識更為重要！但肥蝦在此，想從另一角度去說明專案成功的要件中，專案經理的職能與角色中所謂的管理能力，是不是僅瞭解如何去管理專案比較重要？

因為此篇不是為考題解析，準備考試的朋友還是不要看肥蝦以下的推論比較好！

何為專案經理所需要的知識領域，在PMBOK IV版中，已經第III版中圖1.2-Areas of expertise needed by the project team拿掉，針對專案經理的角色寫在1.6 role of a project manager。針對專案經理的角色，PMBOK說明好的專案經理應具有下列特性：
(1)知識(Knowledge)：針對專案管理的知識。
(2)技能(Performance)：有效的運用專案管理知識。
(3)個人特質(Personal)：態度、性格與領導力。

肥蝦個人是以為如此的修正，是PMI為了行銷目的，強調專案管理知識與技能的重要性。一個專案團隊應具有PMBOK III版所載明的五種專家領域知識─應用領域的知識、瞭解專案所在的環境因素、一般的管理知識與技能、個人的特質與技能，以及專案管理的知識。因此專案經理必須能有效的與專案團隊與客戶進行溝通，設法營造整體環境的正面氛圍，以提升專案的成功機率。

在前述的要求與架構下，專案經理的第一要務是什麼？肥蝦個人是以為要先設法取得信任－來自公司內部的信任、來自客戶的信任、來自專案團隊的信任。基於肥蝦的認知，對於專案管理知識與其它應用領域知識作了如下的解釋：
(1)專案管理是一個基本面的know-how，就算不是專案經理，專案團隊成員也應該要有基本專案管理的知識，才能解讀專案工作的本質，瞭解專案團隊成員的互動必要，如此才能促進團隊的有效運作。

(2)那專案經理要強化的那些專案管理能力，才能顯出他適合當一個專案經理！因為每一個專案都是獨一無二的，且有一定的時限。所以專案經理的專案管理能力如果依據堅強(兼具廣度與深度)的應用領域專業知識，以及應有的一般管理知識，那可能無法有效的去整合(Integrate)專案團隊成員、客戶與公司的需求。

(3)專案管理能力跟一般的企業管理能力差異在那裏？
試想：「一個資訊公司行銷部門的經理，進入房地產公司擔任行銷經理比較容易？還是一個從資訊專案的專案經理，進入房地產專案的專案經理容易？」
肥蝦先前曾撰寫【MBA乎？PMP乎？-兩種管理"專業人材"之我見】乙文，說明兩者之間並不違背，而且是相輔相成，並且是糾葛難分的！

(4)PMI的想法！
PMI是試圖把專案經理知識抽離出來向企業管理一樣。就像行銷學一般，不管你是資訊公司行銷部門的經理，,還是房地產公司擔任行銷經理，大家的基礎學術訓練，都是都唸行銷學。
但是因為專案的本質，導致很多專案管理的應用都要立基於對專案的領域知識有一定深度的瞭解，才能進一步發揮我們所學到的專案管理知識，強化PMBOK IV版中所說的技能(Performance)。

(5)「領域專家不一定適合當專案經理，可能比較適合當顧問。」
肥蝦可以同樣把這句話反過來說：「一個專案管理的專家不一定適合當專案經理，可能比較適合當顧問。」因為一個專案經理重要的是營造完成專案的正面氛圍，引入專案所必要的專家，並與伊溝通，作為溝通的中心介面。就如同在PMBOK IV版第26頁，對專案經理的說明：「The project manager is the lead person responsible for communicating all stakeholders. The project manager occupies the center of the interactions between stakeholders and the project itself.」

基於上述肥蝦淺薄的認知，肥蝦將原有第III版中圖1.2-Areas of expertise needed by the project team的圖形，修改為如上圖的專案經理知識架構。

RISKOLOGY-"與熊共舞"所提供的風險評估工具

肥蝦近日於專案管理交流論壇(http://bbs.pm-i-study.net/)寫了一系列"與熊共舞"的導讀！
再看過該書提供的風險評估工具(Riskology)，雖然只是一個用EXCEL寫的工具，但已包含了一些風險評估的要點，加以該工具是作者免費提供給讀者大眾，因此肥蝦特把下載網址與個人的觀感整理如下，以供大家一起分享！

下載網址：http://www.systemsguild.com/riskology
版本名稱:RiskologyV4.xls
使用說明:RiskologyManual.pdf

使用簡要說明:
使用者需要輸入專案名稱、預估起迄日期、風險名稱、對應每個風險的三點估計值，每個風險導致專案取銷的百分比值。RISKOLOGY將協助您計算最小與最大完成期間概估。

工具背後理論:
基於三點估計法(three-points estimate)與利用隨機變數(random)，隨機取樣五百次(取樣值介於三點估計的最佳與最壞之間)，以蒙地卡羅(MONTE CARLO)模擬風險的概估值。

肥蝦建議:
(1)目前該工具僅能提供十個RISK FACTOR的輸入。可客製化加入新風險因子。
(2)奈米機率日必須先行輸入。使用者可再工具算出最小與最大期間之後，再行參考修正奈米機率日！

遇到更正時程問題時，專案經理的優先選項是?

When correcting a scheduling problem, what is the FIRST technique a project manager should consider?
A. Crashing.
B. Reducing project scope.
C. Fast-tracking.
D. Out-sourcing.

肥蝦就個人對PMBOK的瞭解解析該題答案；並分享個人的經驗，關於專案經理在發現時程問題的考量與對應作法。

(一)PMP考題解析
各位可以注意本題的關鍵詞：「correcting a scheduling problem」。在第六章的六個processes，那一個process有"Recommended Corrective Actions"？各位可以發現是在6.6 Control Schedule，那時project management plan已經產生，其中的cost baseline都已經放入project management plan了。

因此，如果cost reserve不夠，那要怎麼辦？因為向公司要人、要錢，如果超過cost baseline都是要Change Request；而針對專案經理所掌控的contingency reserve是針對know-unknown；如果這個問題是unknown-unknown，那就要動到management reserve，那就要sponsor的approved。

而Project Schedule Network Diagrams不是schedule baseline喔！並未納入project management plan中。所以應該思考調整fast-tracking中的選擇性依賴關係的順序，設法變更其中的leads 跟lags的安排，還有請記住Schedule Compression是6.5Develop Schedule的Tool and Technique；Adjusting Leads and Lags可是6.6 Control Schedule的Tool and Technique喔！

(二)實務經驗分享
在實務上，肥蝦碰到的專案中，很多的管理高層在碰到時程的問題時，很多人是喜歡優先採用crashing，但個人以為這是受到"人多好辦事"這古老諺語的影響！可是相對地，很少人去考慮到為什麼會造成延誤(提前)的原因！

一般專案經理最普遍的作法，就是回去跟公司要人、要錢！

我以為，這一方面是專案經理給自己一個藉口：「這是資源不夠，而不是專案當初規劃有問題，或是專案經理管理上有些不當的地方。」另一方面，當專案經理向公司要資源之時，就把專案的問題，上綱到公司人力資源管理政策的問題！把問題推給公司，然後變相的給自己增加緩衝的時間。

肥蝦認為每個專案經理處理的方式會跟，會因為外在的限制、sponsor的壓力與利害關係人的要求而變化！也會跟時程問題發生的時點在專案作業的時點有很大的關係！

以肥蝦個人參與專案的淺薄經驗與認知，肥蝦在解決更正時程問題時，會進行以下的程序：

(1)釐清原因：為什麼？造成問題背後的原因是什麼？與當初所設想的差在哪裡？
=>事前的規劃與現在的狀況之間到底出了什麼狀況？到底是有什麼沒想到？或是想到了而沒去注意？背後造成的原因在哪裡？真正的關鍵點是什麼？

(2)設法集中問題的焦點，縮小問題的範圍！
=>基本上， crashing如果不是用專案已有的reserve，你會發現你將落入公司內部競爭的難題！如果你很紅，有時候你會發現跟公司要錢比要人可能簡單一些！如果公司是要給你現有公司的員工，有時候要到的人很多都是別的團隊不要的！如果是招募新人，很多公司的政策跟管理，會需要一定的時間，新進的人如何融入團隊，多久融入，這些都是問題的範圍！

(3)考量對問題解決方案外在跟內在的限制！
=>比如合約的限制，專案團隊成員是否已經呈報買方，而且變更需要申請跟審核；合約的金額是否允許你增加成本；專案現有的文件跟作法，是否足以訓練一個新手儘速的融入團隊；團隊是否存在強烈的排外性。

另外，針對同一個更正時程的問題，肥蝦會考慮更正的時間點：
(1)時間點：合約簽定前
=>完工日期是買方強力要求的，那用crashing增加成本，或減少產品功能與性質(scope)或品質(quality)。

(2)時間點：規劃中
=>crashing跟fast-tracking，我會同時思考！尤其對於fast-tracking中的選擇性依賴關係儘量去調整，crashing所增加的成本則可納入cost-baseline。

(3)時間點：執行前期
=>我會先看看fast-tracking中的選擇性依賴關係！如果schedule reserve能cover，那不管它，但要強力監控！如果cost reserve充足，那我會考慮用crashing。而且在專案執行的前期，新人的加入，可以有一些緩衝與容忍度讓新人融入團隊！或者外包給別人，但自己的團隊要花費些心力在外包廠商跟專案範圍的接合處！

(4)時間點：執行後期
=>如果reserve都已經被用了差不多，而且團隊之間已有一定的默契跟向心力，那我會考慮fast-tracking先。因為rework的風險，跟加人把團隊搞雜的風險，我會比較擔心團隊垮掉的風險！

(5)時間點：快驗收的時候
=>考量工作的本質，如果只是文件撰寫等行政工作，或是黑箱測試可以比較獨立於原有團隊之外的工作，可以考慮crashing！那fast-tracking就比較不考量了，因為大概沒有什麼activity可以平行運作了！如果這些時程所包含的activity的delivery不太影響交付產品的主要功能，也在stakeholder的tolerance的邊界，那我會設法去嚕掉它，作變相的scope change。

以上是肥蝦個人小小的看法！以下，肥蝦將分享一個我個人的實例：

曾經有一個專案的部份活動在執行發生delay，經深究原因發現是兩個同事在工作的接合界面有衝突。因為前者工作的負責人，比較懶散與不負責任，因此導致後者activity的負責人必須花費很多精力跟時間，去檢核前者的delivery。後來跟後者打個商量，如果他去cover前者的工作，他是否能負荷？對他是否也比較方便？而後者的回答是正面的。因此前者被要求離開團隊，不但省錢、省人，省下的錢一部份，發給後者當獎金！結果，大家是皆大歡喜，且有效的縮短delay的時間呢！

因此如果把時程問題背後的原因找出來！你會發現：並不是增加資源就會有效喔！