CMMI-项目计划中文说明，项目管理必读

能看懂的CMMI官方文档（2：项目计划）

项目计划

目的：

项目计划的目的是制定和维护项目中各类活动的计划。（译者注：凡事预则立，不预则废。一个非日常化工作的、多人组成需要协作完成的项目更是如此）

简介：

项目计划包括如下几个方面：

·制定项目计划

·和项目干系人进行必要的沟通，并达成承诺

·维护已经制定的计划

制定项目计划的起点是产品和项目的需求。（译者注：需求决定了项目的工作内容和成果的价值）

制定项目计划通常的内容包括：估计工作产品和任务的规模和复杂度，确定所需要的资源，同客户协商并达成协议，制定进度表，识别并分析可能的风险；上述内容在制定项目计划过程中往往是交叠进行的（译者注：即没有严格的先后顺序）。

为了完成已经同客户达成的协议，项目计划是执行和控制项目的基础（译者注：没有清晰的、文档化的计划，项目的执行和监控就是没有基础的，也就无法保证协议的完成）。

当项目执行过程中遇到需求变更、同客户达成的协议更改、之前的估计不准确、需要采取措施以解决项目中存在的问题、和改变项目正在采用的过程时，通常需要修订项目计划。本文中会详细描述计划和重新计划的内容。

CMMI中和项目计划相关的内容还包括：需求开发、需求管理、风险管理和技术方案等。

<!--[if !supportLists]-->1 <!--[endif]-->进行项目的估计

进行项目的估计是要搞清楚会影响项目的各种因素，对这些因素有了充分的了解和估计，我们才有足够的信心来制定现实的、可完成项目目标的计划。

影响项目的主要因素包括：

·项目需求，包括产品本身的需求，组织层面的需求，客户的需求，以及其他影响项目的需求

·项目的范围

·确定的任务和工作产品

·技术路线

·选用的项目生命周期模型（如：瀑布模型、增量模型、迭代模型等）

·工作产品和任务的规模和复杂度

·要求的进度表

·历史数据（可以把工作产品和任务的规模和复杂度转换为需要的人日和成本）

·计算得到所需要资源、技能、工作人日和成本的计算方法

我们需要把估算理由和支撑数据等材料提供给项目干系人评审，以便能达成对项目计划的一致意见，也便于项目进展中维护项目计划（译者注：看项目执行过程中同计划估算的偏离程度，才便于进行项目的监控和重计划）。

<!--[if !supportLists]-->1.1 <!--[endif]-->估计项目范围

可以通过建立高层的WBS（工作任务分解）的方法来估计项目的范围。

在项目过程中，贯穿着WBS方法。在项目初期，可以用高层WBS来进行最初的项目估计。制定WBS可以把整个项目分解为相互联系的、便于管理的部分，每个部分也被称为“工作包”。WBS提供了一种用来分配工作量、制定进度表和明确工作职责的机制，以便于项目的计划、组织和控制。

具体操作：

<!--[if !supportLists]-->1） <!--[endif]-->基于产品架构进行WBS工作任务分解

WBS提供了围绕要完成的工作任务来组织项目的一种机制，即可以根据用WBS分解之后的工作任务来：

·识别项目风险及其确定缓解措施

·明确交付件和项目支持的活动

·分析需要提供的知识和技能

·制定相关的计划，如配置管理计划、质量保证计划和测试计划

<!--[if !supportLists]-->2） <!--[endif]-->高层WBS可以用来帮助计算项目所需的工作量，并进行职责的分配。WBS越是详细，就越有助于帮助项目制定更为现实的进度表，从而减少管理上预留时间的必要。

<!--[if !supportLists]-->3） <!--[endif]-->确定需要外部提供的产品或功能组件

可以参考“供应商管理”部分，了解如何从外部来源获取项目所需要的产品或功能组件。

<!--[if !supportLists]-->4） <!--[endif]-->确定可以重用的工作产品

<!--[if !supportLists]-->1.2 <!--[endif]-->估计工作产品和任务的规模和复杂度

很多估算模型都首选“规模”作为估计工作量、成本和进度的输入条件；其他条件还包括相互之间的关联性、复杂度等。

可用来衡量规模的指标包括：

