PMP从好奇到惊奇

本文深入探讨了项目管理的知识体系,包括五大过程组、十大知识领域,以及敏捷方法的应用。强调了规划、执行、监控和变更控制的重要性,同时也提到了敏捷环境下的团队协作、领导风格、风险管理和干系人管理。通过实例展示了如何在敏捷项目中进行需求管理、迭代评审、风险应对和冲突解决,强调了透明、检视和适应的敏捷原则。
摘要由CSDN通过智能技术生成

知识点

1203

5大过程组,10大知识领域,49个项目管理过程
工具与技术

复习题1

质量管理强调规划和执行胜于检查
为确保达到预期收益,一定要及时邀请客户和干系人来进行审查/评审
瀑布型项目往往在需要的时候或临近阶段收尾时评审
敏捷项目每个迭代末都邀请干系人来评审
当风险变大时,需要规划风险应对,进一步减轻或消除风险
服务型/仆人型领导风格的敏捷项目经理会积极为团队成员提供指导,支持,培训等,以提高团队能力
敏捷强调面对面沟通,鼓励成员在会上发言
商业价值是立项的最直接原因,当商业价值降低时,应该与发起人一起讨论分析
德尔菲技术避免圣人光环效应和凡人从众心理的影响,给出客观的分析和决策结果
冲突需要冲突管理和谈判来解决
谈判是项目经理获得期望资源的必要方法
识别到风险,进行风险分析
干系人参与出现问题,首先检查其输入的干系人登记册及干系人参与计划
质量控制测量结果是对项目实施中可交付物的质量控制结果的记录,遇到未达到质量标准的情况,核查QC记录
制定供方选择标准,包括筛选系统和加权系统,依次获得符合要求的最好的供应商
做详细计划瀑布型
做不确定项目,滚动式
敏捷强调把有限的精力优先分配给开发工作上的非管理计划,尽早做出来结果以获得干系人评审
CCB变更批准的时间很长,对较为激进的时间表来说是潜在风险
备选方案分析用以产生尽可能多的潜在可选方案
如果项目在完工前就提前终止,本过程还需制定程序,来调查和记录提前终止的原因
mvp(最小可行产品),对其进行可行性分析,然后再看是否立项
新需求作为一项待办事项
沟通出现问题,首先检查沟通管理计划,项目经历是项目的沟通接口,高级经理向成员询问项目信息是沟通问题
项目规划时对关键部件进行风险识别,制定风险应对措施
敏捷PO负责需求
进行报告时,不仅要给出状态信息,还需要让读者了解道状态的原因
mvp是敏捷可变范围的交付方式
敏捷中架构师与团队属开发团队,团队是自组织自管理的,他们的决定尤其是技术方面问题的决定,应该获得仆人式pm的支持
识别风险后,进行风险定性分析,设置风险责任人以便对相应的风险进行进一步的应对规划/执行/监督
敏捷环境下的团队领导/项目经理/敏捷主管以及服务型/仆人式领导力,来服务和赋能团队及成员
检查沟通管理计划以获得计划的沟通人员,沟通渠道等
变更管理计划定义了变更控制过程,并记录变更控制委员会的角色和职责
先开会分析讨论,在相应的更新计划
干系人对可交付成果不批准/不满意,检查需求,如需求跟踪矩阵
干系人对信息担心/不满意,检查沟通管理计划
干系人对某个问题不满意,检查干系人参与计划
干系人参与计划的目的是让干系人达到满意,不满意的话首先检查哪些措施没有执行好或制定好
项目经理对本项目负责,有始有终,完成项目收尾的工作
敏捷里PO是客户的代表,对需求负责
启动项目时包括了高层级风险评估
项目章程里包含了高层及范围/主要交付物,概要的里程碑进度,粗略预算,主要资源,高层及风险
敏捷采用增量交付,每次迭代遵守时间盒
当要完成的待办事项已经占满本次迭代的能力时,其它待办事项留给后续的迭代里去规划和执行
PO对需求负责
提高SME的沟通技能
为了避免,本应该,找规划工作
未满足需求,强调规划时应该做好收集需求,应该让相关的跨职能人员都参与规划
沟通有问题,与团队合作来解决沟通问题
破产的供应商也可以合作(尤其具有稀缺性时),但风险很大,需要规划风险应对
新变更请求需要得到批准后才能实施
规划时尽量让相关干系人都参与进来,而非pm或高层几个人参与
群体讨论与民主协商方式制定的计划才是正确的计划
未获干系人参与和批准的计划,即使比较正确,但在认同,承诺和沟通理解上都将非常不足
需求不确定,敏捷使用backlog来适应需求得不断变化
在执行交付高优先级高确定性功能得同时,题干迭代不断调整范围以适应变化
pm是沟通责任人,干系人应该先找pm进行沟通,而不应该直接找项目成员来执行任务(尤其与项目无关得)
预算不够,则按优先级来交付,抓大放小
风险发生变化,应该首先在风险登记册里更新,并更新应对措施
敏捷方法实现尽早地持续交付产品增量,客户用户就可以使用,产生价值
瀑布型往往是最后一次姓交付
一般不要升级给发起人,PM是项目层级内问题得解决者
采购中出现需要不一致得情况,首先检查采购合同和采购计划
出现重大问题,需要升级上报
高层往往需要得是可视化及时面对面沟通
出现沟通问题,首先检查沟通管理计划
进度压缩会增加成本和/或风险,一般赶工会增加成本,快速更进会增加风险
干系人支持与客户配合,可以获得很快的增量评审
出现越界得情况,属于确定问题,应该找原来来解决
当题干出现问题时,因果图/石川图往往是正确选项
冲突双方合作解决问题
采购争议或索赔,先检查合同
出现问题后,先分析原因,才能针对性得解决方案
集中办公,方便采用每日站会来实现透明和检视
持续得监控及验收,才能顺利进入收尾阶段
对于冲突,采取合作解决问题
沟通方式未满足干系人期望,可能是沟通方式得问题,需要审查沟通管理计划,也可能是干系人期望,需要审查干系人参与计划
监督风险需要储备分析
识别到风险,下一步进行风险分析,以及规划应对(解决风险)
蔓延是非法变更,应该得到变更控制
变化与不确定,都说明要采用滚动式规划
对于新方法,鼓励团队先对其进行讨论分析
敏捷增量交付,首先交付价值高得优先级得产品增量
新项目经理刚到位,先审查项目合规得当前状态,在进一步采取行动
以前得类似项目,暗示有经验教训
干系人得持续参与,反馈,和验收,才能够确保产品得成功发布/上市(交付后作为一个立即可用,好用得产品,暗示交付前得持续验收)
面向问题,且比较紧迫(耽搁几个月),直接找团队领导来合作解决问题
团队领导即敏捷主管,各SM是主要得协调人,都是服务型/仆人式领导者
识别到风险,更新风险登记册
解决问题流程:定义问题,分析原因,产生多种解决方案,选择最佳方式,执行方案,检查结果,总结教训
与团队讨论协商,定义出一致得每日站会得时间
增量计划会议就是迭代规划会
客户验收的问题,需要检查需求,尤其是需求跟踪矩阵
会议需要被更好的管理。会议是解决特定问题最有效的沟通方式之一,但会议的代价很高,所以会议管理的技巧和规则都非常重要
团队章程/基本规则会记录主要的会议规则和冲突解决原则
收集需求的工具包括头脑风暴
启动会为干系人传递重要信息,并取得干系人的认同
一般在项目管理计划得以批准后召开,也常常在规划过程中(启动阶段后)召开
项目启动和收尾时,要获得发起人的帮助
对最终预算进行审查,说明此时在预定预算,处于规划期间,识别出了成本超支风险
技能欠缺,注意进行培训
资源过度分配,需要资源平衡,其结果往往导致关键路径变长
权力利益方格,该主管(总监)职权高,利益大(负责改项目的产品)
沟通类型中面对面是最好的沟通方式,信息传递率最高
项目产品的价值,通过项目收益获得
意外即未识别的风险,检查风险管理计划看如何进行下一步
识别出新风险,需要进行分析和风险应对规划
合同履约出现问题,需要首先检查合同
自然灾害是否在规划及签订合同时已经考虑
地震往往不可预测,属于除外责任
台风往往具有规律且可预测,可能不属于除外责任
资源管理计划包含认可和奖励计划
紧急问题需要升级给特定的人员
先分析,在决策和执行
节日不一定放假,重要的节日才能房价
项目结束后,PM和成员依然被要求进行交接,说明没有成功移交
采购监督中的问题和争议,先检查合同,在进行谈判及ADR
出现问题,分析原因,产生解决方案
错误的行为将对团队带来很大影响,需要PM及时处理
SWOT和PESTLE都是风险识别和分析的工具
敏捷工具和方法(任务版,每日会)也可以在预测型中使用
识别到机会,开拓策略是将最有能力的资源分配给任务
敏捷强调团队负责,而非个人负责
瀑布更强调个人负责
担心说明沟通有问题,检查沟通管理计划
新需求是变更请求,需要遵守变更流程,通过CCB决策
变更都需要经过整体变更控制过程
合规要求属于非功能需求,往往定义在DOD中
如果采用了正确的敏捷方法,那么已开发的功能的优先级最高,不应该进行所有修改,虽然还未使用backlog来管理产品功能
大量测试任务堵塞,说明团队应该蜂拥去解决杜塞,需要团队成员是通才(T型人才)
敏捷方法对外部变化进行及时响应
风险包括负面威胁和正面机会,进行量化分析可以得出风险总体值为正还是负
开发经理说可以满足,还需要PO来判断
质量问题是在控制质量过程中,结果往往过程没做好,需要审计质量过程
希望停止项目是大风险,应该已经被识别和规划,并记录在风险登记册里
如果没有上述选项,应该需要参考风险管理计划来看如何处理
新主任是新干系人,首先添加在干系人登记册中
干系人态度出现问题,需要分析和解决(在干系人参与计划里)
预测型项目需要尽可能完善的项目规划,以免在项目执行中出现问题,此时解决问题将需要巨大代价
对于资源规划,需要先确定需要哪些技能,如果不足,在考虑通过培训来获得
不积极参与,是要解决的问题
出现问题,分析原因,产生解决方案
新变更,遵循变更流程10步
预防-变更请求-分析影响-备选方案-CCB批准-更新-沟通-执行-检查-总结
诚实反馈,往往采用匿名方式
可能,说明出现了新风险
开会是互动沟通,不是拉式或推式沟通
干系人包括外部干系人和内部干系人,所以与干系人开会不能说是外部或内部沟通
敏捷强调透明,检视,适应。项目领导应该多与大家分享
敏捷团队合作,一起工作
敏捷主张采用小/短周期的迭代,以便尽早地持续不断地交付有价值的产品增量
采购中的争议,往往找合同和SOW
SOW是对需要采购的详细范围描述,与供应商在可交付成果方面有争议时,可以查看SOW来核实
敏捷中干系人通过持续参加冲刺评审会给出反馈和新要求,并进行更多沟通
敏捷不提倡详细的工作绩效报告
成本基准中包含应急储备,不包含管理储备
处于监督风险过程,风险已经消失,项目即将完成,应该关闭风险,即风险审查/风险在评估
收集需求时,当需求不确定时,需要使用原型法从模型创建,用户体验,反馈收集,原型修改的反复循环过程
事先设计故事板及用户界面框图,从客户方获得反馈和更明确的需求
PO定义冲刺待办事项(被选中的用户故事,及分解用户故事后的任务),而不是一起通过冲刺规划会来制定,说明整个团队存在角色和工作的认识问题
确定的部分(具有详细规格)使用预测方法,不确定的部分(只是基本规格)使用敏捷方法
需求不明确可能是敏捷项目,几个月暗示迭代太长,达数月,应该采用短迭代/小增量
风险负责人未执行风险,应该尽快纠正
角色和职责往往通过RACI来定义,可以认为定义好的RACI表格在资源管理计划里
团队成员对敏捷的认识不一致,需要进行培训和交流以获得一致
启动项目。PM参与制定项目章程,获得重要干系人的支持,最终由发起人确认并承担
敏捷转型:从文化,团队,项目三个维度来进行评测和改善
干系人坚持认为这项功能对可交付成功而言是必要的,按时需要进行变更
只有满足被奖励者的某个重要需求的奖励,才是有效的奖励
有抱怨,说质量保证可能有问题,应该进行分析和解决
质量审计是质量保证过程主要的工具之一
敏捷项目适应外部变化,每次新的冲刺都是调整的时机
收集需求及定义范围,需要对需求进行优先级排序及取舍,在资源和成本约束的情况下,以规划MVP并获得干系人的建议
问题及原因已经获得,为避免将来出现同样的问题,应该进行经验教训总结并更新知识库
非关键路径上的获得存在浮动时间,可以利用
项目结束时由相关部门进行各种审计,将为项目交付物带来更多价值
PM通过创建沟通管理计划,来管理沟通
PO负责对backlog事项进行优先级排序,考虑平衡业务特性和技术特性
识别问题-分析原因-产生解决方案
团队成员技能不匹配,PM安排培训来加强匹配关系
项目既可以采用预测,又可以采用敏捷,说明可以进行优化成为混合型,即确定的部分采用预测,不确定的部分采用敏捷
团队速度,所以项目为混合型/敏捷型,当事项/问题很多时,需要进行优先及排序,以便花精力解决主要问题
冲突是要解决的,否则团队绩效很低
敏捷提倡团队一起办公,方便沟通且凝聚力更高
关键干系人例如客户不着PM而是直接找发起人沟通,说明沟通出现问题,先审查沟通管理计划。
PM是沟通负责人/接口

