学信息系统项目管理师第4版系列26_项目绩效域(下)

1. 项目工作绩效域

1.1. 涉及项目工作相关的活动和职能

1.2. 预期目标

1.2.1. 高效且有效的项目绩效

1.2.2. 适合项目和环境的项目过程

1.2.3. 干系人适当的沟通和参与

1.2.4. 对实物资源进行了有效管理

1.2.5. 对采购进行了有效管理

1.2.6. 有效处理了变更

1.2.7. 通过持续学习和过程改进提高了团队能力

1.3. 指标及检查方法

1.3.1. 状态报告:通过状态报告可以表明项目工作有效率且有效果

1.3.2. 过程的适宜性:证据表明,项目过程是为满足项目和环境的需要而裁剪的

1.3.3. 过程相关性和有效性:过程审计和质量保证活动表明,过程具有相关性且正得到有效使用

1.3.4. 沟通有效性:项目沟通管理计划和沟通文件表明,所计划的信息与干系人进行了沟通,如有新的信息沟通需求或误解,可能表明干系人的沟通和参与活动缺乏成效

1.3.5. 资源利用率:所用材料的数量、抛弃的废料和返工量表明,资源正得到高效利用

1.3.6. 采购过程适宜:采购审计表明,所采用的适当流程足以开展采购工作,而且承包商正在按计划开展工作

1.3.7. 变更处理情况:使用预测型方法的项目己建立变更日志,该日志表明,正在对变更做出全面评估,同时考虑了范围、进度、预算、资源、干系人和风险的影响;采用适应型方法的项目己建立待办事项列表,该列表显示完成范围的比率和增加新范围的比率

1.3.8. 团队绩效:团队状态报告表明,错误和返工减少,而效率提高

1.4. 绩效要点

1.4.1. 项目过程

1.4.1.1. 优化过程
1.4.1.1.1. 精益生产法
1.4.1.1.2. 召开回顾会议
1.4.1.1.3. 价值导向审查

1.4.2. 项目制约因素

1.4.3. 专注于工作过程和能力

1.4.4. 管理沟通和参与

1.4.5. 管理实物资源

1.4.6. 处理采购事宜

1.4.7. 监督新工作和变更

1.4.8. 学习和持续改进

1.5. 对其他绩效域具有促进作用

1.5.1. 项目工作可促进并支持有效率且有效果的规划、交付和度量

1.5.2. 项目工作可为项目团队互动和干系人参与提供有效的环境

1.5.3. 项目工作可为驾驭不确定性、模糊性和复杂性提供支持,平衡其他项目制约因素

2. 交付绩效域

2.1. 涉及与交付项目相关的活动和职能

2.2. 预期目标

2.2.1. 项目有助于实现业务目标和战略

2.2.2. 项目实现了预期成果

2.2.3. 在预定时间内实现了项目收益

2.2.4. 项目团队对需求有清晰的理解

2.2.5. 干系人接受项目可交付物和成果,并对其满意

2.2.5.1. 【高23上选56】

2.3. 指标及检查方法

2.3.1. 目标一致性:组织的战略计划、可行性研究报告以及项目授权文件表明,项目可交付物和业务目标保持一致

2.3.2. 项目完成度:项目基础数据表明,项目仍处于正轨,可实现预期成果

2.3.3. 项目收益:进度表明财务指标和所规划的交付正在按计划实现

2.3.4. 需求稳定性:在预测型项目中,初始需求的变更很少,表明对需求的真正理解度较高。在需求不断演变的适应型项目中,项目进展中阶段性需求确认反映了干系人对需求的理解

2.3.5. 干系人满意度:访谈、观察和最终用户反馈可表明干系人对可交付物的满意度

2.3.6. 质量问题:投诉或退货等质量相关问题的数量也可用于表示满意度

2.4. 绩效要点

2.4.1. 价值的交付

2.4.2. 可交付物

