项目管理之八大绩效域------笔记(四)

· 浏览次数 : 1

小编点评

## 变更处理情况适应型概述 **目标七通过检查团队绩效18.6 交付绩效域一、预期目标:** 1. **价值的交付:** * 1.1 什么时候交付价值不同类型的项目,交付价值不一样,比如:增量型的项目,第一周开发一个小的模块。 * 1.2 与价值交付相关的文件对项目影响最大的文件。 * 1.2.1 可行性研究和评估在项目启动或启动之前,做的可行性研究和评估,因为可行性报告里就要明确清楚,一年后交付得到多少利润,1.2.2 项目授权文件对于传统项目,项目章程中要写清楚项目的预期利润的目标,预期交付成果,所以肯定决定交付价值。 **可交付物 (重要内容):** * 可交付物反映了干系人的需求、范围和质量主要学习的事如何处理需求不同项目: * 范围明确且相对稳定的项目,通常会在项目初期与干系人合作,启发并记录需求; * 部分项目,开始时只有高层级的粗略的需求,详细需求会在项目进展过程中逐步细化和明确; * 部分项目会在项目工作进行期间不断提出新的需求。(不断提出需求,只能采用适应型或敏捷型的开发方法) **可交付物 (其他内容):** * 可交付物 ---- 管理需求: * 必须进行需求管理,以确保项目需求得到明确定义。 * 需求管理用于收集、分析、核实和执行需求,以确保项目满足需求。 **质量:** * 除了关注可交付成果,还要关注可交付成果或者整个项目的质量。 * 范围和需求聚焦于需要交付的内容质量聚焦于需要达到的绩效水平。

正文

18.5 项目工作绩效域

  • 在整个项目期间

一、预期目标:

  • ①高效且有效的项目绩效;
  • ②适合项目和环境的项目过程;
  • ③干系人适当的沟通和参与;
  • ④对实物资源进行了有效管理;
  • ⑤对采购进行了有效管理;
  • ⑥有效处理了变更;
  • ⑦通过持续学习和过程改进提高了团队能力.

二、绩效要点:

1.项目过程

1.1 需要过程分析--- 建立并定期审查
  • 该过程中是否存在瓶颈
  • 工作是否以预期速度进行
  • 是否存在阻碍进展的障碍因素
1.2 需要过程优化

1.2.1 精益生产方法

  • 非增值活动: 例如:生产某个产品或者做一个项目,存在五个过程,哪个或哪些过程不增加价值,这种活动叫做非增值活动.

1.2.2 回顾会议或经验教训

  • 经常召开回顾会议:回顾会议主要工作时进行经验教训的总结.敏捷项目每次迭代之后,都要开一个回顾会议.

1.2.3 价值导向审查

2.项目制约因素

平衡竞争制约因素
  • 平衡以下因素,最终是为了实现干系人满意.

  • 三重底线: 不管项目经济方面的制约因素,符合经济指标,社会责任,生态环境责任

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

  • 工作要聚焦在工作过程(去掉非增值的活动,只保留交付价值的过程),聚焦于保护项目团队的工作能力(总结:有好的工作过程,有高绩效,高能力的团队,项目工作才能做好).
  • 项目经理需要持续的进行评估和预测(更关注工作能力,对工作能力进行评估和预测,在整个项目过程中,注意团队的能力平稳和及时的释放)

4.管理沟通和参与

  • 持续的管理干系人的沟通,持续的管理干系人的参与.

  • 在项目进行过程当中,如果干系人提出大量的特殊沟通需求,(特殊沟通需求:需要更多的沟通信息,需要另外一种格式的信息,或者不需要信息,为什么频繁发邮件)结论就是在规划的时候,规划沟通不足,返回去重新进行规划沟通,去修改沟通管理计划.

5.管理实物资源

5.1 管理实物资源需要物流计划
  • 物流计划:描述了如何在项目中实施公司政策,相关文档(就是内容)包括关于材料类型的估算,估算依据、一段时间内的预期使用量、等级规范以及交付时间和地点
