ITTO-01-整合

01-整合管理

1.目的

 (1) 辨識、定義、結合、統一、及協調專案管理流程群組不同的流程與專案管理活動中所需的流程及活動

 (2) 限定了對專案資源分配的選擇

 (3) 對互斥目標及方案作取捨(Trade-Off)

 (4) 管理各知識領域間的相互依賴

2. PM在整合管理中的角色，以規劃開始

1-1 發展專案章程

(1) 作為正式核准一個專案或階段成立的文件；由贊助者、PMO、專案組合指導委員會授權

(2) 作為提供PM動用專案活動所需資源之授權

Input (5):

專案工作說明書	通常是章程的前身,述說公司的策略 (長遠)
營運企劃案	公司營運的商機 (眼前)
協議(含合約)	發起人口頭說明,email或文件
企業環境因素	包含組織、公司或客戶的文化結構、基礎建設(既有設施及資本設備)、市場形勢、人資管理、利害關係者風險承受度、專案管理資訊系統等
組織流程資產	包含標準化指導綱要及指引、溝通媒介/紀錄的保留及安全需求、議題與缺失管理程序、流程衡量資料庫、專案資料檔、專案行事曆/時程/網路圖範本、議題及缺失管理資料庫、經驗學習知識庫等

TT (2):

專家判斷 p43	提供組織或個人所需要的專業知識或訓練
促進技術 p44	促進者用以協助專案團隊及個別成員完成專案活動的關鍵技術

Output (1):

專案章程	內容包含高層次需求/風險/專案描述、里程碑摘要、概要預算、成功準則、專案目的、批准需求、PM指派/職等

1-2 發展專案管理計劃書  : 由利害關係人共同認可,滿足其需求

Input (4):

專案章程		1-1 發展專案章程
其他流程產出	如專案範疇文件,以執行階段產出為主
企業環境因素
組織流程資產

TT (2):

專家判斷
促進技術

Output (2):

專案管理計劃書 13+1管理計劃書 + 3大基準

(9 + 2 + 2 ) + 1 , 複合的計劃書 , 九領域 + 變更(小)變更管理計劃, 變更(大)構型管理計劃 , 需求管理計劃(計劃外的意見也要聽), 流程改善計劃書)逐步完善) =>九領域 , 大小便 , 噓噓慢慢來 =>三大基準 , 範圍, 時間 成本 => 包括並不限制 為執行、監控、結束流程群組之投入項(Input)

1-3 指導及管理專案工作

Input (4):

