CMMI-项目监督与控制(PMC)

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
简介: CMMI-项目监督与控制(PMC)

项目监督与控制(Project Monitoring and Control, PMC)的目的在于提供对项目进展的了解,以便在项目绩效显著偏离计划时可采取适当的纠正措施。

一、概述

文档化的项目计划是监督活动、沟通状态以及采取纠正措施的基础。主要通过在项目进度表或 WBS 中预定的里程碑处或者控制级别上,将实际的工作产品与任务属性、工作量、成本以及进度与计划进行对比来确定进展情况。对进展的适当可视性使得绩效与计划发生显著偏差时能够及时采取纠正措施。显著偏差是指如果不解决就会妨碍项目达成其目标的偏差。在本过程域中,用术语“项目计划”表示用于控制项目的总体计划。当实际状态与预期情况显著偏离时,就要酌情采取纠正措施。这些措施可能需要重新计划,包括修订原来的计划,建立新的协议,或者在当前计划中增加额外的缓解活动

二、特定目标与特定实践摘要

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 监督项目计划参数

对照项目计划,监督项目计划参数的实际值。

项目计划参数构成了通常的项目进展与绩效指标,并且包括了工作产品与任务的属性、成本、工作量和进度。工作产品与任务的属性包括规模、复杂度、服务水平、可用性、重量、形状、匹配以及功能。应该考虑监督参数的频率。监督通常涉及度量项目计划参数的实际值,将实际值与计划中的估算值相比较,并且识别重大偏差。对项目计划参数实际值的记录包括对相关情境信息的记录,以帮助理解度量结果。在本过程域的特定目标 2 及其特定实践中将描述如何分析重大偏差的影响,以确定需要采取何种纠正措施。

工作产品实例

1. 项目绩效记录

2. 重大偏差记录

3. 成本绩效报告

子实践

1. 对照进度监督进展。

进展监督通常包括:

• 定期度量各活动和里程碑的实际完成情况

• 将活动和里程碑的实际完成情况与项目计划中的进度相比较

• 识别与项目计划中的进度估算值的重大偏差

2. 监督项目成本与投入的工作量

工作量与成本监督通常包括:

• 定期度量花费的实际工作量与成本,以及指派的人员

• 将实际的工作量、成本、人员以及培训与项目计划中的预算和估算值相比较

• 识别与项目计划中的预算和估算的显著偏差

3. 监督工作产品与任务的属性。

参阅“度量与分析”过程域以进一步了解如何开发并保持用于支持管理信息需要的度量能力。

参阅“项目计划”过程域以进一步了解如何建立并维护工作产品与任务属性的估算。

监督工作产品与任务的属性通常包括:

• 定期度量工作产品与任务的规模、复杂度或服务水平等实际属性(以及这些属性的变化)

• 将实际的工作产品与任务属性(以及这些属性的变化)与项目计划中的估算值相比较

• 识别与项目计划中的估算值的重大偏差

4. 监督资源的提供与使用。

参阅“项目计划”过程域以进一步了解如何计划项目资源。

资源的实例有:

• 物理设施

• 计算机、外围设备以及软件

• 网络

• 保密环境

• 项目人员

• 过程

5. 监督项目人员的知识与技能。

参阅“项目计划”过程域以进一步了解如何计划所需的知识与技能。

监督项目人员的知识与技能通常包括:

• 定期度量项目人员获得的知识与技能

• 比较实际接受的培训与项目计划中的培训

• 识别与项目计划中的估算值的重大偏差

6. 将项目计划参数的重大偏差文档化

SP 1.2 监督承诺

对照项目计划,监督所识别的承诺。

工作产品实例

1. 对承诺进行评审的记录

子实践

1. 定期地评审承诺(外部的和内部的)。

2. 识别尚未满足的承诺,或者存在无法满足的重大风险的承诺。

3. 记录对承诺进行评审的结果。

SP 1.3 监督项目风险

对照项目计划,监督所识别的风险。

参阅“项目计划”过程域以进一步了解如何识别项目风险。

参阅“风险管理”过程域以进一步了解如何在项目潜在的问题发生前对其进行识别,以便在整个产品或项目生命期中,计划并在必要时启动风险的处理行动,从而降低这些潜在问题对达成目标产生的不利影响。工作产品实例

1. 项目风险监督的记录

子实践

1. 结合项目当前的状态与环境,定期评审风险文档。

2. 在得到新增信息时,修订风险文档。

