PMO系列3-為了什麼而管理?
♦作者介紹
作者：後藤年成Toshinari Goto；MSOL Inc, Senior Consultant；元嵩顧問管理股份有限公司 總經理
前言
我們將過去成功專案時所使用的管理指標或是管理表格，拿到現在進行的專案中使用，但卻不會考慮到適不適合。這樣對於PMO來說就變成只是一個簡單的“管理屋”或是“文件中心”，注意在制定的管理表格上有沒有遺漏的資訊罷了。
PMO的主要工作之一，就是要將各項管理計劃(Management Scheme)導入現有的管理。就是要將進度管理、議題管理、風險管理、變更管理、品質管理及預算管理等工作順利地導入到專案中。若是把「Management」翻譯成「管理」的話，語意上是有一點出入。為了讀者方便，以下我們還是用「××管理」來表達。
管理計劃是為了掌握專案時不可或缺的。PMO解釋管理計畫其重要性，縱使專案成員間能夠理解管臉計畫的重要性，但是要專案人員想要徹底執行時，問題就會接踵而來。
如何徹底執行課題管理或進度管理的規則？
舉議題管理為例的時候，管理上所定義的必要項目和思考方法，也會因人而異。議題狀況應該是要敘述成「啟動、處理中、結束」這麼簡單，還是應該細分成「啟動、事前準備、檢討中、簽合、結束」，光是想要用哪一個方式就覺得很困擾。對於議題管理的流程和表單，若是一股腦把標準導入，也會有作業上的人員反彈，所以在調整上需要比較多的時間。
說到進度管理，報告的表示方法也會有很大的差異。我們常常把工作進度用百分比的形式來表達，例如十個種類的設計書，因為完成了五個程式，所以算出來的進度為50%；也有用「預算消化率」去計算。(預算消化率：從預算開始日被消化預算的比例)，所以決定統一的進度數值的計算方法及調整是不可以或缺的步驟。
麻煩的是，高層對於專案完成度是用百分比的數值作為依據。但是我們會時常遇到在某個案件上報告「進度為80%」，幾週後的報告仍是「進度為80%」。因為不清楚剩下的20%是什麼樣的工作。為了要避免這種問題的發生，所以我們必須要決定使用哪種進度管理的作法。
增加專案現場壓力的「無目的管理」
為了讓管理流程一致化並且提升專案管理工作的進度與效率，我們常會使用專案管理方法論(methodology)，並且搭配過去成功案例的管理指標及管理成果物(管理表格等)來套用到新專案上。而PMO的職責就是，將這些方法論導入專案中，並且依這方法論的規則為專案找出適合的管理成果物，然後提供給目前專案使用。
然而在現實狀況中，我們常常不去檢討這些管理方法是否真的適合目前專案，就直接把管理流程方法直接導入專案中。如此一來，PMO就變成一個只是的管理屋，甚至可以說是一個文件中心，對於專案本身的改善並沒有任何幫助。
未經深思熟慮而導入的方法論與管理工具的情況，只是讓各專案負責人做出符合規定卻缺乏內容的報告。從各專案負責人的角度來看，PMO要求這些報告，只是為了鞏固管理權利，最終不得不被稱為「為了要管理而管理。」所以PMO必須深刻地思考「是為了什麼而管理」才可以。
而PMO要為了什麼而管理呢? 透過管理找出的資訊，並將它活用在專案管理上，最終一定改善專案本身。像是透過進度管理能評估工作的進度；議題管理能掌握造成進度阻礙的癥結點；風險管理能發先未來可能會發生的問題，並且能配合高層管理決策做下一步計畫。
下放決定權，需要確認界限
日本的企業管理文化中，被管理的一方對管理方有定程度的抵抗感。相對於美國的企業比較重視管理，日本企業的管理為了能迅速把管理決策傳達到第一線，會傾向使用由上而下管理法(Top-down Approach)。我們不能說美國的專案管理優於日本傳統的由上而下管理，因為日本的管理模式，比較不會有遺漏訊息的問題出現。
專案現場有一種特殊的文化，就是第一線執行人員不需要上層的指揮管理，就可以直接針對問題去做溝通並且即時解決問題。並不需要等待專案經理的判斷和決策就直接進行作業，這種高機動性的文化是企業的高執行力的特徵。
隨著專案規模的擴大，專案成員除了有默契的聘顧員工以外，還有中途轉職進公司的成員（日本公司文化都傾向雇用新鮮人而非轉職）、外包公司的人員，甚至還有海外成員參與專案的狀況。若把專案現場直接讓這些第一線人員做決策的話，專案將伴隨著極大的風險。
以資訊系統開發為例，專案成員都是大家所熟識並且也一起合作，平時除了有密切的溝通；晚上也常常一起吃飯喝酒。因此與專案管理有關係的部分，也會特別地去注意，這種情況下就不太需要什麼管理。
隨著專案的進行與設計工作的擴大，成員也逐漸增加，這時候的PMO就要為建立流程規範，因為PMO的工作突然暴增，所以要導入符合組織需求的流程規範的時間也變得非常有限。PMO的立場為了要捍衛制度而變得比較官僚，站在以前一起奮鬥的伴的立場來看，突然這樣按表操課的管理態度，多少會讓人有抵抗的念頭。如果專案就這樣繼續進行的話，依照經驗來看，應該執行到一半以後就很難掌握專案狀況，最後系統專案將以延遲或是預算超過而告終。所以應該要依照專案的需要來考慮對應的管理方式才行。