交付性能域:如何明确承诺交付的内容

项目交付性能域是关于您的项目将交付什么。项目管理知识体系7交付性能领域的两个关注点是范围和质量。范围是关于项目需要交付什么，而质量是关于您需要满足的标准或性能水平。

这是我们的8篇系列文章中的第6篇，涵盖了7个项目性能域中的8个^th项目管理知识体系PMI指南(PMBOK 7)的版本。对于这些领域的一般介绍，请查看我们的文章，项目性能域:你知道它们是什么吗?为什么它们很重要?

本文结构

在本文中，我们将研究:

• 什么是交付性能域?
• 交付领域的基本原则
• PMI对交付性能域组件的描述
• 交付领域的关键评估
• 我们还应该在交付绩效领域包括什么?
• 交付绩效域如何与其他项目管理域相关联

什么是交付域?

我认为我不会像项目管理知识体系7中PMI那样定义一个名为“交付”的项目绩效域。在我看来，它应该聚焦于我们如何交付项目。

然而，我们不得不承认，这并不是作者们解决这个问题的方式。他们关注您的项目将交付什么。如果不问，就不可能知道这是否是因为:

• 他们想要专注于性能领域“是什么”-这是他们能找到的最好的名字，或者
• 的“是什么”他们在考虑送货的时候会想到什么

这对我来说很重要，因为和往常一样，我将评估性能域的内容。在我看来，用一个与作者选择的定义完全不同的定义来评估它是毫无意义的。言归正传，下面是……

交付绩效域的项目管理知识体系定义

项目管理知识体系7对交付绩效域的定义如下:

“交付性能域处理与交付项目所要达到的范围和质量相关的活动和功能。”

项目管理知识体系指南，7^th版
项目管理学院，2021年

令人高兴的是，作者在这一节中继续触及了利益和价值的关键话题。我稍后将讨论它们是如何做到这一点的。

但重要的是要注意，我们交付的东西需要实现利益，从而交付价值。这将使我得到一个稍微修改过的定义。

我们对交付性能域的扩展定义

有两个可能的方向。两者之间的差别很细微，但很重要。

选项1

“交付绩效域处理与交付项目所要实现的价值相关的活动和功能。”

选项2

“交付性能域处理与交付项目所要实现的利益相关的活动和功能。”

的差异

我的版本和PMI的不同之处在于我已经替换了的范围和质量由:

• 在选项1中，value和
• 在选项2中，福利

如果我是诚实的，我更喜欢选项1和使用“价值”．价值是关于成本和收益之间的关系。PMI在项目管理知识体系7中优先考虑价值，并在项目绩效域的第一个主要小节中讨论价值的交付。这显然是更好的定义。

那么，为什么要纠结于选项2和使用“福利”呢?

我对整个交付性能领域的最大批评是，它没有触及“如何”。因此，它不包括成本管理或进度管理。事实上，虽然下一个性能领域，测量，涉及到成本管理，它只在测量成本绩效的背景下这样做。而且它似乎在很大程度上忽视了进度监控和控制。

因此，在我看来，项目管理知识体系7所描述和涵盖的交付性能领域可能只是嘴上说说价值，但实际上谈论的是收益。

因此，选项1是性能域的更好定义应该是．选项2是性能域的更好定义是．

了解更多…

• 价值是什么?…或项目价值?|视频
• 价值交付:应该激励您的项目的驱动力
• 什么是项目收益?|视频
• 利益管理:每个项目经理需要知道[和做]的事情

交付性能领域的预期结果

项目管理知识体系7继续根据五个期望的结果来定义领域，这证明了项目团队已经有效地执行了它:

1. 项目有助于实现业务目标和战略的推进
2. 项目实现了它们打算交付的结果
3. 项目收益是在计划的时间框架内实现的
4. 项目团队对需求有清晰的理解
5. 涉众接受并满意项目可交付成果

让我们依次来看看这些。

项目有助于实现业务目标和战略的推进

这里没什么可说的。它是有意义的。

