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

ccpm0601

連續幾篇都在談TOC認為專案現況中造成專案時程績效表現不佳的原因,該是時候做個小小的結論了。

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

再加上另一個核心問題「追求局部效率的績效指標」的管理思維,主管們總是害怕資源閒置,覺得讓資源手上同時進行好幾件事可以降低資源的單位成本,誤以為這是讓資源生產力提高的作法。這樣的管理思維驅使大家在一接到專案就急著找人去執行,在專案經理看不到其他專案狀況的運作模式下,大家各自規劃、各管各的,到了執行階段再來搶資源,而資源不良多工、組織溝通不良、時程Delay、組織產出減少…都是隨之而來的結果。TOC透過衝突圖挑戰這個似是而非的假設,並認為在多專案環境裡規劃專案時程及交期時,必須考慮資源產能的可得性(Resource availability),適當地延後部份專案的開工時機,將是化解不良多工的方向。

而這幾週陸續和大家提到的議題,包括估算任務工期 (傾向用90~95%高度把握的時間)、資源行為 (任務即使有足夠安全時間還是會因為學生症候群以及提早完工不報告的資源行為而浪費掉),以及遞延效應 (任務工期因遞延效應只有延後的可能卻難以獲得提早的好處)。在此以TOC現況圖整合分析這些問題的因果關係:

ccpm0602

由上圖可以看到「任務準時完成,專案就可以準時完成」的思維導致主管把預估的時間當承諾來考核績效,卻引發大家為了確保個人的專案績效,在規劃專案階段估算把握度高的安全時間加在各別任務裡,以及執行時為了符合初期押出來的任務里程碑引發的人員行為,並形成惡性循環。這些問題的背後存在一個核心衝突,以TOC衝突圖分析如下:

ccpm0603

這幾週討論的內容已經很明確地挑戰「把安全時間放在各別任務裡」背後的假設是錯的,為了化解專案裡衍生的連串問題,解決方向是在做單一專案規劃時採取不把安全時間放置在各別任務裡的作法,並放棄追求任務里程碑,唯有如此才有機會把安全時間聚集起來,並放在更能夠保護專案的地方。

哦!當然,這樣的作法還得搭配全面性的措施才行得通。未來我將開始在How to Cause the Change的系列裡和大家分享關鍵鏈專案管理因應這些專案核心問題所提出的不同作法。

時逢年節,文章的最後向大家恭祝新年快樂,事事如意啊!^_^

覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
Mia Chang

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

