專案管理

內容大綱• 導論• 瞭解專案• 界定範圍• 工作規劃• 更改管理• 品質管理• 風險管理• 專案的執行• 專案的評估與控制• 結論

導論

• 「專案」（ Project ）是一項在預定的時間內投入預定的資源，以達到特定目標的工作，專案管理則是應用管理的原則及方法，使專案得以順利進行達成預定目標。

• 引進專案管理的方法可使系統的開發做的更好。

瞭解專案• 探討下列議題有助於對專案的瞭解：

– 專案是如何開始的？– 主要的使用者是誰？– 意見的主導者在那裏？– 那些人或部門是專案的倡導者？反對者？旁觀

者？– 是否有相關的專案？關係如何？– 高階管理者與顧客對時間、金錢、品質與信譽

等因素的優先順序為何？– 重要的人員及角色為何？

界定範圍• 主要是定義那些工作該做，那些不必做，

交付什麼項目與內容等。• 範圍失控會引發專案管理的問題，例如：

– 成本的超支– 時效的延誤– 需求的衝突– 設計的更改– 管理的複雜度提高

界定範圍 (c.2)

• 界定範圍是一個討論、溝通、與協調的過程，過程中應考量時間的限制，資源的多寡和顧客的優先順序等。

• 界定範圍的方法可透過工作分解圖（ Work Breakdown Structure, WBS ）將系統的功能加以展開，在決定那些功能要納入專案時，應注意有那些功能無法分割，有那些可分階段來進行，有那些功能可以縮減等。

系統功能的工作分解圖

剪下 複製 貼上 刪除 全選

系統

檔案處理 撿視

開啟檔案 關閉檔案

編輯

縮放 工具列

縮小 放大

工作規劃• 工作規劃包含

– 預算規劃– 時程規劃– 人力規劃

工作規劃 (c.2)• 預算規劃

– 可以從由上而下 (Top-down) 和由下而上 (Bottom-up) 兩種角度來執行。

– 由上而下的方法：• 將專案的總預算依某個百分比分配到各階段，此一

百分比是一個過去經驗的平均值，對於特殊的情形再予以調整。

– 由下而上的方法：• 由工作分解圖中所列的功能逐一估計所需之成本，

由下而上加總後得到的預算估計。– 這兩種方法可並行使用，以相互對照比較。

工作規劃 (c.3)

• 預算可依下列項目加以細分：1. 技術部門人事費用

包括專案經理的費用、技術人員的費用、及助理人員的費用。

2. 資本支出從事專案所需的軟硬體設備、辦公設備等。

3. 費用 (Expenses)

各階段發生的旅費、顧問費、訓練費用等。4. 經常費用 (Overhead)

包括行政人員的分攤費用、水電費、辦公用品費用、保險費、管理費用等。

工作規劃 (c.4)

• 時程規劃– 目的在於定義：

• 專案的活動•每個活動所需的時間•活動的先後順序及起始／完成日期

工作規劃 (c.5)

• 時程規劃可依下列步驟進行： 1. 將專案的活動依工作分解圖展開。

– 工作分解圖的最底層便是所要執行的工作，– 工作分解圖之詳細程度可以責任劃分清楚，

容易管理為原則。

專案活動的工作分解圖

系統分析與設計

環境模式建立 流程塑模 資料塑模 模組設計 測試計畫

專案

需求分析 編碼

需求擷取 需求認證

工作規劃 (c.7)

2.找出活動的先後順序並劃成 PERT （ Program Evaluation and Review Technique ）圖。

–每一框框表示一個對應於工作分解圖的活動，箭頭表示活動的先後關係。框框內左邊的數字表示工期，右邊的數字表示寬延時間或浮動時間（ Floating Time ）。

–寬延時間是活動可延遲而不致影響整體完成時間的容許範圍。

工作規劃 (c.8)

需求分析

0 w 0 w89/1/10 89/1/10

流程塑模

4 w 0 w89/1/24 89/2/20

資料塑模

2 w 2 w89/1/24 89/2/6

模組設計

4 w 0 w89/2/21 89/3/19

測試計畫

4 w 6 w89/1/10 89/2/6

程式編碼

0 w 0 w89/3/19 89/3/19

環境模式建立

2 w 0 w89/1/10 89/1/23

PERT 圖（欄位左表工期、欄位右表寬裕時間）

需求分析→環境模式建立→流程塑模→模組設計→程式撰寫為要徑。

