全部展开 全部合拢

3.3.3 组织

项目经理需要积极地与其他项目经理互动。其他独立项目或同一项目集的其他项目可能会对项目造成影响,原因包括(但不限于):

  • 对相同资源的需求;
  • 资金分配的优先顺序;
  • 可交付成果的接受或发布;
  • 项目组织的目的和目标的一致性。

与其他项目经理互动有助于产生积极的影响,以满足项目的各种需求。这些需求可能是团队为完成项目而需要的人力、技术或财力资源和可交付成果项目经理需要寻求各种方法来培养人际关系,从而帮助团队实现项目目的和目标。

此外,项目经理在组织内扮演强有力的倡导者的角色。在项目过程中,项目经理积极地与组织中的各位经理互动。此外,项目经理应与项目发起人合作处理内部的政治和战略问题,这些问题可能会影响团队或项目的可行性或质量。

项目经理可以致力于提高自己在组织内的总体项目管理能力和技能,并参与隐性和显性知识的转移或整合计划(见 4.4 节的管理项目知识)。项目经理还应致力于:

基于组织结构,项目经理可能向职能经理报告。而在其他情况下,项目经理可能与其他项目经理一起,向 PMO、项目组合或项目集经理报告。项目组合或项目集经理对整个组织范围内的一个或多个项目承担最终责任。为了实现项目目标,项目经理需要与所有相关经理紧密合作,确保项目管理计划符合所在项目组合或项目集的计划。项目经理还需与其他角色紧密协作,如组织经理、主题专家以及商业分析人员。在某些情况下,项目经理可以是临时管理角色的外部顾问。

标准是基于权威、惯例或共识而建立并用作模式或范例的文件。本标准的开发过程遵循协商一致、开放公开、程序公正和各方平衡的基本原则。本标准描述在大多数时候适用于大多数项目的、被视为良好实践的过程,并把这些过程归入相应的过程组。本标准也对关键的项目管理概念进行定义,包括项目管理与组织战略及目标的关系,项目管理与组织治理、项目组合管理、项目集管理、项目环境及项目成功之间的关系。本标准还介绍项目生命周期、项目相关方,以及项目经理的角色。第 1 章介绍一些基本概念,并提供有关项目管理的背景信息。第 2 章至第 6 章对五大过程组进行逐一定义,并描述其下属过程。第 2 章至第 6 章还描述各项目管理过程的主要作用、输入和输出。本标准将作为《项目管理知识体系指南》(《PMBOK® 指南》)1 的基础和框架。《PMBOK® 指南》通过对相关背景、环境及其对项目管理的影响进行更深入的阐述,来扩展本标准的内容。此外,《PMBOK® 指南》也描述项目管理过程的输入和输出,识别项目管理过程的工具和技术,并按知识领域讨论一些重要概念和新趋势。

项目管理并非新概念,它已存在数百年之久。项目成果的例子包括:

  • 吉萨金字塔;
  • 奥林匹克运动会;
  • 中国长城;
  • 泰姬陵;
  • 儿童读物的出版;
  • 巴拿马运河;
  • 商用喷气式飞机的发明;
  • 脊髓灰质炎疫苗;
  • 人类登陆月球;
  • 商业软件应用程序;
  • 使用全球定位系统 (GPS) 的便携式设备;
  • 地球轨道上的国际空间站。

这些项目成果是领导者和项目经理在工作中应用项目管理实践、原则、过程、工具和技术的结果。

这些项目经理运用一系列关键技能和知识来满足客户和参与项目或受项目影响的其他人的要求。二十世纪中期,项目经理开始致力于将项目管理确立为一种职业,其中一个方面就是对知识体系 (BOK)的内容,即项目管理达成一致意见。这一知识体系后来称为“项目管理知识体系”(PMBOK)。项目管理协会 (PMI) 制定了一套有关项目管理知识体系的图表和词汇基准。项目经理很快意识到,并非一本书就可以包含项目管理知识体系的所有内容。因此,PMI 制定并发布了《项目管理知识体系指南》(简称《PMBOK® 指南》)。

PMI 将项目管理知识体系 (PMBOK) 定义为描述项目管理专业范围内知识的术语。项目管理知识体系包括已被验证并广泛应用的传统做法,以及本专业新近涌现的创新做法。

知识体系 (BOK) 包括已发布和未发布的材料。这一知识体系仍在不断演变发展。本《PMBOK® 指南》收录项目管理知识体系中被普遍认可为“良好实践”的那一部分。

  • 所谓“普遍认可”,是指这些知识和做法在大多数时候适用于大多数项目,并且其价值和有效性已获得一致认可。
  • 所谓“良好实践”,则指人们普遍认为,在项目管理过程中使用这些知识、技能、工具和技术,能够达成预期的商业价值和成果,从而提高很多项目成功的可能性。

项目经理与项目团队和其他相关方携手合作,共同确定并采用适用于各个项目且被普遍认可的良好实践。确定过程、输入、工具、技术、输出和生命周期阶段的恰当组合以管理项目的过程,即指本指南所述知识的“裁剪”应用。

本《PMBOK® 指南》与方法论有所不同。方法论是由专门的从业人员所采用的实践、技术、程序和规则所组成的体系。而本《PMBOK® 指南》是组织制定实践项目管理所需方法论、政策、程序、规则、工具、技术和生命周期阶段的基础。

通用词汇是专业学科的基本要素。《PMI 项目管理术语词典》[4] 收录了基本的专业词汇,供组织、项目组合、项目集和项目经理及其他项目相关方统一使用。《术语词典》会随着时间的推移而更改。本指南的词汇表包含了《术语词典》中的词汇以及其他定义。项目可能会采用由行业文献定义的相关行业特定的术语。

项目是为创造独特的产品、服务或成果而进行的临时性工作。

  • 独特的产品、服务或成果。开展项目是为了通过可交付成果达成目标。目标指的是工作所指向的结果,要达到的战略地位,要达到的目的,要取得的成果,要生产的产品,或者准备提供的服务。可交付成果指的是在某一过程、阶段或项目完成时,必须产出的任何独特并可核实的产品、成果或服务能力。可交付成果可能是有形的,也可能是无形的。

实现项目目标可能会产生以下一个或多个可交付成果:

  • 一个独特的产品,可能是其他产品的组成部分、某个产品的升级版或修正版,也可能其本身就是新的最终产品(例如一个最终产品缺陷的修正);
  • 一种独特的服务或提供某种服务的能力(如支持生产或配送的业务职能);
  • 一项独特的成果,例如某个结果或文件(如某研究项目所创造的知识,可据此判断某种趋势是否存在,或判断某个新过程是否有益于社会);
  • 一个或多个产品、服务或成果的独特组合(例如一个软件应用程序及其相关文件和帮助中心服务)。

某些项目可交付成果和活动中可能存在重复的元素,但这种重复并不会改变项目工作本质上的独特性。例如,即便采用相同或相似的材料,由相同或不同的团队来建设,但每个建筑项目仍具备独特性(例如位置、设计、环境、情况、参与项目的人员)。

项目可以在组织的任何层面上开展。一个项目可能只涉及一个人,也可能涉及一组人;可能只涉及一个组织单元,也可能涉及多个组织的多个单元。

项目的例子包括(但不限于):

  • 为市场开发新的复方药;
  • 扩展导游服务;
  • 合并两家组织;
  • 改进组织内的业务流程;
  • 为组织采购和安装新的计算机硬件系统;
  • 一个地区的石油勘探;
  • 修改组织内使用的计算机软件;
  • 开展研究以开发新的制造过程;
  • 建造一座大楼。
  • 临时性工作。项目的“临时性”是指项目有明确的起点和终点。“临时性”并不一定意味着项目的持续时间短。在以下一种或多种情况下,项目即宣告结束:
  • 达成项目目标;
  • 不会或不能达到目标;
  • 项目资金缺乏或没有可分配资金;
  • 项目需求不复存在(例如,客户不再要求完成项目,战略或优先级的变更致使项目终止,组织管理层下达终止项目的指示);
  • 无法获得所需人力或物力资源;
  • 出于法律或便利原因而终止项目。

虽然项目是临时性工作,但其可交付成果可能会在项目的终止后依然存在。项目可能产生与社会、经济、材料或环境相关的可交付成果。例如,国家纪念碑建设项目就是要创造一个流传百世的可交付成果。

  • 项目驱动变更。项目驱动组织进行变更。从商业角度来看,项目旨在推动组织从一个状态转到另一个状态,从而达成特定目标(见图 1-1)。在项目开始之前,通常将此时的组织描述为“当前状态”。项目驱动变更是为了获得期望的结果,即“将来状态”。

有些项目可能会创造一个过渡状态,即由多个步骤组成的连续区间,以过渡到将来状态。通过成功完成项目,组织可以实现将来状态并达成特定目标。关于项目管理和变更的更多信息,请参见《管理组织变更:实践指南》[6]。

图 1-1组织通过项目进行状态转换

  • 项目创造商业价值。PMI 将商业价值定义为从商业运作中获得的可量化净效益。效益可以是有形的、无形的或两者兼有之。在商业分析中,商业价值被视为回报,即以某种投入换取时间、资金、货物或无形的回报(参见《从业者商业分析:实践指南》,第 185 页 [7])。

项目的商业价值指特定项目的成果能够为相关方带来的效益。项目带来的效益可以是有形的、无形的或两者兼有之。

有形效益的例子包括:

  • 货币资产;
  • 股东权益;
  • 公共事业;
  • 固定设施;
  • 工具;
  • 市场份额。

无形效益的例子包括:

  • 商誉;
  • 品牌认知度;
  • 公共利益;
  • 商标;
  • 战略一致性;
  • 声誉。
  • 项目启动背景。组织领导者启动项目是为了应对影响该组织的因素。这些基本因素说明了项目背景,大致分为四类(见图 1-2):
  • 符合法规、法律或社会要求;
  • 满足相关方的要求或需求;
  • 执行、变更业务或技术战略;
  • 创造、改进或修复产品、过程或服务。

图 1-2项目启动背景

这些因素会影响组织的持续运营和业务战略。领导者应对这些因素,以便组织持续运营。项目为组织提供了一个有效的途径,使其能够成功做出应对这些因素所需的变更。这些因素最终应与组织的战略目标以及各个项目的商业价值相关联。

表 1-1 展示了如何将示例因素归入一个或多个基本因素类别。

表 1-1促成项目创建的因素示例

项目管理过程、工具和技术的运用为组织达成目的和目标奠定了坚实的基础。一个项目可以采用三种不同的模式进行管理:作为一个独立项目(不包括在项目组合或项目集中)、在项目集内或在项目组合内。如果在项目组合或项目集内管理某个项目,则项目经理需要与项目集和项目组合经理互动合作。例如,为达成组织的一系列目的和目标,可能需要实施多个项目。在这种情况下,项目可能被归入项目集中。项目集是一组相互关联且被协调管理的项目、子项目集和项目集活动,以便获得分别管理所无法获得的利益。项目集不是大项目。规模特别大的项目称为“大型项目”。一般定义,大型项目通常需要 10 亿美元或以上的成本,可影响上百万人,并且将持续数年。

有些组织可能会采用项目组合,以有效管理在任何特定的时间内同时进行的多个项目集和项目。

项目组合是指为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。图 1-3 展示了项目组合、项目集、项目和运营在特定情况下如何关联的。

项目集管理和项目组合管理的生命周期、活动、目标、重点和效益都与项目管理不同;但是,项目组合、项目集、项目和运营通常都涉及相同的相关方,还可能需要使用同样的资源(见图 1-3),而这可能会导致组织内出现冲突。这种情况促使组织增强内部协调,通过项目组合、项目集和项目管理达成组织内部的有效平衡。

图 1-3 所示的项目组合结构示例表明了项目集、项目、共享资源和相关方之间的关系。将项目组

合组成部分合为一组能够促进这项工作的有效治理和管理,从而有助于实现组织战略和相关优先级。在开展组织和项目组合规划时,要基于风险、资金和其他考虑因素对项目组合组件排列优先级。项目组合方法有利于组织了解战略目标在项目组合中的实施情况,还能促进适当项目组合、项目集和项目治理的实施和协调。这种协调治理方式可为实现预期绩效和效益而分配人力、财力和实物资源。

图 1-3项目组合、项目集、项目和运营

从组织的角度来看项目、项目集和项目组合管理:

  • 项目集和项目管理的重点在于以“正确”的方式开展项目集和项目;
  • 项目组合管理则注重于开展“正确”的项目集和项目。

表 1-2 概述了项目组合、项目集与项目组合管理的比较。

表 1-2项目、项目集、项目组合管理的比较概述

项目集管理指在项目集中应用知识、技能与原则来实现项目集的目标,获得分别管理项目集组成部分所无法实现的利益和控制。项目集组成部分指项目集中的项目和其他项目集。项目管理注重项目本身的相互依赖关系,以确定管理项目的最佳方法。项目集管理注重作为组成部分的项目与项目集之间的依赖关系,以确定管理这些项目的最佳方法。项目集和项目间依赖关系的具体管理措施可能包括:

  • 调整对项目集和项目的目的和目标有影响的组织或战略方向;
  • 将项目集范围分配到项目集组成部分;
  • 管理项目集组成部分之间的依赖关系,从而以最佳方式实施项目集;
  • 管理可能影响项目集内多个项目的项目集风险;
  • 解决影响项目集内多个项目的制约因素和冲突;
  • 解决作为组成部分的项目与项目集之间的问题;
  • 在同一个治理框架内管理变更请求;
  • 将预算分配到项目集内的多个项目;
  • 确保项目集及其包含的项目能够实现效益。

建立一个新的通信卫星系统就是项目集的一个实例,其所辖项目包括卫星与地面站的设计和建造、卫星发射以及系统整合。

关于项目集管理的更多信息,请参见《项目集管理标准》[3]。

项目组合是指为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。

项目组合管理是指为了实现战略目标而对一个或多个项目组合进行的集中管理。项目组合中的项目集或项目不一定彼此依赖或直接相关。

项目组合管理的目的是:

  • 指导组织的投资决策。
  • 选择项目集与项目的最佳组合方式,以达成战略目标。
  • 提供决策透明度。
  • 确定团队和实物资源分配的优先顺序。
  • 提高实现预期投资回报的可能性。
  • 实现对所有组成部分的综合风险预测的集中式管理。

此外,项目组合管理还可确定项目组合是否符合组织战略。

要实现项目组合价值的最大化,需要精心检查项目组合的组成部分。确定组成部分的优先顺序,使最有利于组织战略目标的组成部分拥有所需的财力、人力和实物资源。

例如,以“投资回报最大化”为战略目标的某基础设施公司,可以把油气、供电、供水、道路、铁路和机场等项目归并成一个项目组合。在这些归并的项目中,组织又可以把相互关联的项目作为项目组合来管理。所有供电项目归类成供电项目组合,同理,所有供水项目归类成供水项目组合。然而,如果组织的项目是设计和建造发电站并运营发电站,这些相互关联的项目可以归类成一个项目集。这样的话,供电项目集和类似的供水项目集就是该基础设施公司项目组合中的基本组成部分。

关于项目组合管理的更多信息,请参见《项目组合管理标准》[2]。

.

业务或组织运营的改变也许就是某个项目的关注焦点,尤其当项目交付的新产品或新服务将导致业务运营的有实质性改变时。持续运营不属于项目的范畴,但是它们之间存在交叉。

项目与运营会在产品生命周期的不同时点交叉,例如:

  • 在新产品开发、产品升级或提高产量时;
  • 在改进运营或产品开发流程时;
  • 在产品生命周期结束阶段;
  • 在每个收尾阶段。

在每个交叉点,可交付成果及知识在项目与运营之间转移,以完成工作交接。在这一过程中,将转移项目资源或知识到运营中,或转移运营资源到项目中。

项目组合、项目集和项目均需符合组织战略,或由组织战略驱动,并以不同的方式服务于战略目标的实现:

  • 项目组合管理通过选择适当的项目集或项目,对工作进行优先排序,以及提供所需资源,来与组织战略保持一致。
  • 项目集管理对其组成部分进行协调,对它们之间的依赖关系进行控制,从而实现既定收益。
  • 项目管理使组织的目的和目标得以实现。

作为项目组合或项目集的组成部分,项目是实现组织战略和目标的一种手段,常常应用于作为项目投资主要引导因素的战略规划之中。为了使项目符合组织的战略业务目标,对项目组合、项目集和项目进行系统化管理,可以应用组织级项目管理 (OPM)。OPM 指为实现战略目标而整合项目组合、项目集和项目管理与组织驱动因素的框架。

OPM 旨在确保组织开展正确的项目并合适地分配关键资源。OPM 有助于确保组织的各个层级都了解组织的战略愿景、支持愿景的举措、目标以及可交付成果。图 1-4 展示了战略、项目组合、项目集、项目和运营相互作用的组织环境。

关于 OPM 的更多信息,请参见《实施组织项目管理:实践指南》[8]。

图 1-4组织项目管理

项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。

生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段,属性是可测量且独特的。属性可能包括(但不限于):

  • 名称(例如阶段 A、阶段 B、阶段 1、阶段 2、提建议阶段);
  • 数量(例如项目的三个阶段、项目的五个阶段);
  • 持续时间(例如一个星期、一个月、一个季度);
  • 资源需求(例如人力、建筑、设备);
  • 项目进入某一阶段的准入标准(例如已获得特定批准文件、已完成特定文件);
  • 项目完成某一阶段的退出标准(例如已获得批准文件、已完成文件、已达成可交付成果)。

项目可以分解为不同的阶段或子组件,这些阶段或子组件的名称通常说明了该阶段完成的工作类型。阶段名称的例子包括(但不限于):

  • 概念开发;
  • 可行性研究;
  • 客户要求;
  • 解决方案开发;
  • 设计;
  • 原型法;
  • 建造;
  • 测试;
  • 转换;
  • 试运行;
  • 里程碑审查;
  • 经验教训。

项目阶段可基于各种因素而建立,其中包括(但不限于):

  • 管理需求;
  • 项目性质;
  • 组织、行业或技术的独特性;
  • 项目的组成要素,包括但不限于技术、工程、业务、过程或法律;
  • 决策点(例如资金、继续/终止项目,里程碑审查)。

分为多个阶段的方式有助于更好地掌控项目管理,同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。项目阶段的其中一个关键组成部分是阶段审查(见 1.2.4.3 节)。

阶段关口在项目阶段结束时进行,将项目的绩效和进度与项目和业务文件比较,这些文件包括( 但不限于):

  • 项目商业论证(见 1.2.6.1 节);
  • 项目章程(见 4.1 节);
  • 项目管理计划(见 4.2 节);
  • 效益管理计划(见 1.2.6.2 节)。

根据比较结果做出决定(例如继续/终止的决定),以便:

  • 进入下个阶段;
  • 整改后进入下个阶段;
  • 结束项目;
  • 停留在当前阶段;
  • 重复阶段或某个要素。

在不同的组织、行业或工作类型中,阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。组织可以通过这些审查来检查本指南范围之外的其他相关项,例如产品相关文件或模型。

除了过程组,过程还可以按知识领域进行分类。知识领域指按所需知识内容来定义的项目管理领域,并用其所含过程、实践、输入、输出、工具和技术进行描述。

虽然知识领域相互联系,但从项目管理的角度来看,它们是分别定义的。本指南确定了大多数情况下大部分项目通常使用的十个知识领域。本指南描述的十个知识领域包括:

  • 项目整合管理包括为识别、定义、组合、统一和协调各项目管理过程组的各个过程和活动而开展的过程与活动。
  • 项目范围管理包括确保项目做且只做所需的全部工作以成功完成项目的各个过程。
  • 项目进度管理包括为管理项目按时完成所需的各个过程。
  • 项目成本管理包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程。
  • 项目质量管理包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方的期望的各个过程。
  • 项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程。
  • 项目沟通管理包括为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程。
  • 项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。
  • 项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。
  • 项目相关方管理包括用于开展下列工作的各个过程:识别影响或受项目影响的人员、团队或组织,分析相关方对项目的期望和影响,制定合适的管理策略来有效调动相关方参与项目决策和执行。

某些项目可能需要一个或多个其他的知识领域,例如,建造项目可能需要财务管理或安全与健康管理。表 1-4 列出了项目管理过程组和知识领域。第 4 章至第 13 章详细说明了各个知识领域。该表格概述了第 4 章至第 13章所描述的基本过程。

表 1-4项目管理过程组与知识领域

项目经理通常将项目管理方法论应用于工作。方法论是由专门的从业人员所采用的实践、技术、程序和规则所组成的体系。根据这一定义,本指南本身并不是方法论。

建议在裁剪时参考本指南和《项目管理标准》[1],因为这些标准文件可识别项目管理知识体系中被普遍认可为“良好实践”的那一部分。“良好实践”并不意味着这些知识总是一成不变地应用于所有项目。本指南不讨论具体的方法论。

项目管理方法论可能:

  • 由组织内的专家开发;
  • 从供应商采购而来;
  • 从专业协会获取;
  • 从政府机构获取。

应选择恰当的项目管理过程、输入、工具、技术、输出和生命周期阶段以管理项目。这一选择活动即为针对项目裁剪的项目管理。项目经理与项目团队、发起人或组织管理层合作进行裁剪。在某些情况下,组织可能要求采用特定的项目管理方法论。

由于每个项目都是独特的,所以有必要进行裁剪;并非每个项目都需要《PMBOK® 指南》所确定的每个过程、工具、技术、输入或输出。裁剪应处理关于范围、进度、成本、资源、质量和风险的相互竞争的制约因素。各个制约因素对不同项目的重要性不一样,项目经理应根据项目环境、组织文化、相关方需求和其他变量裁剪管理这些制约因素的方法。

在裁剪项目管理时,项目经理还应考虑运行项目所需的各个治理层级,并考虑组织文化。此外,还需要考虑来自于组织内部还是外部的项目客户也可能会影响项目管理的裁剪决定。

合理的项目管理方法论需要考虑项目的独特性,允许项目经理做出一定程度的裁剪。不过,对某一特定项目而言,方法论中的裁剪法本身可能也需要进行裁剪。

项目经理需要确保项目管理方法紧扣商业文件的意图。表 1-5 列出了这些文件的定义。在整个项目生命周期中,这两种文件相互依赖并得到反复制定和维护。

表 1-5项目商业文件

项目发起人通常负责项目商业论证文件的制定和维护。项目经理负责提供建议和见解,使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致,并与组织的目的和目标保持一致。

项目经理应适当地为项目裁剪上述项目管理文件。某些组织会维护项目集层面的商业论证和效益管理计划。项目经理应与相应的项目集经理合作,确保项目管理文件与项目集文件保持一致。图 1-8说明了这些关键项目管理商业文件与需求评估之间的相互关系。图 1-8 展示了项目生命周期内各种文件大概的生命周期。

图 1-8需求评估与关键业务/项目文件的相互关系

项目商业论证指文档化的经济可行性研究报告,用来对尚缺乏充分定义的所选方案的收益进行有效性论证,是启动后续项目管理活动的依据。商业论证列出了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成功。商业论证是一种项目商业文件,可在整个项目生命周期中使用。在项目启动之前通过商业论证,可能会做出继续/终止项目的决策。

需求评估通常是在商业论证之前进行,包括了解业务目的和目标、问题及机会,并提出处理建议。需求评估结果可能会在商业论证文件中进行总结。

定义业务需要、分析形势、提出建议和定义评估标准的过程,适用于任何组织的项目。商业论证可能包括(但不限于)记录以下内容:

  • 业务需要;
  • 确定促进采取行动的动机;
  • 情况说明,记录了待处理的业务问题或机会,包括能够为组织创造的价值;
  • 确定受影响的相关方;
  • 确定范围。
  • 形势分析:
  • 确定组织战略、目的和目标;
  • 确定问题的根本原因或机会的触发因素;
  • 分析项目所需能力与组织现有能力之间的差距;
  • 识别已知风险;
  • 识别成功的关键因素;
  • 确定可能用于评估各种行动的决策准则;

用于形势分析的准则可分为:

* 必需。必须践行的准则,可处理问题或机会。

* 预期。希望践行的准则,可处理问题或机会。

* 可选。非必要的准则。这一准则的践行情况可能成为区分备选行动方案的因素。

  • 确定一套方案,用以处理业务问题或机会。可选方案指组织可能采取的备选行动方案。

可选方案也可称为商业场景。例如,商业论证可提供以下三种可选方案:

* 不采取任何行动。亦称为“一切照常”方案。选择这种方案会使项目未被授权。

* 尽最小的努力处理问题或机会。最小的努力可能指确定一系列对处理问题或机会而言极为关键的既定准则。

* 以超过最低限度的努力处理问题或机会。这一方案可满足最低限度的准则以及一些或所有其他在案准则。商业论证可能会提供上述多个方案。

  • 推荐:
  • 一种给出了针对项目的建议方案的说明书;
  • 说明书的内容可能包括(但不限于):

* 潜在方案的分析结果;

* 潜在方案的制约因素、假设、风险和依赖关系;

* 成功标准(见 1.2.6.4 节)。

  • 一种实施方法,可能包括(但不限于):

* 里程碑;

* 依赖关系;

* 角色与职责。

  • 评估:
  • 一种描述了衡量项目交付效益的计划的说明书,应包含在初步实施之后,任何持续运营层面的可选方案。

通过将成果与目标和确定的成功标准进行比较,商业论证文件为衡量整个项目生命周期的成功和进展奠定了基础。请参见《从业者商业分析:实践指南》[7]。

项目效益管理计划描述了项目实现效益的方式和时间,以及应制定的效益衡量机制。项目效益指为发起组织和项目预期受益方创造价值的行动、行为、产品、服务或成果的结果。项目生命周期早期应确定目标效益,并据此制定效益管理计划。它描述了效益的关键要素,可能包括(但不限于)记录以下内容:

  • 目标效益(例如预计通过项目实施可以创造的有形价值和无形价值;财务价值体现为净现值);
  • 战略一致性(例如项目效益与组织业务战略的一致程度);
  • 实现效益的时限(例如阶段效益、短期效益、长期效益和持续效益);
  • 效益责任人(例如在计划确定的整个时限内负责监督、记录和报告已实现效益的负责人);
  • 测量指标(例如用于显示已实现效益的直接测量值和间接测量值);
  • 假设(例如预计存在或显而易见的因素);
  • 风险(例如实现效益的风险)。

制定效益管理计划需要使用商业论证和需求评估中的数据和信息,例如,成本效益分析数据。

在成本效益分析中已经把成本估算与项目拟实现的效益进行了比较。效益管理计划和项目管理计划描述了项目创造的商业价值如何能够成为组织持续运营的一部分,包括使用的测量指标。测量指标可核实商业价值并确认项目成功与否。

项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程和项目管理计划的补充性文件。项目经理与发起人共同确保项目章程、项目管理计划和效益管理计划在整个项目生命周期内始终保持一致。请参见《从业者商业分析:实践指南》[7]、《项目集管理标准》[3]和《项目组合管理标准》[2]。

项目章程是由项目发起人发布的,正式批准项目成立,并授权项目经理动用组织资源开展项目活动的文件。

项目管理计划是描述如何执行、监督和控制项目的一份文件。

关于项目章程和项目管理计划的更多信息,请参见第 4 章项目整合管理。

确定项目是否成功是项目管理中最常见的挑战之一。

时间、成本、范围和质量等项目管理测量指标历来被视为确定项目是否成功的最重要的因素。

最近,从业者和学者提出,确定项目是否成功还应考虑项目目标的实现情况。

关于项目成功的定义和最重要的因素,项目相关方可能有不同的看法。明确记录项目目标并选择可测量的目标是项目成功的关键。主要相关方和项目经理应思考以下三个问题:

  • 怎样才是项目成功?
  • 如何评估项目成功?
  • 哪些因素会影响项目成功?

主要相关方和项目经理应就这些问题达成共识并予以记录。

项目成功可能涉及与组织战略和业务成果交付有关的其他标准。这些项目目标可能包括(但不限于):

  • 完成项目效益管理计划;
  • 达到商业论证中记录的已商定的财务测量指标。这些财务测量指标可能包括(但不限于):
  • 净现值 (NPV);
  • 投资回报率 (ROI);
  • 内部报酬率 (IRR);
  • 回收期 (PBP);
  • 效益成本比率 (BCR)。
  • 达到商业论证的非财务目标;
  • 完成组织从“当前状态”转到“将来状态”;
  • 履行合同条款和条件;
  • 达到组织战略、目的和目标;
  • 使相关方满意;
  • 可接受的客户/最终用户的采纳度;
  • 将可交付成果整合到组织的运营环境中;
  • 满足商定的交付质量;
  • 遵循治理规则;
  • 满足商定的其他成功标准或准则(例如过程产出率)。

为了取得项目成功,项目团队必须能够正确评估项目状况,平衡项目要求,并与相关方保持积极主动的沟通。

但在业务环境中,如果项目能够与组织的战略方向持续保持一致,那么项目成功的概率就会显著提高。

有可能一个项目从范围/进度/预算来看是成功的,但从商业角度来看并不成功。这是因为业务需要和市场环境在项目完成之前发生了变化。

项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。

事业环境因素源于项目外部(往往是企业外部)的环境,事业环境因素可能对整个企业、项目组合、项目集或项目产生影响。关于事业环境因素的更多信息,请参见 2.2 节。

组织过程资产源于企业内部,可能来自企业自身、项目组合、项目集、其他项目或这些的组合。

图 2-1 分解了事业环境因素和组织过程资产所涵盖的项目影响。关于组织过程资产的更多信息,请参

见 2.3 节。

图 2-1项目影响

除了事业环境因素和组织过程资产,组织系统对项目生命周期也起着重要的作用。组织系统(见2.4 节)进一步讨论了影响了组织系统内部人员的权力、影响力、利益、技能和政治能力的系统因素。

事业环境因素(EEFs)是指项目团队不能控制的,将对项目产生影响、限制或指令作用的各种条件。这些条件可能来自于组织的内部和(或)外部。事业环境因素是很多项目管理过程,尤其是大多数规划过程的输入。这些因素可能会提高或限制项目管理的灵活性,并可能对项目结果产生积极或消极的影响。

从性质或类型上讲,事业环境因素是多种多样的。有效开展项目,就必须考虑这些因素。事业环境因素包括(但不限于)第 2.2.1 节和 2.2.2 节所描述的因素。

以下是组织内部的事业环境因素:

  • 组织文化、结构和治理。例如包括愿景、使命、价值观、信念、文化规范、领导风格、等级制度和职权关系、组织风格、道德和行为规范。
  • 设施和资源的地理分布。例如包括工厂位置、虚拟团队、共享系统和云计算。
  • 基础设施。例如包括现有设施、设备、组织通讯渠道、信息技术硬件、可用性和功能。
  • 信息技术软件。例如包括进度计划软件工具、配置管理系统、进入其他在线自动化系统的网络界面和工作授权系统。
  • 资源可用性。例如包括合同和采购制约因素、获得批准的供应商和分包商以及合作协议。
  • 员工能力。例如包括现有人力资源的专业知识、技能、能力和特定知识。

以下是组织外部的事业环境因素:

  • 市场条件。例如包括竞争对手、市场份额、品牌认知度和商标。
  • 社会和文化影响与问题。例如包括政治氛围、行为规范、道德和观念。
  • 法律限制。例如包括与安全、数据保护、商业行为、雇佣和采购有关的国家或地方法律法规。
  • 商业数据库。例如包括标杆对照成果、标准化的成本估算数据、行业风险研究资料和风险数据库。
  • 学术研究。例如包括行业研究、出版物和标杆对照成果。
  • 政府或行业标准。例如包括与产品、生产、环境、质量和工艺有关的监管机构条例和标准。
  • 财务考虑因素。例如包括货币汇率、利率、通货膨胀率、关税和地理位置。
  • 物理环境要素。例如包括工作环境、天气和制约因素。

组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库,会影响对具体项目的管理。

组织过程资产包括来自任何(或所有)项目执行组织的,可用于执行或治理项目的任何工件、实践或知识,还包括来自组织以往项目的经验教训和历史信息。组织过程资产可能还包括完成的进度计划、风险数据和挣值数据。组织过程资产是许多项目管理过程的输入。由于组织过程资产存在于组织内部,在整个项目期间,项目团队成员可对组织过程资产进行必要的更新和增补。组织过程资产可分成以下两大类:

  • 过程、政策和程序;
  • 组织知识库。

第一类资产的更新通常不是项目工作的一部分,而是由项目管理办公室 (PMO) 或项目以外的其他职能部门完成。更新工作仅须遵循与过程、政策和程序更新相关的组织政策。有些组织鼓励团队裁剪项目的模板、生命周期和核对单。在这种情况下,项目管理团队应根据项目需求裁剪这些资产。

第二类资产是在整个项目期间结合项目信息而更新的。例如,整个项目期间会持续更新与财务绩效、经验教训、绩效指标和问题以及缺陷相关的信息。

组织用于执行项目工作的流程与程序,包括(但不限于):

  • 启动和规划
    • 指南和标准,用于裁剪组织标准流程和程序以满足项目的特定要求;
    • 特定的组织标准,例如政策(如人力资源政策、健康与安全政策、安保与保密政策、质量政策、采购政策和环境政策);
    • 产品和项目生命周期,以及方法和程序(如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内使用的标准化的过程定义);
    • 模板(如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵,以及相关方登记册模板);
    • 预先批准的供应商清单和各种合同协议类型(如总价合同、成本补偿合同和工料合同)。
  • 执行、监控:
    • 变更控制程序,包括修改组织标准、政策、计划和程序(或任何项目文件)所须遵循的步骤,以及如何批准和确认变更;
    • 跟踪矩阵;
    • 财务控制程序(如定期报告、必需的费用与支付审查、会计编码及标准合同条款等);
    • 问题与缺陷管理程序(如定义问题和缺陷控制、识别与解决问题和缺陷,以及跟踪行动方案)。
    • 资源的可用性控制和分配管理;
    • 组织对沟通的要求(如可用的沟通技术、许可的沟通媒介、记录保存政策、视频会议、协同工具和安全要求);
    • 确定工作优先顺序、批准工作与签发工作授权的程序;
    • 模板(如风险登记册、问题日志和变更日志);
    • 标准化的指南、工作指示、建议书评价准则和绩效测量准则;
    • 产品、服务或成果的核实和确认程序。
  • 收尾项目收尾指南或要求(如项目终期审计、项目评价、可交付成果验收、合同收尾、资源分配,以及向生产和(或)运营部门转移知识)

组织用来存取信息的知识库,包括(但不限于):

  • 配置管理知识库,包括软件和硬件组件版本以及所有执行组织的标准、政策、程序和任何项目文件的基准;
  • 财务数据库,包括人工时、实际成本、预算和成本超支等方面的信息;
  • 历史信息与经验教训知识库(如项目记录与文件、完整的项目收尾信息与文件、关于以往项目选择决策的结果及以往项目绩效的信息,以及从风险管理活动中获取的信息);
  • 问题与缺陷管理数据库,包括问题与缺陷的状态、控制信息、解决方案以及相关行动的结果;
  • 测量指标数据库,用来收集与提供过程和产品的测量数据;
  • 以往项目的项目档案(如范围、成本、进度与绩效测量基准,项目日历,项目进度网络图,风险登记册,风险报告以及相关方登记册)。

运行项目时需要应对组织结构和治理框架带来的制约因素。为有效且高效地开展项目,项目经理需要了解组织内的职责、终责和职权的分配情况。这有助于项目经理有效地利用其权力、影响力、能力、领导力和政治能力成功完成项目。

单个组织内多种因素的交互影响创造出一个独特的系统,会对在该系统内运行的项目造成影响。这种组织系统决定了组织系统内部人员的权力、影响力、利益、能力和政治能力。系统因素包括(但不限于):

  • 管理要素;
  • 治理框架;
  • 组织结构类型。

组织系统因素的完整信息和说明,以及这些因素组合对项目的影响方式并不在本指南范围之内。

本指南并不像有些与文献、方法论和实践相关的学科那样深入地探索这些因素,只是在本节概述了这些因素及其相互关系。

本概述先简要介绍一下系统。系统是各种组件的集合,可以实现单个组件无法实现的成果。组件是项目或组织内的可识别要素,提供了某种特定功能或一组相关的功能。各种系统组件的相互作用创造出组织文化和能力。以下是关于系统的几个原则:

  • 系统是动态的;
  • 系统是可以优化;
  • 系统组件是可以优化;
  • 系统及其组件不能同时优化;
  • 系统呈现非线性响应(输入的变更并不会产生可预测的输出)。

系统内部以及系统与其环境之间可能会发生多个变更。出现这些变更时,各组件内部发生的适应性行为反过来会增加系统的动态特性。这种特性取决于组件之间的联系和依赖关系的相互作用。