2.4.2.1. 需求启发
2.4.2.1.1. 记录需求的要求
2.4.2.1.1.1. 清晰
2.4.2.1.1.2. 简洁
2.4.2.1.1.3. 可核实
2.4.2.1.1.4. 一致性
2.4.2.1.1.5. 完整
2.4.2.1.1.6. 可跟踪
2.4.2.2. 不断演变和发现的需求
2.4.2.3. 管理需求
2.4.2.4. 定义范围和管理变更

2.4.3. 质量

2.4.3.1. 质量聚焦于需要达到的绩效水平
2.4.3.2. 发现缺陷的时间越晚,纠正缺陷的成本就越高
2.4.3.3. 前期工作完成得越多,变更的成本就越大

3. 度量绩效域

3.1. 涉及评估项目绩效和采取应对措施相关的活动和职能

3.2. 预期目标

3.2.1. 对项目状况充分理解

3.2.2. 数据充分,可支持决策

3.2.3. 及时采取行动,确保项目最佳绩效

3.2.4. 能够基于预测和评估作出决策,实现目标并产生价值

3.3. 指标及检查方法

3.3.1. 度量结果和报告:通过审计度量结果和报告,可表明数据是否可靠

3.3.2. 度量结果:度量结果可表明项目是否按预期进行,或者是否存在偏差

3.3.3. 度量结果:度量结果提供了提前指标以及当前状态,可导致及时的决策和行动

3.3.4. 工作绩效数据:回顾过去的预测和当前的工作绩效数据可发现,以前的预测是否准确地反映了目前的情况。将实际绩效与计划绩效进行比较,并评估业务文档,可表明项目实现预期价值的可能性

3.4. 绩效要点

3.4.1. 制定有效的度量指标

3.4.1.1. 关键绩效指标
3.4.1.1.1. 提前指标
3.4.1.1.2. 滞后指标
3.4.1.2. 有效度量指标
3.4.1.2.1. SMART特征
3.4.1.2.1.1. Specific (具体的)
3.4.1.2.1.2. Measurable (有意义的)
3.4.1.2.1.3. Attainable (可实现的)
3.4.1.2.1.4. Relevant (具有相关性)
3.4.1.2.1.5. Time-bount (具有及时性)

3.4.2. 度量内容及相应指标

3.4.2.1. 可交付物的度量指标
3.4.2.1.1. 有关错误或缺陷的信息
3.4.2.1.2. 绩效度量指标
3.4.2.1.3. 技术绩效度量指标
3.4.2.2. 交付的度量指标
3.4.2.2.1. 在制品
3.4.2.2.2. 提前期
3.4.2.2.3. 周期时间
3.4.2.2.4. 队列大小
3.4.2.2.5. 批量大小
3.4.2.2.6. 过程效率
3.4.2.3. 基准绩效的度量指标
3.4.2.3.1. 针对进度基准
3.4.2.3.1.1. 开始日期和完成日期
3.4.2.3.1.2. 人力投入和持续时间
3.4.2.3.1.3. 进度偏差(SV)
3.4.2.3.1.4. 进度绩效指数(SPI)
3.4.2.3.2. 针对成本基准
3.4.2.3.2.1. 与计划成本相比的实际成本
3.4.2.3.2.2. 成本偏差(CV)
3.4.2.3.2.3. 成本绩效指数(CPI)
3.4.2.4. 资源的度量指标
3.4.2.4.1. 与实际资源利用率相比的计划资源利用率
3.4.2.4.2. 与实际资源成本相比的计划资源成本
3.4.2.5. 价值的度量指标
3.4.2.5.1. 成本效益比
3.4.2.5.2. 计划收益交付与实际收益交付的对比
3.4.2.5.3. 投资回报率(ROI)
3.4.2.5.4. 净现值(NPV)
3.4.2.6. 干系人的度量指标
3.4.2.6.1. 净推荐值(NPS)
3.4.2.6.2. 情绪图
3.4.2.6.3. 士气
3.4.2.6.4. 离职率
3.4.2.7. 预测型度量指标
3.4.2.7.1. 完工尚需估算(ETC)
3.4.2.7.2. 完工估算(EAC)
3.4.2.7.3. 完工偏差(VAC)
3.4.2.7.4. 完工尚需绩效指数(TCPI)
3.4.2.7.5. 回归分析
3.4.2.7.6. 产量分析
3.4.2.8. 产品规模度量指标
3.4.2.8.1. 需求、功能变更、功能点、数据库规模、构件、代码行、接口
3.4.2.9. 技术有效性度量指标
3.4.2.9.1. 需求覆盖、基线变更
3.4.2.10. 产品质量度量指标
3.4.2.10.1. 【高22下选63】
3.4.2.10.2. 缺陷、缺陷的延续时间、技术性能水平、恢复的时间、复杂度、利用率、吞吐率、响应时间、一些标准间的依从性、操作员的错误、平均故障时间
3.4.2.11. 过程质量度量指标
3.4.2.11.1. 参考成熟度评定、过程审计、生产率、循环时间、已包含的缺陷、遗漏的缺陷、返工工作量、返工构件
3.4.2.12. 3版

