3.3.2 过程

每当开始编撰新版《项目管理标准》和《 PMBOK 指南》时，我们都有机会从全球视角考虑关于项目管理、实现收益所用的方法，以及项目输出的价值这些方面所发生的变化。在各版指南发布的间隔期内，世界已经发生了变化。有些组织已经不复存在，而新的组织不断涌现。旧的技术已经走到尽头，而提供全新能力的技术也已逐步发展起来。继续在职的员工要像新入职者一样在思维、技能和能力方面获得提升，他们要重点关：快速了解专业语言，培养技能，增强商业敏锐度，为实现雇主目标做出贡献。

虽然在上述变化发生过程中，还保留着一些基础性的概念和构念，人们仍然认为，与个人的思考相比，集体思考能够形成更具整体性的解决方案。而且组织通过项目来交付独特结果或输出的情况仍然会继续存在。

虽然第 6 版《 PMBOK 指南》仍在发展中，但在第七版指南的整个开发过程中，PMI 一直在全球范围内积极争取对《项目管理标准》和《 PMBOK 指南》有使用体验的广泛的干系人参与。这些参与包括：

这些反馈和输入共同强调了以下四个要点：

自 1987 年以来《项目管理标准》一直代表着基于过程的项目管理标准《 PMBOK 指南》中包含的《项目管理标准》与一系列业务过程有关的项目管理准则和职能相保持一致。这些业务过程支持以下持续且可预测的实践：

在支持良好实践方面，虽然这些做法是有效的，但从本质上看，基于过程的项目管理标准是规定性的。随着项目管理在按比以往更快的速度发展，过去基于过程导向的版本难以为继，无法反映价值交付的整个大环境。因此，本版指南转而采用基于原则的标准，为有效的项目管理提供支持，并更多地关注预期成果，而非可交付物。

在本版标准部分逐步发展过程中，来自全球各地不同行业和组织、担任不同职位、实施不同类型项目的从业者为该标准的草案编撰贡献了力量，并/或提供了反馈意见。此外，参与第 7 版《 PMBOK 指南》编写的各位负责人和工作人员还审阅了其他知识体系和专注于项目管理的著作，来探究这些资料中蕴含的有关项目管理原则的概念。这些共同的努力凸显了各界对我们的强有力支持，为我们确认本版指南中的指导原则以适用于项目管理涉及的整个范围提供了支持。

迄今为止，全球项目管理界已认同应将该标准转变为一份原则声明。这些原则声明充分体现并总结了项目管理实践的公认目标及其核心功能。这些原则声明还提供了广泛的参考因素，项目团队能够在这些参考因素范围内开展工作，并提供众多方法来契合这些原则的意图。

借助这些原则声明，PMI 提供了整个价值交付环境中有效的项目管理方法：从预测型到适应型，以及中间的各种方法。这些基于原则的方法还与《项目集管理标准（第 3 版和第 4 版）和《项目组合管理标准》（第 4 版）的发展保持一致《项目组合、项目集和项目的风险管理标准》和《收益实现管理：实践指南》，这两个标准是全球主题专家团队基于原则的方法开发的新产品的代表。

本版《项目管理标准》或《项目管理知识体系指南》中的任何内容都不否定与过去版本中基于过程的方法的一致性。对于指导其项目管理能力、调整其方法论并评估其项目管理能力，很多组织和从业人员仍然认为基于过程的方法非常有用。这种方法与新版本的内容仍是相关的。

本版《 PMBOK 指南》的另一个重要变化是从系统视角论述项目管理。这一转变始于将系统视角的价值交付作为《项目管理标准》的一部分，并继续呈现《 PMBOK 指南》的内容。该“价值交付系统”部分改变了原有视角，即从项目组合、项目集和项目治理到重点关注将它们与其他业务能力结合在一起的价值链，再进一步推进到组织的战略、价值和商业目标。在项目管理的背景下《项目管理标准》和《 PMBOK 指南》强调，项目不只是产生输出，更重要的是要促使这些输出推动实现成果，而这些成果最终会将价值交付给组织及其干系人。

这种系统视角反映了从过去版本的《 PMBOK 指南》中的“知识领域”转变为八个绩效域。绩效域是一组对有效地交付项目成果至关重要的相关活动。总的来说，绩效域所代表的项目管理系统体现了彼此交互、相互关联且相互依赖的管理能力，这些能力只有协调一致才能实现期望的项目成果。随着各个绩效域彼此交互和相互作用，变化也会随之发生。项目团队要有整体系统思维的意识，不断审查、讨论、适应并应对这些变化，而非只是关注发生变化的具体绩效域。遵照《项目管理标准》中的“价值交付系统”这一概念，团队会通过以成果为中心的测量指标，而非按照各个过程或生成的工件、计划等来对各绩效域中的有效绩效作出评估。

原先版本的《 PMBOK 指南》强调必须对项目管理方法进行裁剪，使之适应于各项目的独有特征及其运行背景。第 6 版明确包括了相关考虑因素，以帮助项目团队思考如何对其项目管理方法进行裁剪。这些内容包含在各知识领域章节的前言部分，同时介绍了各类项目环境的考虑因素。本版《 PMBOK 指南》特设“裁剪”一章，对这项内容作出了进一步阐述。

本版指南新增了“模型、方法和工件”一章，为支持项目管理提供了高层级组合的模型、方法和工件。

这一章中有原先版本指南中为项目管理提供支持的工具、技术和输出的链接，但对团队应在何时、如何使用哪种工具未做出规定。

最后一个变化反映了《 PMBOK 指南》发行史上最重要的创新，即推出了 PMIstandards+™ 这一交互式数字平台，该平台融合了当下、新兴和未来的实践、方法、工件及其他有用的信息。这些数字内容更好地反映了项目管理知识体系的动态性PMIstandards+ 向项目管理从业人员和其他干系人提供了更加丰富、范围更加广泛的信息和资源，这些信息和资源能够更加快速地顺应项目管理领域中的发展和变化。这些内容根据行业板块、项目类型或其他特征阐述了具体实践、方法或工具如何适用于具体的项目PMIstandards+首先介绍了《 PMBOK 指南》第 6 版的输入、工具和技术以及输出，同时会继续纳入支持项目管理发展的新资源。展望未来《项目管理标准》和 《 PMBOK 指南》的用户可以在 PMIstandards+ 中找到补充印刷版出版物的丰富信息。

下图说明了项目《项目管理标准》的修订内容，以及《 PMBOK 指南》从第 6 版到第 7 版的变化，此外还有与 PMIstandards+ 数字平台的连接。

项目管理行业和项目管理方式的不断变化支持采用一种规定性较弱的标准。行业研究、具有广泛行业代表性的全球参与以及迭代审查过程塑造并验证了从基于过程的标准向基于原则的标准这一转变。未来的团队可以评估《项目管理标准》中所体现的这一转变的影响，并使用这些信息来增强或修订未来的版本。

可以单独或共同使用多种组件（例如项目组合、项目集、项目、产品和运营）以创造价值。这些组件共同组成了一个符合组织战略的价值交付系统。图 2-1 显示了价值交付系统的一个示例，该系统有两个项目组合，它们包含了多个项目集和项目。该系统还显示了一个包含多个项目的独立项目集以及与项目组合或项目集无关的多个独立项目。任何项目或项目集都可能会包括产品。运营可以直接支持和影响项目组合、项目集和项目以及其他业务职能，例如工资支付、供应链管理等。项目组合、项目集和项目会相互影响，也会影响运营。

如图 2-2 所示，价值交付系统是组织内部环境的一部分，该环境受政策、程序、方法论、框架、治理结构等制约。内部环境存在于更大的外部环境中，包括经济、竞争环境、法律限制等。第 2.4 节提供了与内部和外部环境相关的更多详细信息。

价值交付系统中的组件创建了用于产出成果的可交付物。成果是某一过程或项目的最终结果或后果。聚焦成果、选择和决策强调了项目的长期绩效。成果可带来收益，收益是组织实现的利益。收益继而可创造价值，而价值是具有作用、重要性或实用性的事物。

可以单独或共同使用多种组件（例如项目组合、项目集、项目、产品和运营）以创造价值。这些组件共同组成了一个符合组织战略的价值交付系统。图 2-1 显示了价值交付系统的一个示例，该系统有两个项目组合，它们包含了多个项目集和项目。该系统还显示了一个包含多个项目的独立项目集以及与项目组合或项目集无关的多个独立项目。任何项目或项目集都可能会包括产品。运营可以直接支持和影响项目组合、项目集和项目以及其他业务职能，例如工资支付、供应链管理等。项目组合、项目集和项目会相互影响，也会影响运营。

如图 2-2 所示，价值交付系统是组织内部环境的一部分，该环境受政策、程序、方法论、框架、治理结构等制约。内部环境存在于更大的外部环境中，包括经济、竞争环境、法律限制等。第 2.4 节提供了与内部和外部环境相关的更多详细信息。

