下面是一個常見的專案規劃，專案的負責人把所有工作用Excel列出，並定出他覺得可行的開始與完成時間。

 
(表一，某專案的作業清單)

假設今天的日期是九月十日。 透過上圖可以看出，在紅線上面(也就是九月十日之前)有四個作業的開始日期或結束日期跟預計的時間有所出入。 因此，在這組織裡頭的高階管理人員可能會要求專案經理針對這些作業的延遲做出報告，給與每個延遲的理由。

在傳統上這是很常見的要求，這是因為一般人總以為所有延遲都必須要有個理由，而關注這些理由就是在管理專案。 但實際上並不是這麼一回事，延遲的理由都是過去了的東西，在專案進行中檢討雖然有助於讓我們了解到底犯了甚麼錯，但這畢竟都是過去了。 只把眼光放在這個地方，並沒辦法讓我們後面更順利，反而常常忘記了我們應該關注的其實該是前面。 這就像在高速行駛時，我們撞到了甚麼東西，結果我們只把目光放在後照鏡上，想努力看到到底撞的是甚麼，而沒想到其實先專注於前方恐怕更重要。 除非你能徹底停下來檢討，不然又要看後面又要高速前進下，前方一定還會撞到新東西，這樣問題將永遠也看不完！

而讓這問題變得更糟糕的，往往是高階管理人員在看到這麼多延遲時，會要求專案經理多派駐人力在作業C以及E中。

問題會變糟糕的理由我們在之前的文章提過，後期的增加人力往往沒辦法立刻讓這些人力的效率出現在專案中。 他們需要熟悉時間、需要與既有人員培養默契、加上既有的延遲通常源自於工作中發生的狀況，既有的人可能都還不知道況狀在哪，新加入的人要找出來狀況且解決所花的時間肯定要更久。 所以臨時干涉並加人可能讓問題更嚴重。

還有一個讓問題變糟糕的原因在於，真正關鍵影響專案完成時間的，其實可能不是所有作業，而僅是幾個作業。 舉例來說，若我們考量在了這個專案中作業的施作順序然後透過軟體排程計算上面那專案後，我們可能得出如下的結果 :

 
(透過排程軟體做的專案規劃)

完成此規劃後我們可以發現，工作A、D、H、以及J呈現紅色，這我們稱之為要徑(Critical path)。 所謂要徑，指的是專案中最長的那條連續作業路徑，或是「專案最短可完成的時間」；換句話說，專案最後的完成時間為何將取決於這條路徑上作業的狀態。 若各位注意上圖紅色的作業桿應可以注意到，因為這些作業相互連結且又有較長的工時，任何這幾個作業有延遲，整個專案的完成時間即會向後拖延。 所以「要徑作業」就是這整個專案中，真正決定專案完成時間的一群作業；也因此，是我們必須仔細關注的工作。

而反過來，綠色的作業桿，他們若稍微延遲一點時間，將不至於造成專案完成時間被影響。 所以我們稱呼這些作業為非要徑作業。 而可以延遲的時間量，我們通常稱為浮時(Float)。 因此我們發現，有些作業對專案的完成時間有重大影響(在要徑上)，而有些的影響性相對很小(非要徑)。 所以通常我們在專案執行階段，應該把所有心力放在這些要徑作業上。所有資源的調度，也都應該根據要徑的狀態來做調整。

那如何往前看，而不要只看著照後鏡呢？

這其實也是我們花時間透過軟體排程(如Oracle P6或MS Project這類軟體)的最主要目的。 因為透過要徑法(Critical Path Method)的計算，過去的延遲與變動，將會反應在接下來的「可能變異」上，讓我可以了解哪裡是接下來最需要被關注之處；而這最需要被關注之處可能並不如我們原來想像。因此，讓我們回頭來看一開始提到的那個範例。

若同樣假設今天是第10天，把上表的資料透過軟體排程之後會顯示如下圖

我們可以發現，目前疑似延遲的作業C以及E其實都不在要徑上！

從上圖我們甚至發現，因為要徑作業D的進度早於預期，這專案反而有可能提早完成。 這些非要徑上作業雖然有些延遲，但對目前專案完成時間還沒有影響。 由此來看，此專案經理的執行方式其實並不需要調整。 追加資源去追趕作業C以及E對於整個專案的執行其實並無立即及顯著的幫助。 若我們抽走擺在要徑的資源去追趕這些非要徑，或因為增加資源造成溝通增加而降低產值，很可能反而造成要徑作業的延遲，最後將得不償失。 因此，專注於要徑的管理才是真正對於我們專案掌握最有幫助的工具與方式！

延伸活動

我們的排程訓練基礎班106動態排程基礎