PMP：4.專案整合管理
阿新 • • 發佈：2018-11-06
====================專案整合管理========================
專案整合管理包括對隸屬於專案管理過程組的各種過程和專案管理活動進行識別、定義、組合、 統一和協調的各個過程。
{
4.1 制定專案章程 — 編寫一份正式批准專案並授權專案經理在專案活動中使用組織資源的文 件的過程。
4.2 制定專案管理計劃 — 定義、準備和協調專案計劃的所有組成部分，並把它們整合為一份綜合專案管理計劃的過程。
4.3 指導與管理專案工作 — 為實現專案目標而領導和執行專案管理計劃中所確定的工作，並實施已批准變更的過程。 ![]()
![]()
輸入：
商業檔案（商業論證&效益管理計劃）：經批准的商業論證或類似檔案是最常用於制定專案章程的商業檔案。
商業論證從商業視角描述必要的資訊，並且據此決定專案的期望結果是否值得所需投資。
高於專案級別的經理和高管們通常使用該檔案作為決策的依據。
一般情況下，
商業論證會包含商業需求和成本效益分析，以論證專案的合理性並確定專案邊界。
既然商業檔案不是專案檔案，
專案經理就不可以對它們進行更新或修改，只可以提出相關建議。
協議：協議用於定義啟動專案的初衷。
協議有多種形式，包括合同、諒解備忘錄（MOUs）、 服務水平協議（SLA）、協議書、意向書、口頭協議、電子郵件或其他書面協議。 為外部客戶做專案時，通常就以合同的形式出現。
事業環境因素：
{
uu政府或行業標準（如產品標準、質量標準、安全標準和工藝標準）；
uu法律法規要求和（或）制約因素；
uu市場條件；
uu組織文化和政治氛圍；
uu組織治理框架（通過安排人員、制定政策和確定過程， 以結構化的方式實施控制、指導和協調，以實現組織的戰略和運營目標）；
uu相關方的期望和風險臨界值。
}
組織過程資產：
{
uu組織的標準政策、流程和程式；
uu專案組合、專案集和專案的治理框架（用於提供指導和制定決策的治理職能和過程）；
uu監督和報告方法；
uu模板（如專案章程模板）；
uu歷史資訊與經驗教訓知識庫（如專案記錄與檔案、關於以往專案選擇決策的結果及以往專案績 效的資訊）。
}
工具與技術：
專家判斷：專家判斷是指基於某應用領域、知識領域、學科和行業等的專業知識而做出的，關於當前活動的合理判斷，這些專業知識可來自具有專業學歷、知識、技能、經驗或培訓經歷的任何小組或個人。
{
uu組織戰略；
uu效益管理；
uu關於專案所在的行業以及專案關注的領域的技術知識；
uu持續時間和預算的估算；
uu風險識別。
}
資料收集：
{
頭腦風暴：
焦點小組：
訪談：訪談是指通過與相關方直接交談來了解高層級需求、假設條件、制約因 素、審批標準以及其他資訊。
}
人際關係與團隊技能：
{
衝突管理：
引導：引導是指有效引導團隊活動成功以達成決定、解決方案或結論的能力。引導者確保參與者有效參與，互相理解，考慮所有意見，按既定決策流程全力支援得到的結論或結果，以及所達成的行動計劃和協議在之後得到合理執行。
會議管理：
}
會議：
輸出：
專案章程（是由專案啟動者或發起人釋出的，它記錄了關於專案和專案預期交付的產品、服務或成果的高層級資訊）：{
uu專案目的；
uu可測量的專案目標和相關的成功標準；
uu高層級需求；
uu高層級專案描述、邊界定義以及主要可交付成果；
uu整體專案風險；
uu總體里程碑進度計劃；
uu預先批准的財務資源；
uu關鍵相關方名單；
uu專案審批要求（例如， 用什麼標準評價專案成功， 由誰對專案成功下結論， 由誰來簽署專案結束）；
uu專案退出標準（例如，在何種條件下才能關閉或取消專案或階段）；
uu委派的專案經理及其職責和職權；
uu發起人或其他批准專案章程的人員的姓名和職權。
}
假設日誌：
通常，在專案啟動之前編制商業論證時，識別高層級的戰略和運營假設條件與制約因素。
這些假設條件與制約因素應納入專案章程。
較低層級的活動和任務假設條件在專案期間隨著諸如定義技術規範、估算、進度和風險等活動的開展而生成。
假設日誌用於記錄整個專案生命週期中的所有假設 條件和制約因素。
====================制定專案管理計劃========================
制定專案管理計劃是定義、準備和協調專案計劃的所有組成部分，並把它們整合為一份綜合專案管理計劃的過程。
本過程的主要作用是，生成一份綜合檔案，用於
確定所有專案工作的基礎及其執行方式。
它
僅開展一次或僅在專案的預定義點開展。
{
可以是概況|詳細、
足夠強大、
應基準化（基準確定之前需要多次更新，更新無需遵循正式流程，一旦確定需通過實施整體變更）
專案受收尾前，需要通過不斷更新漸進明細，且需要控制和批准。
專案集管理計劃中要求超過某一特定成本的所有變更都需要上報變更控制委員會（CCB）審查，
在專案管理計劃中就應該對審查流程和成本臨界值做出相應規定。
}
![]()
輸入：
專案章程：專案團隊把專案章程作為初始專案規劃的起始點。在專案章程中至少應該定義專案的高層級資訊，以便細化。
其他過程的輸出：
事業環境因素：
組織過程資產：
工具與技術：
專家判斷：
{
uu根據專案需要裁剪專案管理過程，包括這些過程間的依賴關係和相互影響，以及這些過程的主要輸入和輸出；
uu根據需要制定專案管理計劃的附加組成部分；
uu確定這些過程所需的工具與技術；
uu編制應包括在專案管理計劃中的技術與管理細節；
uu確定專案所需的資源與技能水平；
uu定義專案的配置管理級別；
uu確定哪些專案檔案受制於正式的變更控制過程；
uu確定專案工作的優先順序，確保把專案資源在合適的時間分配到合適的工作。
}
收集資料：
{
頭腦風暴：制定專案管理計劃時，經常以頭腦風暴的形式來收集關於專案方法的創意和解決方案。參會者包括專案團隊成員，其他主題專家 (SME) 或相關方也可以參與。
核對單：很多組織基於自身經驗制定了標準化的核對單，或者採用所在行業的核對單。核對單可以指導專案經理制定計劃或幫助檢查專案管理計劃是否包含所需全部資訊。
焦點小組：
訪談：
}
人際關係與團隊技能：
{
衝突管理：
引導：
會議管理：
}{
會議：專案開工會議通常意味著規劃階段結束和執行階段開始， 旨在傳達專案目標、獲得團隊對項 目的承諾， 以及闡明每個相關方的角色和職責。 開工會議可能在不同時間點舉行， 具體取決於項 目的特徵：
{
uu對於小型專案，通常由同一個團隊開展專案規劃和執行。這種情況下，專案在啟動之後很快就會開工（規劃過程組），因為執行團隊參與了規劃。
uu對於大型專案， 通常由專案管理團隊開展大部分規劃工作。 在初始規劃工作完成、開發（執行）階段開始時，專案團隊其他成員才參與進來。這種情況下，將隨同執行過程組的相關過程召開開工會議。
}
輸出：
專案管理計劃：說明專案執行、監控和收尾方式的一份檔案，它整合並綜合了所有子管理計劃和基準，以及管理專案所需的其他資訊。究竟需要哪些專案管理計劃元件，取決於具體專案的需求。
子管理計劃：
{
nu範圍管理計劃。確立如何定義、制定、監督、控制和確認專案範圍。
nu需求管理計劃。確定如何分析、記錄和管理需求。
nu進度管理計劃。為編制、監督和控制專案進度建立準則並確定活動。
nu成本管理計劃。確定如何規劃、安排和控制成本。
nu質量管理計劃。確定在專案中如何實施組織的質量政策、方法和標準。
nu資源管理計劃。指導如何對專案資源進行分類、分配、管理和釋放。
nu溝通管理計劃。確定專案資訊將如何、何時、由誰來進行管理和傳播。
nu風險管理計劃。確定如何安排與實施風險管理活動。
nu採購管理計劃。確定專案團隊將如何從執行組織外部獲取貨物和服務。
nu相關方參與計劃。。確定如何根據相關方的需求、利益和影響讓他們參與專案決策和執行。
}
基準：
{
nu範圍基準。經過批准的範圍說明書、工作分解結構 (WBS) 和相應的 WBS 詞典， 用作比較依據。
nu進度基準。經過批准的進度模型，用作與實際結果進行比較的依據。
nu成本基準。經過批准的、按時間段分配的專案預算，用作與實際結果進行比較的依據。
}
其他元件：大多數專案管理計劃元件都來自於其他過程， 雖然有些元件是在本過程生成的。 雖然在本過程生成的元件會因專案而異，但一般包括以下元件
{
nu變更管理計劃。描述在整個專案期間如何正式審批和採納變更請求。
nu配置管理計劃。描述如何記錄和更新專案的特定資訊， 以及該記錄和更新哪些資訊， 以保持產品、服務或成果的一致性和（或）有效性。
nu績效測量基準。經過整合的專案範圍、進度和成本計劃， 用作專案執行的比較依據， 以測量和管理專案績效。
nu專案生命週期。描述專案從開始到結束所經歷的一系列階段。
nu開發方法。描述產品、服務或成果的開發方法，例如預測、迭代、敏捷或混合型模式。
nu管理審查。 確定專案經理和有關相關方審查專案進度
}
其他檔案：
![]()
====================指導與管理專案工作========================
指導與管理專案工作是為實現專案目標而領導和執行專案管理計劃中所確定的工作，並實施已批准變更的過程。
本過程的主要作用是，
對專案工作和可交付成果開展綜合管理，以提高專案成功的可能性。
本過程需要在
整個專案期間開展。
![]()
![]()
輸入：
專案管理計劃：
專案檔案：
{
uu變更日誌。變更日誌記錄所有變更請求的狀態。
uu經驗教訓登記冊。經驗教訓用於改進專案績效，以免重犯錯誤。登記冊有助於確 定針對哪些方面設定規則或指南，以使團隊行動保持一致。
uu里程碑清單。里程碑清單列出特定里程碑的計劃實現日期。
uu專案溝通記錄。專案溝通記錄包含績效報告、可交付成果的狀態，以及專案生成的其他資訊。
uu專案進度計劃。進度計劃至少包含工作活動清單、持續時間、資源，以及計劃的 開始與完成日期。
uu需求跟蹤矩陣。需求跟蹤矩陣把產品需求連線到相應的可交付成果，有助於把關注點放在最終結果上。
uu風險登記冊。風險登記冊提供可能影響專案執行的各種威脅和機會的資訊。
uu風險報告。風險報告提供關於整體專案風險來源的資訊，以及關於已識別單個 專案風險的概括資訊。
}
批准的變更請求：批准的變更請求可能是糾正措施、預防措施 或缺陷補救，可能對專案或專案管理計劃的任一領域產 生影響，還可能導致修改正式受控的專案管理計劃元件或專案檔案。
事業環境因素：
組織過程資產：
工具與技術：
專家判斷：
專案管理資訊系統（PMIS）：PMIS 提供資訊科技 (IT) 軟體工具，例如進度計劃軟體工具、工作授權系統、配置管理系統、資訊收集與釋出系統，以及進入其他線上自動化系統（如公司知識庫）的介面。自動收集和報告關鍵績效指標（KPI）可以是本系統的一項功能。
會議：
輸出：
可交付成果：可交付成果是在某一過程、階段或專案完成時，必須產出的任何獨特並可核實的產品、成果或服務能力。一旦完成了可交付成果的第一個版本，就應該執行變更控制。用配置管理工具和程式來支援對可交付成果（如檔案、軟體和構件）的多個版本的控制。
工作績效資料：工作績效資料是在執行專案工作的過程中， 從每個正在執行的活動中收集到的原始觀察結果和測量值。
問題日誌：問題日誌是一種記錄和跟進所有問題的專案檔案,作為本過程的輸出，問題日誌被首次建立（指導與管理專案工作），儘管在專案期間任何時候都可能發生問題。
{
uu問題型別；
uu問題提出者和提出時間；
uu問題描述；
uu問題優先順序；
uu由誰負責解決問題；
uu目標解決日期；
uu問題狀態；
uu最終解決情況。
}
變更請求：變更請求是關於修改任何檔案、可交付成果或基準的正式提議，任何專案相關方都可以提出變更請求，應該通過實施整體變更控制過程對變 更請求進行審查和處理。變更請求源自專案內部或外部，是可選或由法律（合同）強制的。
{
uu糾正措施。為使專案工作績效重新與專案管理計劃一致，而進行的有目的的活動。
uu預防措施。為確保專案工作的未來績效符合專案管理計劃，而進行的有目的的活動。
uu缺陷補救。為了修正不一致產品或產品元件的有目的的活動。
uu更新。對正式受控的專案檔案或計劃等進行的變更，以反映修改或增加的意見或內容。
}
專案管理計劃更新：
專案檔案更新：
{
活動清單、
假設日誌、
經驗教訓登記處、
需求檔案、
風險登記冊、
相關方登記冊
}
組織過程資產更新
====================管理專案中知識========================
管理專案知識是使用現有知識並生成新知識，以實現專案目標，並且幫助組織學習的過程。
本過程的主要作用是，
利用已有的組織知識來創造或改進專案成果，並且使當前專案創造的知識可用於支援組織運營和未來的專案或階段。
![]()
![]()
顯性知識、隱性知識
知識管理指管理顯性和隱性知識，旨在重複使用現有知識並生成新知識。
有助於達成這兩個目的的關鍵活動是
知識分享和 知識整合（不同領域的知識、情境知識和專案管理知識）。
因為知識存在於人們的思想中，且無法強迫人們分享自 己的知識或關注他人的知識，所以，知識管理最重要的環節就是
營造一種相互信任的氛圍，激勵人 們分享知識或關注他人的知識。
一個常見誤解是，知識管理只是將知識記錄下來用於分享；
另一種常見誤解是，知識管理只是在專案結束時總結經驗教訓，以供未來專案使用。
如果不激勵人們分享知識或關注他人的知識，即便最好的知識管理工具和技術也無法發揮作用。
在實踐中，聯合使用
知識管理工具和技術（用於人際互動）以及資訊管理工具和技術（用於編撰顯性知識）來分享知識。
輸入：
專案管理計劃：
專案檔案:
{
經驗教訓登記冊
專案團隊派工單：專案團隊派工單說明了專案已具有的能力和經驗以及可能缺乏的知識。
資源分解結構：資源分解結構包含有關團隊組成的資訊，有助於瞭解團隊擁有和缺乏的知識。
供方選擇標準：
相關方登記冊：
}
可交付成果：它通常是為實現專案目標而完成的有形的組成部分，並可包括專案管理計劃的組成部分。
事業環境因素：
{
組織文化、相關方文化和客戶文化
設施和資源的地理分佈：團隊成員所在的位置有助於確定收集和分享知識的方法。
組織中的知識專家
法律法規的要求或制約因素：包括對專案資訊的保密性要求。
}
組織過程資產:
{
組織政策、流程和程式
人事管理制度
組織溝通要求
正式的知識分享和資訊分享程式
}
工具與技術：
專家判斷：
知識管理:
可以通過面對面和（或）虛擬方式來應用所有這些工具和技術。通常，面對面互動最有利於建立知識管理所需的信任關係。一旦信任關係建立，可以用虛擬互動來維護這種信任關係。
資訊管理：
資訊管理工具和技術用於建立人們與知識之間的聯絡， 可以有效促進簡單、明確的顯性知識的分享，通過增加互動要素，如“與我聯絡”的功能，使使用者能夠與經驗教訓發帖者聯絡，並向其尋求與特定專案和情境有關的建議。
互動和支援也有助於人們找到相關資訊。
相比搜尋關鍵詞， 直接詢問通常是一種更輕鬆快捷的方式。
搜尋關鍵詞經常難以使用， 因為人們可能不知道選擇什麼樣的關鍵詞或關鍵短語才能找到 所需的資訊。
知識和資訊管理工具與技術應與專案過程和過程責任人相對應。
人際關係與團隊技能:
{
積極傾聽
引導
領導力
人際交往
政治意識
}
輸出
經驗教訓登記冊：
專案管理計劃更新：
組織過程資產更新：所有專案都會生成新知識。
有些知識應該被編撰，並在管理專案知識過程中被嵌入可交付成果， 或者被用於改進過程和程式。
在本過程中，也可以首次編撰或使用現有知識。
可在本過程更新任組織過程資產。
====================監控專案工作========================
監控專案工作：是跟蹤、審查和報告整體專案進展， 以實現專案管理計劃中確定的績效目標的過程。
本過程的主要作用是，
讓相關方瞭解專案的當前狀態並認可為處理績效問題而採取的行動， 以及通過成本和進度預測， 讓相關方瞭解未來專案狀態。
本過程需要在整個專案期間開展。
![]()
![]()
監督：是貫穿於整個專案的專案管理活動之一，包括收集、測量和分析測量結果，以及預測趨勢， 以便推動過程改進。持續的監督使專案管理團隊能洞察專案的健康狀況，並識別須特別關注的任何方面。
控制：包括制定糾正或預防措施或重新規劃，並跟蹤行動計劃的實施過程，以確保它們能有效解決問題。
{
uu把專案的實際績效與專案管理計劃進行比較；
uu定期評估專案績效，決定是否需要採取糾正或預防措施，並推薦必要的措施；
uu檢查單個專案風險的狀態；
uu在整個專案期間，維護一個準確且及時更新的資訊庫，以反映專案產品及相關檔案的情況；
uu為狀態報告、進展測量和預測提供資訊；
uu做出預測，以更新當前的成本與進度資訊；
uu監督已批準變更的實施情況；
uu如果專案是專案集的一部分，還應向專案集管理層報告專案進展和狀態；
uu確保專案與商業需求保持一致。
}
輸入：
專案管理計劃：監控專案工作包括檢視專案的各個方面。專案管理計劃的任一組成部分都可作為本 過程的輸入
專案檔案：
{
假設日誌：假設日誌包含會影響專案的假設條件和制約因素的資訊。
估算依據：估算依據說明不同估算是如何得出的， 用於決定如何應對偏差。
成本預測：
問題日誌：問題日誌用於記錄和監督由誰負責在目標日期內解決特定問題。
經驗教訓登記冊：
里程碑清單：
質量報告：質量報告包含質量管理問題，針對過程、專案和產品的改善建議，糾正措施建議（包括返工、缺陷（漏洞）補救、100% 檢查等），以及在控制質量過程中發現的情況的概述。
風險登記冊：
風險報告：
進度預測：
}
工作績效資訊：
在工作執行過程中收集工作績效資料， 再交由控制過程做進一步分析。
將工作績效資料與專案管理計劃元件、專案檔案和其他專案變數比較之後生成工作績效資訊。
通過資訊為確定專案是否符合預算或是否 存在偏差提供了相應的情境；
還有助於瞭解偏差的嚴重程度。
通過與專案管理計劃中的偏差臨界值 進行比較，就可以確定是否需要採取預防或糾正措施。
對工作績效資料和附加資訊進行綜合分析， 可以為專案決策提供可靠的基礎。
協議：
事業環境因素:
{
uu專案管理資訊系統，例如進度、成本、資源工具、績效指標、資料庫、專案記錄和財務資料；
uu基礎設施（如現有設施、裝置、組織通訊渠道）；
uu相關方的期望和風險臨界值；
uu政府或行業標準（如監管機構條例、產品標準、質量標準和工藝標準）；
}
組織過程資產:
{
uu組織的標準政策、流程和程式；
uu財務控制程式（如必需的費用與支付審查、會計編碼及標準合同條款等）；
uu監督和報告方法；
uu問題管理程式，用於定義問題控制、問題識別及其解決，以及行動事項跟蹤；
uu缺陷管理程式，用於定義缺陷控制、缺陷識別及其解決，以及行動事項跟蹤；
uu組織知識庫，尤其是過程測量和經驗教訓知識庫。
}
工具
專家判斷
{
uu掙值分析；
uu資料的解釋和情境化；
uu持續時間和成本的估算技術；
uu趨勢分析；
uu關於專案所在的行業以及專案關注的領域的技術知識；
uu風險管理；
uu合同管理。
}
資料分析
{
備選方案分析
成本效益分析
掙值分析
根本原因分析
趨勢分析
偏差分析
}
決策：
會議：會議可以是面對面或虛擬會議，正式或非正式會議。參會者可以包括專案團隊成員和其他合適的專案相關方；會議的型別包括（但不限於）使用者小組會議和使用者審查會議。
輸出：
工作績效報告:
基於工作績效資訊， 以實體或電子形式編制工作績效報告，
以制定決策、採取行動或引起關注。
根據專案溝通管理計劃， 通過溝通過程
向專案相關方傳送工作績效報告。
工作績效報告的示例包括狀態報告和進展報告。
工作績效報告可以包含掙值圖表和資訊、 趨勢線和預測、儲備燃盡圖、缺陷直方圖、合同績效資訊和風險情況概述。可以表現為有助於引起 關注、制定決策和採取行動的儀表指示圖、熱點報告、訊號燈圖或其他形式。
變更請求：
通過比較實際情況與計劃要求，可能需要提出變更請求，來擴大、調整或縮小專案範圍與產品範圍，或者提高、調整或降低質量要求和進度或成本基準。
變更請求可能導致需要收集和記錄新的需求。
變更可能會影響專案管理計劃、專案檔案或產品可交付成果。
應該通過實施整體變更控制過程對變更請求進行審查和處理。
{
uu糾正措施。為使專案工作績效重新與專案管理計劃一致，而進行的有目的的活動。
uu預防措施。為確保專案工作的未來績效符合專案管理計劃，而進行的有目的的活動。
uu缺陷補救。為了修正不一致產品或產品元件而進行的有目的的活動。
}
專案管理計劃更新:
專案管理計劃的
任何變更都以變更請求的形式提出，且通過組織的變更控制過程進行處理。
在監控專案工作過程中提出的變更可能會影響整體專案管理計劃。
專案檔案更新
{
成本預測
問題日誌
經驗教訓登記冊:在本過程中識別的新風險應記錄在風險登記冊中，並通過風險管 理過程進行管理。
風險登記冊
進度預測：進度預測基於專案以往的績效，用於確定專案是否仍處於進度的公差區間內，並識別任何必要的變更。
}
====================實施整體變更========================
實施整體變更控制是審查所有變更請求、批准變更，管理對可交付成果、專案檔案和專案管理計劃的變更，並對變更處理結果進行溝通的過程。
本過程審查對
專案檔案、可交付成果或專案管理計劃的所有變更請求，並決定對變更請求的處置方案。
本過程的
主要作用是確保對專案中已記錄在案的變更做綜合評審。
如果不考慮變更對整體專案目標或計劃的影響就開展變更，往往會加劇整體專案風險。
本過程需要在整個專案期間開展。
![]()
![]()
實施整體變更控制過程
貫穿專案始終， 專案經理對此承擔最終責任。
變更請求
可能影響專案範 圍、產品範圍以及任一專案管理計劃元件或任一專案檔案。
在整個專案生命週期的
任何時間，參與專案的任何相關方都可以提出變更請求。
變更控制的實施程度，
取決於專案所在應用領域、專案復 雜程度、合同要求，以及專案所處的背景與環境。
在基準確定之前，變更無需正式受控於實施整體變更控制過程。一旦確定了專案基準，就必須通 過本過程來處理變更請求。
依照常規，
每個專案的配置管理計劃應規定哪些專案工件受控於配置控制程式。
對配置要素的任何變更都應該提出變更請求，並經過正式控制。
儘管也可以口頭提出，但所有
變更請求都必須以書面形式記錄，並納入變更管理和（或）配置管理系統中。
在批准變更之前，可能需要了解變更對進度的影響和對成本的影響。
在變更請求可能
影響任一專案基準的情況下，都需要開展正式的整體變更控制過程。
每項記錄在案的變更請求都必須
由一位責任人批准、推遲或否決，這個責任人通常是專案發起人或專案經理。應該在專案管理計劃或組織程式中指定這位責任人，必要時，應該由變更控制委員會（CCB）來開展實施整體變更控制 過程。
CCB 是一個正式組成的團體，負責審查、評價、批准、推遲或否決專案變更，以及記錄和傳 達變更處理決定。
變更請求得到
批准後， 可能需要新編（或修訂）成本估算、活動排序、進度日期、資源需求 和（或）風險應對方案分析，這些變更可能要求調整專案管理計劃和其他專案檔案。
某些特定的變更請求，在 CCB 批准之後，可能還需要得到客戶或發起人的批准，除非他們本身就是 CCB 的成員。
輸入：
專案管理計劃：
{
變更管理計劃
配置管理計劃：配置管理計劃描述專案的配置項、識別應記錄和更新的配置項， 以便保持專案產品的一致性和有效性。
範圍管理計劃
進度管理計劃
成本管理計劃
}
專案檔案：
{
估算依據：估算依據指出了持續時間、成本和資源估算是如何得出的，可用於計算變更對時間、預算和資源的影響。
需求跟蹤矩陣：需求跟蹤矩陣有助於評估變更對專案範圍的影響。
風險報告
}
工作績效報告:
變更請求：
變更可能影響專案基準， 也可能不影響專案基準， 而隻影響相對於基準的專案績效。
變更決定通常由專案經理做出。
對於會影響專案基準的變更， 通常應該在變更請求中說明執行變更的成本、所需的計劃日期修改、資源需求以及相關的風險。
這種變更應由 CCB（如有）和客戶或發起人審批，除非他們本身就 是 CCB 的成員。
只有經批准的變更才能納入修改後的基準。
事業環境因素：
{
uu法律限制，例如國家或地區法規；
uu政府或行業標準（如產品標準、質量標準、安全標準和工藝標準）；
uu法律法規要求和（或）制約因素；
uu組織治理框架（通過安排人員、制定政策和確定過程， 以結構化的方式實施控制、指導和協 調，以實現組織的戰略和運營目標）；
uu合同和採購制約因素。
}
組織過程資產:
{
uu變更控制程式，包括修改組織標準、政策、計劃和程式（或任一專案檔案）所須遵循的步驟， 以及如何批准和確認變更；
uu批准與簽發變更的程式；
uu配置管理知識庫，包括組織標準、政策、程式和專案檔案的各種版本及基準。
}
工具與技術：
專家判斷：
{
uu關於專案所在的行業以及專案關注的領域的技術知識；
uu法律法規；
uu法規與採購；
uu配置管理；
uu風險管理。
}
變更控制工具：
配置控制重點關注可交付成果及各個過程的技術規範，
變更控制則著眼於識別、記錄、批准或否決對專案檔案、可交付成果或基準的變更。
工具的選擇應基於專案相關方的需要，包括考慮組織和環境情況和（或）制約因素。
工具應支援以下配置管理活動：
{
識別配置項
記錄並報告配置項狀態
進行配置項核實與審計：通過配置核實與審計， 確保專案的配置項組成的正確性， 以及相應的變更都被登記、評估、批准、跟蹤和正確實施， 從而確保配置檔案所規定的功能要求都已實現。
&&
識別變更
做出變更決定
跟蹤變更
}
資料分析：
{
備選方案分析
成本效益分析
}
決策：
{
投票：投票可以採取一致同意、大多數同意或相對多數原則的方式，以決定是否接受、推遲或否決變更請求。
獨裁型決策制定：將由一個人負責為整個集體制定決策。
多標準決策分析：該技術藉助決策矩陣，根據一系列預定義的準則，用系統分析方法評估變更請求。
}
會議：
輸出：
批准的變更請求：
做出批准、推遲或否決的決定批准的變更請求應通過指導與管理專案工作過程加以實施。
對於推遲或否決的變更請求，應通知提出變更請求的個人或小組。
以專案檔案更新的形式，在變更日誌中記錄所有變更請求的處理情況。
專案管理計劃更新：
專案檔案更新：
{
變更日誌
}
====================結束專案或階段========================
結束專案或階段是終結專案、階段或合同的所有活動的過程。
本過程的主要作用是，
存檔專案或階段資訊，完成計劃的工作，釋放組織團隊資源以展開新的工作。
它僅開展一次或僅在專案的預定 義點開展。
![]()
![]()
在結束專案時，專案經理需要回顧專案管理計劃，確保所有專案工作都已完成以及專案目標均已實現。專案或階段行政收尾所需的必要活動包括（但不限於）：
uu為達到階段或專案的完工或退出標準所必須的行動和活動，例如：
nu確保所有檔案和可交付成果都已是最新版本，且所有問題都已得到解決；
nu確認可交付成果已交付給客戶並已獲得客戶的正式驗收；
nu確保所有成本都已記入專案成本賬；
nu關閉專案賬戶；
nu重新分配人員；
nu處理多餘的專案材料；
nu重新分配專案設施、裝置和其他資源；
nu根據組織政策編制詳盡的最終專案報告。
uu為關閉專案合同協議或專案階段合同協議所必須開展的活動，例如
nu確認賣方的工作已通過正式驗收；
nu最終處置未決索賠；
nu更新記錄以反映最後的結果；
nu存檔相關資訊供未來使用。
uu為完成下列工作所必須開展的活動：
nu收集專案或階段記錄；
nu審計專案成敗；
nu管理知識分享和傳遞；
nu總結經驗教訓；
nu存檔專案資訊以供組織未來使用。
uu為向下一個階段，或者向生產和（或）運營部門移交專案的產品、服務或成果所必須開展的行動和活動。
uu收集關於改進或更新組織政策和程式的建議，並將它們傳送給相應的組織部門。
uu測量相關方的滿意程度。 如果專案在完工前就提前終止，結束專案或階段過程還需要制定程式，來調查和記錄提前終止的 原因。為了實現上述目的，專案經理應該引導所有合適的相關方參與本過程。
輸入：
專案章程：專案章程記錄了專案成功標準、審批要求，以及由誰來簽署專案結束。
專案管理計劃：
專案檔案：
{
假設日誌
估算依據
變更日誌
問題日誌:問題日誌用於確認沒有未決問題。
經驗教訓登記冊
里程碑清單
專案溝通記錄
質量控制測量結果
質量報告
需求檔案
風險登記冊
風險報告:風險報告提供了有關風險狀態的資訊，用於確認專案結束時沒有未 關閉的風險。
}
驗收的可交付成果
商業檔案：
{
商業論證:商業論證記錄了作為專案依據的商業需求和成本效益分析。確定專案是否達到了經濟可行性研究的預期結果。
效益管理計劃: