CMMI过程域详解-项目策划(PP)之SG2 制订项目计划

SG 2 制订项目计划

项目计划得到建立与维护,以此作为管理项目的基础。

项目计划是用于管理和控制项目执行的经过批准的正式文件。它以项目需求和已建立的估算为基础。

项目计划应考虑项目生命周期中的所有阶段。制订项目计划时应确保所有影响项目的计划与整体项目计划一致。

 

SP 2.1 建立预算与进度

建立并维护项目的预算与进度。

项目的预算与进度以编制好的估算为基础,并确保预算分配、任务复杂度以及任务依赖关系都得到适当的处理。

以事件为驱动、以资源为限制条件的进度已经被证明能够有效应对项目风险。明确某个事件开始之前需要展示的成果,能够提供该事件在时间上的灵活性、对预期成果的共识、更清晰的项目状态展望以及对项目任务更准确的状态了解。

CMMI模型中,PP过程域的工作产品实例:

1. 项目进度

2. 进度依赖

3. 项目预算

CMMI模型中,PP过程域的子实践:

1. 识别主要的里程碑。

里程碑是预先计划的事件或指定时间点,用来执行对项目状态的全面评审,以便了解干系人需求的符合程度。(如果项目包含一个演进性的里程碑,那么应执行评审以确保与该里程碑相关的假设及需求都已得到满足。)里程碑可以与整体项目或一个特定的服务类型或实际服务相关。里程碑可以基于事件或日期。如果基于日期,一旦就里程碑日期达成一致,常常很难更改。

2. 识别进度的假设。

当开始编制进度表时,通常要对特定活动的工期作出假设。这些假设经常针对估算数据较少甚至没有的事项做出。识别这些假设提供了对整个进度的置信度(即:不确定性)的深刻理解。

3. 识别约束。

需要尽早识别出影响管理者选择的灵活性的限制因素。对工作产品和任务属性的检查,常常可以揭示这些问题。这些属性可能包括任务工期、资源、输入及输出。

4. 识别任务的依赖关系。

项目或服务的任务常常能够以某种工期最短的排序完成。这需要识别任务之间的先后次序,并确定最优排序。能够帮助确定任务活动的最佳排序的工具与输入的实例有:

• 关键路径法(Critical Path Method,CPM)

• 项目评价与评审技术(Program Evaluation and Review Technique,PERT)

• 资源受限的进度编制

• 客户优先级

• 可市场化的特性

• 最终用户的价值

5. 建立并维护预算与进度。

建立并维护项目的预算与进度通常包括:

• 定义资源及设施的已承诺或已预期的可用时段

• 确定活动的时间阶段

• 确定附属进度的分解

• 定义活动之间的依赖关系(前导或者后继关系)

• 确定支持项目监督与控制的进度活动及里程碑

• 确定交付客户产品的里程碑、发布版本或增量

• 定义工期适当的活动

• 定义时间间隔适当的里程碑

• 根据满足进度与预算的信心程度,定义管理预留

• 利用适当的历史数据来验证进度

• 定义增量式的经费需求

• 记录项目的假设和依据

6. 建立纠正措施准则。

建立确定何为明显偏离项目计划的准则。为了确定何时应该采取纠正措施,需要建立估量各种问题和事项的基础。纠正措施可能要求重新计划——包括修订原计划和建立新协议,或者在当前计划中包含缓解措施。项目计划定义何时(例如:何种情况下、以何种频率)由何人来应用这些准则。

 

SP 2.2 识别项目风险

识别并分析项目风险。

参阅“项目监督与控制”过程域中的“监督项目风险”特定实践,以进一步了解风险监督活动。

参阅“风险管理”过程域,以进一步了解如何在项目潜在的问题发生前对其进行识别,以便在整个产品或项目生命期中,计划并在必要时启动风险的处理行动,从而降低这些潜在问题对达成目标产生的不利影响。

识别或者发现风险并且加以分析,以支持项目计划活动。本特定实践应该扩展到所有影响项目的计划,以确保所有相关干系人在已识别的风险上适当地协作。

项目计划工作中的风险识别与分析通常包括:

• 识别风险

• 分析风险以确定其影响、发生的可能性以及可能发生问题的时间范围

• 划分风险优先级

CMMI模型中,PP过程域的工作产品实例:

1. 已识别的风险

2. 风险影响及发生概率

3. 风险的优先级

CMMI模型中,PP过程域的子实践:

1. 识别风险。

风险的识别包括识别可能对工作和计划带来负面影响的潜在问题、危险、威胁、弱点等。在对风险进行分析与适当的管理之前,应该识别并以易于理解的方式描述风险。识别风险时,最好能采用定义风险的标准方法。可以使用风险识别与分析工具,来帮助识别可能的问题。风险识别与分析工具的实例有:

• 风险分类法

• 风险评估

• 检查单

• 结构化访谈

• 头脑风暴

• 过程、项目及产品性能或绩效模型

• 成本模型

• 网络分析

• 质量因素分析

2. 将风险文档化。