系统通常由组织管理层负责。组织管理层检查组件与系统之间的优化权衡,以便采取合适的措施为组织实现最佳结果。这一检查工作的结果将对相应的项目造成影响。因此,项目经理在确定如何达成项目目标时务必要考虑这些结果。此外,项目经理应考虑到组织的治理框架。

近期的 PMI 研究指出,治理指组织各个层面的有组织的或有结构的安排,旨在确定和影响组织成员的行为 [9]。研究结果表明,治理是一个多方面概念,并且:

  • 包括考虑人员、角色、结构和政策;
  • 要求通过数据和反馈提供指导和监督。

治理是在组织内行使职权的框架,其包括(但不限于):

  • 规则;
  • 政策;
  • 程序;
  • 规范;
  • 关系;
  • 系统;
  • 过程。

这个框架会影响:

  • 组织目标的设定和实现方式;
  • 风险监控和评估方式;
  • 绩效优化方式。

《 项目组合、项目集和项目治理:实践指南》[10] 描述了协调组织级项目管理 (OPM) 与项目组合、项目集和项目管理的常见治理框架,涉及四个治理领域:一致性、风险、绩效和沟通。各个领域都具备以下职能部门:监督、控制、整合与决策。各个职能部门都可针对独立项目或项目组合/项目集中的项目的支持过程与活动进行治理。

项目治理是指用于指导项目管理活动的框架、功能和过程,从而创造独特的产品、服务或结果以满足组织、战略和运营目标。不存在一种治理框架适用于所有组织。组织应根据组织文化、项目类型和组织需求裁剪治理框架,才能发挥其作用。

关于项目治理及其实施的更多信息,请参见《项目组合、项目集和项目治理:实践指南》[10]。

管理要素指组织内部关键职能部门或一般管理原则的组成部分。组织根据其选择的治理框架和组织结构类型分配一般管理要素。

关键职能部门或一般管理原则包括(但不限于):

  • 基于专业技能和可用性开展工作的部门;
  • 组织授予的工作职权;
  • 工作职责,开展组织根据技能和经验等属性合理分派的工作任务;
  • 具有纪律性的行为(例如尊重职权、人员和规定);
  • 统一指挥原则(例如一位员工仅接受一个上级对任何行动或活动给出的指示);
  • 统一领导原则(例如针对一组活动只能有一个计划或一个领导人,以及相同的目标);
  • 组织的总体目标优先于个人目标;
  • 支付合理的薪酬;
  • 资源的优化使用;
  • 畅通的沟通渠道;
  • 在正确的时间让正确的人使用正确的材料做正确的事情;
  • 公正、平等地对待所有员工;
  • 明确工作岗位的安全职责;
  • 确保员工安全;
  • 允许任何员工参与计划和实施;
  • 保持员工士气。

组织将这些管理要素的绩效分派到选定的员工身上。这些员工可能在不同的组织层级上执行上述职能。例如,组织的层级结构有平级和上下级的关系。从基层到高层,这些管理层级关系多种多样。分配到各个层级的职责、终责和职权表明了各个层级的员工在组织结构内执行上述职能的方式。

组织需要权衡两个关键变量之后才可确定合适的组织结构类型。这两个变量指可以采用的组织结构类型以及针对特定组织如何优化组织结构类型的方式。不存在一种结构类型适用于任何特定组织。因要考虑各种可变因素,特定组织的最终结构是独特的。2.4.4.1 节和 2.4.4.2 节描述了在权衡这两个变量时应考虑的一些因素。2.4.4.3 节讨论了项目管理中常见的一种组织结构。

组织结构的形式或类型是多种多样的。表 2-1 比较了几种组织结构类型及其对项目的影响。

在确定组织结构时,每个组织都需要考虑大量的因素。在最终分析中,每个因素的重要性也各不相同。综合考虑因素及其价值和相对重要性为组织决策者提供了正确的信息,以便进行分析。

选择组织结构时应考虑的因素包括(但不限于):

  • 与组织目标的一致性;
  • 专业能力;
  • 控制、效率与效果的程度;
  • 明确的决策升级渠道;
  • 明确的职权线和范围;
  • 授权方面的能力;
  • 终责分配;
  • 职责分配;
  • 设计的灵活性;
  • 简单的设计;
  • 实施效率;
  • 成本考虑;
  • 物理位置(例如集中办公、区域办公和虚拟远程办公);
  • 清晰的沟通(例如政策、工作状态和组织愿景)。

表 2-1组织结构对项目的影响

项目管理办公室 (PMO) 是对与项目相关的治理过程进行标准化,并促进资源、方法论、工具和技术共享的一个组织结构。PMO 的职责范围可大可小,从提供项目管理支持服务,到直接管理一个或多个项目。

PMO 有几种不同类型,它们对项目的控制和影响程度各不相同,例如:

  • 支持型。支持型 PMO 担当顾问的角色,向项目提供模板、最佳实践、培训,以及来自其他项目的信息和经验教训。这种类型的 PMO 其实就是一个项目资源库,对项目的控制程度很低。
  • 控制型。控制型 PMO 不仅给项目提供支持,而且通过各种手段要求项目服从,这种类型的 PMO对项目的控制程度属于中等。服从可能包括:
  • 采用项目管理框架或方法论;
  • 使用特定的模板、格式和工具;
  • 服从治理。
  • 指令型。指令型 PMO 直接管理和控制项目。项目经理由 PMO 指定并向其报告。这种类型的 PMO对项目的控制程度很高。

项目管理办公室可能会承担整个组织范围的职责,在支持战略调整和创造组织价值方面发挥重要的作用。PMO 从组织战略项目中获取数据和信息,进行综合分析,评估如何实现更高级别的战略目标的。PMO 在组织的项目组合、项目集、项目与组织考评体系(如平衡计分卡)之间建立联系。

除了被集中管理以外,PMO 所支持和管理的项目不一定彼此关联。PMO 的具体形式、职能和结构取决于所在组织的需要。

为了保证项目符合组织的业务目标,PMO 可能有权在每个项目的生命周期中充当重要相关方和关键决策者。PMO 可以:

  • 提出建议;
  • 领导知识传递;
  • 终止项目;
  • 根据需要采取其他行动。

PMO 的一个主要职能是通过各种方式向项目经理提供支持,这些方式包括(但不限于):

  • 对 PMO 所辖的全部项目的共享资源进行管理;
  • 识别和制定项目管理方法、最佳实践和标准;
  • 指导、辅导、培训和监督;
  • 通过项目审计,监督对项目管理标准、政策、程序和模板的遵守程度;
  • 制定和管理项目政策、程序、模板和其他共享的文件(组织过程资产);
  • 对跨项目的沟通进行协调。

项目经理在领导项目团队达成项目目标方面发挥至关重要的作用。在整个项目期间,这个角色的作用非常明显。很多项目经理从项目启动时参与项目,直到项目结束。不过,在某些组织内,项目经理可能会在项目启动之前就参与评估和分析活动。这些活动可能包括咨询管理层和业务部门领导者的想法,以推进战略目标的实现、提高组织绩效,或满足客户需求。某些组织可能还要求项目经理管理或协助项目的商业分析、商业论证的制定以及项目组合管理事宜。项目经理还可能参与后续跟进活动,以实现项目的商业效益。不同组织对项目经理的角色有不同的定义,但本质上它们的裁剪方式都一样——项目管理角色需要符合组织需求,如同项目管理过程需要符合项目需求一般。

下面将大型项目的项目经理与大型管弦乐队的指挥作比较,以帮助理解项目经理角色:

  • 成员与角色。大型项目和管弦乐队都包含了很多成员,每个成员都扮演着不同的角色。一个大型管弦乐队可能包括由一位指挥带领的上百位演奏者。这些演奏者需要演奏 25 种不同的乐器,组成了多个主要乐器组,例如弦乐器、木管乐器、铜管乐器和打击乐器。类似的,一个大型项目可能包括由一位项目经理领导的上百位项目成员。这些团队成员需要承担各种不同的角色,例如设计、制造和设施管理。与乐队的主要乐器组一样,项目团队成员也组成了多个业务部门或小组。演奏者和项目成员都会形成对应的团队。
  • 在团队中的职责。项目经理和指挥都需要为团队的成果负责,分别是项目成果和交响音乐会。

这两个领导者都需要从整体的角度来看待团队产品,以便进行规划、协调和完成。首先,应审查各自组织的愿景、使命和目标,确保与产品保持一致。然后解释与成功完成产品相关的愿景、使命和目标。最后向团队沟通自己的想法,激励团队成功完成目标。

  • 知识和技能:
  • 指挥不需要掌握每种乐器,但应具备音乐知识、理解和经验。指挥通过沟通领导乐队并进行规划和协调,采用乐谱和排练计划作为书面沟通形式,还通过指挥棒和其他肢体语言与团队进行实时沟通。
  • 项目经理无需承担项目中的每个角色,但应具备项目管理知识、技术知识、理解和经验。

项目经理通过沟通领导项目团队进行规划和协调。项目经理采用书面沟通(文档计划和进度),还通过会议和口头提示或非言语提示与团队进行实时沟通。

本章接下来的部分讨论项目经理角色的主要方面。关于这个话题有数以千计书籍和文章,但本章不涵盖全部内容,而是旨在通过概述让从业者对这个话题有个基本的认识,为深入研究文中提及的各个方面做好准备。

项目经理的角色不同于职能经理或运营经理。一般而言,职能经理专注于对某个职能领域或业务部门的管理监督。运营经理负责保证业务运营的高效性。项目经理是由执行组织委派,领导团队实现项目目标的个人。

项目经理领导项目团队实现项目目标和相关方的期望。项目经理利用可用资源,以平衡相互竞争的制约因素。

项目经理还充当项目发起人、团队成员与其他相关方之间的沟通者,包括提供指导和展示项目成功的愿景。项目经理使用软技能(例如人际关系技能和人员管理技能)来平衡项目相关方之间相互冲突和竞争的目标,以达成共识。这种情况下的共识指即便不 100% 赞同,相关方还会支持项目决定和行动。

研究表明,成功的项目经理可以持续和有效地使用某些基本技能。研究指出,在由上级和团队成员指定的项目经理中,排名前 2% 的项目经理之所以脱颖而出,是因为他们展现出了超凡的人际关系和沟通技能以及积极的态度 [12]。

与团队和发起人等相关方沟通的能力适用于项目的各个方面,包括(但不限于)以下各个方面:

  • 通过多种方法(例如口头、书面和非言语)培养完善的技能;
  • 创建、维护和遵循沟通计划和进度计划;
  • 不断地以可预见的方式进行沟通;
  • 寻求了解项目相关方的沟通需求(沟通可能是某些相关方在最终产品或服务实现之前获取信息的唯一渠道);
  • 以简练、清晰、完整、简单、相关和经过裁剪的方式进行沟通;
  • 包含重要的正面和负面消息;
  • 合并反馈渠道;
  • 人际关系技能,即通过项目经理的影响力范围拓展广泛的人际网络。这些人际网络包括正式的人际网络,例如组织架构图;但项目经理发展、维护和培养的非正式人际网络更加重要。非正式人际网络包括与主题专家和具有影响力的领导者建立的个人人际关系。通过这些正式和非正式的人际网络,项目经理可以让很多人参与解决问题并探询项目中遇到的官僚主义障碍。

对项目经理而言,持续的知识传递和整合非常重要。项目管理专业和项目经理担任主题专家的其他领域都在持续推进相应的专业发展。知识传递和整合包括(但不限于):

  • 在当地、全国和全球层面(例如实践社区、国际组织)向其他专业人员分享知识和专业技能;
  • 参与培训、继续教育和发展:
  • 项目管理专业(例如大学、PMI);
  • 相关专业(例如系统工程、配置管理);
  • 其他专业(例如信息技术、航空航天)。

专业的项目经理针对组织的价值可以选择指导和教育其他专业人员项目管理方法。项目经理还可以担任非正式的宣传大使,让组织了解项目管理在及时性、质量、创新和资源管理方面的优势。

近期的 PMI 研究通过 PMI 人才三角®(见图 3-2)指出了项目经理根据《项目经理能力发展 (PMCD) 框架》需要具备的技能。人才三角重点关注三个关键技能组合:

  • 技术项目管理。与项目、项目集和项目组合管理特定领域相关的知识、技能和行为,即角色履行的技术方面。
  • 领导力。指导、激励和带领团队所需的知识、技能和行为,可帮助组织达成业务目标。
  • 战略和商务管理。关于行业和组织的知识和专业技能,有助于提高绩效并取得更好的业务成果。

图 3-2 PMI 人才三角®

虽然技术项目管理技能是项目集和项目管理的核心,但 PMI 研究指出,当今全球市场越来越复杂,竞争也越来越激烈,只有技术项目管理技能是不够的。各个组织正在寻求其他有关领导力和商业智慧技能。来自不同组织的成员均提出,这些能力可以有助于支持更长远的战略目标,以实现赢利。

为发挥最大的效果,项目经理需要平衡这三种技能。

战略和商务管理技能包括纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力。这项能力可能涉及其他职能部门的工作知识,例如财务部、市场部和运营部。战略和商务管理技能可能还包括发展和运用相关的产品和行业专业知识。这种业务知识也被称为领域知识。项目经理应掌握足够的业务知识,以:

  • 向其他人解释关于项目的必要商业信息;
  • 与项目发起人、团队和主题专家合作制定合适的项目交付策略;
  • 以实现项目商业价值最大化的方式执行策略。

为制定关于项目成功交付的最佳决策,项目经理应咨询具备关于组织运营的专业知识的运营经理。这些经理应了解组织的工作以及项目计划会对工作造成的影响。对项目经理而言,对项目主题的了解越多越好,至少应能够向其他人说明关于组织的以下方面:

  • 战略;
  • 使命;
  • 目的和目标;
  • 产品和服务;
  • 运营(例如位置、类型、技术);
  • 市场和市场条件,例如客户、市场状况(发展或萎缩)和上市时间因素等;
  • 竞争(例如什么、谁、市场地位)。

为确保一致性,项目经理应将以下关于组织的知识和信息运用到项目中:

  • 战略;
  • 使命;
  • 目的和目标;
  • 优先级;
  • 策略;
  • 产品或服务(例如可交付成果)。

战略和商业技能有助于项目经理确定应为其项目考虑哪些商业因素。项目经理应确定这些商业和战略因素会对项目造成的影响,同时了解项目与组织之间的相互关系。这些因素包括(但不限于):

  • 风险和问题;
  • 财务影响;
  • 成本效益分析(例如净现值、投资回报率),包括各种可选方案;
  • 商业价值;
  • 效益预期实现情况和战略;
  • 范围、预算、进度和质量。

通过运用这些商务知识,项目经理能够为项目提出合适的决策和建议。随着条件的变化,项目经理应与项目发起人持续合作,使业务战略和项目策略保持一致。

人际交往占据项目经理工作的很大一部分。项目经理应研究人的行为和动机,应尽力成为一个好的领导者,因为领导力对组织项目是否成功至关重要。项目经理需要运用领导力技能和品质与所有项目相关方合作,包括项目团队、团队指导和项目发起人。

领导和管理的最终目的是办好事情。这些技能和品质有助于项目经理实现项目目的和目标。很多技能和品质归根究底就是处理政治的能力。政治涉及影响、谈判、自主和权力。

政治及其相关要素不局限于“好”与“不好”以及“正面”与“负面”之分。项目经理对组织运行方式的了解越多,就越有可能获得成功。项目经理应观察并收集有关项目和组织概况的数据,然后从项目、相关人员、组织以及整个环境出发来审查这些数据,从而得出计划和执行大多数行动所需的信息和知识。这些行动是项目经理运用适当的权力影响他人和进行协商之后的成果。有了权力就有了职责,项目经理应体察并尊重他人。项目经理的有效行动保持相关人员的独立自主。项目经理的行动成果就是让合适的人执行必要的活动来实现项目目标。

权力可能体现个人或组织的特征。人们对领导者的认知通常是因为权力;因此,项目经理应注意自己与他人的关系是非常重要的。借助人际关系可以让项目相关事项得到落实。行使权力的方式有很多,项目经理可自行决定。由于权力的性质以及影响项目的各种因素,权力及其运用变得非常复杂。行使权力的方式包括(但不限于):

  • 地位(有时称为正式的、权威的、合法的,例如组织或团队授予的正式职位);
  • 信息(例如收集或分发的控制);
  • 参考(例如因为他人的尊重和赞赏,获得的信任);
  • 情境(例如在危机等特殊情况下获得的权力);
  • 个性或魅力(例如魅力、吸引力);
  • 关系(例如参与人际交往、联系和结盟);
  • 专家(例如拥有的技能和信息、经验、培训、教育、证书);
  • 奖励相关的(例如能够给予表扬、金钱或其他奖励);
  • 处罚或强制力(例如给予纪律处分或施加负面后果的能力);
  • 迎合(例如运用顺从或其他常用手段赢得青睐或合作);
  • 施加压力(例如限制选择或活动自由,以符合预期的行动);
  • 出于愧疚(例如强加的义务或责任感);
  • 说服力(例如能够提供论据,使他人执行预期的行动方案);
  • 回避(例如拒绝参与)。

在权力方面,顶尖的项目经理积极主动且目的明确。这些项目经理会在组织政策、协议和程序许可的范围内主动寻求所需的权力和职权,而不是坐等组织授权。

项目经理领导团队的方式可以分为很多种。项目经理可能会出于个人偏好或在综合考虑了与项目有关的多个因素之后选择领导力风格。根据作用因素的不同,项目经理可能会改变风格。要考虑的主要因素包括(但不限于):

  • 领导者的特点(例如态度、心情、需求、价值观、道德观);
  • 团队成员的特点(例如态度、心情、需求、价值观、道德观);
  • 组织的特点(例如目标、结构、工作类型);
  • 环境特点(例如社会形势、经济状况和政治因素)。

研究显示项目经理可以采用的多种领导力风格。在这些风格中,最常见的包括(但不限于):

  • 放任型领导(例如,允许团队自主决策和设定目标,又被称为“无为而治”);
  • 交易型领导(例如,关注目标、反馈和成就以确定奖励,例外管理);
  • 服务型领导(例如,做出服务承诺,处处先为他人着想;关注他人的成长、学习、发展、自主性和福祉;关注人际关系、团体与合作;服务优先于领导);
  • 变革型领导(例如,通过理想化特质和行为、鼓舞性激励、促进创新和创造,以及个人关怀提高追随者的能力);
  • 魅力型领导(例如,能够激励他人;精神饱满、热情洋溢、充满自信;说服力强);
  • 交互型领导(例如,结合了交易型、变革型和魅力型领导的特点)。

个性指人与人之间在思维、情感和行为的特征模式方面的差异。个人性格特点或特征可能包括(但不限于):

  • 真诚(例如,接受他人不同的个性,表现出包容的态度);
  • 谦恭(例如,能够举止得体、有礼貌);
  • 创造力(例如,抽象思维、不同看法、创新的能力);
  • 文化(例如,具备对其他文化的敏感性,包括价值观、规范和信仰);
  • 情绪(例如,能够感知情绪及其包含的信息并管理情绪,衡量人际关系技能);
  • 智力(例如,以多元智能理论衡量的人的智商);
  • 管理(例如,管理实践和潜力的衡量);
  • 政治(例如,政治智商和把事办好的衡量);
  • 以服务为导向(例如,展现出愿意服务他人的态度);
  • 社会(例如,能够理解和管理他人);
  • 系统化(例如,了解和构建系统的驱动力)。

高效的项目经理在上述各个方面都具备一定程度的能力。每个项目、组织和情况都要求项目经理重视个性的不同方面。

管理项目的方法有很多,而方法的选择通常取决于项目的具体特点,包括规模、项目或组织的复杂性,以及执行组织的文化。显然,项目经理的人际关系技能和能力与其管理项目的方式有紧密的关系。

项目经理应尽量掌握所有项目管理知识领域。熟练掌握这些知识领域之后,项目经理可以将经验、见解、领导力、技术以及商业管理技能运用到项目管理中。最后,项目经理需要整合这些知识领域所涵盖的过程才有可能实现预期的项目结果。

与几十年前相比,当今企业和项目所处的环境有了很大的变化。新技术不断涌现。社交网络、多元文化、虚拟团队和新的价值观都是项目所要面临的全新现实。整合涉及多个组织的、大规模、跨职能项目实施中的知识和人员便是一例。项目经理在指导项目团队进行沟通规划和知识管理时需要考虑这个背景所产生的影响。

在管理整合时,项目经理需要意识到项目背景和这些新因素,然后项目经理可以决定如何在项目中最好地利用这些新环境因素,以获得项目成功。

有些项目可能非常复杂,难以管理。简单来说,“复杂”一词通常被用来描述难以理解或错综复杂的事物。

项目的复杂性来源于组织的系统行为、人类行为以及组织或环境中的不确定性。《项目复杂性管理:实践指南》[13] 将复杂性的三个维度定义为:

  • 系统行为。组成部分与系统之间的依赖关系。
  • 人类行为。不同个体和群体之间的相互作用。
  • 不明确性。出现问题、缺乏理解或造成困惑引发的不确定性。

复杂性本身指个体基于自身经验、观察和技能的一种感知,更准确的描述应该是项目包含复杂性的要素,而不是项目本身复杂。项目组合、项目集和项目可能包含复杂性的要素。

项目整合之前,项目经理应考虑项目内外的要素。项目经理应检查项目的特征或属性。作为项目的一种特征或属性,复杂性通常被定义为:

  • 包含多个部分;
  • 不同部分之间存在一系列连接;
  • 不同部分之间有动态交互作用;
  • 这些交互作用所产生的行为远远大于各部分简单的相加(例如突发性行为)。

这些因素会增加项目的复杂性,通过检查,有助于项目经理在规划、管理和控制项目时可以识别关键领域,确保完成整合。

项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中,整合兼具统一、合并、沟通和建立联系的性质,这些行动应该贯穿项目始终。项目整合管理包括进行以下选择:

  • 资源分配;
  • 平衡竞争性需求;
  • 研究各种备选方法;
  • 为实现项目目标而裁剪过程;
  • 管理各个项目管理知识领域之间的依赖关系。

项目整合管理过程包括:

4.1 制定项目章程 — 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。

4.2 制定项目管理计划 — 定义、准备和协调项目计划的所有组成部分,并把它们整合为一份综合项目管理计划的过程。

4.3 指导与管理项目工作 — 为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。

4.4 管理项目知识 — 使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。

4.5 监控项目工作 — 跟踪、审查和报告整体项目进展,以实现项目管理计划中确定的绩效目标的过程。

4.6 实施整体变更控制 — 审查所有变更请求,批准变更,管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。

4.7 结束项目或阶段 — 终结项目、阶段或合同的所有活动的过程。

图 4-1 概述了项目整合管理的各个过程。虽然在本《PMBOK® 指南》中,各项目整合管理过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 4-1项目整合管理概述

项目整合管理的核心概念项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家(如成本分析专家、进度规划专家、风险管理专家)管理,但是项目整合管理的责任不能被授权或转移。只能由项目经理负责整合所有其他知识领域的成果,并掌握项目总体情况。项目经理必须对整个项目承担最终责任。

项目与项目管理本质上具有整合性质,例如,为应急计划制定成本估算时,就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。在识别出与各种人员配备方案有关的额外风险时,可能需要再次进行上述某个或某几个过程。

项目管理过程组的各个过程之间经常反复发生联系。例如,在项目早期,规划过程组为执行过程组提供书面的项目管理计划;然后,随着项目的进展,规划过程组还将根据变更情况,更新项目管理计划。

项目整合管理指的是:

  • 确保产品、服务或成果的交付日期,项目生命周期以及效益管理计划这些方面保持一致;
  • 编制项目管理计划以实现项目目标;
  • 确保创造合适的知识并运用到项目中,并从项目中获取必要的知识;
  • 管理项目管理计划中活动的绩效和变更;
  • 做出针对影响项目的关键变更的综合决策;
  • 测量和监督项目进展,并采取适当措施以实现项目目标;
  • 收集关于已达成结果的数据,分析数据以获取信息,并与相关方分享信息;
  • 完成全部项目工作,正式关闭各个阶段、合同以及整个项目;
  • 管理可能需要的阶段过渡。

项目越复杂,相关方的期望越多样化,就需要越全面的整合方法。

项目整合管理的发展趋势和新兴实践项目整合管理知识领域要求整合所有其他知识领域的成果。与整合管理过程相关的发展趋势包括(但不限于):

  • 使用自动化工具。项目经理需要整合大量的数据和信息,因此有必要使用项目管理信息系统(PMIS) 和自动化工具来收集、分析和使用信息,以实现项目目标和项目效益。
  • 使用可视化管理工具。有些项目团队使用可视化管理工具,而不是书面计划和其它文档,来获取和监督关键的项目要素。这样,就便于整个团队直观地看到项目的实时状态,促进知识转移,并提高团队成员和其他相关方识别和解决问题的能力。
  • 项目知识管理。项目人员的流动性和不稳定性越来越高,就要求采用更严格的过程,在整个项目生命周期中积累知识并传达给目标受众,以防止知识流失。
  • 增加项目经理的职责。项目经理被要求介入启动和结束项目,例如开展项目商业论证和效益管理。按照以往的惯例,这些事务均由管理层和项目管理办公室负责。现在,项目经理需要频繁地与他们合作处理这些事务,以便更好地实现项目目标以及交付项目效益。项目经理也需要更全面地识别相关方,并引导他们参与项目,包括管理项目经理与各职能部门、运营部门和高级管理人员之间的接口。
  • 混合型方法。经实践检验的新做法会不断地融入项目管理方法,例如,采用敏捷或其他迭代做法,为开展需求管理而采用商业分析技术,为分析项目复杂性而采用相关工具,以及为在组织中应用项目成果而采用组织变革管理方法。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理可能需要裁剪项目整合管理过程。裁剪时应考虑的因素包括(但不限于):

  • 项目生命周期。什么是合适的项目生命周期?项目生命周期应包括哪些阶段?
  • 开发生命周期。对特定产品、服务或成果而言,什么是合适的开发生命周期和开发方法?预测型或适应型方法是否适当?如果是适应型,开发产品是该采用增量还是迭代的方式?混合型方法是否为最佳选择?
  • 管理方法。考虑到组织文化和项目的复杂性,哪种管理过程最有效?
  • 知识管理。在项目中如何管理知识以营造合作的工作氛围?
  • 变更。在项目中如何管理变更?
  • 治理。有哪些监控机构、委员会和其他相关方该参与项目治理?对项目状态报告的要求是什么?
  • 经验教训。在项目期间及项目结束时,应收集哪些信息?历史信息和经验教训是否适用于未来的项目?
  • 效益。应该在何时以何方式报告效益:在项目结束时还是在每次迭代或阶段结束时?

在敏捷或适应型环境中需要考虑的因素迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。

在适应型环境下,《整合管理的核心概念》中所述的对项目经理的期望保持不变,但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围,并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域,那么这种合作型方法就会更加有效。

制定项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。本过程的主要作用是,明确项目与组织战略目标之间的直接联系,确立项目的正式地位,并展示组织对项目的承诺。本过程仅开展一次或仅在项目的预定义点开展。图 4-2 描述本过程的输入、工具与技术和输出。图 4-3 是本过程的数据流向图。

图 4-2制定项目章程:输入、工具与技术和输出

图 4-3制定项目章程:数据流向图

项目章程在项目执行组织与需求组织之间建立起伙伴关系。在执行外部项目时,通常需要用正式的合同来达成合作协议。这种情况下,可能仍要用项目章程来建立组织内部的合作关系,以确保正确交付合同内容。项目章程一旦被批准,就标志着项目的正式启动。在项目中,应尽早确认并任命项目经理,最好在制定项目章程时就任命,且总应在规划开始之前任命。项目章程可由发起人编制,或者由项目经理与发起机构合作编制。通过这种合作,项目经理可以更好地了解项目目的、目标和预期效益,以便更有效地向项目活动分配资源。项目章程授权项目经理规划、执行和控制项目。

项目由项目以外的机构来启动,如发起人、项目集或项目管理办公室(PMO)、项目组合治理委员会主席或其授权代表。项目启动者或发起人应该具有一定的职权,能为项目获取资金并提供资源。

项目可能因内部经营需要或外部影响而启动,故通常需要编制需求分析、可行性研究、商业论证或有待项目处理的情况的描述。通过编制项目章程,来确认项目符合组织战略和日常运营的需要。

不要把项目章程看作合同,因为其中未承诺报酬或金钱或用于交换的对价。

专家判断是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的,关于当前活动的合理判断,这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。

本过程应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:

  • 组织战略;
  • 效益管理;
  • 关于项目所在的行业以及项目关注的领域的技术知识;
  • 持续时间和预算的估算;
  • 风险识别。

项目章程是由项目启动者或发起人发布的,正式批准项目成立,并授权项目经理使用组织资源开展项目活动的文件。它记录了关于项目和项目预期交付的产品、服务或成果的高层级信息,例如:

  • 项目目的;
  • 可测量的项目目标和相关的成功标准;
  • 高层级需求;
  • 高层级项目描述、边界定义以及主要可交付成果;
  • 整体项目风险;
  • 总体里程碑进度计划;
  • 预先批准的财务资源;
  • 关键相关方名单;
  • 项目审批要求(例如,用什么标准评价项目成功,由谁对项目成功下结论,由谁来签署项目结束);
  • 项目退出标准(例如,在何种条件下才能关闭或取消项目或阶段);
  • 委派的项目经理及其职责和职权;
  • 发起人或其他批准项目章程的人员的姓名和职权。

项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。

在商业论证(见 1.2.6.1 节)和效益管理计划(见 1.2.6.2 节)中,可以找到关于项目目标以及项目对业务目标的贡献的相关信息。虽然商业文件是在项目之前制定的,但需要定期审核。

  • 商业论证。经批准的商业论证或类似文件是最常用于制定项目章程的商业文件。商业论证从商业视角描述必要的信息,并且据此决定项目的期望结果是否值得所需投资。高于项目级别的经理和高管们通常使用该文件作为决策的依据。一般情况下,商业论证会包含商业需求和成本效益分析,以论证项目的合理性并确定项目边界。关于商业论证的更多信息,请见 1.2.6.1 节。

商业论证的编制可由以下一个或多个因素引发:

  • 市场需求(例如,为应对汽油紧缺,某汽车制造商批准一个低油耗车型的研发项目);
  • 组织需要(例如,因为管理费用太高,公司决定合并一些职能并优化流程以降低成本);
  • 客户要求(例如,为了给新工业园区供电,某电力公司批准一个新变电站建设项目);
  • 技术进步(例如,基于技术进步,某航空公司批准了一个新项目,来开发电子机票以取代纸质机票);
  • 法律要求(例如,某油漆制品厂批准一个项目,来编写有毒物质处理指南);
  • 生态影响(例如,某公司批准一个项目,来降低对环境的影响);
  • 社会需要(例如,为应对霍乱频发,某发展中国家的非政府组织批准一个项目,为社区建设饮用水系统和公共厕所,并开展卫生教育)。

项目章程包含来源于商业文件中的相关项目信息。既然商业文件不是项目文件,项目经理就不可以对它们进行更新或修改,只可以提出相关建议。

能够影响制定项目章程过程的事业环境因素包括(但不限于):

  • 政府或行业标准(如产品标准、质量标准、安全标准和工艺标准);
  • 法律法规要求和(或)制约因素;
  • 市场条件;
  • 组织文化和政治氛围;
  • 组织治理框架(通过安排人员、制定政策和确定过程,以结构化的方式实施控制、指导和协调,以实现组织的战略和运营目标);
  • 相关方的期望和风险临界值。

能够影响制定项目章程过程的组织过程资产包括(但不限于):

  • 组织的标准政策、流程和程序;
  • 项目组合、项目集和项目的治理框架(用于提供指导和制定决策的治理职能和过程);
  • 监督和报告方法;
  • 模板(如项目章程模板);
  • 历史信息与经验教训知识库(如项目记录与文件、关于以往项目选择决策的结果及以往项目绩效的信息)。

能够影响制定项目管理计划过程的事业环境因素包括(但不限于):

  • 政府或行业标准(如产品标准、质量标准、安全标准和工艺标准);
  • 法律法规要求和(或)制约因素;
  • 垂直市场(如建筑)和(或)专门领域(如环境、安全、风险或敏捷软件开发)的项目管理知识体系;
  • 组织的结构、文化、管理实践和可持续性;
  • 组织治理框架(通过安排人员、制定政策和确定过程,以结构化的方式实施控制、指导和协调,以实现组织的战略和运营目标);
  • 基础设施(如现有的设施和固定资产)。

能够影响制定项目管理计划过程的组织过程资产包括(但不限于):

  • 组织的标准政策、流程和程序;
  • 项目管理计划模板,包括:
  • 根据项目的特定要求而裁剪组织的标准流程的指南和标准;
  • 项目收尾指南或要求,如产品确认及验收标准。
  • 变更控制程序,包括修改正式的组织标准、政策、计划、程序或项目文件,以及批准和确认变更所须遵循的步骤;
  • 监督和报告方法、风险控制程序,以及沟通要求;
  • 以往类似项目的相关信息(如范围、成本、进度与绩效测量基准、项目日历、项目进度网络图和风险登记册);
  • 历史信息和经验教训知识库。

可用于本过程的数据收集技术包括(但不限于):

  • 头脑风暴。见 4.1.2.2 节。制定项目管理计划时,经常以头脑风暴的形式来收集关于项目方法的创意和解决方案。参会者包括项目团队成员,其他主题专家 (SME) 或相关方也可以参与。
  • 核对单。见 11.2.2.2 节。很多组织基于自身经验制定了标准化的核对单,或者采用所在行业的核对单。核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
  • 焦点小组。见 5.2.2.2 节。焦点小组召集相关方讨论项目管理方法以及项目管理计划各个组成部分的整合方式。
  • 访谈。见 5.2.2.2 节。访谈用于从相关方获取特定信息,用以制定项目管理计划、任何子计划或项目文件。

项目管理计划是说明项目执行、监控和收尾方式的一份文件,它整合并综合了所有子管理计划和基准,以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件,取决于具体项目的需求。

项目管理计划组件包括(但不限于):

  • 子管理计划:
  • 范围管理计划。见 5.1.3.1 节。确立如何定义、制定、监督、控制和确认项目范围。
  • 需求管理计划。见 5.1.3.2 节。确定如何分析、记录和管理需求。
  • 进度管理计划。见 6.1.3.1 节。为编制、监督和控制项目进度建立准则并确定活动。
  • 成本管理计划。见 7.1.3.1 节。确定如何规划、安排和控制成本。
  • 质量管理计划。见 8.1.3.1 节。确定在项目中如何实施组织的质量政策、方法和标准。
  • 资源管理计划。见 9.1.3.1 节。指导如何对项目资源进行分类、分配、管理和释放。
  • 沟通管理计划。见 10.1.3.1 节。确定项目信息将如何、何时、由谁来进行管理和传播。
  • 风险管理计划。见 11.1.3.1 节。确定如何安排与实施风险管理活动。
  • 采购管理计划。见 12.1.3.1 节。确定项目团队将如何从执行组织外部获取货物和服务。
  • 相关方参与计划。见 13.2.3.1 节。确定如何根据相关方的需求、利益和影响让他们参与项目决策和执行。
  • 基准:
  • 范围基准。见 5.4.3.1 节。经过批准的范围说明书、工作分解结构 (WBS) 和相应的 WBS 词典,用作比较依据。
  • 进度基准。见 6.5.3.1 节。经过批准的进度模型,用作与实际结果进行比较的依据。
  • 成本基准。见 7.3.3.1 节。经过批准的、按时间段分配的项目预算,用作与实际结果进行比较的依据。
  • 其他组件。大多数项目管理计划组件都来自于其他过程,虽然有些组件是在本过程生成的。

虽然在本过程生成的组件会因项目而异,但是通常包括(但不限于):

  • 变更管理计划。描述在整个项目期间如何正式审批和采纳变更请求。
  • 配置管理计划。描述如何记录和更新项目的特定信息,以及该记录和更新哪些信息,以保持产品、服务或成果的一致性和(或)有效性。
  • 绩效测量基准。经过整合的项目范围、进度和成本计划,用作项目执行的比较依据,以测量和管理项目绩效。
  • 项目生命周期。描述项目从开始到结束所经历的一系列阶段。
  • 开发方法。描述产品、服务或成果的开发方法,例如预测、迭代、敏捷或混合型模式。
  • 管理审查。确定项目经理和有关相关方审查项目进展的时间点,以考核绩效是否符合预期,或者确定是否有必要采取预防或纠正措施。

项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划,但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。

表 4-1项目管理计划和项目文件

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。本过程的主要作用是,对项目工作和可交付成果开展综合管理,以提高项目成功的可能性。本过程需要在整个项目期间开展。图 4-6 描述本过程的输入、工具与技术和输出。图 4-7 是本过程的数据流向图。

图 4-6指导与管理项目工作:输入、工具与技术和输出

