第二章 过程域——项目计划

项目计划

目的

项目计划（PP）的目的是建立并且保持定义项目活动的计划。

介绍

项目计划过程域包括如下：

l         制订项目计划

l         与相关干系人适当的相互影响

l         获得对计划的承诺

l         维持计划

计划以定义产品和项目的需求为开端。

计划包括估计工作产品的属性和任务，决定需要的资源，谈判承担的义务，产生一个进度表，并且识别和分析项目的风险。建立项目计划可能必须通过重复以上的这些活动来完成。项目计划为执行和监督那些与项目的客户达成委托协议的项目活动提供了基础。

项目计划通常需要被作为项目进展进行修订，从而应对需求和委托协议的改变，错误的估计，纠正活动，以及过程的改变。描述计划编制和计划重新编制的关键实践都包含在这个过程域中。

在这个过程域中贯穿一般和特殊实践中用到的术语“项目计划”是指控制项目的整体计划。

相关过程域

有关定义产品和产品组件的开发需求的更多信息请参见需求制定过程域。产品和产品组件需求以及对这些需求的变更是作为计划和重新计划的基础而服务的。

有关计划和重新计划的管理需求的更多信息请参见需求管理过程域。

有关风险的识别和管理的更多信息请参见风险管理过程域。

有关把需求转换成产品和产品组件解决方案的更多信息请参见技术方案过程域。

有关项目进展和性能度量的计划的更多信息请参见度量与分析过程域。

实践－目标关系表

实现目标的关键实践

SG1 建立估计

项目计划参数的估计已建立并已保持。

项目计划参数包括项目为执行必要的计划、组织、人员配备、指导、协调、报告和预算等所需的全部信息。

计划参数的估计应建立在可靠的基础上，从而慢慢的使人建立起信心，相信根据这些估计拟订的计划是能够支持项目目标的。

估计这些参数时典型的要考虑的因素包括以下各项：

l         项目需求，包括产品需求、本组织的需求、顾客的需求以及其他对项目产生影响的需求；

l         项目范围

l         已识别的任务和工作产品

l         技术途径

l         选择的项目生命周期模型（例如，瀑布模型、增量模型或者螺旋模型）

l         工作产品和任务的属性（例如，规模和复杂性）

l         进度计划

l         把工作产品和任务属性转换成工时数和成本的模型或历史数据

l         用于确定所需的材料、技能、工时和成本的方法论（例如，模型、数据、算法）

把估计的基本原理和支持数据文档化是干系人回顾和承诺计划以及作为项目进展维护计划时所需要的。

SP1.1-1 估计项目的范围

建立一个从最高层次展开的工作详细展开架构（WBS），以估计项目的范围。

工作分解结构（WBS）随着项目而发展。最初，一个顶级的工作分解结构（WBS）能够服务于构成初始的估计。一个工作分解结构（WBS）的发展将整个项目划分成一组互相关联的可管理的组成部分。典型的，工作分解结构（WBS）是一个产品定向结构，它为识别和组织将被管理的工作的逻辑单元提供一个计划，这些逻辑单元被称之为“工作包”。工作分解结构（WBS）为标记成果，进度以及职责提供一个参考和组织机制，同时被用于作为计划、组织以及控制项目工作的根本框架。

典型工作产品

1.       任务描述

2.       工作包描述

3.       工作分解结构（WBS）

子实践

1.       根据产品体系结构开发一个工作分解结构（WBS）。

工作分解结构（WBS）围绕工作所支持的产品为组织项目的工作提供了一个计划。工作分解结构（WBS）应该允许如下各项的识别：

l         已识别的风险及其缓解任务

l         可交付的和支持性活动的任务

l         技能和知识收集的任务

l         制订所需的支持类计划（例如，配置管理计划、质量保证计划和验证计划）的任务

l         非开发项的集成和管理任务

2.       充分的识别工作产品，以便说明项目任务、职责和进度的评估情况。

顶级工作分解结构（WBS）有助于在任务、组织角色以及职责的条件下帮助计量项目的工作量。在工作分解结构（WBS）中，细节的数量不断的增多有助于制订切实的进度表，进而使需要的管理储备最小化

3.       识别将从项目以外获得的工作产品（或工作产品组件）。

有关从项目以外的来源获取工作产品的更多信息请参见供应协议管理过程域。

4.       识别将要再用的工作产品。

SP1.2-1 建立工作产品和任务特征的估计

建立并保持对工作产品和任务的特征的估计。

