2.6.2 可交付物

项目通常有一个发起人,具体视组织的不同情况而定。项目发起人的决策领导力超出项目经理和项目团队的权限和职权。项目发起人的积极参与监督项目经理和项目团队提供支持,并最终推动取得项目成果。发起人还将项目团队组织高级管理层的战略和全局视角联系起来。
和其他职能一起,发起人还履行下列职能:
▶ 向团队沟通愿景、目标和期望。
▶ 成为项目和团队的拥护者。
▶ 促使高级管理层做出决策。
▶ 帮助获得资源
▶ 使项目与商业目标保持一致。
▶ 清除障碍。
▶ 解决项目团队职权之外的问题。
▶ 让高层管理人员注意到项目中出现的机会
▶ 在项目结束后密切关注项目成果,以确保实现预期的业务收益。发起人组织中的职位和从该职位看待问题的视角,使发起人能够在以下方面向团队提供关键支持:
▶ 愿景。制定和/或沟通项目的愿景和方向。
商业价值。始终与团队合作,保持与战略和商业目标的一致性。当市场、竞争和战略急剧波动且不断演变时,这可能需要频繁的互动来调整项目工作以适应不断变化的方向。
▶ 关注客户。平衡各个干系人的需要和优先级。当有多个干系人,特别是多个干系人的需要相互冲突时,可能有必要考虑干系人的需要的优先级并做出权衡。
▶ 决策。当做出的决策超出项目团队的职权范围时,应做出决策或指导相应的个人或群体做出决策。
如果团队无法做出决策,或者团队意见不一,发起人可以调解意见冲突并促进决策过程
激励发起人可通过让项目团队积极参与并向其提供支持,成为他们的激励源泉。
▶ 担责。发起人通常对项目成果担责,具体视角色的职权级别而定。在此角色中,他们可以接受或拒绝项目可交付物
引用
保持《PMBOK指南》的相关性
自从 1987 年《项目管理知识体系》 (PMBOK)形式首次推出以来《项目管理知识体系指南(简称“《 PMBOK指南》”)一直在逐步演进。同时我们认识到,项目管理的基本要素依然未变。这种逐步演进不仅涉及书本页数的增加,还涉及实质内容的显著且根本的变化。其中的一些主要变化请见下表:
《 PMBOK 指南》中主要变化的逐步演进情况

与原先各版《项目管理标准》和《 PMBOK 指南》一样,本版指南认识到项目管理的大环境在不断发展变化。仅就过去 10 年以来,推动各类产品、服务和解决方案中采用的软件呈指数增长。随着人工智能、基于云的能力和新的商业模式对创新和新的工作方式的驱动,软件能够促使这种增长继续变化。同时组织模式发生了转型,这引发了新的项目工作和团队结构,从而需要采用一系列广泛的方法来进行项目和产品交付,并要更多地关注成果而非可交付物。另外来自世界任何地方的个人贡献者均可加入项目团队,来承担更广泛的角色,并采用新的思考和协作方式。这些变化以及更多的因素使我们有机会重新考虑各种观点,为《项目管理标准》和《 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+ 数字平台的连接。

修订了《项目管理标准》 ,并将《 PMBOK 指南》和 PMIstandards+ 数字内容平台从第 6 版过渡到第 7 版
1.2 关键术语和概念
可以单独或共同使用多种组件(例如项目组合、项目集、项目、产品和运营)以创造价值。这些组件共同组成了一个符合组织战略的价值交付系统。图 2-1 显示了价值交付系统的一个示例,该系统有两个项目组合,它们包含了多个项目集和项目。该系统还显示了一个包含多个项目的独立项目集以及与项目组合或项目集无关的多个独立项目。任何项目或项目集都可能会包括产品。运营可以直接支持和影响项目组合、项目集和项目以及其他业务职能,例如工资支付、供应链管理等。项目组合、项目集和项目会相互影响,也会影响运营。

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

图 2-2. 价值交付系统 (示例 )的组件
价值交付系统中的组件创建了用于产出成果的可交付物。成果是某一过程或项目的最终结果或后果。聚焦成果、选择和决策强调了项目的长期绩效。成果可带来收益,收益是组织实现的利益。收益继而可创造价值,而价值是具有作用、重要性或实用性的事物。
2.1.1 价值交付组件
可以单独或共同使用多种组件(例如项目组合、项目集、项目、产品和运营)以创造价值。这些组件共同组成了一个符合组织战略的价值交付系统。图 2-1 显示了价值交付系统的一个示例,该系统有两个项目组合,它们包含了多个项目集和项目。该系统还显示了一个包含多个项目的独立项目集以及与项目组合或项目集无关的多个独立项目。任何项目或项目集都可能会包括产品。运营可以直接支持和影响项目组合、项目集和项目以及其他业务职能,例如工资支付、供应链管理等。项目组合、项目集和项目会相互影响,也会影响运营。

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

图 2-2. 价值交付系统 (示例 )的组件
价值交付系统中的组件创建了用于产出成果的可交付物。成果是某一过程或项目的最终结果或后果。聚焦成果、选择和决策强调了项目的长期绩效。成果可带来收益,收益是组织实现的利益。收益继而可创造价值,而价值是具有作用、重要性或实用性的事物。
2.1.2 信息流
当信息和反馈在所有组件之间以一致的方式共享时,价值交付系统最为有效,使系统与战略保持一致,并与环境保持协调。
图 2-3 显示了一个信息流模型,其中黑色箭头代表从高层领导到项目组合,项目组合到项目集和项目,然后到运营部门的信息。高层领导会与项目组合分享战略信息。项目组合与项目集和项目分享预期成果、收益和价值。项目集和项目的可交付物及其支持和维护信息一起传递给运营部门。
图 2-3 中的浅灰色箭头表示信息的反向流动。从运营部门到项目集和项目的信息表明对可交付物的调整、修复和更新。项目集和项目给项目组合提供实现预期成果、收益和价值方面的绩效信息和进展。项目组合会提供与高层领导一起对项目组合进行的绩效评估。此外,运营部门还提供有关组织战略推进情况的信息。

图 2-3. 信息流示例
2.2 组织治理系统
治理系统与价值交付系统协同运作,可实现流畅的工作流程、管理问题并支持决策。治理系统提供了一个框架,其中包含指导活动的职能和流程。治理框架可以包括监督、控制、价值评估、各组件之间的整合以及决策能力等要素。
治理系统提供了一个整合结构,用于评估与环境和价值交付系统的任何组件相关的变更、问题和风险。这些组件包括项目组合目标、项目集收益和项目生成的可交付物。
项目可以在一个项目集或项目组合内运作,也可以作为一个独立的活动进行。在一些组织中,项目管理办公室可能会为项目组合内的项目集和项目提供支持。项目治理包括定义用于批准变更和做出与项目相关的其他业务决策的职权。项目治理与项目集和/或组织治理保持一致。
2.3 与项目有关的职能
项目交付是由人驱动的。人们通过有效率且有效果地履行项目所必需的职能来实现这一目标。与项目相关的职能可由一个人或一组人履行,也可以包含在已定义的角色中。
协调集体工作对于任何项目的成功都至关重要。有不同类型的协调方式以适合不同的情况。有些项目受益于去中心化的协调,用这种协调方式,项目团队成员会进行自组织和自管理。其他项目则受益于由指定的项目经理或类似角色领导和指导的集中化协调。有些进行集中化协调的项目也可以受益于将自组织的项目团队纳入进来,让其承担部分工作。无论协调是如何进行的,项目团队与其他干系人之间的支持型领导模式和有意义的、持续的互动才是成功地取得成果的基础。
无论如何协调项目,项目团队的共同努力都能交付成果、收益和价值。项目团队可能得受到其他职能的支持,具体取决于可交付物、行业、组织和其他变量。第 2.3.1 节至第 2.3.8 节提供了项目中常见职能的示例,但这些示例并非完整列表。除这些职能外,可能还需要其他职能,以实现能产生预期成果的项目可交付物。项目需要、组织和环境会影响项目中使用的职能以及这些职能的执行方式。
2.3.1 提供监督和协调
具有此职能的人员通常通过精心安排项目工作,帮助项目团队实现项目目标。在项目团队内如何履行这一职能的具体情况可能因组织而异,但都可能包括领导规划、监督和控制活动。一些组织中,在项目前期,这一职能可能涉及一些评估和分析活动。此职能包括监督和开展工作以改善项目团队成员的健康、安全和整体福祉。
协调包括咨询管理层和业务单元领导的想法,以推进目标的实现、提高项目绩效或满足客户需要。它还可以包括协助进行商业分析、招标和合同谈判以及商业论证开发。
在项目可交付物最终确定后,但在项目正式结束之前,监督可以参与有关收益实现和维持的后继活动。此职能也可以为项目启动所在的项目组合和项目集提供支持。最后,需要裁剪此职能以适应组织。
2.3.2 提出目标和反馈
具有此职能的人员提供客户和最终用户的观点、见解和清晰指导。客户和最终用户并非总是同义词。本标准对客户的定义是:提出项目申请或提供项目资金的个人或群体。最终用户是将直接使用项目可交付物的个人或群体。
项目需要客户和最终用户就项目需求、成果和期望作出明确指导。在适应型和混合型项目环境中,项目更需要获得持续反馈,因为项目团队正在探索和开发特定增量中的产品要素。在某些项目环境中,客户或最终用户会参与到项目团队,以便进行定期审查和反馈。在某些项目中,客户代表会加入项目团队的工作。对客户和最终用户意见和反馈的需要取决于项目性质以及所需的指导或指引。
2.3.4 开展工作并贡献洞察
这一群体的人员会提供生产产品和实现项目成果所需的知识、技能和经验,可以在项目持续期间或有限时间内以全职或兼职方式开展工作。项目团队可以集中办公或者以虚拟方式工作,具体取决于环境因素。有些工作可能具有高度专业性,而其他工作则可以由具有多种技能的项目团队成员完成。
从代表组织不同部门的跨职能项目团队成员获得洞察可以提供多种内部观点,与关键业务部门建立联盟,并鼓励项目团队成员成为其职能领域内的变革推动者。随着项目可交付物的实施或移交到运营,这项工作可以扩展到支持职能(在项目开展期间或结束之后)。
2.3.6 提供业务方向和洞察
具有此职能的人员会指导并澄清项目方向或产品成果。它涉及根据商业价值、依赖关系以及技术或运营风险来确定需求或待办事项的优先级。具有此职能的人员向项目团队提供反馈,并为要开发或交付的下一个增量或要素设定方向。此职能涉及与其他干系人、客户及其项目团队互动,以定义产品方向。其目标是使项目可交付物的价值最大化。
在适应型和混合型环境中,可以使用特定的节奏提供方向和洞察。在预测型环境中,可以设定指定的检查点来呈现项目进展并提供有关项目进展的反馈。在某些情况下,业务方向可以与资金提供职能和资源提供职能相互影响。
3.1 成为勤勉、尊重和关心他人的管家