图 4-7指导与管理项目工作:数据流向图

指导与管理项目工作包括执行计划的项目活动,以完成项目可交付成果并达成既定目标。本过程需要分配可用资源并管理其有效使用,也需要执行因分析工作绩效数据和信息而提出的项目计划变更。指导与管理项目工作过程会受项目所在应用领域的直接影响,按项目管理计划中的规定,开展相关过程,完成项目工作,并产出可交付成果。

项目经理与项目管理团队一起指导实施已计划好的项目活动,并管理项目内的各种技术接口和组织接口。指导与管理项目工作还要求回顾所有项目变更的影响,并实施已批准的变更,包括纠正措施、预防措施和(或)缺陷补救。

在项目执行过程中,收集工作绩效数据并传达给合适的控制过程做进一步分析。通过分析工作绩效数据,得到关于可交付成果的完成情况以及与项目绩效相关的其他细节,工作绩效数据也用作监控过程组的输入,并可作为反馈输入到经验教训库,以改善未来工作包的绩效。

能够影响指导与管理项目工作过程的事业环境因素包括(但不限于):

  • 组织的结构、文化、管理实践和可持续性;
  • 基础设施(如现有的设施和固定资产);
  • 相关方的风险临界值(如允许的成本超支百分比)。

能够影响指导与管理项目工作过程的组织过程资产包括(但不限于):

  • 组织的标准政策、流程和程序;
  • 问题与缺陷管理程序,用于定义问题与缺陷控制、问题与缺陷识别及其解决,以及行动事项跟踪;
  • 问题与缺陷管理数据库,包括历史问题与缺陷状态、问题和缺陷解决情况,以及行动事项的结果;
  • 绩效测量数据库,用来收集与提供过程和产品的测量数据;
  • 变更控制和风险控制程序;
  • 以往项目的项目信息(如范围、成本、进度与绩效测量基准,项目日历,项目进度网络图,风险登记册,风险报告以及经验教训知识库)。

见 4.1.2.1 节。应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:

  • 关于项目所在的行业以及项目关注的领域的技术知识;
  • 成本和预算管理;
  • 法规与采购;
  • 法律法规;
  • 组织治理。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中通过变更请求加以更新。

管理项目知识是使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。本过程的主要作用是,利用已有的组织知识来创造或改进项目成果,并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。图 4-8 描述本过程的输入、工具以及技术和输出。图 4-9 是本过程的数据流向图。

图 4-8管理项目知识:输入、工具与技术和输出

图 4-9管理项目知识:数据流向图

知识通常分为“显性知识”(易使用文字、图片和数字进行编撰的知识)和“隐性知识”(个体知识以及难以明确表达的知识,如信念、洞察力、经验和“诀窍”)两种。知识管理指管理显性和隐性知识,旨在重复使用现有知识并生成新知识。有助于达成这两个目的的关键活动是知识分享和知识集成(不同领域的知识、情境知识和项目管理知识)。

一个常见误解是,知识管理只是将知识记录下来用于分享;另一种常见误解是,知识管理只是在项目结束时总结经验教训,以供未来项目使用。这样的话,只有经编撰的显性知识可以得到分享。

因为显性知识缺乏情境,可作不同解读,所以,虽易分享,但无法确保正确理解或应用。隐性知识虽蕴含情境,却很难编撰。它存在于专家个人的思想中,或者存在于社会团体和情境中,通常经由人际交流和互动来分享。

从组织的角度来看,知识管理指的是确保项目团队和其他相关方的技能、经验和专业知识在项目开始之前、开展期间和结束之后得到运用。因为知识存在于人们的思想中,且无法强迫人们分享自己的知识或关注他人的知识,所以,知识管理最重要的环节就是营造一种相互信任的氛围,激励人们分享知识或关注他人的知识。如果不激励人们分享知识或关注他人的知识,即便最好的知识管理工具和技术也无法发挥作用。在实践中,联合使用知识管理工具和技术(用于人际互动)以及信息管理工具和技术(用于编撰显性知识)来分享知识。

能够影响管理项目知识过程的事业环境因素包括(但不限于):

  • 组织文化、相关方文化和客户文化。相互信任的工作关系和互不指责的文化对知识管理尤其重要。其他因素则包括赋予学习的价值和社会行为规范。
  • 设施和资源的地理分布。团队成员所在的位置有助于确定收集和分享知识的方法。
  • 组织中的知识专家。有些组织拥有专门从事知识管理的团队或员工。
  • 法律法规要求和(或)制约因素。包括对项目信息的保密性要求。

在项目管理过程和例行工作中,经常必然要使用项目管理知识,能够影响管理项目知识过程的组织过程资产包括(但不限于):

  • 组织的标准政策、流程和程序。可能包括:信息的保密性和获取渠道、安全与数据保护、记录保留政策、版权信息的使用、机密信息的销毁、文件格式和最大篇幅、注册数据和元数据、授权使用的技术和社交媒体等。
  • 人事管理制度。包括员工发展与培训记录以及关于知识分享行为的能力框架。
  • 组织对沟通的要求。正式且严格的沟通要求有利于信息分享。对于生成新知识和整合不同相关方群体的知识,非正式沟通更加有效。
  • 正式的知识分享和信息分享程序。包括项目和项目阶段开始之前、开展期间和结束之后的学习回顾,例如识别、吸取和分享从当前项目和其他项目获得的经验教训。

见 4.1.2.1 节。应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:

  • 知识管理;
  • 信息管理;
  • 组织学习;
  • 知识和信息管理工具;
  • 来自其他项目的相关信息。

可用于本过程的人际关系与团队技能包括(但不限于):

  • 积极倾听。见 10.2.2.6 节。积极倾听有助于减少误解并促进沟通和知识分享。
  • 引导。见 4.1.2.3 节。引导有助于有效指引团队成功地达成决定、解决方案或结论。
  • 领导力。见 3.4.4 节。领导力可帮助沟通愿景并鼓舞项目团队关注合适的知识和知识目标。
  • 人际交往。见 10.2.2.6 节。人际交往促使项目相关方之间建立非正式的联系和关系,为显性和隐性知识的分享创造条件。
  • 政治意识。见 10.1.2.6 节。政治意识有助于项目经理根据项目环境和组织的政治环境规划沟通。

经验教训登记册可以包含情况的类别和描述,经验教训登记册还可包括与情况相关的影响、建议和行动方案。经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会,或其他适用的内容。

经验教训登记册在项目早期创建,作为本过程的输出。因此,在整个项目期间,它可以作为很多过程的输入,也可以作为输出而不断更新。参与工作的个人和团队也参与记录经验教训。可以通过视频、图片、音频或其他合适的方式记录知识,确保有效吸取经验教训。

在项目或阶段结束时,把相关信息归入经验教训知识库,成为组织过程资产的一部分。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中更新。

所有项目都会生成新知识。有些知识应该被编撰,并在管理项目知识过程中被嵌入可交付成果,或者被用于改进过程和程序。在本过程中,也可以首次编撰或使用现有知识,例如,关于新程序的现有想法在本项目中试用并获得成功。

可在本过程更新任一组织过程资产。

见 12.2.3.2 节。采购协议中包括条款和条件,也可包括其他条目,如买方就卖方应实施的工作或应交付的产品所做的规定。如果项目将部分工作外包出去,项目经理需要监督承包商的工作,确保所有协议都符合项目的特定要求,以及组织的采购政策。

能够影响监控项目工作过程的事业环境因素包括(但不限于):

  • 项目管理信息系统,例如进度、成本、资源工具、绩效指标、数据库、项目记录和财务数据;
  • 基础设施(如现有设施、设备、组织通讯渠道);
  • 相关方的期望和风险临界值;
  • 政府或行业标准(如监管机构条例、产品标准、质量标准和工艺标准);

能够影响监控项目工作过程的组织过程资产包括(但不限于):

  • 组织的标准政策、流程和程序;
  • 财务控制程序(如必需的费用与支付审查、会计编码及标准合同条款等);
  • 监督和报告方法;
  • 问题管理程序,用于定义问题控制、问题识别及其解决,以及行动事项跟踪;
  • 缺陷管理程序,用于定义缺陷控制、缺陷识别及其解决,以及行动事项跟踪;
  • 组织知识库,尤其是过程测量和经验教训知识库。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。在监控项目工作过程中提出的变更可能会影响整体项目管理计划。

实施整体变更控制是审查所有变更请求、批准变更,管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 4-12 描述本过程的输入、工具与技术和输出。图 4-13 是本过程的数据流向图。

图 4-12实施整体变更控制:输入、工具与技术和输出

图 4-13实施整体变更控制:数据流向图

实施整体变更控制过程贯穿项目始终,项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间,参与项目的任何相关方都可以提出变更请求。变更控制的实施程度,取决于项目所在应用领域、项目复杂程度、合同要求,以及项目所处的背景与环境。

在基准确定之前,变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准,就必须通过本过程来处理变更请求。依照常规,每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。对配置要素的任何变更都应该提出变更请求,并经过正式控制。

尽管也可以口头提出,但所有变更请求都必须以书面形式记录,并纳入变更管理和(或)配置管理系统中。在批准变更之前,可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下,都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决,这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人,必要时,应该由变更控制委员会(CCB)来开展实施整体变更控制过程。CCB 是一个正式组成的团体,负责审查、评价、批准、推迟或否决项目变更,以及记录和传达变更处理决定。

变更请求得到批准后,可能需要新编(或修订)成本估算、活动排序、进度日期、资源需求和(或)风险应对方案分析,这些变更可能要求调整项目管理计划和其他项目文件。某些特定的变更请求,在 CCB 批准之后,可能还需要得到客户或发起人的批准,除非他们本身就是 CCB 的成员。

能够影响实施整体变更控制过程的事业环境因素包括(但不限于):

  • 法律限制,例如国家或地区法规;
  • 政府或行业标准(如产品标准、质量标准、安全标准和工艺标准);
  • 法律法规要求和(或)制约因素;
  • 组织治理框架(通过安排人员、制定政策和确定过程,以结构化的方式实施控制、指导和协调,以实现组织的战略和运营目标);
  • 合同和采购制约因素。

能够影响实施整体变更控制过程的组织过程资产包括(但不限于):

  • 变更控制程序,包括修改组织标准、政策、计划和程序(或任一项目文件)所须遵循的步骤,以及如何批准和确认变更;
  • 批准与签发变更的程序;
  • 配置管理知识库,包括组织标准、政策、程序和项目文件的各种版本及基准。

为了便于开展配置和变更管理,可以使用一些手动或自动化的工具。配置控制重点关注可交付成果及各个过程的技术规范,而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。

工具的选择应基于项目相关方的需要,包括考虑组织和环境情况和(或)制约因素。工具应支持以下配置管理活动:

  • 识别配置项。识别与选择配置项,从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
  • 记录并报告配置项状态。关于各个配置项的信息记录和报告。
  • 进行配置项核实与审计。通过配置核实与审计,确保项目的配置项组成的正确性,以及相应的变更都被登记、评估、批准、跟踪和正确实施,从而确保配置文件所规定的功能要求都已实现。

工具还应支持以下变更管理活动:

  • 识别变更。识别并选择过程或项目文件的变更项。
  • 记录变更。将变更记录为合适的变更请求。
  • 做出变更决定。审查变更,批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
  • 跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。

也可以使用工具来管理变更请求和后续的决策,同时还要格外关注沟通,以帮助变更控制委员会的成员履行职责,以及向相关方传达决定。

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是,存档项目或阶段信息,完成计划的工作,释放组织团队资源以展开新的工作。它仅开展一次或仅在项目的预定义点开展。图 4-14 描述本过程的输入、工具与技术和输出。图 4-15 是本过程的数据流向图。

图 4-14结束项目或阶段:输入、工具与技术和输出

图 4-15结束项目或阶段:数据流向图

• Projectcharter在结束项目时,项目经理需要回顾项目管理计划,确保所有项目工作都已完成以及项目目标均已实现。项目或阶段行政收尾所需的必要活动包括(但不限于):

  • 为达到阶段或项目的完工或退出标准所必须的行动和活动,例如:
  • 确保所有文件和可交付成果都已是最新版本,且所有问题都已得到解决;
  • 确认可交付成果已交付给客户并已获得客户的正式验收;
  • 确保所有成本都已记入项目成本账;
  • 关闭项目账户;
  • 重新分配人员;
  • 处理多余的项目材料;
  • 重新分配项目设施、设备和其他资源;
  • 根据组织政策编制详尽的最终项目报告。
  • 为关闭项目合同协议或项目阶段合同协议所必须开展的活动,例如nn确认卖方的工作已通过正式验收;
  • 最终处置未决索赔;
  • 更新记录以反映最后的结果;
  • 存档相关信息供未来使用。
  • 为完成下列工作所必须开展的活动:
  • 收集项目或阶段记录;
  • 审计项目成败;
  • 管理知识分享和传递;
  • 总结经验教训;
  • 存档项目信息以供组织未来使用。
  • 为向下一个阶段,或者向生产和(或)运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
  • 收集关于改进或更新组织政策和程序的建议,并将它们发送给相应的组织部门。
  • 测量相关方的满意程度。

如果项目在完工前就提前终止,结束项目或阶段过程还需要制定程序,来调查和记录提前终止的原因。为了实现上述目的,项目经理应该引导所有合适的相关方参与本过程。

能够影响结束项目或阶段过程的组织过程资产包括(但不限于):

  • 项目或阶段收尾指南或要求(如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资源重新分配、团队绩效评估,以及知识传递);
  • 配置管理知识库,包括组织标准、政策、程序和项目文件的各种版本及基准。

可用于项目收尾的数据分析技术包括(但不限于):

  • 文件分析。见 5.2.2.3 节。评估现有文件有助于总结经验教训和分享知识,以改进未来项目和组织资产。
  • 回归分析。该技术分析作用于项目结果的不同项目变量之间的相互关系,以提高未来项目的绩效。
  • 趋势分析。见 4.5.2.2 节。趋势分析可用于确认组织所用模式的有效性,并且为了未来项目而进行相应的模式调整。
  • 偏差分析。见 4.5.2.2 节。偏差分析可通过比较计划目标与最终结果来改进组织的测量指标。

项目交付的产品、服务或成果可转交给另一团队或组织,并由其在整个生命周期中进行运营、维护和支持。

本输出所指的正是把项目交付的最终产品、服务或成果(对于阶段收尾,则是所在阶段的中间产品、服务或成果)从一个团队转交到另一个团队。

需要更新的组织过程资产包括(但不限于):

  • 项目文件。在项目活动中产生的各种文件,例如项目管理计划,范围文件、成本文件、进度文件和项目日历,以及变更管理文件。
  • 运营和支持文件。组织维护、运营和支持项目交付的产品或服务时所需的文件。可包括新生成的文件,或对已有文件的更新。
  • 项目或阶段收尾文件。项目或阶段收尾文件包括表明项目或阶段完工的正式文件,以及用来将完成的项目或阶段可交付成果移交给他人(如运营部门或下一阶段)的正式文件。在项目收尾期间,项目经理应该回顾以往的阶段文件,确认范围过程(见 5.5 节)所产生的客户验收文件,以及合同协议(如果有的话),以确保在达到全部项目要求之后才正式关闭项目。

如果项目在完工前提前终止,则需要在正式的收尾文件中说明项目终止的原因,并规定正式程序,把该项目的已完成和未完成的可交付成果移交他人。

  • 经验教训知识库。将在整个项目期间获得的经验教训和知识归入经验教训知识库,供未来项目使用。

项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。

项目范围管理过程包括:

5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。

5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。

5.3 定义范围 — 制定项目和产品详细描述的过程。

5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。

5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。

5.6 控制范围 — 监督项目和产品的范围状态,管理范围基准变更的过程。

图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出

现,但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。

图 5-1项目范围管理概述

项目范围管理的核心概念在项目环境中,“范围”这一术语有两种含义:

  • 产品范围。某项产品、服务或成果所具有的特征和功能。
  • 项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。

从预测型方法到适应型或敏捷型方法,项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。

采用适应型生命周期,旨在应对大量变更,需要相关方持续参与项目;因此,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完项)。在一个迭代开始时,团队将努力确定产品未完项中,哪些最优先项应在下一次迭代中交付。在每次迭代中,都会重复开展三个过程:收集需求、定义范围和创建 WBS。相反,在预测型项目中,这些过程在项目开始时开展,并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,随同可交付成果的创建提供反馈意见,并确保产品未完项反映他们的当前需求。在每次迭代中,都会重复开展两个过程:确认范围和控制范围。相反,在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围则是一个持续性的过程。

在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序,才能进行基准变更。在开展确认范围、控制范围及其他控制过程时,基准被用作比较的基础。而采用适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。

项目范围的完成情况是根据项目管理计划来衡量的,而产品范围的完成情况是根据产品需求来衡量的。在这里,“需求”是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。

确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入,而验收的可交付成果是确认范围过程的输出之一,由获得授权的相关方正式签字批准。因此,相关方需要在规划阶段早期介入(有时需要在启动阶段就介入),对可交付成果的质量提出意见,以便控制质量过程能够据此评估绩效并提出必要的变更建议。

目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点,并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂,组织开始认识到如何运用商业分析,通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理:实践指南》[14],需求管理过程始于需要评估,而需要评估又可能始于项目组合规划、项目集规划或单个项目。

在项目范围管理过程中,收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括(但不限于)注重与商业分析专业人士的合作,以便:

  • 确定问题并识别商业需要;
  • 识别并推荐能够满足这些需要的可行解决方案;
  • 收集、记录并管理相关方需求,以满足商业和项目目标;
  • 推动项目集或项目的产品、服务或最终成果的成功应用 [7]。

需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期测量、监控、实现和维持效益。

应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师,那么,与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责,项目成功的可能性就更大。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括(但不限于):

  • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了在未来项目中重复使用需求,项目经理应建立哪些指南?
  • 确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南?
  • 开发方法。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
  • 需求的稳定性。项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求,直至需求稳定且定义明确?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下,不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在在整个项目期间被定义和再定义。在敏捷方法中,把需求列入未完项。

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。本过程的主要作用是,在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 5-2 描述本过程的输入、工具与技术和输出。图 5-3 是本过程的数据流向图。

图 5-2规划范围管理:输入、工具与技术和输出

图 5-3规划范围管理:数据流向图

范围管理计划是项目或项目集管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于对下列信息的分析:项目章程(见 4.1.3.1 节)中的信息、项目管理计划(见 4.2.3.1 节)中已批准的子计划、组织过程资产(见 2.3 节)中的历史信息和相关事业环境因素(见 2.2 节)。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 质量管理计划。见 8.1.3.1 节。在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
  • 项目生命周期描述。项目生命周期定义了项目从开始到完成所经历的一系列阶段。
  • 开发方法。开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。

能够影响规划范围管理过程的事业环境因素包括(但不限于):

  • 组织文化;
  • 基础设施;
  • 人事管理制度;
  • 市场条件。

能够影响规划范围管理过程的组织过程资产包括(但不限于):

  • 政策和程序;
  • 历史信息和经验教训知识库。

需求管理计划是项目管理计划的组成部分,描述将如何分析、记录和管理项目和产品需求。根据《从业者商业分析:实践指南》[7],有些组织称之为“商业分析计划”。需求管理计划的主要内容包括(但不限于):

  • 如何规划、跟踪和报告各种需求活动;
  • 配置管理活动,例如,如何启动变更,如何分析其影响,如何进行追溯、跟踪和报告,以及变更审批权限;
  • 需求优先级排序过程;
  • 测量指标及使用这些指标的理由;
  • 反映哪些需求属性将被列入跟踪矩阵的跟踪结构。

会影响收集需求过程的事业环境因素包括(但不限于):

  • 组织文化;
  • 基础设施;
  • 人事管理制度;
  • 市场条件。

会影响收集需求过程的组织过程资产包括(但不限于):

  • 政策和程序;
  • 包含以往项目信息的历史信息和经验教训知识库。

可用于本过程的数据收集技术包括(但不限于):

  • 头脑风暴。见 4.1.2.2 节。头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。
  • 访谈。访谈是通过与相关方直接交谈,来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题,并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话,但也可以包括多个访谈者和/或多个被访者。访谈有经验的项目参与者、发起人和其他高管,以及主题专家,有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。
  • 焦点小组。焦点小组是召集预定的相关方和主题专家,了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
  • 问卷调查。问卷调查是指设计一系列书面问题,向众多受访者快速收集信息。问卷调查方法非常适用于以下情况:受众多样化,需要快速完成调查,受访者地理位置分散,并且适合开展统计分析。
  • 标杆对照见 。 8.1.2.2 节。标杆对照将实际或计划的产品、过程和实践,与其他可比组织的实践进行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的,也可以是外部的。

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。需求文件的格式多种多样,既可以是一份按相关方和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。

许多组织把需求分为不同的种类,如业务解决方案和技术解决方案。前者是相关方的需要,后者是指如何实现这些需要。把需求分成不同的类别,有利于对需求进行进一步完善和细化。需求的类别包括:

  • 业务需求。整个组织的高层级需要,例如,解决业务问题或抓住业务机会,以及实施项目的原因。
  • 相关方需求。相关方或相关方群体的需要。
  • 解决方案需求。为满足业务需求和相关方需求,产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求:
  • 功能需求。功能需求描述产品应具备的功能,例如,产品应该执行的行动、流程、数据和交互。
  • 非功能需求。非功能需求是对功能需求的补充,是产品正常运行所需的环境条件或质量要求,例如,可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
  • 过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力,如数据转换和培训需求。
  • 项目需求。项目需要满足的行动、过程或其他条件,例如里程碑日期、合同责任、制约因素等。
  • 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准,例如测试、认证、确认等。

会影响定义范围过程的事业环境因素包括(但不限于):

  • 组织文化;
  • 基础设施;
  • 人事管理制度;
  • 市场条件。

能够影响定义范围过程的组织过程资产包括(但不限于):

  • 用于制定项目范围说明书的政策、程序和模板;
  • 以往项目的项目档案;
  • 以往阶段或项目的经验教训。

创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是,为所要交付的内容提供架构,它仅开展一次或仅在项目的预定义点开展。图 5-10 描述本过程的输入、工具与技术和输出。图 5-11 是本过程的数据流向图。

图 5-10创建 WBS:输入、工具与技术和输出

图 5-11创建 WBS:数据流向图

WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。

WBS 组织并定义了项目的总范围,代表着经批准的当前项目范围说明书中所规定的工作。

WBS 最低层的组成部分称为工作包,其中包括计划的工作。工作包对相关活动进行归类,以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词语中,“工作”是指作为活动结果的工作产品或可交付成果,而不是活动本身。

能够影响创建 WBS 过程的组织过程资产包括(但不限于):

  • 用于创建 WBS 的政策、程序和模板;
  • 以往项目的项目档案;
  • 以往项目的经验教训。

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 WBS 最低层的工作,可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度,以实现对项目的高效管理;工作包的详细程度则因项目规模和复杂程度而异。要把整个项目工作分解为工作包,通常需要开展以下活动:

  • 识别和分析可交付成果及相关工作;
  • 确定 WBS 的结构和编排方法;
  • 自上而下逐层细化分解;
  • 为 WBS 组成部分制定和分配标识编码;
  • 核实可交付成果分解的程度是否恰当。

图 5-12 显示了某工作分解结构的一部分,其中若干分支已经向下分解到工作包层次。

图 5-12分解到工作包的 WBS 示例

创建 WBS 的方法多种多样,常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS模板。自下而上的方法可用于归并较低层次组件。WBS 的结构可以采用多种形式,例如:

  • 以项目生命周期的各阶段作为分解的第二层,把产品和项目可交付成果放在第三层,如图 5-13 所示;
  • 以主要可交付成果作为分解的第二层,如图 5-14 所示;
  • 纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后,作为外包工作的一部分,卖方须制定相应的合同 WBS。

图 5-13 WBS 示例:以阶段作为第二层

图 5-14 WBS 示例:以主要可交付成果作为第二层

对 WBS 较高层组件进行分解,就是要把每个可交付成果或组件分解为最基本的组成部分,即可核实的产品、服务或成果。如果采用敏捷方法,可以将长篇故事分解成用户故事。WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作,来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层,即可到达工作包的层次,而另一些则须分解更多层。工作分解得越细致,对工作的规划、管理和控制就越有力。但是,过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低,同时造成 WBS 各层级的数据汇总困难。

要在未来远期才完成的可交付成果或组件,当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见,才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。

WBS 包含了全部的产品和项目工作,包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总,来确保既没有遗漏的工作,也没有多余的工作。这有时被称为 100% 规则。

关于 WBS 的详细信息,可参考《工作分解结构实践标准》(第 2 版)[15]。该标准列举了一些具体行业的 WBS 模板,可以在裁剪后应用于特定领域的具体项目。

范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典,只有通过正式的变更控制程序才能进行变更,它被用作比较的基础。范围基准是项目管理计划的组成部分,包括:

  • 项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述(见 5.3.3.1 节)。
  • WBS。WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层,代表对项目工作更详细的定义。
  • 工作包。WBS 的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构,构成账户编码。每个工作包都是控制账户的一部分,而控制账户则是一个管理控制点。在该控制点上,把范围、预算和进度加以整合,并与挣值相比较,以测量绩效。控制账户拥有两个或更多工作包,但每个工作包只与一个控制账户关联。
  • 规划包。一个控制账户可以包含一个或多个规划包,其是一种低于控制账户而高于工作包的工作分解结构组件,工作内容已知,但详细的进度活动未知。
  • WBS 词典。WBS 词典是针对 WBS 中的每个组件,详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持,其中大部分信息由其他过程创建,然后在后期添加到词典中。WBS 词典中的内容可能包括(但不限于):
  • 账户编码标识;
  • 工作描述;
  • 假设条件和制约因素;
  • 负责的组织;
  • 进度里程碑;
  • 相关的进度活动;
  • 所需资源;
  • 成本估算;
  • 质量要求;
  • 验收标准;
  • 技术参考文献;
  • 协议信息。

能够影响控制范围过程的组织过程资产包括(但不限于):

  • 现有的、正式和非正式的,与范围控制相关的政策、程序和指南;
  • 可用的监督和报告的方法与模板。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。可以更新范围管理计划,以反映范围管理方式的变更。
  • 范围基准。见 5.4.3.1 节。在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后,需要对范围基准做出相应的变更。有时范围偏差太过严重,以至于需要修订范围基准,以便为绩效测量提供现实可行的依据。
  • 进度基准。见 6.5.3.1 节。在针对范围、资源或进度估算的变更获得批准后,需要对进度基准做出相应的变更。有时进度偏差太过严重,以至于需要修订进度基准,以便为绩效测量提供现实可行的依据。
  • 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后,需要对成本基准做出相应的变更。有时成本偏差太过严重,以至于需要修订成本基准,以便为绩效测量提供现实可行的依据。
  • 绩效测量基准。见 4.2.3.1 节。在针对范围、进度绩效或成本估算的变更获得批准后,需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重,需要提出变更请求来修订绩效测量基准,以便为绩效测量提供现实可行的依据。

项目进度管理包括为管理项目按时完成所需的各个过程。其过程包括:

6.1 规划进度管理 — 为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。

6.2 定义活动 — 识别和记录为完成项目可交付成果而需采取的具体行动的过程。

6.3 排列活动顺序 — 识别和记录项目活动之间的关系的过程。

6.4 估算活动持续时间 — 根据资源估算的结果,估算完成单项活动所需工作时段数的过程。

6.5 制定进度计划 — 分析活动顺序、持续时间、资源需求和进度制约因素,创建项目进度模型,从而落实项目执行和监控的过程。

6.6 控制进度 — 监督项目状态,以更新项目进度和管理进度基准变更的过程。

图 6-1 概括了项目进度管理的各个过程。虽然在本《PMBOK® 指南》中,各项目进度管理过程以界限

分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 6-1项目进度管理概述

项目进度管理的核心概念项目进度计划提供详尽的计划,说明项目如何以及何时交付项目范围中定义的产品、服务和成果,是一种用于沟通和管理相关方期望的工具,为绩效报告提供了依据。

项目管理团队选择进度计划方法,例如关键路径法或敏捷方法。之后,项目管理团队将项目特定数据,如活动、计划日期、持续时间、资源、依赖关系和制约因素等输入进度计划编制工具,以创建项目进度模型。这件工作的成果就是项目进度计划。图 6-2 是进度计划工作的概览,展示如何结合进度计划编制方法、编制工具及项目进度管理各过程的输出来创建进度模型。

在小型项目中,定义活动、排列活动顺序、估算活动持续时间及制定进度模型等过程之间的联系非常密切,以至于可视为一个过程,能够由一个人在较短时间内完成。但本章仍然把这些过程分开介绍,因为每个过程所用的工具和技术各不相同。有关某些过程的更详细的描述,请参见《进度计划实践标准》[2]。

在可能的情况下,应在整个项目期间保持项目详细进度计划的灵活性,使其可以随着知识的获得、对风险理解的加深,以及增值活动的设计而调整。

图 6-2进度规划工作概述

项目进度管理的发展趋势和新兴实践全球市场瞬息万变,竞争激烈,具有很高的不确定性和不可预测性,很难定义长期范围,因此,为应对环境变化,根据具体情景有效采用和裁剪开发实践就日益重要。适应型规划虽然制定了计划,但也意识到工作开始之后,优先级可能发生改变,需要修改计划以反映新的优先级。

有关项目进度计划方法的新兴实践包括(但不限于):

  • 具有未完项的迭代型进度计划。这是一种基于适应型生命周期的滚动式规划,例如敏捷的产品开发方法。这种方法将需求记录在用户故事中,然后在建造之前按优先级排序并优化用户故事,最后在规定的时间盒内开发产品功能。这一方法通常用于向客户交付增量价值,或多个团队并行开发大量内部关联较小的功能。适应型生命周期在产品开发中的应用越来越普遍,很多项目都采用这种进度计划方法。这种方法的好处在于,它允许在整个开发生命周期期间进行变更。
  • 按需进度计划。这种方法通常用于看板体系,基于制约理论和来自精益生产的拉动式进度计划概念,根据团队的交付能力来限制团队正在开展的工作。按需进度计划方法不依赖于以前为产品开发或产品增量制定的进度计划,而是在资源可用时立即从未完项和工作序列中提取出来开展。按需进度计划方法经常用于此类项目:在运营或持续环境中以增量方式研发产品,其任务可以被设计成相对类似的规模和范围,或者可以按规模和范围进行组合的工作。

按需进度计划方法通常用于产品在运营和维护环境下以增量方式演进,且任务的规模或范围相对类似,或者,可以按照规模或范围对任务进行组合的项目。

裁剪考虑因素由于每个项目都是独特的,因此项目经理可能需要裁剪项目进度管理过程。裁剪时应考虑的因素包括(但不限于):

  • 生命周期方法。哪种生命周期方法最适合制定详细的进度计划?
  • 资源可用性。影响资源可持续时间的因素是什么(如可用资源与其生产效率之间的相关性)?
  • 项目维度。项目复杂性、技术不确定性、产品新颖度、速度或进度跟踪(如挣值、完成百分比、“红黄绿”停止信号灯指示)如何影响预期的控制水平?
  • 技术支持。是否采用技术来制定、记录、传递、接收和存储项目进度模型的信息以及是否易于获取?

有关进度计划的更多信息,参阅《进度计划实践标准》[16]。

关于敏捷/适应型环境的考虑因素适应型方法采用短周期来开展工作、审查结果,并在必要时做出调整。这些周期可针对方法和可交付成果的适用性提供快速反馈,通常表现为迭代型进度计划和拉动式按需进度计划,具体参见“项目进度管理的发展趋势和新兴实践”一节。

在大型组织中,可能同时存在小规模项目和大规模举措,需要制定长期路线图,通过规模参数(如团队规模、地理分布、法规合规性、组织复杂性和技术复杂性)来管理这些项目集。为管理大规模的、全企业系统的、完整的交付生命周期,可能需要采用一系列技术,包括预测型方法、适应型方法或两种方法的混合。组织还可能需要结合几种核心方法,或采用已实践过的方法,并采纳来自传统技术的一些原则和实践。

无论是采用预测型开发生命周期来管理项目,还是在适应型环境下管理项目,项目经理的角色都不变。但是,要成功实施适应型方法,项目经理需要了解如何高效使用相关的工具和技术。

能够影响规划进度管理过程的事业环境因素包括(但不限于):

  • 组织文化和结构;
  • 团队资源可用性、技能以及物质资源可用性;
  • 进度计划软件;
  • 指南和标准,用于裁剪组织标准过程和程序以满足项目的特定要求;
  • 商业数据库,如标准化的估算数据。

能够影响规划进度管理过程的组织过程资产包括(但不限于):

  • 历史信息和经验教训知识库;
  • 现有与制定进度计划以及管理和控制进度相关的正式和非正式的政策、程序和指南;
  • 模板和表格;
  • 监督和报告工具。

进度管理计划是项目管理计划的组成部分,为编制、监督和控制项目进度建立准则和明确活动。

根据项目需要,进度管理计划可以是正式或非正式的,非常详细或高度概括的,其中应包括合适的控制临界值。

进度管理计划会规定:

  • 项目进度模型制定。需要规定用于制定项目进度模型的进度规划方法论和工具。
  • 进度计划的发布和迭代长度。使用适应型生命周期时,应指定固定时间的发布时段、阶段和迭代。固定时间段指项目团队稳定地朝着目标前进的持续时间,它可以推动团队先处理基本功能,然后在时间允许的情况下再处理其他功能,从而尽可能减少范围蔓延。
  • 准确度。准确度定义了需要规定活动持续时间估算的可接受区间,以及允许的应急储备数量。
  • 计量单位。需要规定每种资源的计量单位,例如,用于测量时间的人时数、人天数或周数,用于计量数量的米、升、吨、千米或立方码。
  • 组织程序链接。工作分解结构(WBS,见 5.4 节)为进度管理计划提供了框架,保证了与估算及相应进度计划的协调性。
  • 项目进度模型维护。需要规定在项目执行期间,将如何在进度模型中更新项目状态,记录项目进展。
  • 控制临界值。可能需要规定偏差临界值,用于监督进度绩效。它是在需要采取某种措施前,允许出现的最大差异。临界值通常用偏离基准计划中的参数的某个百分数来表示。
  • 绩效测量规则。需要规定用于绩效测量的挣值管理(EVM)规则或其他测量规则。例如,进度管理计划可能规定:
  • 确定完成百分比的规则;
  • EVM 技术,如基准法、固定公式法、完成百分比法等。更多信息,参阅《挣值管理实践标准》[17];
  • 进度绩效测量指标,如进度偏差(SV)和进度绩效指数(SPI),用来评价偏离原始进度基准的程度。
  • 报告格式。需要规定各种进度报告的格式和编制频率。

影响定义活动过程的事业环境因素包括(但不限于):

  • 组织文化和结构;
  • 商业数据库中发布的商业信息;
  • 项目管理信息系统 (PMIS)。

能够影响定义活动过程的组织过程资产包括(但不限于):

  • 经验教训知识库,其中包含以往类似项目的活动清单等历史信息;
  • 标准化的流程;
  • 以往项目中包含标准活动清单或部分活动清单的模板;
  • 现有与活动规划相关的正式和非正式的政策、程序和指南,如进度规划方法论,在编制活动定义时应考虑这些因素。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 进度基准。见 6.5.3.1 节。在整个项目期间,工作包逐渐细化为活动。在这个过程中可能会发现原本不属于项目基准的工作,从而需要修改作为进度基准一部分的交付日期或其他重要的进度里程碑。
  • 成本基准。见 7.3.3.1 节。在针对进度活动的变更获得批准后,需要对成本基准做出相应的变更。

能够影响排列活动顺序过程的事业环境因素包括(但不限于):

  • 政府或行业标准;
  • 项目管理信息系统(PMIS);
  • 进度规划工具;
  • 组织的工作授权系统。

能够影响排列活动顺序过程的组织过程资产包括(但不限于):

  • 项目组合与项目集规划,以及项目之间的依赖关系与关联;
  • 现有与活动规划相关的正式和非正式的政策、程序和指南,如进度计划方法论,在确定逻辑关系时应考虑这些因素;
  • 有助于加快项目活动网络图编制的各种模板;模板中也会包括有助于排列活动顺序的,与活动属性有关的信息;
  • 经验教训知识库,其中包含有助于优化排序过程的历史信息。

见 4.3.2.2 节。项目管理信息系统包括进度计划软件;这些软件有助于规划、组织和调整活动顺序,插入逻辑关系、提前和滞后值,以及区分不同类型的依赖关系。

能够影响估算活动持续时间过程的组织过程资产包括(但不限于):

  • 关于持续时间的历史信息;
  • 项目日历;
  • 估算政策;
  • 进度规划方法论;
  • 经验教训知识库。

能够影响制定进度计划过程的组织过程资产包括(但不限于):

  • 进度计划方法论,其中包括制定和维护进度模型时应遵循的政策;
  • 项目日历。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 进度管理计划。见 6.1.3.1 节。可能需要更新进度管理计划,以反映制定和管理进度计划的方式的变更。
  • 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后,需要对成本基准做出相应的变更。有时成本偏差太过严重,以至于需要修订成本基准,以便为绩效测量提供现实可行的依据。

能够影响控制进度过程的组织过程资产包括(但不限于):

  • 现有与进度控制有关的正式和非正式的政策、程序和指南;
  • 进度控制工具;
  • 可用的监督和报告方法。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 进度管理计划。见 6.1.3.1 节。可能需要更新进度管理计划,以反映进度管理方法的变更。
  • 进度基准。见 6.5.3.1 节。在项目范围、活动资源或活动持续时间估算等方面的变更获得批准后,可能需要对进度基准做相应变更。另外,因进度压缩技术或绩效问题造成变更时,也可能需要更新进度基准。
  • 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后,需要对成本基准做出相应的变更。
  • 绩效测量基准。见 4.2.3.1 节。在范围、进度绩效或成本估算的变更获得批准后,需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重,需要提出变更请求来修订绩效测量基准,以便为绩效测量提供现实可行的依据。

项目成本管理包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程,从而确保项目在批准的预算内完工。项目成本管理过程包括:

7.1 规划成本管理 — 确定如何估算、预算、管理、监督和控制项目成本的过程。

7.2 估算成本 — 对完成项目活动所需货币资源进行近似估算的过程。

7.3 制定预算 — 汇总所有单个活动或工作包的估算成本,建立一个经批准的成本基准的过程。

7.4 控制成本 — 监督项目状态,以更新项目成本和管理成本基准变更的过程。

图 7-1 概括了项目成本管理的各个过程。虽然在本《PMBOK® 指南》中,各项目成本管理过程以界

限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。这些过程不仅彼此相互作用,而且还与其他知识领域中的过程相互作用。

在某些项目,特别是范围较小的项目中,成本估算和成本预算之间的联系非常紧密,以至于可视为一个过程,由一个人在较短时间内完成。但本章仍然把这两个过程分开来介绍,因为它们所用的工具和技术各不相同。对成本的影响力在项目早期最大,因此尽早定义范围就至关重要(见 5.3 节)。

图 7-1项目成本管理概述

项目成本管理的核心概念项目成本管理重点关注完成项目活动所需资源的成本,但同时也应考虑项目决策对项目产品、服务或成果的使用成本、维护成本和支持成本的影响。例如,限制设计审查的次数可降低项目成本,但可能增加由此带来的产品运营成本。

成本管理的另一个方面是认识到不同的相关方会在不同的时间,用不同的方法测算项目成本。

例如,对于某采购品,可在做出采购决策、下达订单、实际交货、实际成本发生或进行项目会计记账时,测算其成本。在很多组织中,预测和分析项目产品的财务效益是在项目之外进行的,但对于有些项目,如固定资产投资项目,可在项目成本管理中进行这项预测和分析工作。在这种情况下,项目成本管理还需使用其他过程和许多通用财务管理技术,如投资回报率分析、现金流贴现分析和投资回收期分析等。

项目成本管理的趋势和新兴实践在项目成本管理的实践中,通过对挣值管理 (EVM)的扩展,引入挣得进度 (ES) 这一概念。

ES 是 EVM 理论和实践的延伸。挣得进度理论用 ES 和实际时间 (AT) 替代了传统 EVM 所使用的进度偏差测量指标(挣值 – 计划价值),使用这种替代方法计算进度偏差 ES - AT,如果挣得进度大于 0,则表示项目进度提前了;换句话说,在某个给定的时间点,项目的挣值大于计划价值。使用挣得进度测量指标的进度绩效指数 (SPI) 为 ES 与 AT 之比,表示完成项目的工作效率。此外,挣得进度理论通过挣得进度、实际时间和估算持续时间,提供了预测项目完成日期的计算公式。

裁剪考虑因素由于每个项目都是独特的,项目经理因此可能需要裁剪项目成本管理过程。裁剪时应考虑的因素包括(但不限于):

  • 知识管理。组织是否拥有易于使用的、正式的知识管理体系和财务数据库,并要求项目经理使用?
  • 估算和预算。组织是否拥有正式或非正式的,与成本估算和预算相关的政策、程序和指南?
  • 挣值管理。组织是否采用挣值管理来管理项目?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?这对成本估算有什么影响?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

关于敏捷/适应型环境的考虑因素对易变性高、范围并未完全明确、经常发生变更的项目,详细的成本计算可能没有多大帮助。

在这种情况下,可以采用轻量级估算方法快速生成对项目人力成本的高层级预测,在出现变更时容易调整预测;而详细的估算适用于采用准时制的短期规划。

如果易变的项目也遵循严格的预算,通常需要更频繁地更改范围和进度计划,以始终保持在成本制约因素之内。

能够影响规划成本管理过程的事业环境因素包括(但不限于):

  • 能够影响成本管理的组织文化和组织结构;
  • 市场条件,决定着在当地及全球市场上可获取哪些产品、服务和成果;
  • 货币汇率,用于换算发生在多个国家的项目成本;
  • 发布的商业信息,经常可以从商业数据库中获取资源成本费率及相关信息,而这些数据库动态跟踪具有相应技能的人力资源的成本数据,也提供材料与设备的标准成本数据;还可以从卖方公布的价格清单中获取相关信息;
  • 项目管理信息系统,可为管理成本提供多种方案;
  • 不同地区的生产率差异,可能会对项目成本造成巨大影响。

能够影响规划成本管理过程的组织过程资产包括(但不限于):

  • 财务控制程序(如定期报告、必需的费用与支付审查、会计编码及标准合同条款等);
  • 历史信息和经验教训知识库;
  • 财务数据库;
  • 现有的正式和非正式的与成本估算和预算有关的政策、程序和指南。

成本管理计划是项目管理计划的组成部分,描述将如何规划、安排和控制项目成本。成本管理过程及其工具与技术应记录在成本管理计划中。

例如,在成本管理计划中规定:

  • 计量单位。需要规定每种资源的计量单位,例如用于测量时间的人时数、人天数或周数,用于计量数量的米、升、吨、千米或立方码,或者用货币表示的总价。
  • 精确度。根据活动范围和项目规模,设定成本估算向上或向下取整的程度(例如 995.59 美元取整为 1,000 美元)。
  • 准确度。为活动成本估算规定一个可接受的区间(如 ±10%),其中可能包括一定数量的应急储备。
  • 组织程序链接。工作分解结构(见 5.4 节)为成本管理计划提供了框架,以便据此规范地开展成本估算、预算和控制。在项目成本核算中使用的 WBS 组成部分,称为控制账户(CA),每个控制账户都有唯一的编码或账号,直接与执行组织的会计制度相联系。
  • 控制临界值。可能需要规定偏差临界值,用于监督成本绩效。它是在需要采取某种措施前,允许出现的最大差异,通常用偏离基准计划的百分数来表示。
  • 绩效测量规则。需要规定用于绩效测量的挣值管理(EVM)规则。例如,成本管理计划应该:
  • 定义 WBS 中用于绩效测量的控制账户;
  • 确定拟用的 EVM 技术(如加权里程碑法、固定公式法、完成百分比法等);
  • 规定跟踪方法,以及用于计算项目完工估算(EAC)的 EVM 公式,该公式计算出的结果可用于验证通过自下而上方法得出的完工估算。
  • 报告格式。需要规定各种成本报告的格式和编制频率。
  • 其他细节。关于成本管理活动的其他细节包括(但不限于):
  • 对战略筹资方案的说明;
  • 处理汇率波动的程序;
  • 记录项目成本的程序。

关于挣值管理的更多信息,参见《挣值管理实践标准》(第 2 版)[17]。

估算成本是对完成项目工作所需资源成本进行近似估算的过程。本过程的主要作用是,确定项目所需的资金。本过程应根据需要在整个项目期间定期开展。图 7-4 描述本过程的输入、工具与技术和输出,图 7-5 是本过程的数据流向图。

图 7-4估算成本:输入、工具与技术和输出

图 7-5估算成本的数据流向图

成本估算是对完成活动所需资源的可能成本的量化评估,是在某特定时点,根据已知信息所做出的成本预测。在估算成本时,需要识别和分析可用于启动与完成项目的备选成本方案;需要权衡备选成本方案并考虑风险,如比较自制成本与外购成本、购买成本与租赁成本及多种资源共享方案,以优化项目成本。

通常用某种货币单位(如美元、欧元、日元等)进行成本估算,但有时也可采用其他计量单位,如人时数或人天数,以消除通货膨胀的影响,便于成本比较。

在项目过程中,应该随着更详细信息的呈现和假设条件的验证,对成本估算进行审查和优化。

在项目生命周期中,项目估算的准确性亦将随着项目的进展而逐步提高。例如,在启动阶段可得出项目的粗略量级估算(Rough Order of Magnitude,ROM),其区间为 −25% 到 +75%;之后,随着信息越来越详细,确定性估算的区间可缩小至 −5% 到 +10%。某些组织已经制定出相应的指南,规定何时进行优化,以及每次优化所要达到的置信度或准确度。

进行成本估算,应该考虑将向项目收费的全部资源,包括(但不限于)人工、材料、设备、服务、设施,以及一些特殊的成本种类,如通货膨胀补贴、融资成本或应急成本。成本估算可在活动层级呈现,也可以汇总形式呈现。

会影响估算成本过程的组织过程资产包括(但不限于):

  • 成本估算政策;
  • 成本估算模板;
  • 历史信息和经验教训知识库。

会影响制定预算过程的组织过程资产包括(但不限于):

  • 现有的正式和非正式的与成本预算有关的政策、程序和指南;
  • 历史信息和经验教训知识库;
  • 成本预算工具;
  • 报告方法。

会影响控制成本过程的组织过程资产包括(但不限于):

  • 现有的正式和非正式的与成本控制相关的政策、程序和指南;
  • 成本控制工具;
  • 可用的监督和报告方法。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 成本管理计划。见 7.1.3.1 节。成本管理计划中需要更新的内容包括:用于管理项目成本的控制临界值或所要求的准确度。要根据相关方的反馈意见,对它们进行更新。
  • 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后,需要对成本基准做出相应的变更。在某些情况下,成本偏差可能太过严重,以至于需要修订成本基准,以便为绩效测量提供现实可行的依据。
  • 绩效测量基准。见 4.2.3.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 或运营的关注点。

按有效性递增排列的五种质量管理水平如下:

  • 通常,代价最大的方法是让客户发现缺陷。这种方法可能会导致担保问题、召回、商誉受损和返工成本。
  • 控制质量过程包括先检测和纠正缺陷,再将可交付成果发送给客户。该过程会带来相关成本,主要是评估成本和内部失败成本。
  • 通过质量保证检查并纠正过程本身,而不仅仅是特殊缺陷。
  • 将质量融入项目和产品的规划和设计中。
  • 在整个组织内创建一种关注并致力于实现过程和产品质量的文化。

项目质量管理的趋势和新兴实践现代质量管理方法力求缩小差异,交付满足既定相关方要求的成果。项目质量管理的趋势可能包括(但不限于):

  • 客户满意。了解、评估、定义和管理要求,以便满足客户的期望。这就需要把“符合要求”(确保项目产出预定的成果)和“适合使用”(产品或服务必须满足实际需求)结合起来。在敏捷环境中,相关方与项目管理团队合作可确保在整个项目期间始终做到客户满意。
  • 持续改进。由休哈特提出并经戴明完善的“计划 — 实施 — 检查 — 行动 (PDCA)”循环是质量改进的基础。另外,诸如全面质量管理(TQM)、六西格玛和精益六西格玛等质量改进举措也可以提高项目管理的质量以及最终产品、服务或成果的质量。
  • 管理层的责任。项目的成功需要项目团队全体成员的参与。管理层在其质量职责内,肩负着为项目提供具有足够能力的资源的相应责任。
  • 与供应商的互利合作关系。组织与其供应商相互依赖。相对传统的供应商管理而言,与供应商建立合作伙伴关系对组织和供应商都更加有益。组织应着眼于长期关系而不是短期利益。互利合作关系增强了组织和供应商互相为对方创造价值的能力,推动他们共同实现客户的需求和期望,并优化成本和资源。

裁剪考虑因素每个项目都是独特的,因此项目经理需要裁剪项目质量管理过程。裁剪时应考虑的因素包括(但不限于):

  • 政策合规与审计。组织有哪些质量政策和程序?组织使用哪些质量工具、技术和模板?
  • 标准与法规合规性。是否存在必须遵守的行业质量标准?需要考虑哪些政府、法律或法规方面的制约因素?
  • 持续改进。如何管理项目中的质量改进?是在组织层面还是在单个项目层面进行管理?
  • 相关方参与。项目环境是否有利于与相关方及供应商合作?

关于敏捷/适应型环境的考虑因素为引导变更,敏捷方法要求多个质量与审核步骤贯穿整个项目,而不是在面临项目结束时才执行。

循环回顾,定期检查质量过程的效果;寻找问题的根本原因,然后建议实施新的质量改进方法;

后续回顾会议评估试验过程,确定是否可行、是否应继续、或做出调整,或者直接弃用。

为促进频繁的増量交付,敏捷方法关注于小批量工作,纳入尽可能多的项目可交付成果的要素。

小批量系统的目的是在项目生命周期早期(整体变更成本较低)发现不一致和质量问题。

能够影响规划质量管理过程的事业环境因素包括(但不限于):

  • 政府法规;
  • 特定应用领域的相关规则、标准和指南;
  • 地理分布;
  • 组织结构。
  • 市场条件;
  • 项目或可交付成果的工作条件或运行条件;
  • 文化观念。

能够影响规划质量管理过程的组织过程资产包括(但不限于):

  • 组织的质量管理体系,包括政策、程序及指南。
  • 质量模板,例如核查表、跟踪矩阵及其它;
  • 历史数据库和经验教训知识库。

适用于本过程的数据收集技术包括(但不限于):

  • 标杆对照。标杆对照是将实际或计划的项目实践或项目的质量标准与可比项目的实践进行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据。作为标杆的项目可以来自执行组织内部或外部,或者来自同一应用领域或其他应用领域。标杆对照也允许用不同应用领域或行业的项目做类比。
  • 头脑风暴。见 4.1.2.2 节。通过头脑风暴可以向团队成员或主题专家收集数据,以制定最适合新项目的质量管理计划。
  • 访谈。见 5.2.2.2 节。访谈有经验的项目参与者、相关方和主题专家有助于了解他们对项目和产品质量的隐性和显性、正式和非正式的需求和期望。应在信任和保密的环境下开展访谈,以获得真实可信、不带偏见的反馈。

适用于本过程的数据表现技术包括(但不限于):

  • 流程图。流程图,也称过程图,用来显示在一个或多个输入转化成一个或多个输出的过程中,所需要的步骤顺序和可能分支。它通过映射水平价值链的过程细节来显示活动、决策点、分支循环、并行路径及整体处理顺序。图 8-6 展示了其中一个版本的价值链,即 SIPOC(供应商、输入、过程、输出和客户)模型。流程图可能有助于了解和估算一个过程的质量成本。通过工作流的逻辑分支及其相对频率来估算质量成本。这些逻辑分支细分为完成符合要求的输出而需要开展的一致性工作和非一致性工作。用于展示过程步骤时,流程图有时又被称为“过程流程图”或“过程流向图”,可帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方。
  • 逻辑数据模型。逻辑数据模型把组织数据可视化,以商业语言加以描述,不依赖任何特定技术。逻辑数据模型可用于识别会出现数据完整性或其他质量问题的地方。
  • 矩阵图。矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。根据可用来比较因素的数量,项目经理可使用不同形状的矩阵图,如 L 型、T 型、Y 型、X 型、C 型和屋顶型矩阵。在本过程中,它们有助于识别对项目成功至关重要的质量测量指标。
  • 思维导图。见 5.2.2.3 节。思维导图是一种用于可视化组织信息的绘图法。质量思维导图通常是基于单个质量概念创建的,是绘制在空白的页面中央的图像,之后再增加以图像、词汇或词条形式表现的想法。思维导图技术可以有助于快速收集项目质量要求、制约因素、依赖关系和联系。

图 8-6 SIPOC 模型

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 风险管理计划。见 11.1.3.1 节。在确定质量管理方法时可能需要更改已商定的项目风险管理方法,这些变更会记录在风险管理计划中。
  • 范围基准。见 5.4.3.1 节。如果需要增加特定的质量管理活动,范围基准可能因本过程而变更。

WBS 词典记录的质量要求可能需要更新。

管理质量是把组织的质量政策用于项目,并将质量管理计划转化为可执行的质量活动的过程。

本过程的主要作用是,提高实现质量目标的可能性,以及识别无效过程和导致质量低劣的原因。

管理质量使用控制质量过程的数据和结果向相关方展示项目的总体质量状态。本过程需要在整个项目期间开展。

图 8-7 描述本过程的输入、工具与技术和输出。图 8-8 是本过程的数据流向图。

图 8-7管理质量:输入、工具与技术和输出

图 8-8管理质量:数据流向图

管理质量有时被称为“质量保证”,但“管理质量”的定义比“质量保证”更广,因其可用于非项目工作。在项目管理中,质量保证着眼于项目使用的过程,旨在高效地执行项目过程,包括遵守和满足标准,向相关方保证最终产品可以满足他们的需求、期望和要求。管理质量包括所有质量保证活动,还与产品设计和过程改进有关。管理质量的工作属于质量成本框架中的一致性工作。

管理质量过程执行在项目质量管理计划中所定义的一系列有计划、有系统的行动和过程,有助于:

  • 通过执行有关产品特定方面的设计准则,设计出最优的成熟产品;
  • 建立信心,相信通过质量保证工具和技术(如质量审计和故障分析)可以使未来输出在完工时满足特定的需求和期望;
  • 确保使用质量过程并确保其使用能够满足项目的质量目标;
  • 提高过程和活动的效率与效果,以获得更好的成果和绩效并提高相关方的满意程度。

项目经理和项目团队可以通过组织的质量保证部门或其他组织职能执行某些管理质量活动,例如故障分析、实验设计和质量改进。质量保证部门在质量工具和技术的使用方面通常拥有跨组织经验,是良好的项目资源。

管理质量被认为是所有人的共同职责,包括项目经理、项目团队、项目发起人、执行组织的管理层,甚至是客户。所有人在管理项目质量方面都扮演一定的角色,尽管这些角色的人数和工作量不同。参与质量管理工作的程度取决于所在行业和项目管理风格。在敏捷项目中,整个项目期间的质量管理由所有团队成员执行;但在传统项目中,质量管理通常是特定团队成员的职责。

可作为本过程输入的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。项目早期与质量管理有关的经验教训,可以运用到项目后期阶段,以提高质量管理的效率与效果。
  • 质量控制测量结果。见 8.3.3.1 节。质量控制测量结果用于分析和评估项目过程和可交付成果的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析这些测量结果的产生过程,以确定实际测量结果的正确程度。
  • 质量测量指标。见 8.1.3.2 节。核实质量测量指标是控制质量过程的一个环节。管理质量过程依据这些质量测量指标设定项目的测试场景和可交付成果,用作改进举措的依据。
  • 风险报告。见 11.2.3.2 节。管理质量过程使用风险报告识别整体项目风险的来源以及整体风险敞口的最重要的驱动因素,这些因素能够影响项目的质量目标。

能够影响管理质量过程的组织过程资产包括(但不限于):

  • 包括政策、程序及指南的组织质量管理体系;
  • 质量模板,例如核查表、跟踪矩阵、测试计划、测试文件及其它模板;
  • 以往审计的结果;
  • 包含类似项目信息的经验教训知识库。

适用于本过程的数据收集技术包括(但不限于)核对单(见 11.2.2.2 节)。核对单是一种结构化工具,通常列出特定组成部分,用来核实所要求的一系列步骤是否已得到执行或检查需求列表是否已得到满足。基于项目需求和实践,核对单可简可繁。许多组织都有标准化的核对单,用来规范地执行经常性任务。在某些应用领域,核对单也可从专业协会或商业性服务机构获取。质量核对单应该涵盖在范围基准中定义的验收标准。

审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展,如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。质量审计目标可能包括(但不限于):

  • 识别全部正在实施的良好及最佳实践;
  • 识别所有违规做法、差距及不足;
  • 分享所在组织和/或行业中类似项目的良好实践;
  • 积极、主动地提供协助,以改进过程的执行,从而帮助团队提高生产效率;
  • 强调每次审计都应对组织经验教训知识库的积累做出贡献。

采取后续措施纠正问题,可以降低质量成本,并提高发起人或客户对项目产品的接受度。质量审计可事先安排,也可随机进行;可由内部或外部审计师进行。

质量审计还可确认已批准的变更请求(包括更新、纠正措施、缺陷补救和预防措施)的实施情况。

可基于行业需求和组织模板创建测试与评估文件。它们是控制质量过程的输入,用于评估质量目标的实现情况。这些文件可能包括专门的核对单和详尽的需求跟踪矩阵。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 质量管理计划。见 8.1.3.1 节。可能需要根据实际结果修改已商定的质量管理方法。
  • 范围基准。见 5.4.3.1 节。范围基准可能因特定的质量管理活动而变更。
  • 进度基准。见 6.5.3.1 节。进度基准可能因特定的质量管理活动而变更。
  • 成本基准。见 7.3.3.1 节。成本基准可能因特定的质量管理活动而变更。

能够影响控制质量过程的组织过程资产包括(但不限于):

  • 质量标准和政策;
  • 质量模板,例如核查表、核对单等;
  • 问题与缺陷报告程序及沟通政策。

适用于本过程的数据收集技术包括(但不限于):

  • 核对单。见 11.2.2.2 节。核对单有助于以结构化方式管理控制质量活动。
  • 核查表。核查表,又称计数表,用于合理排列各种事项,以便有效地收集关于潜在质量问题的有用数据。在开展检查以识别缺陷时,用核查表收集属性数据就特别方便,例如关于缺陷数量或后果的数据。见图 8-12。

图 8-12核查表

  • 统计抽样。统计抽样是指从目标总体中选取部分样本用于检查(如从 75 张工程图纸中随机抽取10 张)。样本用于测量控制和确认质量。抽样的频率和规模应在规划质量管理过程中确定。
  • 问卷调查。问卷调查可用于在部署产品或服务之后收集关于客户满意度的数据。在问卷调查中识别的缺陷相关成本可被视为 COQ 模型中的外部失败成本,给组织带来的影响会超出成本本身。

测试是一种有组织的、结构化的调查,旨在根据项目需求提供有关被测产品或服务质量的客观信息。测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。用于评估各项需求的测试的类型、数量和程度是项目质量计划的一部分,具体取决于项目的性质、时间、预算或其他制约因素。测试可以贯穿于整个项目,可以随着项目的不同组成部分变得可用时进行,也可以在项目结束(即交付最终可交付成果)时进行。早期测试有助于识别不合规问题,帮助减少修补不合规组件的成本。

不同应用领域需要不同测试。例如,软件测试可能包括单元测试、集成测试、黑盒测试、白盒测试、接口测试、回归测试、α 测试等;在建筑项目中,测试可能包括水泥强度测试、混凝土和易性测试、在建筑工地进行的旨在测试硬化混凝土结构的质量的无损伤测试,以及土壤试验;在硬件开发中,测试可能包括环境应力筛选、老化测试、系统测试等。

以下会议可作为控制质量过程的一部分:

  • 审查已批准的变更请求。对所有已批准的变更请求进行审查,以核实它们是否已按批准的方式实施,确认是否已完成局部变更,以及是否已执行、测试、完成和证实所有部分。
  • 回顾/经验教训。项目团队举行的会议,旨在讨论:
  • 项目/阶段的成功要素;
  • 待改进之处;
  • 当前项目和未来项目可增加的内容;
  • 可增加到组织过程资产中的内容。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于)质量管理计划,见 8.1.3.1 节。

项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程,这些过程有助于确保项目经理和项目团队在正确的时间和地点使用正确的资源。

项目资源管理过程包括:

9.1 规划资源管理 — 定义如何估算、获取、管理和利用实物以及团队项目资源的过程。

9.2 估算活动资源 — 估算执行项目所需的团队资源,以及材料、设备和用品的类型和数量的过程。

9.3 获取资源 — 获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。

9.4 建设团队 — 提高工作能力,促进团队成员互动,改善团队整体氛围,以提高项目绩效的过程。

9.5 管理团队 — 跟踪团队成员工作表现,提供反馈,解决问题并管理团队变更,以优化项目绩效的过程。

9.6 控制资源 — 确保按计划为项目分配实物资源,以及根据资源使用计划监督资源实际使用情况,并采取必要纠正措施的过程。

图 9-1 概括了项目资源管理的各个过程。虽然在本《PMBOK® 指南》中,各项目资源管理过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 9-1项目资源管理概述

团队资源管理相对于实物资源管理,对项目经理提出了不同的技能和能力要求。实物资源包括设备、材料、设施和基础设施,而团队资源或人员指的是人力资源。项目团队成员可能具备不同的技能,可能是全职或兼职的,可能随项目进展而增加或减少。项目资源管理与项目相关方管理之间有重叠的部分(见 13 节),本节(第 9 节)则重点关注组成项目团队的部分相关方。

项目资源管理的核心概念项目团队由承担特定角色和职责的个人组成,他们为实现项目目标而共同努力。项目经理因此应在获取、管理、激励和增强项目团队方面投入适当的努力。尽管项目团队成员被分派了特定的角色和职责,但让他们全员参与项目规划和决策仍是有益的。团队成员参与规划阶段,既可使他们对项目规划工作贡献专业技能,又可以增强他们对项目的责任感。

项目经理既是项目团队的领导者又是项目团队的管理者。除了项目管理活动,例如启动、规划、执行、监控和关闭各个项目阶段,项目经理还负责建设高效的团队。项目经理应留意能够影响团队的不同因素,例如:

  • 团队环境;
  • 团队成员的地理位置;
  • 相关方之间的沟通;
  • 组织变更管理;
  • 内外部政治氛围;
  • 文化问题和组织的独特性;
  • 其他可能改变项目绩效的因素。

作为领导者,项目经理还负责积极培养团队技能和能力,同时提高并保持团队的满意度和积极性,项目经理还应留意并支持职业与道德行为,确保所有团队成员都遵守这些行为。

实物资源管理着眼于以有效和高效的方式,分配和使用成功完成项目所需的实物资源,如材料、设备和用品。为此,组织应当拥有如下数据:(当前和合理的未来的)资源需求、(可以满足这些需求的)资源配置,以及资源供应。不能有效管理和控制资源是项目成功完成的风险来源。例如:

  • 未能确保关键设备或基础设施按时到位,可能会推迟最终产品的制造;
  • 订购低质量材料可能会损害产品质量,导致大量召回或返工;
  • 保存太多库存可能会导致高运营成本,使组织盈利下降;另一方面,如果库存量太低,就可能无法满足客户需求,同样会造成组织盈利下降。

项目资源管理的趋势和新兴实践项目管理风格正在从管理项目的命令和控制结构,转向更加协作和支持性的管理方法,通过将决策权分配给团队成员来提高团队能力。此外,现代的项目资源管理方法致力于寻求优化资源使用。

有关项目资源管理的趋势和新兴实践包括(但不限于):

  • 资源管理方法。过去几年,由于关键资源稀缺,在某些行业中出现了一些普遍的趋势,涌现出很多关于精益管理、准时制 (JIT) 生产、Kaizen(持续改善)、全员生产维护 (TPM)、约束理论等方法的文献资料。项目经理应确定执行组织是否采用了一种或多种资源管理工具,从而对项目做出相应的调整。
  • 情商 (EI)。项目经理应提升内在(如自我管理和自我意识)和外在(如关系管理)能力,从而提高个人情商。研究表明,提高项目团队的情商或情绪能力可提高团队效率,还可以降低团队成员离职率。
  • 自组织团队。随着敏捷方法在 IT 项目中的应用越来越普遍,自组织团队(无需集中管控运作)越来越多。对于拥有自组织团队的项目,“项目经理”(可能不称为“项目经理”)的角色主要是为团队创造环境、提供支持并信任团队可以完成工作。成功的自组织团队通常由通用的专才而不是主题专家组成,他们能够不断适应变化的环境并采纳建设性反馈。
  • 虚拟团队/分布式团队。项目全球化推动了对虚拟团队的需求的增长。这些团队成员致力于同一个项目,却分布在不同的地方。沟通技术(如电子邮件、电话会议、社交媒体、网络会议和视频会议等)的使用,使虚拟团队变得可行。虚拟团队管理有独特的优势,例如能够利用项目团队的专业技术,即使相应的专家不在同一地理区域;将在家办公的员工纳入团队;以及将行动不便者或残疾人纳入团队。而虚拟团队管理面临的挑战主要在于沟通,包括可能产生孤立感、团队成员之间难以分享知识和经验、难以跟进进度和生产率,以及可能存在时区和文化差异。

裁剪考虑因素由于每个项目都是独特的,项目经理需要裁剪项目资源管理过程。裁剪时应考虑的因素包括(但不限于):

  • 多元化。团队的多元化背景是什么?
  • 物理位置。团队成员和实物资源的物理位置在哪里?
  • 行业特定资源。所在行业需要哪些特殊资源?
  • 团队成员的获得。如何获得项目团队成员?项目团队资源是全职还是兼职?
  • 团队管理。如何管理项目团队建设?组织是否有管理团队建设的工具或是否需要创建新工具?

是否存在有特殊需求的团队成员?是否需要为团队提供有关多元化管理的特别培训?

  • 生命周期方法。项目采用哪些生命周期方法?

在敏捷或适应型环境中需要考虑的因素易变性高的项目得益于最大限度地集中和协作的团队结构,例如拥有通才的自组织团队。

协作旨在提高生产率和促进创新的问题解决方式。协作型团队可以促进不同工作活动的加速整合、改善沟通、增加知识分享,以及提供工作分配的灵活性和其他优势。

虽然协作的优势也适用于其他项目环境,协作型团队对于易变性高且快速变化的项目成功而言通常是至关重要的,因为集中分配任务和决策所需的时间更少。

对于易变性高的项目,实物和人力资源规划的可预测性要低得多。在这些环境中,关于快速供应和精益方法的协议,对控制成本和实现进度而言至关重要。

规划资源管理是定义如何估算、获取、管理和利用团队以及实物资源的过程。本过程的主要作用是,根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度。本过程仅开展一次或仅在项目的预定义点开展。图 9-2 描述本过程的输入、工具与技术和输出。图 9-3 是本过程的数据流向图。

图 9-2规划资源管理:输入、工具与技术和输出

• Projectcharter图 9-3规划资源管理:数据流向图

资源规划用于确定和识别一种方法,以确保项目的成功完成有足够的可用资源。项目资源可能包括团队成员、用品、材料、设备、服务和设施。有效的资源规划需要考虑稀缺资源的可用性和竞争,并编制相应的计划。

这些资源可以从组织内部资产获得,或者通过采购过程从组织外部获取。其他项目可能在同一时间和地点竞争项目所需的相同资源,从而对项目成本、进度、风险、质量和其他项目领域造成显著影响。

能够影响规划资源管理过程的事业环境因素包括(但不限于):

  • 组织文化和结构;
  • 设施和资源的地理分布;
  • 现有资源的能力和可用性;
  • 市场条件。

能够影响规划资源管理过程的组织过程资产包括(但不限于):

  • 人力资源政策和程序;
  • 物质资源管理政策和程序;
  • 安全政策;
  • 安保政策;
  • 资源管理计划模板;
  • 类似项目的历史信息。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:

  • 协调组织内部的最佳资源;
  • 人才管理和员工发展;
  • 确定为实现项目目标所需的初步投入水平;
  • 根据组织文化确定报告要求;
  • 根据经验教训和市场条件,评估获取资源所需的提前量;
  • 识别与资源获取、留用和遣散计划有关的风险;
  • 遵循适用的政府和工会法规;
  • 管理卖方和物流工作,确保在需要时能够提供材料和用品。

适用于本过程的数据表现技术包括(但不限于)图表。数据表现有多种格式来记录和阐明团队成员的角色与职责。大多数格式属于层级型、矩阵型或文本型。有些项目人员安排可以在子计划(如风险、质量或沟通管理计划)中列出。无论使用什么方法来记录团队成员的角色,目的都是要确保每个工作包都有明确的责任人,确保全体团队成员都清楚地理解其角色和职责。层级型可用于表示高层级角色,而文本型则更适合用于记录详细职责。

  • 层级型。可以采用传统的组织结构图,自上而下地显示各种职位及其相互关系。
  • 工作分解结构 (WBS)。WBS 用来显示如何把项目可交付成果分解为工作包,有助于明确高层级的职责。
  • 组织分解结构 (OBS)。WBS 显示项目可交付成果的分解,而 OBS 则按照组织现有的部门、单元或团队排列,并在每个部门下列出项目活动或工作包。运营部门(如信息技术部或采购部)只需要找到其所在的 OBS 位置,就能看到自己的全部项目职责。
  • 资源分解结构。资源分解结构是按资源类别和类型,对团队和实物资源的层级列表,用于规划、管理和控制项目工作。每向下一个层次都代表对资源的更详细描述,直到信息细到可以与工作分解结构(WBS)相结合,用来规划和监控项目工作。
  • 责任分配矩阵。责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个例子是职责分配矩阵(RAM),它显示了分配给每个工作包的项目资源,用于说明工作包或活动与项目团队成员之间的关系。在大型项目中,可以制定多个层次的 RAM。例如,高层次的RAM 可定义项目团队、小组或部门负责 WBS 中的哪部分工作,而低层次的 RAM 则可在各小组内为具体活动分配角色、职责和职权。矩阵图能反映与每个人相关的所有活动,以及与每项活动相关的所有人员,它也可确保任何一项任务都只有一个人负责,从而避免职权不清。RAM的一个例子是 RACI(执行、负责、咨询和知情)矩阵,如图 9-4 所示。图中最左边的一列表示有待完成的工作(活动)。分配给每项工作的资源可以是个人或小组,项目经理也可根据项目需要,选择“领导”或“资源”等适用词汇,来分配项目责任。如果团队是由内部和外部人员组成,RACI 矩阵对明确划分角色和职责特别有用。
  • 文本型。如果需要详细描述团队成员的职责,就可以采用文本型。文本型文件通常以概述的形式,提供诸如职责、职权、能力和资格等方面的信息。这种文件有多种名称,如职位描述、角色 — 职责 — 职权表,该文件可作为未来项目的模板,特别是在根据当前项目的经验教训对其内容进行更新之后。

图 9-4 RACI 矩阵示例

组织理论阐述个人、团队和组织部门的行为方式。有效利用组织理论中的常用技术,可以节约规划资源管理过程的时间、成本及人力投入,提高规划工作的效率。此外,可以根据相关的组织理论灵活使用领导风格,以适应项目生命周期中团队成熟度的变化。重要的是要认识到,组织的结构和文化影响项目组织结构。

作为项目管理计划的一部分,资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南。资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划。资源管理计划可能包括(但不限于):

  • 识别资源。用于识别和量化项目所需的团队和实物资源的方法。
  • 获取资源。关于如何获取项目所需的团队和实物资源的指南。
  • 角色与职责。
  • 角色。在项目中,某人承担的职务或分配给某人的职务,如土木工程师、商业分析师和测试协调员。
  • 职权。使用项目资源、做出决策、签字批准、验收可交付成果并影响他人开展项目工作的权力。例如,下列事项都需要由具有明确职权的人来做决策:选择活动的实施方法,质量验收标准,以及如何应对项目偏差等。当个人的职权水平与职责相匹配时,团队成员就能最好地开展工作。
  • 职责。为完成项目活动,项目团队成员必须履行的职责和工作。
  • 能力。为完成项目活动,项目团队成员需具备的技能和才干。如果项目团队成员不具备所需的能力,就不能有效地履行职责。一旦发现成员的能力与职责不匹配,就应主动采取措施,如安排培训、招募新成员、调整进度计划或工作范围。
  • 项目组织图。项目组织图以图形方式展示项目团队成员及其报告关系。基于项目的需要,项目组织图可以是正式或非正式的,非常详细或高度概括的。例如,一个 3000 人的灾害应急团队的项目组织图,要比仅有 20 人的内部项目的组织图详尽得多。
  • 项目团队资源管理。关于如何定义、配备、管理和最终遣散项目团队资源的指南。
  • 培训。针对项目成员的培训策略。
  • 团队建设。建设项目团队的方法。
  • 资源控制。依据需要确保实物资源充足可用、并为项目需求优化实物资源采购,而采用的方法。包括有关整个项目生命周期期间的库存、设备和用品管理的信息。
  • 认可计划。将给予团队成员哪些认可和奖励,以及何时给予。

能够影响估算活动资源过程的事业环境因素包括(但不限于):

  • 资源的位置;
  • 资源可用性;
  • 团队资源的技能;
  • 组织文化;
  • 发布的估算数据;
  • 市场条件。

