第二章 專案管理過程、階段和生命週期

專案階段的劃分 2

(1)定義專案與決策階段 (2)規劃和設計專案階段 (3)實施與控制專案階段 (4)結束專案與交付階段 3

專案生命週期內的典型階段序列(資料來源：PMI,2004, “PMBOK”)

專案管理過程 Project Management Process 5

專案全過程 ◎過程的主要兩個作用： (1)標準化過程提高工作效率 (2)過程有繼承經驗學習的作用 ◎根據《ISO10006》國際標準，一般「專案」是 由兩種類型的專案過程構成： 專案實現過程(project perform processes) (2) 專案管理過程(project management processes)

專案全過程 某系統整合公司專案管理流程[範例] 1.0 初始階段 2.0 規劃階段 3.0 選型階段 4.0 實施階段 5.0 維運階段 6.0 支援階段 1.1任命專案經理 1.2評估投標書 1.3授權投標 1.4品質審核 2.1準備技術方案 2.2定義專案範疇和初步工作分解 2.3制定初步工作進度表 2.4定義資源需求 2.5制定風險管理計劃 2.6制定其他的初步計劃 2.7制定專案預算 2.8解決專案計劃 中的矛盾與衝突 2.9專案計劃的品 質審查 2.10準備建議書並提交給客戶 2.11品質審核 3.1就方案建議書達成一致 3.2確定最終的建議書並獲得認可 3.3合約談判 3.4品質審核 4.1專案正式啟動 4.2專案進度控制 4.3專案成本控制 4.4實施方案 4.5專案結束 4.6品質審核 5.1保修與維護 5.2品質稽核 6.1提供支援服務 6.2品質量測 6.3品質稽核 某系統整合公司專案管理流程[範例] 7

專案管理過程群組 (1)啟動過程組(initiating processes) (2)規劃過程組(planning processes) (3)執行過程組(executive processes) (4)控制過程組(controlling processes) (5)結束過程組(clusure processes) 一連串行動(Action) A A+

專案管理過程的描述 限制(約束)：Constraints 時間、費用、品質、技術及其他性能參數、法律、環境等 產出(成果)：Output 成果 – 專案可交付物、產品或服務 輸出 – 專案管理計畫、專案實施記錄文化及其他活動產出 投入(依據)：Input 商業機會 客戶需要及需求 組織策略 專案資源 專案過程 專案導向成果過程 專案管理過程 輸入。這是一個專案管理具體過程從上一個專案管理具體過程所獲得的給定檔、資訊和資料。它們是前一個專案管理具體過程所生成的輸出。一個專案管理具體過程的輸入是這一過程中所開展的管理工作與專案實現工作的依據。例如，一個“計畫過程”所獲得的輸入是開始實施一個專案階段的決策檔和資訊與資料；一個“實施過程”所獲得的輸入是包括各種計畫檔和相關技術檔和資訊與資料。 活動/過程。這是指在一個專案管理具體過程中，將所獲“輸入”轉變成的“輸出”所開展的工作和活動。不同的專案管理具體過程有不同的輸入轉為輸出的具體活動，這些活動構成了一個專案管理的具體過程。在一個專案管理具體過程的活動中，有些活動是核心性活動，有些是輔助性活動。例如，在“計畫過程”、“實施過程”和“控制過程”中都有一系列核心性活動和相應的一些輔助性活動。 工具、方法和技術。這是指在一個專案管理具體過程中，在將“輸入”轉成“輸出”的過程中所使用的方法和工具。其中，工具是轉變過程中所採用的具體技術手段，方法是轉變過程中所使用的程式和做法。例如，“控制過程”中使用的各種控制圖表就屬於工具的範疇，而所採用的事前控制、事中控制和事後控制的程式和做法就屬於方法的範疇；而在“計畫過程”中所使用的“甘特圖”就屬於工具，但採用的專案計畫評審法（PERT）或關鍵路徑法（CPM）則屬於方法的範疇。 輸出。這是一個專案管理具體過程所產生的，以檔或資訊的形式給出的結果。例如，一個“計畫過程”的輸出就是各種計畫檔和相應的一些資訊與資料等。這些輸出的檔、資訊和資料既是一個專案管理具體過程的輸出，又是下一個專案管理具體過程的輸入，或者是下一個專案階段的輸入。例如，一個“計畫過程”輸出的各種計畫檔和資訊與資料是“實施過程”和“控制過程”的輸入，而一個“結束過程”輸出的各種檔、資訊和資料是下一個專案階段的“起始過程”的輸入。 機制：Mechanism 人、技術、工具和方法，設備、組織等 專案管理過程圖示

