何謂專案管理？ 美國專案管理學會 專案管理就是「為達成或超出利害關係人的需求或期望，把種種知識、技能、工具、技術應用在專案活動上，…，其牽涉到相互競爭的範疇，時間、成本、品質，以及利害關係人各種不同需求和期望之間的平衡」

Presentation on theme: "何謂專案管理？ 美國專案管理學會 專案管理就是「為達成或超出利害關係人的需求或期望，把種種知識、技能、工具、技術應用在專案活動上，…，其牽涉到相互競爭的範疇，時間、成本、品質，以及利害關係人各種不同需求和期望之間的平衡」"— Presentation transcript:

1 何謂專案管理？ 美國專案管理學會 專案管理就是「為達成或超出利害關係人的需求或期望，把種種知識、技能、工具、技術應用在專案活動上，…，其牽涉到相互競爭的範疇，時間、成本、品質，以及利害關係人各種不同需求和期望之間的平衡」

2 專案管理就是將計畫、組織、管理資源的一些原則加以運用來成功的完全成特定的計劃目標或標的。因為專案具有臨時、特殊、創新加值的特性，因此在管理技巧上就與組織日常管理流程的經營哲學或管理技巧不同。
專案管理的主要作用在於透過管理將有限的資源(金錢、人力、物資、土地、空間、能源等)與活動(激勵、能力)做最佳配置，達成目標(時間、成本、品質、專業性、尤其是案主滿意)

3 專案的八種特性： (一) 目標預定性：專案是受某些目標所左右的 (二) 範疇受制性：指所欲達成的專案的有關的事物 (三) 規模預設性：
(四) 生命周期性：制訂專案規劃及進度表(Project Plan & Schedule)，然後按照該表所訂定的任務(tasks)、時段(duration)和資源(resources)來執行相關的工作，直至該專案結束

4 (五) 預算設限性；工作活動是受到財務預算的約束的
(六) 人力資源有限性；成員數目和工作時間的兩個方面連結起來，便為專案經理營造了一個衝突的困局 (七) 獨特性；每一專案都具有這樣或那樣的不同成份，並各自有其獨特的性質 (八) 完結定數性：沒完沒了的工作項目不是專案！

5 專案金字塔 活動 中間目標、專案 長程目標、策略行動方案 使命願景價值觀

6 專案管理流程 視覺化 計畫 執行 結案

7 傳統上交互影響的三角限制條件

8 時間 透過WBS可以協助各項任務之工作進度的規劃與評估，進而完成特定的目標
各項工作所需條件與資訊也必須在進度表中(Gantt Chart)仔細評估，因為那會在期間不經意地會影響進度。如果專案管理者的管理能力不足，時間這個重要的資源就常常會被忽略掉。

9 成本 固定與變動成本：含人事、物資、風險、土地、建築、設備、能源、間接成本、意外事件成本
對專案管理來說更重要是，因為組織常常使用兼職、部份工時或外包人力，因此人員的素質，包括技巧、生產力是必須被考慮的變數

10 專業性 指完成專案目標所需要的專業條件。它主要表現在最終產品的品質上。
時間與成本的投入當然會影響品質，過與不及都會有意想不到的後果，當然好的品質對時間與成本也會有正向的影響。

11 專業與學習

12 專案管理流程四步驟

13 專案管理的主要活動 分析與設計計畫標的與事件 根據標的計畫工作 評估與控制風險 估計所需資源 分配資源 組織工作 爭取人力與物資 分派工作
指導各項活動 監控計畫之執行 掌控與報告進度(資訊管理) 基於階段事實分析結果 定義計畫的產品 預測計畫未來的發展趨勢 品質管理 議題管理 議題解決方案 不良產品預防 確認、管理與控制變遷 計畫結案 對利害關係人報告與溝通 評估增加或減少工作人員

14 計畫標的 指的是計劃的階段性結果, 這個結果的達成是為了最初規劃的利益所必要的結果 S.M.A.R.T. Specific(專門性與特殊性)
Measurable (可評估的成果) Achievable (預期近期可接受與達成) Realistic (務實可行的組織資源) Time terminated (考慮有限的時間限制).

