大家或許好奇，到底甚麼是「專案管理成熟度」？ 成熟度高、與低又差別在哪裡？ 主管常有迷思，以為讓專案成功就給PM上上課就好啦，或覺得成功或失敗都只是PM一個人的問題。 但其實沒這麼簡單，專案問題其實多是系統問題… 本文就要好好談談，到底啥是「專案管理成熟度」…
<本文開始>
註 : 這篇是我對內部同仁的宣導文章，所以用語會比較宣導性質。
前文提到，我於2007年PMO成立時，定位了如下表所列的五大使命：
- 專案管理成熟度提升 Project Management
– 方法與知識 Methodology
– 時間與花費追蹤 Time and Expense Tracking
– 變異分析 Variance Management
– 資源管理 Resource Management - 製程提升 Process Improvement
– 查核監控
– 標準化 - 知識管理 Knowledge Management
- 組合管理 Portfolio Management
- 預備專案規劃 Backlog Management
不過，因為這些目標聽起來都很抽象，很可能不是所有人看了就能立刻理解。 所以我想花些時間，好好把這些到底是甚麼分享一下，也確保大家都能有相同的理解。這篇將先能跟各位同仁分享第一項，也就是「專案管理成熟度提升」這件事。
「專案管理成熟度」提升，基本上是PMO最核心的功能與目標。
但到底甚麼是「專案管理成熟度」呢？ 成熟度高、與成熟度低又差別在哪裡呢？
再談這部分之前，我們先回到專案這種活動的基本定義。 就如同我之前某篇文章舉例的，做專案就如同放牧山羊。 你有一條既定的放牧路線，但山羊們可不會自己走在直線中。所以做為一個PM得畫一個範圍並控制放牧的邊界。 確保山羊的行徑雖然在過程中似乎是散漫或搖晃，一旦偏離邊界就得導回正確路徑，以確保最終大家能走到終點。
所以一個PM最基本的需求，是整合團隊，確保專案目標能被達成。
換句話說，Deliver the Result！
但組織要存活，光僅是如此並不足夠。 任一專案在第一次做的時候，通常是慘無人寰，一堆問題、加班到人仰馬翻，每天在痛苦中度過。但企業若希望靠執行類型相似的專案來獲利，就得降低運作的風險，不能讓每一次進行時案子都充滿不確定。 所以呢，所謂提升成熟度，就是讓組織能控制的層面增加、減少不確定因子。
一般人常會以為，要讓專案成功就給案子的PM上上課就好啦。也常常以為專案的成功或失敗都只是PM一個人的問題。
但這是個很嚴重的誤解。 因為通常組織的專案成熟度低落，其實多是「系統因素」造成的，而非一定能跟PM能力畫上等號。 舉例來說，專案若用上最好的PM、可是團隊極弱甚麼事情都不會下，進度又能好到哪裡去？就如同帶著小學生去參加國際科學實驗比賽，就算其中管理與規劃得再好也不表示能如期交付結果。
其他常見的因素還包含：主管間對於需求認知不同。 這會造成PM無所適從，或是不知道該把和目標做為優先順序。或是組織架構設計不當，讓PM會無法有效掌握並管理資源。 或是組織獎酬員工的標準跟專案目標牴觸，都會造成專案目標跟人員間的不同調。如此，只要這些因素無法排除，PM就可能得很辛苦才能凝聚團隊以達成結果。
總之，組織的「專案成熟度」要提升，不單單是PM的工作，而其實得透過下面幾個面向的共同提升：
專案經理的經驗、技術、與管理知識增加
這是最基本的需求。 畢竟PM除了產業知識以外，還是需要了解管理的知識與技巧，而管理工具的使用也是該有技能。所以我在這幾年間，陸續在內部開設了幾次「專案基礎概念」的課程。 課程不但提供給現任PM、也一直希望有興趣的同仁能主動參與。因為就算你還不是專案的負責人，能稍微了解一些術語或是粗淺的管理技術其實是有益無害的。 畢竟日後有可能升職、也有可能需要跟PM團隊合作，總是會需要接觸這些東西的。
組織成員的技術能力提升
如果參與專案的成員技術能力無法達到一般水準，這在過程上將增加很多的溝通成本、拉長製作時間、也增加各環節可能出現的錯誤與風險。 但這部分在目前台灣的環境下或許還需要時間來累積。畢竟創意產業中，有豐富經驗的技術人才(或執行人員)相對較少，常需要長時與經驗的磨練。所以技術能力的提升，這也將繼續仰賴各技術部門的主管加以培育。
足夠有經驗的管理團隊
管理團隊指的並不單是PM團隊，而是公司中「所有中階的管理階層」。 案子規模大時，中間的Leaders將需扮演很重要的力量。 比方說，問題的癥兆的辨識、跨流程的溝通、人員的訓練、機會教育、還有流程的具體規畫，其實都需要中層管理者的努力。甚至心態上，中層主管更需要不斷的挑戰既有做法，持續考量「如何能讓同樣的事情更快更好」。 這些流程優化的工作，也都須仰賴中層管理人員的知識與認知。
所以長久往下走，我也希望跟HR等單位合作，一同安排各中層管理人員適當的管理培訓。 另一個重要的目標，是希望培養「中層管理者的接班計畫」。任何一人被拉拔到小組長時，他/她其實就該自己開始物色下一屆的接班人選。 唯有這人選能達到跟自己一樣的成熟度時，自己才能往更高一層晉升。這樣才能確保中層的中流砥柱不致於在升遷時斷炊。
標準程序的建制
當大家有能力把事情做好時，就有把程序標準化的價值了。 有些組織過早推動標準化或SOP這件事情，這將會造成事倍功半。因為若人員對於做事方式尚缺乏共識時，推動標準化不但困難、而且對於運作正確度的提升也常沒有幫助。 所以必須等人員能力足夠、且搭配常用的工具與做法下，才能把流程定義並引為規範。
而且，如之前文章曾經再三強調的。 SOP一般分成幾塊，比方說，製作上的流程，以及管理上的流程。 以目前SOFA為例，我們有製作團隊必須知道的工作流程。 如怎麼透過Alienbrain開檔案、存檔在哪裡、何時該Checkin/checkout、製作上的步驟等。 但也有所為管理上的流程，比方說有人提出要加東西該怎麼辦、某人回報工作完成後該幹嘛、判斷有可能出問題時該如何處理等。這些是必須陸續強化並落實的工作。
而且，流程將會隨著時間演進、工具變換、人員能力提升、甚至組織變動而加以調整。 這也是為何中層管理者的能力如此重要，因為他們將是第一線把關流程的人。 他們若對於流程覺得不佳時，必須要能提出改善的方針，如此才能讓事情不斷的往好面向加以調整。
不斷提早的反應能力
這比較類似小時候做實驗Trial and Error的概念與精神。 在專案執行中，大家必然會察覺某些問題的發現其實應該可以往前提早。尤其時間通常是專案上最最寶貴的一項資源，若能早期發現問題，往往就有比較充裕的時間解決，也往往有比較多的選擇來應對。 比方說，以目前MuMuHug的製作為例，團隊因為對於某些設定是否可製作會有理解差異，就會有Storyboard畫好後大家才發現很難製作。當第一次碰到這問題時，一方面大家當然得先解決問題，再來也就會一起探討如何改善流程，以盡量避免這類事情到很後期才發現。 目前嘗試的做法，是在劇本寫完後先讓後面製作團隊進來檢視一遍；而Storyboard到達一定進度時，也邀請相關的Supervisor一起檢視。這也就是希望能讓問題及早發現，避免時間浪費、也避免讓同仁做白工。
歷史經驗的累積與流程改善
知識傳承是另一個提升成熟度、增加效率、避免重工的重要關鍵。 包含收集大家的做事方法，將其文字化、並存放在統一的平台上。 把經驗落實成文字，將能有效確保當任何人需要或是下一次專案要展開時，團隊成員都能取得相關訊息。
此外，自去年開始，SOFA目前所有完成的專案，PM都會做一份結案分析報告。也因此，目前已累積了一系列對於類似專案如何更好的沈思與建議。 接下來一年中，我也會適度安排一些討論會議，讓主要的管理成員一起討論這些內容。 也希望我們能透過過去的不足，轉化成讓未來更好的契機。
對專案成功的共識
這比較是公司方向的認知與認同。 專案管理的基礎，是整合住所有人以便讓事情成功。 但公司這樣的組織，往往還要追尋更多的東西，可能是最好的產品、可能是最賺錢的產品、可能是最節省的開發過程、可能是快速搶佔市場、也可能是培養團隊能力。但到底何者最重要？這有時候可能就會意見分歧了。 但這些目標都沒有好與壞的差異；只是組織要順利前進，取捨以及最大公約數是必須要能有的。
這其實是提升成熟度最後也最關鍵的要素。 畢竟大家要知道共同追求的目標到底是甚麼？ 不然每個人力量分歧下，最後只會充滿挫折的；人人覺得自己都是為了長期目標好，可是怎麼別人都不認同。這其實就很危險了，因為一旦目標分歧下，最後反而會因為互斥的力量造成停滯不前，甚至造成人心渙散。
以上，列出了我認知要提升「專案成熟度」的所有要素。 組織在剛成立時，這些要素通常都缺乏。 也因此，案子必然將碰得頭破血流的才能順利結案。但當PM第一次整合不同領域的人員，並把東西交付出來之後，接下來的目標才該是轉化成希望省錢、希望快速完成專案、或是希望能把原來繁瑣的流程加以簡化。
此外，透過上面這些幾點大家也可看到，要能達到任何一個更高的成熟度(省錢、快速、簡化流程)其實需要很多條件的同時提升。 這也就是為何集團需要整合性的規劃與協調，確保所有面向都共同有在提升；這也又一次說明為何專案成功並非只是PM的事情，而是所有管理者需要共同投入的事情。
畢竟，一旦專案失敗或是沒能達成目標，其實也是「所有人」都難以逃避的。 好吧，就算沒政治責任，失敗了對誰其實也沒好處吧？ 專案成功才代表公司有營收；公司沒營收，自己恐怕也很難有前景啊。這也是為何我會一直持續的疾呼，希望大家能多學習專案知識，並能共同以讓案子成功做為思考的方針。 這些絕對是幾個專案導向公司(SOFA及KGS)往下走，最要緊的關鍵能力啊！
延伸閱讀
PMO的目標與願景
What is PMO
不能心電感應，所以這麼做.. (圖多)
流程系列五之 專案流程的重點在管理而非方法