專案管理計劃書	做你所寫,寫你所做
獲准之變更申請	新的規定 [FROM 1-5 實施整合變更控制
企業環境因素
組織流程資產

TT (3):

專家判斷
專家管理資訊系統(PMIS)p63
會議 p64

Output (2):

交付標的	具體的可交付成果 (驗收規則請見 2-3 專案範疇說明書 及   2-4 WBS工作包驗收規則)
工作績效資料	原始的數據,如收集到的進度,執行的成本 ; 範圍,時間,成本,品質,缺點數量,變更數量,KPI
變更申請
專案管理計畫書更新
專案文件更新

1-4 監控專案工作

Input (7):

專案管理計劃書	做你所寫,寫你所做
確認之變更
時程預測值	(三大基準) 時間
成本預估值	(三大基準) 成本
工作績效資訊	被監控的物件,實際工作的狀況資訊, 如可交付的成果(差異分析)
企業環境因素
組織流程資產

TT (4):

專家判斷
分析技術 p75
專家管理資訊系統(PMIS)	1. 可用以蒐集及發佈資訊 2. 執行階段發揮功效，其他規劃、監控、及變更階段皆隱含在企業環境因素 3. 整合變更管理及構型管理
會議

Output (4):

工作績效報告	用來跟各相關人員溝通決策用的報告
變更申請	缺點改正(已發生),矯正措施(預見發生),預防行動(不一定發生)
專案管理計畫書更新
專案文件更新

構型管理系統(Configuration Management System; CMS)	變更控制系統(Change Control System; CCS)
1. 目的  (1) 發展評估變更的一致流程  (2) 建立可審查與核准適當變更的環境  (3) 建立溝通標準 2. 作用  (1) 用於提交變更申請、追蹤核准後的變更、確定變更的批准層級、及核准變更的方法  (2) 通過變更控制而對產品特色與細節予以控制 3. 專注於交付標的及流程的規格  (1) 構型辨識, 例: 版本v00 -> v01  (2) 狀態登錄, 例: 編號紀錄  (3) 驗證與稽核, 例: 納管前確認版本、內容…	1. 聚焦於辨識、紀錄、及控制專案與產品基準之變更 2. 是正式的、制定程序、文件表單、追蹤系統、及不同階層審核變更的定義，用以評估在專案中變更申請的影響與後果

*若變更的流程是 Step1 -> Step2 -> Step3  , 變更控制著重在 這個線性流程, 而構型管理著重於點(Step1, Step2,..)的驗証

*CMS有兩大訴求：version control 與 change control。其中的 change control 講的就是這句話。當 SRS 確定後是不是就不可以動了？當然可以，因為系統必須一直的演進，有演進就有變更，所以我們必須允許適當的變更。但是，變更是遵照一定的次序來變更的，不是亂無章法，如果想變就變，到最後我們就不知道到底哪一個版本才是對的了。

1-5 實施整合變更控制

係審查所有的變更申請、核准變更，並管理交付標的、組織流程資產、專案文件、專案管理計畫書等變更之流程

Input (5):

專案管理計劃書	(變更管理計劃,基準)
工作績效報告	現狀
變更申請	有變化了
企業環境因素
組織流程資產

TT (2):

專家判斷
變更控制工具 p87	CCS (Chang Control System) 變更控制系統
會議 p88

Output (4):

獲准之變更申請	(准)
變更紀錄	(淮駁)
專案管理計畫書更新
專案文件更新	不屬於專案管理計劃書的其他文件,看p99

合約變更控制系統: 定義可修改採購的流程，包含文書作業、追蹤系統、爭議化解程序、以及核准變更所需要的核定層級

3. 變更控制委員會(CCB): 負責變更申請之核准或駁回

4. 專案變更處理原則

 (1) 提問有關需求，NEVER say no

 (2) 傾聽利害關係者的希望，要什麼? 可能的影響? (Time, Cost…)

 (3) 分析可行方案，並溝通方案與衝擊

 (4) 讓客戶決定要或不要什麼

5. 當專案收到變更申請時，處理程序/步驟 (P94)

 (1) PM了解認需求,請客戶提出變更申請

 (2) PM登錄變更要求(登錄到CCS及登入到變更紀錄)

 (3) 評估影響及提新方案 Analysis Impact in project goal (Scope, Time, Cost, Quality)

  Solution or Alternative evaluation

 (4) 審批變更Perform Integrated Change Control (if not change baseline, no need CCB)

 (5) 後續處理 Implementation / Check and Review

1-6 結束專案或階段

結束專案或階段流程包含：行政結案。行政結案程序的活動包含：蒐集專案資料、分析專案成敗、蒐集經驗教訓資訊和整理、分析與存檔所蒐集的資訊，和為這些匯整後的專案文件編制索引文件。

Input (3):

專案管理計劃書	要看原本要產出什麼
接受之交付標的	1.客戶驗收：符合專案完成或成功定義 =>獲得顧客或贊助人接受
組織流程資產	參考結案程序

TT (3):

專家判斷
分析技術(p75)
會議

Output (2):

最終產品、服務或成果轉移	2.整理結案資料,並移交  (1) 紀錄、裁適對流程的影響 (蒐集專案或階段紀錄)  (2) 紀錄經驗學習 (稽核專案成功或失敗)
組織流程資產更新	3.結束採購 -> 完成採購的結案 4.更新組織流程資產 包含專案檔案、專案或階段結束文件、歷史資訊(蒐集經驗學習 -> 歷史性資訊、經驗學習移轉至Lesson Learn知識庫),將PMIS中專案文件歸檔，作為歷史資料使用 5.釋出資源，包含解散專案團隊

專案檔案 vs. 合約檔案

 (1) 專案檔案: 專案所發生、決定、與核准變更事情的任何文件，包含財務紀錄、法律文件 (未核准的變更文件，不列入)

 (2) 合約檔案: 包含合約、獲准變更、正式驗收有關的文件