图 3-2. 成为勤勉、尊重和关心他人的管家
在不同的环境中,管家式管理 (stewardship) 的含义和应用会略有不同。管家式管理一方面涉及被委托看管某项事物,另一方面侧重于以负责任的方式规划、使用和管理资源,还有一方面是维护价值观和道德。
管家式管理包括在组织内部和外部的职责。在组织内,管家式管理包括:
▶ 运营时要做到与组织及其目标、战略、愿景、使命保持一致并维持其长期价值;
▶ 承诺并尊重项目团队成员的参与,包括薪酬、机会获得和公平对待;
▶ 勤于监督项目中使用的组织资金、材料和其他资源;
▶ 了解职权、担责和职责的运用是否适当(特别是身居领导岗位时)。组织外部的管家式管理包括在以下领域的职责:
▶ 环境可持续性以及组织对材料和自然资源的使用;
▶ 组织与外部干系人(例如其合作伙伴和渠道)的关系;
▶ 组织或项目对市场、社会和经营所在地区的影响;
▶ 提升专业化行业的实践水平。
管家式管理反映了对信任的理解和接受度以及产生和维持信任的行动和决定。管家既需遵守明确的职责,也需要遵守隐含的职责。这些职责可能包括以下方面:
▶ 诚信。管家在所有参与和沟通中都应做到诚实且合乎道德。管家需秉持最高标准,并反映组织员工所应坚守的价值观、原则和行为。管家作为楷模,并通过在其参与、工作活动和决策中践行和展现个人和组织价值观来建立信任。在项目管理背景下,这一职责通常要求管家建议团队成员、同职级人员和其他干系人考虑他们的言行、展现同理心、进行自我反思并乐于接受反馈。
▶ 关心。管家是其负责的组织事务的受托人,他们会认真监督这些事务。具有高绩效项目的专业人士总是会在严格规定的责任范围外也这样做。管家需密切关注这些事务,且需达到对个人事务相同的关心程度“关心”涉及与组织内部业务相关的事务。组织政策和原则应反映对环境和自然资源可持续利用的关心以及对全球公众状况的关切。项目带来的变化可能会有意想不到或不想要的后果。项目从业者应识别、分析和管理项目成果的潜在负面影响,以便干系人注意到并告知相关情况。“关心”包括营造透明的工作环境、开放的沟通渠道以及让干系人有机会在不受惩罚或不害怕遭到报复的情况下提出顾虑。
▶ 可信。管家需在组织内外准确地说明自己的身份、角色、所在项目团队及其职权。这种行为使人们能够了解个人在多大程度上可以投入资源、做出决策或批准某件事。可信还要求个人主动识别个人利益与其组织或客户利益之间的冲突。此类冲突可能会削弱信任和信心,导致不道德或非法行为,造成混乱或带来次优的成果。管家需保护项目免受此类失信行为的影响。
▶ 合规。管家需遵守其组织内外得到适当授权的法律、规则、法规和要求。但高绩效项目会寻求通过各种方法将合规性更充分地融入项目文化,从而与可能相互冲突的各种准则更好地保持一致性。
管家需努力遵守旨在保护他们及其组织、干系人和广大公众的准则。如果管家在行动或计划是否符合既定准则方面遇到了相互冲突的准则或问题,他们需要寻求适当的建议和指导。管家式管理需要以透明且可信赖的方式进行领导。项目会影响到交付项目的人员以及受项目可交付物和成果影响的人员的生活。项目可以产生某些效果,例如缓解交通堵塞、生产新药物或为人们创造互动机会。这些效果可能会产生负面的影响和后果,例如绿地减少、药物副作用或个人信息泄露。项目团队及其所在组织的领导应仔细考虑这些因素和影响,以便他们可以通过权衡组织和项目目标与全球干系人更大的需求和期望来做出负责任的决定。
越来越多的组织从整体角度看待业务,它们会同时而不是按顺序考虑财务、技术、社会和环境绩效。由于世界现在比以往任何时候都更加相互关联,而且面临有限的资源和共同的环境,因此管家式管理的决策会有超出项目之外的影响。
3.2 营造协作的项目团队环境
在整个项目期间,随着新的干系人被识别,和一些其他干系人的退出,干系人将发生变化。随着项目的进展,一些干系人的态度或权力可能会发生变化。除了识别和分析新的干系人外,还要有机会评估当前的参与策略是否有效或是否需要调整。因此,在整个项目期间对干系人参与的数量和有效性要进行监督。
干系人满意度通常可以通过与干系人的对话来确定,以衡量他们对项目可交付物和项目总体管理的满意状况。也可以通过项目和迭代审查会、产品审查会、阶段关口和其他方法获得定期反馈。如果有大量的干系人,还可以使用问卷调查来评估满意度。必要时,甚至可以通过更新干系人参与方法来提高干系人满意度。
3.4 聚焦于价值

图 3-5. 聚焦于价值
价值(包括从客户或最终用户的角度看的成果)是项目的最终成功指标和驱动因素。价值聚焦于可交付物的成果。项目的价值可以表示为对发起组织或接收组织的财务贡献。价值也可以是对所取得的公共利益的测量,例如,社会收益或客户从项目结果中所感知到的收益。当项目是项目集的组件时,项目对项目集成果的贡献可以表示为价值。
许多项目(尽管不是所有项目)都是基于商业论证而启动。也可能由于任何确定的交付需要,或者修改流程、产品或服务(如合同、工作说明书或其他文件)的需要而启动项目。在所有情况下,项目的目的就是提供预期成果,该成果通过有价值的解决方案满足需要。商业论证可以包含有关战略一致性、风险敞口评估、经济可行性研究、投资回报率、预期关键绩效测量、评估和替代方法的信息。商业论证可以从定性或定量的方面,或者同时从这两方面来说明项目成果的预期价值贡献。商业论证至少包含以下支持性和相互关联的要素:
▶ 商业需要。商业为项目提供理由,并解释为什么开展该项目。它源于初步的业务需求,这些需求反映在项目章程或其他授权文件中。商业需要提供了有关商业目的和目标的详细信息,它可能针对执行组织、客户组织、组织的合伙方或公共福利。明确说明商业需要有助于项目团队了解未来状态的商业驱动因素,并使项目团队能够识别机会或问题,从而提高项目成果的潜在价值。
▶ 项目理由。项目理由与商业需要相关。它解释了为什么商业需要值得投资以及为什么在此时应该满足商业需要。项目理由会附有成本效益分析和假设条件。
▶ 商业战略。商业战略是开展项目的原因,所有需要都与实现价值的战略相关。
除了收益和可能的协议之外,商业需要、项目理由和商业战略一起为项目团队提供信息,使他们能够做出知情决策,以达到或超过预期的商业价值。
在整个项目期间,应清晰描述、以迭代方式评估并更新期望成果。在项目生命周期内,项目可能会发生变更,然后项目团队会作出应对调整。项目团队会根据期望的输出、基准和商业论证不断评估项目进展情况和方向,以确定该项目仍与商业需要保持一致,并将交付预期成果。另外,干系人可以更新商业论证以获取机会,或者将项目团队和其他干系人确定的问题最小化。如果项目或其干系人不再与商业需要保持一致,或者如果项目似乎不可能提供预期价值,则组织可以选择终止此项投入。
价值是指某种事物的作用、重要性或实用性。价值具有主观性,从某种意义上说,同一个概念对于不同的人和组织具有不同的价值。之所以会发生这种情况,是因为所谓的收益取决于组织战略,包含从短期财务收益、到长期收益、甚至是非财务要素。由于所有项目都有一系列干系人,因此必须考虑为每个干系人群体产生的不同价值,并将这些价值与整体价值进行平衡,同时优先考虑客户价值。
在某些项目的背景下,可能存在不同形式的价值工程,这些价值工程可以将客户、执行组织或其他干系人的价值最大化。这方面的一个示例包括在可接受的风险敞口的情况下交付所需的功能和质量水平,同时尽可能少地使用资源,并避免浪费。有时,特别是在没有预先确定范围的适应型项目中,项目团队可以与客户共同努力,确定哪些功能值得投资,哪些功能可能缺乏足够的价值,无需增加到输出之中,从而优化价值。
为了支持从项目中实现价值,项目团队可将重点从可交付物转到预期成果。这样做可以让项目团队实现项目的愿景或目标,而不是简单地创建特定可交付物。虽然可交付物可能会支持预期的项目成果,但它可能无法完全实现项目的愿景或目标。例如,客户可能需要某一特定的软件解决方案,因为他们认为该解决方案可以满足提高生产力这一商业需要。软件是项目的输出,但软件本身并不能实现预期的生产力成果。在这种情况下,增加一项新的可交付物,即提供使用软件的培训和教练,就可以实现更好的生产力成果。如果项目的输出未能提高生产力,干系人可能会认为项目已经失败。因此,项目团队和其他干系人都应该了解可交付物及其预期成果。
项目工作的价值贡献可能是一种短期或长期的测量。由于价值贡献可能与运营活动的贡献相混合,因此很难将其分开。当项目是项目集的一个组件时,也可能需要在项目集层级对价值作出评估,以便以适当的方式对项目进行指导。可靠的价值评估应考虑项目输出的全部背景和整个生命周期。虽然价值会随着时间的推移而实现,但有效的过程可以帮助早日实现收益。通过有效率且有效果地实施项目,项目团队可以展示或实现诸如优先交付、更好的客户服务或改善工作环境等成果。通过与负责将项目可交付物投入使用的组织领导者合作,项目领导者可以确保可交付物能够实现所计划的成果。
3.5 识别、评估和响应系统交互
项目生命周期项目阶段的类型和数量取决于许多变量,其中主要是交付节奏和开发方法(如上所述)。生命周期中阶段的示例包括:
可行性阶段。此阶段会确定商业论证是否有效以及组织是否有能力交付预期成果。
设计阶段。通过规划和分析,可以设计将要开发的项目可交付物。
构建阶段。通过整合的质量保证活动实施构建可交付物。
测试阶段。在移交、上线或客户验收之前,会对可交付物进行最终质量审查和检查。
部署阶段。项目可交付物投入使用,而且持续稳定、实现收益和组织变革管理所需的移交活动均已完成。
收尾阶段。项目收尾了,要存档项目知识和工件,解散项目团队成员,并关闭合同。
项目阶段通常设有阶段关口,以便在进入下一阶段之前检查是否已达到预期成果或满足当前阶段的退出标准。退出标准可能与可交付物、合同义务、满足特定绩效目标或其他有形措施的验收标准密切相关。
图 2-9 显示了各个阶段依次完成的生命周期。这种类型的生命周期与预测型开发方法非常匹配,因为每个阶段只进行一次,每个阶段都侧重于某一特定类型的工作。但有些情况(例如增加范围、需求变化或市场变化)则会导致某些阶段重复进行。

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

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

图 2-11. 采用适应型开发方法的生命周期
可对此方法做出调整,以便在持续交付情况下使用此方法,具体如第 2.3.2 节(交付节奏)所述。
有几种适应型方法论(包括敏捷方法)会进行基于工作流的进度规划,这种进度规划不会采用生命周期或阶段的概念。此举的一个目标是根据资源能力、材料和其他输入优化交付流程。另一个目标是最大限度地减少时间和资源浪费,并优化过程效率和可交付物的产出量。采用这些实践和方法的项目通常采用在精益和准时制(JIT)中使用的看板进度规划系统。
3.7 根据环境进行裁剪

图 3-8. 根据环境进行裁剪
适应独特的目标、干系人和环境的复杂性有助于项目取得成功。裁剪是对有关项目管理方法、治理和过程做出深思熟虑的调整,使之更适合特定环境和当前任务。项目团队对适当的框架进行裁剪,该框架带来灵活性,在项目生命周期的环境内持续产生积极的成果。商业环境、团队规模、不确定性程度和项目复杂性都是如何裁剪项目系统的考虑因素。项目系统可以从整体角度进行裁剪,包括应考虑相互关联的复杂性。通过使用“刚好够”的过程、方法、模板和工件以实现项目期望的成果。裁剪旨在最大化价值、管理制约因素并提高绩效。
项目团队和 PMO 一起,并考虑治理因素,按每个项目逐一讨论并确定交付方法以及产生成果所需的资源。这包括选择要使用的过程、开发方式、方法和交付项目成果所需的工件。裁剪决策可以是接受既定方法论的隐性行动。相反,裁剪也可以是选择并混合特定要素以适应项目和项目环境的独特特征的显性行动。在一定程度上,每个项目都需要裁剪,因为每个项目都存在于特定环境中。
项目通常是独特的,即使项目可交付物看起来并不独特。这是因为项目环境不同之处在于组织及其客户、渠道、和环境都是动态要素。这些变化和不断发展的学问可能会导致项目团队使用或开发不同的方法或方式来追求成功。项目团队应审视每个项目的各种独特条件,以便他们能够确定产生期望成果的最适当方法。
现有的方法论或常见的工作方式可以使我们了解如何对项目进行裁剪。方法论是由专门学科的从业者所采用的实践、技术、程序和规则所组成的体系。项目团队可能需要采取上级组织的方法论,这就是说,项目团队采用的方法论体系由过程、治理、方法和模板组成,它们为如何开展项目提供指导。虽然这使组织内的项目保持了一定程度的一致性,但该方法论本身可能仍需要根据每个项目的情况进行裁剪。组织政策和程序规定了项目团队授权的可以裁剪的边界。
项目团队还可以考虑项目管理过程的时间和成本。未进行裁剪的过程可能对项目或其成果几乎没有什么价值,同时会导致成本增加和进度延长。对项目方法以及适当的过程、方法和工件进行裁剪,可以帮助项目团队就与过程相关的成本和与项目成果相关的价值贡献做出决策。
除了决定如何对方法进行裁剪外,项目团队还需要向与该方法有关的干系人沟通裁剪决策,每个团队成员都应了解与这些干系人及其角色相关的所选方法和过程。
项目团队应该对项目方法进行裁剪,以适应项目及其环境的独特特征,这有助于提高项目的绩效水平,增加项目成功的概率。经过裁剪的项目方法可以为组织产生直接和间接的收益,例如:
▶ 项目团队成员会做出更深入的承诺,因为他们参与了方法的定义;
▶ 行动或资源方面的浪费会有所减少;
▶ 以客户为本(因为客户和其他干系人的需要是项目裁剪的重要影响因素);
▶ 项目资源得到更有效的利用,因为项目团队意识到各个项目过程的权重。
裁剪项目可以带来以下积极成果:
▶ 提高创新、效率和生产力;
▶ 吸取经验教训,以便可以分享特定交付方法的改进之处,并将它们应用于下一轮工作或未来的项目;
▶ 采用新的实践、方法和工件,组织的方法论得到进一步改进;
▶ 通过实验发现了改进的成果、过程或方法;
▶ 在具有多个专业背景的项目团队内,用于交付项目结果的方法和实践得到有效整合;
▶ 从长远来看组织的适应性有所增强。
对方法进行裁剪具有迭代性,因此,在项目生命周期中它是一个持续的过程。项目团队需要收集所有干系人的反馈,了解在项目进展过程中各种方法和经裁剪的过程对他们有何效果,以评估这些方法和过程的有效性,并给组织增加价值。
3.11 拥抱适应性和韧性

