時程壓縮的討論
一般專案管理的書籍中對於壓縮時程通常有著趕工(Crashing)與同步跟進(Fast-Tracking)兩種作法。在作業管理書本中，對於時程壓縮的考量，僅僅單純強調趕工的直接成本與間接成本間的比較，針對關鍵要徑上的工作項目，經由比較趕工所增加的加班成本與縮短專案期限的間接成本，而決定是否採取趕工的策略。但是因為資訊軟體專案，因為建構專案所需的資訊工具技術日新月異；專案需求所依賴的作業流程因應不同產業、不同公司而異；專案的品質除了操作上的可信度與有效度，對於近來日益重視的資訊安全與個人資料保護等議題更有著嚴謹的要求。【表 一】1994-2009年資訊科技專案結案狀態，為依據CHAOSReport 2009調查資訊專案的開發結果，專案在超時、或縮減範圍、或降低品質下，完成的比率，以及完全無法交付專案產出的比率合計高達七成。
【表 一】1994-2009年資訊科技專案結案狀態
| 狀態分類 | 1994 | 1996 | 1998 | 2000 | 2002 | 2004 | 2006 | 2009 |
| Successful | 16% | 27% | 26% | 28% | 34% | 29% | 35% | 32% |
| Challenged | 53% | 33% | 46% | 49% | 51% | 53% | 46% | 44% |
| Failed | 31% | 40% | 28% | 23% | 15% | 18% | 19% | 24% |
由於資訊專案的開發與建置，相較於一般其他類型的專案實有著一定的困難度與特殊性；而且實務上，在遇到需要縮短專案時程之時，趕工加班多為資訊專案的第一優先考量，因此我們認為趕工所要考量的因素，除了加班產生的直接成本之外，應該可能還存在著其他趕工成本的負項因子，以致於加班趕工為縮短專案的主要對策。
因此本文將從論述時程的用途、時程中的制約、時程壓縮考量，風險因子等面向，進一步思考趕工所可能影響專案的因素，並設法轉化為趕工考量成本的要項，並且探討在採行趕工策略之前應有的管理步驟，藉由瞭解軟體專案趕工對於專案整體的影響與衝擊，以為後續研究軟體專案是否採取趕工策略的參考。
時程為專案的三重制約(triple constraint)之一，傳統上，專案的時程多是將之單純的視為專案追蹤的標竿與工具。但是根據PMBOK Guide第四版的說明，時程表(Project Schedule)除了是監控時程的重要投入外；也是估計成本、決定預算，以及計劃採購的重要參考依據(input)。因此，時程可以說是整個專案的縮影，專案的所有要求與限制都將反應在時程表之上。在Scott Berku所著的”Making Things Happen”一書中，說明時程的三大用途：(1)對事情何時完成許下承諾。(2)鼓勵每個人將其付出視為整體的一部份，並盡力使其工作能和他人配合。(3)提供一個追蹤進度的工具，並把工作切分成可管控的小部份。
時程表的完工日期，背後是一個機率的概念。機率在實務上，是客觀跟主觀的混合產物！任何機率的分配都有很多的假設與限制，能提供一些客觀的分析；但如何確認自己所處專案的情況符合特定的假設與限制則就有很多主觀的因素在內。最重要的主觀因素就是"你相不相信"！對專案的利害關係人因為所處位置的不同常會有不同的認定與理解。一般人會為可能達成的目標努力奮鬥；但不會對絕不可能有機會成功的事情打拼，因此如何凝聚，以及延續大家的機率共識，是很重要的。
一個可以被專案利害關係人信任的時程表，就好像給了客戶與內、外相關的利害關係人，對未來一個承諾一樣。雖然最後定版的結案日期很多是來自專案團隊之外的要求。比如：合約上的日期(有些議價方式的合約，專案團隊會跟客戶進行協商，但最後還是由客戶決定)、法律的落日條款、行銷部門的要求、長官的決定…。但是專案的最原始假設：就是專案所交付的產出、服務或結果是一定存在的，也會如期在特定日期產生。依憑於此，專案贊助人(Sponsor)或客戶(Customer)才願意把資源投注在專案的身上。
以PMBOK Guide 2008的觀點來論，在6.5發展時程表之前在6.2排序活動項目下的專案時程網路圖(Project Schedule NetworkDiagrams)就會標明出每個活動的順序與依存關係，就是每個人工作的關聯性。這依存關係與專案時程中定義的完成日期，有著關係，但確沒有絕對的關係。因為就算專案延遲，這每個活動間的依存關係依然存在，除非一開始專案活動間的排序是不合理與盲目制定的。但這背後所發揮的對團隊成員的推進作用(forcing function)的心理活動－事情一旦發生，能自然而然的迫使觀點、心態或行為改變，就稱為推進作用。
專案主要有三種時程規劃的技術：工作分解(WBS)、要徑法(CPM)、計畫評核術(PERT)。但不論採用何種方式，最重要的就是要先找到該軟體執行過程中的關鍵路徑(Critical Path)－執行專案任務所需的要最長工作期間；完成專案最少所需時程的專案任務集合。
在物理博士與企管顧問高德拉特(Eliyahu M. Goldratt)先生所著的”Critical Chain”乙書中，將制約理論TOC(Theory ofConstraints)應用到專案管理之上。在限制下追求極大化，就類同於經濟學中建構個體經濟供給曲線(在既定成本下追求最大產出)，與需求曲線(在所得限制下追求最大效用)的基本出發點。高德拉特先生特別提醒讀者一個思考的主要關鍵點：「成本世界(Cost World)」與「有效產出世界(Throughput World)」的區別。
在個體經濟學的推導中，在（有效產出世界）「既定成本下追求最大產出」與（成本世界）「在既定產出下追求最小成本」兩者間是同義的；但在本書中強調「成本世界」的思維與「有效產出世界」是迥異的。因為專案獨特的特性，完全是「有效產出世界」的產物，因此從事專案的人士，必須不同於一般人所早已習慣的成本世界思維去管理專案。
那麼成本世界與有效產出的思維差異在那裏？「成本世界」的要點在於生產過程中每(任)一環節只要能有效節省成本百分之一；那整體專案也同時節省成本百分之一。「有效產出」的重點在於生產過程中最弱的環節增加產出百分之一；那整體專案才能增加產出百分之一。
針對一個追求有效產出的專案，要如何解除制約的束縛呢？”Critical Chain”陳述了五個步驟：確認制約(Identify the constraint)、有效剝削制約(Decide howto exploit the constraint)、其他一切遷就制約(Subordinate allother processes to above decision)、鬆綁制約(Elevate theconstraint)、回頭重新檢視(If the constraint has moved, returnto Step 1.)。其過程如下圖所示。
【圖一】”Critical Chain”解除制約五步驟
每一步驟的說明整理如【表 二】”Critical Chain”解除制約五步驟說明表。
【表 二】”Critical Chain”解除制約五步驟說明表
| 項次 | 步驟名稱 | 說明 |
| 一 | 確認制約 | (1)有形的實質限制，如：關鍵人力、資源、過程。 (2)無形的限制，如：錯誤的決策。 因此首要工作是找出最弱的一環，就是要【聚焦】。 |
| 二 | 有效剝削制約 | 設法創造制約的最大產出，如：設法增加有效的人力投入，有效安排最弱環結的生產順序與流程…。 |
| 三 | 其他一切遷就制約 | 在整個生產流程必須因應剝削後的制約進行改變，如：重新安排作業流程，設立特定的中繼點與監控點…。 |
| 四 | 鬆綁制約 | 此時原有的制約可能已不再是最弱的一環，因此可以解除對該制約的所要持續投入的關心與資源。 |
| 五 | 回頭重新檢視 | 再重新回到步驟一，重新檢視整個生產流程，再找出最弱的環結，進行步驟二到步驟五。 |
該書中並提到因應專案中每個項目工作之間對於步驟、程序與整體專案的依存關係，提出了四個專案緩衝的安排，以期能縮短時程，避免專案時間的浪費。
| 項次 | 緩衝類別 | 說明 |
| 一 | 接駁緩衝 | 針對步驟依存性。 |
| 二 | 資源緩衝 | 針對資源有限性。 |
| 三 | 瓶頸緩衝 | 針對必要程序限制性。 |
| 四 | 專案緩衝 | 針對整體專案性。 |
由於專案工作項目之間有個關聯與依存的關係，對於外來限制與法令要求也有無法切確掌控的因素，工作項目間的資源分享與利用有數量與時間的限制，因此藉由緩衝的安排，可以提升專案的有效達成率，但也不免的可能增延專案的時程與成本。
在林信惠、黃明祥與王文良三位先生合著的”軟體專案管理”一書將提到，軟體專案時程壓縮的八個方法，以及一些需要考量，比如工作項目依存的合理性，成本的成效等因素。
其中八個方法整理如下表：
| 項次 | 方法 | 說明 |
| 一 | 提高結構化與標準化的程度。 | 藉由作業標準化，縮短工作學習的時間。 |
| 二 | 提高員工努力程度與人員生產力。 | 經由團隊生產力的提升縮短作業的時間。 |
| 三 | 工作減量。 | 直接縮減專案的範圍。 |
| 四 | 增加可用人力資源。 | 增加專案團隊人員。 |
| 五 | 加強專案人力調配與技術選擇的最佳化。 | 重新調試團隊成員的工作項目。 |
| 六 | 修改專案結構與目標。 | 變更專案，縮短專案所要負擔的工作。 |
| 七 | 增加專案整體開發時間。 | 延長專案完工的期限。 |
| 八 | 激勵。 | 提升專案團隊的士氣。 |
在”軟體專案管理”中一再強調：「從方法、技術與工具來做改善, 會比增加人員或時間來得好。」並且認為時程壓縮應要考量：(1)壓縮的工作應有助於縮短整體的工期。(2)壓縮後不會影響合理的先後關係。(3)合理的成本效益。書中並且提到可以利用【Time-sensitive Cost Model】，說明專案時程與成本間的關聯，經由COCOMO模式(Barry Boehm)、軟體生命週期模式(Putnam)、 Price S(RCA)、Air Force(Boehm)四模式，可推衍出時程與成本間有一個最佳的trade-off點。當時程的壓縮低過此trade-off點之後，時程的壓縮將導致高昂的成本。
書中所列示的增加可用人力資源，除了增加團隊成員之外，也應該考率慮設法增長原有團隊成員的工作時間。直接增加團隊成員，也將同步增加團隊間溝通的成本與困難度，因此增加團隊成員，除了人事成本的考量外，應該還要再加上專案溝通上的成本，以及新成員進入專案的訓練成本與學習時間。
在PMBOK第四版對於專案管理的說明中，針對專案工作可能遭遇的錯誤或失敗，在除了終止專案的可能性外，提出了重工(Rework)、重新規劃(Replan)、或者重新開始(Restart)的可能狀況。針對特定一個專案工作項目而言，趕工的最大風險結果，就是重新進行此工作，原先該項目所施作的成本均成為沉沒成本(sunk cost)進，再也無法經過工作的修正，而減少已發生的成本。
【圖二】PMBOK專案管理架構圖
對於工作項目的風險衡量，可以利用計畫評核術(PERT)中的最樂觀時間(Optimistic time)、最悲觀時間(Pessimistic time)，以及最可能時間(Most likely time)，三者數字間的分配狀況得知預估的風險狀態。由於一般統計學中均常假設機率的分配為常態分配，但是此處，對於工作項目風險的分配狀態建議應以假設最可能時間為分配中的眾數，以其距離最樂觀與最悲觀的時間數值間的距離，設定該工作風險的分配型態為常態分配或是Beta分配。此外，也應注意的是一般專案成員在估計最悲觀的時間之時，是否忽略了最嚴重問題所要花費時間的可能性！因此，在進行計畫評核術(PERT)，也應該要加註三個情況中的機率估計，每一工作項目的風險分配圖就可如下圖所顯示的狀態，去進一步初略估計所應考量的分配型態。
【圖三】工作項目時間機率分配
上圖中所呈現的最嚴重問題所要花費的時間，可以改以”有可能需要重做幾次的觀點”來衡量！因為工作項目的錯誤，如果假設與其他的工作項目間存在著獨立的關係，則就是重工的可能性，因此可用重工的觀點來衡量此分配最右邊的端點。
立基於以上從時程的用途，時程上可能的制約條件，時程壓縮的考量因素，以及工作項目重工可能的風險等面向，我們可以將書本中關於特定工作項目進行趕工，即原有團隊成員在加班的情況下所可能發生的成本要項，除了原有的直接加班成本之外，可以再行增加以下的因素：
| 項次 | 成本因子 | 代號 | 假設 |
| 一 | 直接加班成本。 | Direct Cost | 加班的薪資與誤餐費用。 |
| 二 | 工作項目內容的標準化程度。 | Standardized Level | 標準化程度愈高，加工的效果愈大。 |
| 三 | 與其他工作項目的依存度。 | Active Dependency | 工作項目依存度愈高，趕工的效果有外溢的效果愈高。 |
| 四 | 工作項目的風險分配狀態。 | Risk Concentration | 工作項目的風險愈集中，趕工所可能產生的失敗損失愈小。 |
除加班成本之外，工作項目內容的標準化程度因子所能表示的加工效果；項目之間的依存度所可能產生的外溢效果；風險分配狀態愈集中表示趕工失敗的成本愈小，這三項也應必須經由統計檢定來進一步檢測。
如果在假設以上的條件均成立之下，趕工的成本或可設成下列的數學等式：
Cost of Crash =Direct Cost + (Standardized Level × Weight Factor I) + (Active Dependency × Weight Factor II) + (Risk Concentration × Weight Factor III)
其中，Direct Cost與Cost ofCrash為正比關係；其餘的Standardized Level、Active Dependency、Risk Concentration均與Cost of Crash呈反向關係，Weight Factor I 、II、III為代表StandardizedLevel、Active Dependency與RiskConcentration三要素轉換為價格衡量的轉換權重因子。
對於如何選擇那些工作項目進行趕工的處理，除了成本考量之外，在管理層面上，也需要作適當的考量。為每個專案經理在選擇趕工處理的工作項目，因該因應外在的限制、專案贊助人(sponsor)的壓力與利害關係人的要求，以及工作項目作業的時點在整體專案作業的時間點。因此選擇趕工處理的工作項目前應考量下表的關鍵因素：
【表 三】趕工處理考量管理因素表
| 項次 | 步驟 | 說明 |
| 一 | 釐清原因 | 事前的規劃與現在的狀況之間到底出了什麼狀況？到底是有什麼沒想到？或是想到了而沒去注意？背後造成的原因在哪裡？真正的關鍵點是什麼？ |
| 二 | 集中問題的焦點，縮小問題的範圍 | crashing如果不是用專案已有的reserve，你會發現你將落入公司內部競爭的難題！如果你很紅，有時候你會發現跟公司要錢比要人可能簡單一些！如果公司是要給你現有公司的員工，有時候要到的人很多都是別的團隊不要的！如果是招募新人，很多公司的政策跟管理，會需要一定的時間，新進的人如何融入團隊，多久融入，這些都是問題的範圍！ |
| 三 | 考量對問題解決方案外在跟內在的限制 | 比如合約的限制，專案團隊成員是否已經呈報買方，而且變更需要申請跟審核；合約的金額是否允許你增加成本；專案現有的文件跟作法，是否足以訓練一個新手儘速的融入團隊；團隊是否存在強烈的排外性。 |
另外，針對專案的的時間點，趕工的策略實行也應該要有不同的考量。
【表 四】趕工策略在專案時點的考量表
| 項次 | 時點 | 考量說明 |
| 一 | 合約簽定前 | 完工日期是買方強力要求的，那用crashing增加成本，或減少產品功能與性質(scope)或品質(quality)。 |
| 二 | 規劃中 | 趕工跟同步跟進，應該同時思考！尤其對於同步跟進中的選擇性依賴關係儘量去調整，趕工所增加的成本則可納入成本基準。 |
| 三 | 執行前期 | 先行檢驗同步跟進中的選擇性依賴關係！如果時程預備能承受，那不管它，但要強力監控！如果成本預備充足，那應該會考慮用趕工。而且在專案執行的前期，新人的加入，可以有一些緩衝與容忍度讓新人融入團隊！或者外包給別人，但專案團隊要花費些心力在外包廠商跟專案範圍的接合處！ |
| 四 | 執行後期 | 如果預備金都已經被用了差不多，而且團隊之間已有一定的默契跟向心力，那優先考慮同步跟進先。因為重工的風險將非常高。 |
| 五 | 快驗收的時候 | 如果只是文件撰寫等行政工作，或是黑箱測試可以比較獨立於原有團隊之外的工作，可以考慮趕工。 |
以上兩表，主要的目的在說明，趕工的加班策略，除了成本的考量之外，也應該要進一步擴展到對專案的整體考量，經由專案管理因素，以及專案的進行時點，考慮趕工加班的負面與正面效果。
由於作業管理書中對於專案的時程壓縮特別說明了加班趕工的方式，並且特別標示了是否採行趕工加班的策略端在於比較加班所導致的成本，以及縮短整體專案時程所減少的間接成本。由於實務上，趕工加班為資訊專案在選擇縮短專案時程之時的第一優先考量，因此本文以為加班趕工除了比較書本中所載明的兩種成本之外，應該還隱含著其他的因素，以使得趕工加班為一般資訊專案壓縮時程作業的首要選項。
在逐一探索時程的用途、制約要項、壓縮考量因素、風險因子之後，本文提出了另外三個影響加班成本的因素─工作項目內容的標準化程度、與其他工作項目的依存度、工作項目的風險分配狀態；並且假設該等因素與趕工成本間的預設互動方向。此外，進一步探討專案執行的時點，以及管理的方式，並假設趕工成本與效果可能與其之間存在著不同乘數因子。
本文相關的說明僅是經由整理相關專案管理專著或者文獻中對於時程管理的陳述，所得出的假設，還待進一步的統計檢定，並非為確定的答案，所以本文僅是強調專案時程中的加班趕工的探討應不能僅用加班的直接成本，而應該思考更多的面向，提出更廣懋的思考假設，以為後續研究加班趕工策略的基礎。
文章定位：