工作規劃 (c.9)

3.找出要徑（ Critical Path ）及各活動的寬延時間。

–要徑是活動的總工期最大的一條路徑。–要徑上的寬延時間均為零，表示此路徑上的活動均不得延誤，才不會影響整體專案的完成時間。

工作規劃 (c.10)

4. 將活動的起迄時間轉為甘特圖。–首先，假設所有活動都從「最早開始

時間」就開始，並不考慮寬延時間。–並開始人力規劃，圖形下半部表示人

力資源之需求量。

不考慮任何調整下之人力分配

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

任務名稱 工期 寬延時間

需求分析 0 w 0 w

環境模式建立 2 w 0 w

流琵塑模__ 4 w 0 w

資料塑模 2 w 2 w

模組設計 4 w 0 w

測試計畫 4 w 6 w

琵式編碼__ 0 w 0 w

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00 年

200%

400%

600%

800%

1,000%

1,200%

最大資源量 :

SA 過度分派 : 分派 :

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00年

600% 600% 1,200% 1,200% 400% 400% 400% 400% 400% 400%

不考慮任何調整下之人力分配

• 上圖中，假設– 環境模式建立需要 3 人，– 流程塑模需要 4 人，– 資料塑模需要 5 人，– 模組設計需要 4 人，– 測試計畫需要 3 人，

• 則最高之人力需求為 12 人，最低為 4 人，起伏頗大。

工作規劃 (c.13)

5. 資源過度分配及不平衡的情形可考量人員調配、資源限制等因素，利用寬延時間的彈性，進行資源平滑（ Leveling ）。

平移活動以達到資源平滑

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

任務名稱 工期 寬延時間

需求分析 0 w 0 w

環境模式建立 2 w 0 w

流琵塑模__ 4 w 0 w

資料塑模 2 w 0 w

模組設計 4 w 0 w

測試計畫 4 w 6 w

琵式編碼__ 0 w 0 w

1/10

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

SA[300%]

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

SA[400%]

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

SA[500%]

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

SA[400%]

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

SA[300%]

200%

400%

600%

800%

1,000%

:最大資源量

SA :過度分派 :分派

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00年

600% 600% 700% 700% 900% 900% 400% 400% 400% 400%

任務名稱 工期 寬延時間需求分析 0 w 0 w

環境模式建立 2 w 0 w

流程塑模 4 w 0 w

資料塑模 2 w 0 w

模組設計 4 w 0 w

測試計畫 4 w 6 w

程式編碼 0 w 0 w

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00 年

200%

400%

600%

800%

1,000%

最大資源量 :

SA 過度分派 : 分派 :

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00 年

600% 600% 700% 700% 900% 900% 400% 400% 400% 400%

平移活動以達到資源平滑

• 上圖中，利用寬延時間的彈性將「資料塑模」的工作延後兩週所得的人力分配圖。

• 未平滑前的尖峰人力需求為 12 人，平滑後降為 9人。

分割活動以達到資源平滑

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/300年

任務名稱 工期 寬延時間

需求分析 0 w 0 w

環境模式建立 2 w 0 w

流琵塑模 _. 4 w 0 w

資料塑模 2 w 2 w

模組設計 4 w 0 w

測試計畫 4 w 4 w

琵式編碼 _ 0 w 0 w

1/10

SA[300%]

SA[400%]

SA[500%]

SA[400%]

SA[300%]

3/19

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00 年

200%

400%

600%

800%

1,000%

最大資源量 :

SA 過度分派 : 分派 :

1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3

00 年

600% 600% 900% 900% 700% 700% 400% 400% 400% 400%

分割活動以達到資源平滑• 上圖中，是依分割活動的方法將「測試計畫」活動的工作拆開，結果尖峰人力需求由原來的 12 人再降為 9 人，同樣可以達到人力需求的穩定性。

工作規劃 (c.18)

Try this exercise !

02/7/21 02/7/27

1week

A

02/7/28 02/8/17

1week3weeks

B

02/7/28 02/8/31

5weeks

F

02/9/1 02/10/12

6weeks

G

02/8/25 02/9/7

2weeks

C

02/8/25 02/9/21

4weeks

D02/9/22 02/10/5

2weeks

E

02/10/13 02/10/26

2weeks

H

預計開始日期 預計結束日期

寬延時間工期

工作名稱

工作規劃 (c.19)

Critical Path = A-F-G-H

02/7/21 02/7/27

0 week1week

A