图 3-12. 拥抱适应性和韧性
大多数项目在某个阶段都会遇到挑战或障碍。如果项目团队开展项目的方法同时具备适应性和韧性,则有助于项目适应各种影响并蓬勃发展。适应性是指应对不断变化的情形的能力。韧性由两个具有互补性的特质组成:吸收冲击的能力和从挫折或失败中快速恢复的能力。适应性和韧性是任何开展项目的人员应具备的有益特征。
项目很少会按最初的计划执行。项目会受到内部和外部因素(新需求、问题、干系人影响等因素)影响,这些因素存在于一个有各种相互作用的系统中。项目中的某些要素可能会失败或达不到预期,这需要项目团队重新组合、重新思考和重新规划。例如,在基础设施项目中,法院在项目执行期间的裁决可能会导致设计和计划的变更。在技术项目中,技术方面的电脑化模型可能会显示各个组件可以正常协同工作,但它们在实际应用时却发生故障。在这两个案例中,项目团队都需要应对此情形,以便推进项目。有一种观点认为,项目应严格遵守早期阶段的计划和承诺,即使在出现新的或不可预见的因素之后亦是如此。这种观点对包括客户和最终用户在内的干系人是没有益处的,因为这束缚了产生价值的可能性。但是,应该从整体的角度做到适应性,例如应采用适当的变更控制过程,以避免诸如范围蔓延等问题。在项目环境中,支持适应性和韧性的能力包括:
▶ 较短的反馈循环,以便快速适应;
▶ 持续学习和改进;
▶ 拥有宽泛技能组合的项目团队,同时还有在每个所需技能领域具有广博知识的个人;
▶ 定期检查和调整项目工作,以识别改进机会;
▶ 多样化的项目团队,以获得广泛的经验;
▶ 开放和透明的规划,让内部和外部干系人参与;
▶ 小规模的原型法和实验,以测试想法和尝试新方法;
▶ 充分运用新的思考方式和工作方式的能力;
▶ 平衡工作速度和需求稳定性的过程设计;
▶ 组织的开放式对话;
▶ 具有宽泛的技能组合、文化和经验的多样性项目团队,同时还有各个所需技能领域的主题专家;
▶ 对过去相同或类似工作中所获学习成果的理解力;
▶ 预测多种潜在情景,并为多种可能的情况做好准备的能力和意愿;
▶ 将决策推迟到最后责任时刻;
▶ 管理层支持;
▶ 平衡速度和稳定性的开放式设计。
预期的成果而非可交付物能够促成解决方案,进而可利用比原始计划更好的结果。例如,项目团队可找到替代解决方案,以提供比原始定义的可交付物更优的成果。虽然探寻替代方案通常属于商业论证的范畴,但技术和其他能力的演变非常快,以至于在商业论证完成和项目收尾之间的任何时候都可能会出现解决方案。项目期间可能会出现适应项目的机会,届时项目团队应向项目发起人、产品负责人或客户说明为何要抓住这一机会。根据合同类型,因适应项目而进行的某些变更可能需要客户批准。在项目发起人、产品负责人或客户的支持下,项目团队应准备好调整其计划和活动以利用这一机会。
项目系统中的意外变更和情况也可能会带来机会。为了优化价值交付,项目团队应该针对变更和计划外事件运用问题解决和整体思维方法。发生计划外事件时,项目团队应寻找可能获得的潜在积极成果。
例如,将项目时间线后期发生的变更包含进来,这样就可以成为市场上第一个提供该功能的产品,从而增加竞争优势。
在项目中保持适应性和韧性,可使项目团队在内部和外部因素发生变化时聚焦于期望成果,这有助于他们从挫折中恢复过来。这些特征还有助于项目团队学习和改进,以便他们能够从失败或挫折中快速恢复,并继续在交付价值方面取得进展。
3.12 为实现预期的未来状态而驱动变革

图 3-13. 为实现预期的未来状态而驱动变革
在当今的商业环境中保持相关性是所有组织面临的根本挑战。要做到具有相关性,必须对干系人的需要和期望作出响应。这就需要为干系人的利益不断评估产品/服务,对变革作出快速响应,并担当变革推动者。项目经理应具备独特的能力,让组织做好变革的准备。根据项目本身的定义,项目会创造新的事物:它们是变革推动者。
变革管理使能(enablement)是一种综合的、周期性的和结构化的方法,可使个人、群体和组织从当前状态过渡到实现期望收益的未来状态。它不同于项目变更控制,后者是一个过程,通过该过程,项目团队可以识别和记录项目的文件、可交付物或基准的修改,然后批准或拒绝这些修改。
组织中的变革可能源自内部,例如需要新的能力或应对绩效差距。变革也可能源自外部,例如技术进步、人口结构变化或社会经济压力。任何类型的变革都涉及到经历变革的群体以及与其互动的行业某种程度的适应或接受。
变革可能由干系人实施并对其产生影响。推动干系人变革是促进项目提供所需可交付物和预期成果的一部分。
在组织中推动变革可能充满挑战,这有多种原因,比如有些人可能天生就抵制变革或厌恶风险,又如所处环境可能表现出保守的文化。有效的变革管理采用激励型策略,而不是强制型策略。参与和双向沟通可营造出这样的一种环境,即变革会得到采用和接受,或者从抵制变革的用户那里识别出一些需要解决的有效问题。
项目团队成员和项目经理可与有关干系人共同合作,解决抵制、疲劳和变革吸收的问题,以提高客户或项目可交付物接收者成功采纳或接受变革的可能性。这包括在项目早期沟通与变革相关的愿景和目的,以争取各方对变革的认同。在整个项目期间,应向组织内所有层级的人员说明变革的收益和对工作过程的影响。
同样重要的是,使变革的速度适应干系人和环境接受变革的意愿、成本和能力。如果试图在太短的时间内进行过多的变革,则可能会因变革饱和而受到抵制。即使干系人一致认为变革将产生更多价值或增强成果,他们仍往往难以采取能够交付更高收益的行动。为了促进收益实现,项目还可能会开展一些活动,以便在变革实施后使其得到强化,从而避免人们回到初始的状态。
认识并解决干系人在整个项目生命周期内接受变革的需要,有助于将由此产生的变革整合到项目工作中,从而使成功取得的成果更有可能。
有关组织变革管理的更多信息,可参阅《组织变革管理:实践指南》[4]。
1.1 《PMBOK指南》的结构
除了本引论之外,本版本《 PMBOK 指南》还包含另外三章内容:
▶ 第 2 章 项目绩效域。此章确定并描述了构成整体系统的八个项目绩效域,以便成功交付项目和预期成果。
▶ 第 3 章 裁剪。此章介绍了裁剪的内涵,并概述了要裁剪的内容以及如何对各个项目进行裁剪。
▶ 第 4 章 模型、方法和工件。此章简要介绍了常用的模型、方法和工件。这些模型、方法和工件说明了项目团队可用于生成可交付物、组织工作以及实现沟通和协作的方案的选择范围。
2.1.1.5 监督
在整个项目期间,随着新的干系人被识别,和一些其他干系人的退出,干系人将发生变化。随着项目的进展,一些干系人的态度或权力可能会发生变化。除了识别和分析新的干系人外,还要有机会评估当前的参与策略是否有效或是否需要调整。因此,在整个项目期间对干系人参与的数量和有效性要进行监督。
干系人满意度通常可以通过与干系人的对话来确定,以衡量他们对项目可交付物和项目总体管理的满意状况。也可以通过项目和迭代审查会、产品审查会、阶段关口和其他方法获得定期反馈。如果有大量的干系人,还可以使用问卷调查来评估满意度。必要时,甚至可以通过更新干系人参与方法来提高干系人满意度。
2.1.2 与其他绩效域的相互作用
干系人渗透到项目的各个方面。他们会为项目团队定义需求和范围,并对其进行优先级排序。他们会参与并制定规划。他们会确定项目可交付物和项目成果的验收和质量标准。大部分的项目工作都围绕着争取干系人参与以及与干系人进行沟通而展开。在整个项目过程中或在项目结束时,他们会使用项目可交付物并影响项目成果的实现。
某些干系人可以帮助减少项目中存在的不确定性的数量,而其他干系人则可能导致不确定性增加。客户、高层管理人员、项目管理办公室领导或项目集经理等干系人将重点关注项目及其可交付物绩效的测量。这些相互作用只是干系人绩效域如何与其他绩效域整合和交织的示例,它们并不包含所有绩效域中对干系人考虑相互作用的全部方式。
2.2.1.3 团队发展的共同方面
无论管理活动如何安排,项目团队发展中总有一些与大多数项目团队相关的共同方面。这些共同的方面包括:
▶ 愿景和目标。每个人都必须了解项目的愿景和目标。在整个项目期间应沟通项目的愿景和目标。这包括当项目团队参与决策和解决问题时应参考预期成果。
▶ 角色和职责。确保项目团队成员了解并履行其角色和职责是很重要的。这可以包括识别知识和技能方面的差距,以及通过培训、辅导或教练解决这些差距的策略。
▶ 项目团队运作。促进项目团队沟通、解决问题和达成共识的过程可能包括与项目团队共同努力制定项目团队章程和一套行动指南或项目团队规范。
▶ 指导。可以向整个项目团队提供指导,让每个人都朝着正确的方向前进。项目团队个体成员也可以就特定任务或可交付物提供指导。
▶ 成长。确定项目团队表现良好的领域并指出项目团队可以改进的领域有助于项目团队成长。项目团队协同工作,可以识别改进目标,并采取措施实现这些目标。这也适用于项目团队中的每个人。
个人可能希望提高自己在某些领域的技能和经验,项目经理可以为此提供帮助。
第 4 章中包含的几个模型描述了项目团队成长的各个阶段。
当项目团队基于合同、战略合作关系或其他商业关系在跨不同组织中形成时,根据合同或其他条款,执行各种职能的特定角色可能会更加正式化和缺乏灵活性。此类安排通常需要更多的前期工作来形成“一个团队”的思维模式,这可确保项目团队成员了解每个人如何为项目做出贡献,并可确定整合了技能、能力和过程的其他驱动因素。
2.2.2 项目团队文化
自从 1987 年《项目管理知识体系》 (PMBOK)形式首次推出以来《项目管理知识体系指南(简称“《 PMBOK指南》”)一直在逐步演进。同时我们认识到,项目管理的基本要素依然未变。这种逐步演进不仅涉及书本页数的增加,还涉及实质内容的显著且根本的变化。其中的一些主要变化请见下表:
《 PMBOK 指南》中主要变化的逐步演进情况

