要改變成甚麼 (Part 2) ─TOC單一專案規劃方法

好的專案規劃是執行順暢的良好基礎,因此今天要來向大家介紹TOC的單一專案規劃方法─關鍵鏈排程法。

TOC關鍵鏈專案管理(Critical Chain Project Management, CCPM)在進行單一專案規劃時,有一個基本功必須先完成,那便是「完整的專案網路圖」。這裡指的完整,包括定義出合適的任務、為“所有”任務建立起前後關聯性、預估任務時間,以及為“所有”任務分派適當資源。如下圖:

基礎專案網路圖

看起來很合理,對吧?不過現實中大部分專案經理還是習慣以Gantt Chart做規劃,也就是任務之間並無前後關聯性或任務未指派資源;即便用的是專業的專案軟體,也不盡然將這些屬性設定完全。但這個完整的專案網路圖將是關鍵鏈排程的基礎,所以特別在這裡強調。

CCPM和一般專案規劃的邏輯有幾個不同的地方,包括任務的開工時機、任務的估算期程、以及最長路徑的決定。

據我所知,目前很多組織的管理習慣是認為「任務提早開始做,專案就能提早完工」,因此把計劃裡可以開工的任務一起啟動並分派給資源,雖然理論上要徑的任務優先次序會高於非要徑,但對於資源本身來說,手頭上同時拿到不一樣的工作,腦袋不免會針對個別任務的規格思考一番,在回報任務時也得都給點進度,再加上很多專案經理規劃完了以後並沒有優序管理的準則,容易在執行階段形成不良多工的狀況,造成任務優序混淆,以及任務間切換工作而延誤專案。在這樣的管理模式下,常造成很多任務同時開工而引起不必要的產能高峰,為了避免同樣的問題,CCPM是以Backward scheduling的方式安排專案網路圖,因此這個基礎網路圖應該這樣調整:

Backward scheduling

從最後面的H任務開始往前規劃,讓任務不間斷地接續著,以這樣的方式找到任務應該開始的必要時間。上圖我們可以看到原來的規劃面臨了資源衝突,若未在此時化解,執行階段將使藍色資源同時接到A和D任務,黃色資源將有一段時間同時負責J、B、G任務。之前和各位談過不良多工是造成任務及專案延誤的主因之一,因此一旦發現資源衝突,便要先做衝突的化解:

化解資源衝突

再來,便是調整任務的估算時間。為了讓大家了解一旦安全時間放在各別任務裡很容易引發的負面影響,我花了不少篇幅說明太多的安全時間會引發資源行為(學生症候狀、提早完工不報告),而資源行為又會反過來造成任務安全時間的浪費。因此,CCPM基礎專案網路圖裡的任務時間,必須以資源不受干擾而專注完成的基礎來估算。

任務期程以專注時間來估算

估算時間那篇文章裡已向大家說明過,由於大部分的人估任務期程會以90~95%的把握度來確保任務可以準時,所以CCPM將安全時間從任務裡取出後,會保留一半的任務時間。先別緊張,這樣做並不是要忽略現實,該給的安全時間還是會給,只不過為了讓安全時間發揮保護作用,放置的位置不同罷了。這部分晚點會加以說明。

定義好完整的專案網路圖之後,接下來就以TOC改善程序的聚焦步驟來進行排程。首先,先定義出系統的限制(Identify the system’s constraints)。

通常在單一專案網路圖的規劃過程中,造成專案週期無法進一步縮短的最長路徑,就是單一專案的限制。CCPM認為專案的最長路徑必須同時考量任務相依性以及資源相依性,也就是除了要把任務的前後順序考量進來,還必須考慮資源執行前置任務後是否立即做其他後續任務。尋找關鍵鏈時一樣是從最早的開工任務當起點:

決定關鍵鍊

D為最早的任務,所以以其做為起始點。由於藍色資源執行完D之後,立即接手做A任務,代表藍色資源執行D任務若有延遲,受到衝擊的除了後續的E任務外,需要藍色資源執行的A任務也會受到影響,因此在規劃時必須把資源衝擊納入考量。由於D和E任務之間尚有空檔,D-A的資源相依性較為立即,故把A納入關鍵鏈。決定後面的路徑時,藍色資源已經沒有負責其他緊接著的任務,所以只需要考慮任務相依性,關鍵鏈為D-A-B。接著,執行B任務的黃色資源做完後,需緊接著做G任務,考量到B-G的資源相依性,關鍵鏈為D-A-B-G。最後已沒有資源相依性,只需考慮任務相依性,此時我們已找出單一專案的限制─完整的關鍵鏈為D-A-B-G-H。

找出系統的限制後,接著就是要進行第二個聚焦步驟─決定充分利用限制(Decide How to Exploit the System’s Constraints)。

由於在單一專案裡,關鍵鏈已經是同時考量任務相依性和資源相依性最長的路徑,為了避免專案的不確定性因素造成關鍵鏈的進一步拉長,我們要把剛才取出來的安全時間放回專案中,用來保護關鍵鏈。

安排專案緩衝