复习题2

敏捷强调个体和互动,强调开发成员角色转型为T型人才,进行民主,平等,高效的互动,以产生团队智力
SME作为新成员如果认识到这点,就可以鼓励并促进自组织自管理敏捷团队的形成
凸显模型可以确定已识别相关方的重要性
适用于发杂的相关方大型社区,或在相关方社区内部存在复杂的关系和网络
凸显模型将干系人分为八类
权力利益方格将干系人分为四类
制定项目管理计划过程。PM与团队编制项目管理计划后,需要与干系人进行交流与更新,并获得干系人们的批准
良好的沟通避免歧义和返工
开工会议/启动会议用以实现项目目标传达,获得团队及干系人的承诺
瀑布模式下的产品上市或者发布是在项目结束后
敏捷模式的产品上市或发布是增量的
项目管理转型时,干系人不了解这样的情况,需要沟通以确保被正确理解
虽然分布在各地,不便沟通,但总结经验教训是一定要做到的,他是项目结束时的交付物之一,使组织过程资产增值
制定项目章程的工具解决冲突。
项目章程的内部比较高层及(粗略)
通过合作解决问题在此时最常用的冲突解决策略
已批准的变更,需要与干系人进行沟通
当某些干系人坚决不认可时,可以提出他的新变更请求
通过会议如引导式研讨会等,帮助干系人实现讨论协商,最终获得共识
获取资源时,PM往往通过谈判获得所需资源
瀑布型项目环境下默认的组织结构类型是平衡型矩阵,PM不具有资源的支配权,且资源往往是兼职
敏捷开发人员是全职在团队里
对供应商的合作需要更多规范化,对所有潜在供应商一视同仁,进行协商及招投标,而非简单确定之前的或某人推荐的供应商
冲突出现时,不经协商讨论直接做出决策,是强迫/指导的冲突解决技术
项目收尾报告,包括项目实施的详细信息,包括最终更新的成本估算信息
项目初始阶段(启动阶段),规划阶段之前,高层及风险是包含在项目章程里的
问题解决流程:定义问题,分析原因。产生多种解决方案,选择最佳方案,执行方案,检查结果,总结教训
商业论证记录了项目对组织的价值,此时需要审查商业论证
敏捷项目里的干系人主要通过评审会了解项目进展,如果有的干系人需要了解项目更及时的进展信息,可以邀请他来参加每日会(但不要干扰开发团队)
团队期待收尾,应该先获得验收,PM应该事先定义验收标准
出现问题,分析原因,产生解决方案
成员对下一步及最终结果感到困惑,是因为缺乏目标感,项目目标与阶段目标,都是为了加强团队的方向和动力
敏捷开发团队基本上处于冲刺开发活动中,所以需要协商一个双方都可以参与的时间来进行主题研讨
进行敏捷实践时,需要分析,选择并裁剪适合于组织自己的具体敏捷方法
敏捷团队如果不能集中办公,则需要视频或虚拟协作软件,营造一种集中办公的氛围,实现集中办公的高效合作和绩效
执行阶段即成熟期/绩效期/表现期
多个敏捷团队通过SOS进行协作
团队可能需要对用户故事进行进一步的理解,才能决定哪个算法更好
服务型/仆人式领导在组织里是变革代言人,宣传敏捷,向干系人解释敏捷的好处及良好实践,并指导和培训
干系人的要求是冲突的,除了理解差异,还要对干系人的权利,利益,影响等进行分析评估,甚至优先级排序,才能更好的解决问题
EAC>BAC说明预算不足以完成项目,钱的事需要找发起人
转型敏捷,先进行敏捷培训,对使用敏捷工具存在分歧,往往是不能正确使用,也说明要进行培训
敏捷项目里干系人参与项目的最主要方式是参加迭代评审会
敏捷主张学习别人的优良做法
采用新技术后速度下降是正常的,早期需要学习,所以导致工作速度下降,对此问题在回顾会里进行分析讨论,并制定解决方案和纠正措施
每日会超过15分钟,需要解决这个问题,可以是每个团队领导SM先开会,在整体开会
团队五阶段:形成期,震荡期,规范期,成熟期/绩效期,解散期
形成期后很容易进入震荡期,团队绩效很低
在形成期和震荡期,要积极主动解决负面行为,减少对团队绩效的破坏
敏捷项目里干系人参与项目的最主要方式是参加迭代评审会
对于会议确定的诸多行动事项,需要进行优先排序以便有效行动,并指定责任人监督执行
开发团队在迭代中一般不接受需求变更。PO应该将变更添加到Backlog里,而非找开发团队直接变更
敏捷交付的问题尤其是质量问题,往往是DOD没有很好定义
文档编辑作为DOD的一项
缺乏干系人支持的问题,需要通过干系人管理来解决
执行干系人分析,规划干系人参与计划,举行开工会议以获得干系人承诺,这些将保证干系人更好的支持
开工会议期间,团队收到干系人对计划的支持,和对项目的承诺,说明在规划和沟通方面做的都很有效
在计划线以上的点,就是执行不好的点
质量问题实施质量管理计划/执行保证质量过程
好过程就有好结果
为了物质利益而牺牲质量,非常错误
PM/SM是服务型/仆人型领导,对团队要及时进行指导,辅导,培训促进团队的健康成长
敏捷三角形:固定的时间,固定的成本,可变的范围
可变的范围是backlog待办事项列表的表现,按照优先级来进行排序
缺乏干系人支持,监督参与干系人有问题,需要检查干系人参与计划并执行好管理干系人参与,计划好,执行过程好,结果就会好
提倡不同敏捷团队之间的知识共享和交流
分解是项目管理的第一大做法
瀑布项目使用工作分解结构WBS来分解
敏捷项目使用待办事项列表PBL来分解
瀑布项目的进度压缩包括赶工和快速跟进
SS属于并行,比串行更快
当前使用的沟通渠道,要符合总体的沟通政策
沟通问题,检查干系人对沟通的需求
合规性往往是看工作是否符合流程,政策。即通过审计来监督合规性
当前处于启动阶段,对于反对项目的干系人,应该进行干系人分析及干系人映射分析,设法影响干系人。
如果还不行,在找发起人解决
PM先自己努力解决,解决不了再找发起人
目前处于冲刺期间,质量问题及由此带来的时间问题,可以在冲刺末的回顾会里进行分析讨论和解决
收尾时机密文件的归档,需要遵守客户(政府机构)的相关保密政策
对于软件应用程序,增量交付可用尽早地,持续不断地交付有价值地产品增量让客户满意,每次迭代都可用适应竞争市场带来地变化
项目管理计划不被批准,项目就无法开始执行,大事需要升级给发起人来解决
敏捷团队是自组织自管理,项目领导通过服务型支持团队来自己解决问题
完全按照流程,出现问题,说明流程有问题需要改进
项目章程包含了项目成功标准地内容
问题日志有效更近和管理问题,确保他们得到调查和解决
为获取资源,项目经理先检查所需资源地可用性
进度延迟地问题需要解决,以免不满足发起人要求
项目经理消除团队遇到地障碍,并通过服务型/仆人型来赋能团队
风险是将来可能地问题/机会,设计时间,概率和影响
PM应该积极开展团队建设活动,提高信任,提高协作
团队是自组织自管理地,对于技术问题,更是开发团队来分析解决,PM通过服务型/仆人型来赋能团队
障碍(缺陷/技术债)是backlog里地一类事项,需要进行优先级排序
成功消除75地障碍,说明项目遇到多个障碍,多个事项时,需要进行优先级排序,以集中精力解决掉哪些大影响地障碍
团队是自组织自管理地,PM通过服务型/仆人式来解决团队问题
项目经理支持团队学习新工具,解决瓶颈
项目经理支持团队通过学习新工具,解决瓶颈
项目启动,首先指定项目章程,包含项目目标,使命和愿景
客户不具有适当地决策权,是造成项目管理计划无法批准地原因,需要识别出正确地干系人
关键干系人不找PM,直接找项目成员询问项目信息,说明是沟通问题,需要解决。
PM应该定期(每周)发布工作绩效报告,以便干系人了解项目状态
敏捷团队是核心,敏捷团队对优先级排序具有决定权
敏捷三角形(固定的时间,固定的成本/资源,可变的范围)。钱不够时,减少范围
鼓励冲突双方自行解决冲突,需要培训他们具有适当的情商
敏捷项目通过增量发布来实现价值的快速交付
审查范围管理计划,来看是否应该提出范围变更请求
产品设计不合格,说明产品设计前的需求收集没做好
控制图出现越界,说明过程失控,过程失控,意味着大量的结果不符合指标
担忧是因为沟通不足,加强沟通,针对特殊话题需要互动式沟通,面对面开会沟通是效率最高的方式
启动大会具有重要意义,尽量获得所有干系人的参加和承诺
沟通出现问题,需要审查沟通管理计划
团队按照一定的节奏进行开发工作,如果经常被临时打断,工作效率将降低,所以服务型/仆人式应该消除干扰,去找项目负责人以改变相应的做法
项目责任人可能是发起人或PO,是对项目结果负责的那个人
PO是对产品结果负责的那个人
运营团队是重要的干系人,参加迭代评审会以便给出反馈和要求
混合/敏捷强调持续获得干系人反馈
对于分歧进行沟通,互相理解对方的想法,最终达到一致
敏捷三角形(固定的时间,固定的成本/资源,可变的范围)
mvp最小可行产品就是这样的体现
出现问题,在回顾会讨论,获得应该措施
发起人要求开发过程中产品可用增量展示
团队成员技能欠缺,去参加培训是良好的做法
干系人直接发生争议,不支持变更,审查干系人参与计划以期改变态度/参与度,并提供变更被批准的信息
项目团队负责解决项目执行中的问题
敏捷团队是自组织自管理的,任务是开发团队自己分配
估算技术里,专家判断和类比估算都比较块
项目启动,从发起人那里获得项目相关信息
项目不确定性很高,采用敏捷方法。敏捷项目采用mvp进行验证,获得反馈
项目工作已经完成,项目结束
增量交付是每次迭代就展示价值
收集需求:访谈,焦点小组,引导式研讨会
团队成员的职责发生变化,及时更新
创造透明,真诚的沟通环境
干系人极大地影响项目成败
敏捷项目里干系人一般是通过参加迭代评审会,以及PO与他们地持续合作,来参与项目
多项目时项目直接地依赖关系是要管理地
敏捷项目经理通过服务型/仆人式来支持自组织团队
开发团队可以指定一名成员对其进行管理,来参加各敏捷团队地SOS协调会
识别新地干系人,持续地发布项目信息
当PMO项目框架不符合敏捷,应该请求PMO修改框架
团队成员在每日会上进行沟通和协调,出现风险,需要下一次每日会上更新情况
项目经理对管理干系人参与负责,紧密合作,满足他们地需求
规划地时候,就要对关键路径上地资源进行风险识别
在项目实施中,这些资源发生问题地话,应该是已识别风险,且有相应地应对措施
新项目,先指定项目章程
本地机构是干系人,说明PM应该事先进行干系人管理
沟通非常重要,虚拟团队由于不在一起,尤其要重视沟通与协调
每日会议是一种有效地沟通机制
理想地召开启动会议地时机,是在项目管理计划得以批准后召开,也即它是规划阶段地最后一件事,所以会议结束意味着规划阶段就结束了
外部法规变化,需要分析讨论其影响,并可能实施变更措施
收益,参考收益实现计划
团队成员是通才,每日会最好的主持人是团队自己,所以应该鼓励并提供机会给这名团队成员
CPI成本绩效指标是项目地核心绩效信息
敏捷团队缺乏某方面地能力时,往往是培训大家来掌握
有时候完全缺乏某方面技能,就可能需要增加人员来承担,并进行知识共享
关键路径反映了项目进度
团队成员绩效有问题,需要PM指导和支持,帮助提高绩效
RACI说明每个人地角色与职责,有效防止职责不清和冲突
可行性研究地不确定程度很高,所需时间不确定,首选工料合同
敏捷项目以团队为核心,团队是自组织自管理,要鼓励并相信团队工作
担心说明需要去沟通解释,敏捷里功能优先级排序地主要依据是其商业价值
项目开始前,先制定项目地产品路线图和发布计划,以便干系人理解方向与远景
合同履约过程中地不一致,首先检查合同
敏捷项目里,项目经理通过服务型/仆人型领导来促进团队工作
支持团队内部地合作,实现更好地沟通和工作绩效
混合型/敏捷项目采用每日会来沟通和协调,实现团队透明和检查。虚拟团队采用虚拟地每日会来进行协调
合作解决问题来解决冲突
OM通过开会,了解客户更新地里程碑和成果要求,需要尽快与项目干系人分享
帮助以后地项目管理将其识别为风险,以避免在次发生这样地问题
合作来解决冲突,分析情况来产生解决问题
敏捷项目经理服务型/仆人型来支持自组织团队,促进团队地沟通和合作来解决问题
长期地跨国项目,需要尤其注重汇率和通货膨胀地影响
风险已经在风险登记册里,已经被识别并有应对计划,需要使用应急储备
需要减少哪些需求,使用成本效益分析来减少那些相对而言成本高收益低地需求
风险研讨会需要关键干系人参加
PM需要制定一个沟通管理计划来进行沟通管理、
对于变更需要先分析影响,在制定相应地解决方案
项目经理鼓励每个人地成长和担当
敏捷项目经理服务型/仆人型来指导和支持团队自我组织和解决问题
在转型为敏捷方法时,可能一开始是混合方法,部分预测部分敏捷,敏捷方法来实现敏捷转型,部分的,循环渐进地改进,而不是一次性地拒绝地修改
敏捷:滚动式规划,应对不断地变化
识别到风险,PM和团队对风险进行分析和规划应对
项目经理需要指导沟通管理计划来实现有效沟通
沟通策略/战略可以理解为高层及地初步地沟通计划
干系人直接出现冲突,合作解决问题是主要方式
干系人已经对项目目标达成一致,可以从这个共同目标出发
迭代评审会很重要,需要事先准备,迭代评审会是在迭代末来举行地,迭代及其评审会都遵守时间盒
规划好,过程执行好,这样就会有好结果,就不用担心
团队不在一起,需要工作环境支持这样地虚拟合作,使用如视频,同步软件,硬件网络配置等设施
项目收尾时,成本移交成果时获得正式地接收签字很重要
PO对需求地优先级排序负责,新需求收到后,先进行需求地优先级排序,以便迭代可以按照待办事项地优先级来进行选择
每日站会地时间盒为15分钟及聚焦话题
要制定干系人参与计划,以便采取措施改善干系人参与度
PM鼓励和支持团队成员及时,定期,持续地总结经验教训,而不是只在里程碑及项目结束时才总结
客户希望尽快有结果,这是敏捷方法可以实现地,敏捷原则强调尽早地,持续不断地提供有价值地产品
服务型/仆人式地项目经理对团队多加指导和支持,以提高团队绩效
对干系人多培训,让他们理解敏捷地原则和正确做法
客户需要高层及,长期地计划,说明需要在高层及使用预测方法,又需要随着项目进展增加功能,说明需要敏捷方法
多项目管理和项目中多各待办事项地管理在有时间逻辑一样,都要进行优先级排序,以便产生更大价值
出现问题,分析原因并制定方案
定义问题,分析原因,产生多种解决方案,选择最佳方案,执行方案,检查结果,总结教训
敏捷通过检查产品增量,以保证产品一定是符合需求和高质量地
虚拟团队,尤其要考虑沟通和协作
实施策略/项目管理计划需要PM和团队一起来制定
PM先考虑团队协作,才能保证后续规划工作地顺利开展
已识别风险发生,审查风险登记册并实施既定地风险应对措施