能够影响估算活动资源过程的组织过程资产包括(但不限于):

  • 关于人员配备的政策和程序;
  • 关于用品和设备的政策与程序;
  • 关于以往项目中类似工作所使用的资源类型的历史信息。

见 4.3.2.2 节。项目管理信息系统可以包括资源管理软件,这些软件有助于规划、组织与管理资源库,以及编制资源估算。根据软件的复杂程度,可以确定资源分解结构、资源可用性、资源费率和各种资源日历,有助于优化资源使用。

获取资源是获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。本过程的主要作用是,概述和指导资源的选择,并将其分配给相应的活动。本过程应根据需要在整个项目期间定期开展。图 9-8 描述本过程的输入、工具与技术和输出。图 9-9 是本过程的数据流向图。

图 9-8获取资源:输入、工具与技术和输出

• Projectcharter图 9-9获取资源:数据流向图

项目所需资源可能来自项目执行组织的内部或外部。内部资源由职能经理或资源经理负责获取(分配),外部资源则是通过采购过程获得。

因为集体劳资协议、分包商人员使用、矩阵型项目环境、内外部报告关系或其他原因,项目管理团队可能或可能不对资源选择有直接控制权。重要的是,在获取项目资源过程中应注意下列事项:

  • 项目经理或项目团队应该进行有效谈判,并影响那些能为项目提供所需团队和实物资源的人员。
  • 不能获得项目所需的资源时,可能会影响项目进度、预算、客户满意度、质量和风险;资源或人员能力不足会降低项目成功的概率,最坏的情况可能导致项目取消。
  • 如因制约因素(如经济因素或其他项目对资源的占用)而无法获得所需团队资源,项目经理或项目团队可能不得不使用也许能力和成本不同的替代资源。在不违反法律、规章、强制性规定或其他具体标准的前提下可以使用替代资源。

在项目规划阶段,应该对上述因素加以考虑并做出适当安排。项目经理或项目管理团队应该在项目进度计划、项目预算、项目风险计划、项目质量计划、培训计划及其他相关项目管理计划中,说明缺少所需资源的后果。

能够影响获取资源过程的事业环境因素包括(但不限于):

  • 现有组织资源信息,包括可用性、能力水平、以及有关团队资源和资源成本的以往经验;
  • 市场条件;
  • 组织结构;
  • 地理位置。

能够影响获取资源过程的组织过程资产包括(但不限于):

  • 有关项目资源的采购、配置和分配的政策和程序;
  • 历史信息和经验教训知识库。

适用于本过程的人际关系与团队技能包括(但不限于)谈判。见 12.2.2.5 节。很多项目需要针对所需资源进行谈判,项目管理团队需要与下列各方谈判:

  • 职能经理。确保项目在要求的时限内获得最佳资源,直到完成职责。
  • 执行组织中的其他项目管理团队。合理分配稀缺或特殊资源。
  • 外部组织和供应商。提供合适的、稀缺的、特殊的、合格的、经认证的或其他特殊的团队或实物资源。特别需要注意与外部谈判有关的政策、惯例、流程、指南、法律及其他标准。

在资源分配谈判中,项目管理团队影响他人的能力很重要,如同在组织中的政治能力一样重要。例如,说服职能经理,让他/她看到项目具有良好的前景,会影响他/她把最佳资源分配给这个项目而不是竞争项目。

虚拟团队的使用为招募项目团队成员提供了新的可能性。虚拟团队可定义为具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人。现代沟通技术(如电子邮件、电话会议、社交媒体、网络会议和视频会议等)使虚拟团队成为可行。虚拟团队模式使人们有可能:

  • 在组织内部地处不同地理位置的员工之间组建团队;
  • 为项目团队增加特殊技能,即使相应的专家不在同一地理区域;
  • 将在家办公的员工纳入团队;
  • 在工作班次、工作小时或工作日不同的员工之间组建团队;
  • 将行动不便者或残疾人纳入团队;
  • 执行那些原本会因差旅费用过高而被搁置或取消的项目;
  • 节省员工所需的办公室和所有实物设备的开支。

在虚拟团队的环境中,沟通规划变得日益重要。可能需要花更多时间,来设定明确的期望、促进沟通、制定冲突解决方法、召集人员参与决策、理解文化差异,以及共享成功喜悦。

项目团队派工单记录了团队成员及其在项目中的角色和职责,可包括项目团队名录,还需要把人员姓名插入项目管理计划的其他部分,如项目组织图和进度计划。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。

开展本过程可能导致项目管理计划更新的内容包括(但不限于):

  • 资源管理计划。见 9.1.3.1 节。更新资源管理计划,以反映获取项目资源的实际经验,包括在项目早期获取资源的经验教训,这些经验会影响项目后期的资源获取过程。
  • 成本基准。见 7.3.3.1 节。在项目资源采购期间,成本基准可能发生变更。

需要更新的事业环境因素包括(但不限于):

  • 组织内资源的可用性;
  • 组织已使用的消耗资源的数量。

作为获取资源过程的结果,需要更新的组织过程资产包括(但不限于)有关采购、配置和分配资源的文件。

建设团队是提高工作能力,促进团队成员互动,改善团队整体氛围,以提高项目绩效的过程。

本过程的主要作用是,改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。本过程需要在整个项目期间开展。

图 9-10 描述本过程的输入、工具与技术和输出。图 9-11 是本过程的数据流向图。

图 9-10建设团队:输入、工具与技术和输出

• Projectcharter图 9-11建设团队:数据流向图

项目经理应该能够定义、建立、维护、激励、领导和鼓舞项目团队,使团队高效运行,并实现项目目标。团队协作是项目成功的关键因素,而建设高效的项目团队是项目经理的主要职责之一。

项目经理应创建一个能促进团队协作的环境,并通过给予挑战与机会、提供及时反馈与所需支持,以及认可与奖励优秀绩效,不断激励团队。通过以下行为可以实现团队的高效运行:

  • 使用开放与有效的沟通;
  • 创造团队建设机遇;
  • 建立团队成员间的信任;
  • 以建设性方式管理冲突;
  • 鼓励合作型的问题解决方法;
  • 鼓励合作型的决策方法。

项目经理在全球化环境和富有文化多样性的项目中工作:团队成员经常来自不同的行业,讲不同的语言,有时甚至会在工作中使用一种特别的“团队语言”或文化规范,而不是使用他们的母语;

项目管理团队应该利用文化差异,在整个项目生命周期中致力于发展和维护项目团队,并促进在相互信任的氛围中充分协作;通过建设项目团队,可以改进人际技巧、技术能力、团队环境及项目绩效。在整个项目生命周期中,团队成员之间都要保持明确、及时、有效(包括效果和效率两个方面)的沟通。建设项目团队的目标包括(但不限于):

  • 提高团队成员的知识和技能,以提高他们完成项目可交付成果的能力,并降低成本、缩短工期和提高质量;
  • 提高团队成员之间的信任和认同感,以提高士气、减少冲突和增进团队协作;
  • 创建富有生气、凝聚力和协作性的团队文化,从而:(1)提高个人和团队生产率,振奋团队精神,促进团队合作;(2)促进团队成员之间的交叉培训和辅导,以分享知识和经验;
  • 提高团队参与决策的能力,使他们承担起对解决方案的责任,从而提高团队的生产效率,获得更有效和高效的成果。

有一种关于团队发展的模型叫塔克曼阶梯理论 [19,20],其中包括团队建设通常要经过的五个阶段。尽管这些阶段通常按顺序进行,然而,团队停滞在某个阶段或退回到较早阶段的情况也并非罕见;而如果团队成员曾经共事过,项目团队建设也可跳过某个阶段。

  • 形成阶段。在本阶段,团队成员相互认识,并了解项目情况及他们在项目中的正式角色与职责。在这一阶段,团队成员倾向于相互独立,不一定开诚布公。
  • 震荡阶段。在本阶段,团队开始从事项目工作、制定技术决策和讨论项目管理方法。如果团队成员不能用合作和开放的态度对待不同观点和意见,团队环境可能变得事与愿违。
  • 规范阶段。在规范阶段,团队成员开始协同工作,并调整各自的工作习惯和行为来支持团队,团队成员会学习相互信任。
  • 成熟阶段。进入这一阶段后,团队就像一个组织有序的单位那样工作,团队成员之间相互依靠,平稳高效地解决问题。
  • 解散阶段。在解散阶段,团队完成所有工作,团队成员离开项目。通常在项目可交付成果完成之后,或者,在结束项目或阶段过程中,释放人员,解散团队。

某个阶段持续时间的长短,取决于团队活力、团队规模和团队领导力。项目经理应该对团队活力有较好的理解,以便有效地带领团队经历所有阶段。

能够影响建设团队过程的组织过程资产包括(但不限于)历史信息和经验教训知识库。

在建设项目团队过程中,需要对成员的优良行为给予认可与奖励。最初的奖励计划是在规划资源管理过程中编制的,只有能满足被奖励者的某个重要需求的奖励,才是有效的奖励。在管理项目团队过程中,可以正式或非正式的方式做出奖励决定,但在决定认可与奖励时,应考虑文化差异。

当人们感受到自己在组织中的价值,并且可以通过获得奖励来体现这种价值,他们就会受到激励。通常,金钱是奖励制度中的有形奖励,然而也存在各种同样有效、甚至更加有效的无形奖励。

大多数项目团队成员会因得到成长机会、获得成就感、得到赞赏以及用专业技能迎接新挑战,而受到激励。项目经理应该在整个项目生命周期中尽可能地给予表彰,而不是等到项目完成时。

培训包括旨在提高项目团队成员能力的全部活动,可以是正式或非正式的,方式包括课堂培训、在线培训、计算机辅助培训、在岗培训(由其他项目团队成员提供)、辅导及训练。如果项目团队成员缺乏必要的管理或技术技能,可以把对这种技能的培养作为项目工作的一部分。项目经理应该按资源管理计划中的安排来实施预定的培训,也应该根据管理项目团队过程中的观察、交谈和项目绩效评估的结果,来开展必要的计划外培训,培训成本通常应该包括在项目预算中,或者如果增加的技能有利于未来的项目,则由执行组织承担。培训可以由内部或外部培训师来执行。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组成部分包括(但不限于)资源管理计划,见 9.1.3.1 节。

作为建设团队过程的结果,需要更新的组织过程资产包括(但不限于):

  • 培训需求;
  • 人事评测。

能够影响管理团队过程的组织过程资产包括(但不限于):

  • 嘉奖证书;
  • 公司制服;
  • 组织中其他的额外待遇。

适用于本过程的人际关系与团队技能包括(但不限于):

  • 冲突管理。在项目环境中,冲突不可避免。冲突的来源包括资源稀缺、进度优先级排序和个人工作风格差异等。采用团队基本规则、团队规范及成熟的项目管理实践(如沟通规划和角色定义),可以减少冲突的数量。

成功的冲突管理可提高生产力,改进工作关系。同时,如果管理得当,意见分歧有利于提高创造力和改进决策。假如意见分歧成为负面因素,应该首先由项目团队成员负责解决;如果冲突升级,项目经理应提供协助,促成满意的解决方案,采用直接和合作的方式,尽早并且通常在私下处理冲突。如果破坏性冲突继续存在,则可使用正式程序,包括采取惩戒措施。

项目经理解决冲突的能力往往决定其管理项目团队的成败。不同的项目经理可能采用不同的解决冲突方法。影响冲突解决方法的因素包括:

  • 冲突的重要性与激烈程度;
  • 解决冲突的紧迫性;
  • 涉及冲突的人员的相对权力;
  • 维持良好关系的重要性;
  • 永久或暂时解决冲突的动机。

有五种常用的冲突解决方法,每种技巧都有各自的作用和用途。

mm撤退/回避。从实际或潜在冲突中退出,将问题推迟到准备充分的时候,或者将问题推给其他人员解决。

mm缓和/包容。强调一致而非差异;为维持和谐与关系而退让一步,考虑其他方的需要。

mm妥协/调解。为了暂时或部分解决冲突,寻找能让各方都在一定程度上满意的方案,但这种方法有时会导致“双输”局面。

mm强迫/命令。以牺牲其他方为代价,推行某一方的观点;只提供赢 — 输方案。通常是利用权力来强行解决紧急问题,这种方法通常会导致“赢输”局面。

mm合作/解决问题。综合考虑不同的观点和意见,采用合作的态度和开放式对话引导各方达成共识和承诺,这种方法可以带来双赢局面。

  • 制定决策。这种情况下,决策包括谈判能力以及影响组织与项目管理团队的能力,而不是决策工具集所描述的一系列工具。进行有效决策需要:
  • 着眼于所要达到的目标;
  • 遵循决策流程;
  • 研究环境因素;
  • 分析可用信息;
  • 激发团队创造力;
  • 理解风险。
  • 情商。情商指识别、评估和管理个人情绪、他人情绪及团体情绪的能力。项目管理团队能用情商来了解、评估及控制项目团队成员的情绪,预测团队成员的行为,确认团队成员的关注点及跟踪团队成员的问题,来达到减轻压力、加强合作的目的。
  • 影响力。在矩阵环境中,项目经理对团队成员通常没有或仅有很小的命令职权,所以他们适时影响相关方的能力,对保证项目成功非常关键。影响力主要体现在如下各方面:
  • 说服他人;
  • 清晰表达观点和立场;
  • 积极且有效的倾听;
  • 了解并综合考虑各种观点;
  • 收集相关信息,在维护相互信任的关系下,解决问题并达成一致意见。
  • 领导力。成功的项目需要强有力的领导技能,领导力是领导团队、激励团队做好本质工作的能力。它包括各种不同的技巧、能力和行动。且领导力在项目生命周期中的所有阶段都很重要。

有多种领导力理论,定义了适用于不同情形或团队的领导风格。领导力对沟通愿景及鼓舞项目团队高效工作十分重要。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组成部分包括(但不限于):

  • 资源管理计划。见 9.1.3.1 节。资源管理计划根据实际的项目团队管理经验更新。
  • 进度基准。见 6.5.3.1 节。可能需要更改项目进度,以反映团队的执行方式。
  • 成本基准。见 7.3.3.1 节。可能需要更改项目成本基准,以反映团队的执行方式。

作为管理团队过程的结果,需要更新的事业环境因素包括(但不限于):

  • 对组织绩效评价的输入;
  • 个人技能。

可作为本过程输入的项目文件包括(但不限于):

  • 问题日志。见 4.3.3.3 节。问题日志用于识别有关缺乏资源、原材料供应延迟,或低等级原材料等问题。
  • 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段,以改进实物资源控制。
  • 实物资源分配。见 9.3.3.1 节。实物资源分配描述了资源的预期使用情况以及资源的详细信息,例如类型、数量、地点以及属于组织内部资源还是外购资源。
  • 项目进度计划。见 6.5.3.2 节。项目进度计划展示了项目在何时何地需要哪些资源。
  • 资源分解结构。见 9.2.3.3 节。资源分解结构为项目过程中需要替换或重新获取资源的情况提供了参考。
  • 资源需求。见 9.2.3.1 节。资源需求识别了项目所需的材料、设备、用品和其他资源。
  • 风险登记册。见 11.2.3.1 节。风险登记册识别了可能会影响设备、材料或用品的单个风险。

见 12.2.3.2 节。在项目中签署的协议是获取组织外部资源的依据,应在需要新的和未规划的资源时,或在当前资源出现问题时,在协议里定义相关程序。

能够影响控制资源过程的组织过程资产包括(但不限于):

  • 有关资源控制和分配的政策;
  • 执行组织内用于解决问题的升级程序;
  • 经验教训知识库,其中包含以往类似项目的信息。

见 8.2.2.7 节。问题解决可能会用到一系列工具,有助于项目经理解决控制资源过程中出现的问题。问题可能来自组织内部(组织中另一部门使用的机器或基础设施未及时释放,因存储条件不当造成材料受损等)或来自组织外部(主要供应商破产或恶劣天气使资源受损)。项目经理应采取有条不紊的步骤来解决问题,包括:

  • 识别问题。明确问题。
  • 定义问题。将问题分解为可管理的小问题。
  • 调查。收集数据。
  • 分析。找出问题的根本原因。
  • 解决。从众多解决方案中选择最合适的一个。
  • 检查解决方案。确认是否已解决问题。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组成部分包括(但不限于):

  • 资源管理计划。见 9.1.3.1 节。资源管理计划根据实际的项目资源管理经验更新。
  • 进度基准。见 6.5.3.1 节。可能需要更新项目进度,以反映管理项目资源的方式。
  • 成本基准。见 7.3.3.1 节。可能需要更新项目成本基准,以反映管理项目资源的方式。

可在本过程更新的项目文件包括(但不限于):

  • 假设日志。见 4.1.3.2 节。把关于设备、材料、用品和其他实物资源的新假设条件更新在假设日志中。
  • 问题日志。见 4.3.3.3 节。在本过程中出现的新问题可以记录到问题日志中。
  • 经验教训登记册。见 4.4.3.1 节。在经验教训登记册中更新有效管理资源物流、废料、使用偏差,以及应对资源偏差的纠正措施的技术。
  • 实物资源分配单。见 9.3.3.1 节。实物资源分配单是动态的,会因可用性、项目、组织、环境或其他因素而发生变更。
  • 资源分解结构。见 9.2.3.3 节。可能需要更新资源分解结构,以反映使用项目资源的方式。
  • 风险登记册。见 11.2.3.1 节。关于资源可用性、利用或其他实物资源的风险更新风在险登记册中。

项目沟通管理包括通过开发工件,以及执行用于有效交换信息的各种活动,来确保项目及其相关方的信息需求得以满足的各个过程。项目沟通管理由两个部分组成:第一部分是制定策略,确保沟通对相关方行之有效;第二部分是执行必要活动,以落实沟通策略。

项目沟通管理的过程包括:

10.1 规划沟通管理 — 基于每个相关方或相关方群体的信息需求、可用的组织资产,以及具体项目的需求,为项目沟通活动制定恰当的方法和计划的过程。

10.2 管理沟通 — 确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程。

10.3 监督沟通 — 确保满足项目及其相关方的信息需求的过程。

图 10-1 概括了项目沟通管理的各个过程。虽然在本《PMBOK® 指南》中,各项目沟通管理过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 10-1项目沟通管理概述

项目沟通管理的核心概念沟通是指有意或无意的信息交换。交换的信息可以是想法、指示或情绪。信息交换的方法包括:

  • 书面形式。实物或电子形式。
  • 口头形式。面对面或远程形式。
  • 正式或非正式形式(用正式纸质或社交媒体)。
  • 手势动作。语调和面部表情。
  • 媒体形式。图片、行动,甚至只是遣词造句。
  • 遣词造句。表达一种想法的词语往往不止一个,且各词语的含义会存在细微差异。

沟通是指用各种可能的方式来发送或接收信息,或者通过沟通活动(如会议和演讲),或者以工件的方式(如电子邮件、社交媒体、项目报告或项目文档)。

项目经理的大多数时间用于与团队成员和其他项目相关方沟通,包括来自组织内部(组织的各个层级)和组织外部的人员。不同相关方可能有不同的文化和组织背景,以及不同的专业水平、观点和兴趣,而有效的沟通能够在他们之间架起一座桥梁。

沟通活动可按多种维度进行分类,包括(但不限于):

  • 内部。针对项目内部或组织内部的相关方。
  • 外部。针对外部相关方,如客户、供应商、其他项目、组织、政府,公众和环保倡导者。
  • 正式。报告、正式会议(定期及临时)、会议议程和记录、相关方简报和演示。
  • 非正式。采用电子邮件、社交媒体、网站,以及非正式临时讨论的一般沟通活动。
  • 层级沟通。相关方或相关方群体相对于项目团队的位置将会以如下方式影响信息传递的形式和内容:
  • 向上沟通。针对高层相关方。
  • 向下沟通。针对承担项目工作的团队和其他人员。
  • 横向沟通。针对项目经理或团队的同级人员。
  • 官方沟通。年报,呈交监管机构或政府部门的报告。
  • 非官方沟通。采用灵活(往往为非正式)的手段,来建立和维护项目团队及其相关方对项目情况的了解和认可,并在他们之间建立强有力的关系。
  • 书面与口头沟通。口头(用词和音调变化)及非口头(肢体语言和行为),社交媒体和网站、媒体发布。

沟通可以为成功完成项目与项目集建立必要的关系。用于开展沟通的活动和工件多种多样,从电子邮件和非正式对话,到正式会议和定期项目报告。通过言语、面部表情、手势动作和其他行动有意或无意地发送和接收信息。为了成功管理与相关方的项目关系,沟通既包括制定策略和计划,以便创建合适的沟通工件和开展合适的沟通活动,也包括运用相关技能来提升计划和即兴的沟通的效果。

成功的沟通包括两个部分。第一部分是根据项目及其相关方的需求而制定适当的沟通策略。从该策略出发,制定沟通管理计划,来确保用各种形式和手段把恰当的信息传递给相关方。这些信息构成项目沟通-成功沟通的第二部分。项目沟通是规划过程的产物,在沟通管理计划中有相关规定。

沟通管理计划定义了信息的收集、生成、发布、储存、检索、管理、追踪和处置。最终,沟通策略和沟通管理计划将成为监督沟通效果的依据。

在项目沟通中,需要尽力预防理解错误和沟通错误,并从规划过程所规定的各种方法、发送方、接收方和信息中作出谨慎选择。

在编制传统(非社交媒体)的书面或口头信息的时候,应用书面沟通的 5C 原则,可以减轻但无法消除理解错误:

  • 正确的语法和拼写。语法不当或拼写错误会分散注意力,还有可能扭曲信息含义,降低可信度。
  • 简洁的表述和无多余字。简洁且精心组织的信息能降低误解信息意图的可能性。
  • 清晰的目的和表述(适合读者的需要)。确保在信息中包含能满足受众需求与激发其兴趣的内容。
  • 连贯的思维逻辑。写作思路连贯,以及在整个书面文件中使用诸如“引言”和“小结”的小标题。
  • 受控的语句和想法承接。可能需要使用图表或小结来控制语句和想法的承接。

书面沟通的 5C原则需要用下列沟通技巧来配合:

  • 积极倾听。与说话人保持互动,并总结对话内容,以确保有效的信息交换。
  • 理解文化和个人差异。提升团队对文化及个人差异的认知,以减少误解并提升沟通能力。
  • 识别、设定并管理相关方期望。与相关方磋商,减少相关方社区中的自相矛盾的期望。
  • 强化技能。强化所有团队成员开展以下活动的技能:
  • 说服个人、团队或组织采取行动;
  • 激励和鼓励人们,或帮助人们重塑自信;
  • 指导人们改进绩效和取得期望结果;
  • 通过磋商达成共识以及减轻审批或决策延误;
  • 解决冲突,防止破坏性影响。

有效的沟通活动和工件创建具有如下基本属性:

  • 沟通目的明确;
  • 尽量了解沟通接收方,满足其需求及偏好;
  • 监督并衡量沟通的效果。

项目沟通管理的发展趋势和新兴实践在关注相关方,以及认可相关方的有效参与对项目及组织的价值的同时,也要认识到制定和落实适当的沟通策略,对维系与相关方的有效关系是至关重要的。项目沟通管理的发展趋势和新兴实践包括(但不限于):

  • 将相关方纳入项目评审范围。每个项目的相关方社区中都包括被项目团队确定为对成功达成项目目标和组织成果不可或缺的个人、群体和组织。有效的沟通策略要求定期且及时地评审相关方社区,以管理成员及其态度的变化。
  • 让相关方参加项目会议。项目会议应邀请项目外部甚至组织外部(若适当)的相关方参与。敏捷方法中的一些做法适用于任何类型的项目,例如,简短的每日站会。在每日站会上,项目团队和主要相关方就前一天的成绩和问题以及当天的工作计划展开讨论。
  • 社交工具的使用日益增多。以硬件平台、社交媒体服务和个人便携设备为代表的社交工具已经改变组织及其人员的沟通和业务方式。在公共 IT 基础设施的支持下,社交工具将不同的协作方式融合在一起。网络社交是指用户建立关系网络,与他人共同拓展兴趣和活动。社交媒体工具不仅能支持信息交换,而且也有助于建立更深层次的信任和社群关系。
  • 多面性沟通方法。制定项目相关方沟通策略时,通常应考虑所有可用技术,并从中作出选择;

同时也应尊重因文化、实践和个人背景而产生的对沟通语言、媒介、内容和方式的偏好。可以根据需要采用社交媒体和其他先进的电脑技术。多面性方法能够提高与不同年代和文化背景的相关方沟通的效果。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目团队需要裁剪项目沟通管理过程。裁剪时应考虑的因素包括(但不限于):

  • 相关方。相关方是属于组织内部或外部,或者二者都是?
  • 物理地点。团队成员身处何地?团队是否集中办公?团队是否位于相同地理区域?团队是否分散于多个时区?
  • 沟通技术。哪项技术可用于创建、记录、传输、检索、追踪和储存沟通工件?哪些技术最适用于与相关方沟通且成本效益最高?
  • 语言。语言是沟通活动中要考虑的主要因素。使用的是一种语言,还是多种语言?是否已为适应多语种团队的复杂情况安排了资金?
  • 知识管理。组织是否有正式的知识管理库?是否采用管理库?

在敏捷或适应型环境中需要考虑的因素在模糊不定的项目环境中,必然需要对不断演变和出现的细节情况,进行更频繁和快速的沟通。

因此,应该尽量简化团队成员获取信息的通道,频繁进行团队检查,并让团队成员集中办公。

此外,为了促进与高级管理层和相关方的沟通,还需要以透明的方式发布项目工件,并定期邀请相关方评审项目工件。

规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产,以及具体项目的需求,为项目沟通活动制定恰当的方法和计划的过程。本过程的主要作用是,为及时向相关方提供相关信息,引导相关方有效参与项目,而编制书面沟通计划。本过程应根据需要在整个项目期间定期开展。图 10-2 描述本过程的输入、工具与技巧和输出。图 10-3 是本过程的数据流向图。

图 10-2规划沟通管理:输入、工具与技术和输出

• Projectcharter图 10-3规划沟通管理:数据流向图

需在项目生命周期的早期,针对项目相关方多样性的信息需求,制定有效的沟通管理计划。应该定期审核沟通管理计划,并进行必要的修改,例如在相关方社区发生变化或每个新项目阶段开始时。

在大多数项目中,都需要很早就开展沟通规划工作,例如在识别相关方及制定项目管理计划期间。

虽然所有项目都需要进行信息沟通,但是各项目的信息需求和信息发布方式可能差别很大。此外,在本过程中,需要考虑并合理记录用来存储、检索和最终处置项目信息的方法。应该在整个项目期间,定期审查规划沟通管理过程的成果并做必要修改,以确保其持续适用。

能够影响规划沟通管理过程的事业环境因素包括(但不限于):

  • 组织文化、政治氛围和治理框架;
  • 人事管理政策;
  • 相关方风险临界值;
  • 已确立的沟通渠道、工具和系统;
  • 全球、区域或当地的趋势、实践或习俗;
  • 设施和资源的地理分布。

能够影响规划沟通管理过程的组织过程资产包括(但不限于):

  • 组织的社交媒体、道德和安全政策及程序;
  • 组织的问题、风险、变更和数据管理政策及程序;
  • 组织对沟通的要求;
  • 制作、交换、储存和检索信息的标准化指南;
  • 历史信息和经验教训知识库;
  • 以往项目的相关方及沟通数据和信息。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:

  • 组织内的政治和权力结构;
  • 组织及其他客户组织的环境和文化;
  • 组织变革管理方法和实践;
  • 项目可交付成果所属的行业或类型;
  • 组织沟通技术;
  • 关于遵守与企业沟通有关的法律要求的组织政策与程序;
  • 与安全有关的组织政策与程序;
  • 相关方,包括客户或发起人。

分析沟通需求,确定项目相关方的信息需求,包括所需信息的类型和格式,以及信息对相关方的价值。

常用于识别和确定项目沟通需求的信息包括(但不限于):

  • 相关方登记册及相关方参与计划中的相关信息和沟通需求;
  • 潜在沟通渠道或途径数量,包括一对一、一对多和多对多沟通;
  • 组织结构图;
  • 项目组织与相关方的职责、关系及相互依赖;
  • 开发方法;
  • 项目所涉及的学科、部门和专业;
  • 有多少人在什么地点参与项目;
  • 内部信息需要(如何时在组织内部沟通);
  • 外部信息需要(如何时与媒体、公众或承包商沟通);
  • 法律要求。

适用于本过程的人际关系与团队技能包括(但不限于):

  • 沟通风格评估。规划沟通活动时,用于评估沟通风格并识别偏好的沟通方法、形式和内容的一种技术。常用于不支持项目的相关方。可以先开展相关方参与度评估(见 13.2.2.5 节),再开展沟通风格评估。在相关方参与度评估中,找出相关方参与度的差距。为弥补这种差距,就需要特别裁剪沟通活动和工件。
  • 政治意识。政治意识有助于项目经理根据项目环境和组织的政治环境来规划沟通。政治意识是指对正式和非正式权力关系的认知,以及在这些关系中工作的意愿。理解组织战略、了解谁能行使权力和施加影响,以及培养与这些相关方沟通的能力,都属于政治意识的范畴。
  • 文化意识。文化意识指理解个人、群体和组织之间的差异,并据此调整项目的沟通策略。具有文化意识并采取后续行动,能够最小化因项目相关方社区内的文化差异而导致的理解错误和沟通错误。文化意识和文化敏感性有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。

沟通管理计划是项目管理计划的组成部分,描述将如何规划,结构化、执行与监督项目沟通,以提高沟通的有效性。该计划包括如下信息:

  • 相关方的沟通需求;
  • 需沟通的信息,包括语言、形式、内容和详细程度;
  • 上报步骤;
  • 发布信息的原因;
  • 发布所需信息、确认已收到,或作出回应(若适用)的时限和频率;
  • 负责沟通相关信息的人员;
  • 负责授权保密信息发布的人员;
  • 接收信息的人员或群体,包括他们的需要、需求和期望;
  • 用于传递信息的方法或技术,如备忘录、电子邮件、新闻稿,或社交媒体;
  • 为沟通活动分配的资源,包括时间和预算;
  • 随着项目进展,如项目不同阶段相关方社区的变化,而更新与优化沟通管理计划的方法;
  • 通用术语表;
  • 项目信息流向图、工作流程(可能包含审批程序)、报告清单和会议计划等;
  • 来自法律法规、技术、组织政策等的制约因素。

沟通管理计划中还包括关于项目状态会议、项目团队会议、网络会议和电子邮件等的指南和模板。如果项目要使用项目网站和项目管理软件,那就要把它们写进沟通管理计划。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于)相关方参与计划(见 13.2.3.1 节)。需要更新相关方参与计划,反映会影响相关方参与项目决策和执行的任何过程、程序、工具或技术。

可作为本过程输入的项目文件包括(但不限于):

  • 变更日志。见 4.6.3.3 节。变更日志用于向受影响的相关方传达变更,以及变更请求的批准、推迟和否决情况。
  • 问题日志。见 4.6.3.3 节。将与问题有关的信息传达给受影响的相关方。
  • 经验教训登记册。见 4.4.3.1 节。项目早期获取的与管理沟通有关的经验教训,可用于项目后期阶段改进沟通过程,提高沟通效率与效果。
  • 质量报告。见 8.2.3.1 节。质量报告包括与质量问题、项目和产品改进,以及过程改进相关的信息。这些信息应交给能够采取纠正措施的人员,以便达成项目的质量期望。
  • 风险报告。见 11.2.3.2 节。风险报告提供关于整体项目风险的来源的信息,以及关于已识别的单个项目风险的概述信息 。这些信息应传达给风险责任人及其他受影响的相关方。
  • 相关方登记册。见 13.1.3.1 节。相关方登记册确定了需要各类信息的人员、群体或组织。

会影响本过程的事业环境因素包括(但不限于):

  • 组织文化、政治氛围和治理框架;
  • 人事管理政策;
  • 相关方风险临界值;
  • 已确立的沟通渠道、工具和系统;
  • 全球、区域或当地的趋势、实践或习俗;
  • 设施和资源的地理分布。

会影响本过程的组织过程资产包括(但不限于):

  • 企业的社交媒体、道德和安全政策及程序;
  • 企业的问题、风险、变更和数据管理政策及程序;
  • 组织对沟通的要求;
  • 制作、交换、储存和检索信息的标准化指南;
  • 以往项目的历史信息,包括经验教训知识库。

见 10.1.2.3 节。会影响技术选用的因素包括团队是否集中办公、需要分享的信息是否需要保密、团队成员的可用资源,以及组织文化会如何影响会议和讨论的正常开展。

适用于本过程的人际关系与团队技能包括(但不限于):

  • 积极倾听。积极倾听技术包括告知已收到、澄清与确认信息、理解,以及消除妨碍理解的障碍。
  • 冲突管理。见 9.5.2.1 节。
  • 文化意识。见 10.1.2.6 节。
  • 会议管理。会议管理是采取步骤确保会议有效并高效地达到预期目标。规划会议时应采取以下步骤:
  • 准备并发布会议议程(其中包含会议目标);
  • 确保会议在规定的时间开始和结束;
  • 确保适当参与者受邀并出席;
  • 切题;
  • 处理会议中的期望、问题和冲突;
  • 记录所有行动以及所分配的行动责任人。
  • 人际交往。人际交往是通过与他人互动交流信息,建立联系。人际交往有利于项目经理及其团队通过非正式组织解决问题,影响相关方的行动,以及提高相关方对项目工作和成果的支持,从而改善绩效。
  • 政治意识。见 10.1.2.6 节。政治意识有助于项目经理在项目期间引导相关方参与,以保持相关方的支持。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可在本过程更新的项目管理计划包括(但不限于):

  • 沟通管理计划。见 10.1.3.1 节。如果本过程导致了项目沟通方法发生变更,就要把这种变更反映在项目沟通计划中。
  • 相关方参与计划。见 13.2.3.1 节。本过程将导致相关方的沟通需求以及商定的沟通策略需要更新。

可在本过程更新的组织过程资产包括(但不限于):

  • 项目记录,例如往来函件、备忘录、会议记录及项目中使用的其他文档;
  • 计划内的和临时的项目报告和演示。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 资源管理计划。见 9.1.3.1 节。通过描述角色和职责,以及项目组织结构图,资源管理计划可用于理解实际的项目组织及其任何变更。
  • 沟通管理计划。见 10.1.3.1 节。沟通管理计划是关于及时收集、生成和发布信息的现行计划,它确定了沟通过程中的团队成员、相关方和有关工作。
  • 相关方参与计划。见 13.2.3.1 节。相关方参与计划确定了计划用以引导相关方参与的沟通策略。

能够影响监督沟通过程的事业环境因素包括(但不限于):

  • 组织文化、政治氛围和治理框架;
  • 已确立的沟通渠道、工具和系统;
  • 全球、区域或当地的趋势、实践或习俗;
  • 设施和资源的地理分布。

可能影响监督沟通过程的组织过程资产包括(但不限于):

  • 企业的社交媒体、道德和安全政策及程序;
  • 组织对沟通的要求;
  • 制作、交换、储存和检索信息的标准化指南;
  • 以往项目的历史信息和经验教训知识库;
  • 以往项目的相关方及沟通数据和信息。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 沟通管理计划。见 10.1.3.1 节。需要更新沟通管理计划,记录能够让沟通更有效的新信息。
  • 相关方参与计划。见 13.2.3.1 节。需要更新相关方参与计划,反映相关方的实际情况、沟通需求和重要性。

项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。项目风险管理的目标在于提高正面风险的概率和(或)影响,降低负面风险的概率和(或)影响,从而提高项目成功的可能性。

项目风险管理的过程是:

11.1 规划风险管理 — 定义如何实施项目风险管理活动的过程。

11.2 识别风险 — 识别单个项目风险,以及整体项目风险的来源,并记录风险特征的过程。

11.3 实施定性风险分析 — 通过评估单个项目风险发生的概率和影响以及其他特征,对风险进行优先级排序,从而为后续分析或行动提供基础的过程。

11.4 实施定量风险分析 — 就已识别的单个项目风险和其他不确定性的来源对整体项目目标的综合影响进行定量分析的过程。

11.5 规划风险应对 — 为处理整体项目风险敞口,以及应对单个项目风险,而制定可选方案、选择应对策略并商定应对行动的过程。

11.6 实施风险应对 — 执行商定的风险应对计划的过程。

11.7 监督风险 — 在整个项目期间,监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险,以及评估风险管理有效性的过程。

图 11-1 概括了项目风险管理的各个过程。虽然在本《PMBOK® 指南》中,各项目管理风险过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 11-1项目风险管理概述

项目风险管理的核心概念既然项目是为交付收益而开展的、具有不同复杂程度的独特性工作,那自然就会充满风险。