·功能点的个数

·源代码行数

·类和对象的数量

·需求的数量

·接口数量和复杂度

·文档的页数

·输入和输出的数量

·技术上存在的风险的数量

估算应该和项目需求保持一致，这样才能确定出项目的工作量、成本和进度。每一个被估算的个体，都应该估计它的难度或复杂度。

具体操作：

<!--[if !supportLists]-->1） <!--[endif]-->确定项目的技术路线

技术路线确定了产品开发的总体策略，包括在架构层面上的决策，如：采用分布式结构还是C/S结构，采用最新的还是成熟的技术，对和功能相关的安全性、人体工程学上的考虑

<!--[if !supportLists]-->2） <!--[endif]-->用恰当的方法确定项目中各项工作的规模和复杂度，以便确定资源的需求

应该用估算模型和历史数据来确定规模和复杂度。并且随着我们对产品特性理解的加深，我们对产品规模和复杂度的认识也会加深。

用来确定规模和复杂度的方法包括：

·软件代码行或功能点的个数

·需求的个数和复杂度

<!--[if !supportLists]-->1.3 <!--[endif]-->确定项目的生命周期模型（即项目所采用软件开发过程）

确定项目生命周期模型，也就确定了项目中计划进行评估和决策的周期和决策点，在这些决策点，我们会就下一步的资源投入以及技术路线的抉择达成一致的意见；并提供对项目进行修正的机会，以确定下一步工作的范围和需要投入的成本。

项目生命周期模型的确定，取决于项目需求的范围、项目所需要资源的估计，以及项目本身的性质。大项目通常都会包括多个阶段，如概念挖掘、开发、生产、实施和部署；每个阶段还有可能包含子阶段。如开发阶段可包括需求分析、设计、编码、集成、验证等子阶段。通常要对一种或多种开发模型进行选择和提炼，才能确定项目阶段，主要是为了能体现出各阶段中项目活动相互之间的关系和顺序。

根据开发策略的不同，我们可以选择的生命周期模型包括：瀑布型、原型法、增量模型和螺旋型等。

对项目所采用生命周期模型的理解，能在很大程度上决定：制定项目计划的工作范围和项目初始计划完成的时间，以及项目计划调整的时间点和关键里程碑。

<!--[if !supportLists]-->1.4 <!--[endif]-->估算工作量和成本

采用恰当的方法来估算项目中工作产品和任务的工作量和成本。

工作量和成本的估算通常是通过使用估算模型或者参照历史数据对本项目的规模、项目活动和其他因素进行分析得出的。对这些估算的信心来自于选择的估算模型和历史数据是否恰当，是否在逻辑上合理。有时候会出现没有可用的历史数据信息，例如项目工作量巨大、前所未有，或者任务的类型不符合估算模型等等。如果开发的产品或组件是全新的，工作量在一定程度上是很难估计的。如果当前开发团队之前没有开发过类似的产品或组件，也很难估计工作量。

难以估计工作量的工作就意味着更大的风险，需要更多的研究才能制定出合理的估算值，也要求在管理层面上给与更多的预留。

在项目最初计划时，由于项目的独特性会做出一些假定，后续使用估算模型时要把项目的独特性记录下来，这样才能确保对这些假设和估算模型的使用达成一致的理解。（译者注：否则其他人就无法理解为什么看似项目有自己的独特性，还能使用通用的估算模型来进行估算）

具体操作：

<!--[if !supportLists]-->1. <!--[endif]-->通过选择好的估算模型和历史数据，把工作产品和任务的特性转换为工作量和成本的估算值

已经有很多带有输入条件的估算模型可以辅助工作量和进度的估算。这些模型最好不要作为估算的唯一方式，因为这些模型所基于的历史数据有可能对你所在的项目是不适合的。使用多种估算模型和方法能保证估算结果的可信度。

可以使用已经完成项目的历史数据，包括成本、工作量和进度等，再加上项目规模和复杂度等不同，乘以恰当的比例系数，来进行估算。

<!--[if !supportLists]-->2. <!--[endif]-->在估算工作量和成本的时候，要考虑到项目所采用的基础支撑架构的情况

