项目生命周期
项目生命周期（Project Life Cycle）
目录 |
项目的生命周期是描述项目从开始到结束所经历的各个阶段，最一般的划分是将项目分为 "识别需求、提出解决方案、执行项目、结束项目"四个阶段。实际工作中根据不同领域或不同方法再进行具体的划分。在项目生命周期运行过程中的不同阶段里，由不同的组织、个人和资源扮演着主要角色。
当需要被客户（愿意提供资金，使需求得到满足的个人或组织）所确定时，项目就诞生了。例如，对于一个正在扩大的家庭来说，可能会需要一间更大些的房子，而对于一个公司来说，问题可能是制造过程的高废品率使它的成本高于期竞争对手，产品生产时间长于竞争对手。客户必须得到确定需求或问题，有时问题会被迅速确认，如在灾难（例如地震或爆炸）发生时。而在另外一些情况下，可能会花去几个月的时间，顾客才能清晰地确认需要，收集问题的有关资料，确定解决问题的个人、项目团队或承约商所需满足的条件。
项目生命周期确定了项目的开端和结束。例如，当一个组织看到了一次机遇，它通常会做一次可行性研究，以便决定是否应该就此设立一个项目。对项目生命周期的设定会明确这次可行性研究是否应该作为项目的第一个阶段，还是作为一个独立的项目。
项目生命周期的设定也决定了在项目结束时应该包括或不包括哪些过渡措施。通过这种方式，我们可以利用项目生命周期设定来将项目和执行组织的连续性操作链接起来。项目的整个生命周期由项目的各个阶段构成，每个项目阶段都以一个或一个以上的工作成果的完成为标志。
项目生命周期的第1阶段涉及需求、问题或是机会的确认能导致客户向个人、项目团队或是组织（承约商）征询需求建议书，以便实现已确认的需求或解决问题。具体要求通常由客户在一个叫做需求建议书（request for proposal, RFP）的文件里注明。通过RFP，客户可以要求个人或承约商提交有关他们如何在成本约束和进度计划下解决问题的申请书。一对需要新房的夫妇，可能会花时间来确认对房子的要求——大小、样式、风格、房间数、地点、他们预算能药的最大钱数以及他们想搬进去的日期，他们可能会写下这些要求，然后要求几个承约商分别提供房屋计划和成本估算。一个把升级它的计算机系统作为需求的公司，可能会以RFP的方式把它的需求用文件证实下来，并把文件分别送给几家计算机咨询公司。然而，并不是所有的情况下都有一个正式的RFP。如在一组单个个体之间召开的会议或讲座人们通常会很随便地定义需求。某些人可能会自愿或是被要求准备一份申请书，以决定项目是否由其承担，并满足需求。这类情况可能是医院的管理层想为本医院雇员的孩子们建造一个当地的日护理中心，管理团队或某个经理可能会在文件里写下这些要求，交给一个内部项目团队，而内部项目团队将会提交一份有关如何建立护理中心的申请书。在这种情况下，承约商是医院自己内部的项目团队，客户是医院的经理或者可能是董事会。确定一个正确的需求是很重要的。例如，某个需求是要提供一个体地的护理中心，还是旨在为医院雇员的孩子提供幼儿护理？“本地”是需求必不可少的组成部分吗？
项目生命周期的第2个阶段，是提出解决需求或问题的方案。这个阶段将会导致某个人或更多的人、组织（承约商）向客户提交申请书，他们希望客户为今后成功执行解决方案而付给他们酬劳。在这个阶段，承约商的努力变得很重要。对回复RFP感兴趣的承约商，可能会花几个星期时间来提出一种解决问题的方案，并估计所需资源的种类、数量，设计执行解决方案所需花费的时间。每个承约商都会以书面申请的方式，把有关信息用文件的方式证实下来。所有的承约商都把申请书提交给客户。例如，几个承约商可能会同时向一个客户提交有关开发和执行一个自动开发票和结帐系统的申请书。在客户评估了申请书并选出中标者后，客户和中标的承约商将协商签署合同（协议）。在许多情况下，可能并不会有外部承约商的参与和竞争需求建议书，以最终取得项目执行权。公司自己内部的项目团队，就可能提出一份响应管理者所定义的需求的申请书。在这种情况下项目将由公司自己的雇员执行，而不是由外部承约商执行。
项目生命周期的第3个阶段是执行解决方案。此阶段开始于客户已决定了哪个解决方案将能最好地满足需求，客户与会上人或提交申请书的承约商之间已签订了合同后。此阶段即执行项目阶段，包括为项目制定详细的计划，然后执行计划以实现项目目标。在执行项目期间，将会使用到不同类型的资源。例如，有关设计并建造一幢办公楼的项目，项目努力的方向可能首先包括由几个建筑师和工程师制定一个建楼计划。然后，在建设工程进行期间，大量增加所需资源，包括炼钢工人、木匠、电工、油漆工等等。项目在盖好楼之后结束，少数其他工人将负责完成美化环境的工作和最后的内部装修。此阶段将会导致项目目标的最终实现。使客户满意于整个工作高质量地在预算内按时完成。例如，如果一个承约商已经完成了客户自动系统的设计、安装，并且系统顺利通过绩效测试，客户也接受了此自动系统；或是公司内部的项目团队已按管理层的要求完成了项目，把公司的两个设备合并成一个，那么这第3个阶段的完成就是圆满的。
项目生命脉周期的最后阶段是结束项目阶段，当项目结束时，某些后续的活动仍需执行。例如，确定一下所有应交付的货物是否已提交给了客户，客户接收了吗？所有的款项已经交付结清了吗？所有的发票已经偿付了吗？这一阶段的一个重要任务就是评估项目绩效，以便从中得知该在哪些方面改善，在未来执行相似项目时有所借鉴。这一阶段应当涉及从客户那儿获取反馈，以查明客户满意度和项目是否达到了客户的期望等活动。同样也应从项目团队那儿得到反馈，以便得到有关示来项目绩效改善方面的建议。
项目生命周期的长度从几个星期到几个不等，依项目内容、复杂性和规模而定。而且，并不是所有项目都必然经历项目生命周期的4个阶段。例如，一组社会志愿者决定，他们要用自己的时间、才智和资源，为远有可归者组织一次进餐比赛，他们可能只涉及第3个阶段——计划和执行，项目生命周期的前两个阶段可能就与这个项目不相关了。同样，如果一家公司的总经理决定改变工厂设备的布局以提高效率，她可能简单地批示，让制造部经理主持这一项目，并用本公司的职工去执行项目。在这种情况下，将不会存在来自外部承约商的书面注建议书。
在另外一些情况下，例如雇佣承约同来重建房屋这一项目，客户可能会以一种不太有内在结构性的、更随便的方式经历项目生命周期的前两个阶段。他可能并不把所有要求都写下来，并要求几个承约商去做估算。相反，他可能会邀请在过去曾为自己或其邻居提供过令人满意的工作的承约商，向其解释一下他想做什么，并且要求这个承约商提供一些引起草案和成本预算。
一般来说，当项目在商业环境中执行时，项目生命周期会以更正式，更有内在结构性的方式展开。当项目由私人或志愿者执行时，项目生命周期则趋向于较随便、不太正式。
大多数项目生命周期的说明具有以下共同的特点：
(1)对成本和工作人员的需求最初比较少，在向后发展过程中需要越来越多，当项目要结束时又会剧烈地减少。
(2)在项目开始时，成功的概率是最低的，而风险和不确定性是最高的。随着项目逐步地向前发展，成功的可能性也越来越高。
(3)在项目起始阶段，项目涉及人员的能力对项目产品的最终特征和最终成本的影响力是最大的，随着项目的进行，这种影响力逐渐削弱了。这主要是由于随着项目的逐步发展，投入的成本在不断增加，而出现的错误也不断得以纠正。
大多数项目生命周期确定的阶段的前后顺序通常会涉及到一些技术转移或转让的，比如设计要求、操作安排、生产设计。在下阶段工作开始前，通常需要验收现阶段的工作成果。但是，有时候后继阶段也会在它的前一阶段工作成果通过验收之前就开始了。当然要在由此所引起的风险是在可接受的范围之内时才可以这样做。这种阶段的重叠在实践中常常被叫"快速跟进"。
我们选择以下项目生命周期的划分方法来解释应用中所采用的方法是有所不同的。这里所给出的案例是具有代表性的，但它们既不是推荐的方法，也不是首选的方法。在每一个案例中，阶段的名称和阶段的主要工作成果是由作者自己确定的。
防御设备的添加。美国国防部1993年2月修订的第5000.2指令明确了一系列添加防御设备的里程牌事件和阶段划分，如下图：
- 导弹需求的确定--以“方案的研究许可”为结束标志。
- 方案探讨和界定--以“方案的演示许可”为结束标志。
- 演示和确定效力--以“开发许可”为结束标志。
- 设计和生产开发--以“生产许可”为结束标志。
- 管理与生产开发--与连续性运作和支持重合。
建筑。莫里斯（Morris）在下图中分析了一个建筑项目的生命周期。
- 可行性--项目陈述，可行性研究和策略规划及许可在该阶段不需要得出对项目取舍的决定。
- 规划和设计--基础设计、成本和进度、合同条款和详细设计。在该阶段末要将主要的合同分包出去。
- 实施--制造、运输、辅助机件、安装、测试。在该阶段来完成全部安装工作。
- 启用和运转--最后测试和维修。在该阶段末全面运行该项设施。
制药。墨菲在下图中解释了在美国开发一种新药品的项目生命周期。
- 发现和甄别--包括基础研究和应用研究，确定可以用作预临床试验的药物。
- 临床前研制--包括为了确定药物安全性和有效性所作的实验和动物试验及其准备工作，并填写新药调查申请表。
- 整理注册--包括Ⅰ、Ⅱ、Ⅲ阶段的临床试验和其准备工作，填写新药申请表。
- 后续工作--包括了由于食品药物管理局对新药申请进行复查所要求做的额外工作。
软件开发。莫切<Mvench>在下图中描绘了一个软件开发的螺旋型模型，在此模型中有四个循环和四个象限。
- 构思求证周期--包括商业需求、确定构思求证的目标，进行概念性的系统设计、设计和构造构思、求证，制定可行性测试计划，进行风险分析以及制作与下一周期连接的接口
- 第一个编制周期--明确系统要求，明确第一期编制的目标，进行逻辑顺序设计，设计和完成第一期编制、制作系统测试计划，完善第一期编制以及制作与下一周期连接的接口。
- 第二个编制周期--明确子系统要求，明确第二期编制的目标，进行具体内容设计、第二期编制，制作系统测试计划，完善第二期编制以及作与下一周期连接的接口。
- 最后一个编制周期--满足单元要求，进行最后的设计。完成最后一期编制，执行单元，子系统，系统以及可行性测试。
项目生命周期中有三个与时间相关的重要概念：检查点（CheckPoint）、里程碑（Mile Stone）和基线（Project Baseline），描述了在什么时候（When）对项目进行什么样控制。
检查点指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个固定"采样"时点，而时间间 隔根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。常见的间隔是每周一次，项目经理需要召开例会并上交周报。
里程碑完成阶段性工作的标志，不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义，我们用一个例子说明：
情况一：你让一个程序员一周内 编写一个模块，前3天你们可能都挺悠闲，可后2天就得拼命加班编程序了，而到周末时又发现系统有错误和遗漏，必须修改和返工，于是周末又得加班了。
情况二：实际上你有另一种选择，即周一与程序员一起列出所有需求，并请业务人员评审，这时就可能发现遗漏并即时修改；周二要求程序员完成模块设 计并由你确认，如果没有大问题，周三、周四就可让程序员编程。同时自己准备测试案例，周五完成测试；一般经过需求、设计确认，如果程序员合格则不会有太大 问题，周末可以休息了。
第二种方式增加了"需求"和"设计"两个里程碑，这看似增加了额外工作，但其实有很大意义：首先，对一些复杂的项目，需要逐步逼近目标，里程碑 产出的中间"交付物"是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间想知道"他们做的怎么样了"是很困难的。其次，可以降低项目风险。通过早 期评审可以提前发现需求和设计中的问题，降低后期修改和返工的可能性。另外，还可根据每个阶段产出结果分期确认收入，避免血本无归。
第三，一般人在工作时 都有"前松后紧"的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理"粒度".
基线指一个（或一组）配置项在项目生命周期的不同时间 点上通过正式评审而进入正式受控的一种状态。基线其实是一些重要的里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立后变化 需要受控制。
项目生命周期可以分成识别需求、提出解决方案、执行项目和结束项目四个阶段。项目存在两次责任转移，所以开始前要明确定义工作范围。 项目应该在检查点进行检查，比较实际和计划的差异并进行调整；通过设定里程碑渐近目标、增强控制、降低风险；而基线是重要的里程碑，交付物应通过评审并开始受控。