全部展开 全部合拢

1.2.5 裁剪

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

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

项目管理方法论可能:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本指南基于《项目管理标准》[1]。标准是基于权威、惯例或共识而建立并用作模式或范例的文件。作为美国国家标准协会 (ANSI) 的标准,《项目管理标准》根据协商一致、开放公开、程序公正和各方平衡等概念予以制定。《项目管理标准》是 PMI 项目管理专业发展计划和项目管理实践的基本参考资料。由于项目管理需要根据项目需求进行调整,标准和指南均基于描述性实践,而不是规范性实践。因此,标准确认了在大多时候都被大多数项目视作良好实践的过程。另外,标准还确认了通常与这些过程相关的输入和输出。标准不要求执行任何特定过程或实践。《项目管理标准》是《项目管理知识体系指南》(《PMBOK® 指南》)的第二部分。

《PMBOK®指南》更详细地说明了核心概念、新兴趋势、裁剪项目管理过程时应考虑的因素,以及如何将工具和技术应用于项目中。项目经理可以采用一种或多种方法论执行本标准所描述的项目管理过程。

本指南的范围仅限于项目管理领域,而不涉及任何项目组合、项目集和多个项目的领域;仅在与项目有关时才会提及项目组合和项目集。PMI 还发布了针对项目组合和项目集的两部标准:

  • 《项目组合管理标准》[2];
  • 《项目集管理标准》[3]。

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

表 1-5项目商业文件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

技术项目管理技能指有效运用项目管理知识实现项目集或项目的预期成果的能力。有很多技术项目管理技能。本指南的知识领域部分描述了很多必要的项目管理技能。项目经理经常会依赖专家判断来有效开展工作。要获得成功,重要的是项目经理必须了解个人专长以及如何找到具备所需专业知识的人员。

研究表明,顶尖的项目经理会持续展现出几种关键技能,包括(但不限于):

  • 重点关注所管理的各个项目的关键技术项目管理要素。简单来说就是随时准备好合适的资料。

最主要的是:

  • 项目成功的关键因素;
  • 进度;
  • 指定的财务报告;
  • 问题日志。
  • 针对每个项目裁剪传统和敏捷工具、技术和方法。
  • 花时间制定完整的计划并谨慎排定优先顺序。
  • 管理项目要素,包括(但不限于)进度、成本、资源和风险。

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

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

项目整合管理过程包括:

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

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

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

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

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

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

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

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

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

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

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

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

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

项目整合管理指的是:

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

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

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

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

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

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

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

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

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

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

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

  • 根据项目需要裁剪项目管理过程,包括这些过程间的依赖关系和相互影响,以及这些过程的主要输入和输出;
  • 根据需要制定项目管理计划的附加组成部分;
  • 确定这些过程所需的工具与技术;
  • 编制应包括在项目管理计划中的技术与管理细节;
  • 确定项目所需的资源与技能水平;
  • 定义项目的配置管理级别;
  • 确定哪些项目文件受制于正式的变更控制过程;
  • 确定项目工作的优先级,确保把项目资源在合适的时间分配到合适的工作。

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

项目范围管理过程包括:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 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 规划进度管理 — 为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 之比,表示完成项目的工作效率。此外,挣得进度理论通过挣得进度、实际时间和估算持续时间,提供了预测项目完成日期的计算公式。

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

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

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

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

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

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

项目质量管理过程包括:

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

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

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

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

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

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

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

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

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

项目资源管理过程包括:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