專案管理過程的描述 (1)輸入(input) (2)活動/過程(activity/process) (3)工具、方法和技術(tools, methods, techniques) (4)輸出(output) 一連串行動(Action) A A+ 10

專案生命週期 Project Life-cycle 11

專案生命週期的定義 因專案具有一定程度的不確定性，且因複雜性與行業別不同，其週期亦有所不同: 如軟體業- 需求分析、概念設計、詳細設計、編碼、測試安裝、交付運行 建築業 專案的各個階段構成專案的整個生命週期(Project Life Cycle)。 實施專案時，通常會將每個專案分解為幾個專案階段(Project Phase)，以便有更好的管理和控制。

專案生命週期的內容 一般專案生命週期四個階段一覽表 階段 萌芽期 成長期 成熟期 衰亡期 工作名稱 建議、立案與 開始 規劃、設計與 評價 執行、控制與 矯正 結束或終止 管理對象 專案定義 範疇與經營目標 功能設計 可行性研究 初步估算(30%) 開始決策過程 系統設計 系統規劃和資源 審查估算(10%) 系統評價 批准 教育訓練和溝通 細部規劃和設計 控制估算(5%) 工作分配 過程監視 績效量測 完成情況預測 控制和矯正 工作完成 系統投入使用 達到利潤目標 遣散專案團隊 獎勵專案團隊 稽核與總結 紀錄歸檔專案團隊 一般專案生命週期四個階段一覽表 13

專案生命週期的內容 (1)專案的時限 (2)專案的階段 (3)專案的任務 (4)專案的成果 14

專案生命週期的階段 專案階段是以一個或一個以上交付標的之完成為標的。 這種交付標的是有形的，且可鑑定的，以利管理控制。 例如一份可行性報告、 設計圖、 工作模型。 一個專案階段的結束，通常對此階段的交付成果和績效進行審查－決定下個階段是否繼續或終止。 phase exits /stage gates /or kill points

專案生命週期的階段 一般意義上專案生命週期階段的劃分 16 大多數專案生命週期定義的階段順序通常包含一些技術遷移或移交的形式，如：從需求分析到設計，從建構到運行，或者從設計到生產。每一個專案階段都可以包括一個以上的過程將投入轉換成產出，稱為IPO模式(Input-Process-Output model)，並以完成一項以上的產出或“交付標的(Deliverables)”作為該階段任務結束的標記。”交付標的”是一項可度量的(measurable)、有形的(tangible)且可驗證的(verifiable)工作產品(work product)、結果(result)或項目(item)。“交付標的”和“階段”都是前後順序與邏輯關係的一個部份，以確保專案產品可被適當的定義。一般說來，一個專案階段的結束是以審查主要“交運標的”和專案績效作為註記，並且(a)決定專案是否應進行到下一階段，以及(b)檢定和更正成本效益上的錯誤。如圖所示。 一般意義上專案生命週期階段的劃分 16

專案生命週期的階段 需求階段 規劃階段 執行階段 專案生命週期的階段與IPO過程模式 投入 過程 產出 限制 方法、技術 與工具 17 大多數專案生命週期定義的階段順序通常包含一些技術遷移或移交的形式，如：從需求分析到設計，從建構到運行，或者從設計到生產。每一個專案階段都可以包括一個以上的過程將投入轉換成產出，稱為IPO模式(Input-Process-Output model)，並以完成一項以上的產出或“交付標的(Deliverables)”作為該階段任務結束的標記。”交付標的”是一項可度量的(measurable)、有形的(tangible)且可驗證的(verifiable)工作產品(work product)、結果(result)或項目(item)。“交付標的”和“階段”都是前後順序與邏輯關係的一個部份，以確保專案產品可被適當的定義。一般說來，一個專案階段的結束是以審查主要“交運標的”和專案績效作為註記，並且(a)決定專案是否應進行到下一階段，以及(b)檢定和更正成本效益上的錯誤。如圖所示。 17 專案生命週期的階段與IPO過程模式

專案生命週期特性的描述 ◎一般專案生命週期通常規定 (1)專案的各個階段應當從事何種技術工作 (2)專案的各個階段可交付成果應何時產生，以及如 何審查(review)、驗證(verify)和確認(validate) (3)專案的各個階段有哪些人參與，及他們的工作 內容 (4)如何控制和批准專案各個階段 18

