遇到更正时程问题时，专案经理的优先选项是?

因此如果把时程问题背后的原因找出来！你会发现：并不是增加资源就会有效喔！
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的时间呢！

因此如果把时程问题背后的原因找出来！你会发现：并不是增加资源就会有效喔！