PMP考试中经常出现,但容易混淆的一些内容,包含15个会议、40个分析、6个矩阵、5个清单、5个审计、5个报告、4个分解结构、4个评估、3个日志、3个登记册、2个日历等。
编号 | 会议名称 | 召开时间 | 目的和作用 | 参与者 |
---|---|---|---|---|
1 | 项目启动会 | 项目启动时 | 发布项目章程,任命项目经理,宣布项目开始 | 项目发起人及各相关方 |
2 | 项目开工会 | 计划完成后,执行开始前;如果是多阶段的项目,则每个阶段开始执行前都应该开一次 | 团队对项目或阶段的目标、范围等达成一致 | 项目团队 |
3 | 焦点小组会议 | 识别需求、风险时 | 了解相关方和主题专家对产品、服务或成果的期望和态度 | 特定的相关方和主题专家 |
4 | 引导式研讨会 | 识别需求、风险时 | 跨职能、跨专业会商项目需求 | 各专业、各职能专家及代表 |
5 | 头脑风暴会议 | 识别需求、风险和产生创意时 | 集思广益、互相启发 | 项目团队及外部专家 |
6 | 投标人会议 | 投标之前 | 澄清招标文件的内容,公示招标过程合规 | 买方及所有报名且具备投标资格的卖方 |
7 | 变更控制会 | 影响基准的变更决策时 | 审查变更请求,做出变更、否决或推迟的决策 | CCB成员 |
8 | 联合应用设计或开发(JAD会议) | 收集需求、改进方案时 | 收集需求、改进软件开发过程 | 业务主题专家、开发团队 |
9 | 风险研讨会 | 识别风险时和进行风险定性分析时 | 风险定性分析,审查已识别风险,评估概率和影响,对风险进行分类和优先级排序,分配风险责任人 | 项目团队及风险专家 |
10 | 需求研讨会 | 识别、评审需求时 | 讨论和评审需求 | 项目团队、相关方及主题专家 |
11 | 项目规划会 | 编制计划时 | 编制各项计划 | 项目团队及主题专家 |
12 | Sprint计划会* | Sprint开始时 | 计划本次迭代要完成的工作内容和开发方案 | 开发团队、产品负责人、Scrum Master |
13 | Sprint评审会* | Sprint结束前 | 对本次迭代的交付成果进行评审 | 开发团队、产品负责人、Scrum Master |
14 | Sprint回顾会* | Sprint结束前 | 回顾本次迭代的开发过程,总结经验教训,讨论改进方案 | 开发团队、Scrum Master |
15 | 每日站会* | 每日固定时间 | 每位成员向团队分享昨日完成的工作和今日计划的工作,以及遇到的障碍和需要的支持 | 开发团队、Scrum Master |
编号 | 名称 | 含义 |
---|---|---|
1 | 商业分析 | 确定项目成果具有足够商业价值的活动 |
2 | 定性风险分析 | 评估单个风险概率、影响和优先级排序 |
3 | 定量风险分析 | 单个项目对项目目标影响的定量评估 |
4 | 储备分析 | 为项目工期、成本或资金需求设定储备的技术 |
5 | 蒙特卡洛分析 | 模拟风险发生的各种组合来评估其对项目的影响 |
6 | 敏感性分析 | 确定影响项目目标的各种因素的敏感性顺序 |
7 | 根本原因分析 | 确定引起偏差、缺陷或风险的根本原因的技术 |
8 | 相关方分析 | 通过收集和分析相关方信息来确定项目中应该考虑哪些相关方的利益及其影响的技术 |
9 | SWOT分析 | 对项目的优势、劣势、机会和威胁逐个检查 |
10 | 技术绩效分析 | 将项目执行取得的技术成果与及计划进行比较 |
11 | 趋势分析 | 根据以往结果,预测未来绩效 |
12 | 形势分析 | 商业论证中对机会、风险和目标的评估 |
13 | 回归分析 | 分析项目结果的不同变量之间的关系 |
14 | 需求分析 | 对需求的必要性、优先级等指标进行评估 |
15 | 偏差分析 | 成本偏差、进度偏差和完工偏差的原因、影响和纠正措施 |
16 | 备选方案分析 | 多角度评估多个备选方案中哪个是最合适的 |
17 | 假设情景分析 | 对各种情景进行评估,预测他们对项目目标的影响 |
18 | 假设条件和制约因素分析 | 探索假设条件和制约因素的有效性,确定哪些会引发项目风险 |
19 | 成本效益分析 | 用来对照项目成本与其带来的收益的财务分析工具 |
20 | 决策树分析 | 评估与一个决策相关的多个可选方案在不确定情形下可能出现的后果 |
21 | 产品分析 | 对产品的用途、特征等方面的描述 |
22 | 文件分析 | 评估现有的文件,以获取需求、风险和经验教训 |
23 | 挣值分析 | 将实际进度和成本绩效与绩效测量基准进行比较 |
24 | 自制或外购分析 | 用于内部制造或外部采购决策的技术 |
25 | 租赁或购买分析 | 决定项目所需设备应该租赁还是购买的分析技术 |
26 | 过程分析 | 识别过程改进机会,检查过程中遇到的问题 |
27 | 多标准决策分析 | 对多个方案进行多项标准打分,按总分选择最优方案 |
28 | 数据分析 | 组织、评估和评价数据与信息的技术 |
29 | 价值分析 | 确定产品功能或组件对最终客户(用户)的价值 |
30 | 关键性分析 | 确定风险模型的哪些活动对项目关键路径的影响最大 |
31 | 相关方映射分析 | 用不同的方法对相关方进行分类的方法 |
32 | 供方选择分析 | 根据必要性确定合适的供方选择方法,降低供方不必要的前期投入 |
33 | 进度网络分析 | 利用网络图推导关键路径,从而优化进度、优化资源等 |
34 | 投资回报率分析 | 对项目未来年化收益与投资额的比值进行分析和评价 |
35 | 现金流贴现分析 | 项目现金流贴现后的资金价值分析 |
36 | 投资回收期分析 | 推导项目累计净现金流为零的时刻,即收回投资的时间 |
37 | 沟通需求分析 | 确定相关方获取信息的范围、方式和频率 |
38 | 故障分析 | 分析故障机理、模式、概率、影响和发展变化的规律 |
39 | 核对单分析 | 用清单来审核材料的准确性及完整性的一种技术 |
40 | 系统分析 | 以系统整体运行最优为目标,对系统的各个方面进行定性和定量分析 |
编号 | 名称 | 含义 |
---|---|---|
1 | 概率和影响矩阵 | 每个风险分别从概率和影响两个维度评分,以分配最优先级的表格 |
2 | 相关方参与度评估矩阵 | 相关方当前的参与水平与期望的参与水平的比较表格 |
3 | 责任分配矩阵(RAM) | 展示资源在各个工作包中的任务分配的表格 |
4 | 需求跟踪矩阵 | 从需求来源链接到相应可交付成果的表格 |
5 | RACI矩阵 | 反映每项活动与每位团队成员之间关系的表格 |
6 | 决策矩阵 | 在多标准决策分析中,对各标准打分排序的表格 |
编号 | 名称 | 含义 |
---|---|---|
1 | 活动清单 | 记录活动描述、标识及工作范围的表格 |
2 | 里程碑清单 | 列出项目所有里程碑的表格 |
3 | 提示清单 | 记录已识别的单个项目风险的详细信息的表格 |
4 | 预审合格的卖方清单 | 记录已经通过资格审查的所有潜在卖方的表格 |
5 | 观察清单 | 记录所有低优先级的威胁和机会,并需要定期维护的表格 |
编号 | 名称 | 含义 |
---|---|---|
1 | 质量审计 | 确定质量管理活动是否遵循了政策、过程和程序 |
2 | 风险审计 | 评估风险管理过程是否有效 |
3 | 采购审计 | 对合同和采购过程的完整性、正确性和有效性进行审查 |
4 | 配置项核实与审计 | 确保配置项组成的正确性,以及变更都被登记、评估、批准、跟踪和正确实施,确保配置文件规定的功能要求都已实现 |
5 | 项目终期审计 | 项目收尾过程中对项目管理过程的合规性进行审查 |
编号 | 名称 | 含义 |
---|---|---|
1 | 质量报告 | 关于质量管理问题、纠正措施建议及质量控制活动中的其他情况的报告 |
2 | 风险报告 | 概述单个项目风险的情况和整体项目风险程度的报告 |
3 | 工作绩效报告 | 为制定决策、采取行动或引起关注而将工作绩效信息汇编所形成的文件 |
4 | 可行性研究报告 | 对项目的技术、经济、市场等方面的可行性进行研究论证,证明项目可以投资的报告 |
5 | 项目报告 | 按沟通计划向相关方发送项目信息的报告 |
编号 | 名称 | 含义 |
---|---|---|
1 | 组织分解结构(OBS) | 项目活动与组织单元之间关系的层级描述 |
2 | 工作分解结构(WBS) | 项目需要实施的全部工作范围的层级分解 |
3 | 资源分解结构(RBS) | 项目所需资源按类别展示的层级结构 |
4 | 风险分解结构(RBS) | 潜在风险来源的层级展示 |
编号 | 名称 | 含义 |
---|---|---|
1 | 风险数据质量评估 | 评估风险数据对风险管理有用程度的技术 |
2 | 风险概率与影响评估 | 为单个风险的概率及其对项目的影响打分,并排序优先级的技术 |
3 | 沟通风格评估 | 识别与相关方沟通的优选方法、形式和内容的技术 |
4 | 个人和团队评估 | 项目经理和项目团队洞察成员的优势和劣势,评估团队成员的偏好、愿望,评估团队成员如何处理和整理信息,如何制定决策,以及如何与他人打交道的技术 |
编号 | 名称 | 含义 |
---|---|---|
1 | 问题日志 | 记录和跟进所有问题的文件 |
2 | 假设日志 | 记录所有假设条件和制约因素的文件 |
3 | 变更日志 | 记录项目变更及项目当前状态的综合清单 |
编号 | 名称 | 含义 |
---|---|---|
1 | 经验教训登记册 | 记录在项目中所获知识的项目文件 |
2 | 相关方登记册 | 记录相关方对结果进行识别、评估和分类的项目文件 |
3 | 风险登记册 | 记录已识别的单个项目风险的详细信息 |
编号 | 名称 | 含义 |
---|---|---|
1 | 资源日历 | 展示具体某个资源可以参与项目工作的时间的日历 |
2 | 项目日历 | 表明进度活动可用的工作日和工作班次的日历,比如每周工作5天还是6天,每天进行1班还是3班 |
制约因素是指对项目或过程的执行有影响的限制性因素。
假设条件是指在制定计划时,不需验证即可视为正确、真实或确定的因素。
两者最大的区别是:制约因素是确定的、客观存在的,而假设条件是当前不能确定的。制约因素和假设条件都存在于项目范围说明书中,并作为范围基准的一部分,是定义活动、估算活动持续时间、制定进度计划、估算成本、制定预算、识别风险和规划采购管理等多个过程的输入。
PMBOK认为“标准”是一种描述既定规范、方法、过程和做法的正式文件。
“制度”则是企业或组织根据自身实践和生产的需要,制定的一系列行为、工作规范,是强制性的。
因此,标准是非强制的、可选择的,号召力来自“标准”所发布的结构,如PMI、ISO等。而制度一般指要求大家共同遵守的办事规程或行动准则。
组织过程资产和事业环境因素各有其特点,主要根据其中两条来区分:
第一,是组织内部的还是外部的。如果是外部的,肯定是事业环境因素,如果是内部的,就要看第二条了。
第二、项目经理是否可以选择。有权选择用或不用的是组织过程资产,没有选择权的是事业环境因素。
提示:PMBOK中以“系统”结尾的词多是事业环境因素,以“程序”结尾的词多是组织过程资产。
产品导向过程就是项目所产生的产品的实现过程,不同产品有着不同的实现过程,一定程度上,项目的阶段划分其实就是产品的实现过程。
项目管理过程就是指5大过程组,无论什么项目,其项目管理过程都一样。
合同收尾:是在合同双方当事人按照合同的规定履行完各自的义务后,应该进行合同收尾工作。例如,如果卖方按合同要求适当的为特殊工程提供了原材料,那么合同可能在工程结束后才终止。项目组将与采购部门一起确保合同上的所有工作顺利完成,同时将收集关于提供商的信息。
行政收尾:是指对项目工作进行全面、系统和深入的回顾,进行完工后评价,考察“如果有机会重新做该项目可以如何改进”,把有关经验教训提炼出来并形成文档,并使它成为“组织过程资产”的一部分。
合同收尾与行政收尾的比较:
在项目的环境中,范围有两种含义:产品范围Product Scope和项目范围Project Scope。
产品范围是指项目产品应具有的功能,而项目范围是指为完成项目产品而必须做的工作。
要特别注意,只有产品的特性被清晰、准确地定义且被项目相关方正确理解,才能确定为提交产品而必须要做的工作,即项目范围。因此,产品范围决定项目范围,也只有项目范围实现了,产品范围才能实现。
产品范围是否完成,以产品需求作为衡量标准;项目范围是否完成,以项目管理计划为衡量标准。
需求:根据合同或其他正式的强制性规范,某个产品、服务或成果必须达到的条件或具备的能力。注意,需求除了具有强制性外,还必须是“量化”和“记录”的。
项目需求是项目需要满足的行动、过程或其他条件。
产品需求更多的从产品角度(技术、安全、性能)描述的需求。需求跟踪矩阵、引导式研讨会、群体创新技术、群体决策技术都是产品需求的工具或技术。
质量规划是确定标准和规划如何实现标准,强调的是建立标准,如何实现。实施质量保证属于执行过程组,是针对过程改进和审计的,关注与质量活动相关的政策、制度、流程和规范等,强调的是过程改进和信心保证。控制质量属于监控过程组,是按照质量要求,检查具体可交付成果的质量,针对的是项目活动或可交付成果的具体的质量问题、质量缺陷,发现并给与消除。
实施质量保证的对象更宏观,涉及制度、政策层面。如果涉及整体项目、正处于项目实施阶段,如果涉及经验教训的汲取或组织过程资产的更新,即正在做质量审计,如果涉及对项目质量标准的重新评价,以确认他们是否仍然使用就属于实施质量保证。
控制质量的对象更具体。如果涉及具体工作成果、正在监控阶段,如果涉及具体工作成果是否可以被接受、是否符合具体的质量标准就属于控制质量。
控制线是控制图中判断过程是否失控的上下界限,超过控制线,表明过程已失控。控制线是项目团队制定的。
规格线是判断产品或成果是否符合要求,是不合格品的分界线,超过规格线,表明产品不合格,规格线是合同(用户或客户)确定的。
控制线一般在规格线之内。对于重复性过程,控制上下限经常设置正负3个西格玛位置,其中一个西格玛代表一个标准差。
同类参数之间的推算就是类比估算,不同类参数之间的推算则是参数估算。
也就是说参数估算方法一定有成熟的数学模型或公式,通过套用公式,计算得出结果。类比估算的优点是耗费时间段、成本低,但估算的结果准确性较差,属于粗略估算。参数估算通常适用于简单重复性工作(如修路、搬砖),而不适用于脑力劳动和创造性劳动(如设计、咨询、新产品研发)
赶工,增加资源,以最小的成本增加来压缩进度工期的一种技术。赶工只适用于那些通过增加资源就能缩短持续时间的活动。
快速跟进,将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。它只适用于能够通过并行活动来缩短工期的情况。
镀金,指在定义范围的工作范围以外,项目团队主动增加的额外工作。
范围蔓延,未对时间、成本和资源做相应调整,未经控制的(未走正常的变更控制流程)产品或项目范围的扩大。
应急计划: 对已经发生的不利风险的应对。应急计划是事先安排的。
弹回计划:在风险发生并且主要应对措施无效时使用的计划。
权变措施:对已经发生的不利风险的应对。与应急计划不同的是,权变措施在风险发生之前并未事先安排
纠正措施:为使项目工作的未来期望绩效与项目管理计划保持一致,而对项目执行工作下达的书面指令。
预防措施:通过实施某项活动,来降低项目风险消极后果的发生概率的书面指令。
三个概念的相同之处:
都是审计的概念
都是特定知识领域的审计
三个概念的区别:
质量审计:执行过程组,实施质量保证的工具与技术
风险审计:监控过程组,监控风险的工具与技术
采购审计:收尾过程组,结束采购的工具与技术
三个概念的内容不同
质量审计:质量审计是一种独立的结构化审查,用来确定项目活动是否遵循了组织和项目的政策、过程与程序。质量审计的目标是:识别正在实施的良好做法、最佳实践;识别全部差距、不足;分享所在组织和/或行业中类似项目的良好实践;积极主动提供协助,改进过程的执行,从而帮助团队提高生产效率;强调每次审计都应对组织经验教训的积累做出贡献。质量审计还可确认已批准的变更请求的实施情况。
风险审计:通过风险审计,检查并记录风险应对措施在处理已识别风险及其根源方面的有效性,以及风险管理过程的有效性。项目经理要确保按项目风险管理计划规定的频率来实施风险审计。既可以在日常项目审查会中进行风险审计,也可单独召开风险审计会议。在实施审计前要明确定义审计的格式和目标。
采购审计:指对从规划采购到管理采购过程的所有采购过程进行结构化审查。其目的是找出可供本项目其他采购合同或执行组织内其他项目借鉴的成功经验与失败教训。
二个概念的相同之处:
都是与绩效评价有关的概念
都属于项目人力资源管理知识领域
二个概念的区别:
虽然二个概念都与绩效评价有关,但一个是过程的结果(输出),一个是工具与技术
团队绩效评价:建设项目团队的输出
项目绩效评估:管理项目团队的工具与技术
二个概念内容不同:
团队绩效评价:随着项目团队建设工作的开展,项目管理团队应该对项目团队的有效性进行正式或非正式评价。有效的团队建设策略和活动可以提高团队绩效,从而提高实现项目目标的可能性,根据项目的技术成功度、项目进度绩效和成本绩效来评价团队绩效,以任务和结果为导向,并且项目结果完全符合要求,这是高效团队的特征,高效团队也会展示出一些与工作过程和人际关系相关的特征,可据此间接考核项目绩效。评价团队有效性指标可包括:个人技能的改进,从而使团队更有效的完成工作任务;团队能力的改进,从而使团队整体工作的更好;团队成员离职率的降低;团队凝聚力的加强,从而使团队成员开放的分享信息和经验,并互相帮助,来提高项目绩效。
项目绩效评估:在项目过程中进行绩效评估的目的包括:澄清角色与职责,向团队成员提供建设性反馈,发现未知或未决问题,制定个人培训计划,以及确立未来各时期的具体目标。
二个概念的相同之处:
都是与沟通有关的概念
都属于项目沟通管理知识领域
二个概念的区别:
分属于不同过程的工具与技术
沟通技术:规划沟通过程的工具与技术
沟通方法:规划沟通、发布信息、管理干系人期望、报告绩效过程的工具与技术。
二个概念的内容不同:
沟通技术:可以采用各种方法在项目关系人之间传递。从尖端的谈话到长时间的会议,从简单的书面文件到可在线查询的资料,都是项目团队可以使用的沟通方法。可能影响项目的因素包括:信息需求的紧迫性;可用技术;预期的项目人员配备;项目的持续时间;项目环境。
沟通方法:可使用多种沟通方法,在项目干系人之间共享信息,这些方法可以大致归类为:交互式沟通;推式沟通;拉式沟通。
个别会谈、集体会议、视频会议、电话会议、计算聊天和其他远程沟通方法都可用于发布信息。
应该使用在沟通管理计划中为每个干系人规定的沟通方法。
项目经理通常使用推式沟通技术来发布绩效报告。
二个概念的相同之处:
都涉及备选方案
都是工具与技术
二个概念区别:
分属于不同过程
备选方案识别:定义范围过程的工具与技术
备选方案分析:估算活动资源过程的工具与技术
二个概念内容不同:
备选方案识别:备选方案识别是用来为项目工作提出不同执行方法的一种技术。许多通用管理技术都可用于备选方案识别,如头脑风暴,横向思维和配对比较等。
备选方案分析(144页):很多活动都有若干种可选的实施方案,如使用能力或技能水平不同的资源,使用不同规模或类型的机器,使用不同的工具(手动或自动化),以及决定是自制还是购买相关资源。
别名:核对表
属性:数据收集
隶属过程组:制定项目管理计划/管理质量/控制质量/识别风险
使用场景:一种结构化工具,通常列出特定组成部分,用来核实所要求的一系列步骤是否已得到执行或检查需求列表是否已得到满足,用作提醒
气泡图
别名:计数表
属性:数据收集
隶属过程组:控制质量
使用情景:用于合理排列各种事项,以便有效地收集关于潜在质量问题的有用数据。在开展检查以识别缺陷时,用核查表收集属性数据就特别方便,例如关于缺陷数量 或后果的数据
参考图例:
属性:数据表现
隶属过程组:管理质量/控制质量
使用情景:二八法则,是一种特殊的垂直条形图,用于识别造成大多数问题的少数重要原因。是一种按发生频率排序的特殊直方图,显示每种已识别的原因分别导致了多少缺陷。排序的目的是为了有重点地采取纠正措施。项目团队首先要处理那些导致最多缺陷的原因。
参考图例:
别名:龙卷风图
属性:数据分析
隶属过程组:实施定量风险分析
使用情景:将项目结果的变化与定量风险分析模型中输入的变化建立关联,从而确定对项目结果产生最大潜在影响的单个项目风险或其他不确定性来源
参考图例:
别名:PDM/单代号网络图/活动节点图/AON
属性:工具技术
隶属过程组:排列活动顺序
使用场景:创建进度模型的一种技术,用节点表示活动,用一种或多种逻辑关系连接活动,以显示活动的实施顺序
参考图例:
别名:CPM
属性:工具技术
隶属过程组:制定进度计划/控制进度
使用情景:在进度模型中估算项目最短工期,确定逻辑网络路径的进度灵活性大小。这种进 度网络分析技术在不考虑任何资源限制的情况下,沿进度网络路径使用顺推与逆推法,计算出所有 活动的最早开始、最早结束、最晚开始和最晚法完成日期
参考图例:
属性:工具技术
隶属过程组:制定进度计划/控制进度
使用场景-资源平衡:为了在资源需求与资源供给之间取得平衡,根据资源制约因素对开始日期和完成日 期进行调整的一种技术。
使用场景-资源平滑:对进度模型中的活动进行调整,从而使项目资源需求不超过预定的资源限制的一种技术。
参考图例(资源平衡):
属性:工具技术
隶属过程组:制定进度计划/控制进度
使用场景-赶工:通过增加资源,以最小的成本代价来压缩进度工期的一种技术。
使用场景-快速跟进:一种进度压缩技术,将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展
参考图例: