项目管理能力

项目管理能力项目管理能力项目管理能力V:1.0精细整理，仅供参考项目管理能力日期：20xx年X月项目管理能力标杆(基于CMMI3级)过程能力基线L81对变更原因进行分析，便于项目组和组织进行计划过程改进

2.对问题和风险影响的分析便于项目组和组织工作量估算过程的改进

3.将调整进度和任务方法和手段提交组织财富库以便后续项目借鉴1.根据需求变更来源以及影响分析变更原因,同时改进项目需求管理方法

2.项目组将经验交付给组织便于需求管理过程的改进1.分析变更原因，有利于对需求和设计等技术实现活动的改进

2.对配置问题原因进行，根据分析结果对项目和组织配置活动进行改进根据质量趋势报告对项目和组织的过程进行不断改进L71.度量计划变更原因，并对变更原因进行归类

2.度量问题和风险对项目计划的影响

3.度量对重计划时调整进度和任务方法和手段度量需求变更的来源

1.客户提出

2.公司产品规划

3.需求采集遗漏

4.需求理解错误1.对配置审计发现的问题进行归类

2.对配置项变更原因度量和归类1.对统计的不合格项进行分析，产生质量趋势报告L6度量从事计划活动的工作量

度量重计划的次数和工作量1.度量从事项目计划跟踪所花费的工作量

2.度量识别的风险数

3.度量项目问题数

4.度量项目进度和工作量

5.度量项目人员流失数量

6.度量项目加班工时1.度量需求变更的数量和类型

2.度量需求变更的所花费的工作量1.度量配置活动的工作量

.度量配置管理的分类活动工作量

.度量相关组的配置活动工作量

2.度量配置项的数量

3.度量变更数量

4.度量基线和配置项交付的延迟率

5.度量配置审计发现的问题数量1.度量从事QA活动的工作量

2.统计QA发现的不合格项L51.项目组能识别出项目的关键任务路径图，决策如何保证项目尽可能并行开展；1.对项目的关键路径上的任务进行跟踪

2.审查任何过程或产品的变更请求报告

3.依据利益相关者介入承诺的变更，调整WBS

4.项目总监定期对项目的风险管理进行审查

5.当关键路径上任务发生偏差时，调整关键任务，重新生成关键路径图；1.审查设计、测试、代码与需求及其变更是否保持一致，并纠正错误1.能详细的配置活动工作任务分解(WBS)

2.基线创建时能识别出差异化需求

3.变更过程有清晰的评审和验证动作,且变更相关的文档作必要的变更

4.按照配置项的变更触发式的发布配置状态报告

5.能项目配置活动作功能审计1.对发现的不合格项进行分析

2.项目总监负责协调处理QA报告中不能或者无法解决的不合格项L4中包含对客户原有系统的优缺点，公司现有产品的强弱项；

2.依据WBS，进一步按月分解任务，制定周计划

3.项目组成立估算小组，使用估算方法对工作量和成本进行估算

4.识别出项目在进度、工作量、资源方面的风险，在WBS里体现针对风险的应对解决任务；

5.在WBS里体现利益相关者介入的活动；

6.项目组执行培训活动，并进行培训评价；1.项目经理组织用户、其他管理人员、供应商以及受影响的利益相关者对活动和工作产品的完成情况共同进行审查；

2.按月/周审查WBS中与利益相关者介入有关的各任务、活动的进展情况，及时调整WBS中与利益相关者介入有关的各任务、活动中相关内容；

3.项目组按周审查项目相关的风险的应对情况，必要时调整风险参数、应对措施，并在WBS中体现被调整的应对措施；

4.采集下列问题，明显偏差的项目计划参数、未得满足的内外承诺、重大变化风险的状态、利益相关者介入情况，分析问题并纠正。1.项目相关组参与需求变更的评估，并及时调整相关组的计划

2.审查项目计划与需求及其变更是否保持一致，并纠正错误

3、用需求跟踪矩阵跟踪需求被功能分解以及设计、测试的过程1.项目中有文档化的配置管理策略

2.项目对配置项进行分类和跟踪

3.在编码和测试阶段创建测试基线

4.项目能依据变更控制流程进行变更控制并有文档化记录

5.按照配置审计计划进行物理审计1.帮助项目组选择适合项目的生命周期和作业过程