价值交付系统中的组件创建了用于产出成果的可交付物。成果是某一过程或项目的最终结果或后果。聚焦成果、选择和决策强调了项目的长期绩效。成果可带来收益，收益是组织实现的利益。收益继而可创造价值，而价值是具有作用、重要性或实用性的事物。

具有此职能的人员会提供与项目特定主题相关的知识、愿景和专业知识。他们会在整个组织内提供建议和支持，并为项目团队的学习过程和工作准确性做出贡献。这些人员可以是组织外部人员，也可以是内部项目团队成员。在整个项目期间或特定时间范围内都可能需要这些人员。

履行治理职能的人员会批准并支持项目团队提出的建议，以及监督项目在实现预期成果方面的进展。

他们会维持项目团队与战略或商业目标之间的联系，而这些目标在项目过程中可能会发生变化。

组织的内部因素可能来自组织自身、项目组合、项目集、其他项目或这些来源的组合。它们包括工件、

实践或内部知识。知识包括从先前项目吸取的经验教训和已完成的工件。示例包括（但不限于）：

价值（包括从客户或最终用户的角度看的成果）是项目的最终成功指标和驱动因素。价值聚焦于可交付物的成果。项目的价值可以表示为对发起组织或接收组织的财务贡献。价值也可以是对所取得的公共利益的测量，例如，社会收益或客户从项目结果中所感知到的收益。当项目是项目集的组件时，项目对项目集成果的贡献可以表示为价值。

许多项目（尽管不是所有项目）都是基于商业论证而启动。也可能由于任何确定的交付需要，或者修改流程、产品或服务（如合同、工作说明书或其他文件）的需要而启动项目。在所有情况下，项目的目的就是提供预期成果，该成果通过有价值的解决方案满足需要。商业论证可以包含有关战略一致性、风险敞口评估、经济可行性研究、投资回报率、预期关键绩效测量、评估和替代方法的信息。商业论证可以从定性或定量的方面，或者同时从这两方面来说明项目成果的预期价值贡献。商业论证至少包含以下支持性和相互关联的要素：

除了收益和可能的协议之外，商业需要、项目理由和商业战略一起为项目团队提供信息，使他们能够做出知情决策，以达到或超过预期的商业价值。

在整个项目期间，应清晰描述、以迭代方式评估并更新期望成果。在项目生命周期内，项目可能会发生变更，然后项目团队会作出应对调整。项目团队会根据期望的输出、基准和商业论证不断评估项目进展情况和方向，以确定该项目仍与商业需要保持一致，并将交付预期成果。另外，干系人可以更新商业论证以获取机会，或者将项目团队和其他干系人确定的问题最小化。如果项目或其干系人不再与商业需要保持一致，或者如果项目似乎不可能提供预期价值，则组织可以选择终止此项投入。

价值是指某种事物的作用、重要性或实用性。价值具有主观性，从某种意义上说，同一个概念对于不同的人和组织具有不同的价值。之所以会发生这种情况，是因为所谓的收益取决于组织战略，包含从短期财务收益、到长期收益、甚至是非财务要素。由于所有项目都有一系列干系人，因此必须考虑为每个干系人群体产生的不同价值，并将这些价值与整体价值进行平衡，同时优先考虑客户价值。

在某些项目的背景下，可能存在不同形式的价值工程，这些价值工程可以将客户、执行组织或其他干系人的价值最大化。这方面的一个示例包括在可接受的风险敞口的情况下交付所需的功能和质量水平，同时尽可能少地使用资源，并避免浪费。有时，特别是在没有预先确定范围的适应型项目中，项目团队可以与客户共同努力，确定哪些功能值得投资，哪些功能可能缺乏足够的价值，无需增加到输出之中，从而优化价值。

为了支持从项目中实现价值，项目团队可将重点从可交付物转到预期成果。这样做可以让项目团队实现项目的愿景或目标，而不是简单地创建特定可交付物。虽然可交付物可能会支持预期的项目成果，但它可能无法完全实现项目的愿景或目标。例如，客户可能需要某一特定的软件解决方案，因为他们认为该解决方案可以满足提高生产力这一商业需要。软件是项目的输出，但软件本身并不能实现预期的生产力成果。在这种情况下，增加一项新的可交付物，即提供使用软件的培训和教练，就可以实现更好的生产力成果。如果项目的输出未能提高生产力，干系人可能会认为项目已经失败。因此，项目团队和其他干系人都应该了解可交付物及其预期成果。

项目工作的价值贡献可能是一种短期或长期的测量。由于价值贡献可能与运营活动的贡献相混合，因此很难将其分开。当项目是项目集的一个组件时，也可能需要在项目集层级对价值作出评估，以便以适当的方式对项目进行指导。可靠的价值评估应考虑项目输出的全部背景和整个生命周期。虽然价值会随着时间的推移而实现，但有效的过程可以帮助早日实现收益。通过有效率且有效果地实施项目，项目团队可以展示或实现诸如优先交付、更好的客户服务或改善工作环境等成果。通过与负责将项目可交付物投入使用的组织领导者合作，项目领导者可以确保可交付物能够实现所计划的成果。

项目生命周期中项目阶段的类型和数量取决于许多变量，其中主要是交付节奏和开发方法（如上所述）。生命周期中阶段的示例包括：

项目阶段通常设有阶段关口，以便在进入下一阶段之前检查是否已达到预期成果或满足当前阶段的退出标准。退出标准可能与可交付物、合同义务、满足特定绩效目标或其他有形措施的验收标准密切相关。

图 2-9 显示了各个阶段依次完成的生命周期。这种类型的生命周期与预测型开发方法非常匹配，因为每个阶段只进行一次，每个阶段都侧重于某一特定类型的工作。但有些情况（例如增加范围、需求变化或市场变化）则会导致某些阶段重复进行。

图 2-10 显示了一个采用增量型开发方法的生命周期。本示例中显示了由计划、设计和构建组成的三次迭代。每个后续的构建都将在初始构建上增加功能。

图 2-11 显示了一个采用适应型开发方法的生命周期。在每次迭代（有时称为“冲刺”）结束时，客户会对具有功能性的可交付物进行审查。在审查时，关键干系人会提供反馈，项目团队会更新项目待办事项列表，以确定下一次迭代中特性和功能的优先级。

可对此方法做出调整，以便在持续交付情况下使用此方法，具体如第 2.3.2 节（交付节奏）所述。

适应独特的目标、干系人和环境的复杂性有助于项目取得成功。裁剪是对有关项目管理方法、治理和过程做出深思熟虑的调整，使之更适合特定环境和当前任务。项目团队对适当的框架进行裁剪，该框架带来灵活性，在项目生命周期的环境内持续产生积极的成果。商业环境、团队规模、不确定性程度和项目复杂性都是如何裁剪项目系统的考虑因素。项目系统可以从整体角度进行裁剪，包括应考虑相互关联的复杂性。通过使用“刚好够”的过程、方法、模板和工件以实现项目期望的成果。裁剪旨在最大化价值、管理制约因素并提高绩效。

项目团队和 PMO 一起，并考虑治理因素，按每个项目逐一讨论并确定交付方法以及产生成果所需的资源。这包括选择要使用的过程、开发方式、方法和交付项目成果所需的工件。裁剪决策可以是接受既定方法论的隐性行动。相反，裁剪也可以是选择并混合特定要素以适应项目和项目环境的独特特征的显性行动。在一定程度上，每个项目都需要裁剪，因为每个项目都存在于特定环境中。

项目通常是独特的，即使项目可交付物看起来并不独特。这是因为项目环境不同之处在于组织及其客户、渠道、和环境都是动态要素。这些变化和不断发展的学问可能会导致项目团队使用或开发不同的方法或方式来追求成功。项目团队应审视每个项目的各种独特条件，以便他们能够确定产生期望成果的最适当方法。

现有的方法论或常见的工作方式可以使我们了解如何对项目进行裁剪。方法论是由专门学科的从业者所采用的实践、技术、程序和规则所组成的体系。项目团队可能需要采取上级组织的方法论，这就是说，项目团队采用的方法论体系由过程、治理、方法和模板组成，它们为如何开展项目提供指导。虽然这使组织内的项目保持了一定程度的一致性，但该方法论本身可能仍需要根据每个项目的情况进行裁剪。组织政策和程序规定了项目团队授权的可以裁剪的边界。

项目团队还可以考虑项目管理过程的时间和成本。未进行裁剪的过程可能对项目或其成果几乎没有什么价值，同时会导致成本增加和进度延长。对项目方法以及适当的过程、方法和工件进行裁剪，可以帮助项目团队就与过程相关的成本和与项目成果相关的价值贡献做出决策。

除了决定如何对方法进行裁剪外，项目团队还需要向与该方法有关的干系人沟通裁剪决策，每个团队成员都应了解与这些干系人及其角色相关的所选方法和过程。

