一、目的
集成项目管理（Integrated Project Management， IPM）的目的在于从组织的标准过程集中裁剪得到集成的已定义过程，并以此为依据建立并管理项目以及相关干系人的参与
二、简介
“集成项目管理”涉及以下活动：
• 在项目启动时，通过裁剪组织的标准过程集建立项目已定义的过程
• 用项目已定义的过程管理项目
• 基于组织的工作环境标准，为项目建立工作环境
• 建立旨在达成项目各项目标的团队
• 使用组织级过程资产并为其做贡献
• 在项目期间，使相关干系人关注的事项得以识别、考虑并在适当的时候得到处理
• 确保相关干系人（1）协作、及时地执行他们的任务；（2）处理项目的需求、计划、目标、问题与风险；（3）实现他们的承诺；（4）识别、跟踪与解决协调问题从组织的标准过程集中裁剪得到的、 集成的、已定义的过程叫做项目已定义的过程。（见术语表中“项目”的定义。）管理项目的工作量、成本、进度、人员、风险以及与项目已定义过程中的各项任务息息相关的其它因素。项目已定义过程的实施与管理通常在项目计划中描述。某些活动可能在影响项目的其它计划中涉及，例如质量保证计划、风险管理策略与配置管理计划。因为每个项目已定义的过程都裁剪自组织的标准过程集，通常项目间的差异性会被降低，各项目可以比较容易地分享过程资产、数据与经验教训。本过程域也处理与项目相关的所有活动之间的协调，例如：
• 开发活动（如需求开发、设计、验证）
• 服务活动（如交付、帮助台、运营、客户联系）
• 采购活动（如招标、协议监督、移交运营）
• 支持活动（如配置管理、文档、市场、培训）
计划并管理项目内、外部的相关干系人之间的工作接口和交互，以保证所有努力的质量和完整性。相关干系人可适当参与项目已定义过程和项目计划的定义。与相关干系人进行定期的评审与交流，以保证协调问题获得适当的关注，并且涉及项目的所有人都能适当地了解状态、计划与行动。（见术语表中“相关干系人”的定义。） 定义项目已定义的过程时，可能有必要建立正式的接口，以保证适当的协调与协作。本过程域适用于任何组织结构，包括采用线性组织、矩阵型组织或者团队结构的项目。相关术语应当在所处的不同组织架构中得到适当的解读
三、相关过程域
SG 1 使用项目已定义的过程
SP 1.1 建立项目已定义的过程
SP 1.2 使用组织级过程资产计划项目活动
SP 1.3 建立项目工作环境
SP 1.4 集成各类计划
SP 1.5 使用集成的计划管理项目
SP 1.6 建立团队
SP 1.7 为组织级过程资产做出贡献
SG 2 与相关干系人协调并协作
SP 2.1 管理干系人的参与
SP 2.2 管理依赖
SP 2.3 解决协调问题
SG 1 使用项目已定义的过程
项目的进行得以使用从组织标准过程集裁剪得到的已定义的过程。
项目已定义的过程包含了来自组织的标准过程集的过程，这些过程说明了采购、开发、维护或者交付特定产品所必须的所有过程。
产品相关的生命周期过程，例如制造与支持过程，与产品同步进行开发。
SP 1.1 建立项目已定义的过程
从项目启动开始并贯穿项目生命期的始终，建立并维护项目已定义的过程。
参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产并建立组织的度量库。
参阅“组织级过程关注”过程域以进一步了解如何部署组织级过程资产并部署标准过程。
项目已定义的过程由为项目构成一个集成的、连贯的生命周期的一组已定义的过程组成。
项目已定义的过程应满足项目的合同需求、运营需要、机会与约束。其设计以最适应项目需要为目的。
项目已定义的过程依据以下因素：
• 干系人需求
• 承诺
• 组织级过程需要与目标
• 组织的标准过程集与裁剪指南
• 操作环境
• 业务环境
在项目启动时建立项目已定义的过程，有助于确保项目人员与相关干系人实施一系列活动，以有效地建立项目初始需求集和计划。随着项目的进展，项目已定义的过程的描述会被细化与修订，以更好地满足项目需求与组织的过程需要和目标。另外当组织的标准过程集变更时，项目已定义的过程可能也需要修订
工作产品实例
1. 项目已定义的过程
子实践
1. 从组织级过程资产中现有的模型里，选择一个生命周期模型。
能够影响生命周期模型选择的项目特性实例有：
• 项目的规模或复杂性
• 项目策略
• 人员实施过程的经验与熟悉程度
• 约束，如周期时间与可接受的缺陷级别
• 客户回答问题并对增量提供反馈的可能性
• 需求的清晰度
• 客户期望
2. 从组织的标准过程集中选择最适合项目需要的标准过程。
3. 依据裁剪指南，对组织的标准过程集与其它组织级过程资产进行裁剪，以形成项目已定义的过程。有时已有的生命周期模型与标准过程并不足以满足项目需要。这种情况下，项目应寻求对于其偏离组织要求的批准。豁免就是为实现这一目的而提供的。
裁剪包括使用组织的公共度量项并明确说明额外的度量项来满足项目的信息需要。
4. 适当地使用组织过程资产库中的其它材料。
其它材料可以包括：
• 经验教训文档
• 模板
• 范例文档
• 估算模型
5. 将项目已定义的过程文档化。
项目已定义的过程涵盖了项目的所有活动以及项目与相关干系人的接口
项目活动的实例有：
• 项目计划
• 项目监督
• 供方管理
• 质量保证
• 风险管理
• 决策分析与解决
• 需求开发
• 需求管理
• 配置管理
• 产品开发与支持
• 代码评审
• 招标
6. 对项目已定义的过程进行同级评审
7. 必要时修订项目已定义的过程
SP 1.2 使用组织级过程资产计划项目活动
使用组织级过程资产与度量库来估算并计划项目活动。
参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。
如有可能，则将以往计划与执行活动的结果作为被估算工作量的相对范围与风险的预测因子。
工作产品实例
1. 项目估算结果
2. 项目计划
子实践
1. 使用项目已定义过程的任务与工作产品作为对项目活动进行估算与计划的基础。
对于项目已定义过程的诸多任务与工作产品之间关系的理解，以及对于相关干系人所执行角色的理解，是制订一个可行的计划的基础。
2. 在项目计划参数的估算中，使用组织的度量库。
该估算通常包括：
• 该项目或类似项目的适当历史数据
• 当前项目与提供历史数据的项目间的异同点
• 确认过的历史数据
• 选择该历史数据的原因、假设与依据
• 众多有经验的项目参加者的论证
用于考量异同点的参数实例有：
• 工作产品与任务属性
• 应用领域
• 人员经验
• 设计与开发方法
• 操作环境
组织的度量库中的数据实例有：
• 工作产品规模或其它工作产品属性
• 工作量
• 成本
• 进度
• 人员配备
• 响应时间
• 服务能力
• 供方绩效
• 缺陷
SP 1.3 建立项目工作环境
基于组织的工作环境标准，建立并维护项目的工作环境。
一个项目的适当的工作环境由设施、工具与设备的基础设施构成，人员用以有效执行其工作，以支持业务与项目的目标。工作环境及其组件需要维持一定的、由组织工作环境标准所指定的性能与可靠性水平。项目工作环境或其组件可以根据实际需要由内部开发或者从外部来源采购。项目工作环境可能包含产品集成、验证与确认环境，也可能是各自单独的环境。
工作产品实例
1. 项目的设备与工具
2. 项目工作环境的安装、运行与维护手册
3. 用户调查与结果
4. 使用、性能与维护记录
5. 为项目工作环境提供的支持服务
子实践
1. 为项目计划、设计并安装工作环境。
与其它任何产品一样，项目工作环境的关键点也是需求驱动的。对于工作环境的功能与质量属性的考察应像其它任何产品开发项目一样严格。可能有必要在质量属性、成本、风险之间做一定取舍。以下各给出一些实例：
• 对质量属性的考虑可以包括实时通讯、 安全性、保密性与可维护性。
• 成本可以包括资本支出、培训、支持结构、现有环境的拆卸与处置以及环境的运作与维护。
• 风险可以包括工作流与项目的异常中断。
设备与工具的实例有：
• 办公软件
• 决策支持软件
• 项目管理工具
• 测试与评价设备
• 需求管理工具与设计工具
• 配置管理工具
• 评价工具
• 集成工具
• 自动化测试工具
2. 为项目工作环境提供持续的维护与运作支持。
工作环境的维护与支持可通过组织内部挖潜或组织外部雇佣来实现。
维护与支持方法的实例有：
• 雇佣人员进行维护与支持
• 培训人员进行维护与支持
• 签订维护与支持合同
• 为所选用的工具培养专家级用户
3. 维护项目工作环境组件的合格证明。
组件包括软件、数据库、硬件、工具、测试设备以及适当的文档。软件的合格证明包括适当的认证。硬件与测试环境的合格证明包括校准与调试记录以及对校准标准的可追溯性
4. 定期评审工作环境满足项目需要与支持协作的程度，并适当地采取措施。
可能采取的措施实例有：
• 添加新工具
• 采购额外的网络、设备、培训与支持
SP 1.4 集成各类计划
集成项目计划与影响项目的其它计划，以描述项目已定义的过程。
本特定实践将建立并维护项目计划的特定实践进行拓展，以描述额外的计划活动，如纳入项目已定义的过程、与相关干系人协作、使用组织级过程资产、纳入同级评审计划以及建立任务客观的入口与出口准则。
项目计划的制订应适当考虑组织、客户、供方以及最终用户的、 当前的与规划中的需要、目标与需求。
工作产品实例
1. 集成的计划
子实践
1. 将影响项目的其它计划与项目计划集成起来。
影响项目计划的其它计划有：
• 质量保证计划
• 风险管理策略
• 验证与确认计划
• 移交至运营与支持的计划
• 配置管理计划
• 文档计划
• 人员培训计划
• 设施与后勤计划
2. 将用于管理项目的度量项定义与度量活动纳入到项目计划中。
应被纳入的度量项实例有：
• 组织的公共度量项
• 项目特定的、额外的度量项
3. 识别并分析产品与项目接口风险。
参阅“风险管理”过程域以进一步了解如何识别并分析风险。
产品与项目接口风险的实例有：
• 不完整的接口描述
• 缺乏工具、供方或测试设备
• 缺乏 COTS 组件
• 不充分或无效的团队接口
4. 考虑关键的开发与交付要素以及项目风险，排定任务进度顺序。
在进度排序时考虑的要素实例有：
• 任务规模与复杂度
• 客户与最终用户的需要
• 关键资源的可用性
• 关键人员的可用性
• 集成与测试问题
5.将对项目已定义过程的工作产品执行的同级评审纳入到计划中。
6. 将执行项目已定义的过程所需的培训纳入到项目培训计划中。
本任务通常包含与组织级培训团队协商他们所提供的支持。
7. 建立客观的入口与出口准则，以授权启动与完成工作分解结构（workbreakdown structure， WBS）中描述的各项任务。
8. 确保项目计划与相关干系人的计划适当兼容。
通常应对计划及其变更进行兼容性评审。
9. 确定如何解决相关干系人之间产生的冲突。
SP 1.5 使用集成的计划管理项目
使用项目计划、影响项目的其它计划以及项目已定义的过程来管理项目。
工作产品实例
1. 执行项目已定义的过程所产生的工作产品
2. 收集的度量项（即实际的）与状态记录或报告
3. 修订的需求、计划与承诺
4. 集成的计划
子实践
1. 使用组织的过程资产库实施项目已定义的过程。
该项任务通常包含以下活动：
• 将组织过程资产库中的成果适当地纳入到项目中
• 使用组织的过程资产库中的经验教训来管理项目
2. 使用项目已定义的过程、项目计划及影响项目的其它计划来监督与控制项目的活动与工作产品。
该项任务通常包含以下活动：
• 使用已定义的入口与出口准则来授权任务的启动并确定任务的完成
• 监督可能明显影响项目计划参数实际值的活动
• 使用将会触发调查与适当行动的可度量的阈值来跟踪项目参数
• 监督产品与项目接口风险
• 基于项目已定义过程的任务与产品的计划，管理外部与内部承诺
对于项目已定义过程的任务与工作产品间关系的理解以及对于相关干系人所执行角色的理解，与完整定义的控制策略（如同级评审）一起，可以更清晰地了解项目的绩效，并更好地控制项目。
3. 获得与分析所选定的度量，以管理项目并支持组织需要。
参阅“度量与分析”过程域以进一步了解如何获得度量数据并分析度量数据。
4. 定期评审项目绩效，并适当地使之与组织、客户以及最终用户当前的和期望的需要、目标及需求保持一致。
该评审包括与组织的过程需要及目标的协调一致。
达成协调一致的行动实例有：
• 对其它计划参数与项目风险进行适当调整，变更进度
• 变更需求或承诺，以响应市场机会或客户、最终用户需要的变化
• 终止项目、迭代或发布
5. 处理选定的、可能影响项目目标的问题的原因。
需要采取纠正措施的问题的确定与分析，是在“项目监督与控制”过程域的“分析问题”与“采取纠正措施”特定实践中进行的。适当时，项目可定期地评审以前其它项目或本项目早期阶段所遇到的问题，并对选定问题进行原因分析，以确定如何防范可能明显影响项目目标的问题的重复发生。对于作为原因分析活动的结果所实施的项目过程变更，应进行效果评价，以确保该过程变更已经防范了重复发生并提高了绩效
SP 1.6 建立团队
建立并维护团队。
项目采用团队的方式进行管理，这些团队反映了组织关于团队结构、组建与运作的规则与指南。（见术语表中“团队”的定义。 ）
在建立团队结构之前建立项目的共同愿景，团队结构可以基于 WBS 建立。对于小的组织，整个组织及其相关外部干系人可以被视为一个团队。参阅“组织级过程定义”过程域中的“建立团队的规则与指南”特定实践以进一步了解如何建立并维护团队的结构、组建与运作的组织级规则与指南。将相关干系人纳入团队，是确保与他们的协调与协作的最佳方式之一。在需要多个产品或服务开发组织相互协作的客户环境中，建立一个由影响总体成功的所有各方代表参加的团队是很重要的。这些代表能帮助确保这些组织间的有效协作，包括及时地解决或协调问题。
工作产品实例
1. 文档化的共同愿景
2. 分配到各个团队的成员列表
3. 团队章程
4. 定期的团队状态报告
子实践
1. 建立并维护项目的共同愿景。
形成共同愿景时，理解项目与项目外部干系人之间的接口是非常关键的。
该愿景应在相关干系人中分享并获得他们的同意与承诺。
2. 建立并维护团队结构。
评估项目 WBS、成本、进度、项目风险、资源、接口、项目已定义的过程与组织级的指南，以建立一个适当的团队结构，包括团队职责、权限及相互关系。
3. 建立并维护每个团队。
建立并维护团队包括为每个团队选择团队领导、团队成员并建立团队章程。也包括提供所需的资源以完成赋予该团队的任务。
4. 定期评估团队结构与组成。
应对各团队进行监督，以发现不同团队间工作的不一致性、管理不善的接口以及给团队成员的任务不匹配等。当团队或项目绩效未能满足期望时采取纠正措施。
SP 1.7 为组织级过程资产做出贡献
将过程相关经验贡献给组织级过程资产。
参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产、建立组织的度量库以及建立组织的过程资产库。参阅“组织级过程关注”过程域以进一步了解如何将经验纳入组织级过程资产。本特定实践阐明的是如何将来自项目已定义过程中部分过程的信息贡献给组织级过程资产
工作产品实例
1. 针对组织级过程资产的改进建议
2. 从项目中收集的实际过程与产品度量项
3. 文档（如可做为范例的过程描述、计划、培训模块、检查单、经验教训）
4. 项目裁剪与实施组织标准过程集的相关过程成果
子实践
1. 向组织级过程资产提交改进建议。
2. 将过程与产品度量项存入组织的度量库中。
参阅“项目监督与控制”过程域以进一步了解如何监督项目计划参数。
参阅“项目计划”过程域以进一步了解如何计划数据管理。
这些过程与产品度量项通常包括：
• 计划数据
• 重新计划数据
由项目记录的数据实例有：
• 任务描述
• 假设
• 估算
• 修订的估算
• 对所记录的数据与度量项的定义
• 度量项
• 将度量项与所执行的活动、所产生的工作产品关联起来的背景情况信息
• 重建已有估算、评价其合理性以及对新工作进行估算所需的相关信息
3. 提交可能会被纳入到组织的过程资产库的文档。
文档实例有：
• 可做为范例的过程描述
• 培训模块
• 可做为范例的计划
• 检查单与模板
• 项目信息库的框架
• 工具配置
4. 将项目经验教训文档化，以纳入到组织的过程资产库中
5. 提供与裁剪、实施组织的标准过程集相关的过程成果，以支持组织的过程监督活动
SG 2 与相关干系人协调并协作
项目与项目相关干系人之间的协调与协作得到开展。
SP 2.1 管理干系人的参与
管理相关干系人在项目中的参与。
依据项目的集成计划与已定义过程来管理干系人的参与。
参阅“项目计划”过程域以进一步了解如何计划干系人的参与并获得对计
划的承诺。
工作产品实例
1. 协作活动的议程与进度
2. 相关干系人问题的解决建议
3. 记录的问题（如与干系人需求、产品与产品组件需求、产品架构、产
品设计相关的问题）
子实践
1. 与应该参加项目活动的相关干系人展开协作。
相关干系人应已在项目计划中得到确定。
2. 确保为满足承诺而产出的工作产品符合接收者的需求。
产出的满足承诺的工作产品可以是服务。
该任务通常包括：
• 对每个由相关干系人产出的工作产品进行适当的评审、演示或测试
• 对每个由项目为其它项目生产的，并由该项目代表接收的工作产品，
进行适当的评审、演示或测试
• 解决与工作产品验收相关的问题
3. 提出建议与协调措施，以解决对需求的误解与问题。
SP 2.2 管理依赖
与相关干系人共同识别、协商并跟踪关键依赖。
工作产品实例
1. 与相关干系人一起评审时产生的缺陷、问题与行动项
2. 关键依赖
3. 对于处理关键依赖的承诺
4. 关键依赖的状态
子实践
1. 与相关干系人一起进行评审
2. 识别所有关键依赖。
3. 基于项目进度建立每个关键依赖的需要日期和计划日期。
4. 与负责提供或接收工作产品的一方，就针对每个关键依赖的承诺进行评审并达成一致。
5. 将关键依赖与承诺文档化。
承诺记录通常包括：
• 对承诺的描述
• 识别承诺方
• 识别履行承诺方
• 明确何时履行承诺
• 明确承诺是否被履行的判定标准
6. 跟踪关键依赖与承诺，并采取适当的纠正措施。
参阅“项目监督与控制”过程域以进一步了解如何监督承诺。
跟踪关键依赖通常包括：
• 评价延迟或提前完成对于未来活动与里程碑的影响
• 尽可能地与责任方共同解决实际与潜在的问题
• 将负责的个人或团体无法解决的实际与潜在的问题进行适当的升级处理
SP 2.3 解决协调问题
与相关干系人共同解决问题。
协调问题的实例有：
• 产品与产品组件的需求与设计缺陷
• 延迟的关键依赖与承诺
• 产品级的问题
• 无法获得关键的资源或人员
工作产品实例
1. 相关干系人的协调问题
2. 相关干系人的协调问题的状态
子实践
1. 识别并记录问题。
2. 向相关干系人沟通问题。
3. 与相关干系人一同解决问题。
4. 将与相关干系人无法解决的问题上报到适当的管理人员。
5. 跟踪问题直至关闭。
6. 就问题的状态与解决，与相关干系人展开沟通
文章下方有交流学习区！一起学习进步！也可以前往官网，加入官方微信交流群！！！你的支持和鼓励是我创作的动力❗❗❗
Doker的成长，欢迎大家一起陪伴！！！
官网：Doker 多克; 官方旗舰店：首页-Doker 多克 多克创新科技企业店-淘宝网全品优惠
