项目管理能力Word文件下载.docx
《项目管理能力Word文件下载.docx》由会员分享,可在线阅读,更多相关《项目管理能力Word文件下载.docx(42页珍藏版)》请在冰豆网上搜索。
1.对项目的关键路径上的任务进行
1.能详细的配置活动工作任务分
跟踪
解(WBS)
2.审查任何过程或产品的变更请求
2.基线创建时能识别出差异化需
报告
求
3.依据利益相关者介入承诺的变
1.审查设计、测试、代码与需求及
3.变更过程有清晰的评审和验证
更,调整WBS
其变更是否保持一致,并纠正错
动作,且变更相关的文档作必要的
4.项目总监定期对项目的风险管理
误
变更
进行审查
4.按照配置项的变更触发式的发
5.当关键路径上任务发生偏差时,
布配置状态报告
调整关键任务,重新生成关键路径
5.能项目配置活动作功能审计
图;
1.对发现的不合格项进行
分析1.项目组能识别出项目的关键任务路径图,决策
L52.项目总监负责协调处理
如何保证项目尽可能并行开展;
QA报告中不能或者无法
解决的不合格项
1.项目经理组织用户、其他管理人
员、供应商以及受影响的利益相关
者对活动和工作产品的完成情况共
L4
1.SOW中包含对客户原有系统的优缺点,公司
现有产品的强弱项;
2.依据WBS,进一步按月分解任务,制定周计
划
3.项目组成立估算小组,使用估算方法对工作量
和成本进行估算
3.项目组按周审查项目相关的风险
4.识别出项目在进度、工作量、资源方面的风险,
的应对情况,必要时调整风险参数、
在WBS里体现针对风险的应对解决任务;
应对措施,并在WBS中体现被调
5.在WBS里体现利益相关者介入的活动;
整的应对措施;
6.项目组执行培训活动,并进行培训评价;
4.采集下列问题,明显偏差的项目
同进行审查;
2.按月/周审查WBS中与利益相关
者介入有关的各任务、活动的进展
情况,及时调整WBS中与利益相
关者介入有关的各任务、活动中相
关内容;
1.项目相关组参与需求变更的评
估,并及时调整相关组的计划
2.审查项目计划与需求及其变更
是否保持一致,并纠正错误
3、用需求跟踪矩阵跟踪需求被功
能分解以及设计、测试的过程
略
2.项目对配置项进行分类和跟踪
3.在编码和测试阶段创建测试基
线
4.项目能依据变更控制流程进行
变更控制并有文档化记录
5.按照配置审计计划进行物理审
计
1.帮助项目组选择适合项
目的生命周期和作业过程
2.按照QA计划对项目作业
过程进行审计
3.在项目的生命周期阶段
进行项目阶段退出审计
1.项目中有文档化的配置管理策
计划参数、未得满足的内外承诺、
重大变化风险的状态、利益相关者
介入情况,分析问题并纠正。
1.项目组有指导项目活动的SOW,包括对客户
原有系统、公司现有产品的功能描述;
1.项目经理在项目例会中对活动和
工作产品的完成情况进行审查
L3
2.项目组根据SOW确定项目生命周期
3.项目建立WBS,覆盖生命周期各个阶段、子
阶段的活动
4.依据WBS进行任务的工作量、资源估算
5.识别出项目的风险,制定应对措施并进行跟踪
6.对WBS中所有任务的工作量、资源、进度的
承诺进行确认
7.识别出组间依赖关系
8.项目组识别所需业务、技术、质量过程的培训
需求,评估现有的技能水平,制定培训计划;
2.按月审查内部和外部的承诺
3.按照WBS中的项目里程碑点对
利益相关者的活动进行审查
4.项目组按生命周期阶段点审查项
目相关的风险的应对情况
5.在项目进度安排的里程碑点与相
关人员共同进行审查
6.采集测试、评审发现的问题,及
项目进度偏差值,分析并进行纠正;
2.对需求变更进行评估,并根据其
对除项目计划外其他工作产品的
影响及时调整工作产品,如设计、
代码、测试
2.能识别出项目活动中结果配置
项以及其变量部分
3.根据项目的生命周期规划出项
目的基线计划
2.按照QA计划对项目的工
作产品进行审核
3.审核问题文档化,并跟踪
其关闭
1.用需求跟踪矩阵跟踪需求的完1.项目有独立于项目计划的配置1.项目有独立于项目计划
整性管理计划的QA计划
L2
1.项目售前阶段有项目估算文档
2.项目组有实现系统的总体开发计划
1.有明确的需求受理的流程
对项目计划的影响及时调整项目
计划
1.项目组至少每周将代码更新到
配置服务器上
2.项目组有独立的配置管理系统
3.项目组能依据项目合同识别交
付产物
1.在客户里程碑点对项目进度/风险
1.项目组按照项目生命周期定期
和问题进行审查
1.与用户达成需求的共识
L11.项目有按照合同约定的里程碑计划
将代码和核心文档备份到公司配
2.按照客户里程碑点对进行情况进2.需求变更有记录
置库
行监督
KPA-PP(项目计划过程)KPA_PMC(项目监督与控制)KPA_REQM(需求管理)KPA-CM(配置管理)KPA-PPQA(质量保证)
2.项目计划过程
1.SOW的变化原因进行归
类总结
1.对项目生命周期的变化
原因进行归类总结
L71.度量SOW的变化量
1.度量项目生命周期的变
化量
3.度量对重计划时调整进度和任务方法和手段
1.度量从事编制SOW活动
所花费的工作量
1.度量策划和确定生命周
期所花费的工作量
1.度量从事项目计划所花费的工作量
2.度量重计划所花费的工作量
1.度量从事估算所花费的工作
2.估算活动的工作量、成本、进
度数据提交到PDB;
1.度量从事风险管
理活动所花费的
2.度量所识别的风
险数量
1.对软件工作产物的估计(需求
项目组能识别出项目的关键任务路径图点、功能点、类、对象、接口)
1.识别任务的相互关系,标示出任务之间的关2.对关键计算机资源的估计;
L53.对工作产物(文档)的估计(页
联,得到关键任务路径图;
2.分析关键路径上的任务,平衡资源,调整任务
数);
之间关系,尽量保证任务并行展开;
4.估算的所有修订及每次修订
的成本、进度和工作量变化;
制定项目工作任务分解(WBS)及进度计划,根
据项目的生命周期对项目的开发、工程实施等
活动进行任务分解
要求:
1.1.WBS
识别出项目在进依据的培训进度
1.SOW:
1.WBS中包括以下内容依据,进一步按月分解任务,制定周计
度、工作量、资源安排执行培训活动;
1.2.客户原有系统分析项目经理或部门经理划;
方面的风险;
1.项目组成立估算小组,根据估
1.12.2.用户原有系统优点和缺任务的资源分配项目组每个成员;
识别出项目在成
对项目组成员进行评价:
算方法[Delphi]法对工作量和
点
成本进行估算
2公司已经有产品的分析
3.叶子工作量不能大于16人时
4.一个人在一周的工作量不能大于60人时
本、性能相关的风
险;
培训目标;
个人技能的
提升;
2.1公司现有产品的强项和3.在WBS里体现3.文档化培训记录;
弱项获得实现计划的承诺:
针对风险的应对4.依据项目实际情况,调
1.根据需要,项目总监审查内部、外部的承诺;
解决任务;
整培训计划;
利益者相关活动:
1.在WBS里体现利益相关者介入的活动;
能根据项目建设目标和制定项目工作任务分解(WBS)及进度计划,根
1.识别出项目的风
1.SOW中包括以下内容:
1.识别出项目所需的知
客户要求确定项目的生据项目的生命周期对项目的开发、工程实施等险;
1.客户原有系统分析2.根据确定的风险
命周期:
活动进行任务分解识和技能,包括:
1.1客户原有系统基本信息1.研发项目明确开发阶段
参数定义评估风
业务、技术和质量过程
1.2原有系统的功能1.WBS覆盖生命周期各个阶段、子阶段的活动;
的生命周期,包括需求分险。
风险参数包方面
2公司已经有产品的分析2.根据项目的WBS重点活动:
1.依据WBS,项目经理估算活2.评估现有的可用的知
析、设计、代码、集成和括:
L32.1公司已经产品基本信息2.1汇编出顶层的WBS任务分解
验证等子阶段;
动、任务的工作量和成本;
识和技能,获取本项目组
概率、影响、优
2.2现有产品主要功能2.工程项目明确开发阶2.2根据顶层WBS进一步分解子活动、子任务;
2.评审估算活动产物
先级;
不具备的知识和技能;
3.系统建设目标2.3叶子工作量不能大于40人时;
3.根据规定的风险3.制定相应的技能培训
段、工程实施阶段的生命
3.1系统基本信息3.依据任务的估算工作量,识别约束条件,确定
周期类别对风险进行计划;
3.2功能描述2.1开发阶段包括:
需求4.在WBS里体现人员技
人力资源;
分类和分组,同时
3.3接口需求4.识别任务相互关系,确定任务的进度时间点;
分析、设计、代码、集成明确风险的因果能培训的活动;
和验证等子阶段5.识别主要里程碑点,包括:
完成的工作、提交
或先后关系;
2.2工程阶段包括:
上线、的交付件的时间点或事件点;
4.排列风险顺序,
维护、推广、初验、终验6.项目组约定了项目重新计划的准则和要求,包
确定风险对项目
等子阶段括:
的影响程度;
项目里程碑点或关键任务的进度偏差,累计5.每个风险中制定
工期偏差超过15天。
相应的应对措施
6.文档化识别的风
获得实现计划的承诺:
险;
1.项目组对项目计划进行评审,包括对WBS中7.和利益相关者审
所有任务的工作量、资源、进度进行确认;
查风险,并达成一
2.项目计划要得到项目总监、用户的确认;
致;
8.根据需要修订风
识别出利益相关小组险文件。
1.关键交付物
2.交付日期
1.在项目售前阶段,根据项目合
同的点对点应答/建议方案等做
项目进度和成本的估算[售前预
算]
合同附件:
点对点应答/建
议方案书
L1-如果是合同外服务,可以
是和用户的一些约定或者
原始
SOW生命周期项目计划估算风险管理技能提高
3.项目监督与控制
度量从事"
监督里程碑审查"
所度量从事"
问题分析&
纠正措施"
所花费的工
1.度量从事"
进展审查"
所花费的工作量1.度量从事"
监督风险"
所花费的工作量
2.度量从事"
监督参数"
所花费的工作量2.统计识别的风险数
花费的工作量作量
3.度量从事"
监督承诺"
问题数量、关闭数量
4.统计不能实现承诺的数量
监督计划参数:
当关键路径上的任务发生偏差时:
1.项目总监定期对项目的风险管理进行审
1.对项目的关键路径上的任务进行跟踪,包括:
1.1调整任务的工作量,重新分配资源;
查;
1.1跟踪任务的进度、工作量、资源;
1.2调整关键路径上与其相关联的任务的工2.项目经理定期对项目风险管理活动进行
2.对工作产品和任务的属性、关键计算机资源等进行跟
作量、资源、进度;
同时调整非关键路径上分析;
踪:
受影响的其他任务的工作量、资源、进度;
2.1工作产品和任务属性(如规模或复杂程度)及其变更;
1.3依据任务的调整,重新生成关键路径图;
2.2系统使用的资源(如计算机、网络、测试设备、软件
工程环境等);
L5
进展审查:
1.审查任何过程或产品的变更请求报告;
2.审查结果文档化;
3.跟踪变更请求,直到其关闭;
监督利益相关者:
1.依据利益相关者介入承诺的变更,调整WBS;
1.采集问题,以供分析,问题包括:
1.项目组按周审查项目相关的风险的应对
对工作产品和任务的资源、工作量以及进度等进行跟踪:
1.1计划中预算值有明显偏差的项目计划参
情况;
1.项目工作量和资源(包括:
项目加班情况、项目组人2.项目例会上主要针对进度、工作量和资
数,包括:
员流失)源等方面的风险设专题讨论;
项目进度、工作量、资源、项目所需的
2.项目需要的知识和技能;
3.分析风险参数,依据项目实际情况及时
知识和技能偏差值;
3.工作量、资源、知识和技能的偏离情况,并文档化。
1.2未得到满足的内部或外部承诺,包括:
调整参数;
WBS中的内部或外部承诺;
3.1风险评价;
1.3发现重大变化的风险状态;
3.2风险发生概率;
1.项目经理组织用户、其他管理人员、供应商以及受影1.4利益相关者的介入情况3.3风险优先顺序;
响的利益相关者对活动和工作产品的完成情况共同进行2.确定为处理所识别的问题而采取相应的纠4.依据项目实际情况及时调整风险应对措
审查;
正措施,纠正措施包括:
施,应对策略;
L42.1当项目工作范围或关键任务的工作量、5.在WBS中体现被调整的应对措施;
资源发生偏差时,进行重估算:
1.按月/周审查WBS中与利益相关者介入有关的各任务、
重新估算任务的工作量、资源
活动的进展情况;
2.2依据重估算的结果,调整项目关键任务
2.依据进展情况,跟踪、解决存在的问题;
的进度;
3.及时调整WBS中与利益相关者介入有关的各任务、活2.3重新确定项目风险;
动中相关内容;
2.4补充资源;
2.5重新商谈承诺;
2.6改变相应过程;
3.采取的措施与相关人共同审查并达成协
议;
4.协商有关内部和外部的承诺变化;
监督计划参数,对工作产品和任务的进度进行跟踪:
1.在项目进度安排的里程碑点1.采集问题,以供分析,问题包括:
1.项目组按生命周期阶段点审查项目相关
1.项目进展:
按照WBS中的进度;
1.1测试和评审活动中发现的问题;
与相关人员共同进行审查;
的风险的应对情况;
2.项目进展的偏离情况,并文档化2.审查该项目的承诺、计划、状1.2计划中预算值有明显偏差的项目计划参2.更新风险的状态;
L33.识别项目新的风险;
态以及风险;
数,包括:
监督承诺:
3.识别重大问题及其影响并将4.把风险状态通知受影响的各方;
项目进度偏差值
1.按月审查内部和外部的承诺,审查承诺包括:
2.确定为处理所识别的问题而采取相应的纠
其文档化;
1.1审查WBS中关键任务执行的承诺;
4.审查结果、为解决问题而采取
正措施,纠正措施包括:
1.2审查功能实现执行的承诺2.1修改相应的需求、设计等文档;
的各项行动以及各项决定文档
1.3审核接口实现任务执行的承诺2.2任务进度累计工期超过15天,重新修订
化;
1.4审核关键资源的承诺,如:
5.跟踪所采取的行动,直至结束WBS,调整任务的进度、资源;
人力资源等2.3对修订后的WBS进行评审;
2.识别那些没有得到满足的承诺或那些很可能得不到满3.与相关人共同审查采取的纠正措施并达成
足的承诺;
协议;
3.承诺审查的结果文档化
4.对发现的问题进行分析跟踪直到关闭
1.项目经理在项目例会中对活动和工作产品的完成情况
进行审查,并通报相关者;
相关者包括:
项目总监、项目成员、用户、其他管理
人员、受影响的利益相关者
2.重大偏差和重大问题文档化;
3.审查结果文档化;
4.跟踪问题报告,直到其关闭;
1.按照WBS中的项目里程碑点对利益相关者的活动进行
审查(组间协同人或者组织)
1.1第三方厂家
1.2主机,数据库等项目环境提供者
2.对发现的问题进行分析跟踪直到关闭
1.按照客户里程碑点对项目进
度/风险/问题/成本进行审核
2.对发现的问题跟踪并直到关
闭
3.在客户里程碑点对发现的问
L1
题进行分析并将记录文档化
4.根据问题分析的结果采取相
应的措施
-增加资源
-延长工期/增加工作量
-修改和用户的约定
进行进展审查里程碑审核分析问题&
纠正措施监督项目风险
4.需求管理过程
1.根据需求变更来源以及影响分析变更原
REQM_L8
因,同时改进项目需求管理方法
2.项目组将经验交付给组织便于需求管理
过程的改进
REQM_L72.公司产品规划
3.需求采集遗漏
REQM_L6
度量获取需求管理的工
1.度量管理需求变更所花费的工作量
2.度量需求变更的数量和类型
度量识别需求和工作产品不一
致花费的功工作
度量获取项目组承诺的工作量
度量维持需求双向可塑性的工作
1、审查设计、测试、代码的变
更是否和需求以及需求变更保REQM_L5
持一致,并及时纠正
1、用需求跟踪矩阵(或系统功能
REQM_L4
1、项目相关组(如集成组)参与对需求变
1、审查项目计划是否和需求以
更进行评估,并及时完成由此带来的对相
及需求变更是一致的,并及时
关组工作计划的调整纠正
说明书)覆盖用户需求被完整的
功能分解
2、用需求跟踪矩阵跟踪功能需求
被实现的过程(包括设计、测试、
代码)
1、项目组内部按照变更流程对需求变更做
REQM_L3
评估,并及时完成由此带来的设计、测试、
代码文档的调整,并对需求跟踪矩阵做更
1、用需求跟踪矩阵(或需求规格
书)覆盖完整的用户需求
新
1、项目组建立需求受理
RM_L2
机制,包括:
1)需求提供人
2)需求受理人
3)需求评估和接受的原
评估,并对影响度进行分析,并及时完成
由此带来的项目计划的调整
1、项目组内部按照变更流程对需求变
更做评估,评估对现有的承诺的影响,
如:
承诺的软件上线时间延迟,并对承
诺的变更,获得承诺双方达成的共识
则
RM_L1
1、双方对需求达成共识
1、文档化项目的需求及需求的变化
2、需求变更有记录
获得可理解的需求管理需求的变更
辨别需求和工作产品的不一致
性
建立对需求的承诺维持需求双向可溯性
5.配置管理过程
1.通过分析变更原
对配置审计问题进行分
因来了解需求/设
析
CM_L8
计等稳定度
2.通过对从事花费
1.对项目配置管理活动
变更工作量的分2.交付组织财富库
析对项目计划的3.对组织的配置过程进
影响行改进
1.对配置审计问题进行
分类
CM_L7
1.度量变更原因,
并对变更原因进
行分类
1.1物理审计发现的问
题
1.2功能审计发现的问
1.3配置管理问题
1.4相关者问题
1.定期度量变更相
关的数据
1.能对配置项的以下指
标度量
1.1申请变更数
1.2累计变更数
CM_L6
1.度量从事版本控制所花
费的工作量
2.度量从事版本控制所出
现的问题
1.按照配置管理活动的子活动度
量出子活动工作量
2.度量相关组配置管理的工作量
1.1.按照生命周期阶段
配置项数量
1.2.按照计划配置项交
付的延期率
1.度量基线创建的延迟率
2.度量从事基线创建所花费
的工作量
1.3批准变更数
1.4⋯⋯
2.度量从事变更控
制所花费的工作
度量从事配置状态报
告所花费的工作量
1.度量从事配置审计所
花费的工作量
2.度量配置审计发现的
问题
2.度量从事配置项识别
2.1