备注：
1.这里将汇总所有管理的输入、输出、使用的工具
2.对真题考过的点，将会标红处理，并进行细致说明
3. 针对最新的改版点，用绿色标记
| 十大管理 | 启动过程组 | 计划过程组 | 执行过程组 | 监控与控制过程组 | 收尾过程组 |
项目整合管理 | 1.制定项目章程 | 2.制定项目管理计划 | 3. 指导与管理项目工作 4. 管理项目知识 | 5. 监控项目工作 6. 实施整体变更控制 | 7.结果项目或阶段 |
项目范围管理 | 1.规划范围管理 2.收集需求 3.定义范围 4.创建WBS | 5.确定范围 6.控制范围 | |||
项目进度管理 | 1.规划进度管理 2.定义活动 3.排列活动排序 4.估算活动持续时间 5.制定进度计划 | 6.控制进度 | |||
项目成本管理 | 1.规划成本管理 2.成本估算 3.制定预算 | 4.控制成本 | |||
项目质量管理 | 1.规划质量管理 | 2.管理质量 | 3.控制质量 | ||
项目资源管理 | 1.规划资源管理 2.估算活动资源 | 1.获取资源 2.建设团队 3.管理团队 | 4.控制资源 | ||
项目沟通管理 | 1.规划沟通管理 | 2.管理沟通 | 3.监督沟通 | ||
项目干系人管理 | 1.识别干系人 | 2.规划干系人参与 | 3.管理干系人参与 | 4.监督干系人参与 | |
项目风险管理 | 1.规划风险管理 2.识别风险 3.实施风险定性管理 4.实施风险定量管理 5.规划风险应对 | 6.实施风险应对 | 7.监督风险 | ||
项目采购管理 | 1.规划采购管理 | 2.实施采购 | 3.控制采购 |
真题考点：
1. 项目整合管理:
| 过程 | 输入 | 工具与技术 | 输出 |
| 制定项目章程 | 1.立项管理文件 2.协议 3.组织过程资产 3.事业环境因素 | 专家判断、人际关系与团队、数据收集、会议 | 项目章程、假设日志 |
制定项目章程的作用、输入、输出、整体变更流程、可行性研究、项目说明书
项目章程作用: ①确定项目的地位、②确定项目与战略目标之间的联系、③组织对项目的承诺
整体变更流程：
①由项目经理、相关干系人提出变更申请
②对变更请求初审
③对变更方案论证
④变更控制委员审查批准
⑤变更控制委员会进行通知、组织实施
⑥对实施情况进行监控
⑦对变更后的效果评估
⑧判断发生变更后的项目是否已纳入正常轨道
可行性研究分析包括：经济可行性、财务可行性、投资必要性、组织可行性、社会可行性、技术可行性、风险因素控制的可行性
项目建议书内容、作用：
①内容：项目的必要性、项目的市场预测、产品或服务的市场预测、项目建设的必需的条件
②作用：是国家或上级主管部分选择项目的依据、可行性研究的依据、项目建设书批准之后，方可对外工作
2.项目范围管理
范围确认跟质量的不同点、收集需求工具与技术、范围确认、WBS分解过程、WBS分解注意事项、范围管理，范围说明书内容、需求跟踪矩阵
| 过程 | 输入 | 工具与技术 | 输出 |
| 规划范围管理 | 项目章程、项目管理计划、组织过程资产、事业环境因素 | 专家判断、会议、数据分析 | 范围管理计划、 需求管理计划 |
| 收集需求 | 立项管理文件、项目章程、项目管理计划、项目文件、协议、事业环境因素、组织过程资产 | 专家判断、会议、数据分析、决策、数据表现、人际关系与团队技能、系统交互图、原型法 | 需求文件、 需求跟踪矩阵 |
| 定位范围 | 项目章程、项目管理计划、项目文件、事业环境因素、组织过程资产 | 专家判断、数据分析、决策、人际关系与团队技能、产品分析 | 项目范围说明书、 项目文件（更新） |
| 创建WBS | 项目管理计划、项目文件、事业环境因素、组织过程资产 | 专家判断、分解 | 范围基准、 项目文件（更新） |
| 确定范围 | 项目管理计划、项目文件、工作绩效数据、核实的可交付成果 | 检查、决策 | 验收的可交付成果、 变更请求 工作绩效信息、 项目文件（更新） |
| 控制范围 | 项目管理计划、项目文件、工作绩效数据、组织过程资产 | 数据分析 | 工作绩效信息、变更请求、项目管理计划（更新）、 项目文件（更新 |
范围确认跟质量控制的不同点：
| 范围确认和质量控制的不同之处 | |
| 检查内容 | 可交付成果获得客户或发起人的接受 |
| 检查的时间点 | 范围确认一般在阶段末尾执行 |
| 执行人员 | 范围确认由外部干系人员对项目可交付成果进行检查验收 |
| 详略程度 | 递进的，越来越细的检查过程 |
需求跟踪矩阵内容：
- 需求描述：对每个需求的详细说明。
- 来源：标识需求的来源，如用户、干系人或项目团队等。
- 负责人：指定负责满足该需求的团队成员。
- 计划时间：标识满足需求的计划时间。
- 实际完成情况：记录实际完成情况和可能遇到的延误或问题。
- 测试策略
- 测试场景
项目范围说明书内容：
①产品范围描述
②验收标准
③可交付成果
④项目的除外责任
⑤制约因素
⑥假设条件
WBS分解注意事项：
①是面向可交付成果的
②符合项目的范围
③底层应该支持计划和控制
④层数一般为4-6层
⑤里的元素必须有人负责，且由一个人负责
⑥工作包的完成时间不应该大于80小时
⑦也要包括分包出去的工作
⑧编制需由所有（主要）项目干系人、团队成员共同参与
⑨并非是一成不变的
3.项目进度管理
4.项目成本管理
一致性成本：在项目期间用来防止失败的费用
非一致性成本：项目期间和项目完成后用于处理失败的费用
5.项目质量管理
质量审计目标：
①识别全部正在实施的良好及最佳实践（发现好的）
②识别全部违规做法、差距及不足（发现不好的）
③分享所在组织或者行业类似项目的良好实践（分享好的）
④积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率（变成好的）
⑤强调每次审计都应对组织经验教训的积累做出贡献（积攒好的）
6.资源管理
| 过程 | 作用 |
| 规划资源管理 | 根据项目的类型、复杂程度来确认适用于项目资源的管理方法和管理程度 |
| 估计活动资源 | 确定完成项目所需的资源种类、特性、数量 |
| 获取资源 | 概述和指导资源的选择，并将获取的资源分配到对应的活动 |
| 建设团队 | 改进团队的协作、增加人际关系技能、激励员工、减少摩擦以及提升整体项目绩效 |
| 管理团队 | 影响团队行为、管理冲突以及解决问题 |
| 控制资源 | 确保所分配的资源适时、适用可用于项目；资源不再需要时被释放 |
7.项目沟通管理
沟通的交互方式
交互式沟通：会议、电话
拉式沟通：在线课程
推式沟线：电子邮件
冲突管理：
妥协(调解)、强迫（命令）、合作（解决问题）、缓和（包容）、撤退（回避）
8.项目干系人管理
识别项目中的干系人
权利/利益方格
管理干系人具体做法：
根据A\B\C\D区域分别采取策略管理
其它：定期召开干系人会议，与关键干系人进行面对面沟通，解决问题和获取反馈。 制定详细的需求管理计划，明确需求的收集、分析和验证过程，确保需求满足干系人期望。 建立项目信息发布渠道，包括内部网站、电子邮件通知和定期报告，确保干系人能够随时获取项目信息
9.项目风险管理
风险识别与应对
风险登记册
风险管理流程：风险再识别、项目文件更新
风险应对策略:
消极风险(威胁)的应对策略：避免(回避)；转移(转嫁)；减轻；接受(被动记录、主动应急)；上报
积极风险(机会)的应对策略：开拓；分享；提高；接受; 上报
SWOT: 优势、劣势、机会、威胁
10.项目采购管理
采购步骤、 采购管理、采购入库条件
采购步骤：
①需求确定采购计划
②供应商的搜寻与分析
③定价
④拟定并发出订单
⑤订单的跟踪和跟催
⑥验货与收货
⑦开票和支付货款
⑧记录管理
采购入库条件：
①采购产品验证完毕后，校验合格的产品，出具《进货校验记录单》
②库房核对本项目对应采购设备无误
③供应商提供运货单或到货证明
招投标程序：
招标：明确招标方式
开标：开标时间等方面的描述
评标：介绍评标委员会和描述评判细则等
中标：中标通知书；然后签订合同
其它：
配置管理
①配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
②配置状态：通常可分为三种--> 配置项初建时其状态为草稿。配置项通过评审后，其状态变为正式。此后若更改配置项，则其状态变为修改。当配置修改完毕后并重新通过评审，其状态又变为正式
③配置版本号：处于“草稿”状态的配置项的版本号格式为0.YZ、配置项第一次成为“正式”文件时，版本号为1.0、 处于“修改”状态的配置项的版本号格式为X.YZ
④配置库的建库模式有两种：按配置项类型建库和按任务建库。
⑤配置库变更控制流程：
配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准 或否决申请，实现、验证和发布己修改的配置项。
要对软件产品进行升级，对配置库的操作顺序是：
1）将待升级的基线从产品库中取出，放入受控库。
2）程序员将欲修改的代码段从受控库中检出（Checkout）,放入自己的开发库中进行修改。代码被 Check out 后即被"锁定"，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法 Check out。
3）程序员将开发库中修改好的代码段检入（Checkin）受控库。Checkin 后，代码的"锁定"被解除，其他程序员可以 Check out 该段代码了。
4）软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中。
权限
| 权限 | 内容 |
| Read | 可以读取文件内容，但不能对文件进行变更 |
| Check | 可使用【check in】命令，对文件内容进行变更 |
| Add | 可使用【文件添加】【文件命令】【文件删除】等命令 |
| Destroy | 有权对文件进行不可逆的毁坏，删除，Rollack等命令 |
⑥配置审计（Configuration Audit）也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。
| 权限\人员 | 项目经理 | 项目成员 | QA | 测试人员 | 配置管理员 |
| （文档）Read | √ | √ | √ | √ | √ |
| （文档）Check | √ | √ | √ | √ | √ |
| （文档）Add | √ | √ | √ | √ | √ |
| （文档）Destroy | × | × | × | × | √ |
| （代码）Read | √ | √ | √ | √ | √ |
| （代码）Check | √ | √ | × | × | √ |
| （代码）Add | √ | √ | × | × | √ |
| （代码）Destroy | × | × | × | × | √ |
| 权限\人员 | 项目经理 | 项目成员 | QA | 测试人员 | 配置管理员 |
| Read | √ | √ | √ | √ | √ |
| Check | √ | √ | √ | √ | √ |
| Add | × | × | × | × | √ |
| Destroy | × | × | × | × | √ |
项目组织结构：职能型、矩阵型、项目型
沟通渠道数：n*(n-1)/2