d模拟一

dbcbb 1 1 1
在这里插入图片描述
计划基准走流程
在这里插入图片描述
知识管理:
EMV:定量风险分析
dcadd 1 1 1
组织结构发生变化,人变了,相关方登记册
制定应急计划说明接受了这个风险
在这里插入图片描述

babba 1
在这里插入图片描述

bbbca 1 1 1
在这里插入图片描述

bbccb
在这里插入图片描述
新的风险=次生风险
bbdab 1

acccd 1 1 1
bcdca 1 1
近似估算
粗略量级估算 -25~75 类比
确定性估算 -5~10 参数

cddbb 1 1
bbbdd 1 1
dbdbb 1 1 1
三个敏捷团队想到SOS
在这里插入图片描述
在这里插入图片描述
PM以计划为驱动
bbdab 1
在这里插入图片描述
a
abde
ccb 1 1
冲突快速解决就强迫

abbca 1
在这里插入图片描述
在这里插入图片描述

de 1
dcdb 1 1
在这里插入图片描述
在这里插入图片描述

dcdac 1 1
发送电子邮件,推式沟通
虚拟会议交互沟通

adabc
bc
cbcc

cadba
ccabba
cdbca
d
abc
cba
dadcd
d
adf
ada
bbddb
dbcbc
ac
cddb

