（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都有可能。
只是，若一旦大家覺得有需要，就該戒慎恐懼的執行。 找個內部最有政治實力的主管負責，輔助一個真正有經驗的人來分析與協助規劃(這部分也是我們常扮演的角色)。 開始之前，兩方一起好好的做整個企業的診斷與分析，然後制定出合適的執行路線。 因為不同的權力結構、不同的人員能力比例、不同的專案成熟度，都會影響做法與步調。 這些都完備了，才開始規劃不同程度的訓練課程。 這樣才會真有助益。
別忘了這句話：做這類事情的目的是讓事情更順利，而不是為了管理而管理。 如果做任何改革只是讓現實變壞，無論做法是否符合「標準」或「課本」，那都不重要了！
延伸閱讀
專案變革失敗的秘密
面對顧問，你該問些甚麼 – 布萊恩
專案管理的騙局？