基础支撑架构包括开发和未来产品维护所需要的资源，如开发环境、测试环境、生产环境、目标用户环境，以及上述环境的组合情况，这些都应在工作量和成本估算中予以考虑。（译者注：例如Linux/Unix上的编译调试等对于一般的开发团队而言，需要的工作量就会比Windows大）

基础支撑架构的例子如下：

·关键的计算机资源，如内存、磁盘、网络带宽、外围设备、信息交流渠道等

·工程设计环境和工具，如原型工具、装配器、计算机辅助设计和模拟器等

·设施、机器和装备，如测试机床和记录设备

<!--[if !supportLists]-->3. <!--[endif]-->使用模型和历史数据来估算工作量和成本

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

·采用专家或专家组的估算方法，如德尔菲法

·风险，包括难以估算的工作量的影响

·完成某项工作所需要的关键的人员和角色

·技术路线

·WBS工作分解

·工作产品的预计规模大小和预期的变更

·需要外部提供的产品的成本

·生命周期的成本估算

·在工程环境中用到的工具的容量（译者注：如项目只有唯一的一套联合调试环境，可同时供多少人并发使用，决定了缺陷解决的速度）

·管理者的技能水平，工作执行团队成员的技能水平

·知识、技能和培训的需要

·需要的设施，如办公室和会议室的空间和环境需要

·工程设施的需要

·制造过程的能力

·传输（译者注：可能是制造生成车间中加工品在生产线上的传输）

·任务、工作产品、硬件、软件、人员和工作环境的安全程度的需要

·符合呼叫服务中心和维修工作的要求（译者注：即可服务性需求）

·直接劳动和开销

<!--[if !supportLists]-->2 <!--[endif]-->制定项目计划

项目计划的制定和维护是项目管理的基础。

项目计划是正式的、被批准的文件，用来管理和控制项目的执行。项目计划的制定应基于项目需求和已经确定的项目估算。

项目计划应该考虑到项目生命周期的所有阶段。应确保影响项目的所有领域计划都遵从于项目总体计划。

<!--[if !supportLists]-->2.1 <!--[endif]-->制定项目预算和进度表

项目的预算和进度表是基于之前已完成的估算制定的，且在预算的分配、任务的复杂性、任务的依赖关系上都是经过了认真的考虑。

在应对项目风险上，采用事件驱动型的进度安排在资源受限时被证明是行之有效的。事件驱动型指的是通过具体事情的开展来驱动项目进展，在某个事情启动之前要先明确要达到的效果，这样时间安排上更为灵活，也容易对具体事情的期望达成一致的理解，便于更好的了解项目当前的整体状态和项目中各项任务更为精确的状态。

具体操作：

<!--[if !supportLists]-->1． <!--[endif]-->确定主要里程碑

我们常常通过制定里程碑来确保在里程碑时特定的交付件能完成。里程碑可以基于事件或者基于日期来制定。如果基于日期来制定，一旦对里程碑的时间达成一致，通常就很难再改变。

<!--[if !supportLists]-->2． <!--[endif]-->确定进度安排的假定条件

当一开始制定进度表时，通常都会对一些活动所需要花费的时间周期进行一些假设。尤其是当很少有估算数据能提供明确的信息时，经常会设定一些假设条件来便于进行时间估算。明确出这些假定条件，我们才能洞察整个进度表的不确定程度。

<!--[if !supportLists]-->3． <!--[endif]-->识别约束条件

应尽可能早的识别出限制工作开展方式上灵活性的因素。通常考察工作产品和任务的属性（包括任务的持续时间、资源需要、输入和输出等）能把这些问题带出水面。

<!--[if !supportLists]-->4． <!--[endif]-->识别任务的依赖关系

项目的任务通常可以按照一定的次序来排列，可使得项目的周期最短。这就需要识别一个任务的前置任务和后续任务，以便能优化工作次序。

能够帮助决定任务活动优化次序的工具包括：

·关键路径法

·PERT法（程序评价和评审技术）

·资源受限的进度安排

<!--[if !supportLists]-->5． <!--[endif]-->确定预算和进度表

制定和维护项目预算和进度表，通常包括以下任务：

·明确已经得到承诺的或者预期可提供的资源和设施

·把项目中的活动划分到各个阶段中

·确定各个子进度表的起至时间