与原先各版《项目管理标准》和《 PMBOK 指南》一样,本版指南认识到项目管理的大环境在不断发展变化。仅就过去 10 年以来,推动各类产品、服务和解决方案中采用的软件呈指数增长。随着人工智能、基于云的能力和新的商业模式对创新和新的工作方式的驱动,软件能够促使这种增长继续变化。同时组织模式发生了转型,这引发了新的项目工作和团队结构,从而需要采用一系列广泛的方法来进行项目和产品交付,并要更多地关注成果而非可交付物。另外来自世界任何地方的个人贡献者均可加入项目团队,来承担更广泛的角色,并采用新的思考和协作方式。这些变化以及更多的因素使我们有机会重新考虑各种观点,为《项目管理标准》和《 PMBOK 指南》的继续演进提供支持。
2.3.1 开发、节奏和生命周期之间的关系
项目可交付物的类型决定了如何进行开发。可交付物的类型和开发方法会影响项目交付的次数和节奏。可交付物的开发方法和所期望的交付节奏决定了项目生命周期及其阶段。
2.3.2 交付节奏
交付节奏是指项目可交付物的时间安排和频率。项目可以一次性交付、多次交付或定期交付。
一次性交付。一次性交付的项目只在项目结束时交付。例如,对于流程再造项目,在项目接近收尾、新过程推出之前,可能不会进行任何交付。
多次交付。有些项目会进行多次交付。一个项目可能包含多个组件,这些组件会在整个项目期间的不同时间交付。新药开发项目可能会进行多次交付,例如临床前提交、第 1 阶段临床试验结果、第 2 阶段临床试验结果、第 3 阶段临床试验结果、注册和上市。在此示例中,交付是按顺序进行的。有些项目的交付是单独而非按顺序进行的,例如更新建筑安全措施的项目。交付物可能包括进入建筑的物理屏障、新工作证、新密码门禁盘等。每件交付物都是单独交付的,无需按特定顺序交付。所有交付物都在项目被视为完成之前交付完毕。
定期交付。定期交付与多次交付非常相似,但定期交付是按固定的交付进度计划进行,例如每月或每两个月交付一次。新的软件应用程序可能每两周进行一次内部交付,然后定期向市场发布。
另一种交付方案被称为持续交付。持续交付是将特性增量立即交付给客户(通常是使用小批量的工作和自动化技术)的实践。持续交付可用于数字化产品。从产品管理的角度看,持续交付强调在整个产品生命周期内产生收益和价值。与项目类似,持续交付的各个方面都是以开发为导向的。然而与项目集类似,持续交付中可能存在许多开发周期和维护活动。这种交付类型更适合于稳定且保持原班人马的项目团队。
由于项目团队专注于一种产品,因此他们可以充分应用关于产品、干系人和市场的知识。这使团队能够应对市场趋势并聚焦于价值交付。DevOps、#NoProject和 Continuous Digital 等多种方法中都包含了这种<716>实践。
2.3.4.1 产品、服务或结果
与产品、服务或结果的性质相关的许多变量会影响开发方法。以下列表概述了在选择开发方法时要考虑的一些变量。
▶ 创新程度。在充分了解范围和需求的情况下,项目团队以前曾完成的工作且能够提前规划的可交付物非常适合采用预测型方法。创新程度高或项目团队没有做过的可交付物更适合采用更多适应性的方法。
▶ 需求确定性。当需求变得众所周知且易于定义时,预测型方法非常适合。而当需求不确定、易变或复杂且预期在整个项目期间会发生演变时,更具有适应性的方法可能更适合。
▶ 范围稳定性。如果可交付物的范围稳定且不可能发生变化,则预测型方法非常有用。如果范围预期会有许多变更,开发方法频谱图上更靠近适应型方法这一端的会很有用。
▶ 变更的难易程度。这与需求确定性和范围稳定性相关。如果可交付物的性质使得管理和合并变更较为困难,那么预测型方法就是最佳的。对于容易适应变更的可交付物,可以采用更具适应性的方法。
▶ 交付选项方案。如第 2.3.2 节(“交付节奏”)中所述,可交付物的性质以及能否以组件形式交付将影响开发方法。可以分组块开发和/或交付的产品、服务或结果选用增量型方法、迭代型方法或适应型方法皆可。有些大型项目可以采用预测型方法进行规划,但其中有些组块可以增量型开发和交付。
▶ 风险。存在固有高风险的产品需要在选择开发方法之前进行分析。某些高风险产品可能需要大量前期规划和严格的流程减少威胁。基于学习利用新出现的机会或减少威胁的敞口,其他产品可以通过模块化构建,以及调整设计和开发来减轻风险。
▶ 安全需求。具有严格安全需求的产品通常采用预测型方法,因为需要进行大量的预先规划,以确保所有安全需求都得到识别、规划、创建、整合和测试。
▶ 法规。对受到严格法规监管的环境,由于有所需的流程、文档和演示的需要,可能要求采用预测型方法。
2.3.5 生命周期和阶段的定义
项目生命周期项目阶段的类型和数量取决于许多变量,其中主要是交付节奏和开发方法(如上所述)。生命周期中阶段的示例包括:
可行性阶段。此阶段会确定商业论证是否有效以及组织是否有能力交付预期成果。
设计阶段。通过规划和分析,可以设计将要开发的项目可交付物。
构建阶段。通过整合的质量保证活动实施构建可交付物。
测试阶段。在移交、上线或客户验收之前,会对可交付物进行最终质量审查和检查。
部署阶段。项目可交付物投入使用,而且持续稳定、实现收益和组织变革管理所需的移交活动均已完成。
收尾阶段。项目收尾了,要存档项目知识和工件,解散项目团队成员,并关闭合同。
项目阶段通常设有阶段关口,以便在进入下一阶段之前检查是否已达到预期成果或满足当前阶段的退出标准。退出标准可能与可交付物、合同义务、满足特定绩效目标或其他有形措施的验收标准密切相关。
图 2-9 显示了各个阶段依次完成的生命周期。这种类型的生命周期与预测型开发方法非常匹配,因为每个阶段只进行一次,每个阶段都侧重于某一特定类型的工作。但有些情况(例如增加范围、需求变化或市场变化)则会导致某些阶段重复进行。

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

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

图 2-11. 采用适应型开发方法的生命周期
可对此方法做出调整,以便在持续交付情况下使用此方法,具体如第 2.3.2 节(交付节奏)所述。
有几种适应型方法论(包括敏捷方法)会进行基于工作流的进度规划,这种进度规划不会采用生命周期或阶段的概念。此举的一个目标是根据资源能力、材料和其他输入优化交付流程。另一个目标是最大限度地减少时间和资源浪费,并优化过程效率和可交付物的产出量。采用这些实践和方法的项目通常采用在精益和准时制(JIT)中使用的看板进度规划系统。
2.3.6 协调交付节奏、开发方法和生命周期
我们将重温第 2.3.3 节中描述的社区中心示例,以揭示交付节奏、开发方法和生命周期是如何融合在一起的。在该示例中,共有四种产品和服务:建筑物、社区行动巡查 (CAP) 培训、老年人服务和网站。表 2-4 描述了交付节奏和开发方法。
表 2-4. 交付节奏和开发方法

根据这些信息,潜在的生命周期可能为:
启动阶段。此阶段的进入标准是:商业论证已获批准,而且项目章程已获审批。这一阶段将制定高层级路线图,确定初步的资金需求,定义项目团队和资源需求,制定里程碑进度计划,及采购战略规划。这些可交付物应在退出启动阶段之前完成。退出标准将在初始阶段关口审查会议上进行审查。
规划阶段。在这一阶段,示例中建筑物的高层级信息将被分解为各个详细的计划CAP 培训的详细设计文件将编制完成。并将完成对面向老年人的产品/服务的分析,与差距分析。还将创建网站的初始线框图。这些可交付物应在退出规划阶段之前完成。退出标准将在规划阶段关口审查会议上进行审查。
开发阶段。此阶段将与测试阶段和部署阶段重叠,因为可交付物有着不同的交付节奏和不同的方法。在此将提前交付网站的部分内容,以便向公众通报社区中心的进展情况。一些老年人服务和CAP 培训的活动可能会在社区中心开放之前开始。在进入测试阶段之前,每项可交付物都可能受到单独的审查。
测试阶段。此阶段将与开发阶段和部署阶段重叠。测试的类型取决于可交付物。这一阶段包括对建筑物的检查、对 CAP 课程的测试交付、对老年人服务的小规模试验以及在网站每个版本的测试环境中运行。在进入部署阶段之前,每项可交付物都将经过应用的测试。
部署阶段。此阶段将与开发和测试阶段重叠。网站的首次部署可能在项目早期进行。随着更多可交付物可以使用,此阶段中的活动将重复进行。在社区中心开放运营的时候,项目将进行最终部署。
社区中心开放后,对网站和老年人服务进行持续更新将成为运营活动的一部分。
收尾阶段。随着可交付物的完成,此阶段会定期进行。在初始网站部署后,项目人员(包括承包商)将会被解散,每项可交付物的回顾或经验教训总结也将完成。当整个项目完成时,将获得各个阶段关口审查的信息,并对比基准来完成项目绩效的总体评价。在最终收尾之前,将对项目章程和商业论证进行审查,以确定可交付物是否实现了预期的收益和价值。
图 2-12 显示了社区中心项目可能的生命周期。启动和计划阶段是按顺序进行的。开发、测试和部署这几个阶段可能会相互重叠,因为不同的可交付物将在不同的时间进行开发、测试和部署,而某些可交付物会进行多次交付。该图更详细地展示了开发阶段,以说明不同的时间安排和交付节奏。测试阶段的节奏将遵循开发阶段的节奏。交付将在部署阶段显示。

图 2-12. 社区中心项目生命周期
询问生命周期中各个阶段的名称并非所有项目从业者都能区分清楚开发方法和生命周期。在一些从业者谈到开发方法时,会说一个项目遵循敏捷生命周期。一些从业者将预测型方法称为“瀑布式方法”。适应型开发方法也可称为演进的方法。
由于项目管理在不断发展,因此所用的语言也在不断演变。要想了解某人所指的到底是哪种方法,最好要确定其可交付物的开发方式,并向其询问生命周期中各个阶段的名称。这有助于构建项目框架并了解人们是如何使用术语的。
2.3.7 与其他绩效域的相互作用
开发方法和生命周期绩效域与干系人绩效域、规划绩效域、不确定性绩效域、交付绩效域、项目工作绩效域和团队绩效域相互作用。所选的生命周期会影响进行规划的方式。预测型生命周期会提前进行大部分规划工作,然后继续使用滚动式规划和渐进明细来重新规划。随着威胁和机会的发生,计划也会得到更新。
开发方法和交付节奏是减少项目不确定性的一种方法。如果一个可交付物存在要满足监管要求相关的大量风险,则可能会选择一种预测型方法来增加额外测试、文档编写以及健全的流程和程序。如果一个可交付物存在要与干系人验收相关的大量风险,则可能会选择一种迭代方法,并向市场发布最小可行产品,以便在开发其他特性和功能之前获得反馈。
在考虑交付节奏和开发方法时,开发方法和生命周期绩效域与交付绩效域有很多重叠。交付节奏是确保价值交付与商业论证和收益实现计划保持一致的主要驱动因素之一。启发产品需求并满足交付绩效域所述的质量要求对开发方法有着重大影响。
在项目团队能力和项目团队领导力技能方面,团队绩效域与开发方法和生命周期绩效域会相互作用。项目团队的工作方式和项目经理的风格会因开发方法的不同而有很大差异。采用预测型方法时,通常需要更加重视预先规划、测量和控制。在开发方法频谱图另一端,适应型方法(特别是在使用敏捷方法时)需要更多的服务型领导风格,而且可能会形成自我管理的项目团队。
2.4.1 规划概述
规划的目的是积极主动地制定一种方法来创建项目可交付物。项目可交付物会推动项目所要取得的成果。高层级规划可以在项目批准授权之前开始。项目团队会逐步制定初始项目文件,例如愿景陈述、项目章程、商业论证或类似文件,以识别或定义实现预期成果的相互合作的方法。
除了财务影响之外,在初步规划中考虑社会和环境影响的做法越来越普遍(有时称为三重底线)。这可能会采取产品生命周期评估(即评估产品、过程或系统的潜在环境影响)的形式。产品生命周期评估为产品和过程的设计提供信息。它会考虑材料和过程有关可持续性、有害毒性和环境的影响。
在项目开始之前和整个项目期间,规划所花费的时间应由具体情况确定。花费更多比需要的时间进行规划属于低效行为。因此,从规划中获得的信息应足以用适当方式推进工作,但这些信息不应超过必要的详细程度。项目团队会使用规划工件来确认干系人的期望,并向干系人提供信息,以便他们做出决策、采取行动,使得项目与干系人之间保持一致。
2.4.2 规划的变量
由于每个项目都是独特的,因此规划的数量、时间安排和频率各不相同。影响项目规划方式的变量包括(但不限于):
开发方法。开发方法会影响如何规划、规划多少及何时实施规划。范例包括:
▹ 生命周期早期进行规划或组织的特定阶段。在这些情况下,大部分规划都是预先进行的。在整个项目期间,最初的计划会渐进明细地制定,但对原来的范围没有什么改变。
▹ 一种预先进行高层级规划的方法,随后是使用原型的设计阶段。在项目团队和干系人对设计表示同意后,项目团队将完成更详细的规划。
▹ 项目团队实施迭代的适应型方法。一些规划会提前进行,以制定发布计划,而进一步的规划会在每个迭代开始时进行。
项目可交付物。通常需要以特定方式规划项目可交付物。建筑项目需要进行大量的前期规划,以便对设计、审批、材料采购、物流和交付做出说明。产品开发或高技术项目可以采用持续性和适应性的规划,以便根据干系人的反馈和技术进步进行演变和变更。
组织需求。组织治理、政策、程序、流程和文化可能会要求项目经理提供特定的规划工件。
市场条件。产品开发项目可能会在竞争激烈的环境中进行。在这种情况下,项目团队可以进行最低限度的前期规划,因为重点是加快投入市场的速度。过量的规划必然造成延迟的成本会超过潜在返工的风险。
法律或法规限制。监管机构或法规可能要求必须先提供特定的规划文件,然后才能得到进行实施的相关授权或者获得批准向市场发布项目可交付物。
2.4.2.3 进度
本节中描述的方法不适合于上述特定类别;但它们是用于项目的多种目的的常用方法。
影响地图。影响地图是一种战略规划方法,在产品开发期间作为组织的可视化路线图。
建模。建模是创建对系统、解决方案或可交付物(例如原型、示意图或故事板)的简化表示法的过程。通过确定信息中的差距、沟通错误的方面或额外需求,建模能有助于进一步分析。
净推荐值 (NPS )。客户将某组织的产品或服务推荐给他人的意愿的一种测量指数。该数值是被用作衡量客户对组织产品或服务的总体满意度,以及客户对品牌的忠诚度的指标。
优先级模型。优先级模型是用于确定项目组合、项目集、项目的组件以及需求、风险、特性或其他产品信息的优先级的方法。例如多标准加权分析和 MoSCoW(“必须有”“应该有”“可以有”和“不会有”)方法。
时间盒。时间盒是工作将在其间完成的较短的固定期间,如 1 周、2 周或 1 个月。
2.4.6 采购
采购可以在项目期间的任何时候进行。但预先规划有助于设定期望,确保采购过程顺利进行。一旦了解了高层级范围,项目团队就会进行自制或外购分析。这包括确定将在内部开发的可交付物和服务,以及将从外部资源购买的可交付物和服务。这些信息会影响项目团队和进度计划。合同签订专业人士需要事先了解所需货物类型、何时需要这些货物以及所采购货物或服务所需的任何技术规范。
2.4.8 度量指标