项目实现了它们打算交付的结果

这也是有道理的。但是，我想用一段话把结果与范围和质量联系起来。在这个性能领域中，我在其他任何地方都没有提到结果。

项目收益是在计划的时间框架内实现的

我对此的问题是交付性能域根本没有讨论进度。

项目团队对需求有清晰的理解

这里没什么可说的。它是有意义的。

涉众接受并满意项目可交付成果

作者似乎认为，如果我们以正确的质量交付正确的范围，我们的涉众将会满意。根据我的经验，这是一个重要的促成因素，但远远不足以确保涉众满意。

验证交付性能域的结果

对于每个领域，项目管理知识体系7也进行了说明“检查”通过它，我们可以根据性能领域的每个结果来评估项目性能。

我将用自己的话解释这些支票。

项目有助于实现业务目标和战略的推进

这里的检查是业务目标和项目可交付成果的一致性。这应该从组织的商业计划和战略，以及项目的授权文件等文件中很清楚。我会更明确地指出，这里的主要项目文档是这样的:

• 商业案例、项目建议书、投资评估
• 利益案例和利益实现计划

项目实现了它们打算交付的结果

这一项是薄弱的，表明与业务案例相比的数据表明项目正在进行中。这不仅提供了很少的指导，而且我想要一个明确的参考需要一个利益实现计划。

项目收益是在计划的时间框架内实现的

然而，在这里我们确实看到了一个直接的参考:

• 利益实现的计划
• 业务案例
• 时间表

我认为这向我表明，这和之前的性能域结果可以明智地结合在一起。

项目团队对需求有清晰的理解

这种检查更多的是一种原则陈述，没有提供实际的检查过程。它正确地提醒我们:

• 预测项目与初始需求陈述相比几乎没有变化
• 适应性项目看到了对需求的新理解

但支票是多少呢?对我来说，项目经理的责任是通过以下方式确保清楚地理解:

1. 编写清晰的需求陈述或清晰定义的用户需求的有序backlog
2. 确保团队成员知道并能够访问这些文档
3. 鼓励团队成员对他们在这里看到的东西提出疑问，以澄清他们对需求的理解或书面表达

涉众接受并满意项目可交付成果

这是这个领域中最强的检查。它包含以下几点:

• 面试
• 观察
• 反馈
• 投诉监控

交付性能域中的重要定义

在交付绩效领域的介绍中，项目管理知识体系7(在方框中)强调了行话术语的五个关键定义:

1. 要求
   一个坚实的定义
2. 工作分解结构(WBS)
   一个坚实的定义
3. 已完成的定义(国防部)
   由于明确提及准备好而削弱的一个合理的定义客户使用的．“客户”的使用限制了这个定义——我想添加一些东西，比如“或释放给受益所有人”．
4. 质量
   我觉得这个定义有点令人惊讶，因为它没有提及任何标准、水平或等级。然而，这是合理的。
5. 质量成本(CoQ)
   一个优秀的定义

似乎缺少的是以下定义:

• 范围
  因为这和质量是性能领域的主要关注点
• 可交付成果
  在下一页有一个很好的定义

我不认为有任何理由在这一点上引用PMI的定义。但是，我们将在讨论本节的主体时返回到其中一些。

添加我的版本，如果有用，然后添加其他版本

交付领域的基本原则

项目管理知识体系7明确了一些重要原则:

1. 项目支持业务目标的交付和战略的实现
2. 他们对交付的解释是满足实现这一目标的范围和质量期望，而不是如何实现
3. 这种产品、服务或补救的交付为业务提供了价值
4. 涉众可能从不同的项目结果中感知到不同层次的价值

第二点是我对这个项目性能域的主要关注。然而，我必须承认，这在很大程度上与项目管理知识体系7基于原则的方法是一致的。

PMI对交付性能域组件的描述

除了与其他域的交互(下面讨论)和检查结果(上面讨论)这两个通常的子部分之外，在这个性能域中有四个子部分:

1. 交付的价值
   简明扼要
2. 可交付成果
   优秀的