3. 与相关干系人一起评审已文档化的风险,就其完整性与正确性达成一致。

4. 适当地修订风险。

何时需要修订已识别风险的实例有:

• 识别出新风险时

• 风险变成问题时

• 风险已经消失时

• 项目环境发生重大变化时

 

SP 2.3 计划数据管理

为项目数据的管理制订计划。

数据是在所有方面(例如管理、工程、配置管理、财务、后勤、质量、安全、制造以及采购)支持项目所需要的文档形式。数据可能采用任何形式(例如报告、手册、笔记、图表、图纸、规格说明、文件或者往来信函)。数据可能存在于任何介质(例如不同材质的打印件或绘制件、照片、电子存储或者多媒体)。数据可能是交付物(例如项目的合同数据需求中标识出来的条目),也可能是不需交付的(例如非正式的数据、权衡分析、分析资料、内部会议纪要、内部设计评审文档、经验教训以及行动项)。数据的分发形式可以是多种多样的,包括电子传递。

项目的数据要求,应当根据通用或标准的数据要求,从要创建的数据项及其内容和格式两方面来建立。统一的数据项内容和格式要求,使数据内容更容易理解,并有助于对数据来源进行一致的管理。收集每份文档的理由都应该很明确。这项任务包括分析与验证项目的交付物及非交付物、数据要求以及客户提供的数据。数据往往是在其用途尚不清楚的情况下就开始收集。收集数据的成本很高,应该只在需要时才去收集。

CMMI模型中,PP过程域的工作产品实例:

1. 数据管理计划

2. 受管理的数据总表

3. 数据内容及格式描述

4. 采购方与供方的数据需求清单

5. 私有性需求

6. 保密性需求

7. 保密性规程

8. 数据检索、复制和分发机制

9. 项目数据的收集进度

10. 需收集的项目数据清单

CMMI模型中,PP过程域的子实践:

1. 建立保证数据的私有性和保密性的要求与规程。

并非每个人都有访问项目数据的需要或者权限。必须建立有关规程,以确定何人能在何时访问何种数据。

2. 建立数据归档以及访问已归档数据的机制。

被访问的信息应该是易于理解的形式(例如来自数据库的电子或计算机输出)或者以其初始产生时的形式表达。

3. 确定待识别、收集和分发的项目数据。

4. 确定对相关干系人进行访问授权或者数据分发的需求。

对项目计划中其他要素的评审,有助于确定何人需要访问或接受项目数据以及需要哪些数据。

5. 确定对哪些项目数据及计划需要版本控制或其他级别的配置控制,并且建立机制以确保项目数据受控。

 

SP 2.4 计划项目资源

为执行项目所需的资源制订计划。

根据初始的估算结果,定义执行项目活动所需的项目资源和数量(例如人工、设备、材料以及方法),并提供额外信息,以展开用于管理项目的WBS。早期作为估算机制所制订的顶层WBS 常常会被展开为若干个代表单一工作单元的工作包,工作包能够分别被分配、执行和跟踪。这种划分能够分配管理职责,并提供更好的管理控制。WBS 中的每个工作包都应该被赋予唯一的标识符(例如编号)以便跟踪。WBS 可能基于需求、活动、工作产品、服务或者它们的组合。WBS 应附有一份描述该工作分解结构中每项工作的字典。

CMMI模型中,PP过程域的工作产品实例:

1. 工作包

2. WBS 任务字典

3. 基于项目规模和范围的人员配备需求

4. 关键设施与设备清单

5. 过程及工作流的定义及图表

6. 项目行政管理需求清单

7. 状态报告

CMMI模型中,PP过程域的子实践:

1. 确定过程需求。

必须会同所有相关干系人一起识别、定义和协商用于管理项目的过程,以保证项目执行期间这些过程的有效运作。

2. 确定沟通需求。

这些需求说明了与客户、最终用户、项目成员以及其他相关干系人沟通所使用的机制。

3. 确定人员配备需求。

项目的人员配备情况取决于为了实现项目需求将其分解成的任务、角色和职责,分解方式与WBS 中的工作包结构一致。

人员配备需求应该考虑到每个已识别的职位所需的知识与技能,正如“计划所需的知识与技能”特定实践中定义的那样。

4. 确定设施、设备及组件需求。

大部分项目具备某些方面的独特性,并需要某些独特的资产来完成项目目标。及时确定并获取这些资产对项目的成功至关重要。最佳做法是尽早识别需要备货周期的事项,以决定应对方式。即使需要的资产不是独特的,也应该编制一份所有设施、设备以及零件(例如项目中人员使用的计算机数量、应用软件、办公空间等)的清单,从而深入了解工作范围内某些经常被忽视的方面。

5. 确定其他持续性的资源需求。

除确定过程、报告模板、用人情况、设施以及设备之外,还有关于其它类型资源的持续需要,以有效地实施项目的活动,包括:

• 易耗品(例如:电力、办公用品)

• 知识产权的使用权

• 运输设备的使用权(对人员及设备)

