项目的运行周期是指从产生项目概念到交付项目价值的整个时期。由于项目概念的产生时间不一定十分明确,通常可以用项目发起人发布《项目工作说明书》(也可以是类似性质的文件,如《项目简介》《项目建议书》)的时间作为项目运行周期的起始点。由于项目价值的交付可能持续很长时间,不一定有明确的结束时间,通常可以用项目可交付成果完成之后的某种近期价值的交付作为项目运行周期的结束点。如果不做出这样的规定,那就无法体现项目的“临时性”,使项目的起点和终点不明确。
在项目的运行周期之内,既要做技术工作,也要做管理工作,这两类工作相互影响且并行开展。针对技术工作的运行周期,称为“项目生命周期”。针对管理工作的运行周期,称为“项目管理生命周期”或“项目管理过程组”。因为每个项目阶段所做的技术工作不同,所以项目生命周期是通常按先后顺序进行有时会交叉的各个技术工作阶段的集合。因为在每个技术工作阶段所做的管理工作都是类似的,而且对整个项目(把整个项目看作只有一个阶段)也需要开展这些管理工作,所以把这些管理工作归类为统一的项目管理过程组,即启动过程组、规划过程组、执行过程组、监控过程组、收尾过程组。需要注意的是,项目的前期准备工作并未包含在这五大过程组之中。
项目生命周期是项目从开始到结束所经历的一系列技术工作阶段。为了便于管理和控制(如针对每个阶段编制计划、进行监控和开展收尾),而把项目生命周期划分成若干个阶段。每个阶段都有阶段准入标准、应完成的工作和应提交的可交付成果,都需要有阶段验收标准与阶段放行口。阶段划分数量的多少取决于所需的管理和控制程度。所需的管理和控制程度越高,阶段的数量就要越多。阶段的多少与项目工期的长短没有必然联系,而主要取决于所需的管理和控制严格程度。
通常,组织会制定适用于某类项目的项目生命周期标准,作为组织过程资产的一部分,供具体项目裁剪使用。该标准通常只是大框架,仅规定项目必须经历的几个大阶段。
在具体项目启动(立项)之时,项目治理委员会应根据项目生命周期标准以及对本项目开展治理的需要,进一步规定项目阶段划分以及各阶段所需的控制,特别是阶段结束时的项目评审(由治理委员会主持开展)。这些阶段结束点都是重要的决策时点,可在此时决定项目是否需要重大变更甚至提前终止。
在编制具体项目的计划之时,项目经理应根据项目生命周期标准和项目治理委员会的要求,对项目生命周期进行更详细的设计。例如,把已确定的一个大阶段划分成两个较小阶段,并决定采用预测型、迭代型、敏捷型或混合型开发方法。详细设计的结果,应该写入项目管理计划。
项目管理虽然是以目标为导向的,但是也强调对过程的控制。在项目进行的全过程中,每个阶段结束时,都要进行阶段评审,考察应该完成的工作有没有完成,应该提交的可交付成果有没有提交,从而决定能否正式关闭本阶段。阶段评审有利于及时且经济有效地纠正错误。
笼统地讲,任何项目都需要经历启动、组织与准备、执行项目工作和关闭项目这四个阶段。随着项目生命周期的演进,项目对资源的需求逐渐增加,并在执行期间达到最高峰,然后在关闭阶段急剧下降。在项目关闭阶段,对资源的需求必须急剧下降,因为收尾要快,不能拖拖拉拉。
通常,在项目的早期,不确定性大,项目风险多,能为项目增加价值的机会也大,进行项目变更所要付出的代价较小。随着项目的进行,不确定性降低,项目风险减少,增加价值的机会变小,项目变更的代价增大。
项目生命周期是按技术工作来划分项目阶段的,每个阶段都要完成不同的技术任务。例如,可以把建筑施工项目的全过程划分为可行性研究、初步设计、详细设计、施工和移交五个阶段,可以把软件开发项目的全过程划分为需求分析、框架设计、详细设计、编程、调试、安装和移交七个阶段。
对项目生命周期,需要注意以下几点:
· 不同类型的项目有不同的阶段划分。例如,建筑施工项目与软件开发项目的阶段划分就完全不同,因为它们所需完成的技术工作完全不同。
· 每个阶段都可看作一个单独的项目或子项目。是否应该把它看成一个单独的项目或子项目,取决于客观情况及主观需要。
· 通常,一个阶段结束后,才开始另一个阶段,阶段按先后顺序演进。如果所涉及的风险不大,也可在这个阶段结束前就开始下一个阶段,让两个阶段部分交叠。
· 阶段之间也可以是迭代关系,即各阶段的技术工作的种类相似,但越来越精细。
· 如果一个项目包括几个相对独立的部分,各阶段既可能在各个组成部分同步演进,也可能不同步演进。例如,在某个时点,一个组成部分处于这个阶段,而另一个组成部分处于上一个或下一个阶段。
· 一个阶段的结束并不一定意味着下个阶段的开始。严格地讲,批准这个阶段的结束与批准下个阶段的开始,是两件事情,即便这两件事可同时完成。任何一个阶段的结束点,都可能成为项目的结束点(项目不再继续)。
项目生命周期是针对项目的整个运行周期而言的,而开发生命周期只针对项目中的可交付成果的纯技术开发而言。如果项目只开发一个可交付成果,那么项目生命周期和开发生命周期就基本一样,只是项目生命周期在前端和后端都会有一段用来做项目准备和项目收尾的行政工作的时间。如果项目要开发几个可交付成果,那么在一个项目生命周期内就有几个开发生命周期。只有这些开发生命周期都完结,项目生命周期才能完结。
开发生命周期的类型是从预测型到适应型的连续变化区间。采用不同类型的开发方法就会导致采用不同类型的开发生命周期。有以下五种典型的开发生命周期类型:
· 预测型生命周期,也叫计划驱动型生命周期,是先编制好项目计划,详细定义项目产品及所需开展的工作,再严格按计划开展工作并完成已定义好的产品。
· 迭代型生命周期,是通过越来越精细地重复开展同种类的技术工作来不断优化产品功能。例如,磨刀,每轮(每次迭代)都要把刀磨得更锋利。
· 增量型生命周期,是经过一个又一个固定时间段(称为“时间盒”)来逐渐增加产品功能。例如,开发万用刀,先在第一阶段开发出一个功能(价值最大的),再在第二阶段开发出第二个功能(价值第二大的)……
· 混合型生命周期,是预测型和其他类型的混合。例如,在同时包含硬件可交付成果和软件可交付成果的开发项目中,对硬件部分用预测型,对软件部分用适应型。
· 适应型生命周期,也叫敏捷型或变更驱动型生命周期,是迭代型和增量型的混合。在许多项目中,既不能只是迭代开发,也不能只是增量开发,而必须两者结合。开展迭代,是因为不可能一次就做好某个功能;进行增量开发,是因为不可能一次就做全所有功能。
开发生命周期的类型决定了项目生命周期的类型,即如果开发生命周期是适应型的,那么项目生命周期也是适应型的。引入“开发生命周期”这个概念的好处是:防止人们滥用敏捷型方法。通常,敏捷型方法只能用于产品功能开发(针对开发生命周期),而不能用于整个项目的实施。如果对整个项目采用敏捷型方法,就会出现不应有的混乱。
为简便起见,下文统一使用“项目生命周期”术语。除非特别需要,不再使用“开发生命周期”术语。
应该尽早考虑该采用何种项目生命周期。预测型生命周期是编好计划再去做,适应型生命周期是一边做一边变。简单地说,可以根据项目的需求和技术的易变程度来选择合适的项目生命周期类型(见图3-1)。
图3-1 项目生命周期的主要决定因素
· 需求清晰且所需技术确定,就用预测型生命周期。
· 需求清晰但所需技术不明,就用迭代型生命周期。
· 需求模糊但所需技术确定,就用增量型生命周期。
· 需求模糊且所需技术不明,就用适应型生命周期。
以新产品研发为例。如果一开始就知道产品须具备三个特定功能,以及这些功能须采用什么技术去实现,那就用预测型生命周期(见图3-2);如果一开始只知道须具备三个特定功能,但不知道须采用的实现技术,那就用迭代型生命周期去摸索技术(见图3-3);如果一开始只知道其中的一个功能及其实现技术,那就用增量型生命周期来逐步明确后续的两个功能(见图3-4)。
图3-2 预测型生命周期示意
图3-3 迭代型生命周期示意
图3-4 增量型生命周期示意
表3-1概括了预测型生命周期和适应型生命周期的主要区别。
表3-1 预测型生命周期和适应型生命周期比较
秘书(项目经理)为领导(客户)写稿子,就必须采用适应型生命周期。秘书先根据领导的最初需求写出第一份草稿(原型),交给领导审阅。领导审阅后提出修改意见(新的需求)。秘书再根据修改意见写出第二份草稿(新一代原型),交领导审阅;如此多次迭代,直到写出让领导满意的稿子。
项目生命周期是产品生命周期的组成部分,是其中的一个产品阶段。因为在一个产品生命周期中可以做多个项目,所以也就可以有多个项目生命周期。项目经理必须考虑项目生命周期对产品生命周期的影响,例如,要考虑项目决策可能对产品的运营和退市的影响,防止为节约项目成本而导致生命周期成本的不合理增加。通常,“生命周期成本”是指在整个产品生命周期发生的全部成本,包括项目建设成本、项目建成后的运营成本,以及产品退市的处理成本。
比起“项目管理生命周期”,“项目管理过程组”是更常用的术语。这两个术语的意思相同,都是指从项目开始到结束要经历的管理工作周期。后文统一使用“项目管理过程组”术语。
“过程”,也叫“流程”,是旨在完成预定目标的、一系列相互关联的活动的集合,以便运用一系列工具与技术把特定的输入转化成特定的输出。项目管理工作需要接收各种相关输入(原材料),运用工具与技术来处理这些输入,创造出所需的输出(成果)(见图3-5)。第6版的大部分内容,都围绕“输入—处理—输出”的逻辑结构编写。当然,其中各过程所列的“输入”、“工具与技术”和“输出”,都是指导性而非强制性的。在现实工作中,实施各过程所需的输入、工具与技术或所得的输出,可以有所不同。
图3-5 过程示意图
借助各种过程来描述项目管理工作,就把本来较模糊、非结构化、不便于言传的项目管理,转变成了较清晰、结构化、便于言传的项目管理。结构化是指把做事的程序、内容和目标规定得很具体、很明确,以保证结果的可控性和可重复性。例如,为了确保生产安全,就必须制定并遵守具体的操作规程。应该把可以结构化的方面尽量结构化,以便腾出更多的时间和精力,去应对那些实在不能结构化的方面。这是提高工作效率与效果的有效途径。
第6版列出了49个项目管理过程,并把它们归纳进五大项目管理过程组。其中,启动过程组有2个过程,规划过程组有24个过程,执行过程组有10个过程,监控过程组有12个过程,收尾过程组有1个过程。虽然只有1个收尾过程,但是项目经理可根据实际需要添加其他收尾过程,所以仍然叫“收尾过程组”。
五大过程组的理论基础是著名的“计划—实施—检查—行动”循环(PDCA循环)。这个循环又常简称为“戴明环”,因为它是经美国质量管理大师威廉·爱德华兹·戴明(William Edwards Deming)改进之后才广为流传的。“规划过程组”相当于戴明环中的“计划”,“执行过程组”相当于戴明环中的“实施”,“监控过程组”相当于戴明环中的“检查”与“行动”。因为项目有明确的开始与结束时间,所以项目管理过程组是两头开口的循环,比戴明环多了一个入口和一个出口,即启动过程组与收尾过程组。
为了讨论方便,项目管理各过程以相互独立、界限分明、首尾相连的形式出现在第6版中。实际上,项目管理各过程之间的关系并非如此简单,各过程会以无法书面详述的方式相互交叠、相互作用,甚至反复循环。
理解项目管理各过程之间的逻辑关系,需要注意以下几点:
· 在实际工作中,各过程之间的界面不一定明确,而是可能有很大程度的相互交叠,即并行开展。不仅同一个过程组内的各过程可以并行开展,而且不同过程组的过程也可以并行开展。例如,执行过程组中的指导与管理项目工作过程和管理质量过程通常会并行开展,执行过程组的过程与监控过程组的过程也通常会并行开展。
· 每个过程在一个项目上可能需要反复进行几次甚至许多次。有两种情况:一种是每次都在更加详细的程度上进行,这是由项目的渐进明细性决定的。另一种是在开展一个过程时,发现有必要重新开展前一个甚至前几个过程。例如,根据执行过程的情况来调整项目计划安排,这就意味着重新开展一次规划过程。
· 监控过程实际上会针对所有其他过程,而不只是针对执行过程,因为任何工作都要被监控。
· 除了专门开展的事后监控,更多的监控工作会随被监控工作同时开展,而不能在时间段上独立存在。例如,对执行过程的监控往往是与执行过程同时进行的,即一边执行一边监控。
· 一个项目或子项目或某个阶段,在正式启动之后、正式结束之前,往往需要反复开展规划、执行与监控过程。
有些过程开展的频率较低,有些过程开展的频率较高。第6版列出了通常只需开展一次或只需在预定义时点(项目阶段开始时、项目阶段结束时或项目重大变更时)开展的14个过程、在整个项目期间须定期开展的8个过程,以及在整个项目期间须持续开展的27个过程。
总结一下,项目管理过程的开展频率有以下特点:
·“制定项目章程”过程、“结束项目或阶段”过程、制订各种管理计划(包括确定项目基准或目标)的过程,以及制订项目范围计划的过程(针对采用预测型生命周期的项目),只需开展一次或只需在预定义时点开展。
·“识别相关方”过程、编制各种具体的实体计划的过程、“实施采购”过程和“确认范围”过程,需要定期开展。
· 绝大多数执行过程和监控过程都要在整个项目期间持续开展。
总体而言,项目管理各过程之间并非纯直线型关系,而是同时存在顺序、交叠和循环关系。过程间的循环关系就会导致一个过程不止开展一次。
项目管理各过程之间的交叠和循环关系,造成了五大过程组之间的交叠和循环关系。尽管五大过程组之间有一定的先后顺序关系,但是绝对不能以简单的直线型思维去理解五大过程组之间的关系。它们之间存在相当程度的交叠和循环关系。这种交叠和循环关系无法以书面方式详细描述。特别是,监控过程组与其他四大过程组都是交叠的,因为任何工作都需要监控。
在第6版中特别强调“项目阶段不同于项目管理过程组”。项目阶段关注的是项目的技术工作,即每个阶段开展不同的技术工作。项目管理过程组关注的是项目的管理工作,即各过程组开展不同的管理工作。例如,严格地讲,规划过程组不等同于规划阶段。规划过程组的过程,不仅可以在规划阶段开展,而且可以在执行阶段开展。之所以把某个过程归入规划过程组,是因为其主要是在规划阶段开展的。实际上,任何一个项目管理过程都可以在任何一个项目阶段开展。甚至在项目的起始阶段也可以开展结束项目或阶段过程,考虑将来的项目收尾该怎么做。
不考虑五大过程组之间的交叠和循环关系,它们之间的基本关系可概括为如图3-6所示。
图3-6 项目管理五大过程组之间的基本关系
项目管理强调按正确的程序做事。虽然在具体项目上,由项目经理和项目管理团队自行决定具体的做事程序,但是项目管理业界还是已经形成一些基本的程序。考试中可能有这样的题目:给出一个情景,要你选择下一步该做什么。所以,考生需要弄清楚项目管理工作的基本程序。
启动过程组旨在确定项目的总体目标,宣布项目正式立项。启动过程组其实是办理项目的立项手续。在正式进入启动过程组之前,项目发起人需要组织专家完成项目的前期准备工作,编写出相应的商业文件(如商业论证报告),签妥发起项目的合作协议。在启动过程组,用项目章程宣布项目正式立项。为了尽早与项目相关方打交道,还应该在启动过程组编制相关方登记册。相关方登记册将不断调整和完善。通常,项目经理参与但并不领导项目启动工作。启动工作由项目发起人或高级管理层领导。
收尾过程组旨在正式关闭项目,更新组织过程资产。第6版对收尾过程组写得比较简单,因为收尾过程组不是用来解决问题的,而只是用来收集资料、开展项目后评价(总结经验教训)、更新组织过程资产和宣布项目关闭。这些工作都属于行政收尾工作。项目的所有问题都必须通过监控过程组和其他三大过程组加以解决。对收尾过程组,需要注意:
· 如果项目是通过合同来做的,对每个合同都要进行合同收尾。在控制采购过程,要对每个合同进行收尾。在结束项目或阶段过程,要审阅全部采购资料(通常会涉及一系列合同),全面总结采购管理的经验教训。
· 项目的产品范围或技术工作全部完成了,并不代表项目结束。项目必须经过正式的结束项目或阶段过程,完成行政收尾工作,才能正式关闭。
· 收尾工作不仅针对整个项目,也要在每个阶段结束时进行。
· 要做好向后续阶段或成果运营的知识转移,支持后续阶段或成果运营的开展。
规划过程组旨在细化项目目标,并为实现项目目标编制项目计划(包括项目管理计划和各种项目文件)。规划过程组的总体思路是:首先编制各分项管理计划(程序性计划),然后根据各分项管理计划编制项目范围计划、进度计划、成本计划、质量计划、风险计划和采购计划(实体性计划),最后把所有分项管理计划以及高层次的范围计划(范围基准)、进度计划(进度基准)和成本计划(成本基准)汇编成项目管理计划。其他低层次实体性计划则作为项目文件或采购文档而存在。
规划过程组的工作内容比较多。为便于掌握,可以把预测型方法下的编制项目计划的步骤总结为如表3-2所示。
表3-2 项目计划编制的步骤
续表
规划过程组的总体工作流程,如图3-7所示。
图3-7 规划过程组的总体工作流程
执行过程组旨在获取资源,按项目计划开展项目工作,实现项目目标。其主要成果是工作绩效数据和可交付成果。因为《PMBOK ® 指南》是关于项目“管理”工作的指南,所以第6版只列出了10个与管理工作密切相关的执行过程,而没有列出开展纯技术执行的过程,例如,没有列出“执行进度计划过程”。
执行过程组内部的工作流程,可概括为如下10个步骤:
第1步:获取项目资源,包括人力和实物资源(获取资源过程)。
第2步:开展项目团队建设(建设团队过程)。
第3步:管理项目团队(管理团队过程)。
第4步:管理相关方参与(管理相关方参与过程)。
第5步:对外购部分进行采购,选择卖方,签订采购合同(实施采购过程)。
第6步:按项目计划开展项目实施(指导与管理项目工作过程)。
第7步:管理项目知识(管理项目知识过程)。
第8步:开展质量管理,包括质量保证(管理质量过程)。
第9步:实施风险应对策略和措施(实施风险应对过程)。
第10步:发布项目信息(管理沟通过程)。
上述步骤的顺序只是为了方便理解,在实际工作中这些步骤往往是纠缠在一起的,没有明显的先后顺序。例如,指导与管理项目工作过程,其实无法与其他9个执行过程截然分开。
监控过程组旨在监督项目进展情况,发现并分析实际与计划的偏差,提出并审批变更请求,以保证项目目标的实现。第6版每个知识领域都有监控过程(共12个)。监控过程组的总体工作流程如下:
· 第1步:开展基层局部监控。开展控制范围、确认范围、控制进度、控制成本、控制质量、控制资源、监督风险、控制采购、监督沟通和监督相关方参与过程,形成工作绩效信息,提出必要的变更请求。
· 第2步:开展高层全局监控,监控整个项目的绩效。开展监控项目工作过程,编制工作绩效报告,提出必要的变更请求。
· 第3步:审批变更请求。开展实施整体变更控制过程,填写变更日志,批准、否决或悬置变更请求。无论是哪个过程提出的变更请求,都必须提交实施整体变更控制过程审批。
监控过程组的总体工作流程,如图3-8所示。
图3-8 监控过程组的总体工作流程
第6版列出了20个输入。其中,4个来自项目外部,即事业环境因素、组织过程资产、商业文件和卖方建议书;1个(协议)既可以来自项目外部,也可以来自项目内部;其他15个都是本项目内部产生的,即相应项目管理过程的输出。来自项目外部的协议,又有两种情况:一种是项目发起人之间关于发起项目的合作协议,另一种是从承包商角度来看的与业主之间的合同,该合同是承包商启动承包项目的依据。
第6版列出了73个输出。其中,2个是项目的最终成果,即最终产品、服务或成果移交,最终报告;4个先成为本项目其他项目管理过程的输入,待最后更新后再成为项目的最终成果,即事业环境因素更新、组织过程资产更新、采购文档更新、项目文件更新;其他67个都会成为本项目其他项目管理过程的输入,即仅在项目内部使用。
总结一下,项目管理过程的大多数输入都来自项目内部的前序过程,大多数输出都供项目内部的后续过程使用。
在实际工作中,几乎每项工作和每个过程都在不同程度上受围绕项目的事业环境因素的影响,并需要不同程度地利用来自项目执行组织的组织过程资产。因此,事业环境因素和组织过程资产是项目管理各过程的常用输入。
因为项目的前期准备工作是在项目进入启动过程组之前完成的,所以来自前期准备工作的成果“商业文件”和“合作协议”就是启动项目所需要的输入。商业文件中含有商业论证报告和效益管理计划,合作协议则是两个或多个项目发起人之间签署的联合出资协议。
项目进入启动过程,就要编制项目章程,用项目章程来明确项目的高层级目标,规定项目发起人对项目的原则性要求,宣布项目正式立项。随后,项目章程要成为许多过程的输入,即必须根据项目章程开展许多过程。
项目立项(启动)之后,就要编制项目管理计划。随后,项目管理计划要成为几乎所有规划过程、执行过程、监控过程和收尾过程的输入,即必须根据项目管理计划开展这些规划、执行、监控和收尾过程。
规划过程编制的各种具体的项目计划,可以统称为“项目文件”。这些项目文件都要成为后续的执行、监控和收尾过程的输入,即必须根据这些项目文件开展各种执行、监控和收尾过程。
执行过程产出的工作绩效数据和可交付成果,要成为监控过程的输入。在监控过程,对工作绩效数据进行分析整理,对可交付成果进行质量检查和正式验收。
监控过程的各种输出,根据需要,要成为执行过程、后续监控过程和收尾过程的输入。
收尾过程要使用启动、规划、执行和监控过程的各种输出作为输入。
无论是在哪个过程中提出的何种变更请求,都要提交给监控过程“实施整体变更控制”进行审批,即成为该过程的输入。
第6版中,项目管理过程的大多数输出都是文件类输出,只有4个非文件类输出。文件类输出包括项目管理计划及其组成部分、各种项目文件、各种采购文档、结束的采购(宣布采购关闭的文件),以及相应的事业环境因素更新和组织过程资产更新。第6版的“事业环境因素更新”很狭义,故也属文件类输出。
非文件类输出包括可交付成果,核实的可交付成果,验收的可交付成果,最终产品、服务或成果移交(可理解为“移交的可交付成果”)。当然,即便非文件类输出,也需要有相关文件的配合。例如,需要用质量检查合格文件来配合“核实的可交付成果”。
开展启动过程,编制和审批“项目章程”,同时编制“相关方登记册”。开展规划过程,编制项目管理计划和各种实体性项目计划(如项目进度计划)。
开展执行过程和监控过程,往往会提出“变更请求”,即得到“变更请求”这个输出。在重复开展启动过程和规划过程时,也可能提出“变更请求”。只有收尾过程不会提出变更请求,因为收尾过程不是用来解决问题的,而只是办理项目或阶段关闭的行政手续。
开展收尾过程,移交可交付成果,更新项目文件,更新组织过程资产。
项目中的各种具体的实体性计划和其他各种项目文件,大多需要随项目进展适时更新,所以“项目文件更新”是许多项目管理过程的输出。在最后的“结束项目或阶段”过程中,再把所有的项目文件都标识为最终版。
在开展各种项目管理过程时,都要及时总结经验教训,收集工作流程、模板和数据,并把它们归入组织过程资产,得到“组织过程资产更新”这个输出。
做项目,必须同时做技术工作和管理工作。技术工作是基础,管理工作则能提高效率和改进效果。项目生命周期关注的是每个阶段要做什么技术工作,而项目管理过程组关注的是每个过程组要做什么管理工作。因为项目生命周期的每个阶段都可看作一个子项目,所以每个阶段都可用五大过程组进行管理。也就是说,每个阶段都要经过启动、规划、执行、监控和收尾过程组。如果项目生命周期有五个阶段,那么在这个项目上,每个过程组都至少要做六次。不仅要对整个项目做一次,而且要对每个阶段做一次。
严格地说,一个项目,只有在做完前期准备工作并且被确认为“可行”之后,才能进入启动过程组办理立项手续。所以,项目的前期准备工作并没有包括在五大过程组之中。不过,“前期准备工作”本身可以被当作一个项目或子项目,从而可以用五大过程组进行管理。也就是说,前期准备工作应该按照启动、规划、执行、监控和收尾过程组来推进。
每个项目管理过程或每个过程组都可在项目生命周期的任何阶段开展。各项目管理过程都被归入与其大多数活动所在的项目阶段基本对应的那个过程组(注意:只是“基本对应”)。例如,识别风险过程之所以被归入规划过程组,是因为识别风险的工作主要是在规划阶段开展的,而与规划阶段基本对应的就是规划过程组。在项目启动阶段开展的识别大风险,在执行阶段开展的识别新风险,也都被归入规划过程组的识别风险过程。
项目生命周期与项目管理过程组之间的关系可概括为:用项目管理过程组来管理项目生命周期的每一个阶段以及阶段之间的衔接,推动项目生命周期各阶段依次向前,直至项目结束(见图3-9)。
图3-9 项目生命周期与项目管理过程组的关系