适用于本过程的沟通技能包括(但不限于):

  • 沟通胜任力。经过裁剪的沟通技能的组合,有助于明确关键信息的目的、建立有效关系、实现信息共享和采取领导行为。
  • 反馈。反馈是关于沟通、可交付成果或情况的反应信息。反馈支持项目经理和团队及所有其他项目相关方之间的互动沟通。例如,指导、辅导和磋商。
  • 非口头技能。例如,通过示意、语调和面部表情等适当的肢体语言来表达意思。镜像模仿和眼神交流也是重要的技能。团队成员应该知道如何通过说什么和不说什么来表达自己的想法。
  • 演示。演示是信息和/或文档的正式交付。向项目相关方明确有效地演示项目信息可包括(但不限于):
  • 向相关方报告项目进度和信息更新;
  • 提供背景信息以支持决策制定;
  • 提供关于项目及其目标的通用信息,以提升项目工作和项目团队的形象;
  • 提供具体信息,以提升对项目工作和目标的理解和支持力度。

为获得演示成功,应该从内容和形式上考虑以下因素:

  • 受众及其期望和需求;
  • 项目和项目团队的需求及目标。

项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。项目风险管理的目标在于提高正面风险的概率和(或)影响,降低负面风险的概率和(或)影响,从而提高项目成功的可能性。

项目风险管理的过程是:

11.1 规划风险管理 — 定义如何实施项目风险管理活动的过程。

11.2 识别风险 — 识别单个项目风险,以及整体项目风险的来源,并记录风险特征的过程。

11.3 实施定性风险分析 — 通过评估单个项目风险发生的概率和影响以及其他特征,对风险进行优先级排序,从而为后续分析或行动提供基础的过程。

11.4 实施定量风险分析 — 就已识别的单个项目风险和其他不确定性的来源对整体项目目标的综合影响进行定量分析的过程。

11.5 规划风险应对 — 为处理整体项目风险敞口,以及应对单个项目风险,而制定可选方案、选择应对策略并商定应对行动的过程。

11.6 实施风险应对 — 执行商定的风险应对计划的过程。

11.7 监督风险 — 在整个项目期间,监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险,以及评估风险管理有效性的过程。

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

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

图 11-1项目风险管理概述

项目风险管理的核心概念既然项目是为交付收益而开展的、具有不同复杂程度的独特性工作,那自然就会充满风险。

开展项目,不仅要面对各种制约因素和假设条件,而且还要应对可能相互冲突和不断变化的相关方期望。组织应该有目的地以可控方式去冒项目风险,以便平衡风险和回报,并创造价值。

项目风险管理旨在识别和管理未被其他项目管理过程所管理的风险。如果不妥善管理,这些风险有可能导致项目偏离计划,无法达成既定的项目目标。因此,项目风险管理的有效性直接关乎项目成功与否。

每个项目都在两个层面上存在风险。每个项目都有会影响项目达成目标的单个风险,以及由单个项目风险和不确定性的其他来源联合导致的整体项目风险。考虑整体项目风险,也非常重要。项目风险管理过程同时兼顾这两个层面的风险。它们的定义如下:

  • 单个项目风险是一旦发生,会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
  • 整体项目风险是不确定性对项目整体的影响,是相关方面临的项目结果正面和负面变异区间。

它源于包括单个风险在内的所有不确定性。

一旦发生,单个项目风险会对项目目标产生正面或负面的影响。项目风险管理旨在利用或强化正面风险(机会),规避或减轻负面风险(威胁)。未妥善管理的威胁可能引发各种问题,如工期延误、成本超支、绩效不佳或声誉受损。把握好机会则能够获得众多好处,如工期缩短、成本节约、绩效改善或声誉提升。

整体项目风险也有正面或负面之分。管理整体项目风险旨在通过削弱负面变异的驱动因素,加强正面变异的驱动因素,以及最大化实现整体项目目标的概率,把项目风险敞口保持在可接受的范围之内。

因为风险会在项目生命周期内持续发生,所以,项目风险管理过程也应不断迭代开展。在项目规划期间,就应该通过调整项目策略对风险做初步处理。接着,应该随着项目进展,监督和管理风险,确保项目处于正轨,并且突发性风险也得到处理。