5.2 管理实物资源的目标
  • 减少或消除现场的材料搬运和储存

  • 消除材料等待时间

  • 最小化报废和浪费

  • 促进安全的工作环境

6.处理采购事宜

  • 采购可以在项目期间的任何时候进行,厂.采购活动应整合进项目运行之中

7.监督新工作和变更

7.1 敏捷或适应型项目---敏捷项目处理变更
  • 敏捷项目会不断演变和调整,所以要使用待办事项列表来记录工作,如果有新的任务就把新的任务直接放入待办事项列表中(注意:敏捷项目中不是项目团队或项目经理把客户新的要求放入到待办事项列表中,而是由客户或者PO(产品负责人)才有权利把新的工作放进待办事项列表中),客户或PO持续对待办事项列表进行优先级排序,团队在进度或预算受到限制的条件下,保证始终完成优先级高的事项

7.2 预测型项目---预测项目处理变更
  • 项目经理或者项目团队跟CCB(变更控制委员会)合作,进行变更流程,事先制定项目管理计划,如果项目管理计划更改了,已批准的变更要修改各个子计划和各种文档,变更结果通知给受影响的干系人,范围变更会影响很多层面的东西,范围变更会造成很大的风险,要对范围变更进行风险评估.

8.学习与持续改进----- 关注知识转移

  • 学习:主要指团队学习,持续改进:团队方面的持续改进.
8.1 项目团队通过定期开会,学习确定
  • 他们未来在哪些方面可以做得更好子 (经验教训) (开会确定经验教训)

  • 他们如何在即将到来的迭代中对过程做出改进和提出质疑(回顾) (回顾过去,看未来如何改进)

8.2 学习不同方面持续学习
  • 针对项目,例如完成特定工作的特定方法和技术
  • 针对项目集和项目组合,例如减少缺陷的质量保证方法
  • 针对整个组织,例如培训用户如何使用新的软件应用程序

三、 指标及检查方法

  • 如何证明七个目标达成了.

目标一

  • 通过查看各种工作绩效报告,来看项目绩效是否达成了.

目标二

  • 过程适宜性,过程是否有价值,是否对最后的可交付成果有意义

目标三

  • 通过沟通的有效性来衡量,沟通管理计划是否正常执行了.

目标四

  • 观察真实的资源的利用率.

目标五

  • 审计采购过程,看采购过程是否合适.

目标六

  • 预测型:通过变更日志来监控或者评估一下变更的处理情况
  • 适应型:去看待办事项列表,是否正常建立了,是不是按照做过的要求进行范围增加了.(待办事项列表的范围也可以删除)

目标七

  • 通过检查团队绩效

18.6 交付绩效域

一、预期目标:

  • ①项目有助于实现业务目标和战略;(项目的交付成果,有助于实现业务目标和战略)
  • ②项目实现了预期成果;
  • ③在预定时间内实现了项目收益;
  • ④项目团队对需求有清晰的理解;(交付的内容要实现需求)
  • ⑤干系人接受项目可交付物和成果并对其满意。

二、绩效要点:

1.价值的交付

1.1 什么时候交付价值
  • 不同类型的项目,交付价值不一样,比如:增量型的项目,第一周开发一个小的模块.
  • 有的项目采用一次性的交付,整体部署之后才产生价值.
  • 越敏捷型的项目交付越早.
1.2 与价值交付相关的文件
  • 对项目影响最大的文件.
  • 项目交付后的一段时间,还可以继续获得价值.
1.2.1 可行性研究和评估
  • 在项目启动或启动之前,做的可行性研究和评估,因为可行性报告里就要明确清楚,一年后交付得到多少利润,

1.2.2 项目授权文件
  • 对于传统项目,项目章程中要写清楚项目的预期利润的目标,预期交付成果,所以肯定决定交付价值.
  • 顶层信息,比较高层次的信息.

2.可交付物(重要内容)

  • 中间的结果也叫可交付物.
  • 可交付物反映了干系人的需求、范围和质量
  • 主要学习的事如何处理需求

