3.3.4 行业

项目经理应时刻关注行业的最新发展趋势,获得并思考这一信息对当前项目是否有影响或可用。

这些趋势包括(但不限于):

  • 产品和技术开发;
  • 新且正在变化的市场空间;
  • 标准(例如项目管理标准、质量管理标准、信息安全管理标准);
  • 技术支持工具;
  • 影响当前项目的经济力量;
  • 影响项目管理学科的影响力;
  • 过程改进和可持续发展战略。
引用
1.1.2 通用词汇

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

1.2.4.2 项目阶段

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

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

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

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

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

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

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

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

1.2.4.3 阶段关口

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

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

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

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

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

1.2.4.4 项目管理过程

项目生命周期是通过一系列项目管理活动进行的,即项目管理过程。每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。输出可以是可交付成果或结果。

结果是过程的最终成果。项目管理过程适用于全球各个行业。

各项目管理过程通过它们所产生的输出建立逻辑联系。过程可能包含了在整个项目期间相互重叠的活动。一个过程的输出通常成为以下二者之一:

  • 另一个过程的输入;
  • 项目或项目阶段的可交付成果。

图 1-6 的示例说明了一个过程的输入、工具、技术和输出的关系以及与其他过程的关系。

图 1-6过程示例:输入、工具与技术和输出

过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类:

  • 仅开展一次或仅在项目预定义点开展的过程。例如制定项目章程以及结束项目或阶段。
  • 根据需要定期开展的过程。在需要资源时执行获取资源。在需要采购之前执行实施采购。
  • 贯穿项目始终执行的过程。在整个项目生命周期中可能执行的过程定义活动,特别是当项目使用滚动式规划或适应型开发方法时。从项目开始到项目结束需要持续开展许多监控过程。

项目管理通过合理运用与整合按逻辑分组的项目管理过程而得以实现。过程分类方法有很多种,但《PMBOK® 指南》把过程归纳为五大类,即五大过程组。

2.2.2 组织外部的事业环境因素

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

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

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

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

图 3-2 PMI 人才三角®

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

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

3.4.3 战略和商务管理技能

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

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

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

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

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

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

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

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

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

4.1.2.1 专家判断

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 挣值分析;
  • 数据的解释和情境化;
  • 持续时间和成本的估算技术;
  • 趋势分析;
  • 关于项目所在的行业以及项目关注的领域的技术知识;
  • 风险管理;
  • 合同管理。
4.6.1.5 事业环境因素

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

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

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

  • 关于项目所在的行业以及项目关注的领域的技术知识;
  • 法律法规;
  • 法规与采购;
  • 配置管理;
  • 风险管理。
5.1.2.1 专家判断

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

  • 以往类似项目;
  • 特定行业、学科和应用领域的信息。
5.2 收集需求

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是,为定义产品范围和项目范围奠定基础,且仅开展一次或仅在项目的预定义点开展。图 5-4 描述本过程的输入、工具与技术和输出。图 5-5 是本过程的数据流向图。

图 5-4收集需求:输入、工具与技术和输出

图 5-5收集需求:数据流向图

《PMBOK® 指南》并没有专门讨论产品需求,因为产品需求因行业而异。《从业者商业分析:

实践指南》[7] 提供了有关产品需求的更深入信息。让相关方积极参与需求的探索和分解工作(分解成项目和产品需求),并仔细确定、记录和管理对产品、服务或成果的需求,能直接促进项目成功。需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求,将其包含在范围基准中,并在项目执行开始后对其进行测量。需求将成为工作分解结构(WBS)的基础,也将成为成本、进度、质量和采购规划的基础。

