你的組織有需要PMO嗎?

你的組織有需要PMO嗎?

(Photo by fauxels from Pexels

專案管理這件事情因產業需求終於慢慢開始受到了重視。 不過可惜的是,在台灣很多單位還只是一種跟風的流行。 前幾年大家比賽考PMP,後來企業發現個人證照對公司經營的實質幫助有限,所以這兩年PMO也開始「受到重視」。 周圍開始有些朋友來問我:「我該去上某單位辦的PMO辦公室課程嗎?」。 也有人問我:「我們公司成立PMO並派我去規劃,可是我到底要做甚麼?」,或是「我被指派研究一下PMO成立的事宜,你有甚麼表單可以給我用?」。

看了這狀況,不免讓我又憂心起來。 數年前我寫了篇「你該去考PMP嗎?」、前一兩年我寫了「專案管理的騙局?」都是在談這類一窩蜂趕流行下大家該反思的問題。 畢竟我的觀念一直是這樣的:如果我們做某些事情,必然是希望那事情有用,而不是花了時間心力只是做做表面功夫

我覺得管理的舉動其實都該像武俠小說一樣 - 要練內功而不是打起拳來徒有形狀就好。 畢竟練武的目的除了強身以外,就是要上了場能打贏對手,而不是為了上台表演。 專案管理也是一樣,能真正解決大小問題的知識與思維,應該比會背流程、講要點來的更重要。 既然個人學習知識該以實用來思考,組織規則就更應該是這樣,而不是做了繁文縟節,可是對組織營運毫無幫助。 也因此,讓我興起了今年開春第一篇,或許應該來談談這個問題:「你的組織有需要PMO嗎?」

我一方面想解釋一下PMO真正在幹嘛;不是教科書上講的那種,而是很現實面的那種。 另一方面,我也想談談很多人從來不知道的一件事:組織需要多大勇氣才該跳入做這件事。 雖然我猜那種真正背後大老闆會看到這篇的機率微乎其微,但若你是個「正直上進」的年輕人,剛巧若你的老闆從哪個研討會聽了甚麼「有PMO你的公司能突飛猛進」而要你去研究一下PMO時,你最少能透過這篇文章了解自己該如何謹慎與小心。 甚至你或許有機會偷偷提醒一下你老闆:「為了達到那目的,你到底願意犧牲多大?」

是,沒錯...「犧牲」。 我用的確實是犧牲兩字。

宇宙遵循著某種質量守恆定律:要得到效用,就必須付出一些甚麼。 而專案管理與PMO建置(這其實常常是另一個議題,稱做企業專案治理)這件事情,絕不單單只是付出時間、送人考幾個證照、或是找個熟讀PMBOK來的人就好。 企業專案治理,需要的其實還有更多其他的東西…

但在談那個「其他東西」前,我想先從PMO的定義談起。

教科書上對於PMO的定義我這就不多說了,有興趣的人請自行Google一下,或去一些補習班的網站都可以看到那些定義。 我不會說這些定義是錯的,但我要提醒一件事情 : 企業導入專案管理甚至專案治理的本質到底是為了甚麼?

為何最近這十年專案管理這議題慢慢開始受到重視? 實在是因為目前很多企業的獲利模式起了「根源的變化」。 以前一台大同電鍋可以賣30年;但現在一支手機出現到下市可能不過三個月。 案子Time to Market的壓力變大了、產品生命週期變短了、以致於進度與成本控制必須更準確。 此外,越來越多非標準化的案子出現,每個案子的技術需求越趨複雜,幾乎的案子都需要跨部門的眾人一起合作。 換言之,事情無法再是單一部門處理,而必須有人橫向的來整合各功能部門。 這是專案管理於各企業中需求一開始的起源。

再來,企業專案數量大增下,可是各PM手法不同、能力不同,造成老闆無法看到整體全貌。 於是,自然就會有些老闆發現,企業其實需要有個辦法把製作流程串接起來、需要有人橫向控制原本各行其是的功能部門、需要有人制訂統一的管理方法與資料架構、需要集中式的資料累積、或需要客觀的監控機制。 這時候,成立一個中央主導的PMO,才會有具體價值。 (換言之,如果你公司沒有上面幾點需求時,成立PMO其實沒什麼意義。 但如果你的公司開始有企業專案治理的問題時,有個中央統一的單位,也變成理所當然的事情了!)

講起來很簡單,可是我得說,我這幾年真的碰到很多朋友來問我「若要建個PMO,部門目標該寫甚麼」這樣的問題。 我每次都覺得訝異。 因為會問這問題,表示你的組織似乎根本沒有想清楚這整件事情,才會無法定義目標。 因為如果專案成功對你的公司真的這麼迫在眉睫,老闆應該會很清楚自己最大的目標是甚麼 → 也就是打破一切既有規定,重新設計一個適合專案環境的組織架構。 簡單的講,企業專案裡的導入、以及PMO的建立,其實就是一個「重新塑造你企業內部Value Chain」的過程。

這也就是為何我一開始會用到「犧牲」兩個字。

你想想,原來你的單位可能各有山頭,專案若要跨部門時阻礙重重。 這情況你該怎麼辦? 買套專案管理系統,原來不支援別部門的老大們突然就會挽起袖子跟大家一起操作軟體? 讓大家都考上PMP,對那些專案成敗不影響年終考績的員工,就會因此熱衷起規劃與排程嗎? 或是成立一個專案辦公室,然後大家大拜拜的聚集宣誓一切要以專案為重,大家就會突然醒悟專案的時限與成本很重要的嗎?

你我都知道,這樣的事情根本是不會發生的。

正常的PMO,其實選甚麼手法、以及Know-how影響成敗只佔不到30%,政治與時機才佔成敗影響的70%以上。 說的極端點,PMO成立其實應該是一種老闆表示他有強大內部改革決心的展現;表示他願意根本且徹底的重塑整個組織架構 → 上從策略目標、中到組織結構、下到出勤規則,都願意為了「專案成敗」而配合調整。 只是遺憾的事情在於,很多人誤以為PMO只是一個新部門。 也「誤以為」專案問題是個「獨立的議題」,以為只要有個專業部門成立後,專案問題自然會解決。 但是若不瞭解專案治理的改革往往必須得是「整個系統改革」下,那PMO就將會如泡影一般。 引導這部門的人若沒有強大的政治資本、缺乏逐步強化的Know-When,那負責PMO的人也將很快失勢下台。 (對此議題有興趣的人,建議也可以看一下我曾經寫過:專案變革失敗的秘密那篇文章。)

但我也要跟大家道歉,因為對於如何成功與平順導入一個PMO(甚至深化專案管理也一樣),我至今沒有單一簡單的方法可分享。 因為每個組織有不同的問題,也有不同的需求,都得量身訂做才行。 我自己的經驗是,往往得花很長時間跟老闆談、跟各專案負責人談,來揣摩需求。 如果公司規模大,甚至還要花三個月到半年以上摸索組織文化、以及各種檯面上與檯面下的規章制度與權力分配。 等這些都搞清楚了,了解鐵板哪裡最薄弱、組織哪裡可動手,才能開始設計規劃。 若這些沒有掌握,貿然急忙就先做了再說,那最後很可能結果悽慘。

OK,雖然我沒有簡單的特效藥;但最少我可以告訴你,怎麼樣運作的PMO一定會失敗。一定會失敗的PMO通常都有三個特徵。 若你公司也有PMO,你可以檢視一下他們是否也犯了這幾個錯誤:

1. 試圖直接照抄別人的方法
這包含抄書、抄別人的表單流程(IBM的、HP的、其他世界知名大廠的等)、抄世界規範(PRINCE2、PMBOK、OPM3)等。 我不是說別人的東西有問題,事實上別人的經驗一定都有價值。 唯一的問題在於,照抄者往往不知道這些方法、表單、與流程背後制定的原因以及試圖要解決的問題是甚麼。 而且,別人的組織跟我們的組織必然有所不同;對方可用的,我們直接拿來可能就會卡住。 就像同樣是患感冒,也不表示我就能直接拿別人的藥來吃是一樣的。

此外,更重要的是,照抄者往往只知道別人做某些事情,卻不思考做這些事情對你的組織是否有幫助? 舉例而言,專案規劃很重要。 可是真正重要的是規劃(動詞)這件事,而不是產出的規劃書(名詞)。 有些PMO不思考怎麼讓專案大家真正動腦規劃,而只注重要得到「符合PMBOK架構的計畫書」。 那可想見,最後大家就是找個部門閒人做Paperwork(像ISO那樣),可是重要的專案規劃還是不存在。 那你想,這種導入最後會有任何成效那才有鬼呢!

2. 先送大家去考證照
我一直覺得PMP是工作數年以上,對於專案狀況已經有點心得的人,才該去考的東西。 一個根本沒有專案經驗的人,上這類課我老覺得是秧苗助長。 不是說學知識不好,而是大部分的班要不注重考照、要不就是只注重背誦「標準流程」。 但PMBOK開宗明義就說,作為一個PM,你要有能力去判斷書中哪些流程是你這案子上必須、哪些流程是可以簡化、哪些甚至是不適用的。

可是來上課的人都有能力判斷哪些流程需要、哪些流程可省略嗎? 實際必然不是這麼一回事。 因為來上課者可能公司內各等級都有,有可以判斷的主管階層、也有根本沒做過專案的新鮮人。 這樣大規模的談這類無法立刻使用的東西,就必然有害無益了。

因為大家上完課後,雖然「看似」學了一堆Best Practice,但若沒有足夠的專案經驗,往往只學了皮卻不知其意。 九成的人上完課後,ㄌㄠˋ術語變得很厲害,可是真叫他做個WBS或是排程,卻又只能做出個跟實際狀況完全不搭嘎的東西。 大家學會術語,但往往認知並不正確,反而更增添了日後溝通的困難。 更增添了日後PMO要統一作法的困難度。正確的步調其實應該反過來,公司應該先有統一的規則與流程。 然後才送有幾年經驗的同仁去考試,讓他們知其然也知其所以然。 這樣才能降低統一規則推動的阻力。

3. 急著甚麼都要
另一個常見的盲點,在於不能抓大放小。 書上對於PMO有很多標準的制定,大型的跨國公司PMO甚至可以定出幾百張表單(我手上就有好幾份這樣公司的Template),數百頁的管理規則。 但是你需要一下子出現幾百種表單嗎? 你的內部不會抗議、不會反彈、不會失焦嗎?

以我自己的經驗來說,除非是很資深的團隊,不然我一開始往往只要求兩張非填不可的表單 → Charter以及Changer Order Form;至於基層同仁只要每日回報工時單就好。不過PM我倒是要求他們要在開案前做詳細的專案規劃。 重要案子還會跟著他們做過一次沙盤推演。 (Susan留言後,增加這段補充) 其他PMBOK裡頭列的甚麼12表格之流,我全不要求。 為何? 主要在於組織若沒有那樣的成熟度,你要大家做甚麼風險分析表,最後大家也還不是應付了事。 反而徒讓沒經驗的一般員工認為專案管理就只是做Paperwork。 既然沒有任何好處,何必浪費大家時間?

這也是為何我會提說那些一下子想一步到位的,必然會遭受組織慘烈的反撲。 大家會質疑做這些事情的目的在哪裡? 反而就讓整個改革失焦。

結論
我要再提醒一次,你的組織若想導PMO,那你最需要思考的是「到底改革要到甚麼程度為止」。

換言之,組織必須要對此推動採取非常非常非常謹慎的步調。 不要急、也不該隨便。 因為要把這當成「如何讓組織轉型的生存根本」來看待。 有人或許會覺得,這樣會否太誇張了? 但真是如此,最高層主管應該先要做個全盤的討論。 了解彼此對這議題的看法為何,甚至最後選擇根本不需要PMO都有可能。

只是,若一旦大家覺得有需要,就該戒慎恐懼的執行。 找個內部最有政治實力的主管負責,輔助一個真正有經驗的人來分析與協助規劃(這部分也是我們常扮演的角色)。 開始之前,兩方一起好好的做整個企業的診斷與分析,然後制定出合適的執行路線。 因為不同的權力結構、不同的人員能力比例、不同的專案成熟度,都會影響做法與步調。 這些都完備了,才開始規劃不同程度的訓練課程。 這樣才會真有助益。

別忘了這句話:做這類事情的目的是讓事情更順利,而不是為了管理而管理。 如果做任何改革只是讓現實變壞,無論做法是否符合「標準」或「課本」,那都不重要了!

 

延伸閱讀
專案變革失敗的秘密
面對顧問,你該問些甚麼 – 布萊恩
專案管理的騙局?

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。