图 2-23. 测量绩效域
测量涉及评估项目绩效和实施适当的应对措施,以保持最佳绩效。
以下定义与测量绩效域相关:
度量指标。对项目或产品属性及其测量方式的描述。
基准。经过批准的工作产品的版本,用作与实际结果进行比较的依据。
仪表盘。一组图表和图形,显示相对于项目的重要指标所取得的进展或绩效。
测量绩效域会评估交付绩效域中完成的工作在多大程度上符合规划绩效域中确定的度量指标。例如,可以使用规划绩效域中确定的基准来测量和评估绩效。拥有关于项目工作和绩效的及时和准确信息,可使项目团队能够了解并确定采取哪些适当措施来解决与预期绩效相比的当前或预期偏差。
人们会出于多种原因使用测量指标,包括:
▶ 对比计划评估绩效;
▶ 跟踪资源利用情况、已完成的工作、支出的预算等;
▶ 表明担责情况;
▶ 向干系人提供信息;
▶ 评估项目可交付物是否处于正轨,能否交付计划收益;
▶ 聚焦关于权衡、威胁、机会和选项的对话;
▶ 确保项目可交付物符合客户验收标准。
测量的价值不在于收集和传播数据,而在于关于如何使用数据以采取适当行动的对话。因此,虽然这一绩效域的大部分内容涉及可以捕获的各种类型的测量,但这些测量指标的使用是在其他绩效域的活动背景中发生的,例如项目团队和干系人讨论、协调项目工作等。
此绩效域聚焦于进展中项目的测量指标。项目组合领导者可能希望包含涉及项目完成后项目成功的测量指标,例如项目是否交付了预期成果和收益。项目组合的领导可以评估项目成果是否提高了客户满意度或降低了单位成本,还可以评估项目结束前无法获得的其他测量指标。同样,业务经理也可以从成果对组织的价值的角度来评估项目。业务测量指标可能包括市场份额增加、利润增加或单位成本下降。测量绩效域涉及项目期间使用的测量指标和度量指标。
2.5.6.2 签订合同
最后,双方达成协议并签订合同。签订合同工具的类型取决于采购规模、工作范围的稳定性以及各组织的风险承受力。
对于某些可交付物采用适应型方法,而其他可交付物采用预测型方法的项目,总体合同可以使用主协议,适应性工作可以放在附录或增补中。这样一来,如果变更发生在适应性范围中,而不会对总体合同造成影响。
一旦选定供应商,就会对项目计划和文件进行更新,以包含供应商日期、资源、成本、质量要求、风险等。从这时起,供应商将成为项目干系人。在整个项目期间,干系人绩效域和测量绩效域中的信息将适用于供应商。
采购可以在项目期间的任何时候进行。所有采购活动都将被整合进项目运行之中。
2.6.1 价值的交付
对于其使用的开发方法支持在整个项目生命周期内发布可交付物的项目,可以在项目期间开始向业务、客户或其他干系人交付价值。在项目生命周期结束时交付大量可交付物的项目会在初始部署后产生价值。
在原先的项目结束后的很长时间内,往往还可以继续获得商业价值。通常,较长的产品和项目集生命周期用于测量早期项目带来的收益和价值。
商业论证文件通常会提供商业理由和对项目预期商业价值的预测。这种商业论证的格式会基于所选的开发方法和生命周期而异。示例包括具有详细估算投资回报的商业论证文件,或是描述问题、解决方案、收入流和成本结构等高层级要素的精益创业画布。这些商业文件说明了项目成果如何与组织的商业目标保持一致。
项目授权文件试图量化项目的预期成果,以便进行定期测量。这些文件可能包括详细的基准计划或高层级路线图,这些计划或路线图会概述项目生命周期、主要发布、关键可交付物、评审和其他顶层信息。
2.6.2.2 范围定义
随着需求被识别,满足这些需求的范围也应被定义。范围是项目所提供的产品、服务和结果的总和。随着范围被定义,还需要识别更多的需求。因此,与需求一样,范围可以预先被定义好,也可以随着时间的推移而演变,或可以被发现。
范围分解。可以使用范围说明书来阐明范围,以识别与项目关联的主要可交付物以及每个可交付物的验收标准。还可以通过使用工作分解结构 (WBS) 将范围分解为较低层级的细节,从而详细说明范围。WBS 是对项目团队为实现项目目标、创建所需可交付物,而需要实施的全部工作范围的层级分解。该层级往下的每一个层级代表着关于可交付物的更详细的信息以及生成可交付物所需的工作。
详细说明范围的另一种方法是在敏捷章程、路线图或作为产品层级结构的一部分来确定项目的各个主题。这些代表着大量用户价值的主题可表示为用户故事,该用户故事与诸如功能、数据源,或安全级别等常见因素相关。为了完成这些主题,项目团队会开发史诗故事。史诗故事是一种逻辑容器,用于容纳因太大而无法在一个迭代中完成的较大的用户故事。史诗故事可以分解为多个特性,这些特性是一组通常被描述为简短的短语或功能的相关需求,代表着产品的特定行为。每个特性都有多个用户故事。用户故事是向特定用户提供的成果的简要描述,而且确保可以通过对话澄清细节。项目团队会在负责的最后责任时刻定义故事细节,以避免在范围发生变更时造成规划浪费。故事可清晰且简洁地描述从最终用户的角度编写的需求。
完成可交付物。根据所使用的方法,有不同的方式来描述组件或项目的完成情况:
验收或完成的标准。在客户验收可交付物之前,或在项目被视为完成之前需要满足的标准通常会记录在范围说明书中。
技术绩效测量指标。产品的技术规范可能记录在单独的规范文件中,也可能记录为 WBS 的扩展。这一扩展称为 WBS 字典,它详细说明了 WBS 中每项可交付物(工作包)的信息。
完成的定义。可将完成的定义与适应型方法一起使用,特别是在软件开发项目中。它是为了考虑可交付物能供客户使用,而须达到的所有标准的检查清单。
2.6.3.1 质量成本
与产品或可交付物相关的属性包括但不限于:
▶ 合规性/关键性。什么程度的过程严格性和质量保证是合适的?
▶ 产品/可交付物的类型。产品是否为人所知且为有形之物,例如像一幢建筑那样易于识别和描述?或者是无形之物,例如软件或者新药设计?
▶ 行业市场。项目产品或可交付物服务于哪个市场?该市场是否受到严格监管,发展迅速或缓慢?竞争对手和所在企业的情况如何?
▶ 技术。技术是稳定且成熟,或是发展迅速且存在过时的风险?
▶ 时间框架。项目时间框架很短(数周或数月)还是很长(数年)?
▶ 需求的稳定性。核心需求出现变更的可能性有多大?
▶ 安全性。产品业务的要素是否属于保密或机密信息?
▶ 增量交付。这是项目团队可以用增量方式开发并获得干系人反馈的东西,还是在接近完成之前难以评估的东西?
2.6.4 次优的成果
所有项目都试图交付成果,尽管有些项目也许未能实现此目标,或可能会产生次优成果。每个项目中都存在次优成果的可能性,在一个完全属于试验性的项目中,组织正在试图取得突破,例如创造一种全新的技术。这需要对不确定的成果进行有意图的投资。生产新药物或化合物的公司在找到成功的配方之前可能会经历多次失败。有些项目可能无法交付成果,因为市场机会已经擦肩而过,或者竞争对手已抢先推出产品。有效的项目管理可以最小化负面结果,但这种可能性是试图产生独特可交付物所面临的不确定性的一部分。
2.7.1.1 关键绩效指标
项目的关键绩效指标 (KPI) 是用于评估项目成功与否的可量化测量指标KPI 有两种类型:提前指标和滞后指标。
提前指标。提前指标可预测项目的变化或趋势。如果变化或趋势不利,项目团队将评估提前指标测量的根本原因,并采取行动扭转这一趋势。以这种方式,通过在可能绩效偏差超出公差临界值之前将其识别,提前指标可以降低项目的绩效风险。提前指标可以量化,如项目规模或待办事项列表中正在进展的事项的数量。其他提前指标更难以量化,但它们可提供潜在问题的预警信号。风险管理过程缺乏、干系人未到位或没有参与、或者项目成功标准定义不明确,这些都是项目绩效可能面临风险的提前指标的示例。
滞后指标。滞后指标可测量项目可交付物或事件。它们在事后提供信息。滞后指标反映的是过去的绩效或状况。滞后指标比提前指标更容易测量。示例包括已完成的可交付物的数量、进度偏差或成本偏差以及所消耗资源的数量。滞后指标也可用于寻找成果与环境变量之间的相关性。例如,显示进度偏差的滞后指标可表明与项目团队成员不满意度的相关性。这种相关性可以帮助项目团队找到根本原因,如果唯一的测量指标是进度状态,则根本原因可能并不明显。
就其本身而言,KPI 只是在使用之前没有实际用处的测量指标。讨论提前指标和滞后指标并视情况确定需要改进的方面可对绩效产生积极影响。
2.7.1.2 有效度量指标
项目测量指标有助于项目团队实现项目目标。然而,会存在一些与测量有关的陷阱。认识到这些陷阱有助于最小化其负面影响。
霍桑效应 (Hawthorne effect)。霍桑效应指出,测量某种事物的行动会对行为产生影响。因此,制定度量指标时要慎重。例如,仅测量项目团队可交付物的输出,会鼓励项目团队专注于创建更多数量的可交付物,而不是专注于提供更高客户满意度的可交付物。
虚荣指标 (Vanity metric)。似乎会显示某些结果但不提供决策所需有用信息的测量指标。测量网站的页面访问量不如测量新访问者的数量有用。
士气低落。如果设定了无法实现的测量指标和目标,项目团队的士气可能会因持续未能达到目标而下降。设定拓展性目标和激励人心的测量指标是可以接受的,但人们也希望看到他们的辛勤工作得到认可。不现实或无法实现的目标可能适得其反。
误用度量指标。尽管存在用于测量绩效的度量指标,人们可能会扭曲测量指标或专注于错误的事情。范例包括:
▹ 专注不太重要的度量指标,而不是最重要的度量指标;
▹ 专注于做好短期测量指标的工作,而以牺牲长期度量指标为代价;
▹ 为了改进绩效指标,开展易于完成的无序活动。
确认偏见。作为人类,我们倾向于寻找并看到支持我们原有观点的信息。这可能会导致我们对数据作出错误解释。
相关性与因果关系对比。解释测量数据的一个常见错误是将两个变量之间的相关性与一个变量导致了另一个变量的因果性混淆起来。例如,看到项目进度落后且预算超支,可能就会推断是预算超支导致了进度问题。这并非真实情况,而且也并非进度落后导致了预算超支。相反,可能还有其他相关因素未考虑进来,例如估算技能、管理变更的能力和积极地管理风险。
我们除了警惕与不适当的测量指标相关的危险外,了解与度量指标相关的陷阱有助于我们制定有效的度量指标。
2.7.2 测量内容
测量内容、参数和测量方法取决于项目目标、预期成果以及开展项目的环境。常见的度量指标类别包括:
▶ 可交付物度量指标;
▶ 交付;
▶ 基准绩效;
▶ 资源;
▶ 商业价值;
▶ 干系人;
▶ 预测。
一组平衡的测量标准有助于让人了解项目及其绩效和成果的整体情况。
第 2.7.2.1 节至第 2.7.2.7 节将简要介绍这些类别。
2.7.2.3 基准绩效
最常见的基准是成本和进度。跟踪范围或技术基准的项目可以使用可交付物测量指标中的信息。
大多数进度测量指标会根据以下相关的计划绩效来跟踪实际绩效:
▶ 开始日期和完成日期。将实际开始日期与计划开始日期进行比较,并将实际完成日期与计划完成日期进行比较,可以测量工作按计划完成的程度。即使工作不在项目的最长路径(关键路径)上,延迟的开始日期和完成日期也表明项目未按计划执行。
▶ 人力投入和持续时间。实际人力投入和持续时间与计划人力投入和持续时间相比较,可表明工作量估算和工作所需时间估算是否有效。
进度偏差 (SV)。通过查看关键路径上的绩效来确定简单的进度偏差。使用挣值管理时,进度偏差表示为挣值与计划价值之差。图 2-24 显示了说明进度偏差的挣值图。
进度绩效指数 (SPI)。进度绩效指数是一种挣值管理测量指标,可表明计划工作的执行效率。
特性完成率。在频繁审查期间,检查特性验收比率有助于评估进展情况并估算完成日期和成本。
常见的成本测量指标包括:
▶ 与计划成本相比的实际成本。此成本测量指标将实际人工或资源的成本与估算成本进行比较。此术语也可称为燃烧率。
成本偏差 (CV)。通过比较可交付物的实际成本和估算成本来确定简单的成本偏差。使用挣值管理时,成本偏差表示为挣值与实际成本之差。图 2-24 显示了一张说明成本偏差的挣值图。
成本绩效指数 (CPI)。一种挣值管理测量指标,可表明相对于工作的预算成本,执行工作的效率。

