目录
整合第一个要整合的对象就是资源，接着是项目需求（平衡取舍不同的需求），然后是项目的方法和路径，接下来是对过程做出裁剪，最后一个方面是知识领域之间的关系，如下图：
在整合管理中有7个过程：
整合管理是项目管理的总章，它定了一个准则和规矩，其他所有内容都依据这个内容来展开。
1. 项目执行组织和发起组织之间建立起伙伴关系。
2. 项目的正式启动。
3. 给项目经理正式授权。
制定项目章程是49个过程之一，它的输入包含1、商业文件（商业论证、效益管理计划），2、协议，3、事业环境因素，4、组织过程资产。
协议包含很广，比较正式的是合同，还有一些口头协议等，如下图所示：
输出包含1、项目章程，2、假设日志（例如汇率不变、政局稳定等）。
由上图可见，制定项目章程是很多其他过程的输入。
针对某个项目，我们制定了很多方案，最终某一个方案被领导认可了，那么这个项目的基准就确定了，例如项目预算、开发周期、资源配置等；在项目实施过程中，发现项目跑偏了，或者项目延误了，那么要及时进行纠正，先按照原计划进行纠偏，这样的处理方式是成本最低的解决方案。但是，当项目跑偏很严重，找回原计划的代价更大，即项目的基准已经变了，那么只能重新定制一个计划，建立新的基准，按照新的计划去实施。
在做项目计划的时候，我们要考虑：范围管理、时间约束、质量要求、成本预算、风险识别、相关方与沟通管理。
项目成功，必须要有良好的项目计划与控制；然而，良好的项目计划与控制并不能保证项目一定会成功。必要条件！
根据微软的一个实例，体现做项目计划的重要性：
没有做计划的项目后期暴露了很多问题，随着时间的推进，很多生产性工作继续不下去，要耗费很多时间和精力去处理协调性工作和计划与控制工作。
而坚持做项目计划的项目，前期虽然花费了一些时间和精力来做计划与控制工作及协调性工作，但随着时间的推移，项目进展越来越顺。
通过两种鲜明对比，可见项目计划的重要性。
项目计划包含两类文件：项目管理计划、项目文件。
项目管理计划是一类特殊的项目文件：
包含“管理”两个字的文件便不包含项目的具体数据，例如进度管理计划，它并不是项目的横道图、交付周期等，项目进度计划才是项目的进度应该如何排的，下图帮助我们理解：
管理计划里面包含的是方法、工具、模型，就像是我们软件上基类的虚函数；
而进度计划里面包含的才是跟项目实际相关的横道图、网络图等数据信息，就像是继承上面基类的子类去实现了管理计划里面规定的方法。
如果说需求管理计划定义的是“你想要的”，那么范围管理计划定义的就是“我要做的”。这两个有着紧密联系，但这两件事不一样，因为你提出的需求并不是我都要做的，我会对你的需求进行一定的妥协、协调。确定了的需求（已经达成共识的必须满足的需求）才能在范围里面体现。
配置管理既包括产品的功能、组件、文档（说明书、使用手册），还包括开发、生产过程中的各种计划、文件及组织过程资产：
配置管理的目标：
1、完整性：配置的定义应当充分完整。
2、一致性：只要是定义了的配置，那么生产出来的就一定跟这个配置一致。
3、可控性：能够按照要求提供可交付的产品，每个功能组件都是按照配置的质量要求来实现的。
4、追溯性：每个版本都可以回滚。
用软件项目的配置管理来说明什么是配置管理：
软件配置管理内容
软件配置管理流程
这是第六版的新知识点，知识管理包含两类：
显性知识和隐性知识在项目知识管理当中是同样的重要。
在项目管理当中要学会“用人”，因为很多隐性知识是难于表达和传递的，让专业的人去做专业的事情。
在项目计划实施当中，免不了要涉及更改，例如项目团队发现用另外一个方案实现项目的时间更短、成本更低，或者相关方提出了新的需求等等。
变更对项目可能的影响：
计划发生变更，如果基准发生变更，新的基准只能对未来的绩效进行评定：
变更通常是项目团队发现的：
项目经理根据项目团队成员的反馈来进行纠偏决策，决定项目是否可以变更的只有两个角色，一个是CCB：
当变更涉及到项目基准发生变化时，必须交由CCB来进行决策；当变更不涉及项目基准发生变化时，项目经理即可自行决策。但是，CCB决定了项目变更的最高决策。
1、相关方提出变更请求，项目团队成员进行变更分析和评估，如果判断没必要变更，则编写反馈报告给到相关方，相关方确认后提交给项目经理输出更新项目文件（变更日志、经验教训登记册）；
2、相关方提出变更请求，项目团队成员进行变更分析和评估，如果判断有必要变更，就提交给项目经理，项目经理根据是否影响项目基准决定是自己决策变更还是提交给CCB进行决策。如果变更不影响项目基准，项目经理决定变更，则更新计划，并通知相关方，进行执行变更。
固定搭配，帮助我们备考：
整合管理里面重要知识点：