dbcda
a
cdef
aaa

bbdac
cacac

cddaa
bcadc

abada
cdbba

dacab
addba

q模拟三

ac

串讲

题目

1-3

pmi:项目管理协会
挣值管理标准
项目:项目是为创造独特的产品,服务或成果而进行的临时性工作
临时性:明确的起点和终点
商业价值是指组织从商业运作中获得的可量化净收益,包括有形价值和无形价值
项目管理是将知识,技能,工具与技术应用于项目活动,以满足项目的要求
opm:组织级项目管理把项目,项目集和项目组合管理的原则和实践与组织驱动因素(OE)联系起来,从而提升组织能力,支持战略目标
项目组合管理:为了实现战略目标而组合在一起管理的项目,项目集,子项目组合和运营工作
确定资源的分配顺序
确保项目组合的管理与组织战略协调一致
项目集:一组相互关联且被协调管理的项目,子项目集和项目集活动,以便获得分别管理无法获得的收益
项目间的依赖关系
运营两大特性:持续性,重复性
项目声明周期:项目的启动到收尾的一系列阶段
阶段关口:阶段结束时的工作,将项目的绩效和进展与项目和商业文件进行对比,根据比较结果做出的进一步决策。
里程碑
增量:在预定的时间内渐进地增加产品地功能
混合:瀑布与敏捷地混合
事业环境因素限制项目地灵活性
组织过程资产为裁剪过程提供指南和准则

  1. 先做计划
  2. 按计划干活
  3. 有问题先看计划