2.按照QA计划对项目作业过程进行审计

3.在项目的生命周期阶段进行项目阶段退出审计L31.项目组有指导项目活动的SOW，包括对客户原有系统、公司现有产品的功能描述；

2.项目组根据SOW确定项目生命周期

3.项目建立WBS，覆盖生命周期各个阶段、子阶段的活动

4.依据WBS进行任务的工作量、资源估算

5.识别出项目的风险，制定应对措施并进行跟踪

6.对WBS中所有任务的工作量、资源、进度的承诺进行确认

7.识别出组间依赖关系

8.项目组识别所需业务、技术、质量过程的培训需求，评估现有的技能水平，制定培训计划；1.项目经理在项目例会中对活动和工作产品的完成情况进行审查

2.按月审查内部和外部的承诺

3.按照WBS中的项目里程碑点对利益相关者的活动进行审查

4.项目组按生命周期阶段点审查项目相关的风险的应对情况

5.在项目进度安排的里程碑点与相关人员共同进行审查

6.采集测试、评审发现的问题，及项目进度偏差值，分析并进行纠正；1.用需求跟踪矩阵跟踪需求的完整性

2.对需求变更进行评估,并根据其对除项目计划外其他工作产品的影响及时调整工作产品,如设计、代码、测试1.项目有独立于项目计划的配置管理计划

2.能识别出项目活动中结果配置项以及其变量部分

3.根据项目的生命周期规划出项目的基线计划1.项目有独立于项目计划的QA计划

2.按照QA计划对项目的工作产品进行审核

3.审核问题文档化,并跟踪其关闭L21.项目售前阶段有项目估算文档

2.项目组有实现系统的总体开发计划1.有明确的需求受理的流程

2.对需求变更进行评估,并根据其对项目计划的影响及时调整项目计划1.项目组至少每周将代码更新到配置服务器上

2.项目组有独立的配置管理系统

3.项目组能依据项目合同识别交付产物L11.项目有按照合同约定的里程碑计划1.在客户里程碑点对项目进度/风险和问题进行审查

2.按照客户里程碑点对进行情况进行监督1.与用户达成需求的共识

2.需求变更有记录1.项目组按照项目生命周期定期将代码和核心文档备份到公司配置库KPA-PP（项目计划过程）KPA_PMC（项目监督与控制）KPA_REQM（需求管理）KPA-CM（配置管理）KPA-PPQA（质量保证）项目计划过程L8的变化原因进行归类总结1.对项目生命周期的变化原因进行归类总结1对变更原因进行分析，便于项目组和组织进行计划过程改进

2.对问题和风险影响的分析便于项目组和组织工作量估算过程的改进

3.将调整进度和任务方法和手段提交组织财富库以便后续项目借鉴L71.度量SOW的变化量1.度量项目生命周期的变化量1.度量计划变更原因，并对变更原因进行归类

2.度量问题和风险对项目计划的影响

3.度量对重计划时调整进度和任务方法和手段L61.度量从事编制SOW活动所花费的工作量1.度量策划和确定生命周期所花费的工作量1.度量从事项目计划所花费的工作量

2.度量重计划所花费的工作量1.度量从事估算所花费的工作量

2.估算活动的工作量、成本、进度数据提交到PDB；1.度量从事风险管理活动所花费的工作量

2.度量所识别的风险数量L5项目组能识别出项目的关键任务路径图

1.识别任务的相互关系，标示出任务之间的关联，得到关键任务路径图；

2.分析关键路径上的任务，平衡资源，调整任务之间关系，尽量保证任务并行展开；1.对软件工作产物的估计（需求点、功能点、类、对象、接口）

2.对关键计算机资源的估计；

3.对工作产物（文档）的估计（页数）；

4.估算的所有修订及每次修订的成本、进度和工作量变化；L4中包括以下内容:

1.客户原有系统分析

用户原有系统优点和缺点

2公司已经有产品的分析

公司现有产品的强项和弱项制定项目工作任务分解（WBS）及进度计划,根据项目的生命周期对项目的开发、工程实施等活动进行任务分解

要求：

1.依据WBS，进一步按月分解任务，制定周计划；

2.任务的资源分配项目组每个成员；

3.叶子工作量不能大于16人时