对于此类资源的需求从以下各项衍生而来:从(现有及未来的)协议(例如:客户协议、服务协议、供方协议)中发现的需求、项目的战略手段以及在一定时期内管理并维持项目运作的需要。

 

SP 2.5 计划所需的知识与技能

为执行项目所需的知识与技能制订计划。

参阅“组织级培训”过程域,以进一步了解如何发展人员的技能与知识,使其能够有效并高效地执行他们的角色。

对项目的知识传递包括对项目人员的培训以及从外部来源获取知识。人员配备需求取决于当前可用于支持项目执行的知识与技能。

CMMI模型中,PP过程域的工作产品实例:

1. 技能需要清单

2. 人员配备与雇佣计划

3. 数据库(例如技能与培训)

4. 培训计划

CMMI模型中,PP过程域的子实践:

1. 识别执行项目所需的知识与技能。

2. 评估可用的知识与技能。

3. 选择提供所需知识与技能的机制。

机制的实例有:

• 内部培训(组织级的和项目级的)

外部培训

• 人员配备及雇佣

• 获取外部技能

根据培训专家的可用性、项目进度以及业务目标来决定选择内部培训还是外包培训获取所需的知识与技能。

4. 将选定的机制纳入项目计划。

 

SP 2.6 计划干系人的参与

计划所识别干系人的参与。

通过识别项目中需要的人员类型和职能,并描述他们与特定的项目活动的相关性和作用的程度,来确定项目生命周期中所有阶段的干系人。使用二维矩阵对照表是完成识别工作的简便方法,两个维度的坐标轴分别表示干系人和项目活动。在特定的项目阶段干系人与活动的相关关系以及预期的参与程度,应该在项目阶段活动轴与干系人轴的交叉位置上标明。

为了使干系人的参与发挥作用,必须慎重地选择相关干系人。对于每项主要活动,识别受到该活动影响的干系人及他们执行该活动所需的专业技能。相关干系人列表应随着项目所处的生命周期阶段而变化。然而重要的是,应保证生命周期后续阶段的相关干系人,能提前参与对他们有影响的需求和设计决策。

应该包含在干系人交互计划中的内容实例有:

• 所有相关干系人的列表

• 干系人参与的依据

• 干系人之间的关系

• 保证干系人的交互所需的资源(例如培训、材料、时间、资金)

• 干系人分阶段交互的时间安排

• 项目生命周期阶段中,相关干系人的角色与职责

• 项目生命周期阶段中,该干系人对项目成功的相对重要性

本特定实践的实施依赖于前一项“计划所需的知识与技能”特定实践的共享或交换信息。

CMMI模型中,PP过程域的工作产品实例:

1. 干系人参与计划

 

SP 2.7 建立项目计划

建立并维护整体项目计划

描述了所有相关计划事项的文档化的计划,对实现执行或支持计划的个人、小组以及组织之间的共同理解与承诺是必要的。

项目计划定义了项目工作的各个方面,以符合逻辑的方式说明以下各项:

• 项目生命周期的考量

• 项目任务

• 预算及进度

• 里程碑

• 数据管理

• 风险识别

• 资源及技能需求

• 干系人的识别及交互

• 基础设施的考量

基础设施的考量应包括项目成员、管理人员和支持组织的职责与权限。生命周期的考量应包括产品或服务后续阶段的覆盖(可能已经超出项目的生命期),特别是移交至其他阶段或团体(例如:转移到制造、培训、运营、服务提供商)。

软件的计划文档通常被称为下列之一:

• 软件开发计划

• 软件项目计划

• 软件计划

对于硬件,计划文档通常被称为硬件开发计划。生产准备中的开发活动可以包含在硬件开发计划里,也可以在独立的生产计划中定义。

美国国防部相关团体使用的计划的实例有:

• 集成的总体计划——事件驱动的计划,描述了项目的重要成果及其业务和技术方面的通过/失败准则,并且将每项成果与关键的项目事件联系起来。

• 集成的总体进度——集成化、网络化的多层次项目任务进度表,这些任务是完成相关的“集成的总体计划”中描述的工作所需要的。

• 系统工程管理计划——详细描述项目中集成的技术工作的计划。

• 系统工程总体进度——事件驱动的进度安排,汇总了所有关键的技术成果,每一项成果都要有可度量准则、要能成功的实现,以通过所识别的事件。

• 系统工程详细进度——详细的、基于时间、任务导向的进度安排,将特定的日期和里程碑与“系统工程总体进度”联系起来。

CMMI模型中,PP过程域的工作产品实例:

1. 总体的项目计划

 

【PP过程域相关文章】

CMMI过程域详解-项目策划(PP)之概述

CMMI过程域详解-项目策划(PP)之SG 1

CMMI过程域详解-项目策划(PP)之SG 2

CMMI过程域详解-项目策划(PP)之SG 3

凡奉首页    管理实践    CMMI管理实践    CMMI过程域详解-项目策划(PP)之SG2 制订项目计划
创建时间:2020-05-02 00:00
收藏