开展项目,不仅要面对各种制约因素和假设条件,而且还要应对可能相互冲突和不断变化的相关方期望。组织应该有目的地以可控方式去冒项目风险,以便平衡风险和回报,并创造价值。

项目风险管理旨在识别和管理未被其他项目管理过程所管理的风险。如果不妥善管理,这些风险有可能导致项目偏离计划,无法达成既定的项目目标。因此,项目风险管理的有效性直接关乎项目成功与否。

每个项目都在两个层面上存在风险。每个项目都有会影响项目达成目标的单个风险,以及由单个项目风险和不确定性的其他来源联合导致的整体项目风险。考虑整体项目风险,也非常重要。项目风险管理过程同时兼顾这两个层面的风险。它们的定义如下:

  • 单个项目风险是一旦发生,会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
  • 整体项目风险是不确定性对项目整体的影响,是相关方面临的项目结果正面和负面变异区间。

它源于包括单个风险在内的所有不确定性。

一旦发生,单个项目风险会对项目目标产生正面或负面的影响。项目风险管理旨在利用或强化正面风险(机会),规避或减轻负面风险(威胁)。未妥善管理的威胁可能引发各种问题,如工期延误、成本超支、绩效不佳或声誉受损。把握好机会则能够获得众多好处,如工期缩短、成本节约、绩效改善或声誉提升。

整体项目风险也有正面或负面之分。管理整体项目风险旨在通过削弱负面变异的驱动因素,加强正面变异的驱动因素,以及最大化实现整体项目目标的概率,把项目风险敞口保持在可接受的范围之内。

因为风险会在项目生命周期内持续发生,所以,项目风险管理过程也应不断迭代开展。在项目规划期间,就应该通过调整项目策略对风险做初步处理。接着,应该随着项目进展,监督和管理风险,确保项目处于正轨,并且突发性风险也得到处理。

为有效管理特定项目的风险,项目团队需要知道,相对于要追求的项目目标,可接受的风险敞口究竟是多大。这通常用可测量的风险临界值来定义。风险临界值反映了组织与项目相关方的风险偏好程度,是项目目标的可接受的变异程度。应该明确规定风险临界,并传达给项目团队,同时反映在项目的风险影响级别定义中。

项目风险管理的发展趋势和新兴实践项目风险管理的关注面正在扩大,以便确保考虑所有类型的风险,并在更广泛的背景中理解项目风险。项目风险管理的发展趋势和新兴实践包括(但不限于):

  • 非事件类风险。大多数项目只关注作为可能发生或不发生的不确定性未来事件的风险。例如:

关键卖方可能在项目期间停业,客户可能在设计完成后变更需求,或分包商可能要求对标准化操作流程进行优化。

不过,识别并管理非事件类风险的意识正在不断加强。非事件类风险有两种主要类型:

  • 变异性风险。已规划事件、活动或决策的某些关键方面存在不确定性,就导致变异性风险。例如,生产率可能高于或低于目标值,测试发现的错误数量可能多于或少于预期,或施工阶段可能出现反常的天气情况。
  • 模糊性风险。对未来可能发生什么,存在不确定性。知识不足可能影响项目达成目标的能力,例如,不太了解需求或技术解决方案的要素、法规框架的未来发展,或项目内在的系统复杂性。

变异性风险可通过蒙特卡洛分析加以处理,即:用概率分布表示变异的可能区间,然后采取行动去缩小可能结果的区间。管理模糊性风险,则需要先定义认知或理解不足之处,进而通过获取外部专家意见或以最佳实践为标杆来填补差距。也可以采用增量开发、原型搭建或模拟等方法来处理模糊性风险。

  • 项目韧性。随着对所谓“未知-未知”因素的意识的增强,人们也越来越明确地知道确实存在突发性风险。这种风险只有在发生后才能被发现。可以通过加强项目韧性来应对突发性风险。

这就要求每个项目:

  • 除了为已知风险列出具体风险预算,还要为突发性风险预留合理的应急预算和时间;
  • 采用灵活的项目过程,包括强有力的变更管理,以便在保持朝项目目标推进的正确方向的同时,应对突发性风险;
  • 授权目标明确且值得信赖的项目团队在商定限制范围内完成工作;
  • 经常留意早期预警信号,以尽早识别突发性风险;
  • 明确征求相关方的意见,以明确为应对突发性风险而可以调整项目范围或策略的领域。
  • 整合式风险管理。项目存在于组织背景中,可能是项目集或项目组合的一部分。在项目、项目集、项目组合和组织这些层面上,都存在风险。应该在适当的层面上承担和管理风险。在较高层面识别出的某些风险,将被授权给项目团队去管理;而在较低层面识别出的某些风险,又可能上交给较高层面去管理(如果在项目之外管理最有效)。应该采用协调式企业级风险管理方法,来确保所有层面的风险管理工作的一致性和连贯性。这样就能使项目集和项目组合的结构具有风险效率,有利于在给定的风险敞口水平下创造最大的整体价值。

裁剪时需要考虑的因素因为每个项目都是独特的,所以有必要对项目风险管理过程的应用方式进行裁剪。裁剪时应考虑的因素包括(但不限于):

  • 项目规模。由预算、持续时间、范围或团队人数所体现的项目规模,要求采取更详细的风险管理方法吗?或者项目小到只需要用简化的风险管理过程吗?
  • 项目复杂性。由高水平创新、新技术采用、商务安排、界面或外部依赖关系导致的项目复杂性提高,是否要求采用更稳健的风险管理方法?或者项目是否简单到只需要用简化的风险管理过程?
  • 项目重要性。项目的战略重要性有多大?项目的风险级别因旨在创造突破性机会、克服组织经营的重大障碍或涉及重大产品创新而提高了吗?
  • 开发方法。它是否是瀑布式项目,风险管理过程可以相继或重复开展;或者此项目是否采取敏捷型方法,需在每个重复过程的开始阶段以及执行期间处理风险?

根据上述需考虑的因素来裁剪项目风险管理过程,这是规划风险管理过程的一部分工作。裁剪结果将被记录在风险管理计划中。

在敏捷或适应型环境中需要考虑的因素从本质上讲,越是变化的环境就存在越多的不确定性和风险。要应对快速变化,就需要采用适应型方法管理项目,即:通过跨职能项目团队和经常审查增量式工作产品,来加快知识分享,确保对风险的认知和管理。在选择每个迭代期的工作内容时,应该考虑风险;在每个迭代期间应该识别、分析和管理风险。

此外,应该根据对当前风险敞口的理解的加深,定期更新需求文件,并随项目进展重新排列工作优先级。

规划风险管理是定义如何实施项目风险管理活动的过程。本过程的主要作用是,确保风险管理的水平、方法和可见度与项目风险程度,以及项目对组织和其他相关方的重要程度相匹配。本过程仅开展一次或仅在项目的预定义点开展。图 11-2 描述本过程的输入、工具与技术和输出。图 11-3 是本过程的数据流向图。

图 11-2规划风险管理:输入、工具与技术和输出

图 11-3规划风险管理:数据流向图

规划风险管理过程在项目构思阶段就应开始,并在项目早期完成。在项目生命周期的后期,可能有必要重新开展本过程,例如,在发生重大阶段变更时,在项目范围显著变化时,或者后续对风险管理有效性进行审查且确定需要调整项目风险管理过程时。

会影响规划风险管理过程的事业环境因素包括(但不限于)由组织或关键相关方设定的整体风险临界值。

会影响规划风险管理过程的组织过程资产包括(但不限于):

  • 组织的风险政策;
  • 风险类别,可能用风险分解结构来表示;
  • 风险概念和术语的通用定义;
  • 风险描述的格式;
  • 风险管理计划、风险登记册和风险报告的模板;
  • 角色与职责;
  • 决策所需的职权级别;
  • 经验教训知识库,其中包含以往类似项目的信息。

见 4.1.2.1 节。应考虑具备以下专业知识或接受过相关培训的个人或小组的意见:

  • 熟悉组织所采取的管理风险的方法,包括该方法所在的企业风险管理体系;
  • 裁剪风险管理以适应项目的具体需求;
  • 在相同领域的项目上可能遇到的风险类型。

风险管理计划是项目管理计划的组成部分,描述如何安排与实施风险管理活动。风险管理计划可包括以下部分或全部内容:

  • 风险管理战略。描述用于管理本项目的风险的一般方法。
  • 方法论。确定用于开展本项目的风险管理的具体方法、工具及数据来源。
  • 角色与职责。确定每项风险管理活动的领导者、支持者和团队成员,并明确他们的职责。
  • 资金。确定开展项目风险管理活动所需的资金,并制定应急储备和管理储备的使用方案。
  • 时间安排。确定在项目生命周期中实施项目风险管理过程的时间和频率,确定风险管理活动并将其纳入项目进度计划。
  • 风险类别。确定对单个项目风险进行分类的方式。通常借助风险分解结构 (RBS)来构建风险类别。风险分解结构是潜在风险来源的层级展现(示例见图 11-4)。风险分解结构有助于项目团队考虑单个项目风险的全部可能来源,对识别风险或归类已识别风险特别有用。组织可能有适用于所有项目的通用风险分解结构,也可能针对不同类型项目使用几种不同的风险分解结构框架,或者允许项目量身定制专用的风险分解结构。如果未使用风险分解结构,组织则可能采用某种常见的风险分类框架,既可以是简单的类别清单,也可以是基于项目目标的某种类别结构。

图 11-4风险分解结构(RBS)示例

  • 相关方风险偏好。应在风险管理计划中记录项目关键相关方的风险偏好。他们的风险偏好会影响规划风险管理过程的细节。特别是,应该针对每个项目目标,把相关方的风险偏好表述成可测量的风险临界值。这些临界值不仅将联合决定可接受的整体项目风险敞口水平,而且也用于制定概率和影响定义。以后将根据概率和影响定义,对单个项目风险进行评估和排序。
  • 风险概率和影响定义。根据具体的项目环境,组织和关键相关方的风险偏好和临界值,来制定风险概率和影响定义。项目可能自行制定关于概率和影响级别的具体定义,或者用组织提供的通用定义作为出发点。应该根据拟开展项目风险管理过程的详细程度,来确定概率和影响级别的数量,即:更多级别(通常为五级)对应于更详细的风险管理方法,更少级别(通常为三级)对应于更简单的方法。表 11-1 针对三个项目目标提供了概率和影响定义的示例。

通过将影响定义为负面威胁(工期延误、成本增加和绩效不佳)和正面机会(工期缩短、成本节约和绩效改善),表格所示的量表可同时用于评估威胁和机会。

表 11-1概率和影响定义示例

  • 概率和影响矩阵。见 11.3.2.6 节。组织可在项目开始前确定优先级排序规则,并将其纳入组织过程资产,或者也可为具体项目量身定制优先级排序规则。在常见的概率和影响矩阵中,会同时列出机会和威胁;以正面影响定义机会,以负面影响定义威胁。概率和影响可以用描述性术语(如很高、高、中、低和很低)或数值来表达。如果使用数值,就可以把两个数值相乘,得出每个风险的概率 - 影响分值,以便据此在每个优先级组别之内排列单个风险相对优先级。

图 11-5 是概率和影响矩阵的示例,其中也有数值风险评分的可能方法。

图 11-5概率和影响矩阵示例(有评分方法)

  • 报告格式。确定将如何记录、分析和沟通项目风险管理过程的结果。在这一部分,描述风险登记册、风险报告以及项目风险管理过程的其他输出的内容和格式。
  • 跟踪。跟踪是确定将如何记录风险活动,以及将如何审计风险的管理过程。

识别风险是识别单个项目风险以及整体项目风险的来源,并记录风险特征的过程。本过程的主要作用是,记录现有的单个项目风险,以及整体项目风险的来源;同时,汇集相关信息,以便项目团队能够恰当应对已识别的风险。本过程需要在整个项目期间开展。图 11-6 描述本过程的输入、工具与技术和输出。图 11-7 是本过程的数据流向图。

图 11-6识别风险:输入、工具与技术和输出

图 11-7识别风险:数据流向图

识别风险时,要同时考虑单个项目风险,以及整体项目风险的来源。风险识别活动的参与者可能包括:项目经理、项目团队成员、项目风险专家(若已指定)、客户、项目团队外部的主题专家、最终用户、其他项目经理、运营经理、相关方和组织内的风险管理专家。虽然这些人员通常是风险识别活动的关键参与者,但是还应鼓励所有项目相关方参与单个项目风险的识别工作。项目团队的参与尤其重要,以便培养和保持他们对已识别单个项目风险、整体项目风险级别和相关风险应对措施的主人翁意识和责任感。

应该采用统一的风险描述格式,来描述和记录单个项目风险,以确保每一项风险都被清楚、明确地理解,从而为有效的分析和风险应对措施制定提供支持。可以在识别风险过程中为单个项目风险指定风险责任人,待实施定性风险分析过程确认。也可以识别和记录初步的风险应对措施,待规划风险应对过程审查和确认。

在整个项目生命周期中,单个项目风险可能随项目进展而不断出现,整体项目风险的级别也会发生变化。因此,识别风险是一个迭代的过程。迭代的频率和每次迭代所需的参与程度因情况而异,应在风险管理计划中做出相应规定。

见 12.3.1.4 节。如果需要从外部采购项目资源,就应该审查初始采购文档,因为从组织外部采购商品和服务可能提高或降低整体项目风险,并可能引发更多的单个项目风险。随着采购文档在项目期间的不断更新,还应该审查最新的文档,例如,卖方绩效报告、核准的变更请求和与检查相关的信息。

会影响识别风险过程的组织过程资产包括(但不限于):

  • 项目文档,包括实际数据;
  • 组织和项目的过程控制资料;
  • 风险描述的格式;
  • 以往类似项目的核对单。

适用于本过程的数据收集技术包括(但不限于):

  • 头脑风暴。头脑风暴(见 4.1.2.2 节)的目标是获取一份全面的单个项目风险和整体项目风险来源的清单。通常由项目团队开展头脑风暴,同时邀请团队以外的多学科专家参与。可以采用自由或结构化的形式开展头脑风暴,在引导者的指引下产生各种创意。可以用风险类别(如风险分解结构)作为识别风险的框架。因为头脑风暴生成的创意并不成型,所以应该特别注意对头脑风暴识别的风险进行清晰描述。
  • 核对单。核对单是包括需要考虑的项目、行动或要点的清单。它常被用作提醒。基于从类似项目和其他信息来源积累的历史信息和知识来编制核对单。编制核对单,列出过去曾出现且可能与当前项目相关的具体单个项目风险,这是吸取已完成的类似项目的经验教训的有效方式。组织可能基于自己已完成的项目来编制核对单,或者可能采用特定行业的通用风险核对单。虽然核对单简单易用,但它不可能穷尽所有风险。所以,必须确保不要用核对单来取代所需的风险识别工作;同时,项目团队也应该注意考察未在核对单中列出的事项。此外,还应该不时地审查核对单,增加新信息,删除或存档过时信息。
  • 访谈。可以通过对资深项目参与者、相关方和主题专家的访谈,来识别单个项目风险以及整体项目风险的来源。应该在信任和保密的环境下开展访谈(见 5.2.2.2 节),以获得真实可信、不带偏见的意见。

适用于本过程的数据分析技术包括(但不限于):

  • 根本原因分析。根本原因分析(见 8.2.2.2 节)常用于发现导致问题的深层原因并制定预防措施。可以用问题陈述(如项目可能延误或超支)作为出发点,来探讨哪些威胁可能导致该问题,从而识别出相应的威胁。也可以用收益陈述(如提前交付或低于预算)作为出发点,来探讨哪些机会可能有利于实现该效益,从而识别出相应的机会。
  • 假设条件和制约因素分析。每个项目及其项目管理计划的构思和开发都基于一系列的假设条件,并受一系列制约因素的限制。这些假设条件和制约因素往往都已纳入范围基准和项目估算。开展假设条件和制约因素分析,来探索假设条件和制约因素的有效性,确定其中哪些会引发项目风险。从假设条件的不准确、不稳定、不一致或不完整,可以识别出威胁,通过清除或放松会影响项目或过程执行的制约因素,可以创造出机会。
  • SWOT 分析。这是对项目的优势、劣势、机会和威胁 (SWOT) 进行逐个检查。在识别风险时,它会将内部产生的风险包含在内,从而拓宽识别风险的范围。首先,关注项目、组织或一般业务领域,识别出组织的优势和劣势;然后,找出组织优势可能为项目带来的机会,组织劣势可能造成的威胁。还可以分析组织优势能在多大程度上克服威胁,组织劣势是否会妨碍机会的产生。
  • 文件分析。见 5.2.2.3 节。通过对项目文件的结构化审查,可以识别出一些风险。可供审查的文件包括(但不限于)计划、假设条件、制约因素、以往项目档案、合同、协议和技术文件。

项目文件中的不确定性或模糊性,以及同一文件内部或不同文件之间的不一致,都可能是项目风险的指示信号。

能够影响实施定性风险分析的组织过程资产包括(但不限于)已完成的类似项目的信息。

适用于本过程的数据分析技术包括(但不限于):

  • 风险数据质量评估。风险数据是开展定性风险分析的基础。风险数据质量评估旨在评价关于单个项目风险的数据的准确性和可靠性。使用低质量的风险数据,可能导致定性风险分析对项目来说基本没用。如果数据质量不可接受,就可能需要收集更好的数据。可以开展问卷调查,了解项目相关方对数据质量各方面的评价,包括数据的完整性、客观性、相关性和及时性,进而对风险数据的质量进行综合评估。可以计算这些方面的加权平均数,将其作为数据质量的总体分数。
  • 风险概率和影响评估。风险概率评估考虑的是特定风险发生的可能性,而风险影响评估考虑的是风险对一项或多项项目目标的潜在影响,如进度、成本、质量或绩效。威胁将产生负面的影响,机会将产生正面的影响。要对每个已识别的单个项目风险进行概率和影响评估。风险评估可以采用访谈或会议的形式,参加者将依照他们对风险登记册中所记录的风险类型的熟悉程度而定。项目团队成员和项目外部资深人员应该参加访谈或会议。在访谈或会议期间,评估每个风险的概率水平及其对每项目标的影响级别。如果相关方对概率水平和影响级别的感知存在差异,则应对差异进行探讨。此外,还应记录相应的说明性细节,例如,确定概率水平或影响级别所依据的假设条件。应该采用风险管理计划中的概率和影响定义(表11-1),来评估风险的概率和影响。低概率和影响的风险将被列入风险登记册中的观察清单,以供未来监控。
  • 其他风险参数评估。为了方便未来分析和行动,在对单个项目风险进行优先级排序时,项目团队可能考虑(除概率和影响以外的)其他风险特征。此类特征可能包括(但不限于):
  • 紧迫性。为有效应对风险而必须采取应对措施的时间段。时间短就说明紧迫性高。
  • 邻近性。风险在多长时间后会影响一项或多项项目目标。时间短就说明邻近性高。
  • 潜伏期。从风险发生到影响显现之间可能的时间段。时间短就说明潜伏期短。
  • 可管理性。风险责任人(或责任组织)管理风险发生或影响的容易程度。如果容易管理,可管理性就高。
  • 可控性。风险责任人(或责任组织)能够控制风险后果的程度。如果后果很容易控制,可控性就高。
  • 可监测性。对风险发生或即将发生进行监测的容易程度。如果风险发生很容易监测,可监测性就高。
  • 连通性。风险与其他单个项目风险存在关联的程度大小。如果风险与多个其他风险存在关联,连通性就高。
  • 战略影响力。风险对组织战略目标潜在的正面或负面影响。如果风险对战略目标有重大影响,战略影响力就大。
  • 密切度。风险被一名或多名相关方认为要紧的程度。被认为很要紧的风险,密切度就高。

相对于仅评估概率和影响,考虑上述某些特征有助于进行更稳健的风险优先级排序。

适用于本过程的数据表现技术包括(但不限于):

  • 概率和影响矩阵。概率和影响矩阵是把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。此矩阵对概率和影响进行组合,以便于把单个项目风险划分成不同的优先级组别(见图 11-5)。基于风险的概率和影响,对风险进行优先级排序,以便未来进一步分析并制定应对措施。采用风险管理计划中规定的风险概率和影响定义,逐一对单个项目风险的发生概率及其对一项或多项项目目标的影响(若发生)进行评估。然后,基于所得到的概率和影响的组合,使用概率和影响矩阵,来为单个项目风险分配优先级别。

组织可针对每个项目目标(如成本、时间和范围)制定单独的概率和影响矩阵,并用它们来评估风险针对每个目标的优先级别。组织还可以用不同的方法为每个风险确定一个总体优先级别。即可综合针对不同目标的评估结果,也可采用最高优先级别(无论针对哪个目标),作为风险的总体优先级别。

  • 层级图。如果使用了两个以上的参数对风险进行分类,那就不能使用概率和影响矩阵,而需要使用其他图形。例如,气泡图能显示三维数据。在气泡图中,把每个风险都绘制成一个气泡,并用x 轴值、y 轴值和气泡大小来表示风险的三个参数。图 11-10 是气泡图的示例,其中,X轴代表可监测性,Y轴代表邻近性,影响值则以气泡大小表示。

图 11-10列出可监测性、邻近性和影响值的气泡图示例

能够影响实施定量风险分析过程的组织过程资产包括已完成的类似项目的信息。

能够影响规划风险应对过程的组织过程资产包括(但不限于):

  • 风险管理计划、风险登记册和风险报告的模板;
  • 历史数据库;
  • 类似项目的经验教训知识库。

针对威胁,可以考虑下列五种备选策略:

  • 上报。如果项目团队或项目发起人认为某威胁不在项目范围内,或提议的应对措施超出了项目经理的权限,就应该采用上报策略。被上报的风险将在项目集层面、项目组合层面或组织的其他相关部门加以管理,而不在项目层面。项目经理确定应就威胁通知哪些人员,并向该人员或组织部门传达关于该威胁的详细信息。对于被上报的威胁,组织中的相关人员必须愿意承担应对责任,这一点非常重要。威胁通常要上报给其目标会受该威胁影响的那个层级。威胁一旦上报,就不再由项目团队做进一步监督,虽然仍可出现在风险登记册中供参考。
  • 规避。风险规避是指项目团队采取行动来消除威胁,或保护项目免受威胁的影响。它可能适用于发生概率较高,且具有严重负面影响的高优先级威胁。规避策略可能涉及变更项目管理计划的某些方面,或改变会受负面影响的目标,以便于彻底消除威胁,将它的发生概率降低到零。

风险责任人也可以采取措施,来分离项目目标与风险万一发生的影响。规避措施可能包括消除威胁的原因、延长进度计划、改变项目策略,或缩小范围。有些风险可以通过澄清需求、获取信息、改善沟通或取得专有技能来加以规避。

  • 转移。转移涉及到将应对威胁的责任转移给第三方,让第三方管理风险并承担威胁发生的影响。采用转移策略,通常需要向承担威胁的一方支付风险转移费用。风险转移可能需要通过一系列行动才得以实现,包括(但不限于)购买保险、使用履约保函、使用担保书、使用保证书等。也可以通过签订协议,把具体风险的归属和责任转移给第三方。
  • 减轻。风险减轻是指采取措施来降低威胁发生的概率和(或)影响。提前采取减轻措施通常比威胁出现后尝试进行弥补更加有效。减轻措施包括采用较简单的流程,进行更多次测试,或者选用更可靠的卖方。还可能涉及原型开发(见 5.2.2.8 节),以降低从实验台模型放大到实际工艺或产品中的风险。如果无法降低概率,也许可以从决定风险严重性的因素入手,来减轻风险发生的影响。例如,在一个系统中加入冗余部件,可以减轻原始部件故障所造成的影响。
  • 接受。风险接受是指承认威胁的存在,但不主动采取措施。此策略可用于低优先级威胁,也可用于无法以任何其他方式加以经济有效地应对的威胁。接受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备,包括预留时间、资金或资源以应对出现的威胁;被动接受策略则不会主动采取行动,而只是定期对威胁进行审查,确保其并未发生重大改变。

针对机会,可以考虑下列五种备选策略:

  • 上报。如果项目团队或项目发起人认为某机会不在项目范围内,或提议的应对措施超出了项目经理的权限,就应该取用上报策略。被上报的机会将在项目集层面、项目组合层面或组织的其他相关部门加以管理,而不在项目层面。项目经理确定应就机会通知哪些人员,并向该人员或组织部门传达关于该机会的详细信息。对于被上报的机会,组织中的相关人员必须愿意承担应对责任,这一点非常重要。机会通常要上报给其目标会受该机会影响的那个层级。

机会一旦上报,就不再由项目团队做进一步监督,虽然仍可出现在风险登记册中供参考。

  • 开拓。如果组织想确保把握住高优先级的机会,就可以选择开拓策略。此策略将特定机会的出现概率提高到 100%,确保其肯定出现,从而获得与其相关的收益。开拓措施可能包括:把组织中最有能力的资源分配给项目来缩短完工时间,或采用全新技术或技术升级来节约项目成本并缩短项目持续时间。
  • 分享。分享涉及到将应对机会的责任转移给第三方,使其享有机会所带来的部分收益。必须仔细为已分享的机会安排新的风险责任人,让那些最有能力为项目抓住机会的人担任新的风险责任人。采用风险分享策略,通常需要向承担机会应对责任的一方支付风险费用。分享措施包括建立合伙关系、合作团队、特殊公司或合资企业来分享机会。
  • 提高。提高策略用于提高机会出现的概率和(或)影响。提前采取提高措施通常比机会出现后尝试改善收益更加有效。通过关注其原因,可以提高机会出现的概率;如果无法提高概率,也许可以针对决定其潜在收益规模的因素来提高机会发生的影响。机会提高措施包括为早日完成活动而增加资源。
  • 接受。接受机会是指承认机会的存在,但不主动采取措施。此策略可用于低优先级机会,也可用于无法以任何其他方式加以经济有效地应对的机会。接受策略又分为主动或被动方式。

最常见的主动接受策略是建立应急储备,包括预留时间、资金或资源,以便在机会出现时加以利用;被动接受策略则不会主动采取行动,而只是定期对机会进行审查,确保其并未发生重大改变。

风险应对措施的规划和实施不应只针对单个项目风险,还应针对整体项目风险。用于应对单个项目风险的策略也适用于整体项目风险:

  • 规避。如果整体项目风险有严重的负面影响,并已超出商定的项目风险临界值,就可以采用规避策略。此策略涉及采取集中行动,弱化不确定性对项目整体的负面影响,并将项目拉回到临界值以内。例如,取消项目范围中的高风险工作,就是一种整个项目层面的规避措施。

如果无法将项目拉回到临界值以内,则可能取消项目。这是最极端的风险规避措施,仅适用于威胁的整体级别在当前和未来都不可接受。

  • 开拓。如果整体项目风险有显著的正面影响,并已超出商定的项目风险临界值,就可以采用开拓策略。此策略涉及采取集中行动,去获得不确定性对整体项目的正面影响。例如,在项目范围中增加高收益的工作,以提高项目对相关方的价值或效益;或者,也可以与关键相关方协商修改项目的风险临界值,以便将机会包含在内。
  • 转移或分享。如果整体项目风险的级别很高,组织无法有效加以应对,就可能需要让第三方代表组织对风险进行管理。若整体项目风险是负面的,就需要采取转移策略,这可能涉及支付风险费用;如果整体项目风险高度正面,则由多方分享,以获得相关收益。整体项目风险的转移和分享策略包括(但不限于):建立买方和卖方分享整体项目风险的协作式业务结构、成立合资企业或特殊目的公司,或对项目的关键工作进行分包。
  • 减轻或提高。本策略涉及变更整体项目风险的级别,以优化实现项目目标的可能性。减轻策略适用于负面的整体项目风险,而提高策略则适用于正面的整体项目风险。减轻或提高策略包括重新规划项目、改变项目范围和边界、调整项目优先级、改变资源配置、调整交付时间等。
  • 接受。即使整体项目风险已超出商定的临界值,如果无法针对整体项目风险采取主动的应对策略,组织可能选择继续按当前的定义推动项目进展。接受策略又分为主动或被动方式。最常见的主动接受策略是为项目建立整体应急储备,包括预留时间、资金或资源,以便在项目风险超出临界值时使用;被动接受策略则不会主动采取行动,而只是定期对整体项目风险的级别进行审查,确保其未发生重大改变。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 进度管理计划。见 6.1.3.1 节。对进度管理计划的变更包括:资源负荷和资源平衡变更,或进度策略更新等。
  • 成本管理计划。见 7.1.3.1 节。对成本管理计划的变更包括:成本会计、跟踪和报告变更,以及预算策略和应急储备使用方法更新等。
  • 质量管理计划。见 8.1.3.1 节。对质量管理计划的变更包括:满足需求的方法、质量管理方法,或质量控制过程的变更等。
  • 资源管理计划。见 9.1.3.1 节。对资源管理计划的变更包括:资源配置变更,以及资源策略更新等。
  • 采购管理计划。见 12.1.3.1 节。对采购管理计划的变更包括:自制或外购决策或合同类型的更改等。
  • 范围基准。见 5.4.3.1 节。如果商定的风险应对策略导致了范围变更,且这种变更已经获得批准,那么就要对范围基准做出相应的变更。
  • 进度基准。见 6.5.3.1 节。如果商定的风险应对策略导致了进度估算变更,且这种变更已经获得批准,那么就要对进度基准做出相应的变更。
  • 成本基准。见 7.3.3.1 节。如果商定的风险应对策略导致了成本估算变更,且这种变更已经获得批准,那么就要对成本基准做出相应的变更。

能够影响实施风险应对过程的组织过程资产包括(但不限于)已完成的类似项目的经验教训知识库,其中会说明特定风险应对的有效性。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。项目管理计划的任何组件都可能受本过程的影响。

可在本过程更新的组织过程资产包括(但不限于):

  • 风险管理计划、风险登记册和风险报告的模板;
  • 风险分解结构。

项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程,例如,合同、订购单、协议备忘录 (MOA),或服务水平协议 (SLA)。被授权采购项目所需货物和(或)服务的人员可以是项目团队、管理层或组织采购部(如果有)的成员。

项目采购管理过程包括:

12.1 规划采购管理 — 记录项目采购决策、明确采购方法,及识别潜在卖方的过程。

12.2 实施采购 — 获取卖方应答、选择卖方并授予合同的过程。

12.3 控制采购 — 管理采购关系、监督合同绩效、实施必要的变更和纠偏,以及关闭合同的过程。

虽然在本指南中,采购过程以界限分明和相互独立的形式出现,但在实践中,采购过程相当复杂且相互作用,还与其他知识领域的过程相互作用。本指南无法全面详述这些相互作用。本章以从项目外部获取货物或服务的视角来叙述采购过程。

图 12-1 概括了项目采购管理的各个过程。虽然在本《PMBOK® 指南》中,各项目采购管理过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 12-1项目采购管理概述

项目采购管理的核心概念与采购过程相关的重大法律义务和惩罚,通常超出大多数其他的项目管理过程。虽然项目经理不必成为采购管理法律法规领域的专家,但应该对采购过程有足够了解,以便做出与合同及合同关系相关的明智决定。通常情况下,项目经理无权签署对组织有约束力的法律协议,这项工作仅由具备相关职权的人员执行。

项目采购管理过程涉及到用协议来描述买卖双方之间的关系。协议可以很简单,如以特定人工单价购买所需的工时,也可以很复杂,如多年的国际施工合同。合同签署的方法和合同本身应体现可交付成果或所需人力投入的简单性或复杂性,其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。

合同应明确说明预期的可交付成果和结果,包括从卖方到买方的任何知识转移。合同中未规定的任何事项则不具法律强制力。开展国际合作的项目经理应牢记,无论合同规定如何详尽,文化和当地法律对合同及其可执行性均有影响。

采购合同中包括条款和条件,也可包括买方就卖方应实施工作或应交付产品的其他规定。在与采购办公室协作确保遵守组织的采购政策的同时,项目管理团队必须确定所有采购都能满足项目的具体需要。因应用领域不同,协议可以是合同、服务水平协议(SLA)、谅解备忘录、协议备忘录(MOA)或订购单。

大多数组织都有相关的书面政策和程序,来专门定义采购规则,并规定谁有权代表组织签署和管理协议。在世界各地,组织虽然用不同的名称来称呼负责采购的单位或部门,如购买部、合同部、采购部或收购部,但其实际职责大同小异。

虽然所有项目文件可能都要经过某种形式的审查与批准,但是,鉴于其法律约束力,合同或协议需要经过更多的审批程序,而且通常会涉及到法务部。在任何情况下,审批程序的主要目标都是确保合同充分描述将由卖方提供的产品、服务或成果,且符合法律法规关于采购的规定。通常把描述产品、服务或成果的文件作为独立的附件或附录,以便合同正文使用标准化的法律合同用语。

在复杂项目中,可能需要同时或先后管理多个合同。这种情况下,不同合同的生命周期可在项目生命周期的任何阶段开始与结束。买卖方关系是采购组织与外部组织之间的关系,可存在于项目的许多层次上。

因应用领域不同,卖方可以是承包商、供货商、服务提供商或供应商;买方可能为最终产品的所有人、分包商、收购机构、服务需求者或购买方。在合同生命周期中,卖方首先是投标人,然后是中标人,之后是签约供应商或供货商。

中标人可将所承揽的工作当作一个项目加以管理。在这种情况下:

  • 买方就变成了承包商、供应商及服务提供商的客户,因此也就是卖方的关键项目相关方。
  • 卖方的项目管理团队就需要关注工作执行或服务提供所涉及的所有过程。
  • 对于卖方来说,合同条款和条件以及采购工作说明书 (SOW) 都是其许多管理过程的重要输入。

在合同中,可实际列出各种输入(如,主要可交付成果、关键里程碑、成本目标),或者可限制项目团队的选择余地(如,在 IT 整合项目中,关于人员配备的决定往往要征得买方的批准)。另外,采购工作说明书可能使用其他名称,如技术工作说明书。

  • 卖方本身也可能成为更低层级的产品、服务和材料分包商及供应商的买方。

本节假设项目所需物品或服务的买方是项目团队,或者是组织内部的某个部门,同时假设卖方是为项目提供物品或服务的一方,且通常来自执行组织外部。在某些项目上,卖方可能是项目执行组织内部但属于项目外部的某个小组或部门。在大型复杂的项目上,卖方可能在授予合同后才成为整合式项目团队的一部分。

在小型组织或初创企业,以及未设置购买、合同或采购部门的组织,项目经理可以拥有采购职权,能够直接谈判并签署合同(分散式采购)。在更成熟的组织中,由专设部门开展实际的采购和合同签署工作,即采购、谈判和签署合同(集中式采购)。

在签署国际合同时,应该在合同中明确规定对合同的法律管辖权。在大多数情况下,卖方是受正式合同关系约束的外部承包商。

采购管理的发展趋势和新兴实践不同行业各方面(软件工具、风险、过程、物流和技术)的一些重大趋势,会影响项目的成功率。项目采购管理的发展趋势和新兴实践包括(但不限于):

  • 工具的改进。用于管理项目采购和项目执行的工具已经取得重大发展。现在,买方能够使用在线工具集中发布采购广告;卖方也能够使用在线工具集中查找采购文件,并直接在线填写。在施工、工程和基础设施领域,建筑信息模型(BIM) 软件的应用日益广泛,为工程项目节省了大量时间和资金。它能够大幅减少施工索赔,从而降低成本、缩短工期,因此世界各地的主要公司和政府都开始要求在大型项目中使用 BIM。
  • 更先进的风险管理。在风险管理领域日益流行的一个趋势,就是在编制合同时准确地将具体风险分配给最有能力对其加以管理的一方。没有任何承包商有能力管理项目的所有重大风险,买方因而必须接受承包商无法掌控的风险,例如,采购方公司政策的不断变化、法规要求的不断变化,以及项目以外的其他风险。在合同中可以明确规定风险管理是合同工作的一部分。
  • 变化中的合同签署实践。在过去几年时间内,超大型项目的数量显著增加,尤其是在基础设施建设和工程项目领域。数十亿美元的项目现在已十分常见。大部分此类项目都要求与多个国家的多家承包商签署国际合同,因此肯定比仅使用当地承包商的项目具有更大的风险。承包商越来越重视在采购过程中与客户开展密切合作,以便对批量采购或有其他特殊关系的客户给予折扣优惠。对于此类项目来说,为了减少执行过程中的问题和索赔,采用国际公认的标准合同范本也日益普遍。
  • 物流和供应链管理。因为如此多的大型工程、施工和基础设施建设项目都由多家跨国承包商来完成,材料物流管理对于项目成功完成至关重要。对采购周期较长的产品,制造环节和运输(到项目现场)环节都是项目进度的决定因素。在 IT 领域,有些产品可能需要提前 2 至 3 个月订购;在复杂的施工项目上,订购时间可能需要提前 1-2 年,甚至更长。在这些项目上,可能需要在签订其他采购合同之前就采购这些订购周期长的产品,以便项目如期完成。在最终产品的最终设计完成之前,就可能需要根据总体设计中已确定的要求开始订购采购周期较长的材料、用品或设备。供应链管理也是承包商的项目团队日益重视的一个领域。在项目早期,不仅要明确主要的采购渠道,通常还需要明确次要和备选渠道。全球很多国家会要求跨国承包商至少向当地供应商采购一定比例的材料和用品。
  • 技术和相关方关系。公共资助的项目正受越来越多的关注。基础设施和商业建设项目正日益采用包括网络摄像(webcams)在内的技术,以改善与相关方的沟通和关系。在施工期间,施工现场会安装一台或多台网络摄像机,定期更新并发布到公开的网站上,方便所有相关方在互联网上查看项目进展。另外,视频资料可以储存,有助于在索赔发生时进行分析。有些项目显示,使用网络摄像机记录现场情况,能够避免对事实的分歧,从而能够把与现场施工有关的争议降到最低程度。
  • 试用采购。并非每一个卖方都能很好地适应买方组织的环境,因此,在决定大批量采购之前,有些项目会试用多个候选卖方,向他们采购少量的可交付成果和工作产品。这样一来,买方可以在推进项目工作的同时,对潜在合作伙伴进行评估。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目采购管理过程。裁剪时应考虑的因素包括(但不限于):

  • 采购的复杂性。只开展一次主要的采购,或者需要在不同时间向不同卖方进行多次采购(会提高采购的复杂性)?
  • 物理地点。买方和卖方在同一或邻近地点,或者位于不同时区、国家或大洲?
  • 治理和法规环境。组织的采购政策是否和当地相关的法律法规兼容?当地的法律法规会如何影响合同审计工作?
  • 承包商的可用性。是否有具备工作执行能力的承包商可供选择?