15 專案(project)不僅是包含了為達成某種目標的串性的整體任務(task) 任務 Task 次要任務 Subtask
作業包裹 Work Package 任務可以說是把專案從起點處至完成彼方的「工具」。 里程碑 Milestone：專案中重要的完成點 15

16 工作說明 Statement of Work 目標 簡要工作說明 預定工作進度表 預算 績效評估標準 16

17 工作結構分析 Work Breakdown Structure WBS 用來定義專案中的所有作業 (層層分解、個個擊破) 17

18 WBS

19 優良的WBS之特性 各工作皆可獨立運作 工作不會太大而不易管理 工作可充分的授權 工作皆可個別監測 可對個別工作提供所需資源 19

20 甘特圖 Gantt chart 優點 簡單 目視管理進度 缺點 不適用於複雜專案 20

21 v 作業 第一週 二 三 四 [ ] [ ] [ ] [ ] 21

22 專案組織 單純式專案組織 專案小組全職專注於專案 優點 專案經理對專案擁有完全的自主權 成員只需面對一個老闆 溝通層級短、決策形成快
榮譽感、動機及使命感 高 22

23 專案組織 單純式專案組織 缺點 人員與設備無法共用，資源重複 組織的目標及政策 易被忽略 功能部門與新科技脫節 專案小組成員無功能部門為後路
組織的目標及政策 易被忽略 功能部門與新科技脫節 專案小組成員無功能部門為後路 (專案完成即失業)使得專案延誤 23

24 專案組織 功能性專案組織 專案建構在功能部門中 優點 成員可同時做許多專案 專業技術不會因人員離開而遺失 成員有機會升遷
功能部門中有大量的專業人員 處理專案的技術問題時會產生綜效 24

25 專案組織 功能性專案組織 缺點 專案的觀點與功能部門的功能 無直接相關者易被忽略 動機較差 顧客的需求易被忽略 25

26 功能性專案組織 26

27 專案組織 矩陣式專案組織 結合單純式與矩陣式 成員由不同功能部門提供 專案經理決定 功能部門經理控制 工作內容 、完成時間 人員 、技術
27

28 專案組織 矩陣式專案組織 優點 強化與功能部門的溝通 專案經理對專案負成敗的責任 降低資源的重複 成員於專案結束後 無出路的問題
成員於專案結束後 無出路的問題 較忠實的執行上級組織的政策專案獲較多的支持 28

29 專案組織 矩陣式專案組織 缺點 同時面對兩個老闆 專案經理需優異的談判技巧 局部最佳化 29

30 矩陣式組織 30

31 專案組織 1.民主式組織(democratic teams)：成員的參與感、成就感及學習機會高，缺點是溝通太多、無責任感且每個人都要有無私的精神。 2.主程式設計師組織(chief-programmer teams)：決策集中、溝通減少、分工清楚，專案成敗定於一人的技術與管理能力。 3.階層式組織(hierarchical teams)：配合外部組織結構、減少溝通

32 時間導向技術 節點：作業 箭頭：作業的先後順序 作業時間的估計方式 CPM = PERT 三種估計時間 一種估計時間
樂觀、悲觀及最可能 一種估計時間 CPM = PERT 現代工程管理萌芽於1950年代，當時美國海軍因建造北極星核子潛艇而發展出PERT。同時，美國杜邦公司發展出CPM(要徑法)。嗣後工程界將兩者合併使用，遂成為我們目前應用廣泛的PERT/CPM(網狀圖)。 32

33 了解何謂PERT，PERT是在1958　-1959年從美國海軍的計劃中所發展出來的，而在1959年後開始被使用於大型企業中進行專案的時程控制，其具體的內容如圖一中所示，其中圓圈部分代表著工作(task)，箭頭部份代表著作業(activity)，至於每一個作業所需的執行時間我們可以用下面的方式來加以計算:

