我在「專案管理雜誌」到目前為止已經發表了六篇文章。 雖然這六篇文章談的好似各不相同，但其實目的都是要跟大家分享一個很大的議題：「考上PMP之後要怎麼繼續累積自己的價值及實力。」

這系列一開始就提到，若要累積自我的價值，建議大家最值得投資的，是趕快學一套PMIS(Project Management Information System)。 這東西若能學會，就能輕易地做專案的「兵棋推演」，以增加自己在規劃、舉證、分析變動的影響、說服專案利害關係人、以及掌握整體局勢。

PMIS也是一個能把PMBOK相關知識最有效呈現的介面，或稱為「專案知識的載體」亦可。 讓你可以把抽象的管理概念，化成一般人也能看懂的數字與圖表，做為你(專業經理人)與一般人溝通的橋樑。 我一直相信唯有同時具備「知識」又懂得「使用工具」的PM，才能輕鬆有效地在實務上解決問題。

再來，我也建議大家，當能善用任何一種PMIS，要常態性地透過PMIS來做專案規劃，並「收集」專案的實際狀況。 一來，實際狀況與計畫差異的比對，能成為自己Lessons Learned的起點。 二來，好的PM更在工作中慢慢累積自己的「歷史資料庫」。

「歷史資料庫」包含了各工作包的作業清單、歷史工期、相關補充的文件、工作所需要的資源以及資源等級、甚至資源的工作能力等各項會影響日後規劃(或投標、或提案)的數值資料。 這讓我們日後在面對客戶、老闆、或其他部門主管時能更有談判的籌碼。 也讓我們在面對爭議時更能夠清楚舉證。 畢竟這才是我們希望專案管理這知識帶給我們的效用：讓我們可以更專業、並可以理服人。

為了能讓讀者更容易體會這概念，我在第六篇文章中也舉了我自己如何靠這些歷史資料與技術主管討論專案規畫的經驗。 畢竟沒有技術背景的PM，如果連數據都沒的話，那就根本不可能跟RD或是相關技術人員協商啦。

下一個我想提醒的，就是這次的主標：「不要迷信單一方法」。

這是甚麼意思呢？

我碰到很多人，不斷地在苦惱，因為他們總以為「自己沒學對方法」。 好不容易考完試、拿到證照後回到公司，卻發現考試前、考試後專案的問題差不太多。 或是明明組織成熟度還不夠，卻仍然強把一些表單跟流程逼著別人配合。 最後自然就是在跟組織碰撞下覺得挫折。 他們通常不服氣，覺得可能是方法不好，以為可以再找到另一種「密技」。 深信只要自己能學會新密技後，專案就將一路平坦。 所以就不斷尋覓、不斷嘗試，但偏偏卻又不斷失望。

這實在是因為「管理」並不是物理科學，不是用個公式、把相關變數套下去結果就會相等。 管理學涉及的大多是組織議題以及解決人的見解差異。 雖然各類管理知識有很多方法與技巧能讓我們防患於未然，但你在套用的同時卻還是必須考慮「環境變因」(也就是PMBOK裏頭提到的Enterprise Environment Factor)以做臨場的人為判斷。 所以就算是同樣手法，套用在不同組織、不同的專案環境上、由不同的人在執行，結果都可能迥然不同。

事實上，這概念在PMBOK就開宗明義做過類似的警告！ PMBOK提到書中內容是所謂的Good Practice，而Good Practice的含意則有這樣的說明：

“Good practice” means there is general agreement that the application of these skills, tools, and techniques can enhance the chances of success over a wide range of projects.  Good practice does not mean the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project. (PMBOK 4^th Edition, Page 4)

對於英文不是很好的讀者，我也在此放上中文版的翻譯：

優良實務並非意味著本書所描述的知識，必須一陳不變地被應用於所有專案上；組織或/及專案管理團隊應負責決定何種知識適合個別專案之所需。 (專案管理知識體系，第四版第四頁)

所以很明顯的，PMBOK認為PM或是組織的管理團隊，其實擔負專案成敗很重要的責任。 畢竟管理書籍能提供的都只是原則以及建議，唯有管理者，因為熟悉他所處的環境，所以在面對問題時，必須花時間與心力去判斷用甚麼手法、技術、或是知識，來解決這類問題。

這並非是我胡亂詮釋喔，因為在同一頁的下面一段，PMBOK寫說：

As a foundational reference, this standard is neither complete nor all-inclusive. This standard is a guide rather than a methodology. One can use different methodologies and tools to implement the framework. (PMBOK 4^th edition, page4)

中文版的內容：

作為一個基本的參考書籍，本標準既非周詳完整，亦非無所不包；本標準應被視為是一種指南而非方法論。 讀者可運用不同的方法與工具來實行這個架構。 (專案管理知識體系，第四版第四頁)

這裡特別要強調Methodology這個字。 中文一般把這翻譯成「方法論」，通常是一個用來解決具體問題的標準手法。 舉例而言，變更發生時，該透過哪些步驟來處理。 這樣的遊戲規則就會是一個方法論。

可是PMBOK裏頭寫的內容大多不是具體的執行方式，只是「你應該要有變更管理的機制，而且這些機制該掌握甚麼原則」，真正使用還是要有人把這些「機制」設計出來。 而要設計出來，就還是得思考專案的特性、團隊的成熟度、組織的文化、組織內有哪些技術可用、利害關係人對此的態度、以及其他Enterprise Environment Factor。 這樣設計出來的機制才是具體可行的！

為何花這麼多篇幅強調這概念呢？ 因為如果你不清楚「指南」與「方法論」的差異，你就會鬧出想把PMBOK完整導入公司內的笑話。 但以我們這麼多年的經歷來回顧，指南絕對是無法當成管理手法的。 這也是為何僅考上PMP並不表示就是個完美的PM是一樣的！ 只是成為專業經理人的起點罷了！

很多人讀到這裡可能會想，那我是否可以找個「別人的方法論」來套用呢？

這通常也不可行。 因為你若沒有先把別人的環境都搞清楚，很可能根本不知道這些管理手法是否全都適合你。 就算其中有部分合適，你也還是要針對自己的環境再做些裁剪與調整。 舉例而言，最近一窩蜂人在瘋Agile也是類似的例子。 就算同樣是軟體開發的產業，也還是有規模差異、工作模式差異、接案或是做產品的差異。 你若是接案的SI，除非業主配合，不然用上Agile的機率是不高的。 就算是自家的產品開發，提出需求的User若不願意完全地配合方法，最後也很難有成效。

所以呢，我建議大家與其一窩蜂地想抄別人，還不如多培養自己的能力，多學會各式各樣不同的方法。 然後配合情境，選擇合適的方法，這可能才能最有效地解決問題。 因為不管是哪種方法，都不可能毫不修改、完全無痛地套用在任何環境的。 差異僅在於：看你是想改方法還是改環境，總有一方要改的。 而且還需要長時間的堅持以及不斷的行為修正，最後才會看出成效。 如果我們只是像游牧民族一樣，一個方法試過一個方法，那必然也只會感受到一次又一次的失望。

我一直覺得PM其實就如同一個小型的CEO一般。 若你能在當PM的階段全面地培養自己管理的知識，總有一天，你能成為組織的重要核心幹部的！ 可是在此之前，你得培養自己宏觀的視野、管理的思維、以及面對變動的態度。 如果只是死心眼地想找一個萬試萬靈的方法，那不但你在目前的位置會做得很辛苦，將來你的升遷空間也必然很有限(因為換了環境、換了位置，你可能無法換腦袋)。 這就失去學管理的意義了啊！