最近，我再次仔細閱讀了《專案管理知識體系指南》（PMBOK）第六版的內容。我想深入研究當年未能理解的內容，希望能從現在的視角激發新的想法，同時也為我部門建構專屬的「專案管理體系」奠定基礎。建構此體系已是我近一年的目標了，旨在規範化專案管理流程，並優化專案效益。
現在回想，在缺乏這份文件的情況下管理專案，確實遭遇了許多問題。儘管最終專案都成功交付，卻也付出了許多慘痛的教訓。今天，我將試著分享我從中學到的教訓，以及目前我是如何間接地補足專案章程所應具備的內容。
我所管理專案的性質
我任職的公司主要為客戶提供軟體開發服務。這表示當有客戶需要開發獨特的軟體時，我們公司就會為他們提供相應的解決方案。因此，我所負責管理的專案，其成立的主要理由就是提供服務。
這類型專案的規模差異極大，有的客戶要求完整的解決方案，以協助其改善業務流程；也有部分專案僅是對現有系統進行微調，以配合客戶最新的政策。儘管專案規模不一，但有一個要素是所有專案高度一致的，那就是合約類型。所有公司與客戶簽訂的服務合約類型都是「固定總價」合約，這意味著一旦專案管理不當，將可能導致虧本為客戶執行專案。
以上便是我所管理專案的背景。接下來，我將介紹過去在管理專案時，曾經遭遇的一些困難。
缺乏專案章程的困難之處
缺乏專案章程，意味著你在專案開始時，只能摸黑前進。
欠缺對專案最基本的理解
正如《PMBOK指南》書中所述，專案章程實際上記載著專案的高層次資訊，例如專案目的、客戶最基本的需求、預期效益以及主要利害關係人名單等資料。在上述所有資訊都付之闕如的前提下啟動專案，基本上就如同你在對戰場環境一無所知的情況下，被推上前線並被要求指揮作戰。試想，在這種情況下指揮作戰，會是何種感受？
我過去在接到這類專案時，通常只知道客戶需要開發一個「某某系統」。隨後，我就被派往客戶端，與他們一同展開專案工作。如此開展的專案，必然會被客戶牽著鼻子走，任由客戶更改方向卻渾然不知。
難以動員人力
專案工作並非單靠一人就能完成，它需要不同人員協同合作。因此，身為專案經理的我，必須請求其他同仁協助。然而問題在於，公司其他同事根本不知道有這個專案需要處理，我本身也沒有獲得正式授權來調動其他部門的同仁（例如開發、系統設計、測試人員）。因此在專案初期，我幾乎是發揮自己多年開發人員的經驗，親自下場參與！無論是需求收集、方案設計，還是系統原型圖繪製等，都只能親力親為。
在親力親為的同時，我也需要發揮自己的影響力，向各部門經理說明專案內容，請求他們能調動同仁協助。當缺乏正式的任命時，將難以有效調動同仁；或者同仁會因為各種理由，優先處理直屬上司分配的任務，而忽略專案任務。
成本控制成為奢望
身為承接專案的廠商（或稱乙方的專案經理），目標當然是透過專案協助客戶（或稱甲方）達成其目的。然而，這不代表我們公司沒有自己的立場，也就是說，公司通常都希望能透過專案賺取收入。當沒有專案章程時，身為專案經理的我，就難以得知專案預算究竟有多少。換句話說，我無從得知公司在規劃承接這項業務前，他們對完成專案的預算評估是多少？公司能從這項業務中賺取多少利潤？
由於缺乏成本資料，我在管理專案時，曾嘗試兩種極端做法：其中一種是「最小化支出」，務求將工作量減到最少。因此，客戶大部分的需求都被我刻意拒絕，或是將需要開發的功能減至剛好可用的程度。這樣的結果可想而知。另一種極端做法是「客戶是上帝」，只要客戶有任何需求，我都毫不協商地直接安排實現他們想要的功能。這樣的結果雖然讓客戶沒有不滿意之處，卻讓公司賠錢為客戶執行專案。
在缺乏專案章程的情況下管理專案，並不只有以上三個困難，但我個人認為這些困難足夠深刻，也是我在早年學到的教訓。
如前文所述，現在公司也沒有高層重視「專案章程」這份文件，那麼現在的我是如何展開專案，以規避上述的困難呢？以下是我的一些方法。
缺乏專案章程的自救辦法
「機會不會自己敲門，除非你建造了那扇門。」— 佚名
如我前面所述，公司「選擇」承接業務，一定有其評估和考量，只是這種考量可能沒有集中反映在一份文件上。更多的情況是各種不同的資料分散記載在不同的文件中，只是自己不知道而已。
從招投標書切入
由於我的專案是從客戶端發起，因此客戶必然會有展開專案的理由，否則公司應該是接不到案子的。招投標書是一份從客戶角度撰寫的文件，其中必然會記錄客戶展開專案的理由。例如他們為了什麼原因要採購一個軟體（專案目的）、他們需要這個軟體具備什麼功能（主要交付項目）、要求能在多少天內完成（進度計畫）。只要我能拿到招投標文件，就能從客戶的角度對專案作初步的理解。
如果公司沒有人主動發送招投標書，也不代表就沒辦法取得。首先，我不可能無緣無故當上一個專案的專案經理，我必定是受直屬主管或相關上級指派。因此，只要我能說明需要這份文件的原因，並有禮貌地向他們索取，我相信他們都會提供。不然的話，我又怎麼可能完成專案呢？
方案建議書是我方的回應
有了招投標書，相對應的就是我方答覆客戶的文件，通常這份文件就是《方案建議書》。方案建議書上會詳細記錄公司是如何看待這個專案的，將會為客戶提供的方案有哪些（可交付成果），專案大致的時間安排（總體里程碑）等資料。透過這份文件，我能對未來專案需要產出的項目和初步的時間安排有所了解。
此外，編寫方案建議書的同事會對所提供的方案進行初步的成本評估，無論他評估的方法為何，我也能從他口中或主管口中得知專案預期成本和效益。在得知這些資訊後，執行專案時就能知道哪些需求在成本內能夠完成，哪些需求會超出預算，需要與客戶協商替換了。
進行內部專案分享會議
現在我接受專案後，會要求編寫專案方案的負責人為我和各職能經理，先行說明專案的內容。包括客戶的要求、方案的詳情和其評估依據、概要的成本和預測的效益等上述資料。更重要的是，透過這個會議，我能讓其他部門的主管得知公司已經承接了這起案件，並且讓他們知道未來需要的人力資源和所需期間。這能降低我在未來向他們獲取資源時的阻力。因此，請務必要求相關部門的主管參加，即使最終他們真的沒有抽空參與，也必須把會議記錄發到他們的電子郵件中，並請他們留意。記住，目標是要讓他知道公司有這一個專案，且我被授命管理這個專案。我個人認為這是變相的專案章程。
業務是客戶關係的維繫者
在首次接觸客戶時，我對有哪些人將會參與專案是不清楚的。如果要數一家公司對客戶組織架構最清楚的，那必定是業務人員了。他們通常不斷與不同客戶以及客戶公司中不同部門的人周旋，因此他們能在專案參與者方面提供相關資訊。
有了這些資訊，就能確保在首次面對客戶的時候掌握分寸了。哪個高層應該要尊重和謹慎應對、哪個客戶是個麻煩製造者、哪位同事將是主要使用者等。這樣能在專案初期有計劃地建立關係，讓專案進行得較為順利。
懂得變通是專案管理的關鍵
專案章程是專案最重要的啟動關鍵，如果公司沒有正式下達這份文件，也並非沒有辦法解決。只需要多動用一點人脈，並且表達自己實際的需求，則必然也能在專案正式開始之前了解專案的用意，並在公司中其他同事的心中先打下基礎，讓專案能在往後的日子順利執行。