34 　　假設　a=樂觀時間，b=悲觀時間，m=最可能的作業時間 則作業的平均時間ET=(a+4m+b) / 6 有了這些作業的平均時間之後，接下來我們便可以算出期望完成這些工作的最早時間(TE，earliest expected completion time) ，而其計算方式如下: 期望完成的最早時間TE(i)=max{ TE(j) + ET(i , j) }

35 機率性時間估計 活動 開始 樂觀 時間 最可能 時間 (眾數) 悲觀 時間 o p m te 前程企業 生產管理6/e 18-35

36 要徑排程 利用圖形來規畫和控制專案 三個關鍵
時間、成本和資源 PERT (Program Evaluation & Review Technique) 計劃評核術 CPM (Critical Path Method) 要徑法 36

37 繪製網路圖的步驟 確認所有作業 作業項目的先後次序及建構網路圖 尋找要徑 專案中的所有主要作業 作業的次序表 網路中耗時最長的路徑
無閒置時間的路徑 37

38 最早開始時間 Early Start time, ES
工作最早可能開始時間 所有前置作業的作業時間總和 Max (前置工作所需時間) 最早結束時間 Early Finish time, EF ES + 作業(所需)時間

39 最晚結束時間 Late Finish time, LF
不造成專案延誤的最晚完成時間 完成的時間 - Max (後繼作業所需時間) 最晚開始時間 Late Start time, LS LF - 作業(所需)時間

40 例：圖表 3.4 40

41 Earliest Begining Time: The minimum amount of time that must be
consumed before an activity. ES = max TB 41

42 42

43 Latest Beginning Time: The maximum amount of time that can be
consumed before an activity begins. LS = Time allowed - max TC 43

44 例題 3.1 活動 代號 先前的活動 週 設計 A － 21 原型製造 B A 5 設備評估 C A 7 原型測試 D B 2
活動 代號 先前的活動 週 設計 A － 21 原型製造 B A 5 設備評估 C A 7 原型測試 D B 2 記錄設備報告 E C,D 5 記錄方式報告 F C,D 8 記錄最後報告 G E,F 2 44

45 45

46 46

47 最小成本排程 專案之成本與完成時間 縮短時程 會增加成本 直接成本 延長時程 會增加成本 間接成本 47

48 直接成本 加班 增加雇員 轉調員工 添購、租賃設備 48

49 間接成本 管理費用 設備與資本的機會成本 契約的罰款 獎金的損失 49

50 最小成本之步驟 繪製網路圖 要徑 縮短要徑中最小成本作業 繪製專案之直接、間接及總成本曲線 決定作業之單位時間趕工成本 正常成本 NC
正常時間 NT 趕工時間 CT (最短的作業時間) 趕工成本 CC 決定作業之單位時間趕工成本 要徑 縮短要徑中最小成本作業 繪製專案之直接、間接及總成本曲線 50

51 51

52 52

53 53

54 The indirect cost remain constant for eight days
and then increase at the rate of $5 per day 總成本 直接 間接 54

55 事件與風險危機處理

56 風險－潛在失敗危機 也有可能成為潛在轉機 顧客(不論是內部或外部的計畫執持者)以及外部組織(不論是政府或監管機構)對於時間、成本與專業可能有所規範,但是第四因素－風險，卻是必須由執行團隊基於自我的評估、專業的能力與技術來回應的。因此必須與利害關係人針對前三因素，透過表、圖與計畫期間的事實、成果保持溝通、協商甚至談判 風險管理必須在四構面(時間、成本、專業、風險)以及六項目(整合、溝通、人資、品保、流程、採購)具備深刻的知識與經驗 錢在失敗 56

57 主要利害關係人的訪談 1.(客戶大名)請告訴我，想到這項專案的成與否時，有哪些事對你而言是最重要的? 2.還有沒有其他的事?
3.這些事情的優先順序呢? 4.假如你描述的成功因素都做到了，你認為有哪些基本的組織結果(像是降低流動率、增加產量、提高銷售量、降低營運成本等)會獲得最大的改善? 5.若能成功地管理專案，有哪些成本可因而避免?

58 步驟一：訪談內容 1.品質/範疇 2.時間 3.成本(相對於預估的財務收益而言)