5.2.2.6 人际关系与团队技能

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

  • 名义小组技术。名义小组技术是用于促进头脑风暴的一种技术,通过投票排列最有用的创意,以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式,由四个步骤组成:
  • 向集体提出一个问题或难题。每个人在沉思后写出自己的想法。
  • 主持人在活动挂图上记录所有人的想法。
  • 集体讨论各个想法,直到全体成员达成一个明确的共识。
  • 个人私下投票决出各种想法的优先排序,通常采用 5 分制,1 分最低,5 分最高。为减少想法数量、集中关注想法,可进行数轮投票。每轮投票后,都将清点选票,得分最高者被选出。
  • 观察和交谈。观察和交谈是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时,就特别需要通过观察来了解他们的工作细节。观察,也称为“工作跟随”,通常由旁站观察者观察业务专家如何执行工作,但也可以由“参与观察者”来观察,通过实际执行一个流程或程序,来体验该流程或程序是如何实施的,以便挖掘隐藏的需求。
  • 引导。见 4.1.2.3 节。引导与主题研讨会结合使用,把主要相关方召集在一起定义产品需求。

研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点,有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通,从而有利于相关方达成一致意见。此外,与分别召开会议相比,研讨会能够更早发现并解决问题。

适合采用引导技能的情境包括(但不限于):

  • 联合应用设计或开发 (JAD)。JAD 会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起,以收集需求和改进软件开发过程。
  • 质量功能展开 (QFD)。制造行业则采用 QFD 这种引导技能来帮助确定新产品的关键特征。QFD从收集客户需要(又称“客户声音”)开始,然后客观地对这些需要进行分类和排序,并为实现这些需要而设定目标。
  • 用户故事。用户故事是对所需功能的简短文字描述,经常产生于需求研讨会。用户故事描述哪个相关方将从功能中受益(角色),他需要实现什么(目标),以及他期望获得什么利益(动机)。
5.2.2.8 原型法

原型法是指在实际制造预期产品之前,先造出该产品的模型,并据此征求对需求的早期反馈。

原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物,它使得相关方可以体验最终产品的模型,而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念,需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后,就可以通过原型获得足够的需求信息,从而进入设计或制造阶段。

故事板是一种原型技术,通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中,如电影、广告、教学设计,以及敏捷和其他软件开发项目。在软件开发中,故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

5.4.1.3 事业环境因素

会影响创建 WBS 过程的事业环境因素包括(但不限于)项目所在行业的 WBS 标准,这些标准可以作为创建 WBS 的外部参考资料。

5.4.2.2 分解

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 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 模板,可以在裁剪后应用于特定领域的具体项目。

6.1.2.1 专家判断

见 4.1.2.1 节。应征求具备专业知识或在以往类似项目中接受过相关培训的个人或小组的意见:

  • 进度计划的编制、管理和控制;
  • 进度计划方法(如预测型或适应型生命周期);
  • 进度计划软件;
  • 项目所在的特定行业。
6.3.1.3 事业环境因素

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

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

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

  • 政府或行业标准;
  • 沟通渠道。
7.1.2.1 专家判断

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

  • 以往类似项目;
  • 来自行业、学科和应用领域的信息;
  • 成本估算和预算;
  • 挣值管理。
7.2.2.1 专家判断

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

  • 以往类似项目;
  • 来自行业、学科和应用领域的信息;
  • 成本估算方法。
7.3.2.1 专家判断

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

  • 以往类似项目;
  • 来自行业、学科和应用领域的信息;
  • 财务原则;
  • 资金需求和来源。
8 项目质量管理

项目质量管理包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方目标的各个过程。此外,项目质量管理以执行组织的名义支持过程的持续改进活动。

项目质量管理过程包括:

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)、六西格玛和精益六西格玛等质量改进举措也可以提高项目管理的质量以及最终产品、服务或成果的质量。
  • 管理层的责任。项目的成功需要项目团队全体成员的参与。管理层在其质量职责内,肩负着为项目提供具有足够能力的资源的相应责任。
  • 与供应商的互利合作关系。组织与其供应商相互依赖。相对传统的供应商管理而言,与供应商建立合作伙伴关系对组织和供应商都更加有益。组织应着眼于长期关系而不是短期利益。互利合作关系增强了组织和供应商互相为对方创造价值的能力,推动他们共同实现客户的需求和期望,并优化成本和资源。

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

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

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

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

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

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

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