图 2-24. 表明进度偏差和成本偏差的挣值分析
2.7.2.5 商业价值
商业价值测量指标用于确保项目可交付物与商业论证和收益实现计划保持一致。商业价值有许多方面,包括财务的和非财务的。测量财务的商业价值的度量指标包括:
成本效益比。这是针对具有初始成本的投资的预期现值的测量指标。成本效益比用于确定项目的成本是否超过其收益。如果成本高于收益,结果将大于 1.0。在这种情况下,除非有监管、社会利益或其他原因来做该项目,否则不应考虑该项目。一个类似的测量指标是效益成本比。效益成本比使用相同的测量指标,但分子是收益,分母是成本。对于此测量指标,如果比率大于 1.0,则应考虑该项目。
与实际收益交付相比的计划收益交付。作为商业论证的一部分,组织可以把价值确定为做该项目将交付的收益。对于预期在项目生命周期内交付收益的项目,测量所交付的收益和这些收益的价值,然后将这些信息与商业论证进行比较,可以提供信息用以证明继续开展项目,或在某些情况下取消项目的合理性。
投资回报率 (ROI)。ROI 是一种将财务回报金额与成本相比较的测量指标,它通常是作为开展项目决策的一种输入而开发的。在整个项目生命周期中,可能会在不同时点对 ROI 进行估算。通过在整个项目期间测量 ROI,项目团队可以确定继续投入组织资源是否有意义。
净现值 (NPV)。NPV 是一段时间内资本流入的现值与资本流出的现值之差,通常是在决定开展项目时开发的。通过在整个项目期间测量 NPV,项目团队可以确定继续投入组织资源是否有意义。
2.7.3.3 目视管理
在精益环境中,信息发射源被称为目视管理。目视管理说明了较容易地比较实际和预期绩效的过程,它使用可视化提示来显示一个过程。从要交付的商业价值到已开始的任务,可以对其中所有层级的信息进行目视管理。它们应该是显而易见的,让任何人都能看到。
任务板。任务板是对计划工作的可视化表示,使每个人都能看到各项任务的状态。任务板可以显示已准备就绪并可以开始(待办)的工作、在制品和已完成的工作(参见图 2-29)。借助任务板,任何人都能一目了然地查看特定任务的状态或每个工作阶段中的任务数。不同颜色的便利贴可以代表不同类型的工作,并且可以使用圆点来显示任务已处于其当前位置的天数。基于工作流的项目(如使用看板的项目)可以使用这些图表来限制在制品的数量。如果看板中某列的任务接近在制品限值,那么项目团队成员可以对当前工作采取“蜂拥模式”,以帮助那些人来处理使流程减缓的任务。
燃烧图。燃烧图(例如燃起图或燃尽图)可以显示项目团队的速度“速度”可测量在预先定义的时间间隔内生成、确认和接受可交付物的生产率。燃起图可以对照预期应完成的工作来跟踪已完成的工作量(参见图 2-30)。燃尽图可以显示剩余故事点的数量或已减少的风险敞口的数量。
▶ 其他类型的图表。可视化图表还可以包括诸如障碍因素清单之类的信息,该清单描述了完成工作所面临的障碍因素、严重程度以及为应对障碍因素而采取的行动。

图 2-29. 任务板或看板

图 2-30. 燃起图
2.7.4 测量陷阱
项目测量指标有助于项目团队实现项目目标。然而,会存在一些与测量有关的陷阱。认识到这些陷阱有助于最小化其负面影响。
霍桑效应 (Hawthorne effect)。霍桑效应指出,测量某种事物的行动会对行为产生影响。因此,制定度量指标时要慎重。例如,仅测量项目团队可交付物的输出,会鼓励项目团队专注于创建更多数量的可交付物,而不是专注于提供更高客户满意度的可交付物。
虚荣指标 (Vanity metric)。似乎会显示某些结果但不提供决策所需有用信息的测量指标。测量网站的页面访问量不如测量新访问者的数量有用。
士气低落。如果设定了无法实现的测量指标和目标,项目团队的士气可能会因持续未能达到目标而下降。设定拓展性目标和激励人心的测量指标是可以接受的,但人们也希望看到他们的辛勤工作得到认可。不现实或无法实现的目标可能适得其反。
误用度量指标。尽管存在用于测量绩效的度量指标,人们可能会扭曲测量指标或专注于错误的事情。范例包括:
▹ 专注不太重要的度量指标,而不是最重要的度量指标;
▹ 专注于做好短期测量指标的工作,而以牺牲长期度量指标为代价;
▹ 为了改进绩效指标,开展易于完成的无序活动。
确认偏见。作为人类,我们倾向于寻找并看到支持我们原有观点的信息。这可能会导致我们对数据作出错误解释。
相关性与因果关系对比。解释测量数据的一个常见错误是将两个变量之间的相关性与一个变量导致了另一个变量的因果性混淆起来。例如,看到项目进度落后且预算超支,可能就会推断是预算超支导致了进度问题。这并非真实情况,而且也并非进度落后导致了预算超支。相反,可能还有其他相关因素未考虑进来,例如估算技能、管理变更的能力和积极地管理风险。
我们除了警惕与不适当的测量指标相关的危险外,了解与度量指标相关的陷阱有助于我们制定有效的度量指标。
2.7.7 与其他绩效域的相互作用
测量绩效域与规划绩效域、项目工作绩效域和交付绩效域相互作用,因为计划构成了将交付和计划进行比较的基础。测量绩效域可以通过提供最新信息来支持作为规划绩效域一部分的活动,从而使经验教训能够反映针对更新计划的有利或不利信息。在项目团队成员制定计划并创建可测量的可交付物时,团队绩效域和干系人绩效域会相互作用。
当不可预测的事件发生时(无论是积极事件还是消极事件),它们会影响项目绩效,从而影响项目的测量和度量指标。应对已发生的不确定事件造成的变更包括了更新受此影响的测量。不确定性绩效域中的活动(例如识别风险和机会)可以根据绩效测量启动。
作为项目工作的一部分,应与项目团队和其他干系人合作,以便制定度量指标、收集数据、分析数据、做出决策并报告项目状态。
2.8.5 风险
从产品或可交付物的角度看,不确定性绩效域与规划绩效域、项目工作绩效域、交付绩效域和测量绩效域相互作用。随着规划的进行,可将减少不确定性和风险的活动纳入计划。这些工作是在交付绩效域中执行的。测量可以表明随着时间的推移风险级别是否有所变化。
项目团队成员和其他干系人是不确定性的主要信息来源。在应对各种形式的不确定性方面,他们可以提供信息、建议和协助。
生命周期和开发方法的选择将影响不确定性的应对方式。在范围相对稳定的预测型项目中,可以使用进度和预算中的储备来应对风险。在采用适应型方法的项目中,需求可能会演变,在系统如何互动或干系人如何反应方面可能存在模糊性,项目团队可以调整计划,以反映对不断演变情况的理解,还可以使用储备来抵消已发生的风险的影响。
2.8.6 与其他绩效域的相互作用
从产品或可交付物的角度看,不确定性绩效域与规划绩效域、项目工作绩效域、交付绩效域和测量绩效域相互作用。随着规划的进行,可将减少不确定性和风险的活动纳入计划。这些工作是在交付绩效域中执行的。测量可以表明随着时间的推移风险级别是否有所变化。
项目团队成员和其他干系人是不确定性的主要信息来源。在应对各种形式的不确定性方面,他们可以提供信息、建议和协助。
生命周期和开发方法的选择将影响不确定性的应对方式。在范围相对稳定的预测型项目中,可以使用进度和预算中的储备来应对风险。在采用适应型方法的项目中,需求可能会演变,在系统如何互动或干系人如何反应方面可能存在模糊性,项目团队可以调整计划,以反映对不断演变情况的理解,还可以使用储备来抵消已发生的风险的影响。
3.1 概述
裁剪是对有关项目管理方法、治理和过程深思熟虑后作出调整,使之更适合特定环境和当前工作。
在项目环境中,裁剪会考虑开发方法、过程、项目生命周期、可交付物以及与其共同参与工作人员的选择。裁剪过程受《项目管理标准》[1] 中的指导性项目管理原则、组织价值观和组织文化的驱动。例如,如果核心的组织价值观是“以客户为中心”,那么为启发需求和确认范围而选择的活动就要倾向于采用以客户为中心的方法。这种方法符合“有效地干系人参与”这一原则。同样,在项目的整个生命周期,风险偏好较低的组织可能有许多流程和程序来指导项目。而在同一市场上运营但风险承受能力高的类似公司可能会有较少的流程和程序。在这两个示例中,尽管各个组织的偏好、流程和程序各不相同,但它们都遵守“优化风险应对”这一原则。
使用裁剪需要谨慎选择和调整多个项目因素,无论是否使用“裁剪”标签皆是如此。
剪裁的替代方案是使用未经修改的框架或方法论。有许多方法论可以描述项目中使用的过程、阶段、方法、工件和模板。这些方法论及其组件不是根据组织环境定制的。
它们中的大多数都有明确的指导说明,它指出不应只是严格遵守,而是要经过一个裁剪过程,以便根据项目的特定类型、规模和复杂性确定哪些要素最有用。可是一些经验不足的从业者试图完完全全地应用该方法论,而不考虑项目规模、复杂性、持续时间或组织环境。
进行裁剪时需要了解项目背景、目的和运行环境。项目的运行环境非常复杂,需要平衡下列潜在的互相矛盾的要求,包括但不限于:
▶ 尽快交付;
▶ 最小化项目成本;
▶ 优化所交付的价值;
▶ 创建高质量的可交付物和成果;
▶ 遵守监管标准;
▶ 满足不同干系人的期望;
▶ 适应变化。
需要理解、评估和平衡这些因素,以便为项目创造切实可行的运行环境。
有些情况可能会限制项目团队调整其方法的程度,例如,当组织政策要求使用特定方法或合同强制规定了某种方法时。
3.3.5 方法和工件
对项目进行裁剪受许多属性影响。这些属性包括但不限于:
▶ 产品/可交付物;
▶ 项目团队;
▶ 文化。
项目团队应该询问关于每个属性的问题,以帮助指导他们完成裁剪过程。对这些问题的回答有助于识别裁剪过程、交付方法、生命周期、工具、方法和工件的需要。
3.4 裁剪过程
裁剪过程并非单一的,一次性的过程。在渐进明细过程中,项目团队的工作方式、产品或可交付物的演变方式,以及其他知识等问题将表明哪些进一步的裁剪可以带来改进。审查点、阶段关口和回顾会议都提供了必要的检查和调整过程、开发方法和交付频率的机会。
让项目团队参与过程改进可以培养主人翁意识,并表现出对实施持续改进和质量的承诺。让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任。项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式。
图 3-6 中显示了增加、取消和变更这些过程的概念。

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