项目团队应该对项目方法进行裁剪，以适应项目及其环境的独特特征，这有助于提高项目的绩效水平，增加项目成功的概率。经过裁剪的项目方法可以为组织产生直接和间接的收益，例如：

裁剪项目可以带来以下积极成果：

对方法进行裁剪具有迭代性，因此，在项目生命周期中它是一个持续的过程。项目团队需要收集所有干系人的反馈，了解在项目进展过程中各种方法和经裁剪的过程对他们有何效果，以评估这些方法和过程的有效性，并给组织增加价值。

大多数项目在某个阶段都会遇到挑战或障碍。如果项目团队开展项目的方法同时具备适应性和韧性，则有助于项目适应各种影响并蓬勃发展。适应性是指应对不断变化的情形的能力。韧性由两个具有互补性的特质组成：吸收冲击的能力和从挫折或失败中快速恢复的能力。适应性和韧性是任何开展项目的人员应具备的有益特征。

项目很少会按最初的计划执行。项目会受到内部和外部因素（新需求、问题、干系人影响等因素）影响，这些因素存在于一个有各种相互作用的系统中。项目中的某些要素可能会失败或达不到预期，这需要项目团队重新组合、重新思考和重新规划。例如，在基础设施项目中，法院在项目执行期间的裁决可能会导致设计和计划的变更。在技术项目中，技术方面的电脑化模型可能会显示各个组件可以正常协同工作，但它们在实际应用时却发生故障。在这两个案例中，项目团队都需要应对此情形，以便推进项目。有一种观点认为，项目应严格遵守早期阶段的计划和承诺，即使在出现新的或不可预见的因素之后亦是如此。这种观点对包括客户和最终用户在内的干系人是没有益处的，因为这束缚了产生价值的可能性。但是，应该从整体的角度做到适应性，例如应采用适当的变更控制过程，以避免诸如范围蔓延等问题。在项目环境中，支持适应性和韧性的能力包括：

预期的成果而非可交付物能够促成解决方案，进而可利用比原始计划更好的结果。例如，项目团队可找到替代解决方案，以提供比原始定义的可交付物更优的成果。虽然探寻替代方案通常属于商业论证的范畴，但技术和其他能力的演变非常快，以至于在商业论证完成和项目收尾之间的任何时候都可能会出现解决方案。项目期间可能会出现适应项目的机会，届时项目团队应向项目发起人、产品负责人或客户说明为何要抓住这一机会。根据合同类型，因适应项目而进行的某些变更可能需要客户批准。在项目发起人、产品负责人或客户的支持下，项目团队应准备好调整其计划和活动以利用这一机会。

项目系统中的意外变更和情况也可能会带来机会。为了优化价值交付，项目团队应该针对变更和计划外事件运用问题解决和整体思维方法。发生计划外事件时，项目团队应寻找可能获得的潜在积极成果。

例如，将项目时间线后期发生的变更包含进来，这样就可以成为市场上第一个提供该功能的产品，从而增加竞争优势。

在项目中保持适应性和韧性，可使项目团队在内部和外部因素发生变化时聚焦于期望成果，这有助于他们从挫折中恢复过来。这些特征还有助于项目团队学习和改进，以便他们能够从失败或挫折中快速恢复，并继续在交付价值方面取得进展。

在当今的商业环境中保持相关性是所有组织面临的根本挑战。要做到具有相关性，必须对干系人的需要和期望作出响应。这就需要为干系人的利益不断评估产品/服务，对变革作出快速响应，并担当变革推动者。项目经理应具备独特的能力，让组织做好变革的准备。根据项目本身的定义，项目会创造新的事物：它们是变革推动者。

变革管理或使能（enablement）是一种综合的、周期性的和结构化的方法，可使个人、群体和组织从当前状态过渡到实现期望收益的未来状态。它不同于项目变更控制，后者是一个过程，通过该过程，项目团队可以识别和记录项目的文件、可交付物或基准的修改，然后批准或拒绝这些修改。

组织中的变革可能源自内部，例如需要新的能力或应对绩效差距。变革也可能源自外部，例如技术进步、人口结构变化或社会经济压力。任何类型的变革都涉及到经历变革的群体以及与其互动的行业某种程度的适应或接受。

变革可能由干系人实施并对其产生影响。推动干系人变革是促进项目提供所需可交付物和预期成果的一部分。

在组织中推动变革可能充满挑战，这有多种原因，比如有些人可能天生就抵制变革或厌恶风险，又如所处环境可能表现出保守的文化。有效的变革管理采用激励型策略，而不是强制型策略。参与和双向沟通可营造出这样的一种环境，即变革会得到采用和接受，或者从抵制变革的用户那里识别出一些需要解决的有效问题。

项目团队成员和项目经理可与有关干系人共同合作，解决抵制、疲劳和变革吸收的问题，以提高客户或项目可交付物接收者成功采纳或接受变革的可能性。这包括在项目早期沟通与变革相关的愿景和目的，以争取各方对变革的认同。在整个项目期间，应向组织内所有层级的人员说明变革的收益和对工作过程的影响。

同样重要的是，使变革的速度适应干系人和环境接受变革的意愿、成本和能力。如果试图在太短的时间内进行过多的变革，则可能会因变革饱和而受到抵制。即使干系人一致认为变革将产生更多价值或增强成果，他们仍往往难以采取能够交付更高收益的行动。为了促进收益实现，项目还可能会开展一些活动，以便在变革实施后使其得到强化，从而避免人们回到初始的状态。

认识并解决干系人在整个项目生命周期内接受变革的需要，有助于将由此产生的变革整合到项目工作中，从而使成功取得的成果更有可能。

有关组织变革管理的更多信息，可参阅《组织变革管理：实践指南》[4]。

本版《 PMBOK 指南》关注交付成果，而不考虑项目团队使用的方法。但使用《 PMBOK 指南》的项目管理从业者也可以从对如何交付项目的某种程度的理解中获益。

与以前的版本相比，本版《 PMBOK 指南》的输入、工具/技术和输出 (ITTO) 变化很大。在以前的版本中，ITTO 对实施项目管理中使用的各种过程提供支持。要实现从基于过程的标准向基于原则的标准的转变，需要采取不同的方法来思考项目管理的各个方面。因此，绩效域代表着一组能有效地交付项目成果且至关重要的相关活动。本指南中有八个项目绩效域。

裁剪是对有关项目管理方法、治理和过程深思熟虑后作出调整，使之更适合特定环境和当前工作。裁剪过程受指导性项目管理原则、组织价值观和组织文化的驱动。

因为认识到没有任何出版物可以涵盖项目团队可能使用的所有工具、技术或实践，本版《 PMBOK指南》采用了全频谱（spectrum）项目方法。所以，本版指南提供了一系列常用的模型、方法和工件，项目管理从业者可以使用它们来完成相应的工作。

一旦识别了干系人，项目经理和项目团队就应努力了解干系人的感受、情绪、信念和价值观。这些因素可能会导致项目成果面临更多威胁或机会。它们也可能会迅速变化，因此，了解和分析干系人是一项持续进行的行动。

我们需要分析每个干系人对项目的立场和观点，这与了解项目干系人密切相关。对干系人进行分析时会考虑到干系人的几个方面，例如：

这些信息有助于项目团队考虑可能影响干系人的动机、行动和行为的相互作用。除了单个分析之外，项目团队还应考虑干系人之间如何互动，因为他们通常结成联盟，而这些联盟有助于或会阻碍项目目标的实现。例如，如果项目团队认为某位关键业务经理影响力很大，但对项目持负面看法，那么他们可以探索如何了解该业务经理的看法，并在项目开展过程中做出适当的应对。在所有情况下，分析工作都应由项目团队保密，如果超出分析的背景范围，信息可能会被误解。

干系人渗透到项目的各个方面。他们会为项目团队定义需求和范围，并对其进行优先级排序。他们会参与并制定规划。他们会确定项目可交付物和项目成果的验收和质量标准。大部分的项目工作都围绕着争取干系人参与以及与干系人进行沟通而展开。在整个项目过程中或在项目结束时，他们会使用项目可交付物并影响项目成果的实现。

某些干系人可以帮助减少项目中存在的不确定性的数量，而其他干系人则可能导致不确定性增加。客户、高层管理人员、项目管理办公室领导或项目集经理等干系人将重点关注项目及其可交付物绩效的测量。这些相互作用只是干系人绩效域如何与其他绩效域整合和交织的示例，它们并不包含所有绩效域中对干系人考虑相互作用的全部方式。

无论管理活动如何安排，项目团队发展中总有一些与大多数项目团队相关的共同方面。这些共同的方面包括：

个人可能希望提高自己在某些领域的技能和经验，项目经理可以为此提供帮助。

第 4 章中包含的几个模型描述了项目团队成长的各个阶段。