02/7/28 02/8/17

1week3weeks

B

02/7/28 02/8/31

0 week5weeks

F

02/9/1 02/10/12

0 week6weeks

G

02/8/25 02/9/7

2 weeks2weeks

C

02/8/25 02/9/21

0 week4weeks

D02/9/22 02/10/5

1 week2weeks

E

02/10/13 02/10/26

0 week2weeks

H

預計開始日期 預計結束日期

寬延時間工期

工作名稱

工作規劃 (c.20)• 上圖中，假設

– A 需要 3 人，– B 需要 5 人，– C 需要 2 人，– D 需要 4 人，– E 需要 2 人，– F 需要 6 人，– G 需要 5 人，– H 需要 4 人。

工作規劃 (c.21)

• 經過調整，尖峰人力需求由原來的 12 人降為 11人。

更改管理

• 更改管理 (Change Management) 是針對文件、程式、工具及開發環境加以控管，所有的更改都在一定的程序下接受管制。

更改管理 (c.2)

• 更改要求（ Change Request ）必須經由一定的程序處理。

• 審核小組審核時，要考慮下列議題：– 更改是否必要？有否有替代方案？– 更改後連帶影響的項目是什麼？是否已一併提

出更改？– 對時程、成本、人員調度的影響有多大？

• 審核小組對提出的更改可以接受、拒絕或做適當的處置，例如：暫時接受但延到下個版本再行更改等。

更改管理 (c.3) 開 始

提出更改要求

主管單位簽核

更改控制委員會審核

是否受理

交付開發團隊處理

進行修改、更新

進行測試

?通過

提供相關基線

提供測試資料

建立新基線更新版本

基線集中管理

要求提供相關基線( )文件、原始碼

要求提供測試資料

是否

是

否

結 束

更改管理 (c.4)

• 基線 (Baseline) ：– 所有列入集中管理的文件、程式、工具、和平台。

品質管理• 要做好品質必須在開發階段的早期就將

– 品質納入規劃，即所謂的 “ Planned In” ，– 接著在設計階段把所需要的品質設計進去，稱

為 “ Designed In” ，– 最後才到執行及測試檢驗階段進行稱為 “ Test

Out” 。

品質管理 (c.2)

• 將品質保證由後階段的測試，移到前階段的分析與設計是一項進步的觀念。

• 因為一個錯誤的發生若未及時去除而延至測試階段，甚至到了顧客手中才發現，則修改之成本將數倍甚至數十倍於一發生便立即去除的成本。

品質管理 (c.3)

• 兩種常用於軟體開發的品質管理方法為：– 審查 (Review)– 檢驗 (Inspection)

品質管理 (c.4)• 審查 (Review)

– 是透過會議的方法來找出潛在的錯誤，以確保品質。可在不同的階段進行，要求的正式程度也有不同，正式審查的程序包含下列步驟：

1. 開發者準備審查資料，並事先發給參與審查的人員。2. 參與審查的人應事先閱讀資料，並依個人專長找出潛在的問題。

3. 選定適當的人當主席。4. 由開發者向大家提出報告。5. 審查者依一定的議程及檢核表逐一審查。6. 審查後應做出審查通過、不通過、或條件通過之決

定，若不通過則應修改後擇期再審；條件通過則在滿足附帶條件後便予通過，不必再審。

7. 記錄審查的結果以累積經驗。

品質管理 (c.5)

• 為使審查能順利進行，並達到儘早發現錯誤的目的，一些重要的會議原則對審查的效果有很大的幫助，茲介紹如下：1. 會議應事先安排議程，並應控制會議時間在 2小時內，以提高會議的效率。

2. 主席對審查的內容應有充分的瞭解，事先閱讀會議資料才能控制會議的進行，使參與者針對問題及避免發言的內容偏離主題。

3.審查的重點在於指出問題和提供方向，而非提供技術性的解答，以免花太多的時間在細節上。

品質管理 (c.6)4.避免人身攻擊和引起爭辯，主席要適當引導會

議的進行，即時進行裁決。5.審查期間，正式的文件應予凍結，等通過後再

解凍以避免不一致。6.參與審查的人員應包括系統開發者、使用者及

品質保證人員，必要時可增加外來的專家或顧問。

7. 會議的記錄應有顧客的簽名，表示對系統開發進行到現階段結果之認同。

8.審查之會議記錄應保留，錯誤的發現與解決就是經驗的累積。