·明确各项活动之间的依赖关系（前置关系或者后续关系）

·明确和活动的进度表以及里程碑，保证过程度量的精确性

·识别要把产品交付给客户的里程碑时间点

·确定每项活动恰当的持续时间

·确定里程碑的恰当时间划分

·根据汇总后的进度安排和预算的可信度，定义出管理上的预留

·使用恰当的历史数据来校验进度表

·记录项目的假定条件和基本原则

<!--[if !supportLists]-->6． <!--[endif]-->建立纠正措施触发的标准

要制定一个触发标准，决定什么是项目计划的显著偏差；当偏差达到触发标准，就必须采取纠正措施来解决问题。为了能知道何时应采取纠正措施，有必要对事情和问题进行计量。纠正措施可以要求重新计划，包括修订原始计划达成新的一致，或者在当前计划内降低对部分活动的要求等。

<!--[if !supportLists]-->2.2 <!--[endif]-->识别项目风险

可参考“风险管理”部分和“项目监控”的“监控项目风险”了解风险管理活动的更多信息。

为了支持项目计划是现实可行的，我们有必要识别和分析项目中存在的风险。项目中制定各领域计划时，都应进行风险管理，并确保对风险的相关干系人进行了恰当的沟通。项目计划的风险识别、分析通常包括以下内容：

·识别风险

·分析风险以确定风险的影响程度、发生的概率，以及问题可能发生的时间段

·对风险进行优先级排序

具体操作：

<!--[if !supportLists]-->1， <!--[endif]-->识别风险

进行风险的识别可以从潜在问题、危险、威胁、弱点以及诸如此类会对工作成果和计划产生负面影响的东西出发来发掘。识别出风险，并用大家都能理解的方式进行描述风险，以便于进行风险的分析。在识别风险的过程中，使用一种标准的方法来定义风险是一个好主意。风险识别和分析工具能提供一些帮助。

风险识别和分析工具的例子如下：

·风险的分类体系

·风险的评价

·检查列表

·结构化的评审

·头脑风暴

·工作情况模型

·成本模型

·网络分析

·质量因素分析

<!--[if !supportLists]-->2， <!--[endif]-->把风险记录到文档中

<!--[if !supportLists]-->3， <!--[endif]-->和相关干系人回顾风险，并在对风险的处理上取得一致的意见

<!--[if !supportLists]-->4， <!--[endif]-->进行恰当的风险修订

已经识别的风险在下列时候需要被修订：

·当新的风险被识别时

·当风险转换为问题时

·当风险消除时

·当项目情况发生显著变化时

<!--[if !supportLists]-->2.3 <!--[endif]-->制定资料管理计划

这里所讲的“资料”指的是各种类型的、用来在某领域内发挥作用的文件；领域可以包括：管理、工程、配置管理、金融、后勤、质量、安全、制造和采购等。资料的外在形式可以是任意的，包括：报告、手册、笔记、图表、图形、说明书、文件或者信件等。资料可以存储在任意介质上，既可以是打印出来的，也可以是在不同材料上绘制的，还包括照片、电子或者多媒体形式的。资料可以是需交付给客户的，如在项目合同中要求的内容，也可以是无需交付的，如非正式的文档、商务研究和分析、内部会议记录、内部设计评审文档、经验教训和行动项等。资料的分发也可以采取多种形式，包括物理介质的或电子方式的传输。

项目的资料需求既要考虑要生成的资料的内容，也要考虑它的形式；应基于共同的资料需求标准。对于资料条目统一的目录和格式要求有助于促进对于资料内容的理解，以及对于资料资源的一致性管理。

收集资料这项任务包括对于项目中交付件和非交付件的分析和确认，合同内外的资料需求的确认，以及客户提供的资料等。我们对于收集每一个文档的原因应该很清晰，通常存在的问题是：收集资料时并没有对如何使用这些资料有清晰的认识。资料的编写制作是昂贵的，应该只在需要时才制作并收集资料。

具体操作：

<!--[if !supportLists]-->1， <!--[endif]-->明确对资料的需求和访问程序以确保资料的隐私和安全

不是每一个人有访问项目资料的明确需要。必须建立一定的程序来识别谁、在哪些时候有访问哪些资料的权限。