规模是许多用于估计工作量、成本和进度的模型的主要输入。这些模型也能以诸如连通性、复杂性和结构作为输入。

这些估计应与项目需求一致，以便确定该项目的工作量、成本和进度。每个规模属性应附上有关的难度和复杂度。

典型工作产品

1.       技术途径

2.       任务和工作产品的规模和复杂性

3.       估计模型

4.       属性评估

子实践

1.       决定项目的技术途径。

技术途径规定产品开发的顶层战略，它包括体系结构的决策，例如分布式或客户／服务器式；发展现状或将被应用的已确定的技术，例如机器人技术、复合材料或人工智能；以及期待在最终产品中的功能性范围，例如保险、安全和生物工程。

2.       用适当的方法去确定那些将用于估计资源需求的工作产品和任务的属性。

确定规模和复杂性的方法应该基于有效的模型和历史数据。

用于确定属性的方法逐渐将我们对产品特性关系的理解转化为属性，使之不断增加。

3.       估计工作产品和任务的属性。

4.       适当地估计项目所需要的工作量、机器、原料和方法。

SP1.3-1 定义项目生命周期

定义项目的生命周期阶段，在此之上确定计划工作量。

一个项目生命周期各阶段的确定为已经做出计划的周期提供估计和所做的决策。这些阶段通常被定义用于支持各个逻辑决策点，在这些决策点上要根据资源和技术途径作出重要承诺。这些决策点提供已经计划的事件，在这些事件中，项目进行改进和确定将来的范围和成本。

项目的生命周期由哪些需要被定义的阶段组成，依赖于需求的范围，项目资源的估计以及项目的种类。大型项目可能包含多种阶段，例如概念研究、开发、生产、运行和处置等阶段。在这些阶段内部，可能需要子阶段。一个开发阶段可能包括例如需求分析、设计、制作、集成和验证的子阶段。依据开发的策略，可能还有一些中间阶段用于创建原型、增加能力或用于螺旋模型的各个周期。

理解项目生命周期至关重要的在于确定计划产生效果的范围以及最初制订计划的时机，同时也在于重新制订计划的时机和标准（重要里程碑）。

典型工作产品

1.项目生命周期各阶段

SP1.4-1 确定对工作量和成本的估计

基于判断的基本原理，估计项目工作产品和任务的工作量和成本。

对工作量和成本的估算通常基于使用模型或历史数据对规模、活动、以及其它计划参数进行分析的结果。估算的置信度基于选定的模型理论和数据的特性。有时无法获得可用的历史数据，例如没有先例可循的工作，或者任务的类型不适于可用的模型。如果从来没有人构建过类似的产品或者部件，某项工作就是（某种程度上）没有先例可循的。如果开发组从来没有构建过这样的产品或者部件，这项工作也是没有先例可循的。

没有先例的工作有更大的风险，需要更多的研究以开发估算的合理基础，并需要更多的管理上的后备。使用这些模型时，项目的独特性必须得到文档化，以保证在最初的计划阶段作出的任何假设都得到共同的理解。

典型工作产品

1.     估算理论

2.     项目工作量估算

3.     项目成本估算

子实践

1.       收集将用于把工作产品与任务属性转换为工时和成本估算的模型或历史数据。

历史数据包括以往实施的项目的成本、工作量以及进度数据加上适当的比例数据以计算不同的规模和复杂性。

2.       估算工作量和成本时，包含支持设施要求。

支持设施包括项目的开发与支持方面需要的事项。

3.       使用模型和/或历史数据估算工作量和成本。

用于估算的工作量和成本输入通常包括：

l         专家或者专家组提供的判断性估算（例如Delphi 方法）

l         风险，包括没有先例的工作的范围

l         执行工作所需的关键能力和角色

l         产品与产品部件的需求

l         技术路径

l         WBS

l         工作产品和预期的变更的规模估算

l         外部采办工作产品的成本

l         选定的项目生存周期模型和过程

l         生存周期成本估算

l         工具在工程环境提供的能力

l         执行工作所需的管理者和员工的技能水平

l         需要的知识、技能与培训

l         需要的设施（例如办公和会议空间与工作站）

l         需要的工程设施

l         制造过程的能力

l         旅行

l         需要的任务、工作产品、硬件、软件、人员以及工作环境的保密性级别

l         呼叫中心和授权工作的服务水平协议

l         直接人工和经常开支

SG2开发项目计划

作为管理项目的基础，项目计划已建立并已保持。

项目计划是一份正式的、经过批准的文档，用于管理并控制项目的实施。它基于项目的需求和已经建立的估算。