專案生命週期特性的描述 利害關係者的影響 強 一個或多個中間階段 最後階段 成本和人力投入的水準 開始階段 變更的代價 弱 專案時間 時間 專案費用與人力投入水準在專案生命期中的典型分佈 強 弱 專案時間 利害關係者的影響 變更的代價 利害關係者影響隨著時間的變化 (a)典型成本和人力投入 (b)專案利害關係人對專案的影響 專案生命週期的特點/特性 19

專案生命週期特性的描述 ◎大多數專案生命週期的說明具有若干共同特點/特性： (1)專案風險的變動 (2)影響力的變動 (3)專案變動的代價 20

專案生命週期與階段 階段 可能的選擇 1 提議階段、建議階段、概念階段、開始階段、構思階段、產生想 法階段 2 初始調查階段、預期可行性階段、初期評估階段、初步調查階 段、評估階段、研究階段 3 詳細調查階段、可行性階段、定義階段、商業案例階段、評估階 段、授權階段 4 開發與測試階段、實施階段、執行階段、實現階段、開發階段、 生產階段、建造階段、製造階段 5 試驗階段、貝塔測試階段、確認階段、試運行階段 6 發佈階段、公佈階段、實施階段、移交階段、接受階段 7 實施後審查階段、商業回顧、專案審計階段、專案事後審查階段 在不同的組織、公司及不同商業專案，可能會在專案的各階段有不同的名稱。表1-2是可能的階段名稱選擇。你可以自己選擇並決定它們的名稱，但這種決定是很重要的。使用相同的詞語將有助於所有關係人的溝通，因此，你在選擇這些詞語時，必需保證它們的意思和你希望取得的目標相一致就可以了。 階段名稱的選擇 [舉例] 21

專案生命週期與產品生命週期的關係 專案生命週期與產品生命週期的關係《PMBOK指南：2008》 22 說明]專案生命週期和產品生命週期是不同的，區分兩者非常重要。專案生命週期可以用到所有類型的專案，不管專案是生產什麼產品；而產品生命週期則根據產品屬性的不同卻會有很大的不同，這裡面存在一般(專案生命週期)與個別(產品生命週期)之間的關係。 專案生命週期與產品生命週期的關係《PMBOK指南：2008》 22

專案生命週期的實例 23

工業工程相關的典型專案生命週期 一般工程建設專案的生命週期描述 (1)專案可行性研究與立案階段 (2)專案計畫與設計階段 (3)專案實施階段 (4)交付使用階段 The project life cycle defines the phases that connect the beginning of a project to its end. 24

工業工程相關的典型專案生命週期 「營建工程」專案生命週期 25 The project life cycle defines the phases that connect the beginning of a project to its end. 25 「營建工程」專案生命週期

工業工程相關的典型專案生命週期 美國國防部專案的生命週期描述 (1)使命與任務需求確定階段 (2)概念擴展和定義階段 (3)展示與驗證階段 (4)工程與製造開發階段 (5)生產與開發階段 (6)運作與支援階段 The project life cycle defines the phases that connect the beginning of a project to its end. 26

工業工程相關的典型專案生命週期 美國國防部5000.2條令之武器獲得生命週期 27 The project life cycle defines the phases that connect the beginning of a project to its end. 美國國防部5000.2條令之武器獲得生命週期 27

工業工程相關的典型專案生命週期 美國新藥物開發專案的生命週期描述 藥品開發專案生命週期 28 The project life cycle defines the phases that connect the beginning of a project to its end. 28 藥品開發專案生命週期

工業工程相關的典型專案生命週期 美國新藥物開發專案的生命週期描述 (1)立案申報和可行性研究 (2)發現和搜尋階段 (3)臨床前開發階段 (4)註冊實驗階段 (5)後期審驗階段 The project life cycle defines the phases that connect the beginning of a project to its end. 29

