每一個PMP或者是準PMP都會知道關鍵鍊這個詞。但能說清楚的應該沒有多少。會用的估計更不會超過1/100。希望本文能是大家不用通讀原著而了解關鍵鍊的概念，隻用30分鐘。
原著以小說的形式說明的管理學中的關鍵鍊的原理及運用方法。小說寫得生動，活潑。在不知不覺間，書就讀完了。但是在現在的時代快餐流行，應該有很多人希望能夠有更快的方式對關鍵鍊有個大概的了解。于是按照個人的了解，總結了一下。
本文中的絕大部分都來自原著。想知道更詳細的資訊，強烈推薦大家讀原著。
第一個問題：雖然在項目中加入了大量的安全時間，但項目還是會延期
先來觀察一下我們身邊的項目，一般來說，都存在以下的問題。
1）成本超出預算
2）時間超出期限
3）項目的規模或設計内容被犧牲。
在項目失敗時，正式的解釋都說是其他人的錯，，如天氣，供應商，環境等等（事業環境因素）。
但是項目經理給出的原因往往是
1)公司高層制定不切實際的日程
2）公司因為成本而選擇不可靠的供應商。
3）元件項目團隊太晚。
項目經理的下屬提出的原因：
1)過分依賴進展報告，事後才發現所報資料不正确。
2）監管不足。
3）項目組成員頻繁的被調派去處理各種突發事故。
4）太多無謂的’協調會議‘阻礙項目的進展。
所有問題都有一個共同點，就是它們都是其他人的錯，我們聽見的都是互相攻擊。員工的地位越低，矛頭越是指向公司内部，而不是外部。
有一點可以肯定，就是我們不應該忽視低層經理的申訴。如果他們說的是對的，那就是說，大部分錯誤就出自公司内部。換言之，公式内部應該是可以把項目管理得更妥善的。
當然我們我不能忽視公司高層的的意見。他們提出的問題都是一些不确定因素，一些在項目開始時難以預料的東西。
不确定因素是所有項目的典型特征。是這頭野獸的本性。如果回頭再分析一下項目經理提出的投訴會發現，它們也都是圍繞着一些不确定因素。
這些因素直接影響項目估算的方式和結果。
如果我們畫一條估算時間和完成機率之間關系的曲線，基本上會像下圖一樣。之是以後面的部分比較長是因為上面提到的不确定因素。不确定因素越高，分布圖的尾巴就會越長。
機率中間值的位置表示項目隻有一半機會再預定時間之前完工。但是實際下屬在估算師留有安全時間，進而将完工時間設在馬可（書中人物）畫的位置。因為墨菲是存在的。
（墨菲定律：一切可能發生的麻煩，都必然發生）
隻有自尋死路，缺乏經驗的人才會選擇中間值。尤其是大部分機構，提前完工不會獲得獎賞，但延誤卻需要層層解釋的情況下。
也就是說，為了8成，9成的成功機會，加進了幾乎200%的安全時間。
結論：因為在所有的項目中，不确定因素就是大部分問題的主要根源，是以人們為此增加了很多安全時間作為保障。這個問題值得深入讨論。
項目的安全時間是怎麼進入估算中的呢？
一：預估時間是根據以往慘痛經曆來制定的，即分布曲線的·最末端。
每個領班都會說“如果”萬事具備，那麼準時完成它負責的部分并不困難，雖然他們不會用機率表達，但大概也有8，9成以上機會。但是同時都會強調：他們的答案是基于兩個假設：
1）他們不被其他人連累而導緻延誤
2）同一時間沒有太多工作要他們分心。
二：涉及管理層越多，完工時間預估會越長，因為每層都會加緊各自的安全因素。
每當任務由多個步驟組成，而步驟由不同的人負責時，項目負責人變回要求每人做出各自的完工時間預估，加起來以後他會在加緊自己的安全時間.如果一個人預估他的任務需時5天，下一個任務也需時5天，項目負責人會說總共需時13天。即：5+5=13
三：預料到高層會削減整體完工時間，各人預先加大安全時間
如果公司高層一半都會在要求削減項目所需時間，比如兩成，那麼大家就會在一開始便把預估加大兩成半。
将以上的安全時間通通加起來，安全時間必然占項目預估完工時間的絕大部分。但為什麼項目還是不能如期完成呢？
那是因為同樣有三個因素到時安全時間被毫無意義的消耗掉。
假設有兩個連續的步驟，預估時間都是10天。如果第一個步驟實際上用了12天，那麼第二個步驟就會推遲2天開始。但如果第一個步驟提前2天完成的話，第二個步驟并不會提前兩天開工。原因大緻有如下幾個：
1）提前完工不但不會帶來獎賞，而且可能導緻老闆削減預估時間。
2）為下一個步驟配置設定的資源無法到位。
3）下一步驟的人清楚的知道時間是足夠的，不會急于開工。
一個步驟的延誤會全部轉嫁到下一個步奏，而提前完工賺得的時間通常會被浪費掉。
同樣，當有多個步驟并行的時候，當中最大的延誤會被轉嫁至下一個步奏，但當中任何提前完工（節約的安全時間）卻完全起不了作用。
沒有可以保護每個步驟的安全時間。
這個問題有一個深層次的原因：學生症候群。(十萬個為什麼：帕金森定律有是一個意思)
十萬個為什麼：如果項目中出現了下面的情況，多半就是安全時間被浪費掉了。
1）擔當者有時忙有時閑
2）很多步奏就正好在預估的時間完成，分毫不差。
還有一個就是多任務，這大概是安工時間的最大殺手。讓每個項目都吃盡了苦頭，稱它為開會，緊急事故或其他任務，影響仍是一樣。都會導緻完工時間大大膨脹。
是以結論是以下三種原因會令早完工所賺得的時間付諸流水。
一：學生症候群-不用急，到最後一刻才動工
二：多任務
三：各步奏之間的依存關系令延誤累積
另外一個問題：關鍵路徑于非關鍵路徑
考慮下面的例子。
很明顯，【興建建築物->發揮各種功能->在建築物内安裝各種機器】是關鍵路徑，共需150天。由于關鍵路徑決定了整個項目的完工期，關鍵路徑上的任何延誤都會延誤整個項目，是以項目經理一定要特别留意它。這是常識。
這裡的問題是另一條路徑挑選供應商，應該在什麼時候開始呢？
方案1：晚開始
這種方法可以推遲投資（實際上包括錢，物，人等各個方面）。
方案2：晚開始
這種方法可以規避風險，避免由于非關鍵路徑上的延遲引起關鍵路徑的延遲。
當然實際的項目通常有很多路徑，遠比這例子複雜。如果所有路徑都在最早的起步日期開工，項目經理會疲于本命。這一點考慮應該遠比押後投資更重要。當然如果一條路徑采取遲的起步日期，它就完全沒有空當時間，也就是說這條路徑上的任何延誤也會導緻項目延誤。
也就是說：如果項目經理采取早的起步日期，他們就無法專注，如果采取遲的起步日期，專注也根本不可能。必須有方法解決這個問題。問題似乎鑽進了死胡同。
換一種思路，這裡需要一個合适的控制機制來讓項目經理保持專注。其實項目都有控制機制用來衡量項目的進展，但問題是，等到進展報告顯示有麻煩時，通常已經太遲了。比如說：進展報告會說：花了一年時間，項目的90%都完成了，而剩下的10%有需要整整一年。
在幾乎所有的項目中（即使是有裡程碑的項目），使用的衡量方法都沒有把關鍵路徑和非關鍵路徑區分開來。這種方法會鼓勵盡早啟動每條路徑，進而導緻項目經理從醒目的最開始就不能專注了。因為根據這種衡量方法，一條路徑取得的進展，會補償另一條路徑的延誤，這實際上就是鼓勵一條路徑快速進展，雖然另一條路徑正被延誤。因為這些路徑最終會合攏，導緻其他路徑上賺取的進展，最終都要等待那條延誤的路徑。
這就是為什麼無數的項目需要那麼長的時間才能完成最後的10%。
原因就是我們在衡量項目進展時，忽視的關鍵路線的重要性！
為了解決上述問題，本書中引入TOC五步法。
步驟一：識别制約因素
在一個項目中，制約因素就是關鍵路徑
步驟二：決定怎樣挖盡制約因素的潛能
不浪費關鍵路徑上的時間，因為關鍵路徑上的任何延誤都會拖累項目。
對策是把每個步奏的預估時間削減，這樣就可以釋放出足夠的時間來建立一個項目緩沖。比如說把每個步驟的時間減少一半，然後将減少的時間的一半作為項目緩沖（project buffer）。
步驟三：其他一切都遷就制約因素
這有這樣才能真正挖盡制約因素的潛能。不懂得遷就，其他路徑遇到的麻煩便會直接連累制約因素，令他損失時間，換言之，沒有好好保護制約因素。
遷就制約因素的方法就是在每條接駁路徑與關鍵路徑回合的地方插入時間緩沖，即接駁緩沖。方法就是在每條接駁路徑上，将各步驟原來的預估時間減少一半。然後将減少的時間總和的一半作為該路徑的接駁緩沖（feeding buffer）。
另外，在某些時候，關鍵路線上的步驟準備就緒，唯獨欠缺相關資源，因為他正忙着其他事情。為了避免這類沖突，可以使用資源緩沖（resource buffer）。
步奏四：将制約因素松綁
步驟五：回到步驟一
怎樣衡量緩沖
使用新的計劃方法以後，取得了以下的效果：
1）不會隻是因為下屬沒有工作做就催逼他人。
2）不在需要裡程碑。
3）不在有拖延。要麼不啟動一個步驟，要麼在可以動工的時候以最高速度執行步驟。學生症候群消失了。
4）由于有相當大的機會不能完工，是以當項目經理關注某個步奏時，更容易被了解。
5）免除警鐘誤鳴即縮短每個步驟的時間對減少多任務也有好處。
關于資源緩沖，雖然不能為了保護關鍵路徑而讓資源在工作開始前一周（比如說）就待命，但是可以在關鍵路徑的工作開始之前發出警号。提醒人們将要到關鍵路徑上工作。最重要的一點是讓人們知道，他們必須放下手頭所有工作，轉而執行關鍵路線上的工作。
在使用這種方法以後，對項目的監控就以以下方式進行：
1）對于關鍵路徑就監控項目緩沖，對于非關鍵路徑就監控接駁緩沖。
2）是用百分比方式還是絕對時間作為衡量标準并不重要。（因為需要監控的清單應該非常短）
3）監控對象不包括尚未開工的步驟，也不包括已經完工的步驟。
新方法的要點：
1）說服各部門消減他們的預估完成時間。
2）消除所有的裡程碑，換言之，個别步驟不再有目标完工日期（duedates)
3)适時報告完工預估時間
項目延期對于公司的影響絕不是增加在項目團隊上的開發經費，而是公司因為産品推遲上市而少獲得的利潤以及失去的市場佔有率。
關鍵鍊誕生了
當項目按照前面的方法進行監控時，會碰到一個問題。
假設其中一條非關鍵路徑(比如3号)進展的實在太慢了，會令整個接駁緩沖耗盡，并已經開始影響了項目緩沖，但（原先的）關鍵路徑卻很正常。
如果按照一般的管理方式來講的話，關鍵路徑發生了轉移。
由于在非關鍵路徑進入關鍵路徑的位置放置了接駁緩沖，改變關鍵路徑，就意味着改變很多接駁緩沖的位置。項目會搞的天翻地覆。但是如果不這樣做，在每次關鍵路徑出現嚴重延誤時，就要重整整個項目。
在有些情況下，關鍵路徑是到處跳的。每隔一段時間就會遇到這個問題。在非關鍵路徑上，本來一切好端端的，接駁緩沖絲毫未動，突然間問題來了。在想要開始某個非關鍵路徑上的某個步驟，但它需要的資源卻不在了。這個資源在另一條也在延遲的非關鍵路徑上工作。
例如下圖中的情況。下圖中有X的步驟是需要專家X執行的步驟。
X是多個步驟争奪的資源（resource contention），以緻它負荷過重，照成延誤。而延誤有一條非關鍵路徑傳給下一條，連各接駁緩沖也消化不了，是以關鍵路徑會到處跳。
十萬個為什麼：在軟體開發中，環境準備，成果物評審環節和這個非常類似。
為了解決這個問題，讓我們首先回到關鍵路徑的定義：需時最長的一串依存的步驟。但是也不要忽視X産能的短缺，不要忽視因公用一個資源而導緻兩個步奏互相依存的情況。産能極為有限，不可能同時進行兩個步驟，隻能先後進行，這就是依存關系。
這樣一來，步驟間的依存關系可以由步驟所在的路徑造成，也可以由步驟所共用的資源造成，根據這兩類依存關系去找那串需時最長的步驟。
一般說來，最長的一串依存的步驟，由不同的部分組成，一部分由于路徑本身，另一部分由于資源配置設定。為了加以區分我們應該先調整一下用詞，關鍵路徑仍然稱關鍵路徑，即最長的一條路徑，但是我們知道最關鍵的是制約因素，即最長的一串有依存關系的步奏，由于我們必須承認，依存關系也可以是資源引起的，我們就用一個新名詞來代表這一串制約因素所在的步驟：
關鍵鍊
在上面的例子中由于關鍵鍊已經成成了制約因素，就必須更改接駁緩沖的位置。下圖是調整後的結果。
十萬個為什麼：這樣還不夠直覺，特補充下圖以友善了解。内容完全一緻，隻是表現形式不同。
關于6，13,11,4,2各個步驟的順序問題，就算用不同的次序編排X的運作，其實差別并不大。即使有差別也不會超過項目的的不确定因素。完全可以靠項目緩沖來吸收。