4.一个人在一周的工作量不能大于60人时

获得实现计划的承诺：

1.根据需要，项目总监审查内部、外部的承诺；

利益者相关活动：

1.在WBS里体现利益相关者介入的活动；1.项目组成立估算小组，根据估算方法[Delphi法]对工作量和成本进行估算1.识别出项目在进度、工作量、资源方面的风险；

2.识别出项目在成本、性能相关的风险；

3.在WBS里体现针对风险的应对解决任务；1.依据WBS的培训进度安排执行培训活动；

2.项目经理或部门经理对项目组成员进行评价：

培训目标；个人技能的提升；

3.文档化培训记录；

4.依据项目实际情况，调整培训计划；L3中包括以下内容:

1.客户原有系统分析

客户原有系统基本信息

原有系统的功能

2公司已经有产品的分析

公司已经产品基本信息

现有产品主要功能

3.系统建设目标

系统基本信息

功能描述

接口需求能根据项目建设目标和客户要求确定项目的生命周期：

1.研发项目明确开发阶段的生命周期，包括需求分析、设计、代码、集成和验证等子阶段；

2.工程项目明确开发阶段、工程实施阶段的生命周期

开发阶段包括：需求分析、设计、代码、集成和验证等子阶段

工程阶段包括：上线、维护、推广、初验、终验等子阶段制定项目工作任务分解（WBS）及进度计划,根据项目的生命周期对项目的开发、工程实施等活动进行任务分解

要求：

覆盖生命周期各个阶段、子阶段的活动；

2.根据项目的WBS重点活动：

汇编出顶层的WBS任务分解

根据顶层WBS进一步分解子活动、子任务；

叶子工作量不能大于40人时；

3.依据任务的估算工作量，识别约束条件，确定人力资源；

4.识别任务相互关系，确定任务的进度时间点；

5.识别主要里程碑点，包括：完成的工作、提交的交付件的时间点或事件点；

6.项目组约定了项目重新计划的准则和要求，包括：

项目里程碑点或关键任务的进度偏差，累计工期偏差超过15天。

获得实现计划的承诺：

1.项目组对项目计划进行评审，包括对WBS中所有任务的工作量、资源、进度进行确认；

2.项目计划要得到项目总监、用户的确认；

识别出利益相关小组

1.关键交付物

2.交付日期1.依据WBS，项目经理估算活动、任务的工作量和成本；

2.评审估算活动产物1.识别出项目的风险；

2.根据确定的风险参数定义评估风险。风险参数包括：

概率、影响、优先级；

3.根据规定的风险类别对风险进行分类和分组，同时明确风险的因果或先后关系；

4.排列风险顺序，确定风险对项目的影响程度；

5.每个风险中制定相应的应对措施

6.文档化识别的风险；

7.和利益相关者审查风险，并达成一致；

8.根据需要修订风险文件。1.识别出项目所需的知识和技能，包括：

业务、技术和质量过程方面

2.评估现有的可用的知识和技能，获取本项目组不具备的知识和技能；

3.制定相应的技能培训计划；

4.在WBS里体现人员技能培训的活动；L21.在项目售前阶段，根据项目合同的点对点应答/建议方案等做项目进度和成本的估算[售前预算]L1合同附件:点对点应答/建议方案书

-如果是合同外服务，可以是和用户的一些约定或者原始SOW生命周期项目计划估算风险管理技能提高项目监督与控制L61.度量从事"进展审查"所花费的工作量

2.度量从事"监督参数"所花费的工作量

3.度量从事"监督承诺"所花费的工作量

4.统计不能实现承诺的数量度量从事"监督里程碑审查"所花费的工作量度量从事"问题分析&纠正措施"所花费的工作量

问题数量、关闭数量1.度量从事"监督风险"所花费的工作量

2.统计识别的风险数L5监督计划参数：

1.对项目的关键路径上的任务进行跟踪，包括：

跟踪任务的进度、工作量、资源；

2.对工作产品和任务的属性、关键计算机资源等进行跟踪：

工作产品和任务属性（如规模或复杂程度）及其变更；

系统使用的资源（如计算机、网络、测试设备、软件工程环境等）；

进展审查：

1.审查任何过程或产品的变更请求报告；

2.审查结果文档化；