工作绩效数据:每个正在执行活动中收集得到地原始观察结果和测量值
工作绩效信息:进行整合分析得到
工作绩效报告:实物或电子项目文件
项目管理商业文件:项目商业论证,项目收益管理计划
沉没成本:已经花掉地成本
事业环境因素:项目团队不能控制地
OPA:组织过程资产
OPA是大部分规划过程地输入
过程,政策,程序(PMO更新)
组织知识库(项目更新)
平衡矩阵是默认
有两个老板
PMO:项目管理办公室
项目经理:项目管理,干系人管理,团队管理
12 18 28

4

项目整合管理必须由项目经理负责
在这里插入图片描述
项目章程:一份正式授权项目经理在项目活动中使用组织资源地文件
项目经理参与项目章程地制定
项目由项目以外地机构来启动
在这里插入图片描述
商业论证预期结果是否值得投资
确定项目边界
项目经理不能修改
协议:定义启动项目地初衷
SLA:服务水平协议
数据收集
不出结论
头脑风暴
集思广益
焦点小组
主持人引导
访谈
一对一
会议
立项会
项目章程:发起人与项目经理之间地契约,初始项目规划地起始点
高层及需求
假设日志:记录项目整个生命周期中地假设条件和制约因素
项目启动之前,编制商业论证时
假设条件:制定计划时,不需验证仍被视为正确地因素
制约因素:项目或过程地执行有影响地限制性因素

