项目管理知识体系7开发方法绩效领域:是否错失良机?

在任何项目中，最重要的决定之一就是你将采取什么开发方法，你将以什么方法为基础，以及你将如何构建你的项目生命周期。

“等一下!”这不是“剪裁”吗?你最近不是写了一篇关于剪裁的文章吗?”

好问题。

是的，我们最近确实写了一篇关于剪裁的文章:“裁剪:如何确定合适的项目方法论、方法和实践”．但裁剪是一个更广泛的概念。剪裁包括:

• 方法
• 生命周期
• 流程
• 治理
• 工具
• 方法
• 工件
• 实际上是你对如何交付项目所做的任何选择。

因此，这个项目域只是8个域中的一个，您需要根据您的项目需求、您的组织文化、您的团队成员以及涉众的更广泛的政治环境来定制它。

也就是说，这是7个项目绩效领域中的一个^thPMBOK指南的版本，在您的剪裁决策中发挥最大的作用。

本文结构

这是我们八篇系列文章中的第三篇，涵盖了PMI项目管理知识体系指南的八个项目绩效领域，7^th对于这些域的一般介绍，请查看我们的文章，项目绩效领域:你知道它们是什么吗?为什么它们很重要?

有关PMBOK指南(第七版)的更多信息:

• 我们的文章:PMBOK指南第七版:回答你的20个最重要的问题
• 采访作者之一:PMBOK 7: PMI项目管理知识体系指南的第7版-与Nader Rad
• 购买您的PMBOK 7．

在本文中，我们将研究:

• 什么是开发方法和生命周期性能领域?
• PMI对开发方法和生命周期性能域组件的描述
• 开发方法和生命周期领域的关键评估
• 我们还应该在开发方法和生命周期性能领域中包括什么?
• 开发方法和生命周期性能领域如何与其他项目管理领域相关联

什么是开发方法和生命周期领域?

开发方法和生命周期性能域都是关于“大局”你如何交付一个项目:

• 您选择的方法类型
  但不是你将使用的具体方法，也不是你所做的调整
