集成的项目管理：CMMI模型过程域系列学习中文版
来源：http://blog.csai.cn/user2/51384/archives/2009/40616.htmlINTEGRATED PROJECT MANAGEMENT +IPPD 集成的项目管理
A Project Management Process Area at Maturity Level 3 项目管理过程域的成熟度第三级
Purpose 目的
集成的项目管理（简称IPM）的目的在于，依据从组织标准过程集裁剪而来的集成的已定义过程，建立并管理项目，以及相关干系人的参与。
Introductory Notes 简介
集成的项目管理包含以下内容：
* 在项目启动初期，通过裁剪组织的标准过程集建立项目已定义过程
* 使用项目已定义过程来管理项目
* 依据组织的工作环境标准，建立项目的工作环境
* 使用组织过程资产，并积累组织过程资产
* 在产品开发的过程中，使相关干系人的意见均被识别、考虑，并进行适当处理
* 确保相关干系人能够及时协调工作量和按时完成任务：（1）处理产品与产品组件需求、计划、目标、问题及风险；（2）履行他们的承诺；（3）识别、追踪和解决问题
从组织标准过程集裁剪而来的集成的已定义过程，称为项目已定义过程。
项目工作量、成本、进度安排、人员、风险及其他因素的管理，与项目已定义过程的任务紧密相关。对项目已定义过程的实施与管理，在项目计划中已进行了典型描述，而某些活动可能包含于影响项目的其他计划中，诸如品质保证计划、风险管理策略、配置管理计划。
本过程域也处理了与项目相关的所有活动的协调，包括以下内容：
* 开发活动，例如：需求开发、设计、验证
* 服务活动，例如：交付、服务台、运营、客户关系
* 采购活动，例如：招标、合同监控、迁移至运营
* 支持活动，例如：配置管理、文档化、市场营销、培训
本过程域适用于任何组织结构，诸如包括垂直领导组织、矩阵组织或集成团队。该术语应该在适当的组织结构中，加以适当的解释。
特定目标和特定实践
SG 1 Use the Project’s Defined Process 使用项目的已定义过程根据从组织标准过程集裁剪而来的已定义过程，指导项目。
项目已定义过程必须包含组织标准过程，该标准过程强调了购买或开发，以及维护产品所需的全部过程。与这些产品相关的生命周期过程，例如制造与支持流程，与产品同步开发。
SP 1.1 Establish the Project’s Defined Process 建立项目已定义过程
从项目启动到整个项目生命周期中，建立并维护项目的已定义过程。
项目的已定义过程，由经过裁剪的已定义过程所组成，这些构成了项目一个集成的、连贯的生命周期。
项目已定义过程，应该满足项目合约与商业上的需求、机会和约束，其设计目的在于提供最适合项目的需求的过程。项目已定义过程的基础是：
* 客户需求
* 产品及产品组件需求
* 承诺
* 组织过程需求与目标
* 组织标准过程集及裁剪指南
* 操作环境
* 商业环境
在项目启动时建立项目已定义过程，有助于确保项目人员与干系人执行一套有效建立项目初步需求与计划所需的活动。
典型的工作产品
1.项目的已定义过程
子实践
1.从组织过程资产中，选择一个适用的生命周期模型。
能够影响生命周期模型的选择的项目特征，举例如下：
* 项目规模
* 过程执行人员的经验和精通程度
* 某些限制，例如周期时间，以及可接受的缺陷级别等
2.从组织标准过程集中，选择最适合项目需要的标准过程。
3.依据裁剪指南，裁剪组织标准过程集和其他的组织过程资产，产生项目的已定义过程。
4.适当时运用组织过程资产库中的其他成果。
其他成果可能包括：
* 经验教训的文档
* 模版
* 样例文档
* 估算模型
5.将项目的已定义过程文档化。
项目的已定义过程，涵盖所有的项目活动，以及与相关干系人的接口。
项目活动举例如下：
* 项目策划
* 项目监督
* 需求开发
* 需求管理
* 供应商管理
* 配置管理
* 质量保证
* 风险管理
* 决策分析与解决
* 产品开发与支持
* 请求
6.对项目的已定义过程进行同行评审。
7.必要时修订项目的已定义过程。
SP 1.2 Use Organizational Process Assets for Planning Project Activities 运用组织过程资产策划项目活动
根据组织过程资产库和度量库，估算与策划项目活动。
典型的工作产品
1.项目估计
2.项目计划
子实践
1.以项目已定义过程的工作任务与工作产品为基础，对项目活动进行估计与策划。
了解项目已定义过程中各项任务和工作产品的关联关系，以及相关干系人执行时的角色，是制定切实可行的计划的基础。
2.利用组织度量库，估算项目策划的参数。
估算通常包括：
* 根据本项目或类似项目适当的历史数据
* 针对当前项目，以及历史数据被采用的项目，了解并记录二者的异同
* 单独确认历史数据
* 记录选择历史数据时使用的假设和推理
考虑异同点时，涉及的参数举例如下：
* 工作产品和任务属性
* 应用领域
* 设计方法
* 操作环境
* 人员的经验
组织度量库中包含的数据，举例如下：
* 工作产品或其他工作产品属性的规模
* 工作量
* 成本
* 进度
* 人员
* 缺陷
* 响应时间
* 服务能力
* 供应性能
SP 1.3 Establish the Project's Work Environment 建立项目工作环境
根据组织的工作环境标准，建立并维护项目的工作环境。
一个项目的适当的工作环境包括设施、工具、设备的基础建设，人员用以有效地贯彻执行工作，以支持企业与项目的目标。工作环境及其组件维持在一个水平，即组织工作环境标准中所指定的性能与可靠性水平。视需要，项目的工作环境或其某些组件可以是内部开发或购置的，或来源于外部。
典型的工作产品
1.项目的设备及工具
2.项目工作环境的安装、操作与维护手册
3.用户调查与结果
4.使用、性能与维护记录
5.项目工作环境的支持服务
子实践
1.计划、设计与安装项目的工作环境。
同其他产品一样，项目工作环境的关键方面也是需求驱动。工作环境的功能和运行，同其他产品开发一样，同样有着精确的要求。
关于权衡性能、成本、风险，举例如下：
* 考虑性能，可能包含互相操作的及时沟通、安全性、保险性、可维护性
* 考虑成本，可能包含资本支出、培训、支持结构、现有环境的解除，以及环境的运行和维护
设备和工具，举例如下：
* 办公软件
* 决策支持软件
* 项目管理工具
* 需求管理工具、设计工具
* 配置管理工具
* 评估工具
* 测试和/或评估设备
2.为项目工作环境提供持续的维护与操作支持。
对工作环境的维护和支持，可以通过组织内部的能力来完成，也可以通过雇佣组织以外的力量来完成。
维护和支持的方法，举例如下：
* 雇佣人员进行维护和支持
* 培训人员进行维护和支持
* 签订维护和支持合同
* 针对选定的工具开发高级用户
3.维护构成项目工作环境的组件的资格条件。
4.定期评审工作环境符合项目需要的程度，以及能否联携，适当时采取措施。
可能采取的措施，举例如下：
* 增加新的工具
* 追加购买网络、设备、培训和支持
SP 1.4 Integrate Plans 集成计划
项目计划和其他从属计划整合起来，描述项目的已定义过程。
本特定实践延伸了建立与维护项目计划的特定实践，以强调额外的计划活动，例如，合并项目的已定义过程，与相关干系人进行协调，使用组织过程资产、合并同行评审的计划，以及建立工作任务客观的入口与出口准则。
项目计划的开发，应考虑当前及项目需求与目标，并适当地考虑组织、客户、供应商、用户的需求。
典型的工作产品
1.集成的计划
子实践
1.将影响项目的其他从属计划与项目计划整合起来。
其他从属计划可能包括：
* 质量保证计划
* 配置管理计划
* 风险管理策略
* 文档计划
2.将用于管理项目的度量定义和度量活动，纳入项目计划。
纳入项目计划的度量，举例如下：
* 组织的公共度量资产
* 项目特定追加的度量
3.识别并分析产品和项目接口的风险。
产品和项目接口的风险，举例如下：
* 接口说明不完整
* 工具或测试设备不可用
* COTS组件的可用性
* 团队接口不充分或无效
4.安排工作顺序时，考虑关键开发因素及项目风险。
日程安排时考虑的因素，举例如下：
* 任务的规模和复杂性
* 集成问题和测试问题
* 客户和最终用户的需要
* 关键资源的可用性
* 关键人员的可用性
5.针对项目已定义过程的工作产品实施同行评审，要纳入计划。
6.项目已定义过程所需的培训，要纳入项目培训计划。
这通常要与组织的培训团队协商，看他们能够提供哪些支持。
7.建立客观的入口准则和出口准则，针对工作分解结构（WBS）描述的工作任务，批准是否启动和完成。
8.确保项目计划与相关干系人的计划相符。
通常要评审计划和计划的变更，看是否兼容。
9.识别如何解决相关干系人之间的冲突。
SP 1.5 Manage the Project Using the Integrated Plans 运用集成计划管理项目
根据项目计划和其他从属计划，以及项目的已定义过程管理项目。
典型的工作产品
1.执行项目已定义过程所产生的工作产品
2.已收集的度量值（实际的）与进度记录或报告
3.已修订的需求、计划及承诺
4.集成的计划
子实践
1.运用组织过程资产库，执行项目的已定义过程。
这项工作通常包括：
* 将组织过程资产库的成果，适当地纳入项目中
* 运用组织过程资产库中获取的经验教训，管理项目
2.根据项目的已定义过程、项目计划和其他从属计划，监控项目活动和工作产品。
这项工作通常包括：
* 根据定义的入口准则和出口准则，批准任务的启动和完成
* 针对严重影响项目策划参数实际值的活动，进行监控
* 根据度量的阈值，追踪项目的计划参数，阈值是指能够触发调查活动和其他适当活动的临界值
* 监控产品和项目接口的风险
* 根据项目已定义过程所包含的任务和工作产品的计划，管理对内和对外的承诺
了解项目已定义过程中各项任务和工作产品的关联关系，了解相关干系人的职责，了解定义的控制机制（如同行评审），如何更好地实现项目的性能以及更好地控制项目。
3.获取并分析选定的度量值，来管理项目并满足组织的需求。
4.定期评审项目的性能，,并根据当前和期望的需要，目标，以及组织、客户、最终用户的需求，对项目性能进行适当的调整。
评审包含调整并符合组织过程的需要和目标。
关于调整措施，举例如下：
* 加快进度，对其他计划参数和项目风险进行适当的调整
* 为应对市场机遇，以及客户和最终用户需要的变更，对需求进行变更
* 结项
SP 1.6 Contribute to the Organizational Process Assets 充实组织过程资产
将工作产品、度量值及经验文档充实到组织过程资产中。
典型的工作产品
1.针对组织过程资产所提出的改进措施
2.从项目中收集的实际过程与产品度量值
3.文档（例如，示范的过程描述、计划、培训模块、检查表、经验教训）
4.裁剪与执行项目的组织标准过程相关的过程成果物
子实践
1.对组织过程资产提出改进。
2.将过程和产品的度量值存储到组织度量库中。
这项工作通常包括：
* 策划的数据
* 再策划的数据
* 度量
项目记录的数据，举例如下：
* 任务说明
* 假设
* 估算
* 修订的估算
* 已记录数据和度量的定义
* 度量
* 与实施的活动或生产的工作产品相关的度量的背景信息
* 重新建立估算，评估是否合理，以及针对新工作导出估算时所需的相关信息
3.提交可能纳入组织过程资产库的文档。
文档举例如下：
* 模范过程说明
* 培训模块
* 模范计划
* 检查单
4.将项目的经验教训文档化，并纳入组织过程资产库。
5.提供与裁剪和执行组织标准过程集相关的过程成果物，支持组织的过程监控活动。
SG 2 Coordinate and Collaborate with Relevant Stakeholders 与相关干系人协调及合作
与相关干系人，进行项目的协调与合作。
SP 2.1 Manage Stakeholder Involvement 管理干系人的参与
管理相关干系人参与项目的程度。
根据项目集成的和已定义的过程，对干系人的参与进行管理。
典型的工作产品
1.协调活动的日程及时间安排
2.记录的问题（例如，客户需求、产品及产品组件需求、产品架构、产品设计等问题）
3.解决相关干系人问题的建议
子实践
1.与应该参与项目活动的相关干系人协调。
早在项目计划中就已识别出相关干系人。
2.确保生产的工作产品满足承诺，并符合验收项目的需求。
这项工作通常包括：
* 针对相关干系人生产的各项产品，适当地评审、验证或测试
* 针对某项目为其他项目（验收产品的项目代表）所生产的各项产品，适当地进行评审、验证或测试
* 解决与验收工作产品相关的问题
3.提出建议并采取协调行动，解决产品与产品组件在需求、架构、设计上存在的误解与问题。
SP 2.2 Manage Dependencies 管理依赖关系
与相关干系人一起，识别、协商并追踪关键的依赖关系。
典型的工作产品
1.与相关干系人评审后，所产生的缺陷、问题及活动项
2.关键依赖关系
3.处理关键依赖关系的承诺
4.关键依赖关系的状态
子实践
1.与相关干系人一起评审。
2.识别每个关键的依赖关系。
3.根据项目的日程安排，针对每个关键依赖关系，制定需求日期和计划日期。
4.与负责提供和接收工作产品的人员一起，针对每个关键依赖关系，评审承诺是否履行并达成一致
5.将关键依赖关系及承诺文档化。
有关承诺的文档，通常包括：
* 描述承诺
* 确定承诺者
* 确定达成承诺的负责人
* 指定达成承诺的时间
* 指定确认承诺达成的标准
6.追踪关键依赖关系及承诺，适当时采取纠正措施。
追踪关键的依赖关系，通常包括：
* 将来的活动和里程碑，如果延迟或超前完成，评估会有哪些影响
* 只要有可能，和负责人一起解决实际存在或潜在的问题
* 将与负责人一起无法解决的实际问题或潜在问题，上升到适当的管理层
SP 2.3 Resolve Coordination Issues 解决协调问题
与相关干系人一起解决问题。
典型的工作产品
1.相关干系人的协调问题
2.相关干系人协调问题的状态
子实践
1.识别并将问题文档化。
2.与相关干系人沟通问题。
3.与相关干系人一起解决问题。
4.与相关干系人一起无法解决的问题，上升到适当的管理层。
5.追踪问题直到关闭。
6.针对问题的状态及解决情况，与相关干系人进行交流。
SG 3 Apply IPPD Principles 应用IPPD原则
根据IPPD原则管理项目。
本特定目标及其实践的目的在于建立IPPD环境，使集成的团队能够有效地满足项目需求，并生产出高质量的产品。
SP 3.1 Establish the Project’s Shared Vision 建立项目的共同愿景
建立并维护项目的共同愿景。
项目并非单独运作，了解组织的使命、目标、期望及约束，能够使项目与组织的方向、活动、共同愿景密切结合，并有助于建立协调项目活动这样一个共同的目的。为此，了解项目与外部干系人之间的接口，以及所有内外部相关干系人的目标与期望，是至关重要的。
建立共同愿景时须考虑：
* 外部干系人的期望与需求
* 项目领导、团队领导及团队成员的抱负与期望
* 项目目标
* 项目将创造的条件与成果
* 项目需要维护的接口
* 由外界团体建立的愿景
* 外在权威人士强加的约束（如环保法规）
* 致力于达成目标的项目运作（原则与行为两方面）
建立一项共同愿景时，项目中全体人员均应受邀参加。尽管可能已经存在一份提案草稿，但应该让更多人有机会，来表达与倾听他们真正关心的事情。共同愿景应该清楚地表达整个团队的中心思想体系（价值、原则、行为），以及每个项目成员所渴望的未来。
有效的沟通策略，是整个项目贯彻与关注共同愿景的关键。共同愿景的公布，是项目承诺共同愿景的公开宣告，并提供机会给他人进行检查、了解，以及向共同的方向调整他们的活动。共同愿景应该与相关干系人进行沟通，并取得他们的同意与承诺。
当有新的项目成员加入时，有效的沟通也显得尤其重要。项目新成员通常需要更多、更特别的关注，才能确保他们了解共同愿景，愿意支持，并准备遵循愿景进行工作。
典型的工作产品
1.文档化的共同愿景
2.沟通策略
3.颁布的原则、共同愿景说明、使命、目标（例如，海报、随身卡、简报）
子实践
1.根据目的或使命、愿景、价值及目标，清楚地表达项目的共同愿景。
2.针对项目的共同愿景达成共识。
3.建立对内和对外沟通项目共同愿景的策略。
4.针对需要被通知项目共同愿景的不同对象，制作合适的演示说明。
5.确保项目及个体的活动和任务，符合项目的共同愿景。
SP 3.2 Establish the Integrated Team Structure 建立集成团队的架构
建立并维护项目集成团队的架构。
产品需求、成本、进度、风险、资源规划、经营过程、项目已定义过程，以及组织指南，都属于用以评估建立定义集成团队及其职责、授权与相互关系的基础。
典型的集成团队架构，是以WBS中产品导向的层级为基础。若WBS不以产品为导向、产品风险不一致，以及资源受限，将会产生更复杂的架构。
集成团队架构是一个动态的实体，随着人员、需求、工作性质的变更而调整，并能处理许多困难。对小项目而言，集成团队架构可以将整个项目视为一个集成团队。集成团队架构需要不断地监控，来发现故障、管理不善的接口、员工与工作不协调。当性能与期望不符时，应采取纠正措施。
典型的工作产品
1.产品及产品架构的评估，包括风险与复杂度
2.集成团队架构
子实践
1.建立集成团队的架构
集成团队的架构依赖于：
* 产品风险和复杂度的评估
* 风险的定位或类型
* 集成的风险，包括产品组件的接口和跨团队之间的沟通
* 资源，包括适当的技术人员的可用性
* 团队规模对有效合作的限制
* 项目以外的干系人成为团队成员资格的需要
* 商业过程
* 组织的架构
集成团队架构的建立，应该以了解项目的已定义过程和共同愿景，了解组织的标准过程，以及了解适用于团队和团队架构的组织过程资产为基础的。
2.定期评估并修订集成团队的架构，以最佳满足项目的需要。
产品需求或架构的变更，会影响到团队的架构。
不断地监控集成团队的架构以发现问题，例如接口管理不善，分配的工作与成员执行的工作不符。采取纠正措施，包括当性能无法满足期望时，对已部署的团队和架构进行评估。
团队架构的变更包括：
* 将某团队撤掉一段时间（例如，已经花费了长期的制造或验证时间）
* 解算某个团队，如果该团队为项目服务的性价比不高
* 组合团队以达到高效运作的目的
* 当确定开发新的产品组件时，增加团队
SP 3.3 Allocate Requirements to Integrated Teams 分配需求至集成团队
分配需求、职责、任务、接口至集成团队架构中的各个团队。
在任何团队形成之前，先完成集成团队的需求分配，以验证集成团队架构是可行的，且涵盖所有必须的需求、职责、授权、工作与接口。一旦架构确认，就选定集成团队发起人来建立架构中的个别团队。
典型的工作产品
1.为每个集成团队分配的职责
2.工作产品需求、技术接口与经营接口（例如，成本核算与项目管理），这些是每个集成团队有责任满足的
3.集成团队发起人的名单
子实践
1.为适合的集成团队，分配工作、职责、要交付的工作产品以及相关的需求和接口
每个集成团队的商业、管理和其他非技术方面的责任和权力，都是组成适当的团队功能必要的因素。集成团队的责任和权力，通常是从项目发展而来的，并与制定的组织实践保持一致。
责任和权力，举例如下：
* 团队选择领导的权力
* 团队发展子团队的权力（例如，某产品团队形成一个集成的子团队）
* 汇报链
* 汇报的要求（成本、进度和性能状态）
* 过程报告的度量和方法
2.检查需求与接口的分配，是否涵盖所有特定的产品需求和其他需求。
如果某事件中，需求完成的覆盖率没有达成，就应该采取纠正措施，重新分配需求或者改变集成团队的架构。
3.指定各集成团队的发起人。
集成团队的发起人即管理者（个体或团队），负责为集成团队建立并提供资源，监督活动和过程，需要时采取纠正措施。一个发起人可能管理一个或多个团队。团队的发起人可以是项目的管理者。
SP 3.4 Establish Integrated Teams 建立集成团队
建立并维护架构中包含的集成团队。
在集成团队架构下的各个集成团队是由团队发起人建立的。该过程包括选定团队领导人与团队成员，依据需求分配建立各集成团队的团队章程，同时也包括提供必要的资源，以完成分派给团队的工作。
典型的工作产品
1.团队领导的名单
2.分配至各个集成团队的成员名单
3.集成团队的章程
4.用来评估集成团队性能的度量指标
5.定期的集成团队状况报告
子实践
1.选择各集成团队的领导人。
组织和项目在选择领导方面，通常出于产品风险和复杂度的考虑，或者组织需要“培养”一位新领导。团队发起人可以在团队内部选择一位团队领导，或是团队成员在团队内部投票选择一位领导，这都取决于组织的政策。
2.为各集成团队分配资源。
为各集成团队分配人员和其他资源。与团队一起讨论这些事项，确保分配的资源充足，人员能够充分执行任务，并与团队的其他成员保持协调一致。
3.规范各集成团队。
团队章程是团队成员之间，以及团队和发起人之间，针对预期的工作和性能水平制定的合同。针对如何组织并执行团队分配到的需求和接口、职责和任务，章程中规定了权利、保证、权限和许可。集成团队及其发起人将制定章程看作是一项协商活动。当双方都审核通过时，团队章程就构成一项公认的具有管理权限的协议。
章程可以包括以下方面：
* 如何验收分配的任务
* 如何存取资源和输入
* 如何工作
* 谁来检查和评审工作
* 工作如何审批
* 如何交付与沟通工作
4.当团队领导或其他成员发生重大变化时，评审该团队的组成及其在集成团队架构中的地位。
这类变化可能严重影响团队达成目标的能力。应该评审新的团队结构是否与当前的职责相符。如果不相符，就应该变更团队的构成或者修订团队的
典型的工作产品
1.工作产品所有权协议
2.团队工作计划
3.承诺清单
子实践
1.建立并维护属于项目或组织的跨团队之间，工作产品所有权的界限。
2.建立并维护跨团队之间，输入、输出或工作产品的接口与过程。
3.开发、沟通与分配在跨团队间，与工作产品或团队接口相关的承诺清单与工作计划。
页:
[1]