项目管理PMP--管理过程绩效域
2023-10-20 16:34:40 0 举报AI智能生成
主要包含项目管理--过程绩效域所有内容
作者其他创作
大纲/内容
管理过程绩效域
做项目首先选择一个开发方法
开发方法和生命周期
预测型/瀑布型
一次性交付
迭代型
多次迭代，一次交付
可以有多次迭代，不断优化，研究，最终交付一个产品
增量型
多次交付
快速。对已经确定的需求，限制变更
适应型或者敏捷
定期交付
快速。对已经确定的需求也可以变更
混合型
定期交付
做计划
规划绩效域
预测计划
项目管理计划在审核通过后才可以去落地实施
适应性计划
基于产品的适应性计划是分层次的，层次分为：愿景，产品路线图，发布计划，迭代计划，每天的站会
计划的变更控制
预测型项目生命周期计划的改变，一定要经过CCB。在适应型生命周期中，针对迭代/冲刺计划的改变的审批和最终确认的责任人是产品负责人
规划的变量
项目交付所需的开发方法
估算
进度
沟通
项目团队的组成和结构
预算
实物资源
采购
测量指标
制定项目章程
通过访谈收集相关方的高层级的需求
通常相关方来自不同职能部门，需求不一致，需要引导达成一致
确保项目章程的目标与商业论证中的战略目标保持一致
PM可以编写项目章程，最后通常需要得到发起人的签字批准
发起人对章程内容做决策，章程的变更直接找发起人协商
项目章程内容
项目的目的和可测量的目标
项目各阶段的目的和符合SMART原则的目标
项目成功的标准
衡量项目成功的标准
项目的退出标准
在何种条件下才能关闭或者取消项目或者阶段
高层级的信息
需求，边界定义，主要可交付成果，风险，预算，工期，相关方等，是一个大杂烩
项目经理及职责
委派项目经理和其职责权限
审批信息
发起人或者其他批准项目章程的人员姓名和职权
交付
进行规划时，首先要了解商业论证，干系人需求以及项目和产品范围
产品范围是某项产品、服务或结果所具有的特性和功能
项目范围是为交付具有规定也行和功能的产品、服务或者结果而必须完成的工作
预测型规划方法从高层级项目可交付物开始，并将他们进行分解，这种方法可以使用范围说明书或工作分解结构将范围分解为更低层级的详细内容
使用迭代方法或增量方法的项目，可以包含高层级的主题或史诗故事，这些主题或者故事会分解为各种特性，然后这些特性会进一步分解为用户故事和其他代办事项列表，并进行优先级排序，项目团队会根据负责最后责任时刻这一概念规划日常工作
预测型项目范围规划
- 规划范围管理
范围管理计划
如何做好跟项目范围相关的一系列工作
描述将如何定义、制定、监督、控制和确认项目范围。
不包含具体需求，所以如果客户加需求，也不用修改此文件
描述将如何定义、制定、监督、控制和确认项目范围。
不包含具体需求，所以如果客户加需求，也不用修改此文件
制定项目范围说明书
描述如何制定项目范围说明书，包括任何备选方案分析或相关方访谈等手段描述
WBS
描述WBS层级或表格结构，比如分不同的项目阶段，区域和主要可交付成果等
WBS词典
识别需要WBS词典中注明的内容和详细水平
范围基准维护
注明需要走变更控制过程的范围变更的类型，以及如何维护范围基准
范围变更
描述如何管理范围变更
可交付成果验收
对每个可交付成果要识别如何被确认，包括需要签收的任何测试或者文档
范围和需求整合
描述如何确定所需收集的需求类型，以及在项目范围说明书和WBS中项目和产品需求将如何整合等相关议题
需求管理计划
如何管理跟项目需求相关的一系列工作
需求收集
规定收集需求过程的工作流程和方法。如访谈法，观察法，头脑风暴等
需求分析
描述如何分析需求以及需求分类或者排序对产品或者项目实施的影响
需求分类
识别对一组需求进行分类的方法
需求记录
定义需求如何被记录的。需求文件的格式可以是从简单的电子表格到包含详细说明和附件的详细表格
需求排序
识别对需求排序的方法，如MoSCoW理论
需求测量指标
需求的验收标准，比如100%的必需功能完成，用户得最终测试并通过
需求跟踪矩阵
识别用于连接初始需求到满意的可交付物之间的信息
需求跟踪
描述追踪需求所需的频率和技术
- 收集需求
需求文件
需求跟踪矩阵
定义范围
项目范围说明书
收集需求太多，定义范围
产品范围，描述各个功能特性
项目范围
可交付成果
验收标准
除外责任
假设条件：不确定性就是风险
制约因素，也属于一种风险
创建WBS
把项目可交付成果和项目工作分解成较小、易于管理的组件
分解对象
成果（产品范围）
工作（项目范围）
分解原则
自上而下
滚动式规划
全员参与
100%原则
确定责任人
WBS组成部分
工作包：WBS最底层的组件
控制账户，进行项目进度控制和成本控制的管理控制节点，与挣值相比较，以测量绩效
规划包，WBS中内容已知，进度未知的组件
WBS词典
工作描述
资源需求
验收标准
质量要求
进度活动
成本估算
估算
规划需要对工作投入、持续时间的评估
预测型进度规划
规划进度管理
搞一个子计划
得到进度管理计划
定义活动
利用范围基准，将最小的工作包再拆分成更小的活动。
活动清单、活动属性、里程碑清单
活动清单、活动属性、里程碑清单
排列活动顺序
估算活动持续时间
类比估算
综合利用历史信息和专家判断，粗略数量级估算，
用于项目早期阶段，成本较低，耗时较少但准确性较低
用于项目早期阶段，成本较低，耗时较少但准确性较低
参数估算
利用历史数据和其他变量；确定性估算，通过表格/模型公式计算；
准确性取决于参数模型成熟度和基础数据可靠性
准确性取决于参数模型成熟度和基础数据可靠性
自上而下估算
自上而下分解再汇总，最准确；当估算缺乏可信度时使用；
成本高，耗时长；准确性取决于较低层次的工作规模和复杂程度
成本高，耗时长；准确性取决于较低层次的工作规模和复杂程度
三点估算
三角分布，贝塔分布；概率值，需要考虑风险；
计算出来的时间存在可能性，考虑风险影响
计算出来的时间存在可能性，考虑风险影响
预测型项目制定进度计划
得到甘特图
储备分析
在进行持续时间估算时，需要考虑应急储备（时间储备/缓冲时间），
并将其纳入到项目进度计划中，用来应对进度方面的不确定性
并将其纳入到项目进度计划中，用来应对进度方面的不确定性
应急储备
包含在进度基准中的一段持续时间，应对已识别的风险。
考核绩效
考核绩效
管理储备
为管理控制的而特别留出的时间，应对项目范围中不可预见的工作。
管理储备用来应对会影响项目的未知-未知风险。
管理储备不包括在进度基准中，不考核绩效，但属于项目总持续时间的一部分
管理储备用来应对会影响项目的未知-未知风险。
管理储备不包括在进度基准中，不考核绩效，但属于项目总持续时间的一部分
关键路径法
关键路径是项目中时间最长的活动顺序，决定着可能的项目最短工期
关键路径不考虑任何资源限制，只考虑最有可能的时间
在进度计划的优化或者项目实施过程中，关键路径可能发生变化
关键路径的总浮动时间通常为0
关键路径可以多条，关键路径越多，风险越大，就越难管理
资源优化法
资源平衡
以受限资源为考虑因素进行平衡。有可能改变关键路径
资源平滑
资源在非关键路径调整，防止资源忽高忽低，保持平稳。不改变关键路径
进度压缩
赶工
批准加班、增加额外资源
不改变活动时间的逻辑关系
增加资源，以加快工作进度
用资源换时间，成本上升
快速跟进
正常情况下按顺序进行的活动或者阶段改为至少部分并行开展
调整活动顺序，风险增加
预测型项目成本规划
规划成本管理
搞一个子计划，如何进行成本管理计划
估算成本
成本估算、估算依据
制定成本
成本基准、项目资金需求
项目团队
规划项目团队时，首先要明确完成项目工作所需要的技能组合
使用内部项目团队成员与获取组织外部人员的成本结构各不相同，对外部人员技能给项目带来的收益与其将会产生的成本进行平衡
在针对项目团队进行规划时，PM会考虑项目团队在同一地点开展工作的能力和必要性。一些项目团队的成员在不同的地点，
通过虚拟方式开展工作，需要花费更多时间通过技术手段将人们连接起来
通过虚拟方式开展工作，需要花费更多时间通过技术手段将人们连接起来
项目团队角色与职责
可以采用等多种格式来记录团队成员角色与职责
层级结构（OBS）
与WBS交叉，确认部门的全部项目职责
OBS（组织分解结构）
矩阵结构
显示工作包或活动与项目团队成员之间的关系，明确划分角色和期望特别有用
RACI（责任分配矩阵）
每个工作包都由以为明确的责任人负责：A类型
团队成员对自己的 角色有足够了解
将团队成员和角色联系起来
文字描述形式
提供诸如职责、职权、能力和资格等方面信息
资源管理计划
识别资源
用于识别和量化项目多需要的团队和实物资源的方法
获取资源
关于如何获取项目所需要的团队的和实物资源的指南
角色与职责
角色、职权、职责、能力
项目团队资源管理
如何定义、配备、管理和最终遣散项目团队资源的指南
项目组织图
项目组织图以图形方式展示项目团队成员及其报告关系
培训
针对成员的培训策略
团队建设
建设项目团队的方法
资源控制
确保实物资源充足可用、为项目需求优化实物资源采购
认可计划
将给与团队成员哪些认可和奖励，以及及时给予
团队章程
团队共识
沟通/会议指南
团队价值观
冲突处理过程
决策标准和过程
估算活动资源
估算活动资源，明确完成项目所需的资源种类、数量和特性，以形成资源需求和资源分解结构
横向是资源类型，纵向是类别的分解结构图
资源需求识别了各个工作包或工作包中每个活动所需的资源类型和数量，可以汇总这些需求，
以估算每个工作包、每个WBS分支以及整个项目所需要的资源
以估算每个工作包、每个WBS分支以及整个项目所需要的资源
沟通需求分析
重视干系人的沟通需求，分析沟通需求，确定干系人的信息需求，包括格式，内容等
沟通技术
信息交换和协作的常见方法包括对话，会议，书面文件，数据库，社交媒体和网站
沟通模型
有来有回的
沟通方法
交互式
推式沟通
受时区影响，邮件等
拉式沟通
信息大，受众多。网站等
沟通风格与文化意识
沟通风格评估
评估沟通风格并识别偏好的沟通方法。形式和内容的一种技术。
常用于不支持项目的干系人
常用于不支持项目的干系人
文化意识
沟通，文化一般是一起存在的
规划沟通管理
分析干系人沟通需求，确定相关方的信息需求
确定项目干系人的沟通技术
沟通管理计划是项目管理计划的一部分
采购
分析是自制还是外购
内/外部实施的可交付物和服务会影响项目团队和进度计划
质量
识别项目以及可交付成果的质量要求和标准，并书面描述如何证明符合这些标准
为在整个项目期间如何管理和核实质量提供指南和方向
为促进频繁的增量交付，敏捷方法关注于小批量工作
风险
风险
项目风险管理的目标在于提高正面风险（机会）的概率或影响，降低负面风险（威胁），从而提高成功可能性
每个项目都在两个层面存在风险。一是每个项目都有影响项目达成目标的单个风险。以及由单个项目风险和不确定性分其他
来源联合导致的整体项目风险
来源联合导致的整体项目风险
在敏捷或适应型项目环境中，通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理。
所以一般高风险项目更适合采用敏捷，可以在不断交付过程中识别并管理风险
所以一般高风险项目更适合采用敏捷，可以在不断交付过程中识别并管理风险
风险临界值
风险偏好，为了预期回报，能承受的不确定性的程度
风险承受能力
风险临界值（敝口）
风险概率影响的定义
定义风险的概率和影响，多大的概率叫高风险，多大的影响等
得到一个风险概率影响矩阵
通过计算风险的概率在矩阵中的位置，来进行排序
RBS（风险分解结构）
识别风险
已知--已知
已识别，可主动管理（规避，减轻，转移，提高，分享），规划应对措施
如何应对：规划应对措施
已知--未知
已识别，无法主动管理（主动接受）
如何应对：应急计划、应急储备
未知--未知
未识别（被动接受）
如何应对：权更措施、管理储备
规划干系人管理
干系人管理
分析干系人，管理策略，适合小型项目
凸显模型：适用于大型项目和复杂的人际关系
记录干系人登记册
记录干系人/相关方
干系人参与
干系人管理、分析、分类。拍优先级后，出一个子计划规划干系人参与
干系人参与评估矩阵
包含干系人的参与程度，参与情况。
评估干系人的态度，支持，反对，中立，领导等。
然后进行沟通
评估干系人的态度，支持，反对，中立，领导等。
然后进行沟通
规划干系人参与
干系人参与计划重点是关注干系人对项目的态度。
前面沟通管理计划重点是信息的传递
前面沟通管理计划重点是信息的传递
变更管理计划
变更的相关知识
变更控制流程
重新确定待办事项列表的优先级顺序
具有合同要素的项目可能需要遵循已定义的合同变更流程
变更请求
变更请求是关于修改任何文档、可交付成果或基准的正式提议。
项目的任何相关方都可以提出变更请求。
项目的任何相关方都可以提出变更请求。
预防措施
确保项目工作的未来绩效符合项目管理计划，而进行的有目的活动
纠正措施
为使项目的工作绩重新与项目管理计划一致。当出现问题了时
缺陷补救
为了修正不一致产品或组件而进行的有目的的活动
更新
对正式受控的项目文件或者计划等进行的变更。
以反映修改或者增加的意见和内容
以反映修改或者增加的意见和内容
变更控制
由PM最终负责
贯穿始终，最终由PM负责
一旦确定项目基准，就必须通过变更控制流程来处理变更请求
在基准确定之前，变更无需正式受控于变更控制流程
所有变更过请求都必须以书面形式记录在变更日志中。
并纳入到变更管理和配置管理系统中
并纳入到变更管理和配置管理系统中
记录在案的变更都必须有责任人批注或者否决，此人
通常是发起人或PM，在项目管理计划或组织流程中指定
通常是发起人或PM，在项目管理计划或组织流程中指定
涉及基准的变更，如范围、成本、进度等。由CCB来审批，不影响基准的变更，
可由项目经理审批
可由项目经理审批
变更控制流程
8个步骤
8个步骤
识别变更：提交变更请求
记录变更：以书面形式记录在变更日志
整体评估变更影响（和团队一起综合评估变更对项目的目标的影响）
考虑施加影响（有利的找审批人沟通，不利的找提出人沟通）
变更审批（pm自己审批/向ccb提交变更请求）
批准或否决变更（得到变更结果）
更新（否决，更新变更日志；批准，更新变更日志以及对应的额计划和文件）
通知相关方（变更提出人；如果批准还要通知项目团队和供应商）
配置管理计划
涉及到配置一般就有版本
识别配置项
记录并报告配置项报告
配置核实与审计
项目工作绩效域
项目工作主要功能
应用精益原则
以精益来履行日常工作
专注当下工作
持续学习和成长
相关概念定义
显性知识
隐性知识
问题
状态报告
每日站会
管理项目工作
管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程
借助项目管理信息系统开展项目工作，该系统集成了各个子系统、工具、资料库等
配置管理系统
变更控制系统
工作授权系统
系统收集与发布系统
范围、进度、质量、沟通管理工具
知识库
经验库
当完成某一过程、阶段或者项目时，将产出任何独特可核实的产品、结果或服务
执行项目工作过程中，从每个正在执行的活动中收集工作绩效数据（原始观察结果和测量值），
再交由控制过程做进一步的偏差分析得到工作绩效信息，再交由项目经理进行整体监控得到工作绩效报告
再交由控制过程做进一步的偏差分析得到工作绩效信息，再交由项目经理进行整体监控得到工作绩效报告
工作绩效数据流
依次是执行过程、控制过程、整体项目控制
在整个项目生命周期中，使用问题日志记录项目遇到的问题、差距、不一致或意外冲突
如果在开展项目工作时发现问题，可提出变更请求，按照变更控制流程对项目政策或程序、项目或产品范围、项目成本
或预算、项目进度计划、项目或产品寄过的质量进行修改
或预算、项目进度计划、项目或产品寄过的质量进行修改
监控项目工作
监控项目中的工作
挣值分析
绩效如何
偏差分析
有没有不一致
根本原因分析
原因是什么
备选方案分析
都能如何解决
成本效益分析
怎么解决最好
趋势分析
未来如何？
工作绩效报告
基于以上开展工作中的各项分析个数据，得到周报。至少包含五个内容
汇总工作绩效信息，即汇总9个领域的信息
质量概述，主要集中在哪些领域
风险概述
解决方案
上面分析、质量、风险有偏差，针对这些偏差的解决方案是啥
未来绩效预测
质量审计
审计项目工作是否合规：是否按照组织规划开展活动
结合核对单进行审计
质量审计的目的：好的，不好的，好的分享，不好的改进，最后总结经验
问题解决
问题解决发现解决问题或挑战的解决方案
- 定义问题（评估对项目的影响，记录问题日志）
- 识别根本原因（因果图、鱼骨图、流程图、直方图）
- 生成可能的解决方案（备选方案分析）
成本效益分析
多标准决策分析
- 选择最佳解决方案
- 执行解决方案（提交变更请求）
明确责任人
- 验证解决方案的有效性（跟踪解决方案的有效性）
PDCA
计划--实施--检查--行动。
六西格玛是常用于分析和评估改进机会的两种质量改进工具
六西格玛是常用于分析和评估改进机会的两种质量改进工具
控制质量
测试、检查
核实项目可交付成果满足相关方的质量要求，可供最终验收
批准的变更请求的实施需要核实，并需要确定完整性、正确性以及是否重新测试
测试与检查结果记录在质量控制测试结果（测试报告）
针对实际测测量结果，比较和分析规划质量管理过程中定义的质量测量指标，以进行绩效审查
控制质量过程的一个目的就是确定可交付成果的正确性，开展控制质量过程的结果是核实可交付成果
如果控制质量过程期间出现了可能影响项目管理计划任何组成部分或者项目文件的变更，项目经理应该提交变更请求进行处理
核对单有助于以结构化方式管理控制质量活动
质量三部曲
质量三部曲
规划质量管理
质量管理计划
质量测量指标
管理质量（QA）
质量报告
测评文件
控制质量（QC）
核实的可交付成果
质量控制测量结果（测试报告）
维护基准
基准VS数据---绩效工作信息，并在必要时，提交变更。
确定偏移范围基准的原因和程度，并觉得是否需要采取纠正措施或预防措施
进度控制强调关键路径法，分析新关键路径，确定影响
资源优化。对活动和活动所需的资源进行规划
调整提前量与滞后量。
进度压缩，使进度落后的项目活动赶上计划
成本控制强调挣值分析、偏差分析、趋势分析、储备分析
挣值分析
EV
挣值（实现值）完成工作对应的预算费用
某个时间点截止，实际挣得钱
AC
实际成本：完成工作实际花费的成本
某个时间点截止，实际花的钱
PV
计划成本：计划完成工作的预算费用
某个时间点截止，计划应该完成的钱
BAC
项目完工预算
偏差分析
成本偏差（CV）
EV-AC
进度偏差（SV）
EV-PV
趋势分析
工期绩效指数（SPI）
EV / PV
成本绩效指数（CPI）
EV / AC
储备分析
工作绩效域的储备分析
储备分析来监督项目中应急储备和管理储备的使用情况，判断是否还需要，或者对否需要额外增加储备
已识别的风险没有发生，就可能要从项目预算中扣除未使用的应急储备
获取资源
预分派
多标准决策分析
人际关系（谈判）
虚拟团队
不同地理位置员工；沟通特别重要；成本、态度、能力、参与
资源日历
记录资源可用性
记录每个团队成员的工作时间段
必须考虑资源可用性和时间限制
规定了确定的团队和实物资源何时可用，可用多久
团队发展的5个阶段
形成
刚形成好奇，士气较高，相互认识
怀疑
震荡
磨合过程中，有冲突，不同观点和意见，不合作，不开放，士气降低
吵架
规范
PM站出来，成为教练，士气逐渐上升。协同工作，开始信任和写作
制度
成熟
成熟团队，士气高，稳定。相互依靠，平稳高效
互帮互助
解散
培训
团队培训
能力缺失，经验不足
新技术，新工具引入
提前做好培训评估，并将培训策略写入资源管理计划
不抛弃，不放弃原则
培训无果，和成员交谈，找原因，确定解决措施
团队环境
团队建设
可以面对面，也可以线上方式
认可和奖励
裁剪，满足某个需求的奖励；考虑文化差异；及时表扬
个人与团队评估
个人和团队评估工具让PM洞察成员优势和劣势
态度调查、细节评估、结构化面谈、能力测试、焦点小组
团队评价
技能提升；离职率降低
管理团队
冲突管理
沟通技能
监督沟通和参与
结合干系人管理六个步骤，是干系人监督应该怎么做。
干系人分析
干系人分类排序
记录干系人
干系人参与程度
调整沟通管理计划
采购
采购相关事宜
项目经理没有签订合同的权限
采购文件
信息邀请书、建议邀请书、报价邀请书、工作说明书、供方选择标准、独立成本估算
广告，发布采购信息
投标人会议：投标会议，公平公正
建议书评价
就是标书，甲方进行专家判断；筛选+加权
采购谈判
处理采购事宜
采购绩效审查
根据合同，审查卖方合同履约情况，对质量、资源、进度和成本绩效进行比较和分析，以审查合同工作的绩效，是否存在资源或质量问题
检查
对卖方的可交付成果进行检查
采购审计
审计是对采购过程的结构化审查。买卖双方都应该关注审计结果，以便对项目进行必要调整
有争议的索赔
处理方式优先是谈判（私了），再找第三方调解，最后不行才上诉
采购处理事宜
关于正式关闭采购要求，通常已在合同条款和条件中规定，并包括在采购管理计划中
卖方提供可交付成果，买方批准所有交付物，并结清款项
买方向卖方发出合同已完成的正式书面通知
采购审计，采购文档更新，总结经验并更新知识库，采购归档
预审合格的卖方清单更新
监督新工作和变更
监督新工作和变更
适应型项目中，根据需要将新工作增加到产品待办事项列表中，产品负责人会持续对项目待办事项列表进行优先级排序，以便完成优先级高的事项
在预测型项目中，项目团队会积极管理工作变更，以确保范围计划中仅包含已批准的变更。项目经理与变更控制委员会和变更的请求者合作，
通过变更控制流程指导变更请求
通过变更控制流程指导变更请求
整个项目期间的学习
分享
信息管理适应于显性分享，会议、人际关系适应于隐性知识分享
知识管理最重要的环节是营造相互信任的氛围
经验教训登记册在项目早期创建，记录经验教训。因此整个项目期间，可以作为很多项目工作的输入，也可以作为输出不断更新。
参与项目工作的个人和团队都参与记录经验教训
参与项目工作的个人和团队都参与记录经验教训
在项目或阶段结束时，吧相关信息归入到经验教训知识库，成为组织过程资产一部分
项目收尾
项目收尾工作
三个原则
完
项目经理需要审查范围基准，确保项目工作全部完成后才宣布项目结束
止
如果项目提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因
人
项目经理应该邀请所有合适的干系人参与
过程
项目收尾的过程
确认
正式验收，需要签字确认
移交
收尾问题可记录到最终报告/经验教训册/问题日志
更新
对收尾提出的变更，委婉拒绝
总结
收尾 不能委派，必须由项目经理带领团队完成
存档
产品移交后，由运营部门在产品生命周期中进行维护
庆功
按照沟通管理计划进行问卷调查，以收集客户满意度
解散
特殊文件，涉密文件，参考合同收尾
测量质量
测量
完成交付
交付
主要从三个维度看是否达成
范围定义：主要是范围是否满足
质量定义：主要是测试质量指标是否达成
价值定义：主要是收益、效益是否达成。根据收益实现计划、效益管理计划来
定义完成
一个检查清单
供客户使用，而必须达到所有准则的检查清单
价值交付
可在项目期间持续
可交付物
需求
和干系人一起开会收集需求；对于开始时的高层级需求，会随着项目时间变化
范围定义
范围分解：
完成可交付物
子主题
验收或完成的标准
验收标准：范围说明书；工作说明书
技术绩效测量指标
验收标准：WBS词典
完成的定义
验收标准：checklist
完成的目标不断移动
因为竞品有一个新功能，我们也要增加，所以我们的完成目标也会往后偏移。
确认范围
由发起人或者客户检查，检查指开展测量、审查等确认活动，来判断工作和可交付成果是否符合验收标准
对已完成但未通过正式验收的可交付成果及其未通过验收原因，应该记录在案。可能需要提出变更请求，开展缺陷补救
符合验收标准的可交付成果应该由客户或者发起人正式签字确认
要从客户或者发起人那获取正式验收文件，证明相关方对成果正式验收，必要时留有证据。
这些文件将提交给结束项目或阶段的过程
这些文件将提交给结束项目或阶段的过程
控制范围
范围镀金
团队成员自行添加功能
范围蔓延
客户提出需求，没有遵循变更控制系统，直接修改，没有进行变更的记录和跟踪。最后导致可交付物和范围定义中不一致，造成蔓延
需求评估
搞清楚业务目标/商业需要
基于前面的进行商业论证
把业务目标抄过来
有各种备选方案
成本效益分析方法得出的收益目标
0 条评论
下一页