制定项目管理计划:定义,准备和协调项目计划地所有组成部分,并把它们整合为一份综合项目管理计划地过程
仅开展一次或仅在项目地预定义节点开展
在这里插入图片描述
专家判断:根据项目需要而裁剪项目管理过程
核对单:考虑地项目,行动或要点清单
制定项目管理计划地时候地会议是项目开工会议(启动大会)

项目管理计划构成
在这里插入图片描述
经批准地版本,只有通过正式地变更控制程序才能对其进行变更
绩效测量标准用于挣值管理中
一个项目或项目阶段,如没有正式批准地项目管理计划,是难以有效开展地
项目文件用于支持项目管理计划地实施与项目基准目标地达成
开工会议:启动会
规划阶段地结束和执行阶段地开始
传达项目目标,获得团队对项目地承诺,阐明每个干系人地角色和职责
指导与管理项目工作
工作绩效数据:从每个正在执行地活动中收集到地原始观察结果和测量值
问题日志:记录和跟进所有问题地项目文件
任何项目干系人都可以提出变更请求
通过实施整体变更控制对变更请求进行评审和处理
管理项目知识:
在项目或阶段结束时,将相关信息归入经验教训知识库,成为组织过程资产地一部分
监控项目工作
挣值管理技术是一种常用的形成工作绩效信息的分析工具
实施整体变更控制贯穿项目始终,项目经理对此承担最终责任
紧急情况下的变更可以不经CCB批准就实施,但事后需补办相关变更手续