資訊系統領域常見的典型專案生命週期模型 瀑布模型 瀑布模型是一個經典的軟體生命週期模型，一般將軟體開發分為：可行性分析（計畫）、需求分析、軟體設計（概要設計、詳細設計）、編碼（含單元測試）、測試、運行維護等幾個階段，如圖1-28所示。瀑布模型中每項開發活動具有以下特點： 從上一項開發活動接受該項活動的工作對象作為輸入。 利用這輸入，實施該項活動應完成的工作內容。 給出該項活動的工作成果，作為輸出傳給一下項開發活動。 對該活動的實施工作成果進行評審。若其所作成果得到確認，則繼續進行下反復。以較小的成本/費用來開發軟體。 瀑布模型(waterfall model)是建立在一定的假設基礎之上，即假設直到工作上游(upstream)的不確定性問題得到瞭解決並已經滿足了主要控制關口(control gates)的審查要求後，下游(downstream)的工作才能開始。這個由Winston W. Royce[1] 博士發明的圖解表示方法將軟體專案週期表示為一連串的對角線步驟，垂直地從左上方走到右下方。把這個圖形叫做瀑布模型的原因是由於專案活動以不連續的順序，按照線性的階段從上端進行到下端。但是，對於一些複雜的高風險的專案來講，這種模型是不適用的。美國總會計署(General Accounting Office)的一名電腦科學家Rona Stillman認為：「瀑布模型是一種風險很高的模型。這種模型鼓勵進行不實際的成本和進度估算，促使了自由開發問題(problem free development)的出現。」 像硬體造型一樣，在專案週期的早期，經常需要進行軟體的設計和編碼，以便確保正確理解需求並証明技術可行。由於這些原因，很多組織並沒採用這些模型或者是相似的模型。對於許多實際情況來說，這種模型並不適用。 [1] Winston W. Royce,“Managing the Development of Large Software Systems,”Proceedings, IEEE WESCON, (August 1970), pp. 1-9.

資訊系統領域常見的典型專案生命週期模型 ◎瀑布模型具有以下特點： (1)從上一項開發活動接受該項活動的工作對象作為 輸入 (2)利用這輸入，實施該項活動應完成的工作內容 (3)給出該項活動的工作成果，作為輸出傳給一下項 開發活動 (4)對該活動的實施工作成果進行評審 The project life cycle defines the phases that connect the beginning of a project to its end. 31

資訊系統領域常見的典型專案生命週期模型 螺旋模型 (1)概念驗證迴圈階段 (2)初始系統建設迴圈階段 (3)中間系統建設迴圈階段 (4)最終系統建設迴圈階段 The project life cycle defines the phases that connect the beginning of a project to its end. 32

資訊系統領域常見的典型專案生命週期模型 螺旋模型 螺旋模型是一個演化軟體過程模型，將原型實現的迭代特徵與線性順序(瀑布)模型中控制的和系統化的方面結合起來。使軟體的增量版本的快速開發成為可能。在螺旋模型或原型；在以後的迭代中，被開發系統的更加完善的版本逐步產生。螺旋模式的整個開發過程如圖1-29所示。圖的螺旋線代表著隨著時間推進的工作進展；開發過程具有週期性重複的螺旋線狀。四個象限分別標誌每個週期所劃分的四階段：制定計畫、風險分析、實施工程和客戶評估。螺旋模型強調了風險分析，特別適用於龐大而複雜的、高風險的系統。 螺旋模型(spiral model)由貝姆(Barry W. Boehm)[1] 博士發明，在軟體開發專案中應用很廣。為了彌補上面提到的不足之處，貝姆博士提出有必要盡早理解需求和可行性造型。雖然這種模型的確實現了減小風險的目標，但應注意到其螺旋形的表示容易令人混淆，放射狀的時間表示與傳統的由左到右的時間表示不一致；而且這種模型掩蓋了對基準演變的控制進行審查的必要性。它的另一個缺點是將風險管理描述成了先行進行的，並且延誤了低風險產品開發過程的一連串的分析活動(在左上象限)，而不是把風險管理看成是與正在進行的開發過程同時進行的工作。 [1] B.W. Boehm, "A Spiral Model of Software Development and Enhancement," Tutorial: System and Software Requirements Engineering ,eds. R.H. Thayer and M. Dorfman (Washington, DC: IEEE Computer Society Press,1990), pp. 513-527. 螺旋模型