不同项目:

  • 范围明确且相对稳定的项目,通常会在项目初期与干系人合作,启发并记录需求;(项目的早起就可以让干系人把项目范围或需求说出来)

  • 有些项目,开始时只有高层级的粗略的需求,详细需求会在项目进展过程中逐步细化和明确;(高层级的需求可以通过原型法不断地细化需求)

  • 还有一些项目会在项目工作进行期间不断提出新的需求。(不断提出需求,只能采用适应型或敏捷型的开发方法)

总结

  • 传统的预测型项目,需求也可能发生变化,所有的项目都要做需求的管理.
  • 传统项目要把所有需求收集完毕,形成需求跟踪矩阵,用类似技术管理和跟踪需求.
2.1 可交付物 ---- 需求启发
  • 需求启发:收集需求的一个过程.
需求应符合以下标准(每一个需求要符合下边的指标)
  • 清晰:只有一种解释需求的方式
  • 简洁:要用尽可能少的文字表述需求
  • 可核实(重点):有一种方法可以核实需求是否已得到满足(需要给定可核实的指标)
  • 一致性:没有相互矛盾的需求 (需求之间的一致性,不同需求之间不能产生对抗或者矛盾)
  • 完整:整组需求代表了当前项目或产品需要的全部
  • 可跟踪:每个需求都可以由一个唯一的标识码来识别(可以通过需求跟踪矩阵,为需求分配一个可以跟踪的ID)
2.2 可交付物 ---- 不断演变和发现的需求
  • 随着项目进展,需要不断演进,要关注不断演变和发现的需求
  • 混合型或者敏捷型项目中,需求不可能明确定义,对于不断演变的需求,可以使用原型、演示、故事板和模型等方法,不断地展现已经收集的需求,让用户提出更多的需求,用这些方式处理需求的演变。
2.3 可交付物 ---- 管理需求
  • 所有项目都要进行需求管理。
  • 不进行需求管理,可能导致很多不好的现象。可能导致返工、范围蔓延客户不满意、预算超支、进度延迟,甚至导致项目失败。
  • 大部分项目应该设置专门的需求管理员,他用各种技术进行需求管理,项目需求非常多,靠手工的方式已经很难管理了。
2.4 可交付物 ---- 定义范围和管理变更
  • 所有需求处理好之后,要最终确定项目的范围。
  • 可交付物绩效域还包括定义范围,管理范围的变更。
  • 在稳定环境运行的项目(预测型项目),如何防止范围漫延,就是所有范围变更都要走整体变更,控制流程。

3.质量

  • 除了关注可交付成果,还要关注可交付成果或者整个项目的质量。
  • 范围和需求聚焦于需要交付的内容质量聚焦于需要达到的绩效水平。
  • 与质量相关的钱,是由组织承担的,成本属于一致性成本,由所在的组织承担
  • 在质量方面投入的钱,不是越多越好,做成本收益分析,平衡投入。
  • 发现缺陷的时间越晚纠正缺陷的成本就越高。基于早期的需求收集和范围定义,假如当时的需求或者范围工伤出现纰漏,导致后期的设计和开发返工,代价特别大,会有一个累积的成本,为了节约成本,尽早在项目的早期及时发现或者孤立

三、 指标及检查方法

  • 目标都达成了。

  • 确定交付物和目标结果的一致性(这个目标不是项目经理决定的)
  • 根据实际完成情况来看实现了(跟项目经理有关)
  • 根据收益管理计划,查看是否在预定在预定时间内有收益了.
  • 需求是否稳定,传统预测型,了解的比较清晰,适应型,是否对干系人的需求理解
  • 调查干系人的满意度,查看质量是否好

与项目管理之八大绩效域------笔记(四)相似的内容:

项目管理之八大绩效域------笔记(四)

18.5 项目工作绩效域 在整个项目期间 一、预期目标: ①高效且有效的项目绩效; ②适合项目和环境的项目过程; ③干系人适当的沟通和参与; ④对实物资源进行了有效管理; ⑤对采购进行了有效管理; ⑥有效处理了变更; ⑦通过持续学习和过程改进提高了团队能力. 二、绩效要点: 1.项目过程 1.1 需