5

项目范围管理:做且只做所需的全部工作
项目范围有时也包含产品范围
范围基准:范围说明书,WBS和WBS词典
产品范围:需求文件
项目范围:项目管理计划

规划范围管理
创建范围管理计划
在整个项目中对如何管理范围提供指南和方向
范围管理是项目管理的基础
处理对详细项目范围说明书的变更

需求管理计划
需求优先级排序过程
决策:德尔菲技术,100%同意,用来获得专家意见的常用方法
德尔菲技术:去除专家光环
亲和图:对大量创意进行分组
思维导图:将头脑风暴整合成一张图
名义小组技术:用于促进头脑风暴的一种技术,投票排列
观察/交谈:查看个人在各自的环境中如何执行工作
用户故事:干系人需求收益
wbs第二层:生命周期各阶段或主要可交付成果
敏捷方法中将史诗任务分解为用户故事
为每一个工作包分配一个控制账户
项目范围说明书有验收标准
分解WBS工作包,团队应该分析并识别所有项目可交付成果及其相关工作
确认范围是正式验收已完成项目可交付成果的过程
控制质量过程通常先于确认范围过程,但二者也可同时进行
项目收尾:核实范围,合同收尾,财务收尾,行政收尾

管理三原则:
目标管理

PDCA
以人为本

名词解释

PMI:项目管理协会
BOK:知识体系
PMBOK:项目管理知识体系
OPM:组织级项目管理
PMIS:项目管理信息系统
项目是为创造独特的产品,服务或成果而进行的临时性工作
临时性表示有明确的起点和终点
项目旨在推动组织从一个状态转到另一个状态
项目创造商业价值:有形无形
项目启动背景:4种
项目集:一组互相关联且被协调管理的项目,子项目集和项目集活动
大型项目通常需要10亿美元
项目组合:为实现战略目标而组合在一起管理的项目,项目集,子项目组合和运营工作
项目,项目集,项目组合使用相同的相关方和资源
运营管理:关注产品的持续生产和服务的持续运作。重点管理把各种输入转变为输出的过程
组织级项目管理(OPM):为实现战略目标而整合项目组合,项目集和项目管理与组织驱动因素的框架
五大过程组,十大知识领域
开发生命周期:预测型,迭代型,增量型,适应型,混合型(预测+适应)
项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束
阶段审查
项目发起人通常负责项目商业论证文件的制定和维护
项目经理负责提供建议和见解
需求评估结果可能会在商业论证文件中进行总结
项目效益管理计划描述了项目实现效益的方式和时间,以及指定的效益衡量机制
指定效益管理计划需要使用商业论证和需求评估中的数据和信息
项目章程是由项目发起人发布的,正式批准项目成立,授权项目经理动用组织资源开展项目活动的文件
投资回报率(ROI)>=0越高越好
内部收益率(IRR)>= 市场利率,越高越好
效益成本率(BCR)>= 1,越大越好,回收期越短越好
投资回收期(PBP)越小,说明项目的效益价值越高

