專案管理總覽
告訴讀者們一件事，不過您聽了也不用太驚訝。自從本書第1版於1997年出版以來，專案管理學會（Project Management Institute; PMI）已經從最初的數千位會員，成長到2011年將近45萬人。PMI是由管理專案的人所組成的專業組織；您可以從該學會的網站www.pmi.org取得更多資訊。除提供種種會員服務之外，PMI成立的主要目的是要將專案管理當成一種專業而加以提升。為達此目的，該學會已建立一項認證過程，使通過認證資格的人獲得專案管理師（Project Management Professional; PMP）的稱號。為獲得這項稱號，這些人必須有工作經驗（大約5,000小時），並通過以專案管理知識體系指南（Project Management Body of Knowledge）或PMBOK® Guide為基礎的線上考試。
也許有人會問，專案管理這件事，真的已經專門到有必要成立專業機構嗎？專案管理應該只是一般管理（general management）的變形而已吧？
沒錯，兩者間的確有很多相似性，但若仔細深究下去，其實可以發現兩者間的差異性，已大到足以將之分門別類的程度。舉個例說，相較於一般管理者所處理的大部分活動，專案與「時程」更加息息相關；此外，專案團隊成員通常不直接由專案經理管轄，而是向大多數一般管理者負責。
那麼專案管理到底是什麼？或者，我們退一步，先說說專案到底是什麼。
專案的定義
PMI定義專案是指「為了產生獨特的產品、服務或結果而進行的臨時性工作」（PMBOK® Guide; Project Management Institute, 2008; p. 5）。這意指專案只完成一次，只要是重複性的工作，那就不是專案。專案應該要有明確的起點和終點（亦即有時間限制），有預算（亦即有成本控制），明確規範工作範疇（或量）的大小，還要符合特定的成效要求。我說「應該要」的原因是，僅有少數專案能達成上述的定義。所以本書從頭到尾都將對專案的這些限制，稱之為PCTS目標，而PCTS指的是成效（performance）、成本（cost）、時間（time）與範疇（scope）。
著名的品管大師朱蘭（J. M. Juran）曾經為專案下定義：專案是必須排定時程去設法解決的問題（problem）。我喜歡這個定義，因為它點出每一個專案都是為了要替公司解決某一類問題而衍生出來的。不過，我必須小心使用「問題」這個字，因為傳統上大家都賦予這個字負面的意義。然而專案所要處理的對象，卻包括了正面和負面的問題。舉例來說，想要開發某項新產品是一個問題，不過卻是「正面的」問題；然而環境大掃除專案則是處理「負面的」問題。
專案失敗
事實上，科技產業研究機構史丹迪希公司（Standish Group，網址：www.standishgroup.com）調查發現：在美國本土完成的所有軟體專案中，只有17% 達成一開始所設定的PCTS目標；另外的50% 需要修改原先的目標──因為通常不是專案完成時間拖延就是超出預算，因此必須降低對成效的要求；最後有33% 的專案，則是無疾而終。算算美國公司平均一年投入超過兩千五百億美元在軟體開發上，照這個比例看來，光是花在那些半途夭折的專案的錢，就有八百億美元之多。真正令人驚訝的是，所有軟體專案當中，有83% 都是有問題的專案。
我並不是專挑軟體公司開刀，這些統計數據同樣也適用於很多不同類型的專案，例如產品開發，也遭遇類似的窘境。產品開發專家估計，一項新產品的開發成本，有30% 是花在重工（rework）上，意思是分派至專案的每三名工程師中，就有一名是被專門請來重新修改其他兩名工程師做錯的部分！
我也有一位同僚鮑伯．杜德利（Bob Dudley），他參與營建專案達35年之久。他告訴我，這些工作也有30% 重工的傾向。我發現，這個事實令人難以相信，因為我一直認為營建工作相當清楚明確，因此或許比研究型的專案更容易控制，不過我的幾位同僚證實了鮑伯的統計數字可信。
這些不斷發生的失敗，歸咎原因不外乎是不恰當的專案規畫所造成。很多人一開始就採取「先做了再說」的心態，不顧一切往前衝，只想馬上看見成果，結果多半事後都必須花更多工夫重來，有如從死胡同倒車轉向再做一次。
最近常有人問我，如何說服公司的資深經理人，正式推動專案管理有其必要性，我也都用上述的統計數據回答他們。事實上，這些經理人最想確定的，就是好的專案管理真的能確實減少重工，甚至避免失敗的命運嗎？我只能說，你不自己真正試過，怎麼會知道呢？如果你只憑自己的直覺管理專案，就能達到僅有少數重工的境界，那麼你就繼續這樣做吧！但我不認為那是行得通的。
我倒是很想進一步探討：相同的問題換成一般管理有沒有不同呢？我也很想做個實驗，把公司所有主管關上幾個月，不讓他們接觸公司任何事務，看看公司的營運表現是否照樣上軌道或是開始下滑。如果表現變差，那我們可以說，一般管理對公司必定有正面的影響，反之亦然。我懷疑有很多一般管理者會想說，他們所做的事對公司營運沒什麼影響。然而我們都知道，有很能幹的一般管理者，也有很肉腳的一般管理者。話說回來，專案經理在這點上和一般管理者是一樣的。
什麼是專案管理？
「PMBOK指南」將專案管理（project management）定義成「應用知識、技能、工具與技巧於專案活動，以滿足專案要求」。專案管理透過按照邏輯分組的42個專案管理流程的應用與整合而實現，這些流程由5個流程群組所組成，分別是起始（initiating）、規畫（planning）、執行（executing）、監視及控制（monitoring and controlling）、以及結束（closing）（PMBOK® Guide, Project Management Institute, 2008, p. 6）。專案的要求包括先前提過的PCTS（成效、成本、時間、範疇）目標。起始、規畫等等的各個流程會在本章稍後談到，而且本書大部分篇幅即在解釋如何完成這些流程。
如果「PMBOK指南」明確指出，專案經理應該使規畫變得更加容易（facilitate），那會是更適當的做法。菜鳥級專案經理特別容易犯的錯誤，是自己一個人卯起來替整個團隊規畫專案。接下來看到的慘劇是，專案團隊成員沒有一個人甩他做的計畫；另一件慘劇是，菜鳥專案經理自己設計出來的計畫，裏面真是千瘡百孔、漏洞百出。經理人不可能每件事都設想得到，他們對任務期程的估計有錯誤，使整件事情在專案開始後破綻百出，最後無法收尾。所以，專案管理的首要原則是：一定要讓未來會牽涉到專案實際作業的人，一起來協助規畫專案。
專案經理所扮演的角色，應該是一個促成者（enabler）。促成者的工作，就是要協助專案團隊成員，把他們所負責的工作順利完成。促成者是團隊成員們的介面，當後者有人缺少資源時，要幫他們找到；當有外力介入，可能中斷他們的工作時，促成者也要能居間緩衝，減少外力衝擊。專案進行時，他絕對不能是獨攬大權者，而是應該成為領導人。
我看過對於領導（leadership） 最好的定義，是范斯．普卡德（Vance Packard） 在《爬金字塔的人》（The Pyramid Climbers）一書中所說的：「領導是一門藝術，它使其他人想去做你認為非做不可的事。」這裏用了一個很鮮活的字眼──想。獨裁者能強迫別人做他們想要「做」的事情，看守監獄的警衛也一樣能強迫犯人分成小組幹活；但是好的領導人卻能讓人「想」去做這些事情，這是兩者之間重大的差異。
專案中有關規畫、排時程（scheduling）與工作控制等要項，是屬於管理或是行政的部分。但是其中如果少了領導的話，專案頂多也只能達到最低水準要求而已。有了好的領導，專案績效絕對不僅止於此。我將在第13章談論專案領導技巧的綜合應用。
不只是排時程
對專案管理最大的誤解之一，就是認為專案管理不過只是排時程罷了。如果是這樣，微軟（Microsoft）不是出了一套軟體叫Microsoft Project，還賣出非常多套嗎？為什麼專案失敗的比例還是一樣那麼高呢？當然，時程安排是管理專案所使用的一項主要工具，但是就重要性來說，讓專案參與人員充分了解專案目標、以良好的工作分解結構（Work Breakdown Structure; WBS，本書第6章會討論）來釐清待完成事項等工作，其實都比時程安排還重要。老實說，如果沒有好的專案管理，一份詳細的時程所代表的意義，只是一份精確記載專案失敗的回憶錄罷了！
說到這裏，我對於安排時程的電腦軟體有一點個人意見。挑選哪一套套裝軟體並不太要緊，因為每套軟體都有優點也有缺點。很多公司傾向於提供給員工軟體，就期待他們不必受任何訓練，經由自學就能知道如何使用這些軟體。但基本上這是行不通的，因為時程安排軟體的最細微部分，不太可能無師自通。先撇開每個人還有例行的工作要做，不太有多餘的時間自學，事實上並不是每個人都適合自己摸索學習。就像你不會讓一個毫無經驗的新人，完全不必經過訓練，就在工廠裏自己摸索操作一台很複雜的機器，因為你知道這麼做的結果，不外乎是機器報銷，或是新人自己受傷。那麼為什麼對軟體就另眼看待呢？
管理一人專案並非專案管理
問個謎語：「什麼時候是在管理專案，卻又不叫做專案管理？」答案是只有一個人參與專案的情況。很多人到我開課的班上來學習怎麼管理專案，但是他們是自己的專案唯一的成員。不可否認，即使是一個人做的某項工作，也能叫做專案，只要這項工作有清楚的起始日、目標、完成日、特定的成效要求、確定的工作範疇以及預算，就是一項專案。但是，如果從事專案的人員只有一位時，也就不需排定要徑（critical path）時程了。所謂的要徑時程，是指在眾多條同時進行的路徑中耗時最久，亦即可以決定整個工作最後完成日的路徑，所需耗費的時間。但是只有一個人在進行工作時，就不存在多條同時進行的路徑──除非你具有分身能力。
一個人做專案，其實需要很好的自我管理能力，也需要很好的時間管理能力，另外還需要一張詳細的待辦事項清單（to-do list）。總括來說，除非你和其他人一起合作，不然就不能算是在做真正的專案管理。
大陷阱：邊做邊管的專案經理
有個蠻普遍的現象是，一些專案經理也被要求在專案中分攤執行面的工作。這必定會造成問題。若專案團隊真的由幾個人所組成，專案經理會發現自己陷入一種兩難局面：既要管理專案運作，又要趕工把自己負責的那部分工作完成。很自然地，完成工作就變成專案經理的先決要務，不然的話，這部分的工作一定會落後於排定的時程。一旦他選擇投入自己被分配到的工作，也就表示管理專案的部分遭到擱置了。即使這時專案經理心中希望的是專案本身能自然地順利進行，然而不幸的是，這種事絕不可能發生。畢竟，如果這個專案團隊能夠自動自發地管理好專案，那麼一開始還要專案經理做什麼？（還記得前面我們曾經討論過，專案管理到底有無必要嗎？）
不幸地，到了績效評估的時候，結果是上層主管直截了當的告訴這名專案經理，專案在管理部分有待改進。其實，早在專案一開始時，他就只需要執行管理的部分就好。
沒錯，對於非常小型的團隊──可能最多三、四個人的團隊──專案經理是可以分擔一些工作的。但是隨著團隊規模擴大，要專案經理同時分攤某項工作，又要做好整個專案的管理，幾乎是不可能的事，因為他注定要在工作和成員之間無止盡地奔波。
造成這種情形的原因之一，是由於組織沒有充分了解到專案管理的本質；他們認為專案經理本來就可以邊做邊管，結果造成公司上上下下幾乎每一個人都試圖想要管理專案。如同每一項專業所呈現出的事實，總有一些人可以把專案管理得很好，而另外一些人則在這方面沒什麼長才。我的建議是，挑選幾個有意願、又有能力的人擔任專案經理，讓他們管理一些小專案。這樣可以讓「技術型」的人員致力於他們擅長的技術性工作，而不必去操心行政方面的事，同時也能讓擅長於專案管理的人才專心管理好專案。
至於如何挑選優秀的專案經理，並不在本書的討論範圍之內。有興趣的讀者，可以參考魏斯基（Wysocki）與路易斯（Lewis）合著的《世界級的專案經理人》（The World-Class Project Manager, Perseus, 2001）一書。
全部囊括，難！難！難！
有一項導致專案失敗常見的原因，是專案的贊助人（sponsor）要求專案經理，必須在限定的時間、預算、範疇、達成特定成效的條件下，完成專案。換句話說，這些贊助人完全支配了專案的四項限制條件，因而導致專案失敗。
有關這四項限制條件之間的關係，我用以下的公式表示：
C＝f（P, T, S）
上述公式轉用文字敘述則為：成本（C）是成效（P）、時間（T）和範疇（S）這三個變數的函數。在圖1-1中，我用三角形來表示四者的關係。在這兩個三角形中，成效、成本和時間各代表三邊，範疇則代表面積。
在幾何學中，如果我們知道三角形的邊長，就可以算出它的面積。或者，如果我們知道三角形的面積和兩邊長，也可以求出第三邊的邊長。這個定理可以實際應用在專案管理上：贊助人可以指定任意三項變數的值，但是剩下一項的值須由專案經理來決定。
假設贊助人要求看到專案在時間與工作範疇的限制下，達到一定的成效。專案經理的工作就是決定需要花費多少成本，才能獲得那些成果。這個時候，我都會提醒專案經理，當他們去向贊助人報告計算出的預估成本時，一定要帶位醫護人員隨侍在側，以提防贊助人看到數據後，隨時會腦中風或是心臟病發。
贊助人永遠不變的反應是：「怎麼可能要花這麼多錢？」專案經理所提出的預算數字，和贊助人心裏所認為的合理數字，永遠有一大段差距。接下來贊助人可能會說：「如果這個專案真的要花那麼多錢，我們不太可能會批准。」沒錯，那正是他應該做的決策。但是贊助人一定會想辦法，要專案經理答應刪減預算。如果專案經理真的讓步，不必懷疑，最後專案成功的機率肯定會大幅滑落。
碰到這種情形，專案經理們一定要有一個觀念：專案經理有義務向專案贊助人提出合理的預算，幫助贊助人能夠做合理的判斷，以決定此項專案是否有進行下去的必要。假如專案經理基於某些原因而妥協，降低了專案預算數字，即使專案得以開始推行，日後專案經理一定會為此承受苦果。因此，寧願一開始做好把關工作，以免日後衍生更大的問題。
當然，還有另一種可能性。假如贊助人說，他們最多只能挹注這個專案某個數目的資金，那麼專案經理就需要提出減少工作範疇的建議。如果減少工作範疇的提議可行，專案就可以進行。否則，審慎的做法是放棄這個專案，而去從事可替公司賺錢的其他事情。有人說，專案意外出錯的可能性，永遠高於意外成功的可能性；從成本估計的角度來看，意味著費用超過預算的可能性，永遠會高於低於預算的可能性。這只是敘述莫非定律（Murphy’s law）的另一種方法。莫非定律說：「只要是可能出錯的地方，就一定會出錯。」
2024專利防護中