上次跟大家講到考完PMP後第一個該學的東西，是去熟悉一套PMIS。 學這東西有兩個好處。 首先，這讓你能更快掌握大局，另一方面它也提升你在預估、規劃、以及面臨變動時的反應能力。 所以這是任何有心想往專案管理繼續精進的朋友，首先該掌握的實務技能。

除了這兩大點外，學會模擬分析還有一個好處，就是能幫你盡快掌握案子管理上的重點。 比方說，能很快了解風險在哪裡、那些工作流程該調整、加速資料統計的速率，尤其能幫忙最有效率的收集專案資料，立刻看出全貌並分析關鍵問題。

講的誇張些，一個優秀的PM與平庸的PM最大的差異就在於能否很快地「掌握全貌」。

缺乏正統訓練的PM，常常整天忙得要死，到處救火，但卻越救越忙。 因為他們先少花時間去「見到林」，碰到問題常常一下子就鑽到樹的層級。 可是優秀的PM會想辦法讓自己能盡快看到大局，做出取捨後，抓大放小的優先處理那最緊急的20%事項。 (注意，20%事項未必指的是「問題」，有可能是該先做後續的規畫、告知利害關係人、訪談需求這類工作。)

以我自己而言，擁有這樣的技能確實對我幫助很大，也讓我在這十年的時間中能藉此參與各類不同的專案。 我直接參與過的專案類型包含高鐵、軟體開發、3D動畫製作、以及遊戲開發。 間接以顧問形式則參與過公共工程、高科技建廠、無塵室規劃、大樓建築、高科技研發、模具開發、主機平台遊戲開發、IOS以及手持平台遊戲、以及一些活動型專案。

每次我在外面演講或上課，很多人聽到這些經歷，都不免會好奇的問我：「Joe，你為何怎麼能在不同的產業中做切換？」

大家有這種好奇我可以理解。 畢竟在台灣大部分的企業中，PM的培養並沒有一個明確的流程。 以至於一個PM要能真正帶好專案，必須在技術領域待很長一段時間，甚至常常是技術主管轉任的。

但這不應該是如此，因為PM最終應該是個策略者，是站在高處告訴大家前方可能會如何的那個人。 只是因為大部分公司都缺乏好的管理制度，這個PM恐怕得靠自己去做一切事情 - 從預估工期、找到對的人做、了解各工作包到底是怎麼進行的、工廠洽談、跟客戶協商、BOM表拆解常常也都得自己來，運氣不好工作延遲了，自己甚至捲起袖子當RD。 也難怪惡性循環，會愈來越見樹不見林。

但專案管理的訓練與經驗應該是培養一個人的視野，尤其是要建立一種全方面管理思維。 我在之前寫過的一篇文章中提到，一個好PM應該要具備三大類十二大點不同的特質與技能。 (文章連結在此專案經理需求的特質 (上)  )

一個受過完整培養，具備這些能力的人，其實根本可說是個小型的CEO。 這樣的人才，就算轉換到不同的產業中，也能迅速掌握重點，並在一兩個案子後就能發揮作用。