图 3-7. 裁剪过程
3.4.3 对项目进行裁剪
对项目进行裁剪受许多属性影响。这些属性包括但不限于:
▶ 产品/可交付物;
▶ 项目团队;
▶ 文化。
项目团队应该询问关于每个属性的问题,以帮助指导他们完成裁剪过程。对这些问题的回答有助于识别裁剪过程、交付方法、生命周期、工具、方法和工件的需要。
3.4.3.1 产品/可交付物
与产品或可交付物相关的属性包括但不限于:
▶ 合规性/关键性。什么程度的过程严格性和质量保证是合适的?
▶ 产品/可交付物的类型。产品是否为人所知且为有形之物,例如像一幢建筑那样易于识别和描述?或者是无形之物,例如软件或者新药设计?
▶ 行业市场。项目产品或可交付物服务于哪个市场?该市场是否受到严格监管,发展迅速或缓慢?竞争对手和所在企业的情况如何?
▶ 技术。技术是稳定且成熟,或是发展迅速且存在过时的风险?
▶ 时间框架。项目时间框架很短(数周或数月)还是很长(数年)?
▶ 需求的稳定性。核心需求出现变更的可能性有多大?
▶ 安全性。产品业务的要素是否属于保密或机密信息?
▶ 增量交付。这是项目团队可以用增量方式开发并获得干系人反馈的东西,还是在接近完成之前难以评估的东西?
3.4.3.2 项目团队
Allan Drexler 和 David Sibbet 开发了团队绩效模型,共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段,第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。
▶ 第 1 步 : 确定方向“确定方向”回答了为什么这个问题。在这一阶段,项目团队会了解项目的目的和使命。这通常发生在开工会议上,或者会记录在商业论证、项目章程或精益创业画布中。
▶ 第 2 步 : 建立信任“建立信任”回答了谁这个问题。这一阶段阐明了谁会加入项目团队以及每个人会带来什么样的技能和能力。它还可以包括关于可能未加入项目团队但对项目团队有影响的关键干系人的信息。
▶ 第 3 步 : 澄清目标“澄清目标”回答了什么这个问题。在这一阶段,项目团队详细阐述了高层级的项目信息。这可能包括进一步了解干系人的期望、需求、假设条件和可交付物的验收标准。
▶ 第 4 步 : 承诺“承诺”解决了如何这个问题。在这一阶段,项目团队开始定义实现目标的计划。这可以包括里程碑进度计划、发布计划、高层级预算、资源需求等。
▶ 第 5 步 : 实施。高层级计划会分解为更详细的层级,例如详细的进度计划或待办事项列表。项目团队开始共同努力生成可交付物。
▶ 第 6 步 : 高绩效。项目团队合作一段时间后,项目团队成员的绩效达到了很高的水平。他们可以很好地协同工作,无需太多监督,并且项目团队会产生协同效应。
▶ 第 7 步 : 重新开始“重新开始”是应对项目团队或项目变更的阶段。可交付物、干系人、环境、项目团队领导或团队成员资格可能会发生变化。这会使项目团队考虑过去的行为和行动是否仍然足够,或者团队是否需要返回到以前的某一阶段,以重新设立期望和合作方式。
3.4.3.4 实施持续改进
裁剪过程并非单一的,一次性的过程。在渐进明细过程中,项目团队的工作方式、产品或可交付物的演变方式,以及其他知识等问题将表明哪些进一步的裁剪可以带来改进。审查点、阶段关口和回顾会议都提供了必要的检查和调整过程、开发方法和交付频率的机会。
让项目团队参与过程改进可以培养主人翁意识,并表现出对实施持续改进和质量的承诺。让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任。项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式。
图 3-6 中显示了增加、取消和变更这些过程的概念。

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

图 3-7. 裁剪过程
3.5.7 不确定性
所有项目都试图交付成果,尽管有些项目也许未能实现此目标,或可能会产生次优成果。每个项目中都存在次优成果的可能性,在一个完全属于试验性的项目中,组织正在试图取得突破,例如创造一种全新的技术。这需要对不确定的成果进行有意图的投资。生产新药物或化合物的公司在找到成功的配方之前可能会经历多次失败。有些项目可能无法交付成果,因为市场机会已经擦肩而过,或者竞争对手已抢先推出产品。有效的项目管理可以最小化负面结果,但这种可能性是试图产生独特可交付物所面临的不确定性的一部分。
4.2.5.2 Stacey 矩阵
Ralph Stacey 开发的 Stacey 矩阵类似于 Cynefin 框架,但它从两个维度来确定项目的相对复杂性(a)针对可交付物的需求的相对不确定性,以及 (b) 将用于创建可交付物的技术的相对不确定性。基于这些维度的相对不确定性,项目被分为简单型、繁杂型、复杂型或混乱型。复杂程度是影响项目裁剪方法和实践的一个因素。
4.2.6.2 Drexler/Sibbet 团队绩效模型
Allan Drexler 和 David Sibbet 开发了团队绩效模型,共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段,第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。
▶ 第 1 步 : 确定方向“确定方向”回答了为什么这个问题。在这一阶段,项目团队会了解项目的目的和使命。这通常发生在开工会议上,或者会记录在商业论证、项目章程或精益创业画布中。
▶ 第 2 步 : 建立信任“建立信任”回答了谁这个问题。这一阶段阐明了谁会加入项目团队以及每个人会带来什么样的技能和能力。它还可以包括关于可能未加入项目团队但对项目团队有影响的关键干系人的信息。
▶ 第 3 步 : 澄清目标“澄清目标”回答了什么这个问题。在这一阶段,项目团队详细阐述了高层级的项目信息。这可能包括进一步了解干系人的期望、需求、假设条件和可交付物的验收标准。
▶ 第 4 步 : 承诺“承诺”解决了如何这个问题。在这一阶段,项目团队开始定义实现目标的计划。这可以包括里程碑进度计划、发布计划、高层级预算、资源需求等。
▶ 第 5 步 : 实施。高层级计划会分解为更详细的层级,例如详细的进度计划或待办事项列表。项目团队开始共同努力生成可交付物。
▶ 第 6 步 : 高绩效。项目团队合作一段时间后,项目团队成员的绩效达到了很高的水平。他们可以很好地协同工作,无需太多监督,并且项目团队会产生协同效应。
▶ 第 7 步 : 重新开始“重新开始”是应对项目团队或项目变更的阶段。可交付物、干系人、环境、项目团队领导或团队成员资格可能会发生变化。这会使项目团队考虑过去的行为和行动是否仍然足够,或者团队是否需要返回到以前的某一阶段,以重新设立期望和合作方式。
4.2.7.4 过程组
项目管理过程可以按逻辑分组,分为项目管理输入、工具和技术以及输出,为了满足组织、干系人和项目的需要会对它们进行裁剪。
过程组不是项目阶段。在项目生命周期的每个阶段内,各个过程组会相互作用。所有这些过程都有可能在一个阶段内发生。在一个阶段或生命周期内,各个过程可能会迭代发生。过程迭代的次数和过程间的相互作用因具体项目的需要而有所不同。
采用基于过程的方法的项目可以将以下五个过程组作为组织结构:
▶ 启动。定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的一组过程。
▶ 规划。明确项目范围,完善目标,为实现目标制定行动方案的一组过程。
▶ 执行。完成项目管理计划中确定的工作,以满足项目需求的一组过程。
▶ 监控。跟踪、审查和调整项目进展与绩效的一组过程,该过程识别任何计划需要变更的领域,并启动相应变更。
▶ 收尾。正式完成或结束项目、阶段或合同时所执行的过程。
这些过程组与交付方法、应用领域(例如市场营销、信息服务和会计)或行业(例如建筑、航空航天和电信)相互独立。在基于过程的方法中,一个过程的输出通常成为另一个过程的输入,或者成为项目或项目阶段的可交付物。例如,在规划过程组中生成的项目管理计划和项目文档(例如风险登记册、假设日志等)是执行过程组的输入,在执行过程组中会对相关工件进行更新。
4.4 常用方法
方法是获得成果、输出、结果或项目可交付物的方式。此处描述的方法的示例,通常用于支持项目工作。还有很多方法本文没有述及,要么是因为它们在项目管理中的使用方式与在其他学科中的使用方式相同(如访谈、焦点小组、核对单等),要么是因为它们不常用于广泛的项目(即这些方法仅适用于特定行业)。
其中的许多方法都与它们达到的目的相关(例如估算或数据收集),因此,它们都会呈现在某个分组中。其他方法则与所涉活动的类型有关,例如会议和分析小组中使用的方法。
本节中的内容并非旨在描述如何使用某种方法。这些描述是高层级的介绍,更详细的信息可从许多来源(包括 PMIstandards+)获得。
4.4.1 数据收集和分析
最常见的基准是成本和进度。跟踪范围或技术基准的项目可以使用可交付物测量指标中的信息。
大多数进度测量指标会根据以下相关的计划绩效来跟踪实际绩效:
▶ 开始日期和完成日期。将实际开始日期与计划开始日期进行比较,并将实际完成日期与计划完成日期进行比较,可以测量工作按计划完成的程度。即使工作不在项目的最长路径(关键路径)上,延迟的开始日期和完成日期也表明项目未按计划执行。
▶ 人力投入和持续时间。实际人力投入和持续时间与计划人力投入和持续时间相比较,可表明工作量估算和工作所需时间估算是否有效。
进度偏差 (SV)。通过查看关键路径上的绩效来确定简单的进度偏差。使用挣值管理时,进度偏差表示为挣值与计划价值之差。图 2-24 显示了说明进度偏差的挣值图。
进度绩效指数 (SPI)。进度绩效指数是一种挣值管理测量指标,可表明计划工作的执行效率。
特性完成率。在频繁审查期间,检查特性验收比率有助于评估进展情况并估算完成日期和成本。
常见的成本测量指标包括:
▶ 与计划成本相比的实际成本。此成本测量指标将实际人工或资源的成本与估算成本进行比较。此术语也可称为燃烧率。
成本偏差 (CV)。通过比较可交付物的实际成本和估算成本来确定简单的成本偏差。使用挣值管理时,成本偏差表示为挣值与实际成本之差。图 2-24 显示了一张说明成本偏差的挣值图。
成本绩效指数 (CPI)。一种挣值管理测量指标,可表明相对于工作的预算成本,执行工作的效率。