3.跟踪变更请求，直到其关闭；

监督利益相关者：

1.依据利益相关者介入承诺的变更，调整WBS；当关键路径上的任务发生偏差时：

调整任务的工作量，重新分配资源；

调整关键路径上与其相关联的任务的工作量、资源、进度；同时调整非关键路径上受影响的其他任务的工作量、资源、进度；

依据任务的调整，重新生成关键路径图；1.项目总监定期对项目的风险管理进行审查；

2.项目经理定期对项目风险管理活动进行分析；L4监督计划参数：

对工作产品和任务的资源、工作量以及进度等进行跟踪：

1.项目工作量和资源（包括：项目加班情况、项目组人员流失）

2.项目需要的知识和技能；

3.工作量、资源、知识和技能的偏离情况，并文档化。

进展审查：

1.项目经理组织用户、其他管理人员、供应商以及受影响的利益相关者对活动和工作产品的完成情况共同进行审查；

监督利益相关者：

1.按月/周审查WBS中与利益相关者介入有关的各任务、活动的进展情况；

2.依据进展情况，跟踪、解决存在的问题；

3.及时调整WBS中与利益相关者介入有关的各任务、活动中相关内容；1.采集问题，以供分析，问题包括：

计划中预算值有明显偏差的项目计划参数，包括：

项目进度、工作量、资源、项目所需的知识和技能偏差值；

未得到满足的内部或外部承诺，包括：

WBS中的内部或外部承诺；

发现重大变化的风险状态；

利益相关者的介入情况

2.确定为处理所识别的问题而采取相应的纠正措施，纠正措施包括：

当项目工作范围或关键任务的工作量、资源发生偏差时，进行重估算：

重新估算任务的工作量、资源

依据重估算的结果，调整项目关键任务的进度；

重新确定项目风险；

补充资源；

重新商谈承诺；

改变相应过程；

3.采取的措施与相关人共同审查并达成协议；

4.协商有关内部和外部的承诺变化；1.项目组按周审查项目相关的风险的应对情况；

2.项目例会上主要针对进度、工作量和资源等方面的风险设专题讨论；

3.分析风险参数，依据项目实际情况及时调整参数；

风险评价；

风险发生概率；

风险优先顺序；

4.依据项目实际情况及时调整风险应对措施，应对策略；

5.在WBS中体现被调整的应对措施；L3监督计划参数，对工作产品和任务的进度进行跟踪：

1.项目进展：按照WBS中的进度；

2.项目进展的偏离情况，并文档化

监督承诺：

1.按月审查内部和外部的承诺，审查承诺包括：

审查WBS中关键任务执行的承诺；

审查功能实现执行的承诺

审核接口实现任务执行的承诺

审核关键资源的承诺，如：

人力资源等

2.识别那些没有得到满足的承诺或那些很可能得不到满足的承诺；

3.承诺审查的结果文档化

4.对发现的问题进行分析跟踪直到关闭

进展审查：

1.项目经理在项目例会中对活动和工作产品的完成情况进行审查，并通报相关者；

相关者包括：项目总监、项目成员、用户、其他管理人员、受影响的利益相关者

2.重大偏差和重大问题文档化；

3.审查结果文档化；

4.跟踪问题报告，直到其关闭；

监督利益相关者：

1.按照WBS中的项目里程碑点对利益相关者的活动进行审查(组间协同人或者组织)

第三方厂家

主机,数据库等项目环境提供者

2.对发现的问题进行分析跟踪直到关闭1.在项目进度安排的里程碑点与相关人员共同进行审查；

2.审查该项目的承诺、计划、状态以及风险；

3.识别重大问题及其影响并将其文档化；

4.审查结果、为解决问题而采取的各项行动以及各项决定文档化；

5.跟踪所采取的行动，直至结束1.采集问题，以供分析，问题包括：

测试和评审活动中发现的问题；

计划中预算值有明显偏差的项目计划参数，包括：

项目进度偏差值

2.确定为处理所识别的问题而采取相应的纠正措施，纠正措施包括：

修改相应的需求、设计等文档；

任务进度累计工期超过15天，重新修订WBS，调整任务的进度、资源；

对修订后的WBS进行评审；

3.与相关人共同审查采取的纠正措施并达成协议；1.项目组按生命周期阶段点审查项目相关的风险的应对情况；