项目团队会经历不同的发展阶段。了解团队在发展过程中所处的阶段有助于项目经理为项目团队及其成长提供支持。第 4.2.6.1 节和第 4.2.6.2 节中介绍的两个模型说明了项目团队如何经历不同的阶段成为高绩效项目团队。

在各个项目绩效域中，都需要识别偏见，找出问题的根本原因，并考虑具有挑战性的问题，例如模糊性、复杂性等。批判性思维有助于完成这些活动。批判性思维包括训练有素、合乎理性、遵从逻辑、基于证据的思维。它需要具备开放思维和客观分析的能力。批判性思维（尤其是在应用于发现过程时）可以包括概念想象力、洞察力和直觉。它还可以包括反思性思维和元认知（“思考之上的思考”和“认知之上的认知”）。

项目团队成员可应用批判性思维来进行：

交付节奏是指项目可交付物的时间安排和频率。项目可以一次性交付、多次交付或定期交付。

由于项目团队专注于一种产品，因此他们可以充分应用关于产品、干系人和市场的知识。这使团队能够应对市场趋势并聚焦于价值交付。DevOps、#NoProject和 Continuous Digital 等多种方法中都包含了这种<716>实践。

该标准由三个部分组成：引论、价值交付系统和项目管理原则。

“引论”部分包括与项目管理相关的关键术语和概念。这些信息大部分与以前的版本一致。

“价值交付系统”部分的内容借鉴了 PMI 基础标准的内容以及与收益实现管理和组织敏捷性相关的研究。这些内容在呈现时聚焦于交付价值，其中还包含有创造价值的各种方式。

在整个开发和验证过程中“项目管理原则”部分始终在不断演变。这些原则的初步概念是通过先前讨论的研究确定的。开发团队的成员采取个人研究与协同努力相结合的方式开展工作，以确定潜在的原则，然后将它们归入相近的类别。开发团队对每个类别进一步分析和分解，将与每个类别相关的关键词列表包含进来。潜在的类别和关键词先被编入初稿，然后由整个开发团队审核和评论，以确保各项原则的意图会在草案中得到体现。

必须指出的是，这些原则具有广泛的基础。这些原则中的任何内容都不是教条，不具有限制性或规定性。这些原则与《 PMI 道德与专业行为规范》中的内容一致，但并非重复该文件。

由于每个项目和组织都不尽相同，所以不可能产生“正确的原则”。因此，这些原则旨在设计成为项目工作人员的指南。项目专业人士和其他项目工作者可以努力与这些原则保持一致，但这些原则并非旨在为管理项目提供操作指南。

所有项目中必然存在不确定性。因此，任何活动的影响都无法准确预测，而且可能会产生一系列结果。对项目目标有益的潜在结果称为机会；对目标产生负面影响的潜在结果称为威胁。这些机会和威胁共同构成了项目风险。有多种方案应对不确定性：

项目生命周期中项目阶段的类型和数量取决于许多变量，其中主要是交付节奏和开发方法（如上所述）。生命周期中阶段的示例包括：

项目阶段通常设有阶段关口，以便在进入下一阶段之前检查是否已达到预期成果或满足当前阶段的退出标准。退出标准可能与可交付物、合同义务、满足特定绩效目标或其他有形措施的验收标准密切相关。

图 2-9 显示了各个阶段依次完成的生命周期。这种类型的生命周期与预测型开发方法非常匹配，因为每个阶段只进行一次，每个阶段都侧重于某一特定类型的工作。但有些情况（例如增加范围、需求变化或市场变化）则会导致某些阶段重复进行。

图 2-10 显示了一个采用增量型开发方法的生命周期。本示例中显示了由计划、设计和构建组成的三次迭代。每个后续的构建都将在初始构建上增加功能。

图 2-11 显示了一个采用适应型开发方法的生命周期。在每次迭代（有时称为“冲刺”）结束时，客户会对具有功能性的可交付物进行审查。在审查时，关键干系人会提供反馈，项目团队会更新项目待办事项列表，以确定下一次迭代中特性和功能的优先级。

可对此方法做出调整，以便在持续交付情况下使用此方法，具体如第 2.3.2 节（交付节奏）所述。

规划的目的是积极主动地制定一种方法来创建项目可交付物。项目可交付物会推动项目所要取得的成果。高层级规划可以在项目批准授权之前开始。项目团队会逐步制定初始项目文件，例如愿景陈述、项目章程、商业论证或类似文件，以识别或定义实现预期成果的相互合作的方法。

在项目开始之前和整个项目期间，规划所花费的时间应由具体情况确定。花费更多比需要的时间进行规划属于低效行为。因此，从规划中获得的信息应足以用适当方式推进工作，但这些信息不应超过必要的详细程度。项目团队会使用规划工件来确认干系人的期望，并向干系人提供信息，以便他们做出决策、采取行动，使得项目与干系人之间保持一致。

本节中描述的方法不适合于上述特定类别；但它们是用于项目的多种目的的常用方法。

采购可以在项目期间的任何时候进行。但预先规划有助于设定期望，确保采购过程顺利进行。一旦了解了高层级范围，项目团队就会进行自制或外购分析。这包括确定将在内部开发的可交付物和服务，以及将从外部资源购买的可交付物和服务。这些信息会影响项目团队和进度计划。合同签订专业人士需要事先了解所需货物类型、何时需要这些货物以及所采购货物或服务所需的任何技术规范。

履行治理职能的人员会批准并支持项目团队提出的建议，以及监督项目在实现预期成果方面的进展。

他们会维持项目团队与战略或商业目标之间的联系，而这些目标在项目过程中可能会发生变化。

招标过程包括制定和公布招标文件、举行投标人会议和选择投标人。

招标文件可以包括：

这三种类型涵盖了大多数招标需要。还有其他招标文件，但它们往往是针对特定行业的。

一旦发出招标文件，买方通常会举行投标人会议，以回答投标人的问题并提供说明性信息。

然后，投标人制定答复内容，并在招标文件规定的日期之前将其交给买方。

选择最佳供应商（有时称为“供方选择”）通常基于多种标准，如经验、参考信息、价格和能否及时交付。可能会给这些变量分配权重，以反映每个变量的相对重要性。买方会根据选择合适供应商的标准对供应商投标做出评估。买方和供应商谈判条款和条件。从成本到交付和付款日期，再到工作地点、知识产权的所有权等，所有一切几乎都可以谈判。

项目团队可能会定期开会，以确定他们未来在哪些方面可以做得更好（经验教训），以及他们如何在即将到来的迭代中对过程做出改进和提出质疑（回顾）。工作方式会不断演变，以产生更好的成果。

在整个项目期间，项目团队会开发并分享显性知识。显性知识可以使用文字、图片或数字轻松地进行编辑。例如，达成新过程的步骤是可以记录的显性知识。可以使用信息管理工具（如手册、登记册、网络搜索和数据库）将人员与信息连接起来，以便传递显性知识。

另一种知识是隐性知识。隐性知识难以表达，因为它无法进行编辑。隐性知识由经验、见解和实践知识或技能组成。通过将需要相关知识的人与拥有这些知识的人连接起来，可以分享隐性知识。这可以通过人际交往、访谈、工作跟随、论坛讨论、研讨会或其他类似方法来实现。

由于项目是临时性的，一旦项目完成，大部分知识就会丢失。关注知识转移对组织而言非常有用，因为它不仅能提供项目所要实现的价值，而且能使组织从运行项目的经验中获得知识。

项目通常有一个发起人，具体视组织的不同情况而定。项目发起人的决策领导力超出项目经理和项目团队的权限和职权。项目发起人的积极参与和监督为项目经理和项目团队提供支持，并最终推动取得项目成果。发起人还将项目团队与组织高级管理层的战略和全局视角联系起来。

和其他职能一起，发起人还履行下列职能：

如果团队无法做出决策，或者团队意见不一，发起人可以调解意见冲突并促进决策过程。

交付不仅仅只是范围和需求。范围和需求聚焦于需要交付的内容。质量聚焦于需要达到的绩效水平。质量需求可能会反映在完成标准、完成的定义、工作说明书或需求文件中。

与质量相关的很多成本都是由发起组织承担的，并反映在政策、程序和工作过程中。例如，治理如何执行工作的组织政策和规定工作过程的程序，通常是组织质量政策的一部分。尽管管理费用、培训和过程审计的成本是由项目使用的，但它们却由组织承担。在各个项目中，必须在过程和产品的质量需要与满足这些需要的相关成本之间取得平衡。

与产品或可交付物相关的属性包括但不限于：

发现缺陷的时间越晚，纠正缺陷的成本就越高。这是因为设计和开发工作通常已经基于有缺陷的组件而进行。此外，随着生命周期的进展，活动的调整成本有所增加，因为更多的干系人会受到影响。变更成本曲线可以描述这种现象（见图 2-22）。