59 步驟二：風險管理— 避免經營管理的熱點 腦力激盪找出熱點，決定作或不作？ 標準─ 何者可能會： 1.導致微幅的調整
步驟二：風險管理— 避免經營管理的熱點 腦力激盪找出熱點，決定作或不作？ 標準─ 何者可能會： 1.導致微幅的調整 2.犧牲最低優先的績效因素 3.犧牲中等優先的績效因素 4.犧牲最優先的績效因素 5.導致全盤失敗

60 步驟三： 把專案細分為可以處理的項目 例如：教材研發專案 1.需求評估 2.界定出願景、範疇及各項主要目標 3.課程發展 4.教材研發
5.檢測/修訂 6.教師培訓 7.課程的推出(開始上課) 8.預算/資源

61 步驟四：組織項目與任務、排程 1.在將任何資料登入某個書面或軟體排程工具之前，先把各個項目和任務依序排列，是有效使用這類工具的關鍵。
2.依序排列的意思是依照各個項目和任務必須完成的順序一一排列。把主項目排在最前面。這個階段可能很主觀，因為有可能是多個項目同時進行。 3.然而，若是項目順序很明顯，就按照順序排列。接著，把每個主項目下的各子項目也依序排列。 4.通常，在主項目中的各個事件順序是比較清楚的。然後，把子項目之下的各個任務也依序排列。

62 步驟五：決定任務的工期 在使用這類工具時，一次只登入一個欄位，可以讓我們清楚地一次專心於一個主題。依照清單上的順序，一一估算完成每個任務所需的時間。在這個階段，不需要登入主項目和子項目的資料。到最後，會把每個相關任務的時段再加總計算。 也可以參考利用軟體工具

63 步驟六：釐清任務間的關係 這個步驟在書面的形式上，會在一個名為「前置任務」(Predecessors)的欄位中進行，在軟體中則是以一個連續相關活動的方式進行。所謂任務之間的關係有好幾種，並行或同時發生的任務意味著可以同時進行。任務之間的相依關係有好幾種，最簡單者為「完成-開始」(finish-to-start)的關係。這些相依的任務，必須是在完成其他任務之後才能開始。

64 步驟七：確定資源與預算 這個步驟可以在專案軟體或另一張試算表上進行。到最後一個步驟才釐清資源和預算的最大好處是，此時所根據的資料已經在前面的幾個步驟中確定了，而且應該是根據專案如何執行，在什麼樣的時間之內，以及有什麼資源等資料估計的。 這樣的技術遠比隨機估計預算來得有效。那些隨機估算通常都是在專案任務指派好時就開始估計的。這些一開始就估計的預算，除非是根據過去類似專案的經驗所得的還不錯的資料，否則往往是毫無資料根據，粗略猜測出來的。

65 下一次作與不作的查核點 1.該專案是否能達成已經過優先順序排列考驗的績效因素? 2.熱點上的風險程度是否可以接受和管理?
3.資源的取得是否沒有問題，時間表是否合乎實際? 4.預測的財務收益是否比預測的成本大?

66 執行 -- 參考資料 例如透過軟體工具，建立 → 一套記名式的專案參考資料 → 一個顯示所需資料存放位置的標示(通常是一個檔案名稱)
→ 在完成當天的工作後，一個能提醒你把按時啟動的參考資料往前挪到專案所需的下一個工作天的提示。這叫做時間啟動前移(Time Activate Forward, TAF)。

67 專案管理模式 Agile(敏捷型), interactive(互動型), incremental(漸進行), and phased(階段型)
不論採哪種模式，重要的是審慎思考釐清計畫的目標與標的，尤其是所有參與者以及利害關係人的角色與責任

68 傳統模式 也就是俗稱的瀑布發展模式“waterfall development”，換句話說就是規劃一系列有序的任務，通常運用在較小且清楚的計畫中。 不同產業有不同的作法，一般也將其稱為問題解決方案problem solving — 界定問題、發展選項與權重、選擇路徑、執行與評估。