8.1.2.2 数据收集

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

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

在规划阶段,项目经理和项目团队决定如何测试或检查产品、可交付成果或服务,以满足相关方的需求和期望,以及如何满足产品的绩效和可靠性目标。不同行业有不同的测试与检查,可能包括软件项目的 α 测试和 β 测试、建筑项目的强度测试、制造和实地测试的检查,以及工程的无损伤测试。

8.2 管理质量

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

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

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

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

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

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

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

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

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

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

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

8.2.2.5 审计

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

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

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

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

8.2.3.2 测试与评估文件

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

8.3 控制质量

控制质量是为了评估绩效,确保项目输出完整、正确且满足客户期望,而监督和记录质量管理活动执行结果的过程。本过程的主要作用是,核实项目可交付成果和工作已经达到主要相关方的质量要求,可供最终验收。控制质量过程确定项目输出是否达到预期目的,这些输出需要满足所有适用标准、要求、法规和规范。本过程需要在整个项目期间开展。

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

图 8-10控制质量:输入、工具与技术和输出

图 8-11控制质量的数据流向图

控制质量过程的目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。

本过程通过测量所有步骤、属性和变量,来核实与规划阶段所描述规范的一致性和合规性。

在整个项目期间应执行质量控制,用可靠的数据来证明项目已经达到发起人和/或客户的验收标准。

控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。例如,相比其他行业,制药、医疗、运输和核能产业可能拥有更加严格的质量控制程序,为满足标准付出的工作也会更广;在敏捷项目中,控制质量活动可能由所有团队成员在整个项目生命周期中执行,而在瀑布式项目中,控制质量活动由特定团队成员在特定时间点或者项目或阶段快结束时执行。

9 项目资源管理

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

项目资源管理过程包括:

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.4 建设团队

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.1.2.1 专家判断

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

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

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

  • 已发布的材料,包括商业风险数据库或核对单;
  • 学术研究资料;
  • 标杆对照成果;
  • 类似项目的行业研究资料。
11.2.2.2 数据收集

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

  • 头脑风暴。头脑风暴(见 4.1.2.2 节)的目标是获取一份全面的单个项目风险和整体项目风险来源的清单。通常由项目团队开展头脑风暴,同时邀请团队以外的多学科专家参与。可以采用自由或结构化的形式开展头脑风暴,在引导者的指引下产生各种创意。可以用风险类别(如风险分解结构)作为识别风险的框架。因为头脑风暴生成的创意并不成型,所以应该特别注意对头脑风暴识别的风险进行清晰描述。
  • 核对单。核对单是包括需要考虑的项目、行动或要点的清单。它常被用作提醒。基于从类似项目和其他信息来源积累的历史信息和知识来编制核对单。编制核对单,列出过去曾出现且可能与当前项目相关的具体单个项目风险,这是吸取已完成的类似项目的经验教训的有效方式。组织可能基于自己已完成的项目来编制核对单,或者可能采用特定行业的通用风险核对单。虽然核对单简单易用,但它不可能穷尽所有风险。所以,必须确保不要用核对单来取代所需的风险识别工作;同时,项目团队也应该注意考察未在核对单中列出的事项。此外,还应该不时地审查核对单,增加新信息,删除或存档过时信息。
  • 访谈。可以通过对资深项目参与者、相关方和主题专家的访谈,来识别单个项目风险以及整体项目风险的来源。应该在信任和保密的环境下开展访谈(见 5.2.2.2 节),以获得真实可信、不带偏见的意见。
11.3.1.3 事业环境因素

能够影响实施定性风险分析的事业环境因素包括(但不限于):

  • 类似项目的行业研究资料;
  • 已发布的材料,包括商业风险数据库或核对单。
11.4.1.3 事业环境因素