2.更新风险的状态；

3.识别项目新的风险；

4.把风险状态通知受影响的各方；L2L11.按照客户里程碑点对项目进度/风险/问题/成本进行审核

2.对发现的问题跟踪并直到关闭

3.在客户里程碑点对发现的问题进行分析并将记录文档化

4.根据问题分析的结果采取相应的措施

-增加资源

-延长工期/增加工作量

-修改和用户的约定进行进展审查里程碑审核分析问题&纠正措施监督项目风险需求管理过程REQM_L81.根据需求变更来源以及影响分析变更原因,同时改进项目需求管理方法

2.项目组将经验交付给组织便于需求管理过程的改进REQM_L7度量需求变更的来源

1.客户提出

2.公司产品规划

3.需求采集遗漏

4.需求理解错误REQM_L6度量获取需求管理的工作量1.度量管理需求变更所花费的工作量

2.度量需求变更的数量和类型度量识别需求和工作产品不一致花费的功工作度量获取项目组承诺的工作量度量维持需求双向可塑性的工作量REQM_L51、审查设计、测试、代码的变更是否和需求以及需求变更保持一致，并及时纠正REQM_L41、项目相关组（如集成组）参与对需求变更进行评估，并及时完成由此带来的对相关组工作计划的调整1、审查项目计划是否和需求以及需求变更是一致的，并及时纠正1、用需求跟踪矩阵（或系统功能说明书）覆盖用户需求被完整的功能分解

2、用需求跟踪矩阵跟踪功能需求被实现的过程（包括设计、测试、代码）REQM_L31、项目组内部按照变更流程对需求变更做评估，并及时完成由此带来的设计、测试、代码文档的调整，并对需求跟踪矩阵做更新1、用需求跟踪矩阵（或需求规格书）覆盖完整的用户需求RM_L21、项目组建立需求受理机制，包括：

1）需求提供人

2）需求受理人

3）需求评估和接受的原则1、项目组内部按照变更流程对需求变更做评估，并对影响度进行分析，并及时完成由此带来的项目计划的调整1、项目组内部按照变更流程对需求变更做评估，评估对现有的承诺的影响，如：承诺的软件上线时间延迟，并对承诺的变更，获得承诺双方达成的共识RM_L1

1、双方对需求达成共识1、文档化项目的需求及需求的变化

2、需求变更有记录获得可理解的需求管理需求的变更辨别需求和工作产品的不一致性建立对需求的承诺维持需求双向可溯性配置管理过程CM_L81.通过分析变更原因来了解需求/设计等稳定度

2.通过对从事花费变更工作量的分析对项目计划的影响对配置审计问题进行分析

1.对项目配置管理活动改进

2.交付组织财富库

3.对组织的配置过程进行改进CM_L71.度量变更原因,并对变更原因进行分类1.对配置审计问题进行分类

物理审计发现的问题

功能审计发现的问题

配置管理问题

相关者问题CM_L61.度量从事版本控制所花费的工作量

2.度量从事版本控制所出现的问题1.按照配置管理活动的子活动度量出子活动工作量

2.度量相关组配置管理的工作量1.能对配置项的以下指标度量

.按照生命周期阶段配置项数量

.按照计划配置项交付的延期率

2.度量从事配置项识别所花费的工作量1.度量基线创建的延迟率

2.度量从事基线创建所花费的工作量1.定期度量变更相关的数据

申请变更数

累计变更数

批准变更数

……

2.度量从事变更控制所花费的工作量

配置管理员所花费的工作量

相关者所花费的工作量度量从事配置状态报告所花费的工作量1.度量从事配置审计所花费的工作量

2.度量配置审计发现的问题CM_L51.能创建独立配置管理活动WBS任务分解

配置管理员从事配置活动的WBS

相关者从事配置活动的WBS

2.配置管理策略说明了项目总监以及项目经理介入配置管理的时机和动作能标识出每个基线版本的差异需求

1.新增的需求

2.修改的缺陷

3.修改了原来的需求1.变更控制过程有评估和验证活动

2.变更过程中涉及到的文档类配置项需要必要的变更

3.变更过程中随时将配置项变更状态周知项目组1.根据配置项变更触发式进行状态报告

2.报告新增以下内容

