| 摘要
 對 專案管理知識體系 （ Project Management Body of Knowledge ， PMBOK ）內容的持續改善而言，關鍵鏈專案管理 ( Critical Chain Project Management ， CCPM) ) 加入一套紮實的步驟。關鍵鏈 （ critical chain ）與關鍵要徑（ critical path ）不同之處包含：
a) 資源依賴性（ resource dependencies ），及
b)
絕不變化（ Never changing ）。
CCPM 改善專案計畫，藉由確保可實行性，及免於受到合理之共同原因變異（ common cause variation ）（不確定性，或統計上的波動）的影響。作法是將不確定性 （ uncertainty ） 聚集到，位於專案活動路徑 （ activity paths ） 末端的緩衝（ buffers ）。專案緩衝（ Project Buffer ）保護整體專案關鍵鏈路徑的完成效果，而匯流緩衝（ Feeding Buffers ）保護關鍵鏈免受其他匯入路徑的影響。緩衝管理（ Buffer Management ）加強專案控制上的衡量與決策機制。實行 CCPM 要求改變資源的操作方式，包含數據導向之活動績效預估與多工（ multitasking ），最重要是改善專案經理與執行者的注意力。採用 CCPM 的專案，在時程、成本與內容範疇的表現，確實得到大幅改善。 CCPM 專案的完成時間，與之前的規劃及控制方法相較之下，一般少一半的時間。
介紹
專案管理知識體系指南 （ PMBOK Guide ） (1) 記載 以目前的 專案管理知識體系 ( Project Management Body of Knowledge ， PMBOK) 來看， 關鍵鏈專案管理（ Critical Chain Project Management ， CCPM ）加強專案規劃、執行與控制部分。 CCPM 強調專案的完成時間，也以改善排程的成效，來降低專案的變化與專案成本超支的主因。透過改變專案的規劃方式、專案衡量方式、控制系統及某些專案執行團隊與支援人員的行為模式， CCPM 得以達到上述結果。
專案執行問題
專案繼續呈現高失敗率，因而各界不斷投入專案執行績效的改善需求。在 澳大利亞 (2) 曾有人（可能是段時間以前）研究，發現建築專案八個合約中只有一個如期完成，平均超時百分之四十。 Chun and Kummaraswamy 最近的研究報告中 (3) ，提到香港建築專案有相似超時情況，『建築專案的延誤情況，在全世界大多數的地方還是很普遍，即使引進尖端的建築技術，與更有效能的管理技巧，還是如此。』以整體專案來看，相關績效統計的量化數據似乎 不足，報告中提到的失敗專案，未能達到承諾的成本或時程（ cost and schedule ）。新聞報導中有很多大型專案失敗的證據，尤其是大型政府的專案（很多國家都有）。個人經驗接觸到不少大公司所管理的許多專案，而未能達成專案目標的失敗比率也不低。
有文獻將專案失敗歸因於許多潛在的原因（ 4 ），有些部分與其他報告相同，而通盤的一致性只有小部分。在研究失敗專案的文獻中，沒看到試圖區別是共同原因變異或是特殊原因變異（ common cause and special cause variation ）（見下文）。以國際上許多類型的專案經驗而論，多將執行專案的難度指向專案管理系統（ project management system ），視其為頭號造成困難的 可疑因素。
Theory of Constraints （限制 / 制約 / 約束理論）
CCPM 來自將 Theory of Constraints 應用 於專案管理。 Theory of Constraints 的 精髓首先出現在 高德拉特博士（ Dr. Eliyahu Goldratt ） 的暢銷書『目標』 (5) 。『目標』演示一套工廠管理的改善系統，對於許多企業已有，而且持續發生中，大幅的改善影響。
高德拉特博士稱他所創的系統改善方法為 Theory of Constraints （限制 / 制約 / 約束理論），或簡稱為 TOC 。 高德拉特博士以科學方法來創立 TOC ，他說『任何系統必定有一個限制，否則產出會沒有極限的增加，或是歸零 （ Any system must have a constraint. Otherwise, its output would increase without bound, or go to zero. ） 』。大多數人都能接收這個論點，是個 不證自明的事實。令人驚訝的事情是，從這個論點產生的效果， TOC 的影響程度已被與牛頓發現的運動定律（ the laws of motion ）相提並論。
『目標』的主要訊息是聚焦（ Focus ），聚焦在企業的目標。聚焦在妨礙達成企業目標的限制。『目標』總結出五項聚焦步驟（ the Five Focusing Steps ），適用於任何實體系統（ physical system ），包含之步驟有：
-
指出系统限制 （ IDENTIFY the system constraint. ）
-
决定如何充分利用系统限制 （ EXPLOIT the system constraint. ） [ 加註： Decide how to EXPLOIT the system's constraint ]
- 所有非限制資源要全力配合步骤二所作的决策 ( SUBORDINATE everything else to the system constraint.) [ 加註： SUBORDINATE everything else to the above decision ]
-
系统限制升级 （ ELEVATE the system constraint
- 如果在前面步驟中發現新的限制，重複這個程序， 回到步骤一，不要讓惰性 ( 典範 ) 成為系統限制 （ If, in the previous step, a new constraint has been uncovered, repeat the process. Do not let INERTIA become the system constraint. ）
一部份是因為 高德拉特博士著作目標是以工廠的生產線為背景，從事專案管理的群眾無法理解其中論述，亦適用於專案管理的重要意義，出版關鍵鏈則導正了這個情況。書中描述應用 TOC 系統理論，從應用於改善生產管理到改善專案管理。我形容關鍵鏈（ Critical Chain ）即為關鍵鏈專案管理（ Critical Chain Project Management ， CCPM) 。
自從在 1990 年代早期起，高德拉特博士與他的同僚開發並 仔細定義 CCPM 的應用。 Dee Jacob 是 the Avraham Y. Goldratt Institute 的執行董事，她是主要的開發人，首先於某 Fortune 500 公司成功實踐 CCPM ，之後便有許多公司採用，並得到良好的成效。 CCPM 現在已有許多豐富經驗及成功案例的記錄，將 CCPM 與 PMBOK 搭配，成為一套普遍適用的改善方法，以利專案執行者提升專案的多元績效。
接下來的討論，依照上述之聚焦步驟。
指出專案的限制（ Identify the Project Constraint ）
TOC 指出的專案限制，稱為關鍵鏈（ Critical Chain ），或是『一系列依賴的事件妨止專案在較短期間內完成。決定關鍵鏈時資源依賴性與任務依賴性一樣重要。 （ The sequence of dependent events that prevents the project from completing in a shorter interval. Resource dependencies determine the critical l chain as much as do task dependencies ）』
從時程（ schedule ）來看定義專案的限制，推論時程對專案成本與專案內容的影響。這三個條件具有依賴性，當時程拉長而內容不變，成本通常增加。當內容增加而成本（或資源）不變，時程傾向拉長。當內容增加而時程不變，成本傾向增加。
關鍵要徑規劃（ Critical Path project planning ）經常有隱藏的假設，這便說明專案具有潛在的資源限制。一種被採用的方式是，首先找出關鍵要徑，接著執行資源平準（ resource leveling ）。網路圖專家知道，沒有 最理想的 平準 演算法（ leveling algorithms ）。在有些網路架構，某些資源 平準 演算法得到很差的結果。對於大多數的網路圖，使用資源 平準 演算法拉長整個專案時程。因而，很少數專案使用資源 平準工具。
圖一演示一個典型的 決定性的專案時程（ deterministic project schedule ）。顏色代表特定的資源。專案計畫指出最後的活動（ activity ）是一個關鍵要徑的活動。資源平準已消除其他的關鍵要徑。這是使用資源平準方法，經常可見的結果。
圖一：例子 – 資源平準的關鍵要徑時程表  由於 資源限制經常是重大的專案限制， TOC 方法在進行專案規劃時，總是會考慮資源限制。因此，關鍵鏈定義整體專案的最長路徑（限制），包含資源依賴性的因素，在決定專案關鍵鏈時，化解所有資源限制。專案關鍵鏈在活動與活動間，可能有間隙。 CCPM 的改善結果不是視專案中的重要資源限制，或資源衝突的處理情形而定。他們應用於任何專案之理由列舉如下。一個沒有資源限制的專案，關鍵鏈與關鍵要徑的最初活動路徑相同。下面描述大不相同的專案計畫。
專案管理知識體系指南之關鍵要徑定義，陳述關鍵要徑可能在執行專案的過程中改變。這是當其他路徑遭遇延遲時，而再次定義到完成專案的最長零浮時（ zero float ）路徑。關鍵鏈則在專案執行期間不改變。這一部份是定義的事情，但大多數是整體關鍵鏈計畫建構程序的結果。五項聚焦步驟的下一步是開發與使用 CCPM ，藉由聚焦於一段已知的時程，充分利用限制，以得到最大的效益。
充分利用（ Exploit ）
充分利用共同原因的變異（ Exploit Common Cause Variation ）
戴明 博士（ W. Edwards Deming ）的淵博知識（ Profound Knowledge ）論述中，包含『變異的理解（ an understanding of variation ）』。 (7) 他定義兩類變異：
-
共同原因的變異：原因是 內含於系統，管理的責任。
-
特殊原因的變異：特殊原因是由於某組的工作人員，或是某特別的生產人員，或是某特別的機器，或是某局部的情況。
戴明 博士注意到，管理人經常沒理解兩類變異的基本不同之處，而使的許多系統更糟。他也注意到，『在我的經驗中，我預估大多數麻煩與大多數改善的可能性，算起來大概是：
-
94% 歸屬於系統（管理的責任）
-
6% 歸屬特殊因素。』
在活動（ activity ）的執行期間，專案有共同原因的變異。雖然執行個別活動的時間，可能彼此獨立，專案活動網路定義出活動間的依賴性。透過專案邏輯的定義，在前面的活動沒完成前，後面的活動無法開始（大多數經常是完成到開始 [finish-to-start] 的活動連結。）
高德拉特博士的生產改善，善用統計上的波動現實及依賴事件。圖二演示典型的活動執行的時間分佈。實心曲線（左邊 縱座標）呈現在 橫座標上 一段時間的或然率（ probability ）。點線呈現活動及時完成的累計或然率，少於或是等於縱座標上的時間。注意到，分佈的左邊 偏斜，及右邊長尾，這是許多專案活動的典型共同原因的變異。
圖二，典型專案活動的執行時間之或然率分佈，呈現最小時間，左邊偏斜，及 右邊長尾。
Figure 2: Typical project activity performance time probability
distributions show a minimum time, left skew, and a long tail to the right.
對特定專案活動，實際執行過程中的波動（ Fluctuations ）可能比生產機器，或人工重複操作同樣零件的波動大多了。專案活動網路清楚地呈現專案中許多依賴關係。拿任何專案與生產線相比，會發現即使是中型大小的專案，有較多的依賴關係。由此觀察推論，改善生產線的邏輯應該也適用於改善專案管理。
在活動執行中的共同原因的變異，不是個例外的事件，例如各別的專案風險事件。 PERT （Program Evaluation and Review Technique， 計劃評核術 ） 試圖預估這個共同原因變異的影響，使用三個活動期間預估（ activity duration estimates ）方式，然而由於種種理由並不成功。 專案管理知識體系指南及文獻還是陳述這個方式，雖然現今使用的不多。『 PERT 圖』在許多專案的文獻中皆有記載，在許多專案軟體系統也是如此，僅是用於呈現專案網路的邏輯，與時間無關，沒應用到三種時間預估。有些專案使用模擬方法及 蒙地卡羅分析法（ Monte Carlo analysis ） ，於評估活動時間與成本不確定性 的影響情況。這些方法提出預估不確定性的方式，但沒提出一套管理不確定性的有效系統化的方法。
CCPM 以共同原因的變異為改善專案管理系統的主要因素，而其程序消除可識別的特殊原因的變異，含資源不可得的情況與共同的資源行為模式，含學生症後狀（ student-syndrome ）及多工（ multi-tasking ）。 CCPM 專案經理使用資源旗（ resource flags ），去指出與確保在關鍵鏈上資源的可得性。
圖三：例子 – 關鍵鏈時程指出計畫的主要 特徵
（待續） |
是的，更加 深謀遠慮的經營方式。如果觀察美國與歐洲大多數經營方式，他們專注於削減成本（ cutting costs ）。所以中國近年來基本上提供無限的產能及低成本，但是無論削減多少，無法據此競爭。歐美製造商面對這樣的沈重負擔。