随着项目的进展(特别是长期或持续运行的项目),会出现新的风险。识别并分析新的风险很重要。例如,软件、设备以及使用的工具可能变得过时;或在对项目与组织极具长期重要性的领域,关键人员的技能逐步退化。

3. 向相关干系人通报风险的状态。

风险状态的实例有:

• 风险发生概率的变化

• 风险优先级的变化

SP 1.4 监督数据管理

对照项目计划,监督项目数据的管理。

参阅“项目计划”过程域中的“计划数据管理”特定实践以进一步了解如何识别应管理数据的类型以及如何计划这些管理活动。为确保数据管理要求得到满足,应监督数据管理活动。根据监督结果以及项目需求、情况或状态的变更,可能需要重新计划项目的数据管理活动。

工作产品实例

1. 数据管理的记录

子实践

1. 对照项目计划中的有关描述,定期评审数据管理活动。

2. 识别重大问题及其影响,将其文档化。

重大问题的一个实例是干系人无法访问其作为相关干系人履行角色时所需的项目数据。

3. 将数据管理活动的评审结果文档化。

SP 1.5 监督干系人的参与

对照项目计划,监督干系人的参与。

参阅“项目计划”过程域中的“计划干系人的参与”特定实践以进一步了解如何识别相关干系人并计划他们适当的参与。

为确保适当的交互,应监督干系人的参与。根据监督结果以及项目需求、情况或状态的变更,可能需要重新计划干系人的参与活动。在敏捷环境下,客户与潜在的最终用户持续参与项目的产品开发活动对项目成功至关重要;因此客户与最终用户在项目中的参与活动也应该受到监督。(见第一部分中的“使用敏捷方法时对 CMMI 的解读”。)

工作产品实例

1. 干系人参与的记录

子实践

1. 定期评审干系人参与的状态。

2. 识别重大问题及其影响,并将它们文档化。

3. 将干系人参与状态的评审结果文档化。

SP 1.6 进行进展评审

定期评审项目的进展、绩效与问题。

“项目的进展”是在某个特定时间点的项目状态,与相关干系人(特别是项目代表及项目管理层)评审到此时间点为止项目活动的执行情况、结果与影响,以决定是否存在重大问题或需要处理的绩效不足。进展评审是为了保持相关干系人对项目情况的了解而进行的评审。这些项目评审可以是非正式的,也可能并未在项目计划中明确规定。

工作产品实例

1. 文档化的项目评审结果

子实践

1. 定期与相关干系人沟通已分派的活动与工作产品的状态。

酌情组织管理人员、员工、客户、最终用户、供方以及其他相关干系人参与评审。

2. 评审用于控制项目的度量项的收集与分析结果。

被评审的度量可以包括客户满意度度量项。

参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致并提供度量结果

3. 识别重大问题和与计划的偏差,并将其文档化。

4. 将工作产品与过程中识别出来的变更请求及问题文档化。

5. 将评审结果文档化。

6. 跟踪变更请求与问题报告直至关闭。

SP 1.7 进行里程碑评审

在选定的项目里程碑处,评审项目的已完成情况与结果。

参阅“项目计划”过程域中的“建立预算与进度”特定实践以进一步了解如何识别主要的里程碑。里程碑是预先计划的事件或指定时间点,用来执行对项目状态的全面评审,以便了解干系人需求的符合程度。(如果项目包含一个演进性的里程碑,那么应执行评审以确保与该里程碑相关的假设及需求都已得到满足。)里程碑可以与整体项目或一个特定的服务类型或服务实例相关。因此里程碑可以基于事件或日期。在项目计划期间就要计划里程碑评审,并且通常是正式的评审。进展评审与里程碑评审并不需要分别进行。一次评审可处理两种评审的内容。例如,一次预先计划的评审可以对照计划中的期望值,评价某个计划中的时间段(或里程碑)内的进展、问题与绩效。根据项目的不同,“项目启动”与“项目结束”可能是里程碑评审包括的阶段。

工作产品实例

1. 文档化的里程碑评审结果

子实践

1. 在项目进度中有重要意义的时刻,例如选定的阶段完成时,与相关干

系人一起进行里程碑评审。

酌情组织管理人员、员工、客户、最终用户、供方以及其他相关干系人

参与里程碑评审。

2. 评审项目的承诺、计划、状态以及风险。

3. 识别重大问题及其影响并将它们文档化。

4. 将评审的结果、行动项以及决策文档化。

5. 跟踪行动项直至关闭。

SG 2 管理纠正措施直至关闭

当项目绩效或结果显著偏离计划时,纠正措施得到管理,直至关闭。

SP 2.1 分析问题