为有效管理特定项目的风险,项目团队需要知道,相对于要追求的项目目标,可接受的风险敞口究竟是多大。这通常用可测量的风险临界值来定义。风险临界值反映了组织与项目相关方的风险偏好程度,是项目目标的可接受的变异程度。应该明确规定风险临界,并传达给项目团队,同时反映在项目的风险影响级别定义中。

项目风险管理的发展趋势和新兴实践项目风险管理的关注面正在扩大,以便确保考虑所有类型的风险,并在更广泛的背景中理解项目风险。项目风险管理的发展趋势和新兴实践包括(但不限于):

  • 非事件类风险。大多数项目只关注作为可能发生或不发生的不确定性未来事件的风险。例如:

关键卖方可能在项目期间停业,客户可能在设计完成后变更需求,或分包商可能要求对标准化操作流程进行优化。

不过,识别并管理非事件类风险的意识正在不断加强。非事件类风险有两种主要类型:

  • 变异性风险。已规划事件、活动或决策的某些关键方面存在不确定性,就导致变异性风险。例如,生产率可能高于或低于目标值,测试发现的错误数量可能多于或少于预期,或施工阶段可能出现反常的天气情况。
  • 模糊性风险。对未来可能发生什么,存在不确定性。知识不足可能影响项目达成目标的能力,例如,不太了解需求或技术解决方案的要素、法规框架的未来发展,或项目内在的系统复杂性。

变异性风险可通过蒙特卡洛分析加以处理,即:用概率分布表示变异的可能区间,然后采取行动去缩小可能结果的区间。管理模糊性风险,则需要先定义认知或理解不足之处,进而通过获取外部专家意见或以最佳实践为标杆来填补差距。也可以采用增量开发、原型搭建或模拟等方法来处理模糊性风险。

  • 项目韧性。随着对所谓“未知-未知”因素的意识的增强,人们也越来越明确地知道确实存在突发性风险。这种风险只有在发生后才能被发现。可以通过加强项目韧性来应对突发性风险。

这就要求每个项目:

  • 除了为已知风险列出具体风险预算,还要为突发性风险预留合理的应急预算和时间;
  • 采用灵活的项目过程,包括强有力的变更管理,以便在保持朝项目目标推进的正确方向的同时,应对突发性风险;
  • 授权目标明确且值得信赖的项目团队在商定限制范围内完成工作;
  • 经常留意早期预警信号,以尽早识别突发性风险;
  • 明确征求相关方的意见,以明确为应对突发性风险而可以调整项目范围或策略的领域。
  • 整合式风险管理。项目存在于组织背景中,可能是项目集或项目组合的一部分。在项目、项目集、项目组合和组织这些层面上,都存在风险。应该在适当的层面上承担和管理风险。在较高层面识别出的某些风险,将被授权给项目团队去管理;而在较低层面识别出的某些风险,又可能上交给较高层面去管理(如果在项目之外管理最有效)。应该采用协调式企业级风险管理方法,来确保所有层面的风险管理工作的一致性和连贯性。这样就能使项目集和项目组合的结构具有风险效率,有利于在给定的风险敞口水平下创造最大的整体价值。

裁剪时需要考虑的因素因为每个项目都是独特的,所以有必要对项目风险管理过程的应用方式进行裁剪。裁剪时应考虑的因素包括(但不限于):

  • 项目规模。由预算、持续时间、范围或团队人数所体现的项目规模,要求采取更详细的风险管理方法吗?或者项目小到只需要用简化的风险管理过程吗?
  • 项目复杂性。由高水平创新、新技术采用、商务安排、界面或外部依赖关系导致的项目复杂性提高,是否要求采用更稳健的风险管理方法?或者项目是否简单到只需要用简化的风险管理过程?
  • 项目重要性。项目的战略重要性有多大?项目的风险级别因旨在创造突破性机会、克服组织经营的重大障碍或涉及重大产品创新而提高了吗?
  • 开发方法。它是否是瀑布式项目,风险管理过程可以相继或重复开展;或者此项目是否采取敏捷型方法,需在每个重复过程的开始阶段以及执行期间处理风险?