项目计划应该考虑项目生存周期的所有阶段。项目计划工作应该保证所有影响该项目的计划都与项目总体计划一致。

SP2.1-1 建立预算和进度表

建立并保持项目的预算和进度表。

项目的预算和进度都以已经开发的估算为基础，并保证预算的分配、任务的复杂性、以及任务的依赖关系都得到适当的处理。

已经证明，事件驱动、资源受限的进度能够有效地处理风险。再启动某个事件之前确定需要证实的成果，能够提供事件在时间上的灵活性、对预期情况的共同理解、对项目状态的更好的观察、以及对项目任务更精确的了解。

典型工作产品

1.       项目进度

2.       进度的依赖

3.       项目预算

子实践

1.       识别主要的里程碑。

经常设置里程碑来保证特定的交付物按里程碑完成。里程碑可以基于事件，也可以基于日历。如果基于日历，一旦里程碑日期得到了一致同意，常常很难修改它。

2.       识别进度的假设。

编制进度时，通常要对特定活动的工期作出假设。这些假设经常是对可用的估算数据较少的事项所做的。识别这些假设提供了对整个进度的置信度（不确定性）的洞察。

3.       识别约束。

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

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

通常，项目的任务能够以某种使得项目持续时间最短的预定顺序完成。这需要为确定最佳顺序而识别任务的先后次序。

5.       定义预算和进度。

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

l         定义资源和设施的承诺或预期的可用性

l         确定活动的时间阶段

l         确定下级进度的分解

l         定义活动之间的依赖关系（前提或者后继关系）

l         定义时间确定的活动和里程碑，以支持进展情况度量的精确性

l         识别将产品交付给用户的里程碑

l         定义工期适当的活动

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

l         根据达到进度与预算的信心程度定义管理上的保留余量

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

l         定义渐进的资金需求

l         将项目组的假设和理由文档化

6.       建立纠正措施准则。

建立了确定那些因素导致项目计划产生重要偏差的准则。为了确定何时应该采取纠正措施，需要建立一个估量各种事项和问题的基础。纠正措施可能要求重新计划，可能包括修订原计划，建立新的协议，或者减缓当前计划中的活动。

SP2.2-1 识别项目风险

识别并分析项目风险。

有关风险管理活动的更多信息请参见风险管理过程域。

有关风险监督活动的更多信息请参见项目监督与控制过程域中的监督项目风险特定实践。

风险被识别或者发现，并且得到分析以支持项目计划。本特定实践应该扩展到所有对项目有影响的计划，以确保所有相关干系人在已识别的风险上有适当的协调关系。项目计划中的风险识别和分析通常包括：

l         识别风险

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

l         区分风险的优先级

典型工作产品

1.       已识别的风险

2.       风险影响和发生概率

3.       风险的优先级

子实践

1.       识别风险。

风险的识别包括识别可能对工作和计划带来不利影响的潜在问题、灾害、威胁、弱点等。风险必须先得到识别和可理解的描述，此后它们才可能得到分析。识别风险时，采用标准的方法来定义风险是比较好的做法。风险识别和分析工具可用于帮助识别可能的问题。

2.       将风险文档化。

3.       评审并获得相关干系人对文档化的风险的完整性和正确性的认可。

4.       适当时修订风险。

SP2.3-1 对（项目的）数据管理进行计划

对项目的数据管理进行计划

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

应当更加一组通用的或者标准的数据要求，在需要创建的数据项以及数据项的内容和形式两个方面为项目建立数据要求。统一数据项内容和形式要求有利于对数据内容的理解，并有助于对数据来源进行一致的管理。

收集每一文档的理由都应该是明确的。本项任务包括分析与验证项目的交付物和非交付物、合同的与非合同的数据要求、以及客户提供的数据。收集数据时往往不明确将要如何使用这些数据。数据是有成本的，因此应该只在需要时才去收集。

典型工作产品

1.       数据管理计划

2.       受管理的主要数据清单

3.       数据内容和格式描述

4.       需方和供方的数据要求清单

5.       私有性要求

6.       保密要求

7.       保密规程

8.       数据获取、再生和发布机制

9.       收集项目数据的时间表

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

子实践

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

并非所有人都有访问项目数据的需要或者经过授权的必要性。必须建立有关规程， 确定何人能在合适访问何种数据。

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

被访问的信息应该是可理解的形式（例如来自数据库的电子的或者计算机的输出）或者再现为初始产生时的形式。

