1. 專案範疇
(1) 定義: 完成並交付一項具有特定功能、特色的產品、服務、或結果所需執行的工作
(2) 以專案管理計畫書(PMP)來衡量完成
2. 產品範疇
(1) 一項產品、服務、或結果所具有的特色功能
(2) 以產品需求來衡量完成
2-1 規劃範疇管理
Input (4): (範時成的Input一樣)
專案管理計劃書
|
攻略 , 整個專案怎麼做 ,以此為母計劃, 產出子計劃
|
1-2 發展專案管理計劃書
|
專案章程
|
要知道發起人的想法,主要產出, 才能產出子計劃
|
1-1 發展專案章程
|
企業環境因素
|
公司資產,文化,外部政策...
| |
組織流程資產
|
企業過去的經驗或知識庫
|
TT (2):
專家判斷
| |
會議
|
Output (2):
範疇管理計劃書
|
專案的範圍訂定(1)如何做 (2)變更控制程序 (3)驗收程序
|
需求管理計劃書
|
如何管理利害關係人的需求的攻略
|
2-2 蒐集需求
1. 定義與管理顧客期望的流程,且需求是WBS的基礎;成本、時程與品質規劃等均是依其而建立的
2. 需求的發展始於分析專案章程與利害關係者登錄表中所包含的相關資訊
3. 需求可分:
(1) 專案需求: 包括營運需求、專案管理需求、與交付需求等
(2) 產品需求: 包括技術需求、安全需求、與性能需求等資訊
Input (5):
範疇管理計劃書
|
2-1 規劃範疇管理
| |
需求管理計劃書
|
2-1 規劃範疇管理
| |
利害關係人管理計劃書
|
如何讓利害關係人被滿足
| |
專案章程
|
這是大方針,一直要參考
|
1-1 發展專案章程
|
利害關係人登錄表
|
要知道利害關係人是誰,辨識利害關係人的需求, 逐步完善
|
TT (11):
討論
|
訪談,焦點團體(預先審核成員),促進研討會,集體創新(腦力激盪)
|
統計圖表
|
集體創新(心智圖,親和圖) , 系統關聯圖
|
書面或分析
|
文件分析,集體創新(多準則決策分析),問卷調查
|
單向
|
觀察
|
具體化
|
雛形
|
模仿
|
標竿比對
|
集體決策
|
一致性,半數,最高,獨裁
|
Output (2):
需求文件
|
把利害關係人的需求列出來 (不見得全都要做,之後再收斂)
|
需求追朔矩陣
(RTM; Requirements Traceability Matrix) |
客戶對問題看法的歷程,逐步完善
(需求不一定會被實做,但要追蹤,以免日後倒楣)
1. 可從原始需求開始連結以至追溯其在整個專案生命週期的表格
2. 可與公司的營運與專案目標相連結,有助確保每一項需求能增加營運價值
3. 可從專案範疇/工作分解結構之交付標的,至產品的設計與開發,並至測試的策略與情境
4. 可從高階的需求至詳細的需求
5. 提供於專案整個生命週期追溯需求的方法
|
2-3 定義範疇 : 將高層次的概念具體化
Input (4):
專案章程
|
1-1 發展專案章程
| |
範疇管理計劃書
|
2-1 規劃範疇管理
| |
需求文件
|
要從這裡收斂
|
2-2 蒐集需求
|
組織流程資產
|
TT (4):
專家判斷
| |
產品分析
|
產品分解/系統分析/系統工程/價值分析/價值工程
|
備案產出
|
風險管理,其他備案(其他做法)
|
促進研討會
|
Output (2):
專案範疇說明書
(Project Scope Statement) |
要有一個很明確,要做什麼的說明書 (規格書,驗收標準),如何做,何時開始結束,怎麼做這個專案(方法)
PS.範疇管理計劃書是在講如何產出這個專案範疇, 專案範疇說明書是專案這個專案如何實作再說明
(1) 基於在專案起始期間所產生之主要交付標的
(2) 詳細描述專案的交付標的,及其用來產出交付標的之工作
(3) 包含產品範疇描述、允收準則、交付標的、排除事項、限制條件、假設事項等
|
專案文件更新
|
2-4 建立WBS
工作分解結構 (WBS) : 結構 + 產出物(交付標的)
(1) 以交付標的為導向的階層式工作分解
(2) 在其範圍內所謂工作是指工作的產出或交付標的
1. 其代表可驗收的產品、服務、或結果
2. 工具: 分解術,是一種由上而下的分析方法
3. 將主要交付標的分解成小的單位,以便於管理;工作包(Work Package)是WBS的最底層單位
4. 正確分解工作包後,才能進行定義活動;定義活動產出包含: 活動清單、活動屬性、里程碑清單
5. 為100%原則,沒有遺漏或是多餘的專案工作
工作分解結構說明表 (WBS Dictionary)
(1) 每一工作項的詳細說明,包含人、事、時、地、成本(估計值/ 資源)、驗收條件
(2) 說明包含工作包與管制帳戶
Input (5):
範疇管理計劃書
|
2-1 規劃範疇管理
| |
專案範疇說明書
|
有具體規劃,所以不用再參考章程
|
2-3 定義範疇
|
需求文件
|
2-2 蒐集需求
| |
企業環境因素
| ||
組識流程資產
|
要用WBS的範本
|
TT (2):
分解術(工具)
|
拆到可執行的活動
|
專家判斷
|
Output (2):
範疇基準
|
範疇說明書, WBS , WBS說明表
|
專案文件更新
|
2-5 確認範疇 : 跟客戶確認這是不是他想要的
1. 與客戶或贊助人審查交付標的,確保滿意地完成
2. 獲得客戶或贊助人對交付標的之正式的接受
3. 比較:
(1) 驗證範疇: 關注於交付標的之接受性 (Acceptance of the Deliverables)
(2) 品質管制: 主要涉及交付標的之正確性 (Correctness of the Deliverables)與特定的品質需求的達成
(3) 一般而言,先執行品質管制,再執行驗證範疇,但亦可並行
Input (5):
專案管理計劃書
|
要從全局看,因牽一髮動全身,所以不是只看之前所產出的計劃書(範疇管理計劃書+範疇基準)
|
1-2 發展專案管理計劃書
|
需求文件
|
和可
|
2-2 蒐集需求
|
需求追朔矩陣
|
2-2 蒐集需求
| |
工作績效資料
| ||
驗証之交付標的
|
QA 確認的
|
TT(2):
檢驗
| |
集體決策技術
|
Output (4):
接受之交付標的
|
外部關係人確認的(正式驗收)
|
變更申請
| |
工作績效資訊
| |
專案文件更新
|
2-6 控制範疇 : PM控制要 on scheudler
1. 確保所有變更申請和建議的矯正或預防行動,均經由執行整合變更控制流程來進行
2. 範疇潛變 (Scope Creep): 未經控制的變更稱之
Input (5):
專案管理計劃書
|
實際上是範疇管理計劃書,但若改變,會影響其他的子計劃
|
1-2 發展專案管理計劃書
|
需求文件
|
2-2 蒐集需求
| |
需求追朔矩陣
|
2-2 蒐集需求
| |
工作績效資料
| ||
組織流程資產
|
TT (1):
變異分析
|
和基準做比較,採哪些措施
|
Output (5):
工作績效資訊
|
監控各部份是否有如期完成,可供決策
|
變更申請
| |
專案管理計劃書 更新
| |
專案文件 更新
| |
組織流程資產 更新
|
謝謝你的分享~
回覆刪除