昨天我們談到要不要給籌碼，結論是需要的，但問題是如何給。今天我們不彷就來談談如何給籌碼。
這個話題無論對企業經營者也好，專案主管也好，甚或功能主管而言，都是一個值得深入探討的話題。首先要先確定一下，為何要給籌碼(Buffer)？如果這個問題都無法確定，那籌碼絕對無法發揮應有的價值。
專案管理的節點多，時間又受限制，諸多的不確定因素又是專案的特色，如果說能夠把工時抓的百分之百的精確，那是不切實際的想法。特別是專案的時間越長，變化就相對增大，如果沒有一點安全閥的設計，就如一個沒有安全裝置的鍋爐一樣，當壓力積壓到一個程度後，爆炸成了唯一的結果，所以給一些籌碼(Buffer)是必要的考量。
就單一專案而言，這個問題還算好處理。只要找出關鍵要徑(Critical Path)，充分的細算工時與評估風險，針對關鍵點(Critical point)，只要適當的規劃一些籌碼工時，做好應變措施，控管上並不是太難。但以現在的電子產業來說，多專案同時進行的案子幾乎是無可避免的現象，一個人手頭上同時負責數個專案也是稀鬆平常的事。這種情況下，傳統的關鍵要徑已不敷使用，工時的評估也變得複雜與麻煩。一個本來不是關鍵要徑的業務，會讓數個專案同時面臨到時程delay的困境，此時的工時評估與網路規劃，難度之高自不在話下。關鍵要徑的觀念已無法滿足多專案管理的需要，取而代之的是關鍵鏈(Critical Chain)管理，才能夠有效的達到多專案控管的效果。
多專案管理已儼然成了是21世紀的專案常態，此部分有待往後設個篇幅，好好的來談談，現在先就單一專案來談談籌碼該如何給。
上次我們談到那個簡單的專案(A、B、C)，還是以這個案例來說明。既然籌碼是濟急不濟窮的措施，那當然不該讓成員隨意浪費。如果每個工作的工時需要五天，網路規劃時不只不能加任何籌碼，三個工作的結合也應該採取壓縮式的規劃，而非傳統的銜接式業務規劃。所謂的壓縮式的規劃，就是讓三個工作有某些程度的重疊，簡而言之，就是採取小同步的方式。當A進行任務的時候，不是等到結束才交給B，而是在工作還沒結束前，B就開始進行其負責的業務。這樣的規劃會讓成員增加壓力，但卻逼得成員必須依據計畫行事。同時要讓業務銜接順利，兩個上下游工作的成員，不得不採取事前規劃與緊密配合的做法，否則將沒完沒了，這是採取同步工程必須承受的風險。為了紓解過程的風險，工時的籌碼，將放在業務最後面的部分，由PM統籌調度。如果前面進行順利，專案籌碼可能會增加，籌碼的燈號將會停留在綠燈區；如果進行出現一點小問題，只要被吃掉的時間，還未突破設計的工時限度時，燈號將會顯示黃燈；當工時已大幅推遲，籌碼大量被侵蝕時，籌碼的紅燈亮起，此時PM就必須啟動緊急應變措施，將專案拉回正軌。專案主管運用交通號誌的顏色管理來處理籌碼的調度。
由此類推，專案主管對籌碼的管理不再如以往的依靠專案會議控制就夠了，日常的進度管控，是不可忽略的重點。當然專案成員的工作申報要求，與業務品質的自我判斷等自我管理，都是成功的不二法門。這些也都是專案的基本功，遺憾的是國內的企業都不願意面對這些基本的客觀問題，專案的管理只靠一個PMP或是一堆的PMP都無濟於事。Team work的重點是一堆人的力量，專案管理的目的之一就是要以三個人發揮五個人的工作績效為目標，效率大幅提高的前提條件不是因為有專案，而是因為有一些別於傳統功能是組織管理的技巧與運作模式，這些的技巧與客觀因素都是企業不得輕視的，否則只會看到空架子，卻無法得到專案模式帶來的效益。
沒有留言:
張貼留言