配置工具的状态

配置库操作情况

配置管理问题跟踪情况（包括审计问题）

基线和配置项度量数据的报告

变更的度量数据

配置审计问题的跟踪

报告需求实现情况1.按照审计计划在基线创建时进行功能审计

需求实现过程是否完整

需求演变过程是否遗漏CM_L41.项目组从配置服务器上检出和检入版本,在检入时时需要填写修改说明,可以在配置工具加注说明也可以用独立文件来描述,详细描述具体到每个文件修改责任人/时间/内容配置计划新增以下内容:

1.项目组有明确的配置管理策略

2.配置审计计划

3.配置管理日常计划

备份计划

配置库日常检查计划

4.配置状态发布计划以及触发提交

5.配置计划需要通过项目总监审批

6.配置计划发布后周知项目组全体人员1.根据一定的规则对代码配置项的颗粒度进行进一步的细化

代码配置项的颗粒度至少细化到模块级

2.对识别的配置项进行归类

将配置项分成技术类文档/工程类文档/接口类文档/计划类

3.能对配置项变更做相应的跟踪和记录

4.能对配置项交付活动作记录和跟踪

5.能识别出项目活动中过程配置项在编码和测试活动中，能根据项目的特点创建测试基线，为测试活动提供可测试的版本1.项目组制定了适合项目特点的变更控制流程

2.变更的过程中的相关活动有文档化的记录1.项目组定期发布配置状态

.只对纳入基线的配置项的状态进行报告

.配置状态报告周知项目组按照配置审计计划,在基线创建是进行物理审计

-检查基线包含的配置项是否完整

-检查配置项的命名和版本的命名规则是否符合约定

-检查配置项纳入基线是否符合条件

-检查与配置项相关活动是否执行

-检查变更过程是否符合规程

-检查版本控制是否有记录

-检查发布过程是否要求(限于产品基线)

-审核配置计划中的相关活动是否落实CM_L31.项目组通过配置管理工具进行版本控制,也就是说有独立的配置管理系统

2.项目组至少每1周更新（检入）一次配置服务器1.项目有独立的配置管理计划,计划中包括以下内容:

项目的生命周期以及模型

项目的建设目标

配置库的目录结构

配置基线计划

配置项管理计划

配置项以及版本命名规则

2.在项目启动之时制定配置计划，配置计划和项目计划同步制定1.能识别出项目活动的结果配置项

2.能识别出项目活动中变量配置项

3.配置项交付时符合交付约束条件

4.配置项的命名符合约定

5.明确配置项责任人根据项目的生命周期规划出项目的基线计划

1.在配置库上有明显的Label动作轨迹

2.按照发布计划,发布活动轨迹CM_L2能根据项目的合同，识别出项目合同中规定的阶段产物CM_L11.项目组按里程碑通过备份的方式将项目源代码备份到公司配置服务器上

2.项目组按里程碑通过备份的方式将项目核心技术文档备份到公司配置服务器上版本控制配置计划配置项识别基线变更控制配置状态报告配置审计质量保证过程L81.项目过程改进

根据质量趋势报告制定项目过程改进计划

根据质量趋势报告向EPG提出过程修改建议1.项目过程改进

根据质量趋势报告制定项目过程改进计划

根据质量趋势报告向EPG提出过程修改建议L71.对工作产品的不合格项进行分析

.分析不合格项产生的质量趋势

文档化趋势报告

向项目组和高层汇报趋势，并提出改进方案和思路1.对过程的不合格项进行分析

.分析不合格项产生的质量趋势

文档化趋势报告

向项目组和高层汇报趋势，并提出改进方案和思路L61.度量从事工作产品审核的工时

2.度量工作产品的不合格数1.度量从事过程审计和辅导的工时

2.度量过程审计发现的不合格数量度量从事质量活动的工作量L51.工作产品不合格项处理

对不合格项进行分析，判定不合格项的处理思路

-解决不合格项

-修改准则

-申请豁免（需要公司EPG核准）

对于不能解决或者无法解决的不合格项交付项目总监,并跟踪问题解决直到关闭1.过程不合格项处理

对不合格项进行分析，判定不合格项的处理思路

-解决不合格项

-修改准则

-申请豁免（需要公司EPG核准）

对于不能解决或者