3.       决定需要识别、收集和分发的项目数据。

SP2.4-1计划项目资源

对完成项目必要的资源进行计划。

根据初始的估算定义执行项目活动所需要的项目资源（劳力、机械/设备、材料、以及方法）和数量，并提供能够用于扩展管理项目所用的WBS 的附加信息。

早期作为估算机制开发的顶层WBS 通常要得到扩展，将这些顶层WBS分解为表示能够独立分配、执行和跟踪的单一工作单元的工作包。进行这种划分以分配管理职责并提供更好的管理控制。WBS 中的每个工作包或者工作产品都应该得到一个唯一的标识符（例如编号）以便跟踪。WBS 可能基于需求、活动、工作产品，或者它们的组合。一份描述WBS 中每个工作包的字典应该是WBS 的补充。

典型工作产品

1.       WBS 工作包

2.       WBS 任务字典

3.       基于项目规模和范围的人力需求

4.       关键设施/装备清单

5.       过程/工作流定义和图表

6.       程序管理要求清单

子实践

1.     确定过程需求。

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

2.     确定人员需求。

项目的人员取决于为了实现分布在WBS 的工作包中的项目需求而对项目需求进行分解得到的任务、角色以及职责。

人员需求必须考虑到每个已识别的职位所需的知识与技能，正如“ 计划需要的知识与技能” 特定实践中定义的那样。

3.     确定设施、装备和部件需求。

大部分项目在某种意义上是独特的，需要某些独特的资产来完成项目的目的。这些资产的及时确定和采办对项目的成功至关重要。

需要交货周期的事项需要早期确定，以决定如何处理它们。即使需要的资产不是独特的，编制一份所有设施、设备、以及部件（例如项目中人员使用的计算机数量、软件应用、办公空间等）的清单能够洞察到经常被忽视的一个工作范围。

SP2.5-1计划需要的知识与技能

计划执行项目所需要的知识与技能。

有关需要纳入项目计划的知识与技能的更多信息请参见组织培训过程域。

对项目的知识传递包括对项目人员的培训和从外部来源获取知识。

人员需求取决于可能用于支持项目执行的知识和技能。

典型工作产品

1.       技能需要清单

2.       员工调配和雇佣计划

3.       数据库（例如技能与培训）

子实践

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

2.       评估已经拥有的知识与技能。

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

根据培训专家的可用性、项目的进度以及业务目标来决定为所需的

知识与技能选择内部培训还是外部采办。

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

SP2.6-1 计划干系人的介入

计划已识别的干系人的介入。

通过识别项目中需要的人员类型和职能来确定项目生存周期中所有阶段的干系人，并描述他们与特定的项目活动的相关性和作用。一根轴表示干系人、另一根轴表示项目活动的两维矩阵是完整识别工作的简便方法。干系人与特定项目阶段中的活动的相关性以及预期的作用可以表示在项目阶段活动轴和干系人轴的交点处。

为了使干系人的输入产生作用，必须仔细地选择相关干系人。对于每项主要的活动，识别受到活动影响的干系人和具备执行该活动所需的技能的干系人。相关干系人的列表将可能随着项目所处的生存周期阶段的变化而变化。然而重要的是保证生存周期后继阶段的相关干系人得到对他们有影响的关于需求和设计决策的早期输入。

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

典型工作产品

1.       干系人介入计划

SP2.7-1 建立项目计划

建立并且保持项目计划的全部内容。

说明所有相关计划事项的文档化的计划是执行或支持项目的个人、团队和组织达成共同的理解、约定和表现所必须的。该计划为了项目而制定，定义工作的所有方面，合理地结合以下内容：项目的生存周期考虑；技术与管理任务；预算和进度；里程碑；数据管理；风险识别；资源和技能要求；以及干系人的识别和介入。基础结构的描述包括项目成员、管理层和支持组织的职责与权力关系。

典型工作产品

1.       总体的项目计划

SG3取得对计划的承诺

对项目计划的承诺已建立并已保持。

为了收到实效，计划需要得到负责实施和支持计划的人员的承诺。

SP3.1-1 回顾对项目有影响的计划

回顾所有对项目有影响的计划以理解项目应承诺的责任。

其它过程域中开发的计划通常包含了与总体项目计划中的要求相类似的信息。这些计划可以提供附加的详细指导，并且应该兼容并支持总体项目计划，以确定谁拥有权力、职责、义务和控制。所有影响项目的计划都应该得到评审，以确保项目成功所需要的对范围、目的、角色、以及关系的共同理解。这些计划中，很多是在每个过程域的“计划该过程”通用实践中描述的。