3.4.3. 展示度量信息和结果

3.4.3.1. 仪表盘
3.4.3.1.1. 信号灯图
3.4.3.1.1.1. RAG图,其中RAG是红、黄、绿的英文缩写
3.4.3.1.2. 横道图
3.4.3.1.3. 饼状图
3.4.3.1.4. 控制图
3.4.3.2. 大型可见图表
3.4.3.3. 任务板
3.4.3.4. 燃烧图
3.4.3.4.1. 燃起图或燃尽图

3.4.4. 度量陷阱

3.4.4.1. 霍桑效应(Hawthorne effect)
3.4.4.1.1. 对某一事物进行度量时会对其行为产生影响,因此需要谨慎制定度量指标
3.4.4.2. 虚荣指标(Vanity metric)
3.4.4.2.1. 对决策没有帮助的度量指标
3.4.4.3. 士气低落
3.4.4.4. 误用度量指标
3.4.4.5. 确认偏见
3.4.4.6. 相关性与因果关系混淆
3.4.4.6.1. 将两个变量之间的相关性与一个变量导致了另一个变量的因果性混淆

3.4.5. 基于度量进行诊断

3.4.6. 持续改进

3.4.6.1. 度量结果和相关报告有助于
3.4.6.1.1. 避免问题或缺陷
3.4.6.1.2. 防止绩效下降
3.4.6.1.3. 促使项目团队学习
3.4.6.1.4. 改进产品或项目绩效
3.4.6.1.5. 推动决策
3.4.6.1.6. 更好地创造价值

3.5. 与其他绩效域的相互作用

3.5.1. 规划构成了交付和规划比较的基础

3.5.2. 度量绩效域通过提供最新信息来支持规划绩效域的活动

3.5.3. 创建可度量的可交付物时,团队绩效域和干系人绩效域会相互作用

3.5.4. 根据绩效度量结果启动不确定性绩效域中的活动,例如识别风险和机会

3.5.5. 作为项目工作的一部分

4. 不确定性绩效域

4.1. 不确定性

4.1.1. 风险:与不可知未来事件相关的风险

4.1.2. 模糊性:与不了解当前或未来状况相关的模糊性

4.1.3. 复杂性:与具有不可预测结果的动态系统相关的复杂性

4.2. 涉及与不确定性相关的活动和职能

4.3. 预期目标

4.3.1. 了解项目的运行环境

4.3.2. 积极识别、分析和应对不确定性

4.3.3. 了解项目中多个因素之间的相互依赖关系

4.3.4. 能够对威胁和机会进行预测,了解问题的后果

4.3.5. 最小化不确定性对项目交付的负面影响

4.3.6. 能够利用机会改进项目的绩效和成果