能够影响实施定量风险分析过程的事业环境因素包括(但不限于):

  • 类似项目的行业研究资料;
  • 已发布的材料,包括商业风险数据库或核对单。
12 项目采购管理

项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程,例如,合同、订购单、协议备忘录 (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.1.1.3 项目管理计划

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

  • 范围管理计划。见 5.1.3.1 节。范围管理计划说明如何在项目的实施阶段管理承包商的工作范围。
  • 质量管理计划。见 8.1.3.1 节。质量管理计划包含项目需要遵循的行业标准与准则。这些标准与准则应写入招标文件,如建议邀请书,并将最终在合同中引用。这些标准与准则也可用于供应商资格预审,或作为供应商甄选标准的一部分。
  • 资源管理计划。见 9.1.3.1 节。资源管理计划包括关于哪些资源需要采购或租赁的信息,以及任何可能影响采购的假设条件或制约因素。
  • 范围基准。见 5.4.3.1 节。范围基准包含范围说明书、WBS 和 WBS 词典。在项目早期,项目范围可能仍要继续演进。应该针对项目范围中已知的工作,编制工作说明书 (SOW) 和工作大纲 (TOR)。
12.1.1.5 事业环境因素

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

  • 市场条件;
  • 可从市场获得的产品、服务和成果;
  • 卖方,包括其以往绩效或声誉;
  • 关于产品、服务和成果的典型条款和条件,或适用于特定行业的典型条款和条件;
  • 特殊的当地要求,例如关于雇用当地员工或卖方的法规要求;
  • 关于采购的法律建议;
  • 合同管理系统,包括合同变更控制程序;
  • 已有的多层级供应商系统,其中列出了基于以往经验而预审合格的卖方;
  • 财务会计和合同支付系统。
12.1.2.2 数据收集

适用于本过程的数据收集技术包括(但不限于)市场调研。市场调研包括考察行业情况和具体卖方的能力。采购团队可运用从会议、在线评论和各种其他渠道得到的信息,来了解市场情况。采购团队也可以调整具体的采购目标,以便在平衡与有能力提供所需材料或服务的卖方的范围有关的风险的同时,利用成熟技术。

12.1.3.3 招标文件

招标文件用于向潜在卖方征求建议书。如果主要依据价格来选择卖方(如购买商业或标准产品时),通常就使用标书、投标或报价等术语;如果其他考虑因素(如技术能力或技术方法)至关重要,则通常使用建议书之类的术语。具体使用的采购术语也可能因行业或采购地点而异。

取决于所需的货物或服务,招标文件可以是信息邀请书、报价邀请书、建议邀请书,或其他适当的采购文件。使用不同文件的条件如下:

  • 信息邀请书 (RFI)。如果需要卖方提供关于拟采购货物和服务的更多信息,就使用信息邀请书。

随后一般还会使用报价邀请书或建议邀请书。

  • 报价邀请书 (RFQ)。如果需要供应商提供关于将如何满足需求和(或)将需要多少成本的更多信息,就使用报价邀请书。
  • 建议邀请书 (RFP)。如果项目中出现问题且解决办法难以确定,就使用建议邀请书。这是最正式的“邀请书”文件,需要遵守与内容、时间表,以及卖方应答有关的严格的采购规则。

买方拟定的采购文件不仅应便于潜在卖方做出准确、完整的应答,还要便于买方对卖方应答进行评价。采购文件会包括规定的应答格式、相关的采购工作说明书,以及所需的合同条款。

采购文件的复杂和详细程度应与采购的价值及相关的风险相符。采购文件既需要具备足够详细的信息,以确保卖方做出一致且适当的应答,同时它又要有足够的灵活度,让卖方为满足相同的要求而提出更好的建议。

12.2.2.1 专家判断

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

  • 建议书评估;
  • 技术或相关主题事宜;
  • 相关的职能领域,如财务、工程、设计、开发、供应链管理等;
  • 行业监管环境;
  • 法律法规和合规性要求;
  • 谈判。
12.2.2.2 广告

广告是就产品、服务或成果与用户或潜在用户进行的沟通。在大众出版物(如指定的报纸)或专门行业出版物上刊登广告,往往可以扩充现有的潜在卖方名单。大多数政府机构都要求公开发布采购广告,或在网上公布拟签署的政府合同的信息。

13.1.1.6 事业环境因素

能够影响识别相关方过程的事业环境因素包括(但不限于):

  • 组织文化、政治氛围,以及治理框架;
  • 政府或行业标准(法规、产品标准和行为规范);
  • 全球、区域或当地的趋势、实践或习惯;
  • 设施和资源的地理分布。
13.1.2.1 专家判断

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

  • 理解组织内的政治和权力结构;
  • 了解所在组织和其他受影响组织(包括客户及其他组织)的环境和文化;
  • 了解项目所在行业或项目可交付成果类型;
  • 了解个体团队成员的贡献和专长。
13.2 规划相关方参与

规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响,制定项目相关方参与项目的方法的过程。本过程的主要作用是,提供与相关方进行有效互动的可行计划。本过程应根据需要在整个项目期间定期开展。

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

图 13-4规划相关方参与:输入、工具与技术和输出

图 13-5规划相关方参与:数据流向图

• Projectcharter为满足项目相关方的多样性信息需求,应该在项目生命周期的早期制定一份有效的计划;然后,随着相关方社区的变化,定期审查和更新该计划。在通过识别相关方过程明确最初的相关方社区之后,就应该编制第一版的相关方参与计划,然后定期更新相关方参与计划,以反映相关方社区的变化。会触发该计划更新的典型情况包括(但不限于):

  • 项目新阶段开始;
  • 组织结构或行业内部发生变化;
  • 新的个人或群体成为相关方,现有相关方不再是相关方社区的成员,或特定相关方对项目成功的重要性发生变化;
  • 当其他项目过程(如变更管理、风险管理或问题管理)的输出导致需要重新审查相关方参与策略。

这些情况都可能导致已识别相关方的相对重要性发生变化。

1.5 项目生命周期

项目生命周期指项目从开始到完成所经历的一系列阶段。项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。这些阶段之间可能是顺序、迭代或交叠的关系。项目阶段的名称、数量和持续时间取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。阶段都有时限,有一个起始点、结束点或控制点(有时称为阶段审查、阶段关口或控制关口,也可以用其他类似名称)。在控制点,需要根据当前环境,重新审查项目章程和商业文件。在该时点,把项目绩效与项目管理计划进行比较,以确定项目是否应该变更、终止或按计划继续。

项目生命周期会受组织、行业、开发方法或所用技术的独特性质的影响。虽然每个项目都有起点和终点,但具体的可交付成果及工作会因项目的不同而有很大差异。不论项目涉及的具体工作是什么,生命周期都可以为管理项目提供基本框架。

虽然项目规模及复杂程度各不相同,但是典型项目都呈现下列项目生命周期结构(见图 1-2):

  • 开始项目;
  • 组织与准备;
  • 执行项目工作;
  • 结束项目。

图 1-2项目生命周期的通用结构

通用的生命周期结构一般具有以下特征:

  • 成本与人力投入在开始时较低,在工作执行期间逐渐增加,并在项目快要结束时迅速回落。
  • 项目开始时风险最大,如图 1-3 所示。在项目的整个生命周期中,随着决策的制定与可交付成果的验收,风险会逐步降低。
  • 在不显著影响成本和进度的前提下,相关方改变项目产品最终特性的能力在项目开始时最大,并随项目进展而减弱。图 1-3 表明,做出变更和纠正错误的成本,通常会随着项目越来越接近完成而显著增高。

图 1-3随时间而变化的变量影响

1.9 项目管理过程组

本标准描述用于实现项目目标的项目管理过程。项目管理过程可归为五大项目管理过程组:

  • 启动过程组定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的过程。启动过程组详见第 2 章。
  • 规划过程组明确项目范围,优化目标,为实现目标制定行动方案的过程。规划过程组详见第 3 章。
  • 执行过程组完成项目管理计划中确定的工作,以满足项目要求的过程。执行过程组详见第 4 章。
  • 监控过程组跟踪、审查和调整项目进展与绩效,识别必要的计划变更并启动相应变更的过程。

监控过程组详见第 5 章。

  • 收尾过程组正式完成或结束项目、阶段或合同所执行的过程(组)。收尾过程组详见第 6 章。

这五大过程组与应用领域(如营销、信息服务或会计)或行业(如建筑、航天、电信)无关。

在阶段或项目完成之前,往往需要反复实施过程组中的单个过程。过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类:

  • 仅开展一次或仅在项目预定义点开展的过程。例如,制定项目章程,以及结束项目或阶段。
  • 根据需要定期开展的过程。例如,在需要资源时开展获取资源过程,在需要使用采购品之前开展实施采购过程。
  • 需要在整个项目期间持续开展的过程。例如,可能需要在整个项目生命周期持续开展定义活动过程,特别是当项目使用滚动式规划或适应型开发方法时;从项目开始到项目结束需要持续开展许多监控过程。

一个过程的输出通常成为另一个过程的输入,或者成为项目或项目阶段的可交付成果。例如,需要把规划过程组编制的项目管理计划和项目文件(如风险登记册、责任分配矩阵等)及其更新,提供给执行过程组作为输入。图 1-4 是各过程组在项目或阶段期间的重叠关系示例。

过程组不同于项目阶段。如果将项目划分为若干阶段,则各过程组中的过程会在每个阶段内相互作用。在一个阶段内可能需要使用所有的过程组,如图 1-5 所示。当项目被分为不同的阶段(例如概念开发、可行性研究、设计、原型、构建或测试等)时,各过程组中的过程根据需要在每个阶段中重复,直到达到该阶段的完工标准。

图 1-5项目或阶段中的过程组相互作用示例

过程组和知识领域涵盖的 49 个过程如表 1-1 所示。

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

X5.5 项目质量管理

裁剪项目质量管理时要考虑的因素包括(但不限于):

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

裁剪项目资源管理时要考虑的因素包括(但不限于):

  • 多样性。团队的多样性背景是什么?
  • 物理位置。团队成员和物质资源的物理位置在哪里?
  • 行业特定资源。所在行业需要哪些特殊资源?
  • 团队成员的招募。如何聘用项目团队成员?团队资源是全职还是兼职的?
  • 团队建设和管理。如何管理项目团队建设?组织是否有管理团队建设的工具或是否需要增加新工具?是否需要为团队提供有关多样性管理的特殊培训?
  • 生命周期方法。项目采用哪些生命周期方法?
X1.10 知识领域引言材料

每一个知识领域部分在介绍第一个过程前都有标准化的材料,此类材料包括以下小章节:

  • 核心概念。收集与具体知识领域相关的核心概念。前几版也收录了此类信息;而在这一版中,我们对它们进行合并和说明,以保证各知识领域之间的一致性。附录 X4 对此类核心概念加以汇编。
  • 趋势和新兴实践。虽然项目管理行业在持续发展,但引领行业并非《PMBOK® 指南》的目的;

相反,它旨在描述在大多数时间适用于大多数项目的良好实践。在此小章节中,我们找出部分正在发生的趋势或新兴趋势,但并非大多数项目都会将其付诸使用。

  • 裁剪考虑因素。第六版强调裁剪项目各方面的重要性,以便于满足组织、环境、相关方和其他变量的需求。在此小章节中,我们确定项目经理在裁剪项目时可以考虑的各个领域。附录 X5 对此类裁剪考虑因素加以汇编。
  • 在敏捷或适应型环境中需要考虑的因素。在此小章节中,我们确定特定知识领域的适应型可能与预测型有区别的某些方面。