要改變成甚麼 (Part 1) ─ 綜觀關鍵鏈專案管理

記得在第一篇TOC乃是關鍵鏈之母向大家說明過，TOC是在複雜環境中釐清事物之間的因果關係，找出事物本質上的簡單性，辨識出最根源的問題，再從中發展出解決方案的改善方法。之前花了一些篇幅以TOC分析專案環境的現況，發現因現有專案管理方法造成專案績效不佳的核心問題包括：嚴重的不良多工、將大量的安全時間放在個別任務、浪費掉安全時間的資源行為以及遞延效應，而在這些問題的背後，有著將任務估計時間當作績效指標的管理思維。為了化解這些問題，新的專案管理機制應具備下列條件：

What to Change？(Part 5) ─ 綜觀專案現況的問題及未來解法

連續幾篇都在談TOC認為專案現況中造成專案時程績效表現不佳的原因，該是時候做個小小的結論了。 回想在What to Change? (Part1) ─ 專案環境的不良多工那篇的最後，由TOC現況圖指出造成資源不良多工的核心問題之一就是「認為專案儘早開工就能儘早完成」的管理思維。其實如果我們所處的組織只有一個專案在進行，而且沒有資源有限的問題，這個想法原則上是有它的道理。很可惜，對大部分的組織來說，這種理想國並不存在。

What to Change? (Part 4) ─ 專案執行中的資源行為

最近有位朋友看了我的文章，向我反應寫得太深，不太怎麼平易近人。其實我自己在寫的時候也是這樣擔心，關鍵鏈的出發原意是想針對現有專案管理未能有效解決的問題提出新解法，說得太多不好讀，說得不清楚，又怕未來介紹解法時讓人摸不著頭緒，甚至引發誤解。想讓大家對關鍵鏈發展的原由多點認識，不知不覺一股腦兒地便把腦袋瓜裡的東西全倒了出來。不過，想來想去，一時之間不知道要怎麼樣才能以兼具嚴謹又簡單的方式傳達，只能請大家看文章之前先喝罐雞精、洗把臉，多多包涵了。:) ------------------------------------------------------

What to Change? (Part 3) ─ 遞延效應的影響

上回談到專案規劃時期估算任務期程的邏輯。在普遍認為「任務準時完成=專案準時完成」的管理思維下，任務的執行者會將安全時間估在自己的任務時間裡，以確保達成對任務里程碑的承諾。其實不只是執行者如此，專案經理在嚐到幾次專案不準時的苦頭後，也開始會再把安全時間塞進專案時程裡。但說實在的，假設一個專案可以拆解成幾十個甚至幾百個任務，真正有技術難度或容易遇到困難的任務其實不到一半。這麼說來，在每個任務都放置安全時間的情況下，專案可以穩穩當當地執行完成的機率應該要比實際來得高才是。……………是嗎？

What to Change? (Part 2) ─ 任務時間的估算

上回有個朋友閒聊時問我：你從家裡到公司上班的路程需要多少時間？ 記得那次只是憑感覺估算一下：嗯… 大概15分鐘左右吧！ 這裡指的“大概”，是依每天上班的經驗得來，所以是個平均之後的結果。也就是說，車況順的時候，也許10分鐘就可以飊到公司樓下，有的時候需要花個20幾分鐘，路況差的時候也許更久。反正只是閒聊，以可能性最高的時間來抓平均值最能表達我每天的上班狀況。 可是，如果估的這個時間會跟我個人績效扯上關係時，那又是另外一回事了。 有一回公司邀請了一位自巴西前來交流的顧問，為了確保Workshop準時開始，老

What to Change? (Part1) ─ 專案環境的不良多工

埋首在專案的工作內容之際，你可曾留意部門目前總共有多少專案/工作正在進行？ 這，是我在接觸一個專案環境時，第一個想了解的問題。曾經針對一些企業做過訪談，問到組織是否有不良多工的情況時，受訪者第一時間的反應都是否定的。由於對大多數的主管來說，追蹤進度的主體是專案，既然專案經理大多時間並不是親自動手執行的人，手頭上有2~3件專案，是合理的工作負荷。然而，如果專案經理們所用到的資源是同一群人，那麼，這又是另外一回事了。 

TOC乃是關鍵鏈之母

文字、圖片by Mia Chang 關鍵鏈，聽過部分涉獵過的人認為這不過是另一個簡單的排程技術罷了…我說，把這樣一套完整的方法歸為排程工具之一，著實可惜了。再者，單純將它視為工具或手法的人，似乎還沒有人學了以後拿它來管看看？ 那是因為有太多人只學了關鍵鏈的排程技術，便被不斷湧現的疑惑和設想的障礙淹沒，對於其他配套作法未能深入了解，就像只拿到一個引擎，空轉，自然起不了什麼作用，畢竟整個機器要運作起來還是得搭配完整的模組和配件的。事實上，正由於關鍵鏈專案管理挑戰了目前現有專案管理的方式，各環節能否同步運作就得更加講究，包括：接到專案不一定要馬上啟動