为了应对变更成本曲线的影响，项目团队会设计项目过程，以便将质量纳入进来。这种方法可以包括质量分析师与设计师和工程师合作，了解并确定如何在项目生命周期的每个步骤以最佳方式达到质量要求。积极主动地开展质量工作有助于避免较高的变更成本，该成本与解决生命周期后期发现的质量问题相关。与解决影响数百个单元的组件问题或者召回影响数千客户的产品相比，解决两名工程师之间的设计问题要更快、更具成本效率。

交付绩效域是在规划绩效域中所执行所有工作的累积。交付节奏是基于开发方法和生命周期绩效域中工作的结构方式。项目工作绩效域通过建立各种过程、管理实物资源、管理采购等促使交付工作。项目团队成员为有关干系人在此绩效域中执行工作。创建交付的工作性质会影响项目团队驾驭不确定性的方式，该不确定性会对项目产生影响。

项目的关键绩效指标 (KPI) 是用于评估项目成功与否的可量化测量指标KPI 有两种类型：提前指标和滞后指标。

就其本身而言，KPI 只是在使用之前没有实际用处的测量指标。讨论提前指标和滞后指标并视情况确定需要改进的方面可对绩效产生积极影响。

交付测量指标与在制品相关联。这些测量指标经常在适应型方法的项目中使用。

报告是正式的信息记录或摘要。报告可向干系人传达有关（通常是摘要级的）信息。报告通常会提供给对项目状态感兴趣的干系人，如发起人、企业所有者或项目管理办公室 (PMO)。

在精益环境中，信息发射源被称为目视管理。目视管理说明了较容易地比较实际和预期绩效的过程，它使用可视化提示来显示一个过程。从要交付的商业价值到已开始的任务，可以对其中所有层级的信息进行目视管理。它们应该是显而易见的，让任何人都能看到。

所有项目中必然存在不确定性。因此，任何活动的影响都无法准确预测，而且可能会产生一系列结果。对项目目标有益的潜在结果称为机会；对目标产生负面影响的潜在结果称为威胁。这些机会和威胁共同构成了项目风险。有多种方案应对不确定性：

模糊性有两类：概念模糊性和情景模糊性。当人们以不同的方式使用类似的术语或论点时，就会出现概念模糊性，即缺乏有效的理解。例如“上周报告的进度处于正轨”这句话不明确。到底是上周进度处于正轨，还是这个情况是上周报告的，这些都不明确。此外，对于何谓“处于正轨”，人们可能也会有疑问。通过正式确立共同的规则并定义术语（例如“处于正轨”的含义），可以减少这种类型的模糊性。

当可能出现多个结果时，就会出现情景模糊性。有多个选项解决一个问题是情景模糊性的一种形式。探究模糊性的解决方案包括渐进明细、实验和使用原型法。

复杂性是由于人类行为、系统行为和模糊性而难以管理的项目集、项目或其环境的特征。当有许多相互关联的影响以不同的方式表现出来并相互作用时，就会存在复杂性。在复杂的环境中，单个要素的累积最终导致无法预见或意外的结果，这种情况并不少见。复杂性的影响是使人们无法准确预测发生任何潜在结果的可能性，甚至无法知道可能会出现什么样的结果。处理复杂性有许多方法，一些方法是基于系统，一些方法需要重新构建，而其他方法则是基于过程。

交付不仅仅只是范围和需求。范围和需求聚焦于需要交付的内容。质量聚焦于需要达到的绩效水平。质量需求可能会反映在完成标准、完成的定义、工作说明书或需求文件中。

与质量相关的很多成本都是由发起组织承担的，并反映在政策、程序和工作过程中。例如，治理如何执行工作的组织政策和规定工作过程的程序，通常是组织质量政策的一部分。尽管管理费用、培训和过程审计的成本是由项目使用的，但它们却由组织承担。在各个项目中，必须在过程和产品的质量需要与满足这些需要的相关成本之间取得平衡。

复杂性是由于人类行为、系统行为和模糊性而难以管理的项目集、项目或其环境的特征。当有许多相互关联的影响以不同的方式表现出来并相互作用时，就会存在复杂性。在复杂的环境中，单个要素的累积最终导致无法预见或意外的结果，这种情况并不少见。复杂性的影响是使人们无法准确预测发生任何潜在结果的可能性，甚至无法知道可能会出现什么样的结果。处理复杂性有许多方法，一些方法是基于系统，一些方法需要重新构建，而其他方法则是基于过程。

裁剪涉及对有关方法、治理和过程进行考虑后作出调整，使之更适合特定环境和当前项目。它涉及对人员要素、所用过程和所用工具进行分析、设计和精心修改。裁剪过程包括四个步骤：

虽然裁剪过程通常由项目干系人进行，但裁剪的界限和方法则受制于组织指南。组织治理有助于确保项目团队之间的外部接口正确匹配，并以裁剪考虑因素的形式提供指导。

裁剪是对有关项目管理方法、治理和过程深思熟虑后作出调整，使之更适合特定环境和当前工作。

在项目环境中，裁剪会考虑开发方法、过程、项目生命周期、可交付物以及与其共同参与工作人员的选择。裁剪过程受《项目管理标准》[1] 中的指导性项目管理原则、组织价值观和组织文化的驱动。例如，如果核心的组织价值观是“以客户为中心”，那么为启发需求和确认范围而选择的活动就要倾向于采用以客户为中心的方法。这种方法符合“有效地干系人参与”这一原则。同样，在项目的整个生命周期，风险偏好较低的组织可能有许多流程和程序来指导项目。而在同一市场上运营但风险承受能力高的类似公司可能会有较少的流程和程序。在这两个示例中，尽管各个组织的偏好、流程和程序各不相同，但它们都遵守“优化风险应对”这一原则。

使用裁剪需要谨慎选择和调整多个项目因素，无论是否使用“裁剪”标签皆是如此。

进行裁剪时需要了解项目背景、目的和运行环境。项目的运行环境非常复杂，需要平衡下列潜在的互相矛盾的要求，包括但不限于：

需要理解、评估和平衡这些因素，以便为项目创造切实可行的运行环境。

有些情况可能会限制项目团队调整其方法的程度，例如，当组织政策要求使用特定方法或合同强制规定了某种方法时。

裁剪旨在更好地满足组织、运行环境和项目的需要。许多变量都是裁剪过程的考虑因素，包括项目的重要性和所涉及干系人的数量。以这些变量为例，关键项目（如建造核反应堆）所需的严谨、制衡和报告的要求显然要远远高于建造新办公楼。

同样，对于一个由 200 人组成的项目团队来说，一个由 10 人组成的项目团队所需的沟通和工作协调也是不够的。过程太少会忽略可支持有效项目管理的关键活动，而如果使用的过程多于所需数量，则引发成本高昂和浪费。因此，裁剪有助于对运行环境和项目需求进行适当管理。

用于交付项目的结构既可以规模很大也可以很小，既可以非常严密也可以是轻量级，既可以是稳健型的也可以是简单的。没有一种单一的方法可以一直应用于所有项目。相反，裁剪应反映每个项目的规模、持续时间和复杂性，并应适应组织所在的行业、组织文化和项目管理成熟度。

裁剪可为组织带来直接和间接的收益。这些属性包括但不限于：

可以裁剪的项目方面包括：

第 3.3.1 节至第 3.3.4 节将更详细地探讨其中的每一项。

对项目进行裁剪受许多属性影响。这些属性包括但不限于：

项目团队应该询问关于每个属性的问题，以帮助指导他们完成裁剪过程。对这些问题的回答有助于识别裁剪过程、交付方法、生命周期、工具、方法和工件的需要。

裁剪过程并非单一的，一次性的过程。在渐进明细过程中，项目团队的工作方式、产品或可交付物的演变方式，以及其他知识等问题将表明哪些进一步的裁剪可以带来改进。审查点、阶段关口和回顾会议都提供了必要的检查和调整过程、开发方法和交付频率的机会。

让项目团队参与过程改进可以培养主人翁意识，并表现出对实施持续改进和质量的承诺。让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任。项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式。

图 3-6 中显示了增加、取消和变更这些过程的概念。

组织的裁剪方式本身就可以被裁剪。但大多数组织采取了以上描述的四个步骤中的部分或全部步骤。他们使用的要素包括选择初始方法、对组织进行裁剪、对项目进行裁剪以及实施持续改进（如图 3-7 所示）。

对于许多企业而言，不确定性加大、变革速度加快、竞争愈发激烈以及客户赋能增加意味着它们需要在日益复杂的环境中创造价值。实施新战略举措和快速变革的能力正在成为一个关键的差异化因素。这些变革也正在对 PMO 产生更大的压力，以展示它们对收益实现和价值创造的贡献PMO 通过以下方式不断演变，以应对这些挑战：

对项目进行裁剪受许多属性影响。这些属性包括但不限于：

项目团队应该询问关于每个属性的问题，以帮助指导他们完成裁剪过程。对这些问题的回答有助于识别裁剪过程、交付方法、生命周期、工具、方法和工件的需要。

与产品或可交付物相关的属性包括但不限于：