69 專案管理的組織管理 行動管理的企業家精神 認同建構的分散化、網絡化 規劃的孤立性 制度化的終止與結局

70 關鍵鏈管理critical chain 有限資源理論Theory of Constraints (TOC)的應用。主要目的是在於提高計畫完成率。所有計畫的主要限制就是資源。 為了能將有限資源利用極大化，關鍵任務的規劃是首要的工作。關鍵鏈管理的精神就在於一旦有限資源出現，並且可以運用時，必須及時將其他資源加以整合在這個關鍵任務的執行上。 因此對於一些特殊計畫，可以透過關鍵鏈，妥善運用資源幹桿，或當多計劃執行時，透過跨計畫資源整合。通常那些能夠跨計畫運用的主要幹桿資源是非常少數且清楚的。

71 事件鏈管理 是關鍵鏈管理的後續管理 其精神在於將不確定性模型化，並且透過事件發生時，其流程網絡的分析，來確認、預測與管理這個事件鏈對專案計畫的影響。透過這個方法可以舒緩事件所造成的負面效應，並且重新調整計劃，一般來說事件鏈管理必須遵守以下原則：

72 事件鏈管理方法 出現高風險時刻的機率：一般而言，專案行為不會是線性、規律、制式發展的，隨時可能受到外部因素的影響而要做調整。
事件鏈：每一事件會引發其他事件，而導致計畫的改變，可以透過量化分析來衡量總影響效果。 關鍵事件：指的是那些具有關鍵影響力的事件，可以透過分析來發掘。 事件與計劃軌跡延續：事件發生後新的成本、資訊、資源必須重新整合來預估可能的新事件並規劃新的計畫走向與成果。 視覺化事件鏈：可使用event chain diagrams或 Gantt chart。

73 專案流程管理 計畫監控可以結合流程管理process-based management。例如結合CMMI (Capability Maturity Model Integration)或 ISO/IEC15504 (SPICE - Software Process Improvement and Capability Determination)。 敏捷型計畫的管理方式則是基於人際互動管理所創造的快速、彈性與合作效果。與傳統管理模式不同的是，他是透過一連串小型的、高彈性的計畫，來事後因應不斷變動的情況，而比較不是事先因應的計畫！

74 計畫控制系統 目標在於將計劃維持在既定的軌道上進行、即時且作預算控制。 然而計畫控制也必須評估是否適當，過多的結果是成本過高，過低的結果是風險過高。如果計畫控制不洽當就會反映在經營成本、不斷錯誤或額外監控支出上。 控制系統可以應用在成本、風險、品質、溝通、時間、變革、採購、人資上。此外執行控制的管理者必須清楚地知道計畫控制對財務績效的影響、對利害關係人信賴關係的重要性。他們必須全盤掌握控制之執行過程，以了解它對最終產品的影響。監控機制應該事先啟動以便事前及早確認問題，監控者可以是團隊的一員或一外部獨立顧問。 系統監控有時是一個正式的系統，可以系統性、有效的、全程的進行監控，將監控設計付諸實施。

75 正式系統監控可達成的項目 經由組織各種標的的理解，建立控制策略，以校準組織的目標。 重新發現或建立新系統的各種標準。
針對計畫管理中的時間與成本進行政策的不斷審視。 對管理過程加以系統性的描述。

76 計劃發展階段 事實上，不論用何種方法，專案管理發展的過程都一樣: 發起、 規劃或發展、 生產或執行、 維持或控制、 結案。

77 發起期 計畫發起期就決定了計畫的本質，如果一開始沒有進行得很好，通常計畫在目標達成上也不會成功。一開始利害關係人各方就要對商業環境充分理解、確定必要的監控機制，讓它整合到整個專案過程中。任何一個出現的缺失都必須加以登錄、報告、確認。 發起期必須涵蓋以下全盤整合的計畫階段。

78 以可評估、測量的目標，來分析研判商業需求。
檢視自我當前的營運狀況。 從預期的最終產品的營運，去發展概念設計。 設備需求調查。 基於本益比之財務分析，包含預算規劃。 選擇利害關係人，含消費、利用者或支持者。 計畫圖涵蓋成本、任務、流程、成果。

