阶段性的计划交付
平均的 IT 项目越来越小。平均较小的项目会有更成功的项目成果， 2 参见图 1，并且证明是更有生产力的。与此同时，综合的商业过程需要复杂度不断增加的 IT 系统集合的支持。这意味着交付主要的商业价值需要以公共使命为中心的一组项目的协同执行，并且经常需要资源、技术、架构，和时间线的协调。这通过计划管理来完成。
有效的计划管理向商家交付增量的价值，它知道如何筹备/安排计划，以便计划中所有项目的子集围绕一组核心的商业目标而协同工作。这一般需要将较大的目标分为子目标，将项目映射为根据这些子目标进行交付。计划将推动相关的项目集合的资源分配和管理，尽可能早地交付相关的商业目标或子目标，这叫做阶段的计划交付，如图 2 所示。
图 2：阶段的计划交付意思是将计划中的项目分成小组，这样每个项目小组可以尽可能早地交付增量的价值。
一旦定义了计划阶段，就通过控制项目对该阶段中的项目进行管理，和通常的 RUP 项目有同样的阶段，如图 3 所示。
控制项目管理集成，并且提供集中于风险和变化的减少的管理里程碑。通过对所有项目的总的评估来评估控制项目。然而，要评估整体计划的风险预测，您不能简单地将每个项目的风险预测汇集起来，您还需要确保与跨项目集成相关的风险已经得到了处理。在提供计划中个别项目的执行的灵活性的同时，控制项目的用途是让计划协同执行。在此，迭代扮演了基础的角色，因为它们提供了稳定的参照点，从而令计划中的项目可以跨项目集成，并且证实有意义。
图 3. 通过控制项目管理计划阶段，通过这个方式可以有效地管理风险的减少和价值的生成。
阶段的计划交付，特别是在利用控制项目时，提供许多好处：
- 着重于商业目标上的有效执行。通过根据商业目标将项目分组，并且将它们作为计划进行管理，我们可以根据主要的商业目标更有效地交付。
- 许多相关部分的协同发布。通过一组着重于风险和变化的减少，以及价值生成的里程碑，控制项目向我们提供定义明确的计划的治理里程碑。
- 增加的价值的交付。将潜在的非常大的计划进行划分可以围绕商业子目标增量地交付价值。通过用迭代的开发技术来管理计划中的项目，可以按照需要部署演进的能力。
- 提高的效率。项目的半独立的执行令各种项目中的有效开发能够进行，因为它提供尽可能多的策略上的灵活性，因而实现了更高的生产力。然而，我们需要可视的控制点来进行个别的项目表现和总体的计划的评估。可以在每个迭代的末尾，利用基于事实的评估来对个别项目的表现进行评估，假设这些项目使用了迭代的开发。
权衡
对于有效的阶段的计划交付有两个重要的权衡。
- 增加协调。执行计划需要协调，这需要资源和知识。
- 延迟的风险。当没有管理好时，计划可能会导致进行最慢的项目来决定发布。在最坏的情况下，这会导致大部分项目团队等待公司的“更大好处”，但事实是这常常是对公司有害的。技巧是进行充分的监督，当给定的项目不能继续时重新确定您的计划范围，这样您仍旧可以在早期交付一些商业价值。
反模式
以下的反模式与通过商业价值管理项目管道相关：
- Slowest drum beat（最慢的打鼓声）。计划中最慢的项目决定整个工作的速度。有效的计划被看作是一列火车 —— 火车在特定时间离开车站，而不论上面有没有项目。
推荐的默认做法
我们推荐由控制项目管理的较小的计划根据 RUP 的四个阶段运行，其中有松散耦合的个别项目，每个都依据 RUP 的迭代方法。
组织和会议
此分类中的实践指导确定适当的组织结构和形式的报告机制，以和正确的项目涉众关注正确的层次。这些实践是：
业务驱动的项目规划
IT 项目的需求总是大于可用的资源，这迫使我们在管道中对潜在的项目排列优先次序，并且优化所选的项目，以结合我们的策略。一个好的治理解决方案应该将开发投资的商业价值最大化，并且确保与商业目标的战略上的结合，而我们需要一种完成这件事的机制。可以利用计分卡和其他项目组合管理策略来有效地实现，其中根据一组反映出战略结合及商业价值的确定的参数来评估每个项目。
应该注意的是，计分卡是商业价值的模型，而所有模型都有它们的局限性。这意味着您可能有时候发现分数较低的项目应该比分数较高的项目优先，迫使手工进行阻止，但还是在这种情况下，计分卡促使关于策略和商业价值的讨论，展现出为什么该模型在一些少有的情况下是不完美的。
好处
通过商业价值管理项目管道带来以下好处：
- 聚集在商业价值之上。管道管理促使组织商定商业策略，以及什么参数推动最大的商业价值。举例来说，考虑这些问题：您的 IT 组织应该将新的商业机会的支持、正在进行的商业过程的成本效率的提高，或更快速的组织成长划分优先级吗？这些问题促使围绕集中于战略结合及商业价值的项目的资金投入的讨论。
- 提高 ROI。选择最佳地混合了风险、价值回报和策略结合的项目，推动更高的整体 ROI。计分卡还为整个 IT 部分结合策略，并最大化商业价值提供强大的沟通和动力机制。如果您想让您的项目得到投资，那么您需要确保它很好地结合了对于商家最重要的东西。
- 提高透明度。在许多组织中，投资决策如何制定是一个迷。依据商业价值的管道管理可以以开放且透明的方式进行，这样提高了可见性，并建立了信任。
权衡
当根据商业价值管理项目管道时要考虑的权衡包括：
- 策略及价值清晰度。管道管理迫使您确定推动投资的内容应该是什么。这很难，并且迫使您通过“大胆地摸索”来确定您的策略“需要是”什么，将要是什么。
- 放弃控制。过程更加客观且开放，并且要求每个项目都能联系它的商业价值。这可能不会要求每个人，特别是那些安于现状的人。
- 频率。管道管理需要在常规的基础上进行，例如每周或每月，以便不延迟项目。这需要实质的投资来使工作有效。
反模式
以下反模式与项目管道的管理相关联：
- 主观的项目得分。如果项目选择成为主观的，且每个项目都不同，并且如果决策不是可追溯或可防御的，那么您就有一个工作得很糟糕得计分过程。（也许您的计分卡很难用，要求太多的主观性，或者在没有恰当的监督和透明性的情况下完成计分。）
- 实施的计分卡。我们已经看到过许多这样的情况，计分卡在书面上效果不错，但在实际中，它们优先考虑了错误的项目。过分强调问题，以至于“受宠的项目”排在顶部，或者仅仅错过对项目计分以获得您期望的政治上的回答，由于上述原因造成了这种情况。您需要校准您的计分卡，直到它正确为止。
- 项目组合负担。如果管理管道的过程是非常墨守陈规的，并且/或者增加了重大的项目计划的延时，那么计分的值可能不会促成障碍。
推荐的默认做法
我们推荐您关注的计分卡中参数要少于五个，并且推荐您将计分作为关于优先化的商业讨论的辅助，而不是严格的度量。
Scenario-Driven Development（场景驱动的开发）
在通过控制项目的阶段性计划交付实践之下，我们讨论了，综合的商业过程需要不断复杂的 IT 系统集合的支持，以及较小的项目比较大的项目更有效且有更高的成功率。我们可以将分为一组较小部件的 IT 系统看成一个系统，其中每个部件都被开发成其自身的一个系统，如图 4 所示。这种配置称为“复合系统”，其中各个部件是由个别项目开发的个别的应用程序。
在不了解局部的情况下，不能确定整体，而在不了解整体的情况下，不能确定局部。风险是我们不了解局部如何影响整个解决方案，而且我们将陷入构建不能结合在一起的局部。因此我们需要应用一种能让我们将整体和局部紧密地结合在一起的技术。我们通过在所有层次上应用用例来实现这一点：
- 通过用例场景来确定并不断使用需求 —— 也就是，展示局部需要如何协作来完成全系统的用例。
- 以同样的方式确定并不断使用架构和接口。
- 用例场景还推动系统级集成和测试场景，并确保局部交付整个系统中关键的端到端的用例。
图 4：在复合系统中，部件是由个别项目开发的个别的应用程序。
如今，我们在 IBM 软件集团中非常成功地应用了该技术。我们通过数百个团队来开发数百个应用程序，而客户同时使用许多我们的产品。在过去的几年里，我们为了那个推动局部更好地集成的整体解决方案，越来越关注端到端的业务场景（有时候称为未成熟的思路）。我们已经发现这使我们将资源优先化，这样这些资源为我们的客户增加最大的价值。
好处
使用复合系统思考的场景驱动的开发带来了许多好处：
- 关注商业能力的交付。它让每个项目都着重于它们的部分是如何向组织交付商业价值。
- 许多可动部分之间的更好的集成。它让开发不同应用程序的项目着重于应用程序之间的良好集成。关注集成是至关重要的，因为商业价值主要是通过端到端的业务场景进行交付，而不是由它们自己通过个别的部分进行交付。
- 提供控制机制。控制机制确保团队交付商业价值。此外，这种基于场景的方法帮助消除能力间的差距，并且可以确定不一致性和缺少进展的区域。
权衡
有两个与场景驱动开发相关的重要权衡：
- 商业和技术视角。此实践需要总体的商业和技术视野，而并非所有组织都处于可以提供该视野的足够的成熟度水平上。
- 企业级协调。此实践基于协调不同部分的开发的能力，而并非所有组织都有拥有在这么大规模中进行协调的能力。
反模式
以下反模式与场景驱动的开发相关联：
- 个人的视角。商业场景只从人脑中不精确地获取，而从不分享或编制文档。端到端的商业场景从不联接，因此决不要根据它们进行交付。
- IT 驱动的业务。虽然 IT 的角色是支持业务，但在此反模式中反过来了。当没有确定商业过程或没有使用商业过程来推动增量的 IT 能力时，就会发生这种事。
- 象牙塔式的商业模型。开发了商业过程，但 IT 项目没有有效地利用它们来推动增量的 IT 能力。
- 竖井式的项目。每个项目都尽力交付商业价值，但端到端的商业过程之间没有联接，项目之间没有协调。
推荐的默认做法
获取关键的商业过程，并用它们来推动并协调 IT 投资。