品質管理 (c.7)• 檢驗 (Inspection)

– 檢驗和審查有相輔相成的效果，它有別於審查的特點是

1. 由有經驗的專家來檢驗：一般的審查較為浮面，檢驗則可深入技術的問題或專注於較複雜的問題。

2.檢驗設計文件或程式碼，而非只是計畫或構想。3.檢驗須依特定的步驟進行，其步驟為規劃、對檢驗者

的簡報、會前準備、會議進行、重做及跟催。4.檢驗須有特定的角色扮演，包括主持人、記錄人、閱讀人及原作者等。

5. 原作者的參與。原作者在場並參與檢驗可節省檢驗者的時間及快速的進入問題核心。

品質管理 (c.8)

• 檢驗除了可提早發現錯誤以提高品質外，也可以減低測試的負荷。由於檢驗在錯誤發現上比測試更符合成本效益，因此檢驗也有提高生產力的效果。

風險管理• 風險可定義為足以危害專案成敗的事件，

這些事件未必發生，然一旦發生可能導致嚴重的後果。

• 風險管理也是軟體生命週期 ( 軟體開發過程 ) 的每一階段都該進行，其步驟如下：

風險認定→風險評估→風險排序→風險規劃→風險解決→風險追蹤

風險管理 (c.2)1. 風險認定 (Risk Identification)

– 風險認定在於找出風險的來源，並判定是否屬於風險管理的範圍。

– 專案所涉及的風險，例如：• 人員風險：重要人員的離職或缺乏可勝任的人員。• 技術風險：使用了錯誤或不成熟的技術、關鍵技術無

法突破。• 顧客風險：顧客需求變動頻繁、使用者配合度不佳、承辦人員變動等。

• 市場風險：同業的競爭導致市場需求變化。• 政治風險：政策急轉彎，利益衝突等。

風險管理 (c.3)2. 風險評估

– 找出風險後必須評估其發生的機率大小，以及一旦發生後可能帶來的損失，兩者的綜合即為風險的大小，總風險的大小可以下表示：Ｒ＝ where

Ｒ：總風險大小Ｐ i ：第ｉ項風險發生的機率，

0 Ｐ i 1

Ｃ i ：第ｉ項風險發生的成本損失

ｎ :　風險項目的總數– 在實務上，風險機率及風險損失的估計無法非常精確，因此可以不同的等級來代表，例如風險機率分為１至５等，風險損失分為１至１０等，兩者的乘積則視為風險的大小。

n

iiicp

1

風險管理 (c.4)

3. 風險排序– 依風險的大小排序，挑出重要的風險項目加以

列管。風險的項目很多，風險管理也必須付出成本，因此管理者只能針對重大的風險加以管理。

風險管理 (c.5)4. 風險規劃

– 找出重要的風險後，就應該做適當的規劃，並找出最有效的方法來控制風險，以下是一些風險控制的方法：(1) 風險規避：

• 使用外包或外購將沒有把握的部分委託外人來做，再依合約要求以達專案的目標。

• 刪除高風險的部分。(2) 風險分散：

• 購買保險。• 找別人合作。• 合約中分散責任的歸屬。

風險管理 (c.6)

(3) 風險降低：• 使用較穩健的設計方法。• 避免將關鍵性的工作集中在一個人身上。• 選擇成熟的技術。• 在合約中明定雙方的權責。

風險管理 (c.7)

5. 風險解決 (Risk Resolution)– 風險解決依據風險規畫的內容去執行。解決的

方法可運用模擬法，雛型的建造等。6. 風險追蹤

– 追蹤風險的解決是否有效，若無效應找其他的解決方案。

– 風險也會隨專案的進行而變動，有些消失有些新增，管理者必須定期更新高風險的項目，列入管制並設法解決。

專案的執行

• 在專案的執行過程中，許多專案管理的技巧可以運用，例如– 人員的組織與領導– 使用者的參與– 有效的會議

專案的執行 (c.2)• 人員的組織與領導

– 開發人員的組織與領導包括：人員的招募、培訓、團隊建立、激勵、領導等工作。

– 系統分析師能力的優劣對生產力的影響可高達數倍，可知人員挑選及訓練的重要性。系統分析師是資訊系統發展過程中的重要人物。

專案的執行 (c.3)

– 成功的系統分析師必須俱備四種技巧：分析，技術，管理及人際關係。

– 分析技巧可幫助系統分析師瞭解組織及其功能，找出機會與問題，並分析解決之道。

