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的時間呢！

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