6 則讀友回應

  1. taylorshieh 2012-01-13 22:05:35 第 6 則

    這陣子,再次花了點時間看critical chain 及toc thinking process..
    認同 Mia Chang 的看法..
    要了解critical chain 的精神,要先理解toc thinking process...

    Chris 所提,"見樹不見林",如TOC 之父Doldratt仍在世,肯定不同意

  2. Mia Chang 2011-02-10 19:15:17 第 5 則

    感謝Chris的指教。

    就如同我一再向大家說明的,我並不打算一開始就直接把關鍵鏈的解法塞給大家,是為了讓大家先理解這個方法發展的原由,因為TOC的解決方案挑戰的不是技術面的議題,它所挑戰的是大家一直以來視為理所當然的管理思維。這篇留言來的正是時候。也正因為目前為止TOC系列文章是在診斷專案管理問題的階段,還未提及關鍵鏈的作法,「看不出和其他方法論不同」是想當然爾的反應。

    Chris對方法論的質疑,我的想法是這樣,公司的經營原本就會有不同層級的目標和策略,所以上層的目標和策略必須以經營層級的角度思考和制定,才會往下層層展開,而專案是這個過程中為了達成各層級目標的一種操作手法。所以對我來說,不同層級的議題會有其適用的方法論,只要找到對應的方法論,理應是互相搭配,而不會是相互抗衡的。

    至於您認為TOC的矛盾,文章中已經說明過,TOC在做組織整體面的改善時,找出最弱一環來加強它,只是改善的第一步,持續改善程序(POOGI)的重點還必須搭配上其他環的同步配合。這樣的改善歷程在企業的生命週期中,通常需要個把年才能走完,等企業經歷過這樣的改善後,公司的經營規模比對起可運用的資源到了某個時間點又會顯得不足,這時才會再次循環。而在專案管理議題上,同樣的思維邏輯,TOC所強調的是找出引發各別問題的核心問題,加以化解,而不是在弄不清楚問題之間的關連性時就冒然採取措施,試圖各別解決,這樣容易白費心力,難以達到預定效果。

    另外,TOC認為「任務準時完成,專案就能準時完成」這個假設錯誤的原因,在遞延效應那篇文章中我舉了不少例子說明。所以我應該這樣補充,今天我們談的如果是「所有任務都可以準時完成,專案就能準時完成」,這個假設便會是對的。那就要問問各位專案經理在過去的經驗中,可曾遇過所有任務都準時的情況?而這樣的專案週期是否具有競爭力?不過,那不是我想表達的重點。重點在於,這個核心思維引發的後續問題對專案的種種負面影響,都已在這幾週的文章和現況圖裡不斷被闡述說明。唯有我們認知到大部分任務準時,不代表專案就能準時,我們才有機會重新思考目前以任務里程碑來判定專案績效的衡量方法,是否是唯一的辦法?也唯有如此,我們才會願意聽聽不同的管理方法是否能帶來不一樣的結果。

    非常感謝Chris丟出這些疑問,我想在還沒詳細說明關鍵鏈方法之前,這些問題我會放在心上先保留起來,等到How to Cause the Change系列文章完成之後,我們可以再來好好地聊聊。屆時,還望您繼續指教啊!

  3. sunny 2011-02-10 12:52:10 第 4 則

    小弟回憶當初讀《關鍵鏈》的模糊印象~
    該書提到「專案緩衝」應統一由PM彙整掌控,
    所以各任務應設定「明確期限」而沒有保留緩衝時間…

    不過就如Chris所提,各任務負責人也都知道PM一定會保留專案緩衝。
    所以有可能變成「皮」的人反而容易「爭取」(拗)到緩衝?

  4. Bryan Yao 2011-02-09 21:23:17 第 3 則

    To Chris:
    嘿嘿,有意思,不管是懷疑論,還是來吵架的,都比意興闌珊好!就像追求男女朋友,好印象,壞印象,都比沒印象好!關於你的意見嘛,還是先請原作來回應吧!

  5. 就是那個Chris 2011-02-09 19:54:17 第 2 則

    不好意思,我是來抱持懷疑態度的(不過不是來吵架的)。這一系列的文章看下來,至少到目前為止,我還不太能理解這個方法論,跟其他千萬個方法論到底有什麼不同。

    老實說,在軟體開發這個領域也混了這麼多年,這類管理方式的方法論也涉獵不少,但是這些理論多半共同的缺陷也都集中在三個相同的地方:

    1.理論本身就基於很多的限制與假設,這些限制與假設使得這個理論本身能應用的場合少之又少,以致於實用性並不高

    2.算是上一個原因的延伸吧,也就是「大部分的理論都強調要對整體做最佳化(這原本就是大家的期望)而非局部,但是這個理論本身就沒有囊括整體,講再多骨子裡還是局部最佳化...」,所以使用這個方法論,經常是拿戰術試圖解決戰略問題,一開始就註定最後的失敗。舉例來說,公司的專案,無論是代工,或是自己生產產品,目的都是銷售、營利。可是絕大部分的時候,軟體開發管理的方法論,根本沒涵蓋銷售、市場,所以軟體開發最佳化的結果,也許會傷害銷售、傷害營利。好,那如果把軟體開發管理擴大到專案管理呢?用專案管理的方法論,把行銷也包括進去?可是那公司的現金流呢、人員薪資管理呢?不同專案間的交互影響呢?又沒考慮到,所以專案管理最佳化,仍然可能導致企業失敗!那如果再擴大,用企業管理的方法論呢?這總夠了吧?可是放眼看看,一旦到了企業管理的層級,一方面就不會有太多實務細節,二方面因為已涵蓋戰略層級,因此有太多學說都強調許多因素無法量化卻又佔有關鍵重要性,例如要找對人、要型塑企業文化...等等,事情到這種形而上地步,老實說方法論我還真不知道還能使上多少力...

    3.新理論點出舊方法的問題,可是他也沒解法,或是解法很爛,搞出更多新問題。

    基於以上原因,我對所有管理的方法論,是很負面的從第一個字懷疑到最後一個字,必須很緩慢的被嚴謹的邏輯以及實證(邏輯再正確,無法實做還是沒用啊,例如時光旅行)來說服。


    回到TOC這一系列文章,我很懶,沒去看完整個理論,所以以下的理解若有錯誤請指正。

    從邏輯上來看我覺得本身前後矛盾耶。首先,在第一篇介紹限制理論的文章中說,一條鍊子不該不分青紅皂白的每個環都加強,而是需要先找到最弱的那一環,加強他,然後再看新的弱環在哪、再加強...等到這些局部的問題一一解決,整體就都強了。但是,這個一個一個解決、找出局部弱點加強的手法,不就是後面文章說的萬萬不可的、見樹不見林的局部最佳化(任務的準時等於專案的準時?)嗎?

    如果照文章所描述的理論,以及後續文章才會詳談,但是已經點出來的題目,就是「基於專案任務之間的相依性,安全時間放在各個任務裡面,會造成安全時間無法共用,因此應該將安全時間從日任務中拉出來,拉到專案層級,才有共用的機會」。

    那們我們也應該可以同理可說,企業這條鍊子,也不會是呆呆的一條龍,一定也是錯綜複雜的鐵網,因此,鐵環之間也會有相依性,因此,解決一個弱環對整體並見得有幫助,因此,弱環不該一個一個解決,應該要一次把所有的相對弱的環節通通抓出來,集中檢查分析,看看有沒有一個方法,可以解決很多環的30%的問題,而不是用一個方法,解決一個環100%的問題,但是卻對他相依的環視而不見。一次解決一環,根據這整套理論的說法,最後發現沒效果的機會大得多...

    好,鍊子只是一個例子,只是為了幫助理解,誰都知道公司是鐵網,對一個例子說三道四沒意思,我了解。

    那如果我們來看範例之外的描述。既然「任務準時,不代表專案準時」,那麼同理可說「專案管理做好,也不代表公司會做好」?!那麼下一個該問的問題就是「那我幹嘛要做專案管理?」我想大部分人面對這個問題,應該會很直覺的回答「專案管理畢竟是重要的一環,如果能把專案管理好,就算沒有解決公司的所有問題,也解決了70%」,好,如果這個回答是大家認同的,那麼「任務準時」這件事情,我們是不是也可以說「從任務層級就設立精確的milestone,並良好的管理,雖然無法解決專案時程的所有問題,至少也解決了70%」(這就是我心中的想法,說實話)?<-跟這一系列的文章要說的完全相反!!!

    說實在的,還沒看到後續文章提出的解決方法(因為我不認為用中位數去抓任務時程,或是跟績效脫勾,就不會有學生症候群,或是大家做完就會立刻回報,應該還有什麼克服人性的秘技才是),也無法這樣就論斷這個理論,畢竟我只是看文章,從一些解釋用的範例中去理解,而不是真的k完這個理論。所以我只能說我還滿拭目以待後續的文章,能用什麼樣的方法,來導正「任務準時完成,專案就能準時完成」,以及「各別任務的安全時間將能被妥善應用」這兩個錯誤假設 :) (我是認為安全時間就算拉到冥王星,只要大家知道他是安全時間,就會濫用)

    其實,「各別任務的安全時間將能被妥善應用」如果是錯的,那麼從文字邏輯來說,正確的應該是「各別任務的安全時間將_不_能被妥善應用」,這還在我的理解範圍內(應該沒錯吧?)。但是如果「任務準時完成,專案就能準時完成」是錯的,正確的是什麼我還真的不太確定,是「任務準時完成,專案就_不_能準時完成」呢?還是「任務_不_準時完成,專案就能準時完成」?還是「任務_不_準時完成,專案就_不_能準時完成」?說真的,既然我覺得對的都被說錯了,面對一些我本來覺得錯的敘述,我想我已經失去猜測誰才是對的的能力了 :p