项目整合管理
- 项目整合管理包括对项目管理过程组内的各种过程和项目管理活动而进行识别、定义、组合、统一与协调的各种过程和活动
- 项目整合管理必须由项目经理负责。其他知识领域可以由相关领域专家管理，但整合的责任不能被授权或转移
- 项目与项目管理本质上具有整合性质
- 项目管理过程组的各个过程之间经常反复发生联系
- 整合管理包括整个整合管理知识领域所有过程所开展的全部工作
- 项目越复杂，干系人的期望越多样化，就越需要全面的整合方法
1、需要对什么进行整合？
干系人需求、约束条件、项目管理各个过程、项目集、项目组合的政策 、公司战略等等。
2、如何实现整合管理？
在整合管理的过程中经常寻找平衡点，考虑各种约束条件、风险和不确定性来满足项目的目标
知识领域构成
制定项目章程
- Develop Project Charter
- 过程定义：编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程
- 过程作用：明确项目与组织战略目标之间的直接联系， 确立项目的正式地位，并展示组织对项目的承诺
- 项目章程的批准，标志着项目的正式启动
- 项目经理应参与项目章程的制定，以便对项目需求有基本的了解，并能更有效地分配资源
- 项目由项目以外的机构来审批授权启动，如发起人、项目集、 PMO或项目组合、治理委员会主席或其授权代表
- 项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源
- 合同不可取代章程
小结：
立项报告+项目经理授权书 = 项目章程
项目经理和项目发起人都可以写章程
发起人或公司高层批准项目章程
若项目章程模糊不清晰或者理解歧义由发起人或高层澄清。
制定项目章程:过程
制定项目章程：输入
商业文件（Business Documents）
- 主要包括商业论证和收益管理计划
- 商业论证或类似文件从商业视角描述必要信息， 并据此决定项目的预期结果是否值得所需投资
- 高于项目级别的经理和高管们通常使用该文件作为决策的依据
- 商业论证包含商业需要分析与成本效益分析
- 论证项目的合理性，并确定项目边界
- 商业论证的原因要符合组织战略需要：
- 市场需求、组织需要、客户要求、技术进步、法律要求、生态影响、社会需要等
- 项目经理不可以对商业文件进行更新或修改，只可以提出相关建议
协议（Agreement）
- 协议用于定义启动项目的初衷
- 协议具有多种形式：
- 合同 Contract
- 谅解备忘录 MOUs
- 服务水平协议 SLA
- 协议书 Letter of Agreements
- 意向书 Letter of Intents
- 口头协议 Verbal Agreements
- 电子邮件 Email
- 其他书面协议 Written Agreements
- 为外部客户做项目，一般采用合同的形式
事业环境因素
- 政府或行业标准
- 法律法规要求和(或)制约因素
- 市场条件
- 组织文化和政治氛围
- 干系人的期望和风险临界值
组织过程资产
- 组织的标准政策、流程和程序
- 项目组合、项目集和项目的治理框架
- 监督和报告方法
- 模版(如项目章程模板)
- 历史信息与经验教训知识库(如以往项目选择决策的结果）
制定项目章程：T&T
专家判断（Expert Judgment）
- 是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断
- 具有专业学历、知识、技能或培训经历的任何小组或个人， 都可以提供专家判断，尤其是主题专家（SME）
数据收集 - 头脑风暴
- 一种用来产生和收集对项目需求与产品需求的多种创意的技术，又称"集思广益"
- 在正常融洽和不受任何限制的气氛中以会议形式进行讨论、 座谈，打破常规，积极思考，畅所欲言，充分发表看法
- 用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导，由两部分组成:创意产生和创意分析
- 本身不包含投票或排序， 常与其他技术一起使用
- 特点:面对面、无拘无束、快速、不求最后结果!
- 头脑风暴向干系人、主题专家和团队成员收集数据、解决方案和创意
小结：产生 创意
数据收集 - 焦点小组
- 焦点小组是一种一对多的群体访谈方式，由主持人组织被调查者针对提问，展开互动式的讨论。
- 焦点小组成为均为同一领域的专家。
- 焦点小组调查必须由主持人来主持，他负责组织并保持
- 焦点小组成员围绕某个具体问题展开讨论。
小结：解决问题、 思考对策
数据收集 - 访谈
- 通过与干系人直接交谈，来获取信息的正式或非正式的方法
- "提问---回答"的方式
- 通常一对一 ，有时也可多对多
- 访谈对象：有经验的项目参与者、发起人、其他高管、主 题专家
- 有助于识别和定义所需产品可交付成果的特征和功能
人际关系与团队技能 - 引导（Facilitation）
- 引导式研讨会是在主持人引导下展开的研讨会。 主持人引导来自不同领域的参会者进行交流和讨论，协调各方的利益， 达成一定程度的共识。
- 推进、推动
会议
- Meeting
- 在本过程中，与关键干系人举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概要信息
制定项目章程：输出
项目章程（Charter）
- 项目章程是由项目启动者或发起人发布的， 正式批准项目成立 ， 并授权项目经理动用组织资源开展项目活动的文件
- 项目章程确保干系人在总体(大概)上就主要可交付成果、里程碑 以及每个项目参与者的角色和职责达成共识
- 章程相当于发起人与项目经理之间的契约， 项目经理接受章程， 便正式接受了发起人的委托
项目启动会（Initiating meeting）
- 意味着启动阶段的结束。
- 主要任务：发布项目章程，任命项目经理， 赋予项目经理动用组织资源的权力
项目章程构成要素
|---------------------------------------|-----------------------------------------------|
| 项目目的 | 预先批准的财务资源 |
| 可测量的项目目标和相关的成功标准 | 关键干系人名单 |
| 高层级（High-level）需求 | 项目审批要求（如用什么标准评价项目成功，由谁对项目成功下结论， 谁来签署项目结束） |
| 高层级项目描述、边界定义以及主要可交付成果 | 项目退出标准（如在何种条件下才能关闭或者取消项目或阶段） |
| 整体项目风险 | 委派的项目经理及其职责和职权 |
| 总体 （Summary）里程碑进度计划 | 发起人或其他审批项目章程的人员的姓名和职权 |
关键字：目的；目标 成功标准；高层级需求、描述、边界定义、主要可交付成果；风险；里程碑；财务资源；审批要求；退出标准；职责和职权；审批人员名单。
假设条件
- Assumptions
- 指那些在制定计划时，不需验证仍被视为正确、真实或确定的因素
- 如果这些因素不成立，可能造成潜在的影响
- 假设条件重要性体现在：
- 让团队形成一个参考或基准
- 基于当时条件可获得的最好信息
- 对已接受的信息形成团队共识
- 避免项目团队重复分析相同信息
- 被记载下来作为决策制定的参考
- 假设条件的特点：
- 是渐进明细的
- 是风险识别的一项重要输入
- 是有时间限制性的
- 以当时所能得到的最准确信息为假设基础
小结：假设->风险；
制约因素
- Constraints
- 对项目或过程的执行有影响的限制性因素，如组织事先确定的预算、强制性日期或进度里程碑，合同条款等
- 制约因素对计划来说很重要是由于：
- 避免团队在他们无法改变的事情上白费功夫
- 让团队关心项目能施加影响的重要事情
- 对风险和风险应对有帮助
- 作为参考文件备案并帮助决策
- 制约因素的特点：
- 通常不可变
- 在规划阶段限制了团队的可选方案
- 不是渐进明细的
- 是必须接受并在所有计划活动中予以考虑的
制定项目管理计划
- Develop Project Management Plan
- 过程定义：定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程
- 过程作用：生成一份综合文件，用于确定所有项目工作的基础及其执行方式
- 它仅开展一次或仅在项目的预定义点开展
- 项目管理计划确定项目执行、监控和收尾方式
- 项目管理计划应足够强壮和敏捷，以应对不断变化的项目环境
- 项目管理计划应基准化，确定基准之前，更新无需遵循正式流程。一旦形成基准之后，就只能通过实施整体变更控制过程进行更新。这种 更新导致在项目收尾之前，项目管理计划不断渐进明细
- 隶属于项目集或项目组合的项目管理计划需要和项目集或项目组合管理计划相一致
制定项目管理计划:过程
制定项目管理计划:输入
项目章程
- 初始项目规划的起始点
其他过程的输出
- 创建项目管理计划需要整合诸多过程的输出
- 其他规划过程所输出的子计划和基准都是本过程的输入
- 子计划或基准的变更都可能导致项目管理计划的更新
事业环境因素
- 垂直市场(如建筑)或专门领域(如环境、安全、风险或敏捷软件开发)的项目管理知识体系
- 组织治理框架
组织过程资产
- 项目管理计划模板
- 变更控制程序
- 历史信息和经验教训知识库
制定项目管理计划:T&T
核对单
- Checklists
- 核对单是包括需要考虑的项目、行动或要点的清 单
- 常用来作为提醒
- 基于从类似项目和其他信息来源积累的历史信息来编制核对单
- 或采用所在行业的核对单
- 核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需的全部信息
人际关系与团队技能
- 可用于本过程的人际关系与团队技能包括:
- 冲突管理: 冲突管理必要时可以让具有差异性的干系人就项目管理计划的所有方面达成共识
- 引导
- 会议管理: 会议管理确保有效召开多次会议，以便制定、统一和商定项目管理计划
会议
- 本过程通过会议讨论项目方法，确定为达成项目目标而采用的工作执行方式，以及制定项目监控方式，包括项目开工会议
制定项目管理计划:输出
项目管理计划
- 说明项目将如何执行、监控和收尾的一份文件
- 整合并综合所有子管理计划和基准，以及管理项目所需的其他信息(取决于具体项目的需求)
- 还包括其他组件:
- 变更管理计划:描述在整个项目期间如何正式审批和采纳变更请求
- 配置管理计划:描述如何记录和更新项目的特定信息，以及该记录和更新哪些信息，以保持产品、服务或成果的一致和/或有效性
- 绩效测量基准
- **项目生命周期:**描述项目从开始到结束所经历的一系列阶段
- 开发方法:描述产品、服务或成果的开发方法，例如预测、迭代、敏捷或混合型模式
- 管理审查:确定项目经理和有关干系人审查项目进展的时间点，以及考核绩效是否符合预期，或者确定是否有必要采取预防或纠正措施
考点：绩效测量基准，项目生命周期
10个子计划；3个基准；6个他组件;
项目管理计划构成
项目基准Baseline
- 包括:范围基准、进度基准和成本基准
- 经批准的版本，只有通过正式的变更控制程序才能对其进行变更
- 用于与实际绩效比较，来确定绩效是否在可接受的偏差范围内
绩效测量基准 Performance Measurement Baseline( PMB )
- 用于挣值管理中
- 项目范围-进度-成本三位一体基准
- 为项目工作制定的，经整合的范围-进度-成本综合计划，用作项目执行的比较依据，以测量和管理项目绩效
三位一体基准
项目管理计划的批准
- 鉴于《项目管理计划》的重要性，一定要得到管理层、发起人、项目经理、项目团队代表和相关项目干系人的同意和正式批准
- 一个项目或项目阶段，如没有正式批准的《项目管理计划》是难以有效开展的
- 正式批准意味着干系人的签名
- 正式批准意味项目管理计划基准化
- 签名意味着发起人与项目经理，项目经理与团队成员之间建立的契约关系
- 项目经理的签名意味着项目经理的承诺
- 项目团队代表的签名意味着团队成员的承诺
开工会议
- Kick-off Meeting
- 又称启动会（注意不要和启动过程/阶段混同） 、开踢会等
- 作用通常意味着规划阶段的结束和执行阶段的开始
- 旨在传达项目目标，获得团队对项目的承诺，阐明每个干系人的角色和职责
- 参加方： 项目各重要干系人（发起人、项目经理、项目团队、 客户、高管层、职能管理部 门、供应商代表等）
指导与管理项目工作
- Direct and Manage Project Work
- 过程定义：为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准的变更的过程
- 过程作用：对项目工作和可交付成果开展综合管理，以提高项目成功的可能性
- 项目经理和项目管理团队一起指导实施已计划好的活动，并管理项目内的各种技术接口与组织接口
- 项目经理还应管理所有的计划外活动，并确定合适的行动方案
- 本过程产出相应的可交付成果
- 本过程收集工作绩效数据，以传递给控制过程进行分析
过程构成
小结：批准的变更请求 与 变更请求 二者之间无关系。输出的变更请求，是指执行4.3过程中有些不合理的地方，需求走变更流程。
专家判断
- 可针对以下主题，开展专家判断
- 关于项目所在行业以及项目关注的领域的技术知识
- 成本和预算管理
- 法规和采购
- 法律法规
- 组织治理
项目管理信息系统)(PMIS )
- 可提供信息技术软件工具:
- 进度计划工具、工作授权系统、配置管理系统、信息收集与发布系统、进入其他自动化系统的网络接口
- 自动收集和报告KPI是PMIS的重要功能
小结：PMIS是事业环境因素。
考点：1）用来传递沟通信息；2）用来收集和记录项目文件，在项目收尾时，可以更新PMIS.即文件归档。
工作授权系统
- Work Authorization System
- 项目管理信息系统的一个子系统
- 工作授权:关于开始某项进度活动、工作包或控制账户的工作的许可或指示，一般是书面形式的工作授权是批准项目工作的一种方法，目的是确保该工作由特定的组织、在正确的时间、以合理的顺序执行
- 工作授权系统是一系列正式书面程序的集合，规定如何授权(委托)项目工作，以保证该工作由特定的组织、在正确的时间、以合理的顺序执行
- 工作授权系统包括发布工作授权所需的步骤、文件、跟踪系统及审批级别
指导与管理项目工作:输出
可交付成果
- Deliverables
- 可交付成果是在某一过程、阶段或者项目完成时， 必须产出的任何独特并可核实的产品、成果或服务能力
- 包括：
- 有形的组件（Components）
- 也可包括项目管理计划
- 一旦完成了可交付成果的第一个版本，就应该执行变更控制
- 用配置管理工具和程序来支持对可交付成果（文件、 软件或构件）的多个版本控制
项目管理数据与信息
- Work Performance Data（WPD）
- 工作绩效数据在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值
- 数据是底层的细节，将交由其他过程从中提炼出信息
- 执行过程中收集数据，再交由控制过程做进一步分析
- 典型的WPD包括：
- 已完成的工作、KPI、技术绩效测量结果、进度活动的实际开始日期和完成日期，已完成的故事点、可交付成果状态、进度进展情况、变更请求数量、缺陷数量、实际发生的成本、实际持续时间等
问题日志
- Issue Log
- 在整个项目生命周期中，项目经理经常会遇到问题、差距、不一致或意外冲突，需要采取某些行动来加以处理，以免影响项目绩效
- 问题日志是记录和跟进所有问题的项目文件
- 问题日志可以帮助项目经理有效跟进和管理问题， 确保他们得到调查和解决
变更请求
- Change Requests
- 关于修改任何文件、可交付成果或基准的正式提议 （Formal Proposal）
- 变更请求可以源自内部或外部，可选或强制提出
- 任何项目干系人都可以提出变更请求，应该通过实施整体变更控制过程对变更请求进行评审和处理
- 变更请求包括：
- 纠正措施 Corrective action，纠正绩效偏差
- 预防措施 Preventive action，防范绩效偏差
- 缺陷补救Defect repair，修正缺陷的产品或组件
- 更新 Updates，针对受控文件或计划的变更
项目管理计划更新
- Project Management Plan Updates
- 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理
- 项目管理计划的任一组成部分都可在本过程中通过变更请求加以更新
项目文件更新
- Project Documents Updates
- 可在本过程更新的项目文件包括(但不限于)
- 活动清单假设日志
- 经验教训登记册
- 需求文件
- 风险登记册
- 干系人登记册