3. 质量
   最优秀的
4. 次优的结果
   一个让人感觉匆忙和缺乏的有趣话题

让我们看看每一个都包含了什么。

交付的价值

项目管理标准是项目管理知识体系第7卷第1部分的核心内容。这一小部分建立在标准第5页关于价值的模糊定义之上:

”价值．价值:某物的价值、重要性或用处

项目管理标准，7^th版
项目管理学院，2021年

虽然这是一个非常短的部分，没有正确地定义价值，但它在四个简短的段落中提出了四个要点。

1. 价值可以以增量的方式交付，在整个生命周期中以块的形式交付，也可以一次性交付(所谓的“大爆炸的方法”)在生命周期的末尾。我真的很想看到一个提醒，渐进主义不是自适应项目管理的专属。
2. 产品或服务生命周期对于价值交付是至关重要的，因此价值交付超出了项目的结束。
3. 有许多方法可以演示业务价值，从正式的业务用例文档到精益“启动油画”．
4. 这些文件需要根据它们所提供的承诺来评估结果。

可交付成果

这个部分很好，有三个部分:

1.需求

这明确规定了以下原则:

• 需求捕获
  有一套有用的标准
• 发展和发现需求
  在自适应项目
• 管理需求
  这阐述了积极管理的理由，也提出了一些基本的工具

2.范围定义

这篇文章很好地涵盖了两个核心主题:

1. 范围分解
   对于预测性项目中工作分解结构的使用，以及适应性项目中路线图、史诗和用户故事的使用，有一个简单但清晰的评估。
2. 完成了可交付成果
   有帮助的(如果重叠)定义:
   • 验收或完成标准
   • 技术性能的措施
   • “完成”的定义

了解更多…

• 范围管理的基础知识:如何管理范围|视频
• 建立项目范围:如何掌握最困难的项目管理挑战
• 范围管理计划:你需要知道的一切

3.移动竣工目标

在可交付内容下的最后一小节承认，您的项目的目标及其完成的定义可能会因为许多可能的原因中的一个或多个而改变。

顺便说一下，“完成”的定义是在您认为交付物完成之前需要满足的标准清单。我喜欢这部分的概念，这对我来说是新的“做漂移”．

这一部分还以一段关于范围渐变和变更控制．

了解更多…

• 如何防止范围爬行|视频
• 项目变更控制:你需要知道什么使它有效

质量

这也是本领域非常重要的一部分——特别是本节的第一部分，关于质量成本。这提醒我们:

“质量成本(CoQ):在产品生命周期内，为防止不符合要求而进行的投资、对符合要求的产品或服务进行评估以及未能满足要求而产生的所有成本。”

项目管理知识体系指南，7^th版
项目管理学院，2021年

质量成本的描述将其分离为不同的成本元素，产生于:

1. 预防
   这是质量设计和质量保证
2. 评估
   这是质量控制
3. 内部故障
   在客户收到产品之前发现并修复缺陷
4. 外部故障
   在客户收到产品后发现并修复缺陷

本节的第二部分讨论更改的成本。它不是关于控制变化，甚至也不是关于范围或功能的变化，而是专注于由质量缺陷引起的变化。

但这里的差距不是我主要关心的。项目管理知识体系7再现了Barry Boehm的变更成本曲线。这条曲线显示了变化的成本呈指数增长。他在1976年的一篇期刊文章中首次发表了这篇文章，然后在1984年的书中复制了这篇文章，软件工程经济学．

我所关心的是，作者并没有声明这条曲线仅用于软件开发，并且是在预测(瀑布)范式下开发的。因此，它不适用于以下任何一种情况:

• 非软件预测项目
  的“S-curves”更典型的
• 现代软件开发
  持续交付意味着变更的成本可能会在项目结束时波动并上升一点，但在大多数迭代过程中基本保持不变。这是敏捷交付模型的主要理由之一!

了解更多…

• 项目质量管理:你需要知道的原则和实践
• 赞扬质量:为什么它应该对你|视频

