通用词汇是专业学科的基本要素。《PMI 项目管理术语词典》[4] 收录了基本的专业词汇,供组织、项目组合、项目集和项目经理及其他项目相关方统一使用。《术语词典》会随着时间的推移而更改。本指南的词汇表包含了《术语词典》中的词汇以及其他定义。项目可能会采用由行业文献定义的相关行业特定的术语。
项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。
生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段,属性是可测量且独特的。属性可能包括(但不限于):
项目可以分解为不同的阶段或子组件,这些阶段或子组件的名称通常说明了该阶段完成的工作类型。阶段名称的例子包括(但不限于):
项目阶段可基于各种因素而建立,其中包括(但不限于):
分为多个阶段的方式有助于更好地掌控项目管理,同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。项目阶段的其中一个关键组成部分是阶段审查(见 1.2.4.3 节)。
阶段关口在项目阶段结束时进行,将项目的绩效和进度与项目和业务文件比较,这些文件包括( 但不限于):
根据比较结果做出决定(例如继续/终止的决定),以便:
在不同的组织、行业或工作类型中,阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。组织可以通过这些审查来检查本指南范围之外的其他相关项,例如产品相关文件或模型。
项目生命周期是通过一系列项目管理活动进行的,即项目管理过程。每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。输出可以是可交付成果或结果。
结果是过程的最终成果。项目管理过程适用于全球各个行业。
各项目管理过程通过它们所产生的输出建立逻辑联系。过程可能包含了在整个项目期间相互重叠的活动。一个过程的输出通常成为以下二者之一:
图 1-6 的示例说明了一个过程的输入、工具、技术和输出的关系以及与其他过程的关系。
图 1-6过程示例:输入、工具与技术和输出
过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类:
项目管理通过合理运用与整合按逻辑分组的项目管理过程而得以实现。过程分类方法有很多种,但《PMBOK® 指南》把过程归纳为五大类,即五大过程组。
以下是组织外部的事业环境因素:
近期的 PMI 研究通过 PMI 人才三角®(见图 3-2)指出了项目经理根据《项目经理能力发展 (PMCD) 框架》需要具备的技能。人才三角重点关注三个关键技能组合:
图 3-2 PMI 人才三角®
虽然技术项目管理技能是项目集和项目管理的核心,但 PMI 研究指出,当今全球市场越来越复杂,竞争也越来越激烈,只有技术项目管理技能是不够的。各个组织正在寻求其他有关领导力和商业智慧技能。来自不同组织的成员均提出,这些能力可以有助于支持更长远的战略目标,以实现赢利。
为发挥最大的效果,项目经理需要平衡这三种技能。
战略和商务管理技能包括纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力。这项能力可能涉及其他职能部门的工作知识,例如财务部、市场部和运营部。战略和商务管理技能可能还包括发展和运用相关的产品和行业专业知识。这种业务知识也被称为领域知识。项目经理应掌握足够的业务知识,以:
为制定关于项目成功交付的最佳决策,项目经理应咨询具备关于组织运营的专业知识的运营经理。这些经理应了解组织的工作以及项目计划会对工作造成的影响。对项目经理而言,对项目主题的了解越多越好,至少应能够向其他人说明关于组织的以下方面:
为确保一致性,项目经理应将以下关于组织的知识和信息运用到项目中:
战略和商业技能有助于项目经理确定应为其项目考虑哪些商业因素。项目经理应确定这些商业和战略因素会对项目造成的影响,同时了解项目与组织之间的相互关系。这些因素包括(但不限于):
通过运用这些商务知识,项目经理能够为项目提出合适的决策和建议。随着条件的变化,项目经理应与项目发起人持续合作,使业务战略和项目策略保持一致。
专家判断是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的,关于当前活动的合理判断,这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。
本过程应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:
能够影响制定项目章程过程的事业环境因素包括(但不限于):
能够影响制定项目管理计划过程的事业环境因素包括(但不限于):
可用于本过程的数据收集技术包括(但不限于):
见 4.1.2.1 节。应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:
能够影响监控项目工作过程的事业环境因素包括(但不限于):
见 4.1.2.1 节。应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:
能够影响实施整体变更控制过程的事业环境因素包括(但不限于):
见 4.1.2.1 节。应该就以下主题,考虑征求具备以下相关专业知识或接受过相关培训的个人或小组的意见:
见 4.1.2.1 节。应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是,为定义产品范围和项目范围奠定基础,且仅开展一次或仅在项目的预定义点开展。图 5-4 描述本过程的输入、工具与技术和输出。图 5-5 是本过程的数据流向图。
图 5-4收集需求:输入、工具与技术和输出
图 5-5收集需求:数据流向图
《PMBOK® 指南》并没有专门讨论产品需求,因为产品需求因行业而异。《从业者商业分析:
实践指南》[7] 提供了有关产品需求的更深入信息。让相关方积极参与需求的探索和分解工作(分解成项目和产品需求),并仔细确定、记录和管理对产品、服务或成果的需求,能直接促进项目成功。需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求,将其包含在范围基准中,并在项目执行开始后对其进行测量。需求将成为工作分解结构(WBS)的基础,也将成为成本、进度、质量和采购规划的基础。
见 4.1.2.3 节。可用于本过程的人际关系与团队技能包括(但不限于):
研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点,有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通,从而有利于相关方达成一致意见。此外,与分别召开会议相比,研讨会能够更早发现并解决问题。
适合采用引导技能的情境包括(但不限于):
原型法是指在实际制造预期产品之前,先造出该产品的模型,并据此征求对需求的早期反馈。
原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物,它使得相关方可以体验最终产品的模型,而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念,需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后,就可以通过原型获得足够的需求信息,从而进入设计或制造阶段。
故事板是一种原型技术,通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中,如电影、广告、教学设计,以及敏捷和其他软件开发项目。在软件开发中,故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
会影响创建 WBS 过程的事业环境因素包括(但不限于)项目所在行业的 WBS 标准,这些标准可以作为创建 WBS 的外部参考资料。
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 WBS 最低层的工作,可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度,以实现对项目的高效管理;工作包的详细程度则因项目规模和复杂程度而异。要把整个项目工作分解为工作包,通常需要开展以下活动:
图 5-12 显示了某工作分解结构的一部分,其中若干分支已经向下分解到工作包层次。
图 5-12分解到工作包的 WBS 示例
创建 WBS 的方法多种多样,常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS模板。自下而上的方法可用于归并较低层次组件。WBS 的结构可以采用多种形式,例如:
图 5-13 WBS 示例:以阶段作为第二层
图 5-14 WBS 示例:以主要可交付成果作为第二层
对 WBS 较高层组件进行分解,就是要把每个可交付成果或组件分解为最基本的组成部分,即可核实的产品、服务或成果。如果采用敏捷方法,可以将长篇故事分解成用户故事。WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作,来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层,即可到达工作包的层次,而另一些则须分解更多层。工作分解得越细致,对工作的规划、管理和控制就越有力。但是,过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低,同时造成 WBS 各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件,当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见,才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。
WBS 包含了全部的产品和项目工作,包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总,来确保既没有遗漏的工作,也没有多余的工作。这有时被称为 100% 规则。
关于 WBS 的详细信息,可参考《工作分解结构实践标准》(第 2 版)[15]。该标准列举了一些具体行业的 WBS 模板,可以在裁剪后应用于特定领域的具体项目。
见 4.1.2.1 节。应征求具备专业知识或在以往类似项目中接受过相关培训的个人或小组的意见:
能够影响排列活动顺序过程的事业环境因素包括(但不限于):
能够影响制定进度计划过程的事业环境因素包括(但不限于):
见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:
见 4.1.2.1. 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:
见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:
项目质量管理包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方目标的各个过程。此外,项目质量管理以执行组织的名义支持过程的持续改进活动。
项目质量管理过程包括:
8.1 规划质量管理 — 识别项目及其可交付成果的质量要求和/或标准,并书面描述项目将如何证明符合质量要求和/或标准的过程。
8.2 管理质量 — 管理质量是把组织的质量政策用于项目,并将质量管理计划转化为可执行的质量活动的过程。
8.3 控制质量 — 为了评估绩效,确保项目输出完整、正确,并满足客户期望,而监督和记录质量管理活动执行结果的过程。
图 8-1 概述了项目质量管理的各个过程。虽然各项目质量管理过程通常以界限分明、相互独立的形
式出现,但在实践中它们会以《PMBOK® 无法全面叙述的方式相互交叠、相互作用。此外,不同行业和公司的质量过程各不相同。
图 8-1项目质量管理概述
图 8-2 概述了项目质量管理过程的主要输入和输出以及这些过程在项目质量管理知识领域中的相
互关系。规划质量管理过程关注工作需要达到的质量,管理质量则关注管理整个项目期间的质量过程。在管理质量过程期间,在规划质量管理过程中识别的质量要求成为测试与评估工具,将用于控制质量过程,以确认项目是否达到这些质量要求。控制质量关注工作成果与质量要求的比较,确保结果可接受。项目质量管理知识领域有两个用于其他知识领域的特定输出,即核实的可交付成果和质量报告。
图 8-2主要项目质量管理过程的相互关系
项目质量管理的核心概念项目质量管理需要兼顾项目管理与项目可交付成果两个方面,它适用于所有项目,无论项目的可交付成果具有何种特性。质量的测量方法和技术则需专门针对项目所产生的可交付成果类型而定,例如,对于软件与核电站建设的可交付成果,项目质量管理需要采用不同的方法和措施。无论什么项目,若未达到质量要求,都会给某个或全部项目相关方带来严重的负面后果,例如:
“质量”与“等级”不是相同的概念。质量作为实现的性能或成果,是“一系列内在特性满足要求的程度”(ISO 9000)[18]。等级作为设计意图,是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及项目管理团队负责权衡,以便同时达到所要求的质量与等级水平。质量水平未达到质量要求肯定是个问题,而低等级产品不一定是个问题。例如:
预防胜于检查。最好将质量设计到可交付成果中,而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。
根据不同的项目和行业领域,项目团队可能需要具备统计控制过程方面的实用知识,以便评估控制质量的输出中所包含的数据。项目管理团队应了解以下术语之间的差别:
质量成本 (COQ) 包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求,以及因未达到要求(返工)而发生的所有成本。失败成本通常分为内部(项目团队发现的)和外部(客户发现的)两类。失败成本也称为劣质成本。第 8.1.2.3 节给出了每类质量成本的一些例子。
组织选择投资缺陷预防,因为它对产品生命周期有利。由于项目的临时性,针对产品生命周期的COQ 决策,通常是项目集管理、项目组合管理、PMO 或运营的关注点。
按有效性递增排列的五种质量管理水平如下:
项目质量管理的趋势和新兴实践现代质量管理方法力求缩小差异,交付满足既定相关方要求的成果。项目质量管理的趋势可能包括(但不限于):
裁剪考虑因素每个项目都是独特的,因此项目经理需要裁剪项目质量管理过程。裁剪时应考虑的因素包括(但不限于):
关于敏捷/适应型环境的考虑因素为引导变更,敏捷方法要求多个质量与审核步骤贯穿整个项目,而不是在面临项目结束时才执行。
循环回顾,定期检查质量过程的效果;寻找问题的根本原因,然后建议实施新的质量改进方法;
后续回顾会议评估试验过程,确定是否可行、是否应继续、或做出调整,或者直接弃用。
为促进频繁的増量交付,敏捷方法关注于小批量工作,纳入尽可能多的项目可交付成果的要素。
小批量系统的目的是在项目生命周期早期(整体变更成本较低)发现不一致和质量问题。
适用于本过程的数据收集技术包括(但不限于):
在规划阶段,项目经理和项目团队决定如何测试或检查产品、可交付成果或服务,以满足相关方的需求和期望,以及如何满足产品的绩效和可靠性目标。不同行业有不同的测试与检查,可能包括软件项目的 α 测试和 β 测试、建筑项目的强度测试、制造和实地测试的检查,以及工程的无损伤测试。
管理质量是把组织的质量政策用于项目,并将质量管理计划转化为可执行的质量活动的过程。
本过程的主要作用是,提高实现质量目标的可能性,以及识别无效过程和导致质量低劣的原因。
管理质量使用控制质量过程的数据和结果向相关方展示项目的总体质量状态。本过程需要在整个项目期间开展。
图 8-7 描述本过程的输入、工具与技术和输出。图 8-8 是本过程的数据流向图。
图 8-7管理质量:输入、工具与技术和输出
图 8-8管理质量:数据流向图
管理质量有时被称为“质量保证”,但“管理质量”的定义比“质量保证”更广,因其可用于非项目工作。在项目管理中,质量保证着眼于项目使用的过程,旨在高效地执行项目过程,包括遵守和满足标准,向相关方保证最终产品可以满足他们的需求、期望和要求。管理质量包括所有质量保证活动,还与产品设计和过程改进有关。管理质量的工作属于质量成本框架中的一致性工作。
管理质量过程执行在项目质量管理计划中所定义的一系列有计划、有系统的行动和过程,有助于:
项目经理和项目团队可以通过组织的质量保证部门或其他组织职能执行某些管理质量活动,例如故障分析、实验设计和质量改进。质量保证部门在质量工具和技术的使用方面通常拥有跨组织经验,是良好的项目资源。
管理质量被认为是所有人的共同职责,包括项目经理、项目团队、项目发起人、执行组织的管理层,甚至是客户。所有人在管理项目质量方面都扮演一定的角色,尽管这些角色的人数和工作量不同。参与质量管理工作的程度取决于所在行业和项目管理风格。在敏捷项目中,整个项目期间的质量管理由所有团队成员执行;但在传统项目中,质量管理通常是特定团队成员的职责。
审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展,如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。质量审计目标可能包括(但不限于):
采取后续措施纠正问题,可以降低质量成本,并提高发起人或客户对项目产品的接受度。质量审计可事先安排,也可随机进行;可由内部或外部审计师进行。
质量审计还可确认已批准的变更请求(包括更新、纠正措施、缺陷补救和预防措施)的实施情况。
可基于行业需求和组织模板创建测试与评估文件。它们是控制质量过程的输入,用于评估质量目标的实现情况。这些文件可能包括专门的核对单和详尽的需求跟踪矩阵。
控制质量是为了评估绩效,确保项目输出完整、正确且满足客户期望,而监督和记录质量管理活动执行结果的过程。本过程的主要作用是,核实项目可交付成果和工作已经达到主要相关方的质量要求,可供最终验收。控制质量过程确定项目输出是否达到预期目的,这些输出需要满足所有适用标准、要求、法规和规范。本过程需要在整个项目期间开展。
图 8-10 描述本过程的输入、工具与技术和输出。图 8-11 是本过程的数据流向图。
图 8-10控制质量:输入、工具与技术和输出
图 8-11控制质量的数据流向图
控制质量过程的目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。
本过程通过测量所有步骤、属性和变量,来核实与规划阶段所描述规范的一致性和合规性。
在整个项目期间应执行质量控制,用可靠的数据来证明项目已经达到发起人和/或客户的验收标准。
控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。例如,相比其他行业,制药、医疗、运输和核能产业可能拥有更加严格的质量控制程序,为满足标准付出的工作也会更广;在敏捷项目中,控制质量活动可能由所有团队成员在整个项目生命周期中执行,而在瀑布式项目中,控制质量活动由特定团队成员在特定时间点或者项目或阶段快结束时执行。
项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程,这些过程有助于确保项目经理和项目团队在正确的时间和地点使用正确的资源。
项目资源管理过程包括:
9.1 规划资源管理 — 定义如何估算、获取、管理和利用实物以及团队项目资源的过程。
9.2 估算活动资源 — 估算执行项目所需的团队资源,以及材料、设备和用品的类型和数量的过程。
9.3 获取资源 — 获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。
9.4 建设团队 — 提高工作能力,促进团队成员互动,改善团队整体氛围,以提高项目绩效的过程。
9.5 管理团队 — 跟踪团队成员工作表现,提供反馈,解决问题并管理团队变更,以优化项目绩效的过程。
9.6 控制资源 — 确保按计划为项目分配实物资源,以及根据资源使用计划监督资源实际使用情况,并采取必要纠正措施的过程。
图 9-1 概括了项目资源管理的各个过程。虽然在本《PMBOK® 指南》中,各项目资源管理过程
以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 9-1项目资源管理概述
团队资源管理相对于实物资源管理,对项目经理提出了不同的技能和能力要求。实物资源包括设备、材料、设施和基础设施,而团队资源或人员指的是人力资源。项目团队成员可能具备不同的技能,可能是全职或兼职的,可能随项目进展而增加或减少。项目资源管理与项目相关方管理之间有重叠的部分(见 13 节),本节(第 9 节)则重点关注组成项目团队的部分相关方。
项目资源管理的核心概念项目团队由承担特定角色和职责的个人组成,他们为实现项目目标而共同努力。项目经理因此应在获取、管理、激励和增强项目团队方面投入适当的努力。尽管项目团队成员被分派了特定的角色和职责,但让他们全员参与项目规划和决策仍是有益的。团队成员参与规划阶段,既可使他们对项目规划工作贡献专业技能,又可以增强他们对项目的责任感。
项目经理既是项目团队的领导者又是项目团队的管理者。除了项目管理活动,例如启动、规划、执行、监控和关闭各个项目阶段,项目经理还负责建设高效的团队。项目经理应留意能够影响团队的不同因素,例如:
作为领导者,项目经理还负责积极培养团队技能和能力,同时提高并保持团队的满意度和积极性,项目经理还应留意并支持职业与道德行为,确保所有团队成员都遵守这些行为。
实物资源管理着眼于以有效和高效的方式,分配和使用成功完成项目所需的实物资源,如材料、设备和用品。为此,组织应当拥有如下数据:(当前和合理的未来的)资源需求、(可以满足这些需求的)资源配置,以及资源供应。不能有效管理和控制资源是项目成功完成的风险来源。例如:
项目资源管理的趋势和新兴实践项目管理风格正在从管理项目的命令和控制结构,转向更加协作和支持性的管理方法,通过将决策权分配给团队成员来提高团队能力。此外,现代的项目资源管理方法致力于寻求优化资源使用。
有关项目资源管理的趋势和新兴实践包括(但不限于):
裁剪考虑因素由于每个项目都是独特的,项目经理需要裁剪项目资源管理过程。裁剪时应考虑的因素包括(但不限于):
是否存在有特殊需求的团队成员?是否需要为团队提供有关多元化管理的特别培训?
在敏捷或适应型环境中需要考虑的因素易变性高的项目得益于最大限度地集中和协作的团队结构,例如拥有通才的自组织团队。
协作旨在提高生产率和促进创新的问题解决方式。协作型团队可以促进不同工作活动的加速整合、改善沟通、增加知识分享,以及提供工作分配的灵活性和其他优势。
虽然协作的优势也适用于其他项目环境,协作型团队对于易变性高且快速变化的项目成功而言通常是至关重要的,因为集中分配任务和决策所需的时间更少。
对于易变性高的项目,实物和人力资源规划的可预测性要低得多。在这些环境中,关于快速供应和精益方法的协议,对控制成本和实现进度而言至关重要。
建设团队是提高工作能力,促进团队成员互动,改善团队整体氛围,以提高项目绩效的过程。
本过程的主要作用是,改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。本过程需要在整个项目期间开展。
图 9-10 描述本过程的输入、工具与技术和输出。图 9-11 是本过程的数据流向图。
图 9-10建设团队:输入、工具与技术和输出
• Projectcharter图 9-11建设团队:数据流向图
项目经理应该能够定义、建立、维护、激励、领导和鼓舞项目团队,使团队高效运行,并实现项目目标。团队协作是项目成功的关键因素,而建设高效的项目团队是项目经理的主要职责之一。
项目经理应创建一个能促进团队协作的环境,并通过给予挑战与机会、提供及时反馈与所需支持,以及认可与奖励优秀绩效,不断激励团队。通过以下行为可以实现团队的高效运行:
项目经理在全球化环境和富有文化多样性的项目中工作:团队成员经常来自不同的行业,讲不同的语言,有时甚至会在工作中使用一种特别的“团队语言”或文化规范,而不是使用他们的母语;
项目管理团队应该利用文化差异,在整个项目生命周期中致力于发展和维护项目团队,并促进在相互信任的氛围中充分协作;通过建设项目团队,可以改进人际技巧、技术能力、团队环境及项目绩效。在整个项目生命周期中,团队成员之间都要保持明确、及时、有效(包括效果和效率两个方面)的沟通。建设项目团队的目标包括(但不限于):
有一种关于团队发展的模型叫塔克曼阶梯理论 [19,20],其中包括团队建设通常要经过的五个阶段。尽管这些阶段通常按顺序进行,然而,团队停滞在某个阶段或退回到较早阶段的情况也并非罕见;而如果团队成员曾经共事过,项目团队建设也可跳过某个阶段。
某个阶段持续时间的长短,取决于团队活力、团队规模和团队领导力。项目经理应该对团队活力有较好的理解,以便有效地带领团队经历所有阶段。
见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:
会影响识别风险过程的事业环境因素包括(但不限于):
适用于本过程的数据收集技术包括(但不限于):
能够影响实施定性风险分析的事业环境因素包括(但不限于):
能够影响实施定量风险分析过程的事业环境因素包括(但不限于):
项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程,例如,合同、订购单、协议备忘录 (MOA),或服务水平协议 (SLA)。被授权采购项目所需货物和(或)服务的人员可以是项目团队、管理层或组织采购部(如果有)的成员。
项目采购管理过程包括:
12.1 规划采购管理 — 记录项目采购决策、明确采购方法,及识别潜在卖方的过程。
12.2 实施采购 — 获取卖方应答、选择卖方并授予合同的过程。
12.3 控制采购 — 管理采购关系、监督合同绩效、实施必要的变更和纠偏,以及关闭合同的过程。
虽然在本指南中,采购过程以界限分明和相互独立的形式出现,但在实践中,采购过程相当复杂且相互作用,还与其他知识领域的过程相互作用。本指南无法全面详述这些相互作用。本章以从项目外部获取货物或服务的视角来叙述采购过程。
图 12-1 概括了项目采购管理的各个过程。虽然在本《PMBOK® 指南》中,各项目采购管理过程
以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 12-1项目采购管理概述
项目采购管理的核心概念与采购过程相关的重大法律义务和惩罚,通常超出大多数其他的项目管理过程。虽然项目经理不必成为采购管理法律法规领域的专家,但应该对采购过程有足够了解,以便做出与合同及合同关系相关的明智决定。通常情况下,项目经理无权签署对组织有约束力的法律协议,这项工作仅由具备相关职权的人员执行。
项目采购管理过程涉及到用协议来描述买卖双方之间的关系。协议可以很简单,如以特定人工单价购买所需的工时,也可以很复杂,如多年的国际施工合同。合同签署的方法和合同本身应体现可交付成果或所需人力投入的简单性或复杂性,其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。
合同应明确说明预期的可交付成果和结果,包括从卖方到买方的任何知识转移。合同中未规定的任何事项则不具法律强制力。开展国际合作的项目经理应牢记,无论合同规定如何详尽,文化和当地法律对合同及其可执行性均有影响。
采购合同中包括条款和条件,也可包括买方就卖方应实施工作或应交付产品的其他规定。在与采购办公室协作确保遵守组织的采购政策的同时,项目管理团队必须确定所有采购都能满足项目的具体需要。因应用领域不同,协议可以是合同、服务水平协议(SLA)、谅解备忘录、协议备忘录(MOA)或订购单。
大多数组织都有相关的书面政策和程序,来专门定义采购规则,并规定谁有权代表组织签署和管理协议。在世界各地,组织虽然用不同的名称来称呼负责采购的单位或部门,如购买部、合同部、采购部或收购部,但其实际职责大同小异。
虽然所有项目文件可能都要经过某种形式的审查与批准,但是,鉴于其法律约束力,合同或协议需要经过更多的审批程序,而且通常会涉及到法务部。在任何情况下,审批程序的主要目标都是确保合同充分描述将由卖方提供的产品、服务或成果,且符合法律法规关于采购的规定。通常把描述产品、服务或成果的文件作为独立的附件或附录,以便合同正文使用标准化的法律合同用语。
在复杂项目中,可能需要同时或先后管理多个合同。这种情况下,不同合同的生命周期可在项目生命周期的任何阶段开始与结束。买卖方关系是采购组织与外部组织之间的关系,可存在于项目的许多层次上。
因应用领域不同,卖方可以是承包商、供货商、服务提供商或供应商;买方可能为最终产品的所有人、分包商、收购机构、服务需求者或购买方。在合同生命周期中,卖方首先是投标人,然后是中标人,之后是签约供应商或供货商。
中标人可将所承揽的工作当作一个项目加以管理。在这种情况下:
在合同中,可实际列出各种输入(如,主要可交付成果、关键里程碑、成本目标),或者可限制项目团队的选择余地(如,在 IT 整合项目中,关于人员配备的决定往往要征得买方的批准)。另外,采购工作说明书可能使用其他名称,如技术工作说明书。
本节假设项目所需物品或服务的买方是项目团队,或者是组织内部的某个部门,同时假设卖方是为项目提供物品或服务的一方,且通常来自执行组织外部。在某些项目上,卖方可能是项目执行组织内部但属于项目外部的某个小组或部门。在大型复杂的项目上,卖方可能在授予合同后才成为整合式项目团队的一部分。
在小型组织或初创企业,以及未设置购买、合同或采购部门的组织,项目经理可以拥有采购职权,能够直接谈判并签署合同(分散式采购)。在更成熟的组织中,由专设部门开展实际的采购和合同签署工作,即采购、谈判和签署合同(集中式采购)。
在签署国际合同时,应该在合同中明确规定对合同的法律管辖权。在大多数情况下,卖方是受正式合同关系约束的外部承包商。
采购管理的发展趋势和新兴实践不同行业各方面(软件工具、风险、过程、物流和技术)的一些重大趋势,会影响项目的成功率。项目采购管理的发展趋势和新兴实践包括(但不限于):
裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目采购管理过程。裁剪时应考虑的因素包括(但不限于):
在敏捷或适应型环境中需要考虑的因素在敏捷型环境中,可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型,让买方和卖方共担项目风险和共享项目奖励。
在大型项目上,可能针对某些可交付成果采用适应型方法,而对其他部分则采用更稳定的方法。
在这种情况下,可以通过主体协议,如主要服务协议(MSA),来管辖整体协作关系,而将适应型工作写入附录或补充文件。这样一来,变更只针对适应型工作,而不会对主体协议造成影响。
见 4.2.3.1 节。项目管理计划组件包括(但不限于):
能够影响规划采购管理过程的事业环境因素包括(但不限于):
适用于本过程的数据收集技术包括(但不限于)市场调研。市场调研包括考察行业情况和具体卖方的能力。采购团队可运用从会议、在线评论和各种其他渠道得到的信息,来了解市场情况。采购团队也可以调整具体的采购目标,以便在平衡与有能力提供所需材料或服务的卖方的范围有关的风险的同时,利用成熟技术。
招标文件用于向潜在卖方征求建议书。如果主要依据价格来选择卖方(如购买商业或标准产品时),通常就使用标书、投标或报价等术语;如果其他考虑因素(如技术能力或技术方法)至关重要,则通常使用建议书之类的术语。具体使用的采购术语也可能因行业或采购地点而异。
取决于所需的货物或服务,招标文件可以是信息邀请书、报价邀请书、建议邀请书,或其他适当的采购文件。使用不同文件的条件如下:
随后一般还会使用报价邀请书或建议邀请书。
买方拟定的采购文件不仅应便于潜在卖方做出准确、完整的应答,还要便于买方对卖方应答进行评价。采购文件会包括规定的应答格式、相关的采购工作说明书,以及所需的合同条款。
采购文件的复杂和详细程度应与采购的价值及相关的风险相符。采购文件既需要具备足够详细的信息,以确保卖方做出一致且适当的应答,同时它又要有足够的灵活度,让卖方为满足相同的要求而提出更好的建议。
见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:
广告是就产品、服务或成果与用户或潜在用户进行的沟通。在大众出版物(如指定的报纸)或专门行业出版物上刊登广告,往往可以扩充现有的潜在卖方名单。大多数政府机构都要求公开发布采购广告,或在网上公布拟签署的政府合同的信息。
能够影响识别相关方过程的事业环境因素包括(但不限于):
见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:
规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响,制定项目相关方参与项目的方法的过程。本过程的主要作用是,提供与相关方进行有效互动的可行计划。本过程应根据需要在整个项目期间定期开展。
图 13-4 描述本过程的输入、工具与技术和输出。图 13-5 是本过程的数据流向图。
图 13-4规划相关方参与:输入、工具与技术和输出
图 13-5规划相关方参与:数据流向图
• Projectcharter为满足项目相关方的多样性信息需求,应该在项目生命周期的早期制定一份有效的计划;然后,随着相关方社区的变化,定期审查和更新该计划。在通过识别相关方过程明确最初的相关方社区之后,就应该编制第一版的相关方参与计划,然后定期更新相关方参与计划,以反映相关方社区的变化。会触发该计划更新的典型情况包括(但不限于):
这些情况都可能导致已识别相关方的相对重要性发生变化。
项目生命周期指项目从开始到完成所经历的一系列阶段。项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。这些阶段之间可能是顺序、迭代或交叠的关系。项目阶段的名称、数量和持续时间取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。阶段都有时限,有一个起始点、结束点或控制点(有时称为阶段审查、阶段关口或控制关口,也可以用其他类似名称)。在控制点,需要根据当前环境,重新审查项目章程和商业文件。在该时点,把项目绩效与项目管理计划进行比较,以确定项目是否应该变更、终止或按计划继续。
项目生命周期会受组织、行业、开发方法或所用技术的独特性质的影响。虽然每个项目都有起点和终点,但具体的可交付成果及工作会因项目的不同而有很大差异。不论项目涉及的具体工作是什么,生命周期都可以为管理项目提供基本框架。
虽然项目规模及复杂程度各不相同,但是典型项目都呈现下列项目生命周期结构(见图 1-2):
图 1-2项目生命周期的通用结构
通用的生命周期结构一般具有以下特征:
图 1-3随时间而变化的变量影响
本标准描述用于实现项目目标的项目管理过程。项目管理过程可归为五大项目管理过程组:
监控过程组详见第 5 章。
这五大过程组与应用领域(如营销、信息服务或会计)或行业(如建筑、航天、电信)无关。
在阶段或项目完成之前,往往需要反复实施过程组中的单个过程。过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类:
一个过程的输出通常成为另一个过程的输入,或者成为项目或项目阶段的可交付成果。例如,需要把规划过程组编制的项目管理计划和项目文件(如风险登记册、责任分配矩阵等)及其更新,提供给执行过程组作为输入。图 1-4 是各过程组在项目或阶段期间的重叠关系示例。
过程组不同于项目阶段。如果将项目划分为若干阶段,则各过程组中的过程会在每个阶段内相互作用。在一个阶段内可能需要使用所有的过程组,如图 1-5 所示。当项目被分为不同的阶段(例如概念开发、可行性研究、设计、原型、构建或测试等)时,各过程组中的过程根据需要在每个阶段中重复,直到达到该阶段的完工标准。
图 1-5项目或阶段中的过程组相互作用示例
过程组和知识领域涵盖的 49 个过程如表 1-1 所示。
表 1-1项目管理过程组与知识领域
裁剪项目质量管理时要考虑的因素包括(但不限于):
裁剪项目资源管理时要考虑的因素包括(但不限于):
每一个知识领域部分在介绍第一个过程前都有标准化的材料,此类材料包括以下小章节:
相反,它旨在描述在大多数时间适用于大多数项目的良好实践。在此小章节中,我们找出部分正在发生的趋势或新兴趋势,但并非大多数项目都会将其付诸使用。