在敏捷或适应型环境中需要考虑的因素在敏捷型环境中,可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型,让买方和卖方共担项目风险和共享项目奖励。

在大型项目上,可能针对某些可交付成果采用适应型方法,而对其他部分则采用更稳定的方法。

在这种情况下,可以通过主体协议,如主要服务协议(MSA),来管辖整体协作关系,而将适应型工作写入附录或补充文件。这样一来,变更只针对适应型工作,而不会对主体协议造成影响。

规划采购管理是记录项目采购决策、明确采购方法,及识别潜在卖方的过程。本过程的主要作用是,确定是否从项目外部获取货物和服务,如果是,则还要确定将在什么时间、以什么方式获取什么货物和服务。货物和服务可从执行组织的其他部门采购,或者从外部渠道采购。本过程仅开展一次或仅在项目的预定义点开展。图 12-2 描述本过程的输入、工具与技术和输出。图 12-3 是本过程的数据流向图。

图 12-2规划采购:输入、工具与技术和输出

图 12-3规划采购管理的数据流向图

应该在规划采购管理过程的早期,确定与采购有关的角色和职责。项目经理应确保在项目团队中配备具有所需采购专业知识的人员。采购过程的参与者可能包括购买部或采购部的人员,以及采购组织法务部的人员。这些人员的职责也应记录在采购管理计划中。

典型的步骤可能有:

  • 准备采购工作说明书 (SOW) 或工作大纲 (TOR);
  • 准备高层级的成本估算,制定预算;
  • 发布招标广告;
  • 确定合格卖方的短名单;
  • 准备并发布招标文件;
  • 由卖方准备并提交建议书;
  • 对建议书开展技术(包括质量)评估;
  • 对建议书开展成本评估;
  • 准备最终的综合评估报告(包括质量及成本),选出中标建议书;
  • 结束谈判,买方和卖方签署合同。

项目进度计划对规划采购管理过程中的采购策略制定有重要影响。在制定采购管理计划时所做出的决定也会影响项目进度计划。在开展制定进度计划过程、估算活动资源过程以及自制或外购决策制定时,都需要考虑这些决定。

组织使用的各种合同协议类型也会影响规划采购管理过程中的决策。能够影响规划采购管理过程的组织过程资产包括(但不限于):

  • 预先批准的卖方清单。经过适当审查的卖方清单可以简化招标所需的步骤,并缩短卖方甄选过程的时间。
  • 正式的采购政策、程序和指南。大多数组织都有正式的采购政策和采购机构。如果没有,项目团队就应该配备相关的资源和专业技能,来实施采购活动。
  • 合同类型。所有法律合同关系通常可分为总价和成本补偿两大类。此外,还有第三种常用的混合类型,即工料合同。下文将分别讨论上述几类较常用的合同类型。但在实践中,单次采购合并使用两种或更多合同类型的情况也并不罕见。
  • 总价合同。此类合同为既定产品、服务或成果的采购设定一个总价。这种合同应在已明确定义需求,且不会出现重大范围变更的情况下使用。总价合同的类型包括:

mm固定总价 (FFP)。FFP 是最常用的合同类型。大多数买方都喜欢这种合同,因为货物采购的价格在一开始就已确定,并且不允许改变(除非工作范围发生变更)。

mm总价加激励费用 (FPIF)。这种总价合同为买方和卖方提供了一定的灵活性,允许一定的绩效偏离,并对实现既定目标给予相关的财务奖励(通常取决于卖方的成本、进度或技术绩效)。FPIF 合同中会设置价格上限,高于此价格上限的全部成本将由卖方承担。

mm总价加经济价格调整 (FPEPA)。这种合同适用于两种情况:卖方履约期将跨越几年时间,或将以不同货币支付价款。它是总价合同的一种类型,但合同中包含了特殊条款,允许根据条件变化,如通货膨胀、某些特殊商品的成本增加(或降低),以事先确定的方式对合同价格进行最终调整。

  • 成本补偿合同。此类合同向卖方支付为完成工作而发生的全部合法实际成本(可报销成本),外加一笔费用作为卖方的利润。这种合同适用于:工作范围预计会在合同执行期间发生重大变更。成本补偿合同又可分为:
  • 成本加固定费用 (CPFF)。为卖方报销履行合同工作所发生的一切可列支成本,并向卖方支付一笔固定费用。该费用以项目初始估算成本的某一百分比计列。除非项目范围发生变更,否则费用金额维持不变。
  • 成本加激励费用 (CPIF)。为卖方报销履行合同工作所发生的一切可列支成本,并在卖方达到合同规定的绩效目标时,向卖方支付预先确定的激励费用。在 CPIF 合同中,如果最终成本低于或高于原始估算成本,则买方和卖方需要根据事先商定的成本分摊比例来分享节约部分或分担超支部分。例如,基于卖方的实际成本,按照 80/20 的比例分担(分享)超过(低于)目标成本的部分。
  • 成本加奖励费用 (CPAF)。为卖方报销一切合法成本,但只有在卖方满足合同规定的、某些笼统主观的绩效标准的情况下,才向卖方支付大部分费用。奖励费用完全由买方根据自己对卖方绩效的主观判断来决定,并且通常不允许申诉。
  • 工料合同 (T&M)。工料合同(又称时间和手段合同),是兼具成本补偿合同和总价合同特点的混合型合同。这种合同往往适用于:在无法快速编制出准确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持。

适用于本过程的数据分析技术包括(但不限于)自制或外购分析。自制或外购分析用于确定某项工作或可交付成果最好由项目团队自行完成,还是应该从外部采购。制定自制或外购决策时应考虑的因素包括;组织当前的资源配置及其技能和能力,对专业技术的需求,不愿承担永久雇用的义务,以及对独特技术专长的需求;还要评估与每个自制或外购决策相关的风险。

在自制或外购分析中,可以使用回收期、投资回报率(ROI)、内部报酬率 (IRR)、现金流贴现、净现值(NPV)、收益成本(BCA)或其他分析技术,来确定某种货物或服务是应该在项目内部自制,还是从外部购买。

采购管理计划包含要在采购过程中开展的各种活动。它应该记录是否要开展国际竞争性招标、国内竞争性招标、当地招标等。如果项目由外部资助,资金的来源和可用性应符合采购管理计划和项目进度计划的规定。

采购管理计划可包括以下内容:

  • 如何协调采购与项目的其他工作,例如,项目进度计划制定和控制;
  • 开展重要采购活动的时间表;
  • 用于管理合同的采购测量指标;
  • 与采购有关的相关方角色和职责;如果执行组织有采购部,项目团队拥有的职权和受到的限制;
  • 可能影响采购工作的制约因素和假设条件;
  • 司法管辖权和付款货币;
  • 是否需要编制独立估算,以及是否应将其作为评价标准;
  • 风险管理事项,包括对履约保函或保险合同的要求,以减轻某些项目风险;
  • 拟使用的预审合格的卖方(如果有)。

根据每个项目的需要,采购管理计划可以是正式或非正式的,非常详细或高度概括的。

一旦完成自制或外购分析,并决定从项目外部渠道采购,就应制定一套采购策略。应该在采购策略中规定项目交付方法、具有法律约束力的协议类型,以及如何在采购阶段推动采购进展。

  • 交付方法。对专业服务项目和建筑施工项目,应该采用不同的交付方法。
  • 专业服务项目的交付方法包括:买方或服务提供方不得分包、买方或服务提供方可以分包、买方和服务提供方设立合资企业、买方或服务提供方仅充当代表。
  • 而工业或商业施工项目的交付方法包括(但不限于):交钥匙式、设计-建造 (DB)、设计-招标-建造 (DBB)、设计-建造-运营 (DBO)、建造-拥有-运营-转让 (BOOT),及其他。
  • 合同支付类型。合同支付类型与项目交付方法无关,需要与采购组织的内部财务系统相协调。

它们包括(但不限于)以下合同类型及其变种:总价、固定总价、成本加奖励费用、成本加激励费用、工料、目标成本及其他。

  • 总价合同适用于工作类型可预知、需求能清晰定义且不太可能变更的情况;
  • 成本补偿合同适用于工作不断演进、很可能变更或未明确定义的情况;
  • 激励和奖励费用可用于协调买方和卖方的目标。
  • 采购阶段。采购策略也可以包括与采购阶段有关的信息,这种信息可能包括:
  • 采购工作的顺序安排或阶段划分,每个阶段的描述,以及每个阶段的具体目标;
  • 用于监督的采购绩效指标和里程碑;
  • 从一个阶段过渡到下一个阶段的标准;
  • 用于追踪采购进展的监督和评估计划;
  • 向后续阶段转移知识的过程。

在确定评估标准时,买方要努力确保选出的建议书将提供最佳质量的所需服务。供方选择标准可包括(但不限于):

  • 能力和潜能;
  • 产品成本和生命周期成本;
  • 交付日期;
  • 技术专长和方法;
  • 具体的相关经验;
  • 用于响应工作说明书的工作方法和工作计划;
  • 关键员工的资质、可用性和胜任力;
  • 公司的财务稳定性;
  • 管理经验;
  • 知识转移计划,包括培训计划。

针对国际项目,评估标准还可包括“本地内容”要求,例如,在提议的关键员工中要有本国人。

针对不同的标准,可以用数值分数、颜色代码或书面描述,来说明卖方满足采购组织需求的程度。这些标准是加权系统的组成部分,可据此以加权打分的方法排列所有建议书的顺序,以便确定谈判的顺序,并与某个卖方签订合同。

对于大型的采购,采购组织可以自行准备独立估算,或聘用外部专业估算师做出成本估算,并将其作为评价卖方报价的对照基准。如果二者之间存在明显差异,则可能表明采购工作说明书存在缺陷或模糊,或者潜在卖方误解了或未能完全响应采购工作说明书。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册,记录任何与法规和合规性、数据收集、数据分析和供方选择分析相关的经验教训。
  • 里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
  • 需求文件。见 5.2.3.1 节。需求文件可能包括:
  • 卖方需要满足的技术要求;
  • 具有合同和法律意义的需求,如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证,以及其他非技术要求。
  • 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
  • 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型,以及最终商定的价格,任何被选中的卖方都会带来特殊的风险。
  • 相关方登记册。见 13.1.3.1 节。更新相关方登记册,记录任何关于相关方的补充信息,尤其是监管机构、合同签署人员,以及法务人员的信息。

作为规划采购管理过程的结果,需要更新的组织过程资产包括(但不限于)关于合格卖方的信息。

对于采购次数少且相对简单的项目,作为本过程输出的有些文件可以合并。不过,对于采购规模较大、较复杂,而且大部分工作需由承包商完成的项目,就需要使用几种不同类型的文件。表 12-1 列出了采购中常用的文件类型及其部分内容。鉴于采购的法律性质,不应把表 12-1 的内容看成规定性描述,而只应该把它们看成关于所需文件的类型和内容的总体大纲,用于指导实施采购工作。组织、环境和法律规定会决定项目具体需要的文件类型和内容。

表 12-1采购文件比较

可作为本过程输入的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。在项目早期获取的与实施采购有关的经验教训,可用于项目后期阶段,以提高本过程的效率。
  • 项目进度计划。见 6.5.3.2 节。项目进度计划确定项目活动的开始和结束日期,包括采购活动。

它还会规定承包商最终的交付日期。

  • 需求文件。见 5.2.3.1 节。需求文件可能包括:
  • 卖方需要满足的技术要求;
  • 具有合同和法律意义的需求,如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证,以及其他非技术要求。
  • 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型,以及最终商定的价格,任何被选中的卖方都会带来特殊的风险。
  • 相关方登记册。见 13.1.3.1 节。此文件包含与已识别相关方有关的所有详细信息。

卖方为响应采购文件包而编制的建议书,其中包含的基本信息将被评估团队用于选定一个或多个投标人(卖方)。如果卖方将提交价格建议书,最好要求他们将价格建议书与技术建议书分开。

评估团队会根据供方选择标准审查每一份建议书,然后选出最能满足采购组织需求的卖方。

能够影响实施采购过程的组织过程资产包括(但不限于):

  • 预审合格的优先卖方清单;
  • 会影响卖方选择的组织政策;
  • 组织中关于协议起草及签订的具体模板或指南;
  • 关于付款申请和支付过程的财务政策和程序。

选定的卖方是在建议书评估或投标评估中被判断为最有竞争力的投标人。对于较复杂、高价值和高风险的采购,在授予合同前,要把选定的卖方报给组织高级管理人员审批。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 需求管理计划。见 5.1.3.2 节。项目需求可能因卖方的要求而变更。
  • 质量管理计划。见 8.1.3.1 节。卖方可能提出备选质量标准或备选解决方案,从而影响质量管理计划中规定的质量管理方法。
  • 沟通管理计划。见 10.1.3.1 节。在选定卖方后,需要更新沟通管理计划,记录卖方的沟通需求和方法。
  • 风险管理计划。见 11.1.3.1 节。每个协议和卖方都会带来独特的风险,从而需要更新风险管理计划。具体的风险应该记录到风险登记册中。
  • 采购管理计划。见 12.1.3.1 节。可能需要基于合同谈判和签署的结果,而更新采购管理计划。
  • 范围基准。见 5.4.3.1 节。在执行采购活动时,需明确考虑范围基准中的项目工作分解结构和可交付成果。本过程可能导致对任何一个或全部可交付成果的变更。
  • 进度基准。见 6.5.3.1 节。如果卖方交付成果方面的变更影响了项目的整体进度绩效,则可能需要更新并审批基准进度计划,以反映当前的期望。
  • 成本基准。见 7.3.3.1 节。在项目交付期间,承包商的材料价格和人力价格可能随外部经济环境而频繁变动。这种变动需要反映到成本基准中。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册,记录在实施采购期间所遇到的挑战、本可采取的规避方法,以及有效的方法。
  • 需求文件。见 5.2.3.1 节。需求文件可能包括:
  • 卖方需要满足的技术要求;
  • 具有合同和法律意义的需求,如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证,以及其他非技术要求。
  • 需求跟踪矩阵。见 5.2.3.2 节。随着将卖方纳入项目计划,可能需要根据特定卖方的能力,变更需求登记册及跟踪矩阵。
  • 资源日历。见 9.2.1.2 节。可能需要根据卖方的可用性更新与进度计划有关的资源日历。
  • 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型,以及最终商定的价格,每个被选中的卖方都会带来特殊的风险。在合同签署过程中,应该对风险登记册进行变更,以反映每个卖方带来的具体风险。
  • 相关方登记册。见 13.1.3.1 节。此文件包含与已识别相关方有关的所有详细信息。 与具体卖方签订协议后,需要更新相关方登记册。

可在实施采购过程更新的组织过程资产包括:

  • 潜在和预审合格的卖方清单;
  • 与卖方合作的相关经验,包括正反两方面。

控制采购是管理采购关系,监督合同绩效,实施必要的变更和纠偏,以及关闭合同的过程。本过程的主要作用是,确保买卖双方履行法律协议,满足项目需求。本过程应根据需要在整个项目期间开展。图 12-6 描述本过程的输入、工具与技术和输出,图 12-7 是本过程的数据流向图。

图 12-6控制采购:输入、工具与技术和输出

• Projectcharter图 12-7控制采购:数据流向图

买方和卖方都出于相似的目的来管理采购合同,每方都必须确保双方履行合同义务,确保各自的合法权利得到保护。合同关系的法律性质,要求项目管理团队必须了解在控制采购期间所采取的任何行动的法律后果。对于有多个供应商的较大项目,合同管理的一个重要方面就是管理各个供应商之间的沟通。

鉴于其法律意义,很多组织都将合同管理视为独立于项目的一种组织职能。虽然采购管理员可以是项目团队成员,但通常还向另一部门的经理报告。

在控制采购过程中,需要把适当的项目管理过程应用于合同关系,并且需要整合这些过程的输出,以用于对项目的整体管理。如果涉及多个卖方,以及多种产品、服务或成果,就往往需要在多个层级上开展这种整合。

合同管理活动可能包括:

  • 收集数据和管理项目记录,包括维护对实体和财务绩效的详细记录,以及建立可测量的采购绩效指标;
  • 完善采购计划和进度计划;
  • 建立与采购相关的项目数据的收集、分析和报告机制,并为组织编制定期报告;
  • 监督采购环境,以便引导或调整实施;
  • 向卖方付款。

控制措施的质量,包括采购审计的独立性和可信度,是采购系统可靠性的关键决定因素。组织的道德规范、内部法律顾问和外部法律咨询,包括持续的反腐计划,都有助于实现适当的采购控制。

在控制采购过程中,需要开展财务管理工作,包括监督向卖方付款。这是要确保合同中的支付条款得到遵循,确保按合同规定,把付款与卖方的工作进展联系起来。需要重点关注的一点是,确保向卖方的付款与卖方实际已经完成的工作量之间有密切的关系。如果合同规定了基于项目输出及可交付成果来付款,而不是基于项目输入(如工时),那么就可以更有效地开展采购控制。

在合同收尾前,若双方达成共识,可以根据协议中的变更控制条款,随时对协议进行修改。通常要书面记录对协议的修改。

可作为本过程输入的项目文件包括(但不限于):

  • 假设日志。见 4.1.3.2 节。假设日志记录了采购过程中做出的假设。
  • 经验教训登记册。见 4.4.3.1 节。在项目早期获取的经验教训可供项目未来使用,以改进承包商绩效和采购过程。
  • 里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
  • 质量报告。见 8.2.3.1 节。质量报告用于识别不合规的卖方过程、程序或产品。
  • 需求文件。见 5.2.3.1 节。需求文件可能包括:
  • 卖方需要满足的技术要求;
  • 具有合同和法律意义的需求,如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证,以及其他非技术要求。
  • 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
  • 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型,以及最终商定的价格,每个被选中的卖方都会带来特殊的风险。
  • 相关方登记册。见 13.1.3.1 节。相关方登记册包括关于已识别相关方的信息,例如,合同团队成员、选定的卖方、签署合同的专员,以及参与采购的其他相关方。

能够影响控制采购过程的事业环境因素包括(但不限于):

  • 合同变更控制系统;
  • 市场条件;
  • 财务管理和应付账款系统;
  • 采购组织的道德规范。

能够影响控制采购过程的组织过程资产包括(但不限于)采购政策。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 风险管理计划。见 11.1.3.1 节。每个协议和卖方都会带来独特的风险,因此可能需要更新风险管理计划。如果在执行合同期间发生重大的意外风险,则风险管理计划可能需要更新。应该把具体的风险记录到风险登记册中。
  • 采购管理计划。见 12.1.3.1 节。采购管理计划包含在采购过程中需要开展的活动。可能需要基于卖方执行工作的绩效情况,对采购管理计划进行更新。
  • 进度基准。见 6.5.3.1 节。如果卖方的重大进度变更影响到了项目的整体进度绩效,则可能需要更新并审批基准进度计划,以反映当前的期望。买方应该注意某个卖方的进度拖延,可能对其他卖方的工作造成连锁影响。
  • 成本基准。见 7.3.3.1 节。在项目交付期间,承包商的材料价格和人力价格可能随外部经济环境而频繁变动。这种变动需要反映到成本基准中。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册,记录能有效维护采购工作的范围、进度和成本的技术。对于出现的偏差,经验教训登记册应该记录曾采取的纠正措施及其有效性。

如果已经发生索赔,则应记录相关信息以避免重蹈覆辙,其他关于如何改善采购过程的信息也应记录在内。

  • 资源需求。见 9.2.3.1 节。随着承包商的工作进展,可能因工作执行不符合原定计划而需要变更资源需求。
  • 需求跟踪矩阵。见 5.2.3.2 节。更新需求跟踪矩阵,记录已实现的需求。
  • 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型,以及最终商定的价格,每个被选中的卖方都会带来特殊的风险。随着早期风险的过时以及新风险的出现,在项目执行期间对风险登记册进行变更。
  • 相关方登记册。见 13.1.3.1 节。随着执行阶段的工作进展,承包商和供应商可能发生变更,应该把承包商和供应商的变更情况记录在相关方登记册中。

作为控制采购过程的结果,需要更新的组织过程资产包括(但不限于):

  • 支付计划和请求。所有支付都应按合同条款和条件进行。
  • 卖方绩效评估文件。卖方绩效评估文件由买方准备,用于记录卖方继续执行当前合同工作的能力,说明是否允许卖方承接未来的项目,或对卖方现在的项目执行工作或过去的执行工作进行评级。
  • 预审合格卖方清单更新。预审合格卖方清单是以前已经通过资格审查(获得批准)的潜在卖方的清单。因为卖方可能因绩效不佳而被取消资格并从清单中删除,所以应该根据控制采购过程的结果来更新这个清单。
  • 经验教训知识库。经验教训应该归档到经验教训知识库中,以改善未来项目的采购工作。在合同执行终了时,应把采购的实际成果与原始采购管理计划中的预期成果进行比较。应该在经验教训中说明项目目标是否达成;若未达成,则说明原因。
  • 采购档案。应该准备好带索引的全套合同文档,包括已关闭的合同,并将其纳入最终的项目档案。

项目相关方管理包括用于开展下列工作的各个过程:识别能够影响项目或会受项目影响的人员、团体或组织,分析相关方对项目的期望和影响,制定合适的管理策略来有效调动相关方参与项目决策和执行。用这些过程分析相关方期望,评估他们对项目或受项目影响的程度,以及制定策略来有效引导相关方支持项目决策、规划和执行。这些过程能够支持项目团队的工作。

项目相关方管理的过程是:

13.1 识别相关方 — 识别相关方是定期识别项目相关方,分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。

13.2 规划相关方参与 — 规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响,制定项目相关方参与项目的方法的过程。

13.3 管理相关方参与 — 管理相关方参与是与相关方进行沟通和协作,以满足其需求与期望,处理问题,并促进相关方合理参与的过程。

13.4 监督相关方参与 — 监督项目相关方关系,并通过修订参与策略和计划来引导相关方合理参与项目的过程。

图 13-1 概括了项目相关方管理的各个过程。虽然在本《PMBOK® 指南》中,各项目相关方管理过

程以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 13-1项目相关方管理概述

项目相关方管理的核心概念每个项目都有相关方,他们会受项目的积极或消极影响,或者能对项目施加积极或消极的影响。

有些相关方影响项目工作或成果的能力有限,而有些相关方可能对项目及其期望成果有重大影响。

关于重大项目灾难的学术研究及分析强调了结构化方法对识别所有相关方、进行相关方优先级排序,以及引导相关方参与的重要性。项目经理和团队正确识别并合理引导所有相关方参与的能力,能决定着项目的成败。为提高成功的可能性,应该在项目章程被批准、项目经理被委任,以及团队开始组建之后,尽早开始识别相关方并引导相关方参与。

相关方满意度应作为项目目标加以识别和管理。有效引导相关方参与的关键是重视与所有相关方保持持续沟通(包括团队成员),以理解他们的需求和期望、处理所发生的问题、管理利益冲突,并促进相关方参与项目决策和活动。

为了实现项目收益,识别相关方和引导相关方参与的过程需要迭代开展。虽然在项目相关方管理中仅对这些过程讨论一次,但是,应该经常开展识别相关方、排列其优先级以及引导其参与等活动。至少要在以下时点开展这些活动:

  • 项目进入其生命周期的不同阶段;
  • 当前相关方不再与项目工作有关,或者在项目的相关方社区中出现了新的相关方成员;
  • 组织内部或更大区域的相关方社区发生重大变化。

项目相关方管理的发展趋势和新兴实践“ 相关方”一词的外延正在扩大,从传统意义上的员工、供应商和股东扩展到涵盖各式群体,包括监管机构、游说团体、环保人士、金融组织、媒体,以及那些自认为是相关方的人员(他们认为自己会受项目工作或成果的影响)。

项目相关方管理的发展趋势和新兴实践包括(但不限于):

  • 识别所有相关方,而非在限定范围内;
  • 确保所有团队成员都涉及引导相关方参与的活动;
  • 定期审查相关方社区,往往与单个项目风险的审查并行开展;
  • 应用“共创”概念,咨询最受项目工作或成果影响的相关方。该概念的重点是,将团队内受影响的相关方视为合作伙伴。
  • 关注与相关方有效参与程度有关的正面及负面价值。正面价值是相关方(尤其是强大相关方)对项目的更积极支持所带来的效益;负面价值是因相关方未有效参与而造成的真实成本,包括产品召回、组织信誉损失或项目信誉损失。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目相关方管理过程。裁剪时应考虑的因素包括(但不限于):

  • 相关方多样性。现有多少相关方?相关方群体中的文化多样性如何?
  • 相关方关系的复杂性。相关方社区内的关系有多复杂?相关方或相关方群体加入的网络越多,与其相关的信息或误传网络就越复杂。
  • 沟通技术。有哪些可用的沟通技术?为了实现技术的最大价值,目前采用怎样的支持机制?

在敏捷或适应型环境中需要考虑的因素高度变化的项目更需要项目相关方的有效互动和参与。为了开展及时且高效的讨论及决策,适应型团队会直接与相关方互动,而不是通过层层的管理级别。客户、用户和开发人员在动态的共创过程中交换信息,通常能实现更高的相关方参与和满意程度。在整个项目期间保持与相关方社区的互动,有利于降低风险、建立信任和尽早做出项目调整,从而节约成本,提高项目成功的可能性。

为加快组织内部和组织之间的信息分享,敏捷型方法提倡高度透明。例如,邀请所有相关方参与项目会议和审查,或将项目工件发布到公共空间,其目的在于让各方之间的不一致和依赖关系,或者与不断变化的项目有关的其他问题,都尽快浮现。

识别相关方是定期识别项目相关方,分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。本过程的主要作用是,使项目团队能够建立对每个相关方或相关方群体的适度关注。本过程应根据需要在整个项目期间定期开展。图 13-2 描述本过程的输入、工具与技术和输出。图 13-3 是本过程的数据流向图。

图 13-2识别相关方:输入、工具与技术和输出

图 13-3识别相关方:数据流向图

本过程通常在编制和批准项目章程之前或同时首次开展。本过程需在必要时重复开展,至少应在每个阶段开始时,以及项目或组织出现重大变化时重复开展。每次重复开展本过程,都应通过查阅项目管理计划组件及项目文件,来识别有关的项目相关方。

• Projectcharter

能够影响识别相关方过程的事业环境因素包括(但不限于):

  • 组织文化、政治氛围,以及治理框架;
  • 政府或行业标准(法规、产品标准和行为规范);
  • 全球、区域或当地的趋势、实践或习惯;
  • 设施和资源的地理分布。

能够影响识别相关方过程的组织过程资产包括(但不限于):

  • 相关方登记册模板和说明;
  • 以往项目的相关方登记册;
  • 经验教训知识库,包括与相关方偏好、行动和参与有关的信息。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:

  • 理解组织内的政治和权力结构;
  • 了解所在组织和其他受影响组织(包括客户及其他组织)的环境和文化;
  • 了解项目所在行业或项目可交付成果类型;
  • 了解个体团队成员的贡献和专长。

适用于本过程的数据分析技术包括(但不限于):

  • 相关方分析。相关方分析会产生相关方清单和关于相关方的各种信息,例如,在组织内的位置、在项目中的角色、与项目的利害关系、期望、态度(对项目的支持程度),以及对项目信息的兴趣。相关方的利害关系可包括(但不限于)以下各条的组合:
  • 兴趣。个人或群体会受与项目有关的决策或成果的影响。
  • 权利(合法权利或道德权利)。国家的法律框架可能已就相关方的合法权利做出规定,如职业健康和安全。道德权利可能涉及保护历史遗迹或环境的可持续性。
  • 所有权。人员或群体对资产或财产拥有的法定所有权。
  • 知识。专业知识有助于更有效地达成项目目标和组织成果,或有助于了解组织的权力结构,从而有益于项目。
  • 贡献。提供资金或其他资源,包括人力资源,或者以无形方式为项目提供支持,例如,宣传项目目标,或在项目与组织权力结构及政治之间扮演缓冲角色。
  • 文件分析。见 5.2.2.3 节。评估现有项目文件及以往项目的经验教训,以识别相关方和其他支持性信息。

适用于本过程的数据表现技术包括(但不限于)相关方映射分析/表现。相关方映射分析和表现是一种利用不同方法对相关方进行分类的方法。对相关方进行分类有助于团队与已识别的项目相关方建立关系。常见的分类方法包括:

  • 权力利益方格、权力影响方格,或作用影响方格。基于相关方的职权级别(权力)、对项目成果的关心程度(利益)、对项目成果的影响能力(影响),或改变项目计划或执行的能力,每一种方格都可用于对相关方进行分类。对于小型项目、相关方与项目的关系很简单的项目,或相关方之间的关系很简单的项目,这些分类模型非常实用。
  • 相关方立方体。这是上述方格模型的改良形式。本立方体把上述方格中的要素组合成三维模型,项目经理和团队可据此分析相关方并引导相关方参与项目。作为一个多维模型,它将相关方视为一个多维实体,更好地加以分析,从而有助于沟通策略的制定。
  • 凸显模型。通过评估相关方的权力(职权级别或对项目成果的影响能力)、紧迫性(因时间约束或相关方对项目成果有重大利益诉求而导致需立即加以关注)和合法性(参与的适当性),对相关方进行分类。在凸显模型中,也可以用邻近性取代合法性,以便考察相关方参与项目工作的程度。这种凸显模型适用于复杂的相关方大型社区,或在相关方社区内部存在复杂的关系网络。凸显模型可用于确定已识别相关方的相对重要性。
  • 影响方向。可以根据相关方对项目工作或项目团队本身的影响方向,对相关方进行分类。可以把相关方分类为:
  • 向上(执行组织或客户组织、发起人和指导委员会的高级高级管理层);
  • 向下(临时贡献知识或技能的团队或专家);
  • 向外(项目团队外的相关方群体及其代表,如供应商、政府部门、公众、最终用户和监管部门);或nn横向(项目经理的同级人员,如其他项目经理或中层管理人员,他们与项目经理竞争稀缺项目资源或者合作共享资源或信息)。
  • 优先级排序。如果项目有大量相关方、相关方社区的成员频繁变化,相关方和项目团队之间或相关方社区内部的关系复杂,可能有必要对相关方进行优先级排序。

相关方登记册是识别相关方过程的主要输出。它记录关于已识别相关方的信息,包括(但不限于):

  • 身份信息。姓名、组织职位、地点、联系方式,以及在项目中扮演的角色。
  • 评估信息。主要需求、期望、影响项目成果的潜力,以及相关方最能影响或冲击的项目生命周期阶段。
  • 相关方分类。用内部或外部,作用、影响、权力或利益,上级、下级、外围或横向,或者项目经理选择的其他分类模型,进行分类的结果。

在项目初始时识别相关方,不会导致项目管理计划更新。但随着项目进展,项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 需求管理计划。见 5.1.1.2 节。新识别的相关方可能会影响规划、跟踪和报告需求活动的方式。
  • 沟通管理计划。见 10.1.3.1 节。沟通管理计划记录相关方的沟通要求和已商定的沟通策略。
  • 风险管理计划。见 11.1.3.1 节。如果相关方的沟通要求和已商定的沟通策略会影响管理项目风险的方法,就应在风险管理计划中加以反映。
  • 相关方参与计划。见 13.2.3.1 节。相关方参与计划记录针对已识别相关方的商定的沟通策略。

规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响,制定项目相关方参与项目的方法的过程。本过程的主要作用是,提供与相关方进行有效互动的可行计划。本过程应根据需要在整个项目期间定期开展。

图 13-4 描述本过程的输入、工具与技术和输出。图 13-5 是本过程的数据流向图。

图 13-4规划相关方参与:输入、工具与技术和输出

图 13-5规划相关方参与:数据流向图

• Projectcharter为满足项目相关方的多样性信息需求,应该在项目生命周期的早期制定一份有效的计划;然后,随着相关方社区的变化,定期审查和更新该计划。在通过识别相关方过程明确最初的相关方社区之后,就应该编制第一版的相关方参与计划,然后定期更新相关方参与计划,以反映相关方社区的变化。会触发该计划更新的典型情况包括(但不限于):

  • 项目新阶段开始;
  • 组织结构或行业内部发生变化;
  • 新的个人或群体成为相关方,现有相关方不再是相关方社区的成员,或特定相关方对项目成功的重要性发生变化;
  • 当其他项目过程(如变更管理、风险管理或问题管理)的输出导致需要重新审查相关方参与策略。

这些情况都可能导致已识别相关方的相对重要性发生变化。

见 12.2.3.2 节。在规划承包商及供应商参与时,通常涉及与组织内的采购小组和(或)合同签署小组开展合作,以确保对承包商和供应商进行有效管理。

能够影响规划相关方参与的事业环境因素包括(但不限于):

  • 组织文化、政治氛围,以及治理框架;
  • 人事管理政策;
  • 相关方风险偏好;
  • 已确立的沟通渠道;
  • 全球、区域或当地的趋势、实践或习惯;
  • 设施和资源的地理分布。

能够影响规划相关方参与过程的组织过程资产包括(但不限于):

  • 企业的社交媒体、道德和安全政策及程序;
  • 企业的问题、风险、变更和数据管理政策及程序;
  • 组织对沟通的要求;
  • 制作、交换、储存和检索信息的标准化指南;
  • 经验教训知识库,包括与相关方偏好、行动和参与有关的信息;
  • 支持有效相关方参与所需的软件工具。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:

  • 组织内部及外部的政治和权力结构;
  • 组织及组织外部的环境和文化;
  • 相关方参与过程使用的分析和评估技术;
  • 沟通手段和策略;
  • 来自以往项目的关于相关方、相关方群体及相关方组织(他们可能参与过以往的类似项目)的特征的知识。

适用于本过程的数据收集技术包括(但不限于)标杆对照。见 8.1.2.2 节。将相关方分析的结果与其他被视为世界级的组织或项目的信息进行比较。

适用于本过程的数据表现技术包括(但不限于):

  • 思维导图。见 5.2.2.3 节。思维导图用于对相关方信息、相互关系以及他们与组织的关系进行可视化整理。
  • 相关方参与度评估矩阵。相关方参与度评估矩阵用于将相关方当前参与水平与期望参与水平进行比较。对相关方参与水平进行分类的方式之一,如图 13-6 所示。相关方参与水平可分为如下:
  • 不了解型。不知道项目及其潜在影响。
  • 抵制型。知道项目及其潜在影响,但抵制项目工作或成果可能引发的任何变更。此类相关方不会支持项目工作或项目成果。
  • 中立型。了解项目,但既不支持,也不反对。
  • 支持型。了解项目及其潜在影响,并且会支持项目工作及其成果。
  • 领导型。了解项目及其潜在影响,而且积极参与以确保项目取得成功。

在图 13-6 中,C 代表每个相关方的当前参与水平,而 D 是项目团队评估出来的、为确保项目成功所必不可少的参与水平(期望的)。应根据每个相关方的当前与期望参与水平的差距,开展必要的沟通,有效引导相关方参与项目。弥合当前与期望参与水平的差距是监督相关方参与中的一项基本工作。

图 13-6相关方参与度评估矩阵