次优的结果

这是一个简短的部分，有助于确定结果令人失望的可能性，并提供了一小部分可能的原因。但是在它的结尾句中却让人非常失望，因为它只是暗示有效的项目管理可以帮助最小化这种情况，但是次优结果的可能性只是结果“尝试生产一种独特的可交付产品的不确定性”．

这不是错误的。它只不过是在说明流血的明显!

交付领域的关键评估

我将评估7个项目性能领域中的每一个^th项目管理知识体系指南的5分制版本，包括:

1. 缺乏
   只是顺便提一下重要的事
2. 可怜的
   需要做很多工作
3. 好吧
   需要大量工作
4. 好
   会是伟大的，但需要小的调整吗
5. 优秀的
   我所希望的一切

这个比其他的更容易评估，但比其他的更难。困难来自于作者为这个性能域选择的有限定义。从表面上看，这是一个弱点。然而，就其本身而言，该定义意味着很容易根据这样一个简单的定义来评估内容。

这样做——似乎是最公平的方法——让我有两个选择:好或好。还有工作要做。但是我认为在交付性能领域有很多值得喜欢的地方。三个主要的子部分都很好，关于可交付内容的子部分非常棒。是的，8^th版需修正费用变更分项。我真的希望他们能给次优结果这部分赋予一些价值。但我认为这只是一些小调整。认为交付性能域是稳固的好我给它打a4．

项目管理知识体系7交付领域的优势

交付性能域的主要优势在于它对以下内容的讨论:

• 价值
• 可交付成果(优秀)
• 质量成本(优)

项目管理知识体系7交付领域的弱点

我将从三个方面列出这个性能领域的弱点:

1. 少了什么
   我将在本文的下一节中对此进行讨论。
2. 什么是弱
   • 价值
     我真的很想看到一个更深入的评估，价值意味着什么，它是如何与利益、ROI、范围、质量和结果联系起来的
   • 成本的改变
     在某种程度上，这里的东西是弱的。其他部分(见下文)只需要修复!
   • 次优的结果
     这是一个很好的附加功能，但未能实现其承诺
3. 需要修改什么
   • 成本的改变
     事实上，使用Boehm曲线而没有批判性的评价——甚至没有清晰的描述——是一个很大的失败。这个模型没有错，但在21世纪20年代，它需要替代模型的背景。

我们还应该在交付绩效领域包括什么?

如上所述，我认为我希望在交付领域中增加四件事:

1. 成本管理
   可以说不符合定义，但没有它就很难谈价值。然而，对结果的检查只涉及利益，因此价值的成本部分可能不需要。
2. 进度管理
   我承认这似乎超出了作者对性能域定义的范围。但是这是在8个性能域中的哪个位置呢?IT不属于度量性能领域——我将在本系列的下一篇文章中抱怨这一点!
3. 配置管理
   这个话题与其说是关于如何做，不如说是关于做什么。因此，如果性能域模型仍然存在，我真的希望在项目管理知识体系指南的未来版本中看到这一点。
4. 福利管理
   效益比价值更容易管理:如果你管理效益和成本，你就管理价值。这里并没有太多关于实际交付价值的内容。

交付绩效域如何与其他项目管理域相关联

我认为项目管理知识体系7在很大程度上是正确的，它关注的是各个环节:

• 从规划性能域到交付域
• 制定交付节奏的开发方法和生命周期绩效域
• 与项目工作绩效域，其中包含了很多“如何”
• 还有团队绩效域，因为是团队进行交付

但是，就像往常一样，看到这个项目性能域与所有其他性能域的集成是正确的。《我们》:

• 选择我们的可交付成果以满足涉众的需求
• 测量结果以控制交付
• 在交付过程中处理不确定性

您对交付性能领域有什么想法?

请分享您对PMI处理交付性能域的方式的看法，以及您对它的任何意见。我一定会回复你在下面发表的任何评论。

项目管理领域电子书系列

这是我们的《交付》卷中的一章Kindle独家项目管理领域电子书系列．