<!--[if !supportLists]-->2， <!--[endif]-->建立一个机制能对资料进行存档管理，并且能访问到存档的资料

被访问的资料应该以一种能理解的形式来展现，例如电子的或数据库的输出，或者以原始产生的形式展现。

<!--[if !supportLists]-->3， <!--[endif]-->确定需要被识别、收集和发布的项目资料

<!--[if !supportLists]-->2.4 <!--[endif]-->制定项目资源计划

在最初估计的基础上，确定项目对各类资源（包括劳动力、机器设备、原料等）的需要，并确定所需要的数量，通过扩展WBS能获得更为准确的数据。

高层WBS的制定在早期通常作为估算工具，之后再扩展WBS，即把这些高层WBS再分解为工作包，每个工作包代表这一个独立的工作单元，也就是每个工作包都是能被独立分派的任务，并可执行和追踪。这种分解方法可以用来分解管理职责，并提供更好的管理上的控制。WBS中的每个工作包或工作产品都应有一个唯一的标识码（如数字），以便可以追踪。一个WBS可以基于需求、项目活动、工作产品或者这些内容的组合而制定出来。每个WBS都应该配备字典来描述其工作包中工作内容的含义。

具体操作：

<!--[if !supportLists]-->1， <!--[endif]-->确定对软件开发过程的要求

应事先确定好用来管理项目的过程，并与所有相关干系人进行协调，以确保在项目执行过程中能高效的运作。

<!--[if !supportLists]-->2， <!--[endif]-->确定人员需求

在把项目需求分解为WBS的工作包后，通过工作包中所列出的任务、角色、责任，来确定项目需要哪些人员。

人员需求必须考虑对每一个已经明确的岗位所需要的知识和技能，这些应在“需要的知识和技能计划”中定义。

<!--[if !supportLists]-->3， <!--[endif]-->确定设施、设备等的需求

通常而言，大多数项目都是独特的，需要一些独特的资源才能达成项目目标。及时的确定和获取这些资源对项目的成功非常关键。

必须提前明了所需要的资源从订货到交货的时间，以便确定这些资源何时能到位。即便这些需要的资产不是独特的时，整理一个所需要的设施、设备、个人用机、软件、办公场地等需求的列表，能明确在这些方面需要投入的工作，防止被遗忘。

<!--[if !supportLists]-->2.5 <!--[endif]-->制定知识和技能的计划

可以参考“组织培训”来了解更多的、项目计划中的关于知识和技能方面的内容。

项目获得所需要的知识包括对项目成员进行培训和从项目外部获取两个途径。

项目对人员的需求依赖于完成项目的所需要的知识和技能。（译者注：即完成项目需要一定的知识和技能，而项目所需要的人应具备这些知识和技能）

具体操作：

<!--[if !supportLists]-->1， <!--[endif]-->明确完成项目需要什么样的知识和技能

<!--[if !supportLists]-->2， <!--[endif]-->评估目前项目已有的知识和技能

<!--[if !supportLists]-->3， <!--[endif]-->选择获取所需要的知识和技能的方式

可选择的方式包括：

·内部培训，包括组织提供的和项目自己提供的

·外部培训

·雇佣掌握这些知识和技能的员工

·从外部获取（译者注：例如请专家作为顾问指点等）

选择内部培训还是外部培训来获取项目所需要的知识和技能，取决于如何确定培训老师、项目的进度安排，以及商业目的。

<!--[if !supportLists]-->4， <!--[endif]-->把已经选定的方式纳入项目计划

<!--[if !supportLists]-->2.6 <!--[endif]-->计划项目干系人的参与

我们可以从项目生命周期的各个阶段中认识到和项目相关的干系人（风险承担人），方法是：辨别需要介入项目的各类人员及职能，并描述他们同项目中具体活动的关系和相互作用的程度。可以用一个二维矩阵，一个轴表示干系人，另一轴表示项目活动，来表示干系人与项目活动之间的关联。干系人和项目阶段中具体活动的关联，通过项目活动轴和干系人轴的交叉处就体现出来了。

