项目生命周期指项目从启动到收尾所经历的一系列阶段。项目阶段通常按顺序排列，阶 段的名称和数量取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其 所在的应用领域。可以在总体工作范围内或根据财务资源的可用性，按职能目标或分项目标、 中间结果或可交付成果，或者特定的里程碑，来划分阶段。阶段通常都有时间限制，有一个 开始点、结束点或控制点。生命周期通常记录在项目管理方法论中。可以根据所在组织或行 业的特性，或者所用技术的特性，来确定或调整项目生命周期。虽然每个项目都有明确的起 点和终点，但具体的可交付成果及项目期间的活动会因项目的不同而有很大差异。不论项目 涉及的具体工作是什么，生命周期都可以为管理项目提供基本框架。

从预测型（或计划驱动的）方法到适应型（或变更驱动的）方法，项目生命周期可以处 于这个连续区间内的任何位置。在预测型生命周期（见 2.4.2.2 节）中，在项目开始时就对产 品和可交付成果进行定义，对任何范围变化都要进行仔细管理。而在适应型生命周期（见 2.4.2.4 节）中，产品开发需要经过多次迭代，在每次迭代开始时才能定义该次迭代的详细范 围。

2.4.1  项目生命周期的特征

项目的规模和复杂性各不相同，但不论其大小繁简，所有项目都呈现下列通用的生命周 期结构（见图 2-8）：

 启动项目；

 组织与准备；

 执行项目工作；

 结束项目。

这个通用的生命周期结构常被用来与高级管理层或其他不太熟悉项目细节的人员进行沟 通。不应把通用生命周期与项目管理过程组相混淆，因为过程组中的过程所包含的活动，可 以在每个项目阶段执行和重复执行，也可以在整体项目层面执行和重复执行。项目生命周期 独立于项目所生产（或改进）的产品的生命周期。但项目应该考虑该产品当前所处的产品生 命周期阶段。通用的生命周期结构从宏观视角为项目间的比较提供了通用参照，即使项目的 性质完全不同。

图 2-8  通用项目生命周期结构中典型的成本与人力投入水平

通用的生命周期结构具有以下特征：

 成本与人力投入在开始时较低，在工作执行期间达到最高，并在项目快要结束时迅速 回落。这种典型的走势如图 2-8 所示。

 图 2-8 中成本和人力投入的典型走势可能并不适用于所有项目。有的项目在生命周期 早期支出较大，以确保所需资源到位，例如，在生命周期很早的时点就配备全部人员。

 风险与不确定性在项目开始时最大，并在项目的整个生命周期中随着决策的制定与可 交付成果的验收而逐步降低（见图 2-9）。

 在不显著影响成本的前提下，改变项目产品最终特性的能力在项目开始时最大，并随 项目进展而减弱。图 2-9 表明，做出变更和纠正错误的成本，随着项目越来越接近完 成而显著增高。

上述特征在几乎所有项目生命周期中都存在，但是程度有所不同。特别是采用适应型生 命周期，就是为了把干系人的影响一直保持在比预测型生命周期中更高的水平，而把变更的 成本一直保持在更低的水平。  

图 2-9  随项目时间而变化的变量影响  

在通用生命周期结构的指导下，项目经理可以确定需要对哪些可交付成果施加更为有力 的控制，或者，哪些可交付成果完成之后才能完全确定项目范围。大型复杂项目尤其需要这 种特别的控制。在这种情况下，最好能把项目工作正式分解为若干阶段。

2.4.2  项目阶段

一个项目可以划分为任意数量的阶段。项目阶段是一组具有逻辑关系的项目活动的集合， 通常以一个或多个可交付成果的完成为结束。如果待执行的工作具有某种独特性，就可以把 它们当做一个项目阶段。项目阶段通常都与特定的主要可交付成果的形成相关。一个阶段可 能着重执行某个特定项目管理过程组中的过程，但是也会不同程度地执行其他多数或全部项 目管理过程。项目阶段通常按顺序进行，但在某些情况下也可重叠。各阶段的持续时间或所 需投入通常都有所不同。具备这种宏观特性的项目阶段是项目生命周期的组成部分。

采用项目阶段结构，把项目划分成合乎逻辑的子集，有助于项目的管理、规划和控制。 阶段划分的数量和必要性及每个阶段所需的控制程度，取决于项目的规模、复杂程度和潜在 影响。但不论项目被划分成几个阶段，所有的项目阶段都具有以下类似特征：

 各阶段的工作重点不同，通常涉及不同的组织，处于不同的地理位置，需要不同的技 能组合。

 为了成功实现各阶段的主要可交付成果或目标，需要对各阶段及其活动进行独特的控 制或采用独特的过程。重复执行全部五大过程组中的过程（如第 3 章所述），可以提 供所需的额外控制，并定义阶段的边界。

 阶段的结束以作为阶段性可交付成果的工作产品的转移或移交为标志。阶段结束点是 重新评估项目活动，并变更或终止项目（如果必要）的一个当然时点。这个时点可称 为阶段关口、里程碑、阶段审查、阶段门或关键决策点。在很多情况下，阶段收尾需 要得到某种形式的批准，阶段才算结束。

尚没有适用于所有项目的最佳结构。尽管行业惯例常常引导项目优先采用某种结构，但 同一个行业内甚至同一个组织中的项目仍然可能大不相同。有些项目仅有一个阶段，如图 2-10 所示，有些项目则有两个或多个阶段。  

图2-10  单阶段项目的例子