典型工作产品

1. 对影响项目的各项计划的回顾记录

SP3.2-1 均衡工作和资源的水平

均衡项目计划，以使工作和可利用的、估计可得到的资源相适应。

为了获得相关干系人的承诺，协调估算的和可用的资源之间的差距是至

关重要的。一般通过降低或者推迟技术性能需求、磋商更多的资源、发

现提高生产力的方法、获取外部资源、调整人员的技能组合、或者修订

所有影响项目的计划或进度等方式来得到协调。

典型工作产品

1. 修订的方法和相关的估算参数（例如更好的工具、市售部件的使用）

2. 重新磋商后的预算

3. 修订的进度

4. 修订的需求列表

5. 重新磋商后的干系人协议

SP3.3-1取得对计划的承诺

取得执行和支持项目完成的相关方的承诺。

获得承诺包括项目内外所有相关干系人的介入。作出承诺的个人或组应该相信工作可以在成本、进度和效能约束内完成。通常，临时的承诺足以使得工作得到开展，并且允许进行研究来增强信心，使之达到能够获得完整承诺的水平。

典型工作产品

1. 对承诺的文档化请求

2. 文档化的承诺

子实践

1. 与相关干系人一起识别需要的支持并就承诺进行磋商。

WBS 可以用作检查单， 来确保为所有任务获得承诺。

对干系人的介入的计划应该确定需要作出承诺的所有当事人。

2. 将所有组织级的承诺——包括完整的临时的——文档化，确保适当的签署等级。

承诺必须是文档化的，以确保共同的理解以及跟踪与维护。临时的

承诺应该伴有与关联关系相关的风险的描述。

3. 适当时与高层管理一同评审内部承诺。

4. 适当时与高层管理一同评审外部承诺。

管理层可能具备必要的洞察力和权力来降低与外部承诺相关的风险。

5. 识别项目元素之间和与其它项目和组织单位之间的接口方面的承诺，从而使它们能够的得到监督。

明确的接口说明构成了承诺的基础。

目标的一般实践

GG2 制度化一个已管理的过程

过程被作为一个已管理的过程制度化。

执行的保障

       GP2.1 建立组织的方针

       建立和维持一个用于计划和执行度量与分析过程的组织性方针。

       详尽的细节

这个方针建立了对估算计划参数、作出内部或对外的承诺、以及制订管理项目的计划的组织性的期望。

执行的能力

       GP2.2计划过程

       建立和维持一个用于执行项目计划过程的计划。

       详尽的细节

执行项目计划过程的计划与本过程域中的特定实践所描述的项目计划不同。本通用实践要求的计划应全面地计划本过程域中的所有特定实践，从估算项目的范围直到获得对项目计划的承诺。换言之，特定实践中要求的项目计划应该全面地计划项目工作本身。

GP2.3 提供资源

提供足够的资源用于执行项目计划过程，开发工作产品，以及提供过程的服务。

详尽的细节

项目计划工作可能需要特殊的专业知识、设施与装备。项目计划中的特殊知识可能包括：

l         有经验的估算者

l         进度编制者

l         应用领域的技术专家（例如产品领域和技术）

GP2.4 分配职责

分配执行过程，开发工作产品以及提供项目计划过程服务的职责。

GP2.5 培训人员

必须培训执行和支持项目计划过程的人员。

详尽的细节

引导（过程的）执行

       GP2.6 管理配置

       在适宜的配置管理水平下放置项目计划过程中指定的工作产品。

       详尽的细节

       GP2.7 识别和包含相关的干系人

       对照计划，识别和包含项目计划过程的相关干系人。

详尽的细节

本通用实践不同于本过程域的特定实践中覆盖到的为项目本身计划干系人的介入。

从高层经理、项目经理、项目职能经理（例如系统工程、软件工程、其它科目）、软件工程师、系统工程师、制造工程师、后勤、供应商、客户和其它受到项目影响、或者影响项目的人员中选择相关干系人。

GP2.8 监督与控制过程

       根据计划监督与控制项目计划过程，从而执行过程并进行适当的纠正活动。

详尽的细节

验证（过程的）执行

       GP2.9 客观的评价坚持状况

对照过程的描述、规则、程序，客观评估项目计划过程的坚持状况，并处理未按此执行的相关事宜。

详尽的细节

GP2.10 用更高等级的管理回顾状态

用更高层次的管理回顾项目计划过程中的活动、状态、和结果，并解决问题。