◆本書為經濟新潮社於2003年出版的《我懂了！專案管理》全新增訂版！ 在國際趨勢上，專案管理已經逐漸凌駕MBA，成為掌握未來的關鍵能力！ 而且，越來越多企業要求它們的承包廠商，必須由專業的專案經理人來負責專案的推動。但是什麼是「專案管理」？ 品管大師朱蘭（J. M. Juran）曾經為「專案」下一個定義：專案是必須排定時程去設法解決的問題。 本書提供一套學習專案管理的捷徑，從最基本的專案四大限制條件（限定的時間、預算、範疇、達成特定成效）開始，然後規劃專案、排定進度、監控作業，以step-by-step的方式，說明一個有經驗的專案經理人，如何在過程中運用各種方法解決問題，完成專案，最後交出漂亮的成績單。而且書中有許多生活化的實例，讓讀者更容易進入、思考和加以應用。 在這次的增訂版當中，已根據最新版的專案管理知識體系指南（PMBOK GuideR）進行更新，因此更加實用，可協助你從頭到尾規劃與執行專案。 本版增加了三章全新的內容：擬定專案風險計畫、變更控制過程、讓專案經理成為領導人。 另外，本書也加入以下主題相關的最新資訊： ．規劃專案 ．運用工作分解結構來規劃專案 ．製作切實可行的時程表 ．專案控制與評估 ．實獲值分析（EVA） ．管理專案團隊 ．在你公司推動專案管理。 全書每一章都深入淺出，容易了解，編排也十分清楚。每一章都含有生動的範例，以及練習題。 想培養專案管理能力的讀者，這是最理想的案頭必備書籍。

第四版序　017

1　專案管理總覽　021
◎專案的定義    023
◎專案失敗        024
◎什麼是專案管理？        026
◎不只是排時程        028
◎管理一人專案並非專案管理        029
◎大陷阱：邊做邊管的專案經理    030
◎全部囊括，難！難！難！    031
◎專案的階段    034
◎定義階段        036
◎擬定策略        038
◎專案實施之規畫    039
◎執行與控制    039
◎結案        040
◎管理專案的步驟    041
‧一、定義問題        041
‧二、發展出各種解決方案    043
‧三、規畫專案        043
‧四、執行計畫書    044
‧五、監視及控制進展    044
‧六、結束專案        044
◎專案管理知識體系（PMBOK�）      045
◎專案流程        045
◎知識領域        049

2　專案經理的角色　057
◎管理是什麼？        058
◎管理的定義    059
◎專案管理離不開人！    060
◎邊做邊管的專案經理    061
◎職權        062
◎關鍵時刻        063
◎領導與管理    064
◎你想成為專案經理嗎？        065

3　規畫專案　069
◎專案規畫絕對必要        072
◎規畫的定義    074
◎策略、戰術及後勤        075
◎執行面的規畫        076
◎後勤的重要性        077
◎計畫書的內容        078
◎會簽計畫        079
◎變更計畫        081
◎有效做規畫    082
◎專案規畫步驟        085

4　制訂專案的使命、願景及目標　089
◎定義問題        090
◎容易混淆的名詞    092
◎現實世界        094
◎專案真正的使命    094
◎訂定專案目標        095
◎目標的本質    098
◎評估專案風險        098

5　擬定專案風險計畫書　103
◎定義專案風險        104
◎六步驟過程    106
◎建立風險準備        113
◎管理多專案風險    114
◎協調點    116
◎風險矩陣        116
◎風險登錄表    117

6　運用工作分解結構來規畫專案　121
◎一個簡單範例        123
◎製作工作分解結構的指導原則    126
◎工作分解結構的用途    128
◎估計時間、成本及資源        130
◎估計的風險    132
◎取得共識的估計    135
◎改進估計能力        136

7　排定專案工作時程　139
◎排時程的簡史        141
◎網路圖    143
◎為什麼要排時程？        145
◎製作箭號圖    148

8　製作一份實用的時程表　157
◎計算時程        158
◎網路時程計算規則        160
◎基本的時程安排計算    160
◎利用網路圖來管理專案        168
◎將箭號圖轉為長條圖    171
◎分配資源給任務    172
◎資源可用性    179

9　專案控制與專案評估　185
◎自我控制的團隊成員    188
◎專案控制系統的特色    190
◎採取矯正措施        191
◎及時反應        192
◎設計正確的系統    193
◎遵行KISS原則     193
◎專案檢討會議        194
◎專案評估        195
◎專案評估的目的    196
◎舉行專案過程檢討        199
◎專案過程檢討報告        200

10　變更控制過程　203
◎變更的來源    205
◎變更控制過程的六個步驟    208
◎變更控制表    212
◎啟動變更的門檻    215
◎變更控制紀要        217
◎專案分割        218
◎擁抱改變        220

11　用實獲值分析控制專案　225
◎衡量進展        227
◎衡量專案成效或品質    230
◎實獲值分析    230
◎用花費曲線做變異數分析    232
◎僅用小時為單位的變異數分析    238
◎回應變異        239
◎可接受的變異        241
◎用完成百分比來衡量進展    242