项目管理之八大绩效域------笔记(五)

18.7 度量绩效域 度量绩效域涉及评估项目绩效和采取应对措施相关的活动和职能度量是评估项目绩效,并采取适当的应对措施,以保持最佳项目绩效的过程。 一、 预期目标: ①对项目状况充分理解;(随时对项目有充分了解) ②数据充分,可支持决策; ③及时采取行动,确保项目最佳绩效; ④能够基于预测和评估作出

项目管理之八大绩效域------笔记(三)

18.3 开发方法和生命周期绩效域 跟开发方法,项目交付节奏和生命周期相关的活动和职能. 一、预期目标: ①开发方法与项目可交付物相符合; ②将项目交付与干系人价值紧密关联; ③项目生命周期由促进交付节奏的项目阶段和产生项目交付物所需的开发方法组成。(项目周期的设计符合项目的交付节奏和开发方法) 二

项目管理之八大绩效域-------笔记(二)

八大绩效域详细解析 18.1 干系人绩效域 跟干系人所有相关的活动. 一、预期目标 ①与干系人建立高效的工作关系 ②干系人认同项目目标 ③支持项目的干系人提高了满意度,并从中收益 ④反对项目的干系人没有对项目产生负面影响 三四是一个意思,就是支持你的人更支持你,反对你的人没有负面影响. 实际工作 这

项目管理之八大绩效域-------笔记(一)

绪论 一、核心术语 1.预期目标 给干系人绩效域一个KPI(预期目标)来对其衡量其做的好不好,这个KPI就叫做预期目标. 2.指标及检查方法 要对目标是否做好进行评价,这个评价就是指标及检查方法 3.绩效要点 为了完成预期目标的三个KPI,应该做什么工作或者应该关注哪几个方面的活动,来达成预期目标,

软考高项八大绩效域及论文纲要

转载请注明出处: 不确定性绩效域 软考高项(高级信息系统项目管理师)中,不确定性的绩效域要点包括风险、模糊性、复杂性和不确定性本身。以下是对这些绩效要点特征的说明,以及项目经理在应对这些要点时的常用实践: 1. 风险 特征: 风险是指潜在的不利事件或情况,可能会对项目的目标产生负面影响。 风险具有可

从零做软件开发项目系列之八——系统部署调试

软件项目的部署和调试工作是项目开发生命周期中的重要阶段,它涉及将开发完成的软件应用程序部署到目标环境并进行测试和调试,以确保系统能够正常运行并满足用户需求。

SaaS化开源项目之HouseKeeper云上部署实践

摘要:华为云DTSE技术专家从源码构建、应用部署到系统调测,详细解读云原生SaaS应用构建的全过程。 本文分享自华为云社区《HouseKeeper云上部署实践》,作者:华为云DTSE。 HouseKeeper是华为云开发者团队基于SaaS项目技术支持实践,采用微服务架构(SpringCloud),结

ArchKeeper (开篇):架构守护平台的问题与理念

在敏捷开发环境下,系统通过迭代增量的交付价值,系统架构也是如此。团队不可能在项目之初就建立完美的系统架构,系统架构应该随着系统迭代不断演进。架构演进和架构腐化是看待架构的不同视角:架构腐化着眼于现状,架构演进侧重于未来架构腐化不可避免,随着时间流转腐化现象必然发生。而我们需要做的是:通过某种方式及早发现和修正

项目讲解之火爆全网的开源后台管理系统RuoYi

博主是在2018年中就接触了 RuoYi 项目 这个项目,对于当时国内的开源后台管理系统来说,RuoYi 算是一个完成度较高,易读易懂、界面简洁美观的前后端不分离项目。 对于当时刚入行还在写 jsp 模板的博主来说,RuoYi 项目在后台基础功能、模块划分、易用性和页面美观度上,对比同期用 Java