为了使干系人的输入信息有效，我们有必要认真的选择项目干系人。对于每个主要活动，都需要识别出会受这项活动影响的人，以及有完成这项任务所需要的专门技能人来作为干系人。干系人列表可随着项目阶段的发展而改变。但是，确保在项目后期才介入的干系人对于会影响他们的需求和设计决策在早期有发言权，是非常重要的。

通常在干系人介入计划中包含的材料类型有：

·所有相关干系人的列表

·干系人介入的理由

·相关干系人对于项目而言，在项目生命周期中的角色和职责

·干系人之间的关系

·对于项目成功而言，干系人的相对重要性

·确保干系人能有效参与的资源，如培训、时间和资金

·干系人参与分阶段的日程安排

<!--[if !supportLists]-->2.7 <!--[endif]-->完成项目计划

为了能形成对项目的一致认识，达成共同承诺，并可衡量参加和支撑项目的个人、团队和组织的绩效，制定一份内容全面的书面文档是必不可少的。

项目计划应包括各个项目各方面的内容，并把这些方面有机的连接在一起；具体包括：对项目生命周期的考虑，关键技术要素，管理组织结构，预算和进度表，里程碑定义，资料管理计划，风险管理，资源和技能需求，项目干系人参与计划。组织结构这部分的内容包括项目成员、管理层和支撑组织之间的责任和职权划分。

对于软件工程，计划文本通常指的是下列的一个：

·软件开发计划

·软件项目计划

·软件计划

<!--[if !supportLists]-->3 <!--[endif]-->取得对计划的承诺

建立并维护对项目计划的承诺

为了使项目计划有效，制定的项目计划需要取得执行和支撑计划的责任人的承诺。

<!--[if !supportLists]-->3.1 <!--[endif]-->审查项目中的各领域计划

审查影响项目中的各领域计划，以了解项目承诺。

项目各领域中的计划（译者注：如质量保证计划、培训计划、风险管理计划等）是项目总体计划中的总体策略在各自职能领域的扩展，领域计划提供了各领域内的详细指导，并和项目总体计划保持一致，以明晰在不同职能领域的职权、责任和控制情况。这些对项目有影响的所有计划都应被审查以确保各领域计划对于项目成功所必须的范围、目标、角色和关系的理解能取得共识。

<!--[if !supportLists]-->3.2 <!--[endif]-->对项目中工作负荷与可提供的资源进行平衡

为了使项目具备可行性，需要从相关干系人获得资源承诺，并在估计需要的资源和可获得资源之间的困难进行平衡和协调。通常可以通过以下方式取得协调一致：降低或推迟技术性能要求，商谈取得更多资源，发现提高生产力的方法，外包，提高项目成员的技能，修订影响项目或进度的领域计划。

<!--[if !supportLists]-->3.3 <!--[endif]-->取得项目所需要的承诺

从各负责执行项目和支持项目的相关干系人处取得承诺。

同所有项目干系人，包括项目内部和外部进行互动交流以取得对项目的承诺。做出承诺的个人或团队应该有信心：工作可以在成本、进度和绩效要求内完成。通常，可以给与一个临时的承诺以便让工作先开始进行一些探索以提高信心直到给与一个正式的承诺。

具体操作：

<!--[if !supportLists]-->1， <!--[endif]-->识别需要的支持，并同相关干系人谈判以取得承诺

WBS能够被用来作为检查列表以确保所有任务都取得了承诺。

“项目干系人参与”计划应识别出：承诺应该从哪些人获得。

<!--[if !supportLists]-->2， <!--[endif]-->所有的组织承诺，包括正式的和非正式的，都应形成文字，并有相应级别的人签署

承诺形成文字，才能确保大家相互理解一致，并可以追溯和维系。非正式的承诺应该被作为风险管理起来（因为它不兑现的概率比较高）。

<!--[if !supportLists]-->3， <!--[endif]-->同相应级别的高层管理者审查内部的承诺

<!--[if !supportLists]-->4， <!--[endif]-->同相应级别的高层管理者审查外部承诺

管理层应有必要的洞察力和职权以降低和外部承诺相关联的风险。

<!--[if !supportLists]-->5， <!--[endif]-->识别项目内各要素之间的接口承诺，以及同其他项目、组织单位之间接口承诺，以便这些承诺能被监控

制定良好的接口规范是这类承诺的基础