4.3.7. 有效利用成本和进度储备,与项目目标保持一致

4.4. 指标及检查方法

4.4.1. 风险应对措施:与项目制约因素(例如,预算、进度和绩效)的优先级排序保持一致

4.4.2. 环境因素:团队在评估不确定性、风险和应对措施时考虑了环境因素

4.4.3. 应对措施适宜性:应对风险、复杂性和模糊性的措施适合于项目

4.4.4. 风险管理机制或系统:用于识别、分析和应对风险的系统非常强大

4.4.5. 项目绩效处于临界值内:满足计划的交付日期,预算执行情况处于偏差临界值内

4.4.6. 利用机会的机制:团队使用既定机制来识别和利用机会

4.4.7. 储备使用:团队采取步骤主动预防威胁,有效使用成本或进度储备

4.5. 绩效要点

4.5.1. 风险

4.5.1.1. 消极风险称为威胁
4.5.1.2. 积极风险称为机会

4.5.2. 模糊性

4.5.2.1. 概念模糊性,即缺乏有效的理解
4.5.2.2. 情景模糊性
4.5.2.2.1. 渐进明细
4.5.2.2.2. 实验
4.5.2.2.3. 原型法

4.5.3. 复杂性

4.5.3.1. 基于系统的复杂性
4.5.3.1.1. 解耦(Decoupling)
4.5.3.1.2. 模拟
4.5.3.2. 重新构建的复杂性
4.5.3.2.1. 多样性
4.5.3.2.2. 平衡
4.5.3.3. 基于过程的复杂性
4.5.3.3.1. 迭代
4.5.3.3.2. 参与
4.5.3.3.2.1. 创造机会争取干系人参与,可以减少假设数量
4.5.3.3.3. 故障保护
4.5.3.3.3.1. 增加冗余
4.5.3.3.3.2. 增加在关键组件出现故障时能提供功能正常降级的要素

4.5.4. 不确定性的应对方法

4.5.4.1. 收集信息
4.5.4.2. 为多种结果做好准备
4.5.4.3. 集合设计
4.5.4.4. 增加韧性

4.6. 与其他绩效域的相互作用

4.6.1. 随着规划的进行,可将减少不确定性和风险的活动纳入计划

4.6.2. 项目团队成员和其他干系人是不确定性的主要信息来源

4.6.3. 生命周期和开发方法的选择将影响不确定性的应对方式

相关推荐
架构师Wu老七5 小时前
【软考】系统架构设计师-信息系统基础
系统架构·软考·系统架构设计师·信息系统基础
萨达大18 小时前
23种设计模式-模板方法(Template Method)设计模式
java·c++·设计模式·软考·模板方法模式·软件设计师·行为型设计模式
架构师Wu老七1 天前
【软考】系统架构设计师-信息安全技术基础
网络·安全·web安全·软考·系统架构设计师
萨达大2 天前
23种设计模式-备忘录(Memento)设计模式
java·c++·设计模式·软考·备忘录模式·软件设计师·行为型设计模式
萨达大2 天前
23种设计模式-访问者(Visitor)设计模式
java·c++·设计模式·软考·访问者模式·软件设计师·行为型设计模式
it技术分享just_free2 天前
软考教材重点内容 信息安全工程师 第 4 章 网络安全体系与网络安全模型
网络安全·信息安全·软考·网络安全模型
萨达大3 天前
23种设计模式-状态(State)设计模式
c++·设计模式·状态模式·软考·软件设计师·行为型设计模式
架构师Wu老七4 天前
【软考】系统架构设计师-数据库设计基础
数据库·软考·系统架构设计师
架构师Wu老七5 天前
【软考】系统架构设计师-计算机系统基础(4):计算机网络
计算机网络·系统架构·软考·系统架构设计师
架构师Wu老七5 天前
【软考】系统架构设计师-计算机系统基础(2):操作系统
系统架构·操作系统·软考·系统架构设计师