– 技術技巧幫助分析師瞭解資訊科技的潛能與限制，所以，身為一位分析師必須能設計出一個資訊系統，來幫助使用者解決問題並引導整個系統分析的發展，也要能使用程式語言工具，使用不同的作業系統與電腦硬體平台。

專案的執行 (c.4)

– 管理技巧使得分析師可以有效的管理專案，資源，風險與改變。

– 人際關係技巧可幫助分析師與終端使用者、其他分析師與程式設計師一起工作。分析師也需要扮演一個重要的聯絡溝通角色。此外，有效的書面與口頭溝通，也是分析師必須要精通的技能。

專案的執行 (c.5)– 團隊建立是透過活動的設計，環境的建立和文化的塑造，使一群來自不同背景的人能建立共識和情感，並朝共同的目標努力。

– 團隊建立的一些重要事項為：• 明確宣示專案的目標• 團隊人員參與擬定達成目標的方法以建立共識• 強調團隊而非個人的成果及榮譽• 舉辦聯誼活動以建立情感• 共同的工作地點，共同的標誌，共同的作業環境等，

以提高對團隊的認同• 提供獎勵，以激勵團隊

專案的執行 (c.6)• 使用者參與

– 使用者的參與有助於提高系統開發的成功率，也可以提高系統開發的效率，縮短開發時間。

– 使用者參與也有不同的方式和程度，介紹如下：1.諮詢式參與：

使用者處於被動的地位，只提供資訊給系統開發人員，對系統如何設計沒有控制權，唯有在約定的審查會議或其他正式會議中，才有表達意見的機會。

2.指派代表參與：使用者指派代表參與開發過程，這是一種持續性、長期性的參與，有助於雙方的溝通，並可加速系統開發的腳步。

專案的執行 (c.7)

3.共同開發： 使用者代表不只是配角，而是成為系統開發的一份子，使用者同時要肩負專案成敗的責任，此時系統開發團隊需要更深入瞭解使用者的組織，也需要更多的協商以達共識。

專案的執行 (c.8)• 有效的會議

– 無論是審查會議，使用者參與或團隊的建立，專案執行的過程中，必須透過各種的會議來達到資訊傳達、決策、工作分派、追蹤考核等目的。因此，有效的設計及主持會議是專案管理不可缺的能力。

– 有效的會議應包含下列幾個重要的事項或角色：1. 主持人

• 主持人和會議的成敗有著密切的關係。• 會議的主席或領導者的角色必須要能控制會議的進

行，並引導到預定的目標。

專案的執行 (c.9)2. 議程

• 會議何時召開、在那裏召開、那些人參與、討論什麼、討論的順序為何？每一個環結都會影響到會議的效果。

• 正式的會議應有事先規劃的議程，以確保會議目標的達成。

3.群體互動的機制• 會議要能夠激發創意、匯集多方的知識和經驗、允許批判性的意見、解決衝突及做成決議，這些都需要有群體互動的機制。

4.記錄• 會議應有指定的人做記錄、保存做成的決議、追蹤

管理歷次會議的記錄，如此才能累積經驗。

專案的評估與控制• 控制的機制在於評估執行的過程與結果是

否符合原訂的計劃，若和原先的計劃不符則應採取校正的措施。

• 評估與控制包括下列項目：– 依原定的衡量標準收集專案資料並加以分析，– 將衡量的結果和原計劃互相比較，– 找出差異和問題，– 進行調整並採取校正行動。

• 資料收集的方法必須方便而有效，儘可能使用自動資料收集或輔以管理系統，以減輕人員的負擔。

實際成本與計畫成本的比較

時間

累計成本 實際成本

計畫成本

預算超支部份

結論• 傳統專案管理的目標在於運用管理的技巧，

使專案能夠在預定的時間與預算內達到所要求的目標。因此，對於時程、成本及品質的規劃與控制便成為專案管理的核心。

• 隨著時代的變遷，以顧客滿意為目標的觀念漸受重視，尤其資訊系統的成效在於它對企業經營管理的貢獻，而評估資訊系統成效的是第一線的使用者，因此專案管理應更重視人和企業經營的因素。

結論 (c.2)

• 系統分析與設計階段是軟開發的過程中，開發人員和使用者互動最頻繁的時刻，也是企業經營融入資訊系統的關鍵點。因此，除了傳統上的規劃與控制方法外，也要重視使用者參與，團隊建立，溝通協調，合約談判等。