• 一般节奏(或'节奏’)的重要事件
  但不是每天的活动安排
• 项目中的主要阶段或阶段
  每个阶段的重点是什么，你将如何在时间上排列它们

项目管理知识体系对开发方法和生命周期性能域的定义

PMBOK 7这样定义这个性能域:

“开发方法和生命周期性能领域处理与项目的开发方法、节奏和生命周期阶段相关的活动和功能。”

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

我想你会同意这个“定义”只不过是标题的一个轻微扩展。那么，我该如何展开它呢?

我们对开发方法和生命周期性能域的扩展定义

我建议使用收缩定义，而不是扩展定义。也就是说，我会用更少的词。然而，至关重要的是，这个定义确实意味着对性能域的关注范围的扩大，这是我希望在PMBOK指南的未来版本中看到的。总是假设，也就是说，将来的定义保持相同的基本性能域结构。

“开发方法和生命周期性能领域解决了交付项目的战略方法。”

迈克·克莱顿博士，2022年

这“战略的方法”当然包括:

• 开发方法
• 节奏
• 生命周期阶段

但是，它还包括两个大项目，我认为这是PMBOK 7在性能领域所缺失的。我稍后会更详细地介绍它们，它们是:

1. 治理和治理结构
2. 采购和采购

开发方法和生命周期性能领域的预期结果

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

1. 与项目可交付成果一致的开发方法
2. 由连接业务和涉众价值交付的阶段组成的项目生命周期，从项目的开始到结束。
3. 项目生命周期由促进交付节奏和产生项目可交付成果所需的开发方法的阶段组成

让我们依次来看看这些。

开发方法

当然，您不能反驳开发方法需要与项目可交付成果相一致的断言。但他们也需要与政治环境和团队技能保持一致。

我同意，在理想的情况下，团队应该具备使用最佳开发方法进行工作的技能。我也承认，理想情况下，政治环境将允许为这项工作选择最佳的发展方法。但我们并不是生活在一个理想的世界。项目经理需要是实用主义者，擅长“凑合和修补”的技巧。

所以，我很高兴，只要我们认识到这句话说与…一致而不是被优化为．我认为作者在这里的措辞非常谨慎。

项目生命周期阶段和价值交付

首先，我想借此机会指出，PMI选择了“阶段”这个词——就像它在以前的版本中所做的那样。事实上，PMBOK 7中的定义与其前身PMBOK 6相匹配。

您可以认为这种用法与阶段是可互换的。phase可能是更常用的术语:

• 项目管理协会:阶段”
• 国际项目经理协会:阶段”
• 国际项目管理协会:阶段和"阶段”
• PRINCE2:“阶段”

这种理想的结果并没有错。只是感觉有点…显而易见。然而，作为PMBOK 7朝着注重价值的方向迈进的一部分，我对此表示欢迎。

顺便说一下，你可能会喜欢我们的文章，项目生命周期和四个基本阶段．

促进交付节奏的项目生命周期阶段和产生项目可交付成果的开发方法

这难道不是与之前期望的结果相辅相成的吗?就交付物驱动价值实现的程度而言，这是多余的。如果可交付成果与价值的交付无关，那么谁会在乎它们呢?

验证来自开发方法和生命周期性能领域的结果

对于每个领域，项目管理知识7还设置了“检查”，通过这些检查，我们可以根据绩效领域的每个结果评估项目绩效。

我对PMBOK 7中这个项目性能域的期望结果的不满，由于我对这里的检查的彻底失望而加剧了。我为创建一套支票的愿望喝彩。但这些只不过是对结果的重申。如果你得到了结果，那么“检查满意”。

我会用我自己的话来解释这些支票。但是，对于前两种情况，除了多说几句话外，它们对结果陈述没有任何补充。然而，让我们来看看第三个。

促进交付节奏的项目生命周期阶段和产生项目可交付成果的开发方法

这确实增加了价值，因为它承认不同的交付可以有不同的交付节奏和开发方法。这些过程可能需要周期或重叠阶段。然而，检查的文本并不代表“如何检查”您是否有期望的结果的明确指南。

开发方法和生命周期性能领域中的重要定义

在开发方法和生命周期性能领域的介绍中，项目管理知识体系7(在方框中)强调了行话术语的五个关键定义:

让我们按照PMBOK 7展示它们的顺序来看它们，从奇数开始，因为它不是域的主题。

可交付物的定义

”可交付成果．任何独特的、可验证的产品、结果或执行服务的能力，都需要生产来完成一个过程、阶段或项目。”

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

这是一个很好的定义，尽管有点啰嗦。我的想法是:

”我们的项目生成的东西被称为可交付成果或产品．它们有时也被称为产出，是项目产生的物质或智力成果。”

置身内部:解码项目管理的行话，2^nd版
迈克·克莱顿在线报道点课程

有趣的是，APM的知识体系，APMBoK 7^th版，不包括'交付'在其词汇表。PRINCE2采用了一种非常不同的方法，这对我来说很有趣。首先，它使用术语“输出”，并将用户发送到术语表中“可交付的”条目的定义。

”输出．交付给用户(或用户)的专业产品。
请注意，管理产品不是输出，而仅仅是为了控制项目而创建的。

使用PRINCE2管理成功的项目
Axelos limited, 2017年

这里，PRINCE2定义区分的最终可交付成果，它称之为“输出”,“临时交付”，它称之为“管理产品”．

发展方法的定义

PMBOK指南为我们提供了这个简单的定义，其中也包含了它自己的例子。

”开发方法．在项目生命周期中用于创建和发展产品、服务或结果的方法，如预测、迭代、增量、自适应或混合方法。

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

项目管理协会将开发方法简单地称为“方法”，或者更宏大地称为“部署哲学”。它在术语表中没有定义。我也不知道。

韵律的定义

PMBOK 7的定义非常简洁，我没有什么可补充的。

”节奏．通过项目进行的活动节奏。”

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

项目阶段的定义

我喜欢项目管理知识体系对项目阶段的定义:

”项目阶段．逻辑上相关的项目活动的集合，最终完成一个或多个可交付成果。”

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

根据我对PRINCE2输出/可交付物定义的评论，这里的可交付物可以是最终可交付物或临时可交付物，如项目定义声明、业务案例、项目计划或原型测试报告。

我自己的定义更侧重于目的，而不是项目阶段的性质:

项目被分为阶段,或阶段帮助我们管理它们。”

置身内部:解码项目管理的行话，2^nd版
迈克·克莱顿在线报道点课程

APM在其APMBoK 7中为我们提供了最令人钦佩的简明定义^th版。

”阶段．生命周期的主要细分

APM知识体系，7^th版
项目管理协会，2019年

我必须说，与所有这些相比，PRINCE2文档中管理阶段(其等效术语)的定义是极其笨拙的。所增加的是项目委员会在阶段结束时审查进度、风险和计划的机会。这为PRINCE2的网关审查过程(Stage Gates)铺平了道路，我将在下面回到这个过程。

项目生命周期的定义

PMBOK 7提供的最后一个定义是项目生命周期。

”项目生命周期．一个项目从开始到完成所经历的一系列阶段。

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

我不能反驳这个定义。事实上，我自己的情况也非常相似:

”生命周期．从项目开始到结束的一系列阶段。

置身内部:解码项目管理的行话，2^nd版
迈克·克莱顿在线报道点课程

而且，虽然PRINCE2书不屑于提供定义，但APM用迄今为止最冗长的版本来弥补它!

”生命周期．一个由一系列不同的高级阶段组成的框架，需要将概念的想法有序而有效地转化为现实。生命周期为开展基于项目的工作提供了系统和有组织的方式，可以被视为支撑部署的结构。”

APM知识体系，7^th版
项目管理协会，2019年

唷!我不相信这45个词对我们的理解有任何帮助。

PMI对开发方法和生命周期性能域组件的描述

在三行简单的介绍之后，我们有如下的小节:

• 交付节奏
• 开发方法
• 选择开发方法的考虑因素
• 生命周期和阶段定义
• 调整交付节奏、开发方法和生命周期

我不能(出于公平和版权的原因)分享这些子部分的太多细节，但是让我们看一下每个子部分的高级摘要。

交付节奏

这提供了四种类型的交付节奏。然而，相当奇怪的是，最后一项(连续交付)被放到一个盒子里，使得它看起来不那么重要。事实并非如此。这四种类型是:

1. 单交货
   有时被称为“大爆炸”方法，即在一次交接活动中交付所有内容
2. 多个交付
   听起来就是这样。PMBOK提供了将交付分成一系列单独交付的几个示例
3. 定期交货
   多个交付遵循常规的发布模式
4. 持续交付
   不断交付增量改进的补充。这是DevOps(开发操作)中的注释

开发方法

在我看来:

所有的项目管理都是混合项目管理。”

但是，从预测到自适应的方法有很多，我们可以从任何一端调用工具、方法和结构来创造适合我们的混合。是的，您的开发方法可能位于一端。但我不相信你会做一个没有工具、方法、想法或工件的项目，有人会认为这是相反的。

PMBOK 7用一个简单的案例研究风格描述和说明:

• 预测的方法
• 混合方法
  用一个合理(但有些缺乏)的图表来解释这些术语“迭代”而且“增量”
• 自适应方法

耽误!你说“有点缺乏”是什么意思?

项目管理知识体系指南遗漏的是对迭代至关重要的一件事。它将一次迭代的输出作为下一次迭代的输入。

想进一步了解这三种发展方法吗?

看看我们的文章:

• 敏捷vs瀑布:哪个更适合你的项目?
• 混合项目管理:你需要知道的

选择开发方法的考虑因素

本节为我们提供了在选择开发方法时需要考虑的三件事情。这些清单是:

1. 产品、服务或结果的考虑
2. 项目注意事项
3. 组织考虑

我想PMI会认为我为这些段落提供一个词是不合理的。然而，我可以提供给你我自己的清单，令人高兴的是，它更全面，包括作者似乎省略了的项目。

的可交付成果

• 规模
• 简报中的自信
• 创新vs重复
• 复杂性
• 战略优先级和价值
• 需求/范围的波动性
• 更改的便利性
• 质量和监管标准
• 风险
• 健康和安全要求
• 安全需求
• 竞争压力

这个项目

• 调度的约束
• 资源约束
• 融资约束
• 外部依赖关系
• 治理的需求
• 团队结构及位置
• 涉众的需求、优先级、偏好和态度

该组织

• 结构和治理过程
• 政策——特别是……
• 采购政策
• 文化
• 能力
• 能力
• 政治和政治压力
• 地理结构

生命周期和阶段定义

在这里，PMBOK指南为我们提供了几个预测生命周期阶段的例子，以及一个混合版本，在更广泛的线性结构中使用周期。还有一个自适应开发方法中的迭代示例。总而言之，本小节内容不多。

调整交付节奏、开发方法和生命周期

这一部分回顾了开发方法小节中正在运行的迷你案例研究，展示了不同的可交付成果如何需要各自的交付节奏和开发方法。接下来是另一个示例交付方法，在每个阶段中都有一个简短的韵律讨论。

开发方法和生命周期领域的关键评估

我将评估7个项目绩效领域中的每一个^thPMBOK指南的5分制版本:

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

我在这里真的很挣扎。我的一部分想给这个项目的表现领域打3分，“好”。但事实上，我认为证据指向2分，“可怜的”．

我的理由在下面的段落中，关于这个领域的弱点。

项目管理知识体系7开发方法和生命周期领域的优势

我认为PMBOK 7团队将其视为项目性能域是一个真正的优势。

有些内容还可以，近乎不错。但远不是全部。我也很喜欢这个例子。

项目管理知识体系7开发方法和生命周期领域的弱点

在我们必须考虑的这个项目性能领域成熟表达的临时开始中有很多缺陷。主要缺点是:

1. 这些定义有些重复。它们只是陈述一些显而易见的东西，并没有给标题增加什么价值
2. 期望的结果很弱，而支票更弱。
3. 有些主要内容充其量是“还可以”。
4. 性能域只有三个关键元素，我认为应该有两个以上的关键元素。这意味着游戏缺少40%的核心内容。
5. 该领域与项目管理知识体系指南中项目绩效领域(裁剪)后面的部分之间的集成很弱，甚至不存在。然而，它们应该更紧密地结合在一起，更清晰地描绘出相互之间的联系
6. 与其他域交互的部分遗漏了一个重要的部分

我们还应该在开发方法和生命周期性能领域中包括什么?

正如我在本文开头所提到的，我认为在PMBOK 7中，性能领域缺少两大项目。这些都是:

1. 治理和治理结构
2. 采购和采购

每一个都代表着一个巨大的，被错过的机会。

1. 首先是有机会更好地纳入项目管理的一个重要元素，这个元素在本版PMBOK指南中仍然没有得到适当的反映。
2. 第二个是有机会从战略上看出现在Project Work性能领域的主题，在那里它被非常肤浅地覆盖

治理和治理结构

这将是讨论在不同交付方式下的良好治理选择的最佳场所。毕竟，剪裁部分只粗略地提到了这个重要的主题三次。并且它不会出现在任何其他项目性能域中，只在质量域中保存一个传递的引用。

这才是最合适的地方。这是起草这个领域的一个重大疏忽。

看看我们的文章:项目治理为我们做过什么?[答:很多]．

项目阶段门

这难道不是PMBOK 7引用阶段门、阶段门、边界门或网关的完美地方吗?绝对会的。

看看我们的文章:阶段门流程如何让你成为更好的项目经理

采购和采购

战略采购不仅仅是选择供应商。它包括开发方法决策，比如我们要:

• 购买现成的部件
• 从头创建组件
• 所有的工作都在公司内部完成
• 把所有的工作都外包出去
• 引入承包商来完成部分或全部工作
• 让顾问来领导我们的部分工作
• 与其他行业参与者合作

……还有更多。

这些都是许多项目面临的重大而重要的选择。然而，书中根本没有提到它们。

开发方法和生命周期性能领域如何与其他项目管理领域相关联

这个性能域必须是您创建项目的中心。

PMBOK纪德列出了与之交互的七个其他项目性能域中的六个。这引出了一个问题:“那另一个呢?””

缺少的是测量。然而，可以衡量的东西肯定会得到管理。开发方法是关于选择我们如何管理我们的项目。每种方法都需要自己的衡量机制。并且每个交付节奏都会有相应的测量节奏。

我非常喜欢将开发方法和交付节奏的选择作为风险管理的重要部分。但是，我发现，没有提及与测量的关系是不可原谅的。

项目管理领域电子书系列

这是我们Kindle独家项目管理领域电子书系列的开发方法和生命周期卷中的一章。

您对开发方法和生命周期性能领域有什么看法?

请分享您对PMI处理[…]性能域的方式的看法以及您对此的任何评论。我一定会回复你在下面发表的任何评论。

奖金的视频