79 規劃與設計期 接下來，要發展並且開始測試最終成果的粗模。 所謂測試指的是結合產品使用者和測試者加以進行，也可以在產品發展中同步進行。
同時導入控制機制，去確保最終的結果能滿足計畫圖裡面所設定的各種專業標準。換言之，在設計階段必須涵蓋：

80 滿足計畫贊助者、產品使用者以及各種商業標準的要求。
滿足最初功能的要求。 能夠在品質標準的要求內生產。 能夠在時間與成本的限制條件內生產。

81 執行期 為了滿足原始專案規劃的各種要求，執行期間必須協調整合計畫的人事、資源、行動。 其產出的成果就可以視為該計畫管理規劃的結果。

82 監控期 監督與控制涵蓋對整個執行過程的觀察，如此才可以即時並且正確地掌握潛在的問題。
監控最重要的意義就在於，透過有規律的觀察與測量計畫的執行，精準地將偏離計畫的點確認出來。

83 在流程中的檢覈

84 測量計畫進行中的各項行動 (where we are);
基於原始計畫規劃以及預期成果，來監督計畫中的各種變數(成本、努力...) (where we should be); 確認達成目標、發展適當議題與規避風險所需要的正確行動(How can we get on track again); 改變組織的因素組合，以避免不可欲的變遷，朝向希望變遷的方向來執行。

85 在多階段計畫中，監控可以提供階段性的回饋，一方面可以讓計畫按照原規劃的正確方向進行，另一方面也可以避免過度順從計畫而導致風險預防機制的失靈。
基本上計劃運作的維繫可包括:

86 最終產品使用者的持續支持 修正錯誤 不斷連續地更新計畫的軟體設備與知識 監控者能夠注意到，隨時有效地解決最終產品使用者的問題。

87 任何一種計畫都會在過程中不斷改變，可能是因為必要的原因所做的修正：不同的環境條件變化、可運用物資的變動、契約要求改變、價值變遷、第三者出現等等。
但是這些改變應該被記錄下來以呈現計畫變遷的真實面，透過解讀不斷出現的事件，來理解計畫的可行性，作為往後的參考。這些紀錄甚至可以成為契約變動或設計的一部份。

88 結案期 結案指正式接受計畫的成果與結束計畫關係，行政上包括相關的書面文獻與檔案，涵蓋兩部份： 結束計畫中各階段以及利害關係人的所有活動。
契約終止。

89 專案管理不善或失敗的原因 缺乏一個明確或共同願景的目標 專案進行期間改變方向 優先事項彼此相互衝突 不實際的期待
種種的資源不足(時間、金錢、設備、知識、專業) 溝通不良 無法達成顧客期待 規劃不善或根本無規劃 沒有明確方法

90 感謝聆聽

91 工具 以下工具可以協助專案計畫者去依據利害關係人之要求來達成標的以及各方的期待 溝通計畫 治理模式 風險登記 事件表 計劃圖 行動項目表
資源管理計畫 計畫時程表 計畫現狀成果報告 責任分派表 學習資料成果 利害關係人分析 文件管理 計劃圖 工作說明書 商業個案可性分析 專業說明書 專案管理計畫書 工作展開結構圖 變革控制計畫 風險管理計畫 風險展開計畫

92 工具(二) Financial tools Cause and effect charts
Online Project Health Check tool (Ph-Check tool) Pert charts Gantt charts Event chain diagrams RACI diagram Run charts Project Cycle Optimisation (PCO) Participatory Impact Pathways analysis (An approach for developing common understanding and consensus amongst project participants and stakeholders as to how the project will achieve its goal) Project management software

93 例：軟體業的專案管理模型 Rational Unified Process，RUP
Inception - Identify the initial scope of the project, a potential architecture for the system, and obtain initial project funding and stakeholder acceptance. Elaboration - Prove the architecture of the system. Construction - Build working software on a regular, incremental basis which meets the highest-priority needs of project stakeholders. Transition - Validate and deploy the system into the production environment