总论
制定解决方案确定满足产出的各方面要求的最佳方法。它的目标是：
- 评估基线要求与满足要求的备选解决方案；
- 选择最优解决方案；
- 为解决方案创建规格要求。
要求管理创建了一套清晰的利益相关方要求，但并没有解释如何去满足那些要求。制定解决方案调研了为满足要求可用的诸多技术措施，再配合以投资评估，对各种不同措施的财务含义进行调研。
正如任何其他的功能一样，需要对制定解决方案做计划、予以启动。因为制定解决方案步骤是自然跟随在要求管理程序的各个步骤之后，通常就不大会对它做独立的规划计划与启动。然而，一些合同情境可能使要求管理与制定解决方案成为不同组织的职责，在这样的情况下，制定解决方案程序就需要独立于要求管理。
评估的时候，要审核备选方法，评估它们将参照所列的标准取得多好的绩效，例如资本成本、交付速度与风险程度。所涉及的技术从简单的制造或购买的考虑，到完全成熟的创新解决措施的建模与模拟技术。可以运用价值管理方法来帮助选择最佳价值方案。
产品证明是质量控制与配置管理的一部分。验证类似于持续确认目标保持其证明为正当合理的，如同商业论证中所定义的那样。
当一种解决措施经过评估，被选为最佳解决措施时，要制定成规格要求。有些情况下，规格要求中的详细要素只能覆盖制定阶段早期的需要，而后续阶段则需要随着工作的推进而进行优化。价值改善提议的制定，可以发生于交付流程中的任何一个阶段。
解决方案应该根据要求（要求本身可能也会发生变更）定期进行检查。这可以采用两种形式。“证明（Verification）”是用于确保所创建的解决方案是正确的；“验证(validation)”是用于确保正在创建的产品是正确的。证明根据规格要求进行，而验证则根据要求进行。
项目、项目群与项目组合
绝大部分项目是用来交付产出，而非其他。要求相对比较简单时，可以运用已经尝试过和测试过的技术。这类解决方案，利益相关方与管理团队都会毫无疑问地理解，例如我的要求是让我的车保持干燥与离开马路 – 那解决方案就是盖一个车库。
然后制定解决方案就只是创建规格要求，而不用先考虑备选措施，例如租一个车库或卖了汽车、以公共汽车代步。项目经理需要判断应该挑战利益相关方的假设到什么程度，并建议更为激进彻底的解决方案。
传统项目以规格要求描述产出。这被包含在定义文档中，并在定义流程结尾时向上递交以获批准。规格要求可能有额外信息的支持，例如产品或工作分解结构。
敏捷方法生命周期早期并不是那么强调和重视解决方案的详细规格要求。反而，他们专注于在一系列时间盒定时器或冲刺中逐渐交付的优先排序功能。产出的细节在反复中得到发展并解决IT项目的典型问题，即利益相关方接受系统的构成要素是比较困难的，要直到他们真正在行动中看到才行。
商业变革项目群的规格要求的对等物，就是蓝图。蓝图描绘了变革对组织产生的累积影响与效果。它描绘的是项目群所创建的所有成果的大图景。
项目群中的每个项目，都旨在交付一个对蓝图有贡献的产出。在大部分情况下，蓝图的详细程度将为项目管理团队留出足够的空间，考虑创建所需产出的备选方案。然而，项目群管理团队必须对项目解决方案加以协调，并评审提案。诸多因素例如可在项目间转移的通用的构件和技术平台，以及不同项目提出的解决方案之间的兼容性，都应该进行检查。
制定解决方案主要是项目与项目群的事情。但项目组合管理团队，可能需要对所考虑的解决方案类型具有限制的创新与风险，设定指导原则。