根据上述需考虑的因素来裁剪项目风险管理过程,这是规划风险管理过程的一部分工作。裁剪结果将被记录在风险管理计划中。

在敏捷或适应型环境中需要考虑的因素从本质上讲,越是变化的环境就存在越多的不确定性和风险。要应对快速变化,就需要采用适应型方法管理项目,即:通过跨职能项目团队和经常审查增量式工作产品,来加快知识分享,确保对风险的认知和管理。在选择每个迭代期的工作内容时,应该考虑风险;在每个迭代期间应该识别、分析和管理风险。

此外,应该根据对当前风险敞口的理解的加深,定期更新需求文件,并随项目进展重新排列工作优先级。

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

  • 熟悉组织所采取的管理风险的方法,包括该方法所在的企业风险管理体系;
  • 裁剪风险管理以适应项目的具体需求;
  • 在相同领域的项目上可能遇到的风险类型。

见 4.2.3.1 节。项目管理计划组件包括风险管理计划(见 11.1.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),来管辖整体协作关系,而将适应型工作写入附录或补充文件。这样一来,变更只针对适应型工作,而不会对主体协议造成影响。

项目相关方管理包括用于开展下列工作的各个过程:识别能够影响项目或会受项目影响的人员、团体或组织,分析相关方对项目的期望和影响,制定合适的管理策略来有效调动相关方参与项目决策和执行。用这些过程分析相关方期望,评估他们对项目或受项目影响的程度,以及制定策略来有效引导相关方支持项目决策、规划和执行。这些过程能够支持项目团队的工作。

项目相关方管理的过程是:

13.1 识别相关方 — 识别相关方是定期识别项目相关方,分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。

13.2 规划相关方参与 — 规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响,制定项目相关方参与项目的方法的过程。

13.3 管理相关方参与 — 管理相关方参与是与相关方进行沟通和协作,以满足其需求与期望,处理问题,并促进相关方合理参与的过程。

13.4 监督相关方参与 — 监督项目相关方关系,并通过修订参与策略和计划来引导相关方合理参与项目的过程。

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

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

图 13-1项目相关方管理概述

项目相关方管理的核心概念每个项目都有相关方,他们会受项目的积极或消极影响,或者能对项目施加积极或消极的影响。

有些相关方影响项目工作或成果的能力有限,而有些相关方可能对项目及其期望成果有重大影响。

关于重大项目灾难的学术研究及分析强调了结构化方法对识别所有相关方、进行相关方优先级排序,以及引导相关方参与的重要性。项目经理和团队正确识别并合理引导所有相关方参与的能力,能决定着项目的成败。为提高成功的可能性,应该在项目章程被批准、项目经理被委任,以及团队开始组建之后,尽早开始识别相关方并引导相关方参与。

相关方满意度应作为项目目标加以识别和管理。有效引导相关方参与的关键是重视与所有相关方保持持续沟通(包括团队成员),以理解他们的需求和期望、处理所发生的问题、管理利益冲突,并促进相关方参与项目决策和活动。

为了实现项目收益,识别相关方和引导相关方参与的过程需要迭代开展。虽然在项目相关方管理中仅对这些过程讨论一次,但是,应该经常开展识别相关方、排列其优先级以及引导其参与等活动。至少要在以下时点开展这些活动:

  • 项目进入其生命周期的不同阶段;
  • 当前相关方不再与项目工作有关,或者在项目的相关方社区中出现了新的相关方成员;
  • 组织内部或更大区域的相关方社区发生重大变化。

项目相关方管理的发展趋势和新兴实践“ 相关方”一词的外延正在扩大,从传统意义上的员工、供应商和股东扩展到涵盖各式群体,包括监管机构、游说团体、环保人士、金融组织、媒体,以及那些自认为是相关方的人员(他们认为自己会受项目工作或成果的影响)。