事實上，不是我誇張，在國外很多高階主管確實可以跨產業的去營運。 最著名的例子，就是1983年賈伯斯把當時的行銷大師約翰史考利(John Sculley從百事可樂挖來成為蘋果電腦的CEO。  姑且不論後來兩人鬧不愉快分道揚鑣以及蘋果1993年後幾個決策失當而走下波的後續故事，但最少他執掌時蘋果的銷售額可是曾經從八億上升的八十億。 你說史考利有能力去設計電腦？ 他當然是沒辦法的。 但只要他知道如何在策略上進行思考、如何模擬他的計畫、如何與別人溝通及說服、如何跟技術人員一起合作、如何監控案子的過程，他一樣可以從飲料廠轉到電子廠，並帶出十倍營收的躍進。

這也顯示，在一個成熟的商業環境中，管理職未必得是由技術職逐步拉拔而成的。 其他另一個知名的例子則是1999年，葛士納因為財務專業從美國運通跳到IBM做CEO的案例。 既然CEO都可以跨產業了，PM也是有機會的。 專案內容或許不同，但只要有充分的經驗與訓練，還是能很快地掌握核心管理要素。

尤其若組織夠成熟(像我曾經去協助顧問的某些公司那樣)，願意把管理機制盡量做合宜的設計，PM在那樣的環境中要養成就容易得多了(這議題日後也可以再跟讀者分享)。 長期而言，我相信台灣也會有越來越多像我這樣，能有機會在不同產業扮演PM、以及PMO規劃經驗的人會浮現。

可是要這樣做，關鍵能力是甚麼？

以我自己的經驗而言，迅速掌握全局絕對是第一步。 老闆通常可以有耐心讓我先跟著一兩個案子，然後才會把責任真正壓上來。 所以在這段「摸索期」就得迅速掌握「關鍵問題」。 技術議題通常公司本來就有技術專業人才在負責，所以未必自己要一下子在技術上學到很細，但最少得知道專案目前的交付項目為何，工作包的工作平時都是怎麼做、為何這樣做、過程中可能有甚麼問題、以及目前專案管理的工作流程有哪些。

那要能清楚的掌握全貌，就得先有個完整的Schedule。 這是非常重要的一步，因為你才會知道整個專案的輪廓是怎麼樣，隨著專案進行我們在哪裡，又遭遇了哪些問題。 也可以檢視各類解法到底在Schedule全貌上產生甚麼助益。

第一次當然沒辦法自己來，可能得跟著技術經驗豐富的人照著傳統作法走一次。 其中或許有些不理想、有些分工不明確、有些交付項目切割不明確，甚至Buffer安排上有缺陷，但總之就先跟著走一次，盡快了解案子全貌。 以我而言，等明確跟著專案走過一遍，有一份自己的Schedule後，我就會清楚知道這類專案的管理重點為何、哪邊是規劃上可以強化的、哪邊是管理上的可能風險、哪些在程序上需要被把關、哪些PMBOK教的手法該倒入，又哪些PMBOK教的手法暫時不該使用(對，實務上若組織還沒準備好，有些流程反而要放緩。 20/80法則這裡也是通用的！)。

雖然只是跟著跑一兩個案子，技術能力我還是一竅不通，但受過嚴格PM訓練的人會知道該在哪裡平衡、BUFFER該放在哪裡、那些可能監控得緊些、那些得鬆些、專案組織的權責是否要調整、是否要追加某些監控點、哪些事情是否該提早確認、專案中的獎勵機制是否該改善、專案的KPI是否該重新設計。 這些若抓得好，加上能跟技術人員有些交情讓他們能協助你(也就是PMBOK中所謂Expert Judgment)，那案子不至於會走得太過離譜。

但除了看懂全貌外，另一個更重要的東西，是要從Day1就開始累積歷史資料。

歷史資料不單單只是課本中的一個名詞，而是讓一個PM能在一個環境生存下去的一大關鍵。 很多PM都會抱怨，自己沒辦法跟客戶、跟老闆、跟技術人員爭取到合適的資源(包含人、錢、及時間)。 但很多時候，PM自己手上根本缺乏談判所需的相關資訊，所以自然難以舉證。

而Schedule以及歷史資料，就是我們最好的武器！ 我自己的認知是，要當一個好的PM不但需要一個完整的Schedule，而且隨著專案過程中，更要有系統地把專案相關的歷史資料，比方說報價、報價基礎、合約、預算上限、資源單價、標準功率、工作的計畫工時、工作的實際工時、工作預計天期、工作實際天期、變更紀錄、變更的執行方式、風險、風險處理投入的資源與時間，等都盡量詳加記錄。

像我自己而言，若能跟隨一兩個案子後，我會累積一些歷史資料。 一方面我可以越來越少去煩技術人員，二來我甚至可以跟技術主管討論如何調整工作配置，讓事情能朝向更有利於專案的方向進行。 有時候甚至有辦法討價還價，舉證為何我的要求比他直覺想像更合宜…

我曾經碰過一件事，非常有代表性。 就是我跟技術主管爭論同仁在某個案子上到底該投入多少時間的一場論戰。 而最後大家同意照我的規劃進行，即是根據完善的Schedule規劃以及小心累積的歷史資料作為舉證所達到的效益。

但礙於這次的篇幅有限，這故事就待下一期再跟大家分享吧~!