图 2-24. 表明进度偏差和成本偏差的挣值分析
4.4.3 会议和活动
会议是吸引项目团队和其他干系人参与的重要方式。它们是整个项目的主要沟通方式。
待办事项列表细化。在待办事项列表的细化会议上,项目团队会以渐进明细方式编制待办事项列表并(重新)明确其中各事项的优先级,以确定在即将到来的迭代中完成的工作。
投标人会议。在准备投标或建议书之前,与潜在卖方举行的会议,以便确保所有潜在供应商对本次采购都有清楚且一致的理解。该会议也称承包商会议、供应商会议或投标前会议。
变更控制委员会。变更控制委员会会议包括负责审核、评估、批准、推迟或拒绝项目变更的人员。
本次会议上所做的决定将被记录下来并传达给有关的干系人。此会议也可称为变更控制会议。
每日站会。每日站会是简短的协作会议,在该会议期间,项目团队会审查前一天的进展,宣布当天的计划,并强调指出遇到或预见的任何障碍。该会议也可称为“每日例会”。
迭代规划会议。迭代规划会议用于澄清待办事项列表中事项的详细信息、验收标准以及实现即将履行的迭代承诺所需的工作投入。此会议也可称为冲刺规划会议。
迭代审查会议。迭代审查会议是在一个迭代结束时举行,旨在展示在该迭代期间完成的工作。此会议也可称为冲刺审查会议。
开工。开工会议是项目开始执行时举行的会议,项目团队成员和其他关键干系人会聚在一起,正式设定期望、达成共识并开始工作。它会确立项目、阶段或迭代的开始。
经验教训会议。经验教训会议用于识别和分享在项目、阶段或迭代过程中获得的知识,其重点是关注提高项目团队的绩效。除了良好的做法和产生非常有利结果的情况外,此会议还可以讨论原本可以处理得更好的事情。
规划会议。规划会议用于创建、详细制订或审核计划,并获得对计划的承诺。
项目收尾。项目收尾会议用于获得发起人、产品负责人或客户对交付范围的最终验收。此会议表明了产品交付工作已完成。
项目审查。项目审查会议是一种在过程或项目结束时开展的活动,旨在评估状态、评估所交付的价值,并确定项目是否已准备好进入下一个阶段或移交至运营。
发布规划。发布规划会议是确定发布或改变产品、可交付物或价值增量的高层级计划。
回顾会议。回顾会议是定期举行的研讨会,参会者探讨其工作和结果,以便改进流程和产品。回顾会议是经验教训会议的一种形式。
风险审查。一种分析现有风险的状态并识别新风险的会议。这包括确定风险是否仍处于活跃状态以及风险属性(如概率、影响、紧急程度等)是否已发生了变化。并对风险应对措施进行评估,以确定它们是否有效或是否应更新。可能会识别和分析新的风险,也可能会关闭不再活跃的风险。风险再评估是风险审查会议的一个示例。
状态会议。状态会议是定期举行的会议,旨在交流和分析项目当前进展情况及其绩效方面的信息。
指导委员会。资深的干系人为项目团队提供指导和支持,并做出项目团队权限以外的决策的会议。
4.4.4 其他方法
本节中描述的方法不适合于上述特定类别;但它们是用于项目的多种目的的常用方法。
影响地图。影响地图是一种战略规划方法,在产品开发期间作为组织的可视化路线图。
建模。建模是创建对系统、解决方案或可交付物(例如原型、示意图或故事板)的简化表示法的过程。通过确定信息中的差距、沟通错误的方面或额外需求,建模能有助于进一步分析。
净推荐值 (NPS )。客户将某组织的产品或服务推荐给他人的意愿的一种测量指数。该数值是被用作衡量客户对组织产品或服务的总体满意度,以及客户对品牌的忠诚度的指标。
优先级模型。优先级模型是用于确定项目组合、项目集、项目的组件以及需求、风险、特性或其他产品信息的优先级的方法。例如多标准加权分析和 MoSCoW(“必须有”“应该有”“可以有”和“不会有”)方法。
时间盒。时间盒是工作将在其间完成的较短的固定期间,如 1 周、2 周或 1 个月。
4.6 常用工件
工件是一种模板、文件、输出或项目可交付物。很多文件或可交付物并未在此处描述,原因可能是:(a)它们具有一定的通用性质,例如更新;(b) 它们仅适用于特定行业;或 (c) 它们是用特定方法创建的结果,例如,虽然成本估算结果是一个重要工件,它们是用不同估算方法得出的结果。
本节中的内容并非旨在描述如何开发或创建工件。这些描述只是高层级的介绍,因为项目经理和/或项目团队成员需要对这些工件的使用进行裁剪,以满足特定项目的需要。有许多来源(包括 PMIstandards+)可提供关于这些工件和其他工件的更加详细的信息。
4.6.1 战略工件
在项目开始前或开始时创建的文件,涉及与项目有关的战略、商业或高层级的信息。战略工件是在项目开始时开发的,通常不会发生变化,但在整个项目期间可能会对其进行审查。
商业论证。商业论证是针对提议项目的价值主张,可能包含财务和非财务收益。
商业模式画布。这种工件是一页纸的可视化摘要,描述了价值主张、基础设施、客户和财务状况。它们通常用于精益创业情境。
项目简介。项目简介是项目的目的、可交付物和过程的高层级概述。
项目章程。项目章程是由项目启动者或发起人发布的,正式批准项目成立,并授权项目经理使用组织资源开展项目活动的文档。
项目愿景说明书。此文件是对项目的简要、高层级描述,介绍了项目的目的,并激励项目团队为项目做出贡献。
路线图。此文件提供的高层级时间线描述了里程碑、重要事件、审查活动和决策点。
4.6.2 日志和登记册
日志和登记册用于记录项目不断演变的方面。它们会在整个项目期间得到更新。日志和登记册这两个词有时可以互换使用。我们经常看到用风险登记册或风险日志这两个词是指同一个工件。
假设日志。假设条件是没有证据或证明即被认为正确、真实或确定的因素。制约因素是对管理项目、项目集、项目组合或过程的方案进行限制的因素。假设日志记录了整个项目期间的所有假设条件和制约因素。
待办事项列表。待办事项列表是待完成工作的有序列表。项目可能有产品待办事项列表、需求待办事项列表、障碍因素待办事项列表等。待办事项列表中的事项会被确定优先级。然后为即将到来的迭代安排优先级高的工作。
变更日志。变更日志是项目过程中提交的变更及其当前状态的综合清单。变更可以是对任何正式受控的可交付物、项目管理计划组件或项目文件的修改。
问题日志。问题是可以对项目目标产生影响的当前条件或情形。问题日志会被用于记录和监督与尚未解决的问题相关的信息。问题将被分配给责任方进行跟进和解决。
经验教训登记册。经验教训登记册可被用于记录在某一项目、阶段或迭代期间所获知识的项目文件,以便未来可将这些知识用于提高团队和组织的绩效。
风险调整待办事项列表。风险调整待办事项列表包含了产品所需工作,以及应对威胁和机会的行动。
风险登记册。风险登记册是记录风险管理过程输出的存储文件。风险登记册中的信息可以包括相关管理风险的负责人,概率、影响、风险评分、计划的风险应对,和用来获得关于单个风险的高层级理解的其他信息。
干系人登记册。干系人登记册会记录与项目干系人有关的信息,其中包括对项目干系人的评估和分类。
4.6.4 层级图
层级图是从高层级信息开始,然后会渐进地分解为较多层级的详细信息。处于较高层级的信息包括处于较低或附属层级的所有信息。随着人们了解了更多有关项目的信息,层级图通常会渐进明细地分解为较多层级的详细信息。
组织分解结构。此图表是对项目组织的一种层级描述,展示了项目活动与执行这些活动的组织单元之间的关系。
产品分解结构。此图表是反映产品组件和可交付物的层级结构。
资源分解结构。此图表是对资源按类别和类型的层级描述。
风险分解结构。此图表是对潜在风险来源的层级描述。
工作分解结构 (WBS)。此图表是对项目团队为实现项目目标、创建所需可交付物,而需要实施的全部工作范围的层级分解。
4.6.6 可视化数据和信息
在精益环境中,信息发射源被称为目视管理。目视管理说明了较容易地比较实际和预期绩效的过程,它使用可视化提示来显示一个过程。从要交付的商业价值到已开始的任务,可以对其中所有层级的信息进行目视管理。它们应该是显而易见的,让任何人都能看到。
任务板。任务板是对计划工作的可视化表示,使每个人都能看到各项任务的状态。任务板可以显示已准备就绪并可以开始(待办)的工作、在制品和已完成的工作(参见图 2-29)。借助任务板,任何人都能一目了然地查看特定任务的状态或每个工作阶段中的任务数。不同颜色的便利贴可以代表不同类型的工作,并且可以使用圆点来显示任务已处于其当前位置的天数。基于工作流的项目(如使用看板的项目)可以使用这些图表来限制在制品的数量。如果看板中某列的任务接近在制品限值,那么项目团队成员可以对当前工作采取“蜂拥模式”,以帮助那些人来处理使流程减缓的任务。
燃烧图。燃烧图(例如燃起图或燃尽图)可以显示项目团队的速度“速度”可测量在预先定义的时间间隔内生成、确认和接受可交付物的生产率。燃起图可以对照预期应完成的工作来跟踪已完成的工作量(参见图 2-30)。燃尽图可以显示剩余故事点的数量或已减少的风险敞口的数量。
▶ 其他类型的图表。可视化图表还可以包括诸如障碍因素清单之类的信息,该清单描述了完成工作所面临的障碍因素、严重程度以及为应对障碍因素而采取的行动。

图 2-29. 任务板或看板

图 2-30. 燃起图
4.6.9 其他工件
工件是一种模板、文件、输出或项目可交付物。很多文件或可交付物并未在此处描述,原因可能是:(a)它们具有一定的通用性质,例如更新;(b) 它们仅适用于特定行业;或 (c) 它们是用特定方法创建的结果,例如,虽然成本估算结果是一个重要工件,它们是用不同估算方法得出的结果。
本节中的内容并非旨在描述如何开发或创建工件。这些描述只是高层级的介绍,因为项目经理和/或项目团队成员需要对这些工件的使用进行裁剪,以满足特定项目的需要。有许多来源(包括 PMIstandards+)可提供关于这些工件和其他工件的更加详细的信息。
X2.2 发起人的角色
项目通常有一个发起人,具体视组织的不同情况而定。项目发起人的决策领导力超出项目经理和项目团队的权限和职权。项目发起人的积极参与和监督为项目经理和项目团队提供支持,并最终推动取得项目成果。发起人还将项目团队与组织高级管理层的战略和全局视角联系起来。
和其他职能一起,发起人还履行下列职能:
▶ 向团队沟通愿景、目标和期望。
▶ 成为项目和团队的拥护者。
▶ 促使高级管理层做出决策。
▶ 帮助获得资源。
▶ 使项目与商业目标保持一致。
▶ 清除障碍。
▶ 解决项目团队职权之外的问题。
▶ 让高层管理人员注意到项目中出现的机会。
▶ 在项目结束后密切关注项目成果,以确保实现预期的业务收益。发起人在组织中的职位和从该职位看待问题的视角,使发起人能够在以下方面向团队提供关键支持:
▶ 愿景。制定和/或沟通项目的愿景和方向。
▶ 商业价值。始终与团队合作,保持与战略和商业目标的一致性。当市场、竞争和战略急剧波动且不断演变时,这可能需要频繁的互动来调整项目工作以适应不断变化的方向。
▶ 关注客户。平衡各个干系人的需要和优先级。当有多个干系人,特别是多个干系人的需要相互冲突时,可能有必要考虑干系人的需要的优先级并做出权衡。
▶ 决策。当做出的决策超出项目团队的职权范围时,应做出决策或指导相应的个人或群体做出决策。
如果团队无法做出决策,或者团队意见不一,发起人可以调解意见冲突并促进决策过程。
▶ 激励。发起人可通过让项目团队积极参与并向其提供支持,成为他们的激励源泉。
▶ 担责。发起人通常对项目成果担责,具体视角色的职权级别而定。在此角色中,他们可以接受或拒绝项目的可交付物。
2 常用缩写
自 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+ 数字平台的连接。

修订了《项目管理标准》 ,并将《 PMBOK 指南》和 PMIstandards+ 数字内容平台从第 6 版过渡到第 7 版
3 定义
自 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+ 数字平台的连接。

修订了《项目管理标准》 ,并将《 PMBOK 指南》和 PMIstandards+ 数字内容平台从第 6 版过渡到第 7 版