1、定义：对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中，整合兼具统一、合并、沟通和建立联系的性质。
2、怎么进行整合管理：相关方需求、约束条件、项目管理各个过程、项目集、项目组合的政策、公司战略等等。
3、如何实现整合管理：在整合管理的过程中要经常寻找平衡点，考虑各种约束条件、风险和不确定性来满足项目的目标。
4、要点：
5、过程组：
制定项目章程（4.1）
1、定义：编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
2、作用：明确项目与组织战略目标之间的联系，确立项目的正式地位，并展示组织对项目的承诺。
3、要点：
- 在项目执行组织和需求组织之间建立伙伴关系。
- 项目章程的批准是项目正式启动的标志。
- 通过编制项目章程，来确认项目符合组织战略和日常运营的需要。
- 最好在制定项目章程时就任命项目经理（最晚应在规划前开始）。
- 项目章程可由发起人编制，或由项目经理与发起机构合作编制。
- 项目由项目以外的人员批准和启动，如发起人、PMO或项目组合治理委员会。
- 发起人应该具有一定的职权，能为项目获取资金并提供资源。
4、制定项目章程的输入：
4.1、商业论证：文档化的项目经济可行性研究报告，包含商业需要分析与成本效益分析。主要是从商业视角描述必要信息，论证项目的合理性，并据此决定项目的预期结果是否值得所需投资，并确定项目边界。高于项目级别的经理和高管们通常使用该文件作为决策的依据。
4.2、协议：协议定义了启动项目的初衷。通常，为外部客户做项目时，就用合同。
4.3、事业环境因素、组织过程资产，基本上是所有过程的输入。
4.4、工作说明书（Statement of Work / SOW）内容包括概括的战略目标、业务需求、可交付成果（产品描述）。PMBOK第6版中制定项目章程的输入，第7版删去；现为规划采购管理的输出。协议和外包采购都会有，是采购人向供应商提供的。
5.1、制定项目章程的工具与技术：专家判断
具有专业知识或受过专业培训的任何小组或者个人，都可以提供专家判断。所以专家判断，有时不仅仅是一个人，有时可以是一个小组、多人。比如主题专家 SME、PMO、行业协会、客户、发起人等等都可以提供专家判断。
项目经理的周边到处都是专家。项目经理自己本身是项目管理专家，但并不表示他什么都该知道。专业技术方面的问题可以咨询主题专家，财务问题可以咨询财务专家。专家判断可用于第四章整合管理的全部过程组。
通俗点来说专家判断就是拍脑袋想问题。
5.2、制定项目章程的工具与技术：数据收集（头脑风暴、焦点小组、访谈）
1）头脑风暴：一种用来产生和收集对项目需求与产品需求的多种创意的技术，又称“集思广益”。拍脑袋、天马行空、集思广益、没有对错，能在短时间内获得大量创意，需要引导者进行引导。不涉及排序或投票。
头脑写作，头脑风暴的进阶版，用于收集创意，适用于内向性格成员较多的团队。每个人把想法写下来，然后以匿名的方式进行传递，添加修改，经过几轮传递，搜集想法，进行分析。
2）焦点小组：召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度，由一位受过训练的主持人引导大家进行互动式讨论，比一对一的访谈更加热烈。
3）访谈：通过与相关方直接交谈，来获取信息的方法。采取“提问—回答”的方式，通常一对一，有时也可多对多。（相关方不多，且愿意说并说得清楚）
5.3、制定项目章程的工具与技术：人际关系与团队技能（冲突管理、引导、会议管理）
1）冲突管理：（详见第9章资源管理）有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑和其他内容达成一致意见；
2）引导：引导者有效指导团队活动成功以达到成功决策、解决方案或结论的能力。
3）会议管理：（详见第10章沟通管理）包括准备议程、确保邀请每个关键相关方群体的代表，以及准备和发送后续的会议纪要和行动计划。
6.1、制定项目章程的输出：项目章程
项目章程又称“项目批准书”，是由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。章程相当于发起人与项目经理之间的契约。
项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。
包括以下12个内容：
1）项目目的
2）可测量的项目目标和相关的成功标准
3）高层级（high-level）需求：（是指宏观、大概、大体上、战略上的需求）
4）高层级项目描述、边界定义以及主要可交付成果（这是一个什么项目？要形成什么产品？）
5）整体项目风险；（主要的风险）
6）总体（Summary）里程碑进度计划：（几个关键的里程碑进度）
7）预先批准的财务资源（大概的项目预算）
8）关键相关方名单：（大概的相关方名单）
9）项目审批要求：（用什么标准评价成功、由谁对成功下结论、由谁来签署项目结束）
10）项目退出标准：（在何种条件下才能关闭或取消项目或阶段）
11）委派的项目经理及其权责
12）发起人或其他审批项目章程的人员的姓名和职权。
6.2、制定项目章程的输出：假设日志
用于记录整个项目生命周期中的所有假设条件和制约因素。
假设条件：不确定因素、风险，需要渐进明细。
制约因素：限制性的因素，比如事先确定的预算、强制性日期、进度里程碑、合同条件等，不是渐进明细的。
- 项目基于假设，同时受制于制约因素。
- 编制商业论证时就要识别高层次（战略、运营）假设条件及制约因素（记入章程）
- 较低层次的活动、任务等假设条件在各规划过程记录（范围说明书、风险登记册）
- 如果假设条件改变，项目可能在阶段审查后取消。
制定项目管理计划（4.2）
1、定义：定义、准备和协调所有子计划，并把它们整合为一份综合项目管理计划。
2、作用：生成一份核心文件，用于确定所有项目工作的基础及其执行方式。
3、要点：
- 确定项目的执行、监控和收尾方式，内容会因项目所在的应用领域和复杂程度而异。
- 在项目预定时间开展，并需要通过不断更新来渐进明细。
- 确定基准之前，这些更新无需遵循正式流程。
- 确定基准之后，只能通过实施整体变更控制过程进行更新。
- 项目管理计划的制定应该与项目集或项目组合管理计划一致。
- 与其他9个知识领域规划工作的关系：总-分-总。
PMI要求在项目中所做的所有事情都必须是在计划中所体现的，做计划之外试图“讨好”相关方被称为“镀金”，这是项目中明令禁止的。
比如客户要PM去买包烟，PM买了烟后又私自决定给客户配了个打火机。这就是镀金了，客户并不需要打火机，也许客户自己有更高级的“ZIPPO”，并不需要PM给他买的打火机。 镀金，是画蛇添足、因为浪费了资源。
4、制定项目管理计划的输入：“其他过程的输出”
是指子计划和基准，比如：范围管理计划、进度管理计划、成本管理计划等等，制定项目管理计划要参考这些子计划，把他们整合为综合的“项目管理计划”。
5、制定项目管理计划的工具：数据收集（头脑风暴、核对单、焦点小组、访谈）
核对单：基于类似项目和历史信息来编制核对单，或采用所在行业的核对单。核对单用来指导项目经理制定计划或帮助检查项目管理计划是否包含所需的全部信息。
6、制定项目管理计划的输出：项目管理计划
项目管理计划，是说明项目将如何执行、监控和收尾的一份文件。它整合并综合所了有子管理计划和基准，以及管理项目所需的其他信息（取决于具体项目的需求）。
构成：子计划、基准和其他组件。
1）子计划：范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、相关方管理计划、风险管理计划、采购管理计划。
2）3个基准：范围基准、进度基准、成本基准。
基准：工作产品、项目计划，经过批准，即成为基准。只有通过正式的变更控制程序才能对其进行变更。用于与实际绩效比较，来确定绩效是否在可接受的偏差范围内。
比如：某网银每天限制转账额度5000，超过5000就要使用大额转账技术，比如u 盾、密保卡等等。这个5000就是一个基准。 如果这个基准需要变化，需要经过正式的变更控制程序才能变更。
3）其他组件（配置管理计划、变更管理计划、绩效测量基准、项目生命周期、开发方法、管理审查）：
绩效测量基准Performance Measurement Baseline，简称PMB。
项目范围-进度-成本三位一体基准。为项目工作制定的，经批准的范围-进度-成本综合计划，用来与项目执行情况相比较，以测量和管理绩效。
项目管理计划的批准：
项目管理计划的批准：《项目管理计划》一定要得到管理层、发起人、项目经理、项目团队代表和相关项目干系人的同意和正式批准。一个项目或项目阶段，如没有正式批准的《项目管理计划》是难以有效开展的。正式批准意味着相关方的签名，签名意味着发起人与项目经理，项目经理与团队成员之间建立的契约关系。
开工会议：Kickoff Meeting：又称开踢会议
- 定义：宣告项目正式进入执行阶段的会议。
- 召开时间：项目规划完成后、项目执行开始前召开；属于规划过程组。
- 参加方：项目各重要相关方（发起人、顾客、高层管理、职能管理部门、卖方代表、项目团队等）。
- 作用：宣告项目进入执行阶段；传达项目目标与项目管理计划，团队就项目目标达成一致，获得相关方对项目的承诺与支持，阐明每个相关方的角色和职责，相当于开工典礼。
启动会议：Initiating Meeting
- 定义：宣布项目成立并启动，任命项目经理的会议。
- 召开时间：在项目启动阶段结束时。
- 作用：发布项目章程，宣告项目正式启动；任命项目经理，赋予项目经理动用组织资源的权力。
- 注意与开踢会议的区别，考试遇到看英文。
指导与管理项目工作（4.3）
1、定义：为实现项目目标而执行项目管理计划中所确定的工作，并实施已批准的变更的过程。
2、作用：对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。
3、要点：
- 执行已计划好的方法和标准，开展活动来实现项目目标。
- 创造项目的可交付成果，完成规划的全部工作。
- 获取、管理和使用资源，包括人员、材料、工具、设备与设施。
- 建立并管理项目团队内外的项目沟通渠道，管理项目相关方参与。
- 生成项目工作绩效数据，传递给核实的控制过程进行分析，并为预测提供基础。
- 提出变更请求，实施批准的变更。
- 管理风险并实施风险应对活动。
- 收集和记录经验风险，并实施批准的过程改进活动。
4、指导与管理项目工作的输入：批准的变更请求
输入有“批准的变更请求”，这个是已经遵循变更管理流程被相关方批准的。
5、指导与管理项目工作的工具：项目管理信息系统（PMIS）
用来收集和发布绩效数据的系统，可自动收集和报告KPI是PMIS的重要功能。
项目管理信息系统提供下列工具：进度计划工具、工作授权系统、配置管理系统、信息收集与发布系统，或进入其他在线自动化系统的网络界面。
- 变更控制系统：明确CCB的角色和职责，辅助完成变更控制活动
- 配置管理系统：识别产品或组成部分功能和属性。控制上述特征的变更。配置状态记录每个变更实施情况。辅助审核，核实是否符合要求。
- 工作授权系统：规定如何授权项目工作，保证项目做正确（授权）的工作，尽最大限度防止镀金。确保某些特殊的工作的开展经过授权。结构化的方法也会限制工作的灵活性。
6.1、指导与管理项目工作的输出：可交付成果
可交付成果（Deliverables）：在某一过程、阶段或者项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。
可交付成果可以是有形的产品，或无形的计划、服务能力等。
6.2、指导与管理项目工作的输出：工作绩效数据（work performance data）
在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。只在指导与管理项目工作输出。
数据是底层的细节，将交由其他过程从中提炼出信息；执行过程中收集数据，再交由控制过程做进一步分析。
比如：第一天计划预习PMBOK 到50页，实际只预习到30页。30是工作绩效数据。
典型的工作绩效数据包括：已完成的工作、KPI、技术绩效测量结果、进度活动的实际开始日期和完成日期，已完成的故事点、可交付成果状态、进度进展情况、变更请求数量、缺陷数量、实际发生的成本、实际持续时间等
6.3、指导与管理项目工作的输出：问题日志
在整个项目生命周期中，项目经理经常会遇到问题、差距、不一致或意外冲突，需要采取某些行动来加以处理，以免影响项目绩效。问题日志可以帮助项目经理有效跟进和管理问题，确保他们得到调查和解决。
项目内解决不了的问题，在收尾时关闭。
6.4、指导与管理项目工作的输出：变更请求
在执行项目管理计划中的工作的时候会引发新的变更请求，这是项目的渐进明细。变更请求：任何相关方都可以提交变更请求，变更请求一定是对项目的某一方面有变化，需要可交付成果、基准或者项目文件更新。
1）纠正措施：实际绩效与计划之间已存在偏差，需要纠偏；强调过程出问题还未影响结果的变更；
2）预防措施：防止实际绩效与计划之间出现偏差，需要防范；
3）缺陷补救：产品组件有质量问题，需要修正；强调针对结果已经出问题的变更；
4）更新：针对受控文件或计划的变更。
如果改变了计划，一定是更新；前面三者：计划不变。
管理项目知识（4.4）
1、定义：使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。
2、作用：利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。
3、要点：
- 知识分为显性知识和隐性知识。
- 重复使用现有知识并生成新知识。
- 显性知识易分享，不易理解；隐性知识虽蕴含情境，却很难编撰。
- 要营造一种互相信任的氛围，激励人们分享知识或关注他人的知识。
- 小事随时复盘，大事阶段复盘。
2.2、管理项目知识的工具：知识管理（无法脱离人而存在）
促进员工合作创造新知识，分享隐性知识。
比如人际交往、工作跟随和跟随指导。
1）人际交往：在组织、行业或职业环境中与他人的正式或非正式互动。
人际交往在项目初始时特别有用，目的是为了建立关系，增加获取资源的途径，改进人力资源管理。人际交往的方式有很多种：写信、午餐会、座谈会等等。
2）工作跟随：徒弟跟着师傅实习，徒弟无需承担任何责任，全部责任由师傅承担。
3）跟随指导：师傅跟随和观察新手的工作情况，并给予指导。
4）交互式培训：学习曲线很陡的知识（学习后容易上手），可采用该方式。例如学折纸飞机，容易学会所以采用交互式培训。
2.2、管理项目知识的工具：信息管理（可以脱离人而存在）
用于促进显性知识分享的各种具体方法。
比如：图书馆服务、文献检索、经验教训登记册编制。
3、管理项目知识的输出：经验教训登记册（只记录显性知识）
会得到更新，最终存入组织过程资产中。
监控项目工作（4.5）
1、定义：跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。
2、作用：让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解项目未来状态。（把实际绩效和项目管理计划进行对比，发现偏差、分析原因，提出变更。）
3、要点：
- 监督贯穿整个项目生命周期，比较实际绩效与项目计划。
- 检查项目风险状态，帮助洞察项目健康状况，并明确重点问题。
- 控制包括纠正和预防或重新规划并跟踪行动计划的实施，确保行动的有效性。
- 为状态报告、进展测量、预测提供信息。
- 注意确保项目与商业需求保持一致。
2、监控项目工作的输入：工作绩效信息（work performance information）
从各控制过程中收集并结合相关背景和跨领域关系，进行整合分析而得到的绩效数据。
比如：第一天计划预习PMBOK 到50页，实际只预习到30页。对比发现，比计划少预习20页，20是工作绩效信息。
3、监控项目工作的工具：数据分析
4.1、监控项目工作的输出：工作绩效报告（work performance reports）
为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息，所形成的实物或电子项目文件。
比如：第一天计划预习PMBOK 到50页，实际只预习到30页。对比发现，比计划少预习20页。第二天少预习10页、第三天又少预习15页，最终写成一份报告，为什么总是不遵守计划，怎么总是少预习。是工作效率太低、还是懒惰引起的，分析找到原因等等。汇总写成一份状态报告。
4.2、监控项目工作的输出：变更请求
是指监控项目工作时会引发变更请求。
通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或縮小项目范围与产品范围，调整质量要求和进度或成本基准。
实施整体变更控制（4.6）
1、定义：审查所有变更请求，批准或否决变更，并管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。
2、作用：确保对项目中已记录在案的变更进行综合评审，并决定对变更请求的处置方案。
3、要点：
- PM对此过程负最终责任。
- 可口头提出，但需要书面记录，并纳入变更或配置管理系统。
- 只有经批准的变更才能纳入修改后的基准中和得到执行。
- 应评估变更对进度和成本的影响，并提供评估结果。
- 变更请求必须由一位责任人处理（计划中制定，如发起人、PM、CCB）
- 特定的变更，在CCB批准后，还可能需要得到客户或发起人的批准，除非他们本来就是CCB的成员。
这个过程的作用，就是对这四种提出来的变更请求，批准或否决，然后更新相应的计划或文件。
提出的变更到底是同意，还是拒绝？需要在这个过程做判断。
实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任。
这句话说明PM对变更负最终责任，万一哪个变更变得不好，责任都在PM没有把控好。PM 要对变更请求跟踪负责到底。
4、变更控制委员会（CCB：Change Control Board）
1）CCB 是正式的团体，但不一定是固定的团体；
2）组成：项目发起人、客户、项目经理、相关专家、其他主要相关方；
3）任务：审查、评价、批准、推迟或否决项目变更，记录和传达变更处理请求；
4）设立原因：项目经理权力有限，对于涉及计划基准的变更不能自做主张；
5）数量：一个项目可以只有一个CCB，也可以有负责不同内容的多个CCB；
一句话概括CCB 设立的原因：PM 一个人决定不了的大事需要通过CCB 来群体决策。
5.1、实施整体变更控制的工具：配置管理系统（Configuration Management System）
用于跟踪项目参数和监控这些参数变更的程序的集合，达到保持产品完整性、一致性和可塑性。
- 识别配置项。识别并记录产品、成果、服务或部件的功能特征和物理特征
- 控制对上述特征的任何变更
- 记录并报告配置项状态。关于各个配置项的信息记录和报告，记录变更及其实施情况
- 进行配置项核实与审计。持对产品、成果或部件的审查，以确保其符合要求；配置管理系统明确了为核准和控制变更所需的批准层次。
- 重点关注可交付成果及各个过程的技术规范及参数。
配置管理活动包括：
1）识别配置项：选择与识别配置项，从而为定义与核实产品配置、 标记产品和文件、管理变更和明确责任提供基础。
相当于编号，version 1.0,version 2.0
2）记录并报告配置项状态：关于各个配置项的信息记录和报告。
相当于记录版本的说明，1.0版本拓展了场景文字；2.0版本优化了bug，解决了闪退问题„
3）配置核实与审计：保证项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
确保配置项组成的正确性，确保变更都被记录、评估、批准、跟踪和正确实施。现在2.0的版本要变更到2.1了，要确保这个变更符合流程。
也可以用五大过程组的关系来理解这三个活动：
识别配置项、记录并报告配置项状态属于执行过程组的活动；
配置项核实与审计属于监控过程组的活动；
简单理解配置管理包含了变更管理和版本管理。
5.2、实施整体变更控制的工具：变更控制系统（Change Control System）
一套描述了如何管理和控制可交付成果和文档的修改的程序。
- 识别变更。识别并选择过程或项目文件的变更项。
- 记录变更。将变更记录为合适的变更请求。
- 做出变更决定。审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
- 跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终成果。
- 重点关注识别、记录、批准或否决对项目文件、可交付成果或基准的变更内容及流程。
6、变更的批准权限：
每项记录在案的变更请求都必须由一位责任人批准或否决。这个责任人通常是PM 或者发起人，在项目管理计划或组织流程中会指定批准责任人。必要时由CCB 开展实施整体变更控制过程。
1）PM：一般批准不涉及基准的变更请求，紧急情况可批准特殊的变更请求。
比如有客户老板的连环夺命call，要求马上、立即、立刻进行一个变更，不变就解约，非常紧急。那就PM 自己决定要不要变吧。因为如果走流程的话，时间来不及。
注意：一些很简单的变更，不涉及基准的，比如说相关方登记册里一位相关方的名字写错了，这种小问题，PM 也可以自行决定，不用走流程
2）发起人：一般批准章程的变更；章程写的不清楚，要进行变更，由发起人来决定要不要变；
3）变更控制委员会CCB：批准或否决基准的变更请求；
4）客户：批准按合同实施的项目的某些变更请求，虽然影响基准的变更必须要通过CCB 的批准，但并不意味着CCB 只能批准影响基准的变更，有一些在变更控制系统中指定需要CCB 批准的变更但并没有影响基准。
|
变更类型 |
批准层级 |
备注 |
|
项目章程 |
签署或批准该章程的人 | |
|
项目目标或项目基准的变更 |
CCB |
PM可分析变更影响提出意见 |
|
与合同有关的变更 |
客户 | |
|
项目计划内的变更 |
PM、指定的团队成员 |
可通过赶工或快速根据来解决 |
|
紧急情况下的变更 |
PM |
后补相关手续 |
7、实施整体变更控制原则：
8、实施整体变更控制流程：
- PM 对可能引起变更的因素施加影响；
- 注意！是“施加”影响，而不是第2步的“评估”影响。看看是否是不必要的变更，避免因个人的主观臆断随意进行变更。
- 相关方正式向PM 提交变更请求，并记录变更请求；
- 书面记录变更、创建变更请求。
- PM 评估变更对项目的影响；
- 记录后，评估如果实施变更会对项目产生什么影响。
- PM 与相关方沟通并寻求处理变更的备选方案；
- 寻找处理变更的解决方案
- PM 自主决策；
- 如果变更不影响基准，PM 自主决策，之后更新到变更日志中。
- PM 提交含解决方案的变更请求给CCB 审批；
- 如果变更影响基准，PM 将变更请求提交给CCB。
- 如果CCB 否决了变更请求，将结果更新到变更日志中。
- 更新项目管理计划与项目文件；
- 如果CCB 批准了变更请求，就需要更新项目管理计划／文件。
- 通知受变更影响的相关方；
- 通知会受到变更影响的相关方。
- 项目团队执行批准的变更；
- 项目团队执行、实施批准的变更请求。
- 跟踪确认变更的实施情况；
- 被批准执行的变更，跟踪、记录实施情况如何。
结束项目或阶段（4.7）
1、定义：完结所有项目管理过程的所有活动，正式结束项目或阶段。也叫项目收尾、行政收尾、阶段收尾。
2、作用：存档项目或阶段信息，完成计划的工作，释放组织团队资源以开展新的工作。
3、要点：
- 为达到阶段或项目的完工或退出标准所必须的行动和活动。
- 为关闭项目、阶段合同协议所必须开展的活动。
- 为完成经验教训总结所必须开展的活动
- 为向下一个阶段，或者向生产运营部门移交项目的产品、服务或成果所必须开展的活动。
- 收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门。
- 测量相关方的满意程度。
项目有明确的起点和终点，起点是项目章程获得批准
终点是：
1）目标达成
2）不能达到目标项目终止
3）项目需求不复存在
4）客户或发起人希望终止等等
如果项目在完工前就提前终止，本过程还需制定程序，来调查和记录提前终止的原因。
4.1、结束项目或阶段的输入：项目章程
记录了项目成功标准、审批要求，以及由谁来签署项目结束
4.2、结束项目或阶段的输入：项目管理计划
结束项目时，项目经理需要审查项目管理计划中的范围基准，确保所有的项目工作均已完成，才可以进行收尾。
4.3、结束项目或阶段的输入：商业文件
商业论证：用于确定项目是否达到了经济可行性研究的预期结果
收益管理计划：用于测量项目是否达到了计划的收益
4.4、结束项目或阶段的输入：验收的可交付成果
正常收尾的验收的可交付成果包括批准的产品规范、交货收据和工作绩效文件；
分阶段或被取消的项目中，包括未全部完成的可交付成果或中间可交付成果。
5、结束项目或阶段的工具：会议
用于确认可交付成果已通过验收、确定已达到退出标准、正式关闭合同，评估相关方满意度，传递项目知识和信息，以及庆祝成功。
参与者：团队成员、参加项目或受项目影响的相关方
会议类型：收尾报告会、客户总结会、经验教训总结会，以及庆祝会等
6.1、结束项目或阶段的输出：最终产品、服务或成果移交
项目收尾，移交项目所产出的最终产品、服务或成果；
阶段收尾，移交该阶段所产出的最终产品、服务或成果。
6.2、结束项目或阶段的输出：最终报告
用最终报告总结项目绩效，可包括以下信息：
a)项目或阶段的概述
b)范围目标、范围的评估标准，以及证明达到完工标准的证据
c)质量目标、项目产品和质量的评估标准，核实信息以及偏差原因
d)成本目标，包括可接受的成本区间、实际成本，以及偏差原因
e)最终产品、服务或成果的确认信息的概述
f)进度目标，包括成果是否实现项目所预期的收益，以及未来实现情况
g)最终产品、服务或成果如何满足商业计划所述业务需求的概述
h)项目过程中发生的风险或问题及其解决情况的概述
7.1、结束项目或阶段：行政收尾
1）为达到阶段或项目的完工或退出标准所必需的行动和活动(确认该做的已经做完，怎么确认，通过什么确认，审查项目管理计划中的范围基准）；
2）确认卖方的工作已通过正式验收，并处置未决索赔；(确认供应商交付的产品已通过验收，并处理采购工作涉及的索赔）；
3）为向下一个阶段或向生产和/或运营部门移交项目的产品、服务或成果所必需的行动和活动（最终成果做移交）；
4）总结经验教训并存档；
5）收集关于改进的建议；
6）测量相关方满意程度；
7）庆功会；
8）释放资源；
7.2、结束项目或阶段：项目审计
项目后评价（Post Project Evaluation）是指在项目已经完成并运行一段时间后，对项目的目的、执行过程、效益、作用和影响进行系统的、客观的分析和总结的一种技术经济活动。包括目标后评级、效益后评价、影响后评价、项目管理后评价。
商业论证与项目审计的比较
商业论证：项目前评价；项目审计：项目后评价
相同点：
- 性质相同，都是对项目生命周期全过程进行技术、经济论证。
- 目的相同，都是为了提高项目的效益，实现经济、社会和环境效益的统一。
不同点：
- 评价的主体不同（目标、成果）
- 所处的阶段不同（项目前、项目后）
- 评价的依据不同（假设、数据）
- 在决策中的作用不同
