第四章 專案範疇 課前指引 專案範疇管理最重要的一件事，就是要把專案的範疇確定下來，能夠明確清楚的定義專案範疇，專案可以說已經成功了一半。很多研究報告顯示，專案目標、範疇不清楚，是專案失敗的主要原因。
章節大綱 4-1 定義範疇 4-4 責任矩陣 4-2 工作分解結構圖 4-3 流程分解結構圖
4-1 定義範疇 專案範疇管理最重要的一件事，就是要把專案的範疇確定下來。 很多研究報告顯示，專案目標、範疇不清楚，是專案失敗的主要原因。
4-1 定義範疇 引發專案成立的背後原因，我們稱之為商業需求(business need)。 組織內專案興起背後的商業需求，有可能是因為： 市場需求 組織需要 客戶要求 新技術的興起 法令變更
4-1 定義範疇 任何專案的目標都不應背離了當初的商業需求。 專案範疇(project scope) 是為了要完成專案最後產出，所需要做的所有工作範疇。 專案範疇內所列出的工作如計畫完成，專案自然會產生出預定的成果。
4-1 定義範疇 專案範疇說明書至少要包含以下各項： 專案源起 專案目標 專案組織 專案產出 專案風險 產品概述 技術需求 專案里程碑 專案時程 專案成本 專案組織 專案風險 技術需求 專案利害關係人 假設 限制 完成標準 專案資助人確認
4-2 工作分解結構圖 工作分解結構圖(WBS, work breakdown structure) 是一個很好用的工具，可以協助我們更加清楚專案的範疇。 以專案開始，使用類似家族 族譜方式，往下展開專案的 各個產出項目，直到足夠清 楚為止。展開到最底層的項 目，我們稱為工作包 (workpackage)。
4-2 工作分解結構圖 舉例來說，專案團隊需要每週開專案現況會議，每月須與客戶開會報告專案進度。那麼在工作分解結構圖上，就應該要有這二種不同會議的安排。 至於表現的方式，可以是就一個會議的工作包，也可以是分別兩個工作包。
4-2 工作分解結構圖 有了工作分解結構圖後，專案範疇將更為清楚完整，所有專案利害關係人對專案範疇，都不再會發生認知不同的誤會。 每一個工作包可以指定負責人，責任清楚，容易管理與追蹤。在時間與成本的估算上，也會比較準確。 將工作包估算值，一一往上加總，就可以預估出整個專案的時程與成本。
4-3 流程分解結構圖 流程分解結構圖(PBS, process breakdown structure) 一個可以協助釐清專案範疇的工具，它和工作分解結構圖的不同在於，拆解細化的方式。 工作分解結構圖由產出開始拆解，產出與產出之間沒有特定的時間前後關係。流程分解結構圖則是根據專案進行的過程，依時間前後進行拆解。
4-3 流程分解結構圖 流程分解結構圖(PBS, process breakdown structure) 例如：一項軟體開發的專案，會經由收集客戶需求、系統分析與設計、程式撰寫與測試、最後到安裝上線等程序。流程分解結構圖就由這幾個流程開始，逐步往下細化專案範疇，直到足夠清楚表達該做的事情為止。
4-4 責任矩陣 當專案規模不是太大時，可以用一個比較簡單的方式來呈現專案範疇，叫作責任矩陣(RM, Responsibility Matrix)，或稱為責任指派矩陣 (RAM,Responsibility Assignment Matrix)。 每一項目，一定有一位負責，而且只有一位。工作項目儘量依時間先後，由上而下依序排列。對於小型專案，責任矩陣可以有效率的安排與追蹤專案工作。
4-4 責任矩陣 生日派對責任矩陣
4-4 責任矩陣 責任矩陣除了負責與支援之外，也可以依專案不同需求而有其他責任種類。 RACI Chart 也是一種責任矩陣，但是它定義有四種責任種類： 負責 (R, responsible) 當責 (A, accountable) 諮詢 (C, consult) 知會 (I, inform)。
4-4 責任矩陣 RACI Chart
4-4 責任矩陣 當責A，代表對這件事情的完成要負起滿意的責任。因此，需要監督與支援負責角色，確保完成而且滿意。一般當責者都是負責角色的上司。 負責R，工作是負責角色實際在進行，而當責者有責任時時關心，並在需要時提供支援，使得工作被滿意地接受。 諮詢C，代表的是可以向他請教，並尋求協助。 知會I，則是對此項工作有需要了解，因此對於工作進展必須定期通知。 儘量一項工作只安排一位負責人，以避免相互推諉卸責。
4-4 責任矩陣 責任矩陣也可以和工作分解結構圖在專案中並存。 專案先以工作分解結構圖展開，針對某部份，再特別製作責任矩陣，讓專案成員更清楚各自該負的責任。