有些组织已经为所有项目制定了标准化的结构，而有些组织则允许项目管理团队自行选 择和裁剪最适合其项目的结构。例如，某个组织可能将可行性研究作为常规的项目前工作， 某个组织将其作为项目的第一个阶段，而另一个组织则可能视其为一个独立的项目。同样地， 某个项目团队可能把一个项目划分成两个阶段，而另一个项目团队则可能把所有工作作为一 个阶段进行管理。这些在很大程度上取决于具体项目的特性及项目团队或组织的风格。

2.4.2.1  阶段与阶段的关系

当项目包含一个以上的阶段时，这些阶段通常按顺序排列，用来保证对项目的适当控制， 并产出所需的产品、服务或成果。然而，在某些情况下，阶段交叠或并行可能有利于项目。

阶段与阶段的关系有两种基本类型：

 顺序关系。在顺序关系中，一个阶段只能在前一阶段完成后开始。图 2-11 的例子中， 项目的三个阶段完全按顺序排列。其按部就班的特点减少了项目的不确定性，但也排除了缩短项目总工期的可能性。

图2-11  三阶段项目的例子

 交叠关系。在交叠关系中，一个阶段在前一阶段完成前就开始（见图 2-12）。这有时 可作为进度压缩的一种技术，被称为“快速跟进”。阶段交叠可能需要增加额外的资 源来并行开展工作，可能增加风险，也可能因尚未获得前一阶段的准确信息就开始后 续工作而造成返工。  

图 2-12  阶段交叠项目的例子

对于多阶段项目而言，各个阶段之间可能存在不同的关系（交叠、顺序、并行）。所需达 到的控制水平和效果，以及所存在的不确定性程度，决定着应该采用何种阶段与阶段的关系。 基于这些因素，上述两种关系可能在同一个项目的不同阶段间发生。

2.4.2.2  预测型生命周期

预测型生命周期（也称为完全计划驱动型生命周期）是项目生命周期的一种，在项目生 命周期的尽早时间，确定项目范围及交付此范围所需的时间和成本。如图 2-13 所示，项目经 过一系列顺序或交叠的阶段，其中每个阶段通常关注一组项目活动和项目管理过程。每个阶 段的工作通常与前续阶段和后续阶段有本质的差别，项目团队的组成和所需技能也因阶段而 异。  

图 2-13 预测型生命周期的例子

项目启动时，项目团队专注于定义产品和项目的总体范围，然后制定产品（及相关可交 付成果）交付计划，接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增 范围，则需要重新计划和正式确认。

以下情况优先选择预测型生命周期：充分了解拟交付的产品，有厚实的行业实践基础， 或者整批一次性交付产品有利于干系人。

即使采用了预测型生命周期，仍可使用滚动式规划的概念。先编制一份高层级的概要计 划，再随新工作的临近、资源得到分配，针对某个合理的时间段编制更详细的计划。

2.4.2.3  迭代和增量型生命周期

在迭代和增量型生命周期中，随着项目团队对产品的理解程度逐渐提高，项目阶段（也 称为迭代）有目的地重复一个或多个项目活动。迭代方法是通过一系列重复的循环活动来开 发产品，而增量方法是渐进地增加产品的功能。迭代和增量型生命周期同时采用迭代和增量 的方式来开发产品。

采用迭代和增量方式的项目也可以按阶段推进，迭代本身可以顺序或交叠进行。一次迭 代中，将执行所有项目管理过程组中的活动。每次迭代结束时，将完成一个或一组可交付成 果。后续迭代可能对这些可交付成果进行改进，也可能创造新的可交付成果。每次迭代中， 项目团队都综合考虑反馈意见，对可交付成果进行增量修补，直到符合阶段出口标准。

在大多数迭代生命周期中，都会制定一个高层级的框架计划以指导整体实施，但一次只 针对一个迭代期制定详细的范围描述。通常，随着当前迭代期的范围和可交付成果的进展， 开始规划下一个迭代期的工作。完成一组既定的可交付成果所需的工期和投入可能发生变化， 项目团队在迭代期之间或之内也可能发生变化。对那些不属于当前迭代期工作范围的可交付 成果，通常只需要简单概述，暂且留给未来的某个迭代期实施。一旦迭代期工作开始，就需 要仔细管理该迭代期的工作范围变更。

以下情况优先选择迭代和增量型生命周期：组织需要管理不断变化的目标和范围，组织 需要降低项目的复杂性，或者，产品的部分交付有利于一个或多个干系人，且不会影响最终 或整批可交付成果的交付。大型复杂项目通常采用迭代方式来实施，这使项目团队可以在迭 代过程中综合考虑反馈意见和经验教训，从而降低项目风险。

2.4.2.4  适应型生命周期

适应型生命周期（也称为变更驱动方法或敏捷方法），其目的在于应对大量变更，获取干 系人的持续参与。适应型生命周期也包含迭代和增量的概念，但不同之处在于，迭代很快（通 常 2～4 周迭代１次），而且所需时间和资源是固定的。虽然早期的迭代更多地聚焦于规划活 动，但适应型项目通常在每次迭代中都会执行多个过程。

应该把项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完 项）。在迭代开始时，团队会确定产品未完项中的哪些最优先项应该在下一次迭代中交付。在 每次迭代结束时，应该准备好产品以供客户审查。但这并不意味着客户需接受交付，而只是 为了确认产品中没有未完成、不完整或不可用的功能。发起人和客户代表应该持续参与项目， 在可交付成果的创建过程中提供反馈意见，从而确保产品未完项能反映他们的当前需求。

以下情况优先选择适应型方法：需要应对快速变化的环境，需求和范围难以事先确定， 或者，能够以有利于干系人的方式定义较小的增量改进。