關鍵鏈實務案例─ 製藥部門的研發專案part2

 

 

在文化變革方面他們收到組織成員很多回饋。包括應該聚焦在需要哪些行為?哪種回饋和評量是他們希望就定位的?新環境的獎勵和認同是什麼?還有要建立大家在關鍵鏈方面的能力。“You know – That’s a big challenge for us.

 

在運作方面,就和技術平台有關,也就是要安裝CCPM的專案管理軟體,這還包括需要在組織裡培養一些專家,也藉此深入了解這個技術。另外是導入政策和流程,這個部門本來沒有這些東西,尤其是和關鍵鏈相關的部分。當然這表示他們必須說服高階主管關於緩衝管理、產能限制、規格變更以及那些基本的東西。然後為新的角色─如任務經理、資源經理─設計流程。包括公司期望他們未來做什麼?當他們和系統互動時要尋找什麼資料?讓他們從一開始就參與,並開始將現有組織和新角色做對應。

 

有個狀況值得一提,在建立標準和慣例這項工作,他們花了非常多的時間(awful lot of time)試圖建立範本。為了加快未來專案管理的流程,他們原本認為建立範本是件好事,這樣就不用每個專案都從零開始。然而把大家認為自己正在做的事拿來檢討後,他們發現有太多不同的人有著太多不同的意見。這個「發展完整範本」的任務卡住整個導入專案的進度,造成緩衝侵蝕很嚴重,迫使他們不得不重新檢討作法。

 

(這是進行專案管理改善時很常碰到的問題,原先的立意是很好的,問題出在大家都想在這個階段畢其功於一役,做出一個Perfect的範本。然而,專案原本就是多變的,即便是訂出了一個版本,隨著不同專案的不同狀況,再完美的範本還是免不了得因應現況而變更。所以借用Dr. Goldratt很愛掛在嘴邊的一句話來提醒大家調整心態,“Good enough”就好。先有一個較佳的版本出來,重要的是趕快讓整個CCPM機制運作起來,不盡完美的部分透過緩衝管理的檢討和修正自然會調整過來。)

 

現在來看一下這個導入專案帶來的挑戰。

 

從單一專案的角度來看,他們花了很大的努力在於建立公司成員整體的專案管理能力、將CCPM作法標準化以及帶領團隊。由於他們有大約12PM,對這個轉變的接受程度處於不同階段,前期的挑戰就是讓他們準備好可以上場,並學習著怎麼在新環境裡操作。另外,怎麼將緩衝管理這個新政策嵌入日常的工作中,建立標準和慣例,讓大家的語言正確。這是讓事情結構化並在組織中展開的好方法。“That’s something that we’re, obviously, trying very hard in our own organization.

 

在多專案層級,他們希望穩定資源分解結構(2)。還有他們發現讓所有的專案都納入系統是非常重要的(3)。“You can’t see the benefit until you get everything in the system.”另外,過程中必須讓對的高階主管參與導入流程並接受訓練。關於這部分,他們和高階主管有一段很有趣的對話。一開始高階主管對於加入很感興趣,並主動問小組成員:“我能做什麼?”和“這要怎麼進行?”而在了解以後則問:萬一我問錯問題怎麼辦?這是個很好的現象,因為這表示主管們認知到:如果問錯問題,將會引發錯誤的行為。對主管做訓練就是希望努力避免這個問題發生。最後,他們在核心團隊裡籌組專案辦公室來支援CCPM,確保大家採用這個不同的新方式來工作。

 

導入CCPM的過程中,他們做了幾件可以強化和鞏固改善的措施。第一個是不論什麼情況下都很重要的:溝通、溝通、再溝通。善用圖表、圖片、或任何可以提升溝通品質的媒介。再來,建立起回饋機制,讓小組成員負責對任何回饋保持警覺,以助於隨時調整和掌握事情的走向。還有就是建立短期的勝利,發表當下的成果、並和大家談論成果。(短期勝利可以激勵士氣,是讓改善走入正循環很重要的小撇步。)另外,他們做了一件事,每週四11:30所有的PM和任何想參與的人會聚在一起吃中餐和學習,由小組的伙伴進來談論他們在modeling過程中經歷到的事。最後,最重要的措施,就是將新方法制度化,讓大家知道這是組織執行計劃的方法。他們曾遇過會議中有人在嘟嚷著抱怨說合作廠商不懂緩衝而且全都弄糊塗了,並質疑為什麼要這樣做。他們的副總這樣回答:Sooner or later you’ve got to tell people, “Look, this is the way we do our planning.”

 

最後,引用project leader提出的Key learning來做結尾:

n          If you don’t have a high level “Sponsor” or “Guiding Coalition”- STOP!!

n          If you don’t have Project Leader Buy in – STOP!!

n          Commitment to planning is NOT the same as implementing CCPM – getting the commitment to do the planning is hard work

n          Define the roles and engage everyone from that perspective – developing ownership “buy-in” is hard work

n          Building competency cannot happen with knowledge of theory alone – you have to practice with real projects.

n          Create and rigorously apply, a multi-faceted sensing method for gathering valuable feedback – it’s the ONLY basis for implementation course corrections

n          Pilots for a CCPM implementation still don’t work

 

針對最後一點,project leader這樣表示:「我知道有很多人在談論pilot。我不相信pilot,這對我來說並不合理。你怎麼能找一個專案來試然後把它當作可以在多專案環境運作成功的證明?很難。你沒有取得你需要的所有資料。如果你決定要做關鍵鏈多專案管理,除非你讓所有的專案進入系統,否則你無法看到回饋。」

 

 

1Flow to the work,工作的流速,換句話說,就是讓已啟動的工作儘速完成。

2:在導入CCPM專案管理初期,導入部門必須先針對部門內的資源進行盤點,並以加快關鍵鏈完成速度的出發點進行資源功能群組的分類,在此基礎上建立資源分解結構。

3:把所有專案都納入系統,相對的作法就是只想拿一個專案做pilot run。這個議題未來可以單獨用一篇來聊。

(JOE: 上面備註的字體請維持正常大小)

 

案例來源:Realization Technologies