能够影响管理相关方参与的事业环境因素包括(但不限于):

  • 组织文化、政治氛围,以及组织的治理结构;
  • 人事管理政策;
  • 相关方风险临界值;
  • 已确立的沟通渠道;
  • 全球、区域或当地的趋势、实践或习惯;
  • 设施和资源的地理分布。

能够影响管理相关方参与过程的组织过程资产包括(但不限于):

  • 企业的社交媒体、道德和安全政策及程序;
  • 企业的问题、风险、变更和数据管理政策及程序;
  • 组织对沟通的要求;
  • 制作、交换、储存和检索信息的标准化指南;
  • 以往类似项目的历史信息。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见:

  • 组织内部及外部的政治和权力结构;
  • 组织及组织外部的环境和文化;
  • 相关方参与过程使用的分析和评估技术;
  • 沟通方法和策略;
  • 可能参与过以往类似项目的相关方、相关方群体及相关方组织的特征。
  • 需求管理、供应商管理和变更管理。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 沟通管理计划。见 10.1.3.1 节。需要更新沟通管理计划,以反映新的或已变更的相关方需求。
  • 相关方参与计划。见 13.2.3.1 节。需要更新相关方参与计划,以反映为有效引导相关方参与所需的新的或更改的管理策略。

能够监督相关方参与过程的事业环境因素包括(但不限于):

  • 组织文化、政治氛围,以及治理框架;
  • 人事管理政策;
  • 相关方风险临界值;
  • 已确立的沟通渠道;
  • 全球、区域或当地的趋势、实践或习惯;
  • 设施和资源的地理分布。

能够影响监督相关方参与过程的组织过程资产包括(但不限于):

  • 企业的社交媒体、道德和安全政策及程序;
  • 企业的问题、风险、变更和数据管理政策及程序;
  • 组织对沟通的要求;
  • 制作、交换、储存和检索信息的标准化指南;
  • 以往项目的历史信息。

适用于本过程的人际关系技能包括(但不限于):

  • 积极倾听。见 10.2.2.6 节。通过积极倾听,减少理解错误和沟通错误。
  • 文化意识。见 10.1.2.6 节。文化意识和文化敏感性有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。
  • 领导力。见 3.4.4 节。成功的相关方参与,需要强有力的领导技能,以传递愿景并激励相关方支持项目工作和成果。
  • 人际交往。见 10.2.2.6 节。通过人际交往了解关于相关方参与水平的信息。
  • 政治意识。见 10.1.2.6 节。政治意识有助于理解组织战略,理解谁能行使权力和施加影响,以及培养与这些相关方沟通的能力。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):

  • 资源管理计划。见 9.1.3.1 节。可能需要更新团队对引导相关方参与的职责。
  • 沟通管理计划。见 10.1.3.1 节。可能需要更新项目的沟通策略。
  • 相关方参与计划。见 13.2.3.1 节。可能需要更新关于项目相关方社区的信息。

项目组合是指为实现战略目标而协调管理的项目、项目集和子项目组合和运营工作。项目组合管理是指为了实现战略目标而对一个或多个项目组合进行的集中管理。项目组合管理的重点是确保项目组合与组织的目标保持一致,并且通过评估项目组合组件来优化资源分配。项目组合可能会包含运营性质的工作。

项目集是相互关联且被协调管理的项目、子项目集和项目集活动,以便获得分别管理所无法获得的利益。项目集包括所属单个项目范围之外的相关工作。项目集管理是指应用知识,技能和原则以实现项目集目标,获得分别管理相关项目集组件所无法实现的效益和控制。项目集也可能包含运营性质的工作。

项目集管理通过授权、变更或终止项目以及管理项目间的依赖关系来支持组织战略。管理项目间的依赖关系可能包括以下行动:

  • 解决影响项目集内各组件的资源制约因素和(或)资源冲突;
  • 确保符合对项目集目的和目标有影响的组织战略;
  • 在同一个治理结构内处理相关问题和开展变更管理;
  • 应对可能影响一个或多个组件的项目和项目集风险;
  • 通过有效分析、排序和监督各组件之间的依赖关系来管理项目集效益的实现。

一个项目可以采用三种不同的模式进行管理:作为完全独立的项目(不隶属于任何项目组合或项目集)、作为项目集的组成部分,或作为项目组合的组成部分。如果一个项目是项目组合或项目集的组成部分,那么项目管理就需要与项目组合和项目集管理进行互动。

图 1-1 所示的项目组合结构表明了组件、共享资源和相关方之间的关系。将项目组合组件归组,有

利于促进对工作的有效治理和管理,排列各组件的优先级,并实现组织战略。在开展组织和项目组合规划时,要基于风险、资金和其他考虑因素对项目组合组件排列优先级。这有利于组织全面审查战略目标在项目组合中的落实情况,开展适当的项目组合、项目集和项目治理,以及分配人力、财力或物力资源。这些资源将根据预期的绩效和收益进行分配。如图 1-1 所示,组织战略与优先级相关联,项目组合与项目集之间、项目组合和项目之间以及项目集与单个项目之间都存在联系。但这些联系并不总是存在严格的等级层次。

组织级项目管理 (OPM) 是开展项目组合管理、项目集管理和项目管理的战略执行框架。该框架使组织不断地以可预见的方式取得更好的绩效、更好的结果及可持续的竞争优势,从而实现组织战略。

图 1-1项目组合、项目集与项目管理间的关系示例

治理类型多种多样,包括组织治理、组织级项目管理 (OPM) 治理,以及项目组合、项目集和项目治理。组织治理通过制定政策和流程,用结构化方式指明工作方向并进行控制,以便实现战略和运营目标。组织治理通常由董事会执行,以确保对相关方的最终责任得以落实,并保持公平和透明。组织治理原则、决策和过程可能通过以下方式影响项目组合、项目集和项目的治理:

  • 执行法律、法规、标准和合规性要求;
  • 明确伦理、社会和环境职责;
  • 制定运营、法律和风险政策。

项目治理是指用于指导项目管理活动的框架、功能和过程,从而创造独特的产品、服务或结果以满足组织、战略和运营目标。项目层面的治理包括:

  • 指导和监督对项目工作的管理;
  • 确保遵守政策、标准和指南;
  • 确立治理角色、职责和职权;
  • 关于风险上报、变更和资源(例如团队、财力、物力、设施)的决策;
  • 确保相应相关方的参与;
  • 监督成效。

项目治理框架为项目相关方提供管理项目的结构、过程、角色、职责、终责和决策模型。项目治理框架的内容包括(但不限于)以下原则或过程:

  • 阶段关口或阶段审查;
  • 识别、上报和解决风险及问题;
  • 明确角色、职责和职权;
  • 开展项目知识管理并吸取项目经验教训的过程;
  • 超出项目经理职权的决策制定、问题解决和需上报议题;
  • 审查和批准超出项目经理职权的项目变更及产品变更。

启动项目旨在抓住与组织的战略目标相符的商业机会。在启动项目之前,通常需要编制商业论证,以概述项目目标、所需投资,以及用于测量项目成功的财务标准和其他量化标准。商业论证为在整个项目生命周期中衡量项目成功和进展奠定了基础,以便把实际结果与预定的目标和成功标准进行比较。

项目的启动通常出于以下一项或多项战略考虑:

  • 市场需求;
  • 战略机会/业务需求;
  • 社会需要;
  • 环境考虑;
  • 客户要求;
  • 技术进步;
  • 法律或法规要求;
  • 现有问题或已预见到的问题。

效益管理计划描述项目效益的实现方法和时间及其衡量方式。效益管理计划可能包括以下内容:

  • 目标效益。使用产品、服务或成果而预期获得的有形和无形商业价值。
  • 战略一致性。项目效益如何支持组织的业务战略并与之保持一致。
  • 实现效益的时限。效益按阶段划分,包括:短期效益、长期效益和持续性效益。
  • 效益责任人。在效益实现计划规定的整个时限内,监督、记录和报告效益实现情况的责任个人或小组。
  • 测量指标。用于考核效益实现情况的直接和间接方法。
  • 风险。与实现目标效益有关的风险。

根据项目目标和成功标准考核项目的成功程度。在许多情况下,产品、服务或成果的成功只有在项目完成后一段时间方能知晓。例如,在项目产品、服务或成果交付运营时,市场份额增加、运营成本降低或新产品成功可能都是未知的。在这些情况下,项目管理办公室 (PMO)、项目组合指导委员会或组织内的其他职能部门,应该在稍晚时间才对项目成功进行评估,以确定结果是否符合业务目标。

商业论证和效益管理计划都是在项目启动之前编制的,并且要成为项目完成之后评估项目成功的依据。因此,它们被视为商业文件,而非项目文件,或者项目管理计划的组成部分。这些商业文件可能成为某些项目管理过程的输入,例如,制定项目章程。

项目生命周期指项目从开始到完成所经历的一系列阶段。项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。这些阶段之间可能是顺序、迭代或交叠的关系。项目阶段的名称、数量和持续时间取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。阶段都有时限,有一个起始点、结束点或控制点(有时称为阶段审查、阶段关口或控制关口,也可以用其他类似名称)。在控制点,需要根据当前环境,重新审查项目章程和商业文件。在该时点,把项目绩效与项目管理计划进行比较,以确定项目是否应该变更、终止或按计划继续。

项目生命周期会受组织、行业、开发方法或所用技术的独特性质的影响。虽然每个项目都有起点和终点,但具体的可交付成果及工作会因项目的不同而有很大差异。不论项目涉及的具体工作是什么,生命周期都可以为管理项目提供基本框架。

虽然项目规模及复杂程度各不相同,但是典型项目都呈现下列项目生命周期结构(见图 1-2):

  • 开始项目;
  • 组织与准备;
  • 执行项目工作;
  • 结束项目。

图 1-2项目生命周期的通用结构

通用的生命周期结构一般具有以下特征:

  • 成本与人力投入在开始时较低,在工作执行期间逐渐增加,并在项目快要结束时迅速回落。
  • 项目开始时风险最大,如图 1-3 所示。在项目的整个生命周期中,随着决策的制定与可交付成果的验收,风险会逐步降低。
  • 在不显著影响成本和进度的前提下,相关方改变项目产品最终特性的能力在项目开始时最大,并随项目进展而减弱。图 1-3 表明,做出变更和纠正错误的成本,通常会随着项目越来越接近完成而显著增高。

图 1-3随时间而变化的变量影响

相关方是指可能影响项目决策、活动或结果的个人、群体或组织,以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。项目相关方可能来自项目内部或外部,可能主动或被动参与项目,甚至完全不了解项目。项目相关方可能对项目施加积极或消极影响,也可能受项目的积极或消极影响。相关方包括(但不限于):

  • 内部相关方:
  • 发起人;
  • 资源经理;
  • 项目管理办公室(PMO);
  • 项目组合指导委员会;
  • 项目集经理;
  • 其他项目的项目经理;
  • 团队成员。
  • 外部相关方:
  • 客户;
  • 最终用户;
  • 供应商;
  • 股东;
  • 监管机构;
  • 竞争者。

图 1-4项目相关方示例

图 1-4 为项目相关方的示例。有些相关方只是偶尔参与项目调查或焦点小组活动,有些则为项目提

供全方位资助,包括资金支持、政治支持或其他类型的支持。在整个项目生命周期内,他们参与项目的方式和程度可能差别很大,因此,在整个项目生命周期中,有效识别和分析相关方,引导他们合理参与,并有效管理他们对项目的期望和参与,对项目成功至关重要。

项目经理是指由执行组织委派,领导团队实现项目目标的个人。项目经理的报告关系依组织结构和项目治理而定。

除了具备项目所需的特定技能和通用管理能力,项目经理至少还应具备以下特性:

  • 掌握关于项目管理、商业环境、技术领域和其他方面的知识,以便有效管理特定项目;
  • 具备有效领导项目团队、协调项目工作、与相关方协作、解决问题和做出决策所需的技能;
  • 形成编制项目计划(包括范围、进度、预算、资源、风险计划等)、管理项目工作,以及开展陈述和报告的能力;
  • 拥有成功管理项目所需的其他特性,如个性、态度、道德和领导力。

项目经理通过项目团队和其他相关方来完成工作。项目经理需要依赖重要的人际关系技能,包括(但不限于):

  • 领导力;
  • 团队建设;
  • 激励;
  • 沟通;
  • 影响力;
  • 决策;
  • 政治和文化意识;
  • 谈判;
  • 引导;
  • 冲突管理;
  • 教练技术。

项目经理的成功取决于项目目标的实现。相关方的满意程度是衡量项目经理的成功的另一标准。

项目经理应处理相关方的需要、关注和期望,令有关的相关方满意。为了取得成功,项目经理应该裁减项目方法、生命周期和项目管理过程,以满足项目和产品要求。

项目管理知识领域是管理各种项目时需普遍使用的专业知识领域。每个知识领域都是项目管理中的一个特定主题,以及与该主题相关的一组过程。这10大知识领域在大多数时候适用于大多数项目。某类特定项目可能需要额外的知识领域。这 10 大知识领域包括:

  • 项目整合管理项目整合管理包括为识别、定义、组合、统一和协调各项目管理过程组的各种过程和活动而开展的过程与活动。
  • 项目范围管理项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。
  • 项目进度管理项目进度管理包括为管理项目按时完成所需的各个过程。
  • 项目成本管理项目成本管理包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程。
  • 项目质量管理项目质量管理包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方的期望的各个过程。
  • 项目资源管理项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程。
  • 项目沟通管理项目沟通管理包括为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程。
  • 项目风险管理项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。
  • 项目采购管理项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。
  • 项目相关方管理项目相关方管理包括用于开展下列工作的各个过程:识别影响或受项目影响的人员、群体或组织,分析相关方对项目的期望和影响,制定合适的管理策略来有效调动相关方参与项目决策和执行。

项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。

事业环境因素源于项目外部(往往是企业外部)的环境,是项目团队不能控制且将影响、制约或指引项目的各种条件。事业环境因素可能对整个企业、项目组合、项目集或项目产生影响。(有关事业环境因素的更多信息,请参阅《PMBOK® 指南》第 2.2 节。)内部的组织文化、组织结构和组织治理就是事业环境因素中的一个类别,其中包括(但不限于):愿景、使命、价值观、信念、文化传统、等级制度和职权关系。

组织过程资产源于企业内部,可能来自企业自身、项目组合、项目集、其他项目或这些的组合。

组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库,会影响对具体项目的管理,包括(但不限于):变更控制程序、模板、来自以往项目的信息和经验教训知识库。(有关组织过程资产的更多信息,请参阅《PMBOK® 指南》第 2.3 节)。

在本标准中,术语“工件”包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。项目经理和项目管理团队需要选择和调整合适的工件,用于其特定项目。这种选择和调整活动称为裁剪。每个项目的独特性决定了必须进行裁剪,因此,并非每个项目都需要每个过程、输入、工具、技术或输出。

项目管理计划是最常用的工件,有许多组成部分,如子管理计划、基准和项目生命周期描述。

子管理计划是与项目特定方面或知识领域相关的计划,如进度管理计划、风险管理计划和变更管理计划。进行裁剪时,需要确定特定项目所需的项目管理计划组件。项目管理计划是一种输入,而项目管理计划更新是本标准中许多过程的输出。在本标准中,不会在输入和输出表中直接列出单个项目管理计划组件,而是在该表下方的正文中列出每个过程可能用到的项目管理计划组件(输入)或可能得到的项目管理计划组件更新(输出)。所列出的组件仅为示例而已。在开展每个特定过程时,项目经理既非必须、也非限于用到上述输入或得到上述输出。

项目管理计划是主要的项目工件之一。另外,还有不属于项目管理计划但也可用于管理项目的其他文件。这些其他文件称为项目文件。与项目管理计划组件类似,过程所需的项目文件会因具体项目而异。项目经理负责确定过程所需的项目文件,以及将作为过程输出的项目文件更新。在本标准中,在输入和输出表下方的正文中列出的项目文件,仅为项目文件的可能示例,而非完整列表。

表 1-2 列出了项目管理计划的主要组件和主要的项目文件。虽然该表并未穷尽所有的计划组件和项

目文件,但的确列出了有助于管理项目的常用计划组件和项目文件。

表 1-2项目管理计划和项目文件

商业文件通常是在项目之外创建的文件,用作项目的输入。商业文件包括商业论证和效益管理计划。如何应用商业文件,将取决于公司文化和项目启动过程。

会影响项目的事业环境因素,以及可用于项目的组织过程资产,将因项目及其所处环境而异,所以并未在本标准中列出。

启动过程组包括定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的一组过程。

启动过程组的目的是:协调相关方期望与项目目的,告知相关方项目范围和目标,并商讨他们对项目及相关阶段的参与将如何有助实现其期望。在启动过程中,定义初步项目范围和落实初步财务资源,识别那些将相互作用并影响项目总体结果的相关方,指派项目经理(如果尚未安排)。这些信息应反映在项目章程和相关方登记册中。一旦项目章程获得批准,项目也就正式立项,同时,项目经理就有权将组织资源用于项目活动。

本过程组的主要作用是,确保只有符合组织战略目标的项目才能立项,以及在项目开始时就认真考虑商业论证、项目效益和相关方。在一些组织中,项目经理会参与制定商业论证和分析项目效益,会帮助编写项目章程。在另一些组织中,项目的前期准备工作则由项目发起人、项目管理办公室 (PMO)、项目组合指导委员会或其他相关方群体完成。本标准假设项目已获得发起人或其他治理机构的批准,并且他们在批准项目之前已经审核了商业文件。

虽然商业文件通常是在项目之外创建的,但是要用作项目的输入。商业文件包括商业论证和效益管理计划。图 2-1 显示了项目发起人及商业文件与启动过程的关系。

图 2-1项目边界

如第 1.5 节所述,项目通常划分为多个阶段。一旦划分了阶段,就需要在后续阶段复审从启动过程得到的信息,以确认是否仍然有效。在每个阶段开始时重新开展启动过程,有助于保持项目符合其预定的商业需求,有助于核实项目章程、商业文件和成功标准,有助于复审项目相关方的影响、动机、期望和目标。

发起人、客户和其他相关方参与项目启动,有助于促进他们对项目成功标准达成一致,也有助于提升项目完成时可交付成果通过验收的可能性,以及在整个项目期间相关方的满意程度。

启动过程组包括第 2.1 节至 2.2 节所列的项目管理过程。

图 2-2启动过程组

制定项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。本过程的主要作用是,明确项目与组织战略目标之间的直接联系,确立项目的正式地位,并展示组织对项目的承诺。本过程仅开展一次或仅在项目的预定义点开展。图 2-3 描述了本过程的输入和输出。

图 2-3制定项目章程:输入和输出

规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产,以及具体项目的需求,为项目沟通活动制定恰当的方法和计划的过程。本过程的主要作用是,为及时向相关方提供相关信息,引导相关方有效参与项目,而编制书面沟通计划。本过程应根据需要在整个项目期间定期开展。图 3-18 描述了本过程的输入和输出。

图 3-18规划沟通管理:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

规划风险管理是定义如何实施项目风险管理活动的过程。本过程的主要作用是,确保风险管理的水平、方法和可见度与项目风险程度,以及项目对组织和其他相关方的重要程度相匹配。本过程仅开展一次或仅在项目的预定义点开展。图 3-19 描述了本过程的输入和输出。

图 3-19规划风险管理:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

规划采购管理是记录项目采购决策,明确采购方法,识别潜在卖方的过程。本过程的主要作用是,确定是否从项目外部获取货物和服务,如果是,则还要确定将在什么时间、以什么方式获取什么货物和服务。货物和服务可从执行组织的其他部门采购,或者从外部渠道采购。本过程仅开展一次或仅在项目的预定义点开展。图 3-24 描述了本过程的输入和输出。

图 3-24规划采购:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

管理项目知识是使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。

本过程的主要作用是,利用已有的组织知识来创造或改进项目成果,并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。图 4-3 描述了本过程的输入和输出。

图 4-3管理项目知识:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

管理质量是把组织的质量政策用于项目,并将质量管理计划转化为可执行的质量活动的过程。

本过程的主要作用是,提高实现质量目标的可能性,以及识别无效过程和导致质量低劣的原因。

本过程需要在整个项目期间开展。图 4-4 描述了本过程的输入和输出。

图 4-4管理质量:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

实施整体变更控制是指审查所有变更请求,批准变更,管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定对变更请求的处置方案。本过程的主要作用是,确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 5-3 描述了本过程的输入和输出。

图 5-3实施整体变更控制:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

收尾过程组包括为正式完成或关闭项目、阶段或合同而开展的过程。本过程组旨在核实为完成项目或阶段所需的所有过程组的全部过程均已完成,并正式宣告项目或阶段关闭。本过程组的主要作用是,确保恰当地关闭阶段、项目和合同。虽然本过程组只有一个过程,但是组织可以自行为项目、阶段或合同添加相关过程。因此,仍把它称为“过程组”。

本过程组也适用于项目的提前关闭,例如项目流产或取消。

收尾过程组(图 6-1)包括第 6.1 节所列的项目管理过程。

图 6-1收尾过程组

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是,存档项目或阶段信息,完成计划的工作,释放组织资源以展开新的工作。本过程仅开展一次或仅在项目的预定义点开展。图 6-2 描述了本过程的输入和输出。

图 6-2结束项目或阶段:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

项目质量管理的核心概念包括:

  • 项目质量管理需要兼顾项目管理与项目可交付成果两个方面,它适用于所有项目,无论项目的可交付成果具有何种特性。质量的测量方法和技术则需视专门针对项目所产生的可交付成果类型而定。
  • 质量和等级是不同的概念。质量是“一系列内在特性满足要求的程度”(ISO 9000)1,而等级是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及团队要负责权衡,以便同时达到所要求的质量与等级水平。
  • 预防胜于检查。最好是在设计时考虑可交付成果的质量,而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。
  • 项目经理可能需要熟悉抽样。属性抽样的结果为合格或不合格,而变量抽样指的是在连续的量表上标明结果所处的位置,以表明合格的程度。
  • 很多项目会为项目和产品衡量确立公差(结果的可接受范围)和控制界限(在统计意义上稳定的过程或过程绩效的普通差异的边界)。
  • 质量成本 (COQ) 包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求,以及因未达到要求(返工)而发生的所有成本。质量成本通常关注项目集管理、项目组合管理、PMO 或运营。
  • 当质量整合到项目和产品规划和设计中时,以及组织文化意识致力于提高质量时,就能达成最有效的质量管理。

X4.6项目资源管理的核心概念项目资源管理的核心概念包括:

  • 项目资源包括物质资源(设备、材料、设施和基础设施)和团队资源(担任项目角色及承担相关职责的人员)。
  • 管理团队资源和物质资源需要不同的技能和能力。
  • 项目经理应同时是项目团队的主管和经理,而且应在聘用、管理、激励和授权团队成员方面做出适当的努力。
  • 项目经理应了解影响团队的因素,例如,团队环境、团队成员所在的地理位置、相关方之间的沟通、组织变更管理、内部和外部政治、文化问题,以及组织的独特性,uu项目经理还负责积极培养团队技能和能力,同时提高并保持团队的满意度和积极性。
  • 物质资源管理着眼于以有效和高效的方式,分配和使用成功完成项目所需的物质资源,而无法有效管理和控制资源可能会降低项目顺利完工的概率。

项目风险管理的核心概念包括:

  • 所有项目都有风险。组织应选择承担项目风险,以便创造价值并在风险和奖励之间取得平衡。
  • 项目风险管理的目的在于,识别并管理其他项目管理过程中未处理的风险。
  • 每个项目中都存在两个级别的风险:单个风险指的是一旦发生,会对一个或多个项目目标产生积极或消极影响的不确定事件或条件;整体项目风险指的是不确定性对项目整体的影响,它代表相关方面临的项目结果可能的积极和消极变化。这些影响源于包括单个风险在内的所有不确定性。项目风险管理过程要处理这两个项目级别上的风险。
  • 一旦发生,单个风险可能对项目目标产生积极或消极的影响,而整体项目风险也有积极或消极之分。
  • 在项目生命周期内,风险将持续涌现,所以,项目风险管理过程也应不断重复。
  • 为了对特定项目的风险进行有效管理,项目团队需要认清在努力实现项目目标过程中,什么级别的风险敞口可以接受。这一点则由反映组织与项目相关者风险偏好的可测量风险临界值来确定。

项目采购管理的核心概念包括:

  • 项目经理应足够熟悉采购过程,以便于制定与合同和合同关系有关的明智决策。
  • 采购所涉及的协议描述双方,即买方和卖方之间的关系。协议可以简单或复杂,但采购方法应反映采购的复杂程度。协议可以是合同、服务水平协议、谅解、协议备忘录,或采购订单。
  • 协议必须遵守当地、所在国及国际法中与合同有关的法律规定。
  • 与采购专家合作以确保遵守组织政策的同时,项目经理还应确定所有采购都能满足项目的具体需要。
  • 鉴于其法律约束力,协议需要经过更多的审批程序,通常会包括法务部,以确保它对产品、服务或卖方同意提供的成果有充分的描述,且其符合法律和法规关于采购的规定。
  • 复杂项目可能需要同时或先后管理多个合同,而买卖方关系存在于项目的许多级别上,以及采购组织内部与外部组织之间。

项目相关方管理的核心概念包括:

  • 每个项目都有相关方,他们会受项目的积极或消极影响,或者能对项目施加积极或消极的影响。部分相关方影响项目工作或成果的能力有限,而有些相关方则会对项目及期望成果有重大影响。
  • 项目经理和团队正确识别并以适当方式吸引所有相关方参与的能力,可以最终决定项目的成功或失败。
  • 要提高成功的概率,相关方识别和吸引其参与的过程应该在项目章程中获得批准、项目经理已被任命,而且团队开始组建之后尽快启动。
  • 有效相关方参与的关键在于,关注与所有相关方保持持续沟通,应该把相关方的满意程度视为关键项目目标来识别和管理。
  • 为了实现项目效益,识别相关方和吸引相关方参与的过程需重复开展,而且应定期接受审查和更新,尤其在项目推进到新的阶段,或组织或更大范围内的相关方群体发生重大变化时。

裁剪项目整合管理时要考虑的因素包括(但不限于):

  • 项目生命周期。合适的项目生命周期是多久?项目生命周期应包括哪些阶段?
  • 开发生命周期。对产品、服务或成果而言,合适的开发生命周期和开发方法是什么?预测型或适应型方法是否适当?如果是适应型,应采用增量还是迭代的方法来开发产品?混合型方法是否为最佳选择?
  • 管理方法。考虑到组织文化和项目的复杂性,哪种管理过程最有效?
  • 知识管理。如何管理项目中的知识才能营造合作的工作环境?
  • 变更。如何管理项目中的变更?
  • 治理。参与项目的有哪些控制委员会、委员会和其他相关方?项目状态报告的要求是什么?
  • 经验教训。在项目期间及项目结束时,应收集哪些信息?历史信息和经验教训是否适用于未来的项目?
  • 效益。何时以及如何报告效益:在项目结束时还是在每次迭代或阶段结束时?

裁剪项目范围管理时要考虑的因素包括(但不限于):

  • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了可在未来的项目中重复使用需求,项目经理应建立哪些指导原则?
  • 确认和控制。组织是否拥有正式或非正式的确认和控制相关政策、程序和指南?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

裁剪项目成本管理时要考虑的因素包括(但不限于):

  • 知识管理。组织是否拥有正式的知识管理体系和财务数据库,并提供给项目经理使用?
  • 估算和预算。组织是否拥有正式或非正式的,与成本估算和预算相关的政策、程序和指南?
  • 挣值管理。组织是否采用挣值管理来管理项目?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?这对成本估算有什么影响?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

裁剪项目质量管理时要考虑的因素包括(但不限于):

  • 政策合规与审计。组织有哪些质量政策和程序?组织使用哪些质量工具、技术和模板?
  • 标准与法规合规性。是否存在必须遵守的行业质量标准?需要考虑哪些政府、法律或法规方面的制约因素?
  • 持续改进。如何管理项目中的质量改进?是在组织级别还是在单个项目级别进行管理?
  • 相关方参与。项目环境是否有利于与相关方及供应商合作?

裁剪项目资源管理时要考虑的因素包括(但不限于):

  • 多样性。团队的多样性背景是什么?
  • 物理位置。团队成员和物质资源的物理位置在哪里?
  • 行业特定资源。所在行业需要哪些特殊资源?
  • 团队成员的招募。如何聘用项目团队成员?团队资源是全职还是兼职的?
  • 团队建设和管理。如何管理项目团队建设?组织是否有管理团队建设的工具或是否需要增加新工具?是否需要为团队提供有关多样性管理的特殊培训?
  • 生命周期方法。项目采用哪些生命周期方法?

裁剪项目沟通管理时要考虑的因素包括(但不限于):

  • 相关方。相关方是属于组织内部或外部,或者二者都是?
  • 物理位置。团队成员的物理位置在哪里?团队是否集中在一处?团队是否位于相同地理区域?

团队是否分散于多个时区?

  • 沟通技术。哪项技术可用于创建、记录、传输、检索、追踪和存储沟通的人为要素?针对相关方沟通,哪些技术最合适且经济有效?
  • 语言。语言是沟通活动过程中要考虑的主要因素。使用的是一种语言,还是多种语言?是否有储备以用于适应不同语言团队成员的复杂情况?
  • 知识管理。组织是否有正式的知识管理库?是否采用管理库?

裁剪项目风险管理时要考虑的因素包括(但不限于):

  • 项目规模。项目规模是否需要依据预算、持续时间、范围或团队规模进行调整,并采取更详细的风险管理方式?或者它是否够小,用简化的风险管理过程就足以应对?
  • 项目复杂性。高水平创新、新技术、商务安排、相互联系或外部依赖关系会提高项目复杂性,它们是否需要稳健的风险管理方式?或者项目是否够简单,用简化的风险管理过程就足以满足需求?
  • 项目重要性。项目有多大的战略重要性?此项目的风险级别升高,是否是因为它以创造突破性机会、克服组织绩效障碍为目标,或牵涉到重要的产品创新?
  • 开发方法。它是否是瀑布式项目,风险管理过程可以相继或重复开展;或者此项目是否采取敏捷型方法,需在每个重复过程的开始阶段以及执行期间处理风险?

裁剪项目采购管理时要考虑的因素包括(但不限于):

  • 采购的复杂性。是否只有一次主要的采购,还是需要在不同时间向不同卖方进行多次采购,从而增加采购的复杂性?
  • 物理位置。买方和卖方是否在同一个地方,或在合理范围内相距较近,还是位于不同时区、国家/地区,或大洲?
  • 治理和法规环境。组织的采购政策是否参考当地相关的采购活动法律和法规?如何影响合同审计要求?
  • 承包商的可用性。是否有其他具备工作执行能力的承包商可供选择?

《PMBOK® 指南》第六版展示的工具与技术和之前的版本有所不同。本版本在适当情况下按用途对工具与技术进行分组。分组名称描述了本组需要完成任务的目的,其中的工具与技术代表了为实现上述目的而采用的不同方法。例如,数据收集一组的目的是收集数据和信息。头脑风暴、访谈和市场调查都是可用于收集数据和信息的技术。

这种方法反映了第六版中强调根据环境、情况、组织和项目的不同需要,对《PMBOK® 指南》所述信息进行裁剪的重要性。

《PMBOK® 指南》第六版中共包括 132 种工具与技术。这些并不是项目管理中仅有的工具与技术。它们代表大多时候都被大多数项目视作良好实践的工具与技术。它们中有些在《PMBOK® 指南》中仅出现一次,有些则多次出现。

为帮助从业人员识别特定工具与技术的使用场合,本附录列出了每种工具与技术、其所属的分组(如适用)以及其在《PMBOK® 指南》中的过程。指南中描述某个工具或技术的过程采用黑体字。

在其他列出有关工具或技术的过程中,将引用描述这些工具或技术的过程。过程中可能针对特定过程怎样使用某个工具或技术进行补充说明。

《PMBOK® 指南》使用了以下工具与技术分组:

  • 数据收集技术。用于从各种渠道收集数据与信息。共有九种数据收集工具与技术。
  • 数据分析技术。用于组织、评估和评价数据与信息。共有 27 种数据分析工具与技术。
  • 数据表现技术。用于显示用来传递数据和信息的图形方式或其他方法。共有 15 种数据表现工具与技术。
  • 决策技术。用于从不同备选方案选择行动方案。共有两种决策工具与技术。
  • 沟通技巧。用于在相关方之间传递信息。共有两种沟通技巧工具与技术。
  • 人际关系与团队技能。用于有效地领导团队成员和其他相关方并与之进行互动。共有 17 种人际关系与团队技能工具与技术。

另外还有 60 种未分组的工具与技术。

表 X6-1工具与技术分类和索引表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)表 X6-1工具与技术分类和索引(续)

以下业务规则用于确保每个项目管理过程中输入和输出的顺序及信息的一致性:

  • 基本规则:
  • 输入是对过程很关键的任何文件。
  • 除非输出为最终输出或被其他输入(如项目文件)采纳,否则输出应成为另一个项目管理过程的输入。
  • 若输入并非来自项目外部,它们应该是其他项目管理过程的输出。
  • 项目文件规则:
  • 具体项目文件首次被识别时会列为具体输出。然后,它们将作为“项目文件更新”列入输出清单,内容叙述部分会对其加以描述。
  • 当任何项目文件是输入时,会列出“项目文件”一词,而且内容叙述部分会说明具体的项目文件。
  • 项目管理计划规则:
  • 对于会制定子计划的规划过程来说,项目章程是第一项输入,项目管理计划为第二项输入。
  • 创建项目管理计划组件的过程将具体列出组成部分。在此之后,它们会作为“项目管理计划更新”列入输出清单,内容叙述部分会对其加以描述。
  • 如果项目管理计划是过程输入,在内容叙述部分可能会对视为输入的具体项目管理计划组成部分进行说明。
  • 排序规则:
  • 若项目章程是输入,则其为第一项输入。
  • 如果项目管理计划是输入或输出,子管理计划会按《PMBOK® 指南》中输出它们的章节顺序列出,随后列出基准和任何其他计划。
  • 项目文件会以字母排列顺序列出。
  • 事业环境因素和组织过程资产也会按该顺序列在末尾。
  • 如果更新是输出,它们的排列顺序如下:

项目管理计划更新;

项目文件更新;

组织过程资产更新。

第 2 章的内容进行了大量重写。关于组织过程资产和事业环境因素的信息保留不变,但新增了关于治理、管理要素和组织结构类型的内容。

每一个知识领域部分在介绍第一个过程前都有标准化的材料,此类材料包括以下小章节:

  • 核心概念。收集与具体知识领域相关的核心概念。前几版也收录了此类信息;而在这一版中,我们对它们进行合并和说明,以保证各知识领域之间的一致性。附录 X4 对此类核心概念加以汇编。
  • 趋势和新兴实践。虽然项目管理行业在持续发展,但引领行业并非《PMBOK® 指南》的目的;

相反,它旨在描述在大多数时间适用于大多数项目的良好实践。在此小章节中,我们找出部分正在发生的趋势或新兴趋势,但并非大多数项目都会将其付诸使用。

  • 裁剪考虑因素。第六版强调裁剪项目各方面的重要性,以便于满足组织、环境、相关方和其他变量的需求。在此小章节中,我们确定项目经理在裁剪项目时可以考虑的各个领域。附录 X5 对此类裁剪考虑因素加以汇编。
  • 在敏捷或适应型环境中需要考虑的因素。在此小章节中,我们确定特定知识领域的适应型可能与预测型有区别的某些方面。

对整体项目风险日益加强的重视已整合到风险过程中,本章也新增了一项新过程“实施风险应对”,作为执行过程组一部分。它不仅关注规划风险应对的重要性,还强调实施风险应对的重要性。我们还引入了一项名为“升级”的全新风险应对,以说明若已识别的风险不在项目目标范围以内,它们应转交给组织的相关人员或小组。风险指的是不确定的未来事件或条件,虽然无法控制它们,但却能监督;因此,控制风险过程重新命名为监督风险。

与从 X1.1 至 X1.11 节所述信息一致的变更也得到采纳。表 X1-6 对第 11 章的过程进行了总结:

表 X1-6 第 11 章变更

为了体现更全球化的视角,我们更新了此知识领域内的大量信息。许多项目是由在多个不同国家的相关方来完成的,或由多个不同国家所设置办公室的组织负责。

市场调查结果显示,实际上很少由项目经理负责结束采购。而是通常由合同、采购或法务部门中拥有此项职权的相关人员负责。因此,结束采购中关于评估所有已完成的可交付成果以及将其与合同比较的信息,已合并到控制采购中;与行政、沟通和记录有关的信息也移到结束项目或阶段。

与从 X1.1 至 X1.11 节所述信息一致的变更也得到采纳。表 X1-7 对第 12 章的过程进行了总结:

表 X1-7 第 12 章变更