在组织层面要建立并形成项目监控的能力，具体内容包括：

<!--[if !supportLists]-->1 <!--[endif]-->建立组织层面对项目计划过程的策略

策略代表着组织对项目计划的过程要求，如对项目规模和负责度的估计的方式方法和准确度要求，达成内部和外部承诺的方式和可信度，开发用来管理项目的计划的投入和专业程度等。

<!--[if !supportLists]-->2 <!--[endif]-->建立和维护执行项目计划的计划

项目计划的制定过程也是需要计划的，尤其是规模稍大的项目的计划，本身也需要一个计划来完成。

<!--[if !supportLists]-->3 <!--[endif]-->提供资源

提供充足的资源以完成项目计划过程和项目相关的成果，并提供过程服务。

在项目计划过程中可能需要组织提供特定领域的专家和设备设施。在项目计划中需要的特定专家可以包括：

·有经验的估算专家

·进度制定专家

·在应用领域的技术专家

其他可能需要的资源包括以下工具：

·电子表格程序

·估算模型

·项目计划和进度表的软件包

<!--[if !supportLists]-->4 <!--[endif]-->分配职责

对于完成：执行制定计划的过程，完成制定计划的成果，以及提供项目计划过程相关的服务等工作，分配相应的职责和职权。

<!--[if !supportLists]-->5 <!--[endif]-->培训人员

为了执行和支撑“项目计划”过程的人员，在需要时应提供培训。

培训的主题可包括：

·估算

·预算

·谈判

·风险识别和分析

·资料管理

·计划

·制定进度

<!--[if !supportLists]-->6 <!--[endif]-->管理配置

把在项目计划过程中产生的工作产品（译者注；即制定项目过程中的各类文档等）置于恰当的控制级别。

工作产品的例子包括：

·工作分解结构（WBS）

·项目计划

·资料管理计划

·干系人参与计划

<!--[if !supportLists]-->7 <!--[endif]-->识别相关干系人并使之参与

干系人参与活动的例子包括如下：

·建立估算

·审查和解决在项目风险中的完备性和正确性的问题

·审查资料管理计划

·制定项目计划

·审查项目计划，并解决在工作和资源方面的问题

<!--[if !supportLists]-->8 <!--[endif]-->监控项目计划过程

根据“制定项目计划的计划”来监控项目计划的制定过程，并采取恰当的纠正措施。

在监控中用到的度量和工作产品包括如下：

·计划的修订次数

·每一次计划修订的成本、进度和工作量

<!--[if !supportLists]-->9 <!--[endif]-->进行客观评价

依据“项目计划过程”的描述、标准和规程，来客观的评价项目计划制定的情况，发现并报告不符合项

可进行审查的活动包括如下：

·建立估算

·制定项目计划

·取得对项目计划的承诺

可进行审查的工作产品包括：

·WBS

·项目计划

·资料管理计划

·干系人参与计划

<!--[if !supportLists]-->10 <!--[endif]-->同高层管理者评估状况

同更高层的管理者一起审查项目计划过程的活动、状况和结果，并解决存在的问题

<!--[if !supportLists]-->11 <!--[endif]-->制度化一个已定义的过程

<!--[if !supportLists]-->11.1 <!--[endif]-->制定一个已定义的过程

制定和维护对于项目计划过程的已定义的描述

<!--[if !supportLists]-->11.2 <!--[endif]-->收集改进信息

收集从计划和执行项目计划过程中的工作产品、度量指标和度量结果，以及改进信息，以支持未来的使用和组织过程的提高，并充实过程资产。

详细解释：工作产品、度量指标、度量结果和改进信息的例子包括：

·项目资料库结构

·项目属性估计

·风险影响度和发生的概率

<!--[if !supportLists]-->12 <!--[endif]-->制度化一个数量管理的过程

<!--[if !supportLists]-->12.1 <!--[endif]-->建立一个对于该过程的度量目标

<!--[if !supportLists]-->12.2 <!--[endif]-->稳定子过程的绩效

<!--[if !supportLists]-->13 <!--[endif]-->制定化优化过程

<!--[if !supportLists]-->13.1 <!--[endif]-->确保持续的过程改进

纠正问题的根本原因