把從關鍵鏈任務D-A-B-G-H取出的安全時間整合起來,變成一個完整的保護時間並放在關鍵鏈的末端,CCPM稱之為專案緩衝(Project Buffer)。過去的管理方法以隱含安全時間的各別任務組成的最長路徑來押交期,一有任務延遲,交期的準時度就面臨危機。CCPM的規劃,是以緩衝來吸收關鍵鏈上的延遲,任務的變動不會直接衝擊到交期。

最後進行第三個聚焦步驟─依上述決定,讓非限制充分配合 (Subordinate Everything Else to the Above Decision)。

此時的非限制指的就是非關鍵鏈(Non-critical chain),或者稱為匯流鏈。從上圖可以看到非關鍵鏈總共有三條路徑─ C、E-F、以及I-J。把從非關鍵鏈路徑取出的安全時間,放回到非關鍵鏈匯入關鍵鏈的地方,成為匯流緩衝(Feeding Buffer, FB)。這樣的放置可以在非關鍵鏈發生延遲時,先以匯流緩衝吸收延遲的天數,避免直接影響關鍵鏈,形成對關鍵鏈的保護。

安排匯流緩衝

另外,執行專案時最常發生的問題還包括原先預定好的資源正在忙別的工作,無法接手準備要開工的任務,這個問題若發生在系統的限制─關鍵鏈上的任務,對專案的交期影響很大,因此CCPM在關鍵鏈任務即將開工前安排一個資源緩衝。這個緩衝並未增加任務的期程,而是一個溝通的工具,也就是在關鍵鏈任務即將開工的幾天前(如:2~3天)通知負責的資源要做好相關的準備,一旦關鍵鏈任務開工日到來,立即接手執行。

安排資源緩衝

排程完成後,各位可以看到,CCPM的專案時程和一般的專案時程規劃出來的非關鍵路徑任務開工時間不大相同,也就是路徑A-B-C及路徑I-J並不是在專案啟動的第一時間開工。這樣的規劃方式有個容易被人誤會的名詞,CCPM稱為As late as possible(ALAP),這裡的ALAP必須是在不違背資源衝突並只早於刻意安排的匯流緩衝時間之下,所得到的任務必要開工時間。當然如果在您的組織裡當時只有這個專案,或是當時可以執行第一個任務的資源是確定閒置著的,那麼是可以在專案第一時間就分派任務給該資源。可惜,在多專案的環境中,通常資源都是在執行別的專案任務時接到一個還不需要急著完成的任務,造成不良多工。CCPM以這樣的規劃方式讓資源在執行階段儘可能專注於當下必要的任務,與As soon as possible將沒有前置任務的工作儘可能拉在專案啟動第一時間開工的方式,兩者背後的思維和作法天差地別。

傳統規劃方式

另一個容易引起討論的議題,是Buffer加總起來的時間比原本取出的時間總合少了一半。傳統的專案規劃方法是將安全時間放在各別任務裡,此時別人的安全時間並無法分享給自己,以致於每個人都得估自己的安全時間,因此從整個專案的角度來看,整體估的安全時間量是超過真正需求的,只是過程中因為不良多工、學生症候狀…等因素而浪費掉了。過去訪談很多專案組織後證實,一個專案裡真正會遇到不確定因素的其實只是少數幾個關鍵任務,其他任務遭遇不確定性因素的機會其實不大。也因此,將安全時間彙整起來後只要保留一半當作buffer就足以應付整個專案的不確定性因素了。當然,這還是得依不同專案屬性來調整,通常大型專案隱藏的安全時間多,任務之間可以互相抵消的空間較大,至於規模太小的專案,抵消的可能性較小,所需要保留的安全時間也許需要多一點。不過今天只是介紹CCPM的排程原則,細節的調整則是組織在進行導入時才需要討論的議題。

今天以簡單的例子向各位說明CCPM在規劃階段如何透過安全時間的重置整合(緩衝)來保護專案的限制(關鍵鏈),和您所熟悉的專案規劃方法是否有很大的差異呢?

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
Mia Chang

台灣少數有協助過公司組織導入關鍵鍊的顧問

