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

關鍵鍊系列文章 作者介紹

雖然我與Bryan一直以來都很努力想把我們知道的東西寫出來。 但畢竟術業有專攻，有些東西在我們沒機會深入研究下，始終了解的也只有皮毛。 所以呢，我這幾年也一直積極的想要找些不同領域的朋友，請他們一起寫些東西，好把他們的心得與知識也分享出來。 這次則很高興邀請到對於「關鍵鍊」這議題有研究的Mia Chang，要來幫我們分享一系列她對關鍵鍊的相關知識。 Mia是台灣少數有協助過公司組織導入關鍵鍊的顧問，相信在此議題上必然有些不同的心得與經驗。 我自己都很期待能讀完她全部的文章 (看自己功力能不能提升一個甲子甚麼的 :P) 總之，她的新文章，我會協助在此