Allan Drexler 和 David Sibbet 开发了团队绩效模型，共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段，第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。

对文化进行评估包括以下方面的考虑因素：

通过对这些属性进行评估，可以为项目指定有关参与、过程和工具的裁剪决策。图 3-5 中描述了这些取消和增加的过程，其中“X”代表取消的过程，虚线框代表增加的试验过程

裁剪过程并非单一的，一次性的过程。在渐进明细过程中，项目团队的工作方式、产品或可交付物的演变方式，以及其他知识等问题将表明哪些进一步的裁剪可以带来改进。审查点、阶段关口和回顾会议都提供了必要的检查和调整过程、开发方法和交付频率的机会。

让项目团队参与过程改进可以培养主人翁意识，并表现出对实施持续改进和质量的承诺。让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任。项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式。

图 3-6 中显示了增加、取消和变更这些过程的概念。

组织的裁剪方式本身就可以被裁剪。但大多数组织采取了以上描述的四个步骤中的部分或全部步骤。他们使用的要素包括选择初始方法、对组织进行裁剪、对项目进行裁剪以及实施持续改进（如图 3-7 所示）。

首字母缩略词“PMO”可以指项目组合、项目集或项目管理办公室。在第 7 版《 PMBOK 指南》中，项目管理办公室 (PMO) 是一种管理结构，其对与项目相关的治理过程进行标准化，并促进资源、工具、方法论和技术共享。认识到在不同组织之间，甚至在同一组织内部，PMO 的特点和功能各不相同，本附录概述了各种PMO 的共同属性，并讨论了 PMO 如何支持项目工作。

Jeff Hiatt 开发了 ADKAR 模型，该模型重点关注个人在适应变革时所经历的五个连续步骤：

裁剪涉及对有关方法、治理和过程进行考虑后作出调整，使之更适合特定环境和当前项目。它涉及对人员要素、所用过程和所用工具进行分析、设计和精心修改。裁剪过程包括四个步骤：

虽然裁剪过程通常由项目干系人进行，但裁剪的界限和方法则受制于组织指南。组织治理有助于确保项目团队之间的外部接口正确匹配，并以裁剪考虑因素的形式提供指导。

模型是反映现实情况的小规模、简化的视图，可呈现优化工作过程和人力投入的场景、策略或方法。

它有助于解释事物在现实世界中的运作原理，还可以塑造行为并指向解决问题或满足需要的方法。有些模型是在考虑项目和项目团队的情况下开发的，而其他模型则属于较为通用的模型。在可行的情况下，本节中的模型将在其适用于项目情形时予以介绍。本节中的内容未介绍如何开发或创建新模型。

所介绍的模型描述提供了一个高层级视图。项目团队成员和其他干系人可以参考许多来源（例如，PMI的标准产品库和 PMIstandards+™），以获得有关模型的更完整的描述和说明。

情境领导力模型是一系列领导力模型中的一种。正如项目团队对过程、方法、生命周期和开发方法进行裁剪一样，项目团队也会对领导风格进行裁剪。情境领导力模型描述了裁剪领导者的领导风格以满足个人和项目团队需要的方法。以下是情境领导力模型的两个示例。

Jeff Hiatt 开发了 ADKAR 模型，该模型重点关注个人在适应变革时所经历的五个连续步骤：

John Kotter 介绍了面向转型组织的领导变革八步法。这是一种自上而下的方法，在这种方法中，变革的需要和方法源于组织的最高层，然后通过组织的管理层向下传达给变革接收者。这八个步骤是：

William Bridges 的转变模型可让人们了解组织变革发生时个人的心理状况。这一模型区分了变革和转变。变革是情境性的，无论人们能否完成转变，都会发生变革。转变是一个心理过程，人们逐渐接受新情况的细节以及随之发生的变革。

该模型识别了与变革相关的三个转变阶段：

项目团队会经历不同的发展阶段。了解团队在发展过程中所处的阶段有助于项目经理为项目团队及其成长提供支持。第 4.2.6.1 节和第 4.2.6.2 节中介绍的两个模型说明了项目团队如何经历不同的阶段成为高绩效项目团队。

Bruce Tuckman 将团队发展的阶段表述为形成阶段、震荡阶段、规范阶段和成熟阶段。后来 Tuckman

又增加了第五个阶段 — 解散阶段。

此模型中的项目团队文化开始于形成阶段，并会在其余的发展阶段不断演进。虽然此模型显示了一个线性进展的过程，但项目团队可能会在这些阶段之间来回反复。此外，并非所有项目团队都能达到成熟阶段，有些甚至无法达到规范阶段。

Allan Drexler 和 David Sibbet 开发了团队绩效模型，共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段，第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。

第 4.2.7.1 节至第 4.2.7.5 节中描述的模型涵盖了广泛的主题，包括冲突管理、谈判、规划、过程组和凸显模型。

招标过程包括制定和公布招标文件、举行投标人会议和选择投标人。

招标文件可以包括：

这三种类型涵盖了大多数招标需要。还有其他招标文件，但它们往往是针对特定行业的。

一旦发出招标文件，买方通常会举行投标人会议，以回答投标人的问题并提供说明性信息。

然后，投标人制定答复内容，并在招标文件规定的日期之前将其交给买方。

选择最佳供应商（有时称为“供方选择”）通常基于多种标准，如经验、参考信息、价格和能否及时交付。可能会给这些变量分配权重，以反映每个变量的相对重要性。买方会根据选择合适供应商的标准对供应商投标做出评估。买方和供应商谈判条款和条件。从成本到交付和付款日期，再到工作地点、知识产权的所有权等，所有一切几乎都可以谈判。

项目管理过程可以按逻辑分组，分为项目管理输入、工具和技术以及输出，为了满足组织、干系人和项目的需要会对它们进行裁剪。

过程组不是项目阶段。在项目生命周期的每个阶段内，各个过程组会相互作用。所有这些过程都有可能在一个阶段内发生。在一个阶段或生命周期内，各个过程可能会迭代发生。过程迭代的次数和过程间的相互作用因具体项目的需要而有所不同。

采用基于过程的方法的项目可以将以下五个过程组作为组织结构：

这些过程组与交付方法、应用领域（例如市场营销、信息服务和会计）或行业（例如建筑、航空航天和电信）相互独立。在基于过程的方法中，一个过程的输出通常成为另一个过程的输入，或者成为项目或项目阶段的可交付物。例如，在规划过程组中生成的项目管理计划和项目文档（例如风险登记册、假设日志等）是执行过程组的输入，在执行过程组中会对相关工件进行更新。

第 4.2.7.1 节至第 4.2.7.5 节中描述的模型涵盖了广泛的主题，包括冲突管理、谈判、规划、过程组和凸显模型。

估算方法用于对某一项目的工作、时间或成本进行近似估算。

会议是吸引项目团队和其他干系人参与的重要方式。它们是整个项目的主要沟通方式。

本次会议上所做的决定将被记录下来并传达给有关的干系人。此会议也可称为变更控制会议。

本节中描述的方法不适合于上述特定类别；但它们是用于项目的多种目的的常用方法。

在项目开始前或开始时创建的文件，涉及与项目有关的战略、商业或高层级的信息。战略工件是在项目开始时开发的，通常不会发生变化，但在整个项目期间可能会对其进行审查。

日志和登记册用于记录项目不断演变的方面。它们会在整个项目期间得到更新。日志和登记册这两个词有时可以互换使用。我们经常看到用风险登记册或风险日志这两个词是指同一个工件。

沟通规划会与干系人识别、分析、优先级排序和参与的内容有所重叠，这些内容会在干系人绩效域（第 2.1 节）中描述。沟通在争取干系人有效参与方面是最重要的因素。为项目规划沟通时需要考虑以下因素：

可能存在不同类别的信息，例如内部信息和外部信息，敏感信息和公开信息，或者一般信息和详细信息。分析干系人、信息需求和信息类别为制定项目的沟通过程和计划奠定了基础。

在精益环境中，信息发射源被称为目视管理。目视管理说明了较容易地比较实际和预期绩效的过程，它使用可视化提示来显示一个过程。从要交付的商业价值到已开始的任务，可以对其中所有层级的信息进行目视管理。它们应该是显而易见的，让任何人都能看到。

报告是正式的信息记录或摘要。报告可向干系人传达有关（通常是摘要级的）信息。报告通常会提供给对项目状态感兴趣的干系人，如发起人、企业所有者或项目管理办公室 (PMO)。

项目通常有一个发起人，具体视组织的不同情况而定。项目发起人的决策领导力超出项目经理和项目团队的权限和职权。项目发起人的积极参与和监督为项目经理和项目团队提供支持，并最终推动取得项目成果。发起人还将项目团队与组织高级管理层的战略和全局视角联系起来。

和其他职能一起，发起人还履行下列职能：

如果团队无法做出决策，或者团队意见不一，发起人可以调解意见冲突并促进决策过程。