12　管理專案團隊　247
◎團隊建立        248
◎透過規畫促進團隊合作        249
◎釐清團隊使命與目標    251
◎化解個人目標與團隊使命的衝突        252
◎處理團隊議題        253
◎改善程序問題        254
◎重視團隊成員關係        255
◎團隊發展階段        256
◎不同階段的領導角色    257
◎如何使成員委身投入團隊    260
◎最後叮嚀        262

13　讓專案經理成為領導人　265
◎打下基礎        266
◎了解領導特性        267
◎了解領導風格        267
◎培養專案支持者    269
◎建立工作關係中的一致性    270
◎鼓勵冒險並消除面對失敗的恐懼感    271
◎建立可表示異議的正面文化        272
◎激勵        272
◎專案領導與團隊環境    274
◎確認與發展團隊成員的角色        274
◎找出解決衝突的適當方法    275
◎主導專案現狀會議        277
◎與虛擬團隊合作    279

14　在你公司推動專案管理 　283

附錄　問題與練習解答　291

索引　295

第四版序

　　想要將人造衛星送到火星？或是規畫一場會議或開發新軟體？你選這本書就對了。專案管理的重要價值在於它能應用於不同的產業，並能應用在多個管理層級。要找到比專案管理更靈活的企業組織學問，那可不容易。無論你的頭銜是否為專案經理，你都能從本書所提到的實際應用中獲益。本書是整個專案管理在工具、技巧與學問方面的簡要綜述。在第四版中，更著重說明三個重要的主題，新增了關於「讓專案經理成為領導人」、「管理專案風險」以及「變更控制過程」的章節。雖然個別來說每個主題都有其重要性，但是這三個主題合起來構成了專案成敗的基礎。

　　專案通常由團隊所完成，團隊由人員所組成，而人員則由專案領導人（project leader）所帶領。顯然前面這句話缺乏「專案經理」（project manager）中的「經理」這個術語。若由專案經理來管理專案，在沒有正式團隊的情況下，即使有構成團隊的人員或支援的人際管道，他們又能有什麼作為？成功的專案領導人帶領其團隊中的人員始終如一地達成目標，並能使績效提高。他們真正了解領導統御和團隊績效，並能將眾多專案工具和技術知識結合運用。要有連續成功的專案，以上兩者都不可缺少，那是執行力與嫻熟的人員管理兩者兼顧的平衡做法。忽略掉其中一項就會導致專案失敗，造成企業組織的專案績效起伏不定。

　　每個專案與生俱來都有風險。當決定要投注多少心力與金錢，來減輕和管理風險時，專案經理必須考慮幾個變數。我的團隊或支援人員要有多少經驗？我有適當的技能組合可運用嗎？我能倚重來自先前專案的可靠資料嗎？或是我處於茫然不知所措的狀態嗎？無論做什麼評估，專案風險是專案存續期間從早期就需要處理的東西。如同本書所介紹的其他任何流程，風險必須正式加以管理，儘管容許有一些彈性，但是不能和標準實務落差太大。等到壞事情發生再去解決的做法，專案經理可承受不起。被動性管理所付出的代價太高。第5章所提出的實用「六步驟流程」應該能應用到任何專案上。如何直接應用則取決於該專案所面對的變數。

　　改變，就像死亡或繳稅一樣，人們總是能拖就拖；但是專案經理需要增加工作中可確定的事項。我在第3章引述了本書前三版的作者詹姆斯．路易斯（James P. Lewis）的話，以說明專案失敗主要是由於未能適當做規畫所導致。我經常告訴我的研討會與會者，規畫最為重要，而且大多數專案的成敗從一開始就決定了。這並不誇張，但是專案執行時經常遺漏掉這一點。從專案第一天開始，就要依據已影響專案的所有變更，將計畫維持在最新狀態。這些變更會影響專案範疇嗎？時程或預算有受到任何顯著的影響嗎？將有效的變更控制應用到專案時，這些是必須提問並且回答的問題。未能管理變更與傳達變更的發生，就會導致嚴重的調整不當，而且可能造成專案失敗。第10章將告訴讀者一種實用的變更控制流程，可協助保證專案成功。

　　我身為美國管理協會（American Management Association）前任的專案管理全球實務領導人（Global Practice Leader），很榮幸能夠為全球多個組織訂定標竿，並確認專案相關的幾項最佳實務。本書中所討論的一些應用正反映出一部分的這類實務，以及專案管理知識體系指南（PMBOK� Guide）最新版本中所提到的實務。隨著《我懂了！專案管理》第四版內容的擴充，我希望能提升你每一次的專案成功的機會，不僅在預算內準時完成，而且也有出色的交付標的（deliverable）。

專案管理總覽

　　告訴讀者們一件事，不過您聽了也不用太驚訝。自從本書第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）的另一種方法。莫非定律說：「只要是可能出錯的地方，就一定會出錯。」

作者：約瑟夫．希格尼(Joseph Heagney) 譯者：何霖 出版社：經濟新潮社 書系：經營管理 出版日期：2012-10-09 ISBN：9789866031212 城邦書號：QB1097 規格：平裝 / 單色 / 304頁 / 15cm×21cm