项目运行环境

EEF:事业环境因素(组织内部或外部),项目不能控制的,对项目产生影响,限制或指令作用的各种条件
OPA:组织过程资产(企业内部)
项目治理:一致性,风险,绩效,沟通
项目治理是指用于指导管理活动的框架,功能和过程
管理要素是指组织内部关键职能部门或一般管理原则的组成部分
PMO:项目管理办公室

项目经理的角色

项目整合管理

项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别,定义,组合,统一和协调的各个过程

制定项目章程

编写一份正式批准项目并授权项目经理在项目活动中使用资源的文件的过程
项目章程是由项目启动者或发起人发布的,正式批准项目成立,授权项目经理使用组织资源开展项目活动的文件

制定项目管理计划

制定项目管理计划时,经常以头脑风暴的形式来收集与项目方法的创意和解决方案
WBS:工作分解结构

指导与管理项目工作

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作
对项目工作和可交付成果开展综合管理,以提高项目成功的可能性
CCB:变更控制委员会
PMIS:项目管理信息系统

管理项目知识

管理项目知识是使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程
利用已有的组织知识来创造或改进项目成功,并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段

监控项目工作

监控项目工作是跟踪,审查和报告整体项目进展
让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动,以及通过成本和进度预测,让相关方了解未来项目状态

实施整体变更控制

实施整体变更控制是审查所有变更请求,批准变更,管理对可交付成果,项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程
确保对项目中已记录在案的变更做综合评审

结束项目或阶段

存档项目或阶段信息,完成计划的工作,释放组织团队资源以展开新的工作

项目范围管理

项目范围管理包括确保项目做且制作所需的全部工作,以完成项目的各个过程
管理项目范围主要定义和控制那些工作应该包括在项目内,那些不应该包括在项目内

规范范围管理

记录如何定义,确认和控制项目范围及产品范围
在整个项目期间对如何管理范围提供指南和方向

收集需求

收集需求是为实现目标而确定,记录并管理相关方的需要和需求的过程
为定义产品范围和项目范围奠定基础,且仅开展一次或仅在项目的预定义点开展
访谈:通过与相关方直接交谈,来获取信息的正式或非正式的方法
焦点小组:召集预定的相关方和主题专家,了解他们对讨论的产品,服务或成果的期望和态度
亲和图:用来对大量创意进行分组的技术,以便进一步审查和分析
思维导图:头脑风暴中获得的创意整合成一张图
JAD:联合应用设计或开发
QFD:质量功能展开

定义范围

指定项目和产品详细描述的过程
描述产品,服务或成果的边界和验收标准

创建WBS

WBS:创建工作分解结构
把项目可交付成果和项目工作分解成较小,更易于管理的组件的过程
为索要交付的内容提供架构,仅开展一次或仅在项目的预定义点开展

确认范围

正式验收已完成的项目可交付成果的过程
使验收过程具有客观性,同时通过确认每个可交付成果,来提高最终产品,服务或成果获得验收的可能性

控制范围

监督项目和产品的范围状态,管理范围基准变更的过程
在整个项目期间保持对范围基准的维护,且需要在整个项目期间开展

项目进度管理

项目进度计划提供详尽的计划

规划进度管理

为规划,编制,管理,执行和控制项目进度而制定政策,程序和文档的过程
为如何在整个项目期间管理项目进度提供指南和方向

定义活动

识别和记录未完成项目可交付成果而必须采取的具体行动的过程
将工作包分解为进度活动,作为对项目工作进行进度估算,规划,执行,监督和控制的基础

排列活动顺序

识别和记录项目活动之间的关系的过程
定义工作之间的逻辑顺序,以便在既定的所有项目制约因素下获得最高的效率

估算活动持续时间

估算活动持续时间是根据资源估算的结果,估算完成单项活动所需工作时段数的过程
确定完成每个活动所需花费的时间量

指定进度计划

完成项目活动而制定具有计划日期的进度模型

控制进度

整个项目期间的保持对进度基准的维护,且需要在整个项目期间开展

项目成本管理

规划成本管理

在整个项目期间为如何管理项目成本提供指南和方向

估算成本

确定项目所需的资金

制定预算

确定可据以监督和控制项目绩效的成本基准

控制成本

监督项目状态,以更新项目成本和管理成本基准变更的过程
在整个项目期间保持对成本基准的维护

项目质量管理

规划质量管理

管理质量

控制质量

11 规划风险管理

定义如何实施项目风险管理活动的过程
确保风险管理的水平,方法和可见度与项目风险程度,以及项目对组织和其他相关方的重要程度相匹配

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值