資訊系統領域常見的典型專案生命週期模型 Vee字模型 Forsberg, Mooz & Cotterham以系統工程程序為基礎，從專案管理的技術構面包括分解(decomposition)、定義(definition)、整合(integration)和驗証)(verification)的序列活動，如圖1-30所示的基本V模型。當改為V模型的形式而不是以原先的水平圖的形式來描述時，這個過程就可以被清楚地呈現在面前。它以圖解說明了：從系統需求和概念向下分解為詳細的部件和組合件之過程，然後相對應一致地將系統元素向上製造和整合為完整的系統之過程。同時，Vee模型也包括了與機會和風險管理相關的活動。基本的Vee模型與20世紀1980年代後期曾經流行一時的NASA的軟體管理和保証大型專案(NASA’s Software Management and Assurance Program)的方法很相似。在專案週期技術構面的形象化(可視化)過程中，一個重大進展就是利用基本的Vee模型精確地描述了機會和風險管理的相關活動。[1] 在專案經理和客戶同意以專案的進展為基準和對新的基準實施正式的變更控制之前，專案工作不應該超出已經決定的範圍。與常用的瀑布模型不同，Vee模型可以在專案週期的任意一點進行初步設計和分析，以觀察和証明所考慮的概念。 雖然Vee模型很適用於專案管理週期中技術構面之系統工程的展開，它只是企業全面專案管理更細節的系統工程程序，還是無法表示從策略規劃到專案執行高層次的管理過程。 [1] K. Forsberg and H. Mooz, "The Relationship of System Engineering to the Project Cycle," Proceedings of the National Council for System Engineering Symposium, (Chattanooga, TN: October 1991), pp. 57-65。

資訊系統領域常見的典型專案生命週期模型 迭代模型 部署 測試 實現 分析與設計 需求獲取 業務建模 移交階段 構造階段 細化階段 初始階段 核心工作流 專案生命週期 在大多數傳統的生命週期中，階段是以其中的主要活動命名的：需求分析、設計編碼、測試。傳統的軟體開發工作大部份強調一個序列化過程，其中一個活動需要在另一個開始之前完成。在迭代式模型的過程中，每個階段都包括不同比例的所有活動。 迭代式開發模型如圖1-31所示，水平方向為時間維，從組織管理的角度描述整個軟體開發生命週期，分四個階段：初始、細化、構造、移交，可進一步描述為週期（Cycle）、階段(Phase)、迭代(Iteration)；核心工作流從技術角度 描述迭代模型的靜態組成部份，包括：業務建模、需求獲取、分析與設計、實現、測試、部署。圖中的陰影部分描述了不同的工作流，在不同的時間內工作量的不同，幾乎所有的工作流在所有的時間段內均有工作量，只是大小不同而已。 各階段的主要任務如下所述： 初始階段：系統地闡述專案的範圍，選擇可行的系統構架，計畫和準備業務案例。 細化階段：細化構想，細化過程和基礎設施，細化結構並選擇構件。 構造階段：資源管理、控制和過程最優化，完成構造的開發並依評價標準進行測試根據構想的驗收標準評估產品的發佈。 移交階段：同步並使開發的構造增量整合到一致的實施基線中，與實施有關的工程活動（商業包裝和生產、人員培訓等）根據完整的構想和需求集的驗收標準評估實施基線。

資訊系統領域常見的典型專案生命週期模型 迭代模型 (1)初始階段 (2)細化階段 (3)構造階段 (4)移交階段 36 在大多數傳統的生命週期中，階段是以其中的主要活動命名的：需求分析、設計編碼、測試。傳統的軟體開發工作大部份強調一個序列化過程，其中一個活動需要在另一個開始之前完成。在迭代式模型的過程中，每個階段都包括不同比例的所有活動。 迭代式開發模型如圖1-31所示，水平方向為時間維，從組織管理的角度描述整個軟體開發生命週期，分四個階段：初始、細化、構造、移交，可進一步描述為週期（Cycle）、階段(Phase)、迭代(Iteration)；核心工作流從技術角度 描述迭代模型的靜態組成部份，包括：業務建模、需求獲取、分析與設計、實現、測試、部署。圖中的陰影部分描述了不同的工作流，在不同的時間內工作量的不同，幾乎所有的工作流在所有的時間段內均有工作量，只是大小不同而已。 各階段的主要任務如下所述： 初始階段：系統地闡述專案的範圍，選擇可行的系統構架，計畫和準備業務案例。 細化階段：細化構想，細化過程和基礎設施，細化結構並選擇構件。 構造階段：資源管理、控制和過程最優化，完成構造的開發並依評價標準進行測試根據構想的驗收標準評估產品的發佈。 移交階段：同步並使開發的構造增量整合到一致的實施基線中，與實施有關的工程活動（商業包裝和生產、人員培訓等）根據完整的構想和需求集的驗收標準評估實施基線。 36

Q & A