发起人展现的某些行为可以帮助团队有效地开展工作，从而改善项目成果：

首字母缩略词“PMO”可以指项目组合、项目集或项目管理办公室。在第 7 版《 PMBOK 指南》中，项目管理办公室 (PMO) 是一种管理结构，其对与项目相关的治理过程进行标准化，并促进资源、工具、方法论和技术共享。认识到在不同组织之间，甚至在同一组织内部，PMO 的特点和功能各不相同，本附录概述了各种PMO 的共同属性，并讨论了 PMO 如何支持项目工作。

《项目管理标准》规定，项目是组织内部价值交付系统的一部分。这些 PMO 可以支持该系统，并且是该系统的一部分。正如项目团队需要特定能力来交付成果一样，PMO 也是如此。有效的 PMO 具有三大贡献，它们可为价值交付提供支持：

对于许多企业而言，不确定性加大、变革速度加快、竞争愈发激烈以及客户赋能增加意味着它们需要在日益复杂的环境中创造价值。实施新战略举措和快速变革的能力正在成为一个关键的差异化因素。这些变革也正在对 PMO 产生更大的压力，以展示它们对收益实现和价值创造的贡献PMO 通过以下方式不断演变，以应对这些挑战：

过去十年，项目管理领域的很多概念已逐步发生转变。将成功定义为满足范围、进度和预算目标等观点已经转变为测量项目的价值和成果（而非输出）。产品管理与这种价值观点保持一致，并增加了一种更长时间框架的观点。这些概念如表 X4-1 所示。

本附录提供了有关产品开发的信息，这些信息提出了团队需要思考的裁剪考虑因素。它描述了产品和服务在使用过程中以及在其使用寿命期间如何继续发展和演变。就本附录而言，产品、产品管理和产品生命周期的定义为：

产品。产品是指可以量化的生产出的工件，既可以是最终制品，也可以是组件制品。

产品管理。产品管理是指将人员、数据、过程和业务系统整合，以便在整个产品生命周期中创建、维护和不断发展产品或服务。

产品生命周期。产品生命周期是指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

考虑到这些定义，产品超出了项目生命周期。它们的运作方式更像是长期运行的项目集，这些项目集重点关注最大化收益实现。例如：

持续开发对许多因素都有影响，包括（但不限于）资金提供模式、人员配备模式、开发和维持实践。

过去十年，项目管理领域的很多概念已逐步发生转变。将成功定义为满足范围、进度和预算目标等观点已经转变为测量项目的价值和成果（而非输出）。产品管理与这种价值观点保持一致，并增加了一种更长时间框架的观点。这些概念如表 X4-1 所示。

本附录提供了有关产品开发的信息，这些信息提出了团队需要思考的裁剪考虑因素。它描述了产品和服务在使用过程中以及在其使用寿命期间如何继续发展和演变。就本附录而言，产品、产品管理和产品生命周期的定义为：

产品。产品是指可以量化的生产出的工件，既可以是最终制品，也可以是组件制品。

产品管理。产品管理是指将人员、数据、过程和业务系统整合，以便在整个产品生命周期中创建、维护和不断发展产品或服务。

产品生命周期。产品生命周期是指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

考虑到这些定义，产品超出了项目生命周期。它们的运作方式更像是长期运行的项目集，这些项目集重点关注最大化收益实现。例如：

持续开发对许多因素都有影响，包括（但不限于）资金提供模式、人员配备模式、开发和维持实践。

自 2010 年以来，PMI 的标准计划除了包括从业者开发标准的经验外，还包括了相关研究。在更新许多标准文件（包括《项目管理标准》）时，学术研究、市场研究、焦点小组和从业者经验都已作为这些标准文件的输入。

早在 2012 年，研究表明项目管理标准正从规定性、基于过程的标准转变为需要反思才能应用于实践的标准。自那时以来，PMI 的许多标准都已转变为基于原则的标准，例如《项目集管理标准》第 3 版和《项目组合管理标准》第 4 版。此外，在为ISO 标准的开发提供支持过程中，PMI 参与了 ISO/TC 258 的讨论，该讨论指出需要转向基于叙述或基于原则的方法，而不是基于过程的方法。

审阅团队和征求意见稿参与者的评论意见一致确认《项目管理标准》将从基于过程的方法转向基于原则的标准，以符合研究结果和从业者的需要。

在更新《项目管理标准》之前，PMI 进行了意义重大的研究并查阅了大量资料，包括：

研究分析的结论是，更多的组织正在采用多种类型的项目管理方法。有些组织正在逐步采用混合型方法，将预测型和适应型实践结合起来。组织和项目团队正在根据行业、组织和项目的需要对其方法进行裁剪。这些调查结果表明，PMI 标准需要反映更具整体性和包容性的项目管理视角，这种管理视角适用于预测型、混合型和适应型方法。

以下所有这些信息都为探索开发过程提供了深入见解：

该标准由三个部分组成：引论、价值交付系统和项目管理原则。

“引论”部分包括与项目管理相关的关键术语和概念。这些信息大部分与以前的版本一致。

“价值交付系统”部分的内容借鉴了 PMI 基础标准的内容以及与收益实现管理和组织敏捷性相关的研究。这些内容在呈现时聚焦于交付价值，其中还包含有创造价值的各种方式。

在整个开发和验证过程中“项目管理原则”部分始终在不断演变。这些原则的初步概念是通过先前讨论的研究确定的。开发团队的成员采取个人研究与协同努力相结合的方式开展工作，以确定潜在的原则，然后将它们归入相近的类别。开发团队对每个类别进一步分析和分解，将与每个类别相关的关键词列表包含进来。潜在的类别和关键词先被编入初稿，然后由整个开发团队审核和评论，以确保各项原则的意图会在草案中得到体现。

必须指出的是，这些原则具有广泛的基础。这些原则中的任何内容都不是教条，不具有限制性或规定性。这些原则与《 PMI 道德与专业行为规范》中的内容一致，但并非重复该文件。

由于每个项目和组织都不尽相同，所以不可能产生“正确的原则”。因此，这些原则旨在设计成为项目工作人员的指南。项目专业人士和其他项目工作者可以努力与这些原则保持一致，但这些原则并非旨在为管理项目提供操作指南。

在整个制定过程中，PMI 举办了多场全球研讨会，展示了向基于原则的标准这一转变，并请研讨会参加者探讨项目管理的指导原则。这些研讨会在爱尔兰都柏林（PMI 全球大会 — 欧洲、中东和非洲）、印度班加罗尔、巴西巴西利亚、加拿大渥太华（PMI 全球执行理事会会议）、美国宾夕法尼亚州费城（PMI 全球大会）和中国北京举行。这些研讨会成为开发团队工作的输入，也成为开发过程中的验证检查点。

项目管理行业和项目管理方式的不断变化支持采用一种规定性较弱的标准。行业研究、具有广泛行业代表性的全球参与以及迭代审查过程塑造并验证了从基于过程的标准向基于原则的标准这一转变。未来的团队可以评估《项目管理标准》中所体现的这一转变的影响，并使用这些信息来增强或修订未来的版本。

自 1987 年以来《项目管理标准》一直代表着基于过程的项目管理标准《 PMBOK 指南》中包含的《项目管理标准》与一系列业务过程有关的项目管理准则和职能相保持一致。这些业务过程支持以下持续且可预测的实践：

在支持良好实践方面，虽然这些做法是有效的，但从本质上看，基于过程的项目管理标准是规定性的。随着项目管理在按比以往更快的速度发展，过去基于过程导向的版本难以为继，无法反映价值交付的整个大环境。因此，本版指南转而采用基于原则的标准，为有效的项目管理提供支持，并更多地关注预期成果，而非可交付物。

在本版标准部分逐步发展过程中，来自全球各地不同行业和组织、担任不同职位、实施不同类型项目的从业者为该标准的草案编撰贡献了力量，并/或提供了反馈意见。此外，参与第 7 版《 PMBOK 指南》编写的各位负责人和工作人员还审阅了其他知识体系和专注于项目管理的著作，来探究这些资料中蕴含的有关项目管理原则的概念。这些共同的努力凸显了各界对我们的强有力支持，为我们确认本版指南中的指导原则以适用于项目管理涉及的整个范围提供了支持。

迄今为止，全球项目管理界已认同应将该标准转变为一份原则声明。这些原则声明充分体现并总结了项目管理实践的公认目标及其核心功能。这些原则声明还提供了广泛的参考因素，项目团队能够在这些参考因素范围内开展工作，并提供众多方法来契合这些原则的意图。

借助这些原则声明，PMI 提供了整个价值交付环境中有效的项目管理方法：从预测型到适应型，以及中间的各种方法。这些基于原则的方法还与《项目集管理标准（第 3 版和第 4 版）和《项目组合管理标准》（第 4 版）的发展保持一致《项目组合、项目集和项目的风险管理标准》和《收益实现管理：实践指南》，这两个标准是全球主题专家团队基于原则的方法开发的新产品的代表。