收集并分析问题,确定处理问题所需的纠正措施。

工作产品实例

1. 需要采取纠正措施的问题的清单

子实践

1. 收集问题以供分析

从评审和其它过程的执行中收集问题。

需要收集的问题的实例有:

• 执行技术评审、验证与确认活动时发现的问题

• 项目计划参数与项目计划中的估算值的显著偏差

• 尚未满足的承诺(内部的和外部的)

• 风险状态的重大变化

• 数据访问、收集、私有性或保密性等问题

• 干系人代表或参与方面的问题

• 产品、工具或环境交接的假设(或其他客户或供方承诺)未能达成

2. 分析问题以决定是否需要纠正措施。

参阅“项目计划”过程域中的“建立预算与进度”特定实践以进一步了解纠正措施准则。如果问题不解决会妨碍项目达成其目标的话,就需要采取纠正措施。

SP 2.2 采取纠正措施

对已识别的问题采取纠正措施。

工作产品实例

1. 纠正措施计划

子实践

1. 确定所需的适当措施并将其文档化,以处理已识别的问题。

可能的措施的实例有:

• 修改工作说明书

• 修改需求

• 修订估算与计划

• 重新协商承诺

• 增加资源

• 修改过程

• 修订项目风险

2. 与相关干系人一同评审将要采取的措施并达成一致。

3. 协商内部与外部承诺的变更

SP 2.3 管理纠正措施

管理纠正措施直至关闭。

工作产品实例

1. 纠正措施的结果

子实践

1. 监督纠正措施是否完成。

2. 分析纠正措施的结果以确定纠正措施的有效性。

3. 当纠正措施的实际结果与计划结果出现偏差时,确定适当的后继纠正措施并将其文档化。

作为采取纠正措施的结果,相关的经验教训可被用作计划与风险管理过程的输入


文章下方有交流学习区!一起学习进步!也可以前往官网,加入官方微信交流群

创作不易,如果觉得文章不错,可以点赞 收藏 评论

你的支持和鼓励是我创作的动力❗❗❗

官网:Doker 多克; 官方旗舰店首页-Doker 多克 多克创新科技企业店-淘宝网 全品优惠



目录
相关文章
|
11月前
【软考】能力成熟度模型CMM
【软考】能力成熟度模型CMM
49 0
|
11月前
|
项目管理 内存技术
CMMI-结项管理
CMMI-结项管理
79 0
|
12月前
|
程序员 开发者
CMMI-技术评审管理方案
CMMI-技术评审管理方案
164 0
|
自然语言处理 测试技术 程序员
当大模型开始规划合作,一个模型打造软件开发团队,代码生成性能狂升(2)
当大模型开始规划合作,一个模型打造软件开发团队,代码生成性能狂升
157 0
|
机器学习/深度学习 人工智能 算法
当大模型开始规划合作,一个模型打造软件开发团队,代码生成性能狂升
当大模型开始规划合作,一个模型打造软件开发团队,代码生成性能狂升
当大模型开始规划合作,一个模型打造软件开发团队,代码生成性能狂升
|
人工智能 自然语言处理 API
超越现有指标57.3%,邢波教授、胡志挺教授团队提出统一NLG评价框架
超越现有指标57.3%,邢波教授、胡志挺教授团队提出统一NLG评价框架
|
机器学习/深度学习 存储 监控
ML:机器学习工程化之团队十大角色背景、职责、产出物划分之详细攻略
ML:机器学习工程化之团队十大角色背景、职责、产出物划分之详细攻略
ML:机器学习工程化之团队十大角色背景、职责、产出物划分之详细攻略
|
人工智能 自然语言处理 API
超越现有指标57.3%,邢波教授、胡志挺教授团队提出统一NLG评价框架
超越现有指标57.3%,邢波教授、胡志挺教授团队提出统一NLG评价框架
149 0
超越现有指标57.3%,邢波教授、胡志挺教授团队提出统一NLG评价框架
【软件工程】CMMI 能力成熟度模型集成 ( CMMI 工程过程域 | CMMI 支持过程域 ) ★
【软件工程】CMMI 能力成熟度模型集成 ( CMMI 工程过程域 | CMMI 支持过程域 ) ★
127 0
|
项目管理
【软件工程】CMMI 能力成熟度模型集成 ( CMMI 过程管理过程域 | CMMI 项目管理过程域 ) ★
【软件工程】CMMI 能力成熟度模型集成 ( CMMI 过程管理过程域 | CMMI 项目管理过程域 ) ★
197 0

热门文章

最新文章