12 則讀友回應

  1. Mia Chang 2011-04-01 11:02:50 第 12 則

    Dear 肥蝦,
    拜讀過您的文章, 見解總是精采!

    Dear Joe,
    是的, 在CCPM導入穩定後, 專案任務50%信心度的工期會漸漸明朗, 屆時就會演變為以這樣的方式運作.

  2. Joe Chang 2011-04-01 10:40:00 第 11 則

    我用我的話描述一遍,請Mia看看是否正確 :
    我們若假設一開始網圖中個別作業的Duration已經沒辦法再壓榨了
    (假設同仁都很真誠的只提供50%信心程度的Duration)
    這表示我的步驟會變成 :
    1. 錯開資源衝突,找出關鍵鍊
    2. 根據關鍵鍊上的工期計算總Duration
    3. 以2所得的Duration/2
    4. 這是我的Project Buffer
    5. 假設此專案並沒設定交期時,會以總Duration+Project Buffer做為承諾交期

    這理解對嗎?

  3. IT肥蝦 2011-04-01 09:58:06 第 10 則

    肥蝦也來呼應一下TOC!

    經濟學中很多理論都引用物理學的觀念,如最有名的"彈性",而TOC的創始人Eliyahu Moshe Goldratt正是一名物理學家!當初看到TOC理論,覺得好眼熟!

    經濟學把生產資源區別為土地,資本,勞動力,跟企業家精神,對應到一個軟體專案,就好像對應到軟硬體設備,資金,勞動力,跟專案管理精神一般!在生產要素有限之下,為達到目標如何加以組合,這就是企業家精神或專案管理精神的重點所在!

    因為在constraint下追求Maximum或Minimum幾乎是經濟學中個體經濟的基礎,因此TOC一下子就擄獲肥蝦的心意!
    因此針對目標所安排出來的schedule必須在因應constraint下重新安排,取其最適解,但這最適解糾就悠關了兩個重點:
    (1)目標:Target,經濟學很強調目標的明確性,就是可測量性!因此如何界定目標,設定量測的標準與方法,就很重要!經濟學知道一個目標的量測很難用單一方法或Metric就可以掌握,因此有所謂的先驗指標,落後指標,同步指標;以及資料的正確性(資料的掌握,瞭解,取樣,估計,機率,正也是統計的重點)!正在衡量專案時也是要注意的!PM教科書中一再強調EVM,但PM應謹記,其個組合各數質的特性!(基本上現在所有的PM Tool所提供的EVM都只能算落後指標!)


    (2)限制:在經濟學中所強調的限制式,主要在生產資源,但除了軟硬體設備,資金,勞動力,跟專案管理精神之外,也應該可以呼應PMBOK的九大知識領域中的時間,成本,品質,人力,等要素!
    因應限制,感覺上TOC一是強調緩衝的使用,二是強調突破限制!
    在緩衝上TOC提出了:
    資源緩衝:針對資源有限性。
    接駁緩衝:針對步驟依存性。
    瓶頸緩衝:針對必要程序限制性。
    專案緩衝:針對整體專案性。

    在突破限制上,TOC強調:
    確認制約
    有效剝削制約
    其他一切遷就制約
    鬆綁制約
    重新檢視
    五個流程!

    Mia是一位TOC的專家,在此篇中的舉例也正呼應了TOC的精神,雖然例子中Mia以資源為主,(在PMBOK也以為TOC主要在資源)但Mia的重點是在限制,限制的範圍涵蓋遠大於資源!但講資源一般人比較有感覺,講流程,講人際關係等無形的限制,可能就不好說明了!

    此外,PM的觀念中都是估完範圍後再來確認資源,就經濟的觀點(或肥蝦認為的TOC)限制是一開始就存在的!甚至在範圍之前就存在!因此Buffer的增加也要遵循這限制!
    因此專案最好的思維應該是在限制中保留Buffer,因此一開始就要設法以最精省的方式來達成目標,然後(限制-最精省的方法)就是Buffer!為了確保目標的達成,再來安排Buffer!

    經濟學從十九世紀中從追求靜態的均衡解到強調動態的均衡!關鍵就在時間,物換星移,因此就算環境如您所料,但隨著時間的經過,市場的變動,原先的架構也會脫離當初的均衡解,再經過調適,而最後這均衡解是收斂還是發散,就決定了這目標能否達成!(就因為太複雜,所以經濟才會強調:其他條件不變下,但這在現實當然是不可能的!)

    因此肥蝦看到了很多的軟體專案的流程都follow一些開發方法論,從簽約,kickoff會議,需求訪談,規格確認,程式開發,單元測試,整合測試,驗收測試,等程序均是一層不變!心中真覺得是"讀書反被讀書誤!"

    就像Mia所舉例的流程可以調整的!就專案層級而言,不變的只有目標跟限制;若就Business來說,這目標跟限制也是會變的!因此一個PM必須隨時注意目標跟限制,並且要常眼觀四方,耳聽八面!所有的流程都要能因應實際的限制而去動態的調整!

    還有這目標!到底是Maximum或Minimum,很多人一開始都不清楚到底是要Maximum?還是Minimum?在經濟中,雖然認為在大多的情況下Minimum Cost是Maximum Profit的必要且充份的條件!但肥蝦印象下,有些就不會是如此了!

    因此一個專案的目標,大家都說是要如期,如質,如預算!但沒有這麼好的事啦!目標還是要先弄清楚!

    還有........

    今天愚人節,肥蝦就寫些愚人的看法,來逗大家開心!!!!

  4. Mia Chang 2011-03-31 16:54:08 第 9 則

    如果專案中的個別作業確定是沒有放Buffer的狀況,
    Buffer就要用外加的方式, 安置在匯流處和專案末端,
    原則上, Buffer長度是對應路徑的1/2.

  5. Joe Chang 2011-03-29 20:47:15 第 8 則

    我指的是假設第一張圖的個別作業中都沒有藏Buffer
    換句話說 已經壓榨不出時間時,那在兩種方式上,會有甚麼差異呢?