本版《项目管理标准》或《项目管理知识体系指南》中的任何内容都不否定与过去版本中基于过程的方法的一致性。对于指导其项目管理能力、调整其方法论并评估其项目管理能力，很多组织和从业人员仍然认为基于过程的方法非常有用。这种方法与新版本的内容仍是相关的。

本版《 PMBOK 指南》的另一个重要变化是从系统视角论述项目管理。这一转变始于将系统视角的价值交付作为《项目管理标准》的一部分，并继续呈现《 PMBOK 指南》的内容。该“价值交付系统”部分改变了原有视角，即从项目组合、项目集和项目治理到重点关注将它们与其他业务能力结合在一起的价值链，再进一步推进到组织的战略、价值和商业目标。在项目管理的背景下《项目管理标准》和《 PMBOK 指南》强调，项目不只是产生输出，更重要的是要促使这些输出推动实现成果，而这些成果最终会将价值交付给组织及其干系人。

这种系统视角反映了从过去版本的《 PMBOK 指南》中的“知识领域”转变为八个绩效域。绩效域是一组对有效地交付项目成果至关重要的相关活动。总的来说，绩效域所代表的项目管理系统体现了彼此交互、相互关联且相互依赖的管理能力，这些能力只有协调一致才能实现期望的项目成果。随着各个绩效域彼此交互和相互作用，变化也会随之发生。项目团队要有整体系统思维的意识，不断审查、讨论、适应并应对这些变化，而非只是关注发生变化的具体绩效域。遵照《项目管理标准》中的“价值交付系统”这一概念，团队会通过以成果为中心的测量指标，而非按照各个过程或生成的工件、计划等来对各绩效域中的有效绩效作出评估。

原先版本的《 PMBOK 指南》强调必须对项目管理方法进行裁剪，使之适应于各项目的独有特征及其运行背景。第 6 版明确包括了相关考虑因素，以帮助项目团队思考如何对其项目管理方法进行裁剪。这些内容包含在各知识领域章节的前言部分，同时介绍了各类项目环境的考虑因素。本版《 PMBOK 指南》特设“裁剪”一章，对这项内容作出了进一步阐述。

本版指南新增了“模型、方法和工件”一章，为支持项目管理提供了高层级组合的模型、方法和工件。

这一章中有原先版本指南中为项目管理提供支持的工具、技术和输出的链接，但对团队应在何时、如何使用哪种工具未做出规定。

最后一个变化反映了《 PMBOK 指南》发行史上最重要的创新，即推出了 PMIstandards+™ 这一交互式数字平台，该平台融合了当下、新兴和未来的实践、方法、工件及其他有用的信息。这些数字内容更好地反映了项目管理知识体系的动态性PMIstandards+ 向项目管理从业人员和其他干系人提供了更加丰富、范围更加广泛的信息和资源，这些信息和资源能够更加快速地顺应项目管理领域中的发展和变化。这些内容根据行业板块、项目类型或其他特征阐述了具体实践、方法或工具如何适用于具体的项目PMIstandards+首先介绍了《 PMBOK 指南》第 6 版的输入、工具和技术以及输出，同时会继续纳入支持项目管理发展的新资源。展望未来《项目管理标准》和 《 PMBOK 指南》的用户可以在 PMIstandards+ 中找到补充印刷版出版物的丰富信息。

下图说明了项目《项目管理标准》的修订内容，以及《 PMBOK 指南》从第 6 版到第 7 版的变化，此外还有与 PMIstandards+ 数字平台的连接。

自 1987 年以来《项目管理标准》一直代表着基于过程的项目管理标准《 PMBOK 指南》中包含的《项目管理标准》与一系列业务过程有关的项目管理准则和职能相保持一致。这些业务过程支持以下持续且可预测的实践：

在支持良好实践方面，虽然这些做法是有效的，但从本质上看，基于过程的项目管理标准是规定性的。随着项目管理在按比以往更快的速度发展，过去基于过程导向的版本难以为继，无法反映价值交付的整个大环境。因此，本版指南转而采用基于原则的标准，为有效的项目管理提供支持，并更多地关注预期成果，而非可交付物。

在本版标准部分逐步发展过程中，来自全球各地不同行业和组织、担任不同职位、实施不同类型项目的从业者为该标准的草案编撰贡献了力量，并/或提供了反馈意见。此外，参与第 7 版《 PMBOK 指南》编写的各位负责人和工作人员还审阅了其他知识体系和专注于项目管理的著作，来探究这些资料中蕴含的有关项目管理原则的概念。这些共同的努力凸显了各界对我们的强有力支持，为我们确认本版指南中的指导原则以适用于项目管理涉及的整个范围提供了支持。

迄今为止，全球项目管理界已认同应将该标准转变为一份原则声明。这些原则声明充分体现并总结了项目管理实践的公认目标及其核心功能。这些原则声明还提供了广泛的参考因素，项目团队能够在这些参考因素范围内开展工作，并提供众多方法来契合这些原则的意图。

借助这些原则声明，PMI 提供了整个价值交付环境中有效的项目管理方法：从预测型到适应型，以及中间的各种方法。这些基于原则的方法还与《项目集管理标准（第 3 版和第 4 版）和《项目组合管理标准》（第 4 版）的发展保持一致《项目组合、项目集和项目的风险管理标准》和《收益实现管理：实践指南》，这两个标准是全球主题专家团队基于原则的方法开发的新产品的代表。

本版《项目管理标准》或《项目管理知识体系指南》中的任何内容都不否定与过去版本中基于过程的方法的一致性。对于指导其项目管理能力、调整其方法论并评估其项目管理能力，很多组织和从业人员仍然认为基于过程的方法非常有用。这种方法与新版本的内容仍是相关的。

本版《 PMBOK 指南》的另一个重要变化是从系统视角论述项目管理。这一转变始于将系统视角的价值交付作为《项目管理标准》的一部分，并继续呈现《 PMBOK 指南》的内容。该“价值交付系统”部分改变了原有视角，即从项目组合、项目集和项目治理到重点关注将它们与其他业务能力结合在一起的价值链，再进一步推进到组织的战略、价值和商业目标。在项目管理的背景下《项目管理标准》和《 PMBOK 指南》强调，项目不只是产生输出，更重要的是要促使这些输出推动实现成果，而这些成果最终会将价值交付给组织及其干系人。

这种系统视角反映了从过去版本的《 PMBOK 指南》中的“知识领域”转变为八个绩效域。绩效域是一组对有效地交付项目成果至关重要的相关活动。总的来说，绩效域所代表的项目管理系统体现了彼此交互、相互关联且相互依赖的管理能力，这些能力只有协调一致才能实现期望的项目成果。随着各个绩效域彼此交互和相互作用，变化也会随之发生。项目团队要有整体系统思维的意识，不断审查、讨论、适应并应对这些变化，而非只是关注发生变化的具体绩效域。遵照《项目管理标准》中的“价值交付系统”这一概念，团队会通过以成果为中心的测量指标，而非按照各个过程或生成的工件、计划等来对各绩效域中的有效绩效作出评估。

原先版本的《 PMBOK 指南》强调必须对项目管理方法进行裁剪，使之适应于各项目的独有特征及其运行背景。第 6 版明确包括了相关考虑因素，以帮助项目团队思考如何对其项目管理方法进行裁剪。这些内容包含在各知识领域章节的前言部分，同时介绍了各类项目环境的考虑因素。本版《 PMBOK 指南》特设“裁剪”一章，对这项内容作出了进一步阐述。

本版指南新增了“模型、方法和工件”一章，为支持项目管理提供了高层级组合的模型、方法和工件。

这一章中有原先版本指南中为项目管理提供支持的工具、技术和输出的链接，但对团队应在何时、如何使用哪种工具未做出规定。

最后一个变化反映了《 PMBOK 指南》发行史上最重要的创新，即推出了 PMIstandards+™ 这一交互式数字平台，该平台融合了当下、新兴和未来的实践、方法、工件及其他有用的信息。这些数字内容更好地反映了项目管理知识体系的动态性PMIstandards+ 向项目管理从业人员和其他干系人提供了更加丰富、范围更加广泛的信息和资源，这些信息和资源能够更加快速地顺应项目管理领域中的发展和变化。这些内容根据行业板块、项目类型或其他特征阐述了具体实践、方法或工具如何适用于具体的项目PMIstandards+首先介绍了《 PMBOK 指南》第 6 版的输入、工具和技术以及输出，同时会继续纳入支持项目管理发展的新资源。展望未来《项目管理标准》和 《 PMBOK 指南》的用户可以在 PMIstandards+ 中找到补充印刷版出版物的丰富信息。

下图说明了项目《项目管理标准》的修订内容，以及《 PMBOK 指南》从第 6 版到第 7 版的变化，此外还有与 PMIstandards+ 数字平台的连接。