项目相关方管理的发展趋势和新兴实践包括(但不限于):

  • 识别所有相关方,而非在限定范围内;
  • 确保所有团队成员都涉及引导相关方参与的活动;
  • 定期审查相关方社区,往往与单个项目风险的审查并行开展;
  • 应用“共创”概念,咨询最受项目工作或成果影响的相关方。该概念的重点是,将团队内受影响的相关方视为合作伙伴。
  • 关注与相关方有效参与程度有关的正面及负面价值。正面价值是相关方(尤其是强大相关方)对项目的更积极支持所带来的效益;负面价值是因相关方未有效参与而造成的真实成本,包括产品召回、组织信誉损失或项目信誉损失。

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

  • 相关方多样性。现有多少相关方?相关方群体中的文化多样性如何?
  • 相关方关系的复杂性。相关方社区内的关系有多复杂?相关方或相关方群体加入的网络越多,与其相关的信息或误传网络就越复杂。
  • 沟通技术。有哪些可用的沟通技术?为了实现技术的最大价值,目前采用怎样的支持机制?

在敏捷或适应型环境中需要考虑的因素高度变化的项目更需要项目相关方的有效互动和参与。为了开展及时且高效的讨论及决策,适应型团队会直接与相关方互动,而不是通过层层的管理级别。客户、用户和开发人员在动态的共创过程中交换信息,通常能实现更高的相关方参与和满意程度。在整个项目期间保持与相关方社区的互动,有利于降低风险、建立信任和尽早做出项目调整,从而节约成本,提高项目成功的可能性。

为加快组织内部和组织之间的信息分享,敏捷型方法提倡高度透明。例如,邀请所有相关方参与项目会议和审查,或将项目工件发布到公共空间,其目的在于让各方之间的不一致和依赖关系,或者与不断变化的项目有关的其他问题,都尽快浮现。

在本标准中,术语“工件”包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。项目经理和项目管理团队需要选择和调整合适的工件,用于其特定项目。这种选择和调整活动称为裁剪。每个项目的独特性决定了必须进行裁剪,因此,并非每个项目都需要每个过程、输入、工具、技术或输出。

项目管理计划是最常用的工件,有许多组成部分,如子管理计划、基准和项目生命周期描述。

子管理计划是与项目特定方面或知识领域相关的计划,如进度管理计划、风险管理计划和变更管理计划。进行裁剪时,需要确定特定项目所需的项目管理计划组件。项目管理计划是一种输入,而项目管理计划更新是本标准中许多过程的输出。在本标准中,不会在输入和输出表中直接列出单个项目管理计划组件,而是在该表下方的正文中列出每个过程可能用到的项目管理计划组件(输入)或可能得到的项目管理计划组件更新(输出)。所列出的组件仅为示例而已。在开展每个特定过程时,项目经理既非必须、也非限于用到上述输入或得到上述输出。

项目管理计划是主要的项目工件之一。另外,还有不属于项目管理计划但也可用于管理项目的其他文件。这些其他文件称为项目文件。与项目管理计划组件类似,过程所需的项目文件会因具体项目而异。项目经理负责确定过程所需的项目文件,以及将作为过程输出的项目文件更新。在本标准中,在输入和输出表下方的正文中列出的项目文件,仅为项目文件的可能示例,而非完整列表。

表 1-2 列出了项目管理计划的主要组件和主要的项目文件。虽然该表并未穷尽所有的计划组件和项

目文件,但的确列出了有助于管理项目的常用计划组件和项目文件。

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

商业文件通常是在项目之外创建的文件,用作项目的输入。商业文件包括商业论证和效益管理计划。如何应用商业文件,将取决于公司文化和项目启动过程。

会影响项目的事业环境因素,以及可用于项目的组织过程资产,将因项目及其所处环境而异,所以并未在本标准中列出。

本附录的目的是总结第 4 到 13 章中每个知识领域的裁剪概念小结。由于每个项目都有独特性,因此此类信息可用于协助从业者确定如何对项目过程、输入、工具和技术,以及输出进行裁剪,还有助于确定知识领域中不同过程应采取的严格程度。

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

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

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

  • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了可在未来的项目中重复使用需求,项目经理应建立哪些指导原则?
  • 确认和控制。组织是否拥有正式或非正式的确认和控制相关政策、程序和指南?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

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

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

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

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

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

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

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

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

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

  • 相关方。相关方是属于组织内部或外部,或者二者都是?
  • 物理位置。团队成员的物理位置在哪里?团队是否集中在一处?团队是否位于相同地理区域?

团队是否分散于多个时区?

  • 沟通技术。哪项技术可用于创建、记录、传输、检索、追踪和存储沟通的人为要素?针对相关方沟通,哪些技术最合适且经济有效?
  • 语言。语言是沟通活动过程中要考虑的主要因素。使用的是一种语言,还是多种语言?是否有储备以用于适应不同语言团队成员的复杂情况?
  • 知识管理。组织是否有正式的知识管理库?是否采用管理库?

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

  • 项目规模。项目规模是否需要依据预算、持续时间、范围或团队规模进行调整,并采取更详细的风险管理方式?或者它是否够小,用简化的风险管理过程就足以应对?
  • 项目复杂性。高水平创新、新技术、商务安排、相互联系或外部依赖关系会提高项目复杂性,它们是否需要稳健的风险管理方式?或者项目是否够简单,用简化的风险管理过程就足以满足需求?
  • 项目重要性。项目有多大的战略重要性?此项目的风险级别升高,是否是因为它以创造突破性机会、克服组织绩效障碍为目标,或牵涉到重要的产品创新?
  • 开发方法。它是否是瀑布式项目,风险管理过程可以相继或重复开展;或者此项目是否采取敏捷型方法,需在每个重复过程的开始阶段以及执行期间处理风险?

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

  • 采购的复杂性。是否只有一次主要的采购,还是需要在不同时间向不同卖方进行多次采购,从而增加采购的复杂性?
  • 物理位置。买方和卖方是否在同一个地方,或在合理范围内相距较近,还是位于不同时区、国家/地区,或大洲?
  • 治理和法规环境。组织的采购政策是否参考当地相关的采购活动法律和法规?如何影响合同审计要求?
  • 承包商的可用性。是否有其他具备工作执行能力的承包商可供选择?

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

  • 相关方多样性。现有多少相关方?相关方群体中的文化多样性如何?
  • 相关方关系的复杂性。相关方群体内的关系有多复杂?相关方或相关方群体加入的网络越多,相关方所处的信息及错误信息网络就越复杂。
  • 沟通技术。可以使用的沟通技术有哪些?为了实现技术的最大价值,目前采用怎样的支持机制?

《PMBOK® 指南》第六版展示的工具与技术和之前的版本有所不同。本版本在适当情况下按用途对工具与技术进行分组。分组名称描述了本组需要完成任务的目的,其中的工具与技术代表了为实现上述目的而采用的不同方法。例如,数据收集一组的目的是收集数据和信息。头脑风暴、访谈和市场调查都是可用于收集数据和信息的技术。

这种方法反映了第六版中强调根据环境、情况、组织和项目的不同需要,对《PMBOK® 指南》所述信息进行裁剪的重要性。

《PMBOK® 指南》第六版中共包括 132 种工具与技术。这些并不是项目管理中仅有的工具与技术。它们代表大多时候都被大多数项目视作良好实践的工具与技术。它们中有些在《PMBOK® 指南》中仅出现一次,有些则多次出现。

为帮助从业人员识别特定工具与技术的使用场合,本附录列出了每种工具与技术、其所属的分组(如适用)以及其在《PMBOK® 指南》中的过程。指南中描述某个工具或技术的过程采用黑体字。

在其他列出有关工具或技术的过程中,将引用描述这些工具或技术的过程。过程中可能针对特定过程怎样使用某个工具或技术进行补充说明。

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

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

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

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