7.5.1 Purpose
The purpose of Define Design Options is to define the solution approach, identify opportunities to improve the business, allocate requirements across solution components, and represent design options that achieve the desired future state.
7.5.2 Description
When designing a solution, there may be one or more design options identified. Each design option represents a way to satisfy a set of requirements. Design options exist at a lower level than the change strategy, and are tactical rather than strategic. As a solution is developed, tactical trade-offs may need to be made among design alternatives. Business analysts must assess the effect these tradeoffs will have on the delivery of value to stakeholders. As initiatives progress and requirements evolve, design options evolve as well.
7.5.3 Inputs
- Change Strategy: describes the approach that will be followed to transition to the future state. This may have some impact on design decisions in terms of what is feasible or possible.
- Requirements (validated, prioritized): only validated requirements are considered in design options. Knowing the requirement priorities aids in the suggestion of reasonable design options. Requirements with the highest priorities might deserve more weight in choosing solution components to best meet them as compared to lower priority requirements.
- Requirements Architecture: the full set of requirements and their relationships is important for defining design options that can address the holistic set of requirements.
7.5.4 Elements
.1 Define Solution Approaches
The solution approach describes whether solution components will be created or purchased, or some combination of both. Business analysts assess the merits of the solution approaches for each design option.
Solution approaches include:
- Create: solution components are assembled, constructed, or developed by experts as a direct response to a set of requirements. The requirements and the design options have enough detail to make a decision about which solution to construct. This option includes modifying an existing solution.
- Purchase: solution components are selected from a set of offerings that fulfill the requirements. The requirements and design options have enough detail to make a recommendation about which solution to purchase. These offerings are usually products or services owned and maintained by third parties.
- Combination of both: not all design options will fall strictly into one of the categories above. Design options may include a combination of both creation and purchase of components. In all of these types of approaches, proposed integration of the components is also considered within the design option.
.2 Identify Improvement Opportunities
When proposing design options, a number of opportunities to improve the operation of the business may occur and are compared.
Some common examples of opportunities include:
- Increase Efficiencies: automate or simplify the work people perform by reengineering or sharing processes, changing responsibilities, or outsourcing. Automation may also increase consistency of behavior, reducing the likelihood of different stakeholders performing the same function in distinctly different fashions.
- Improve Access to Information: provide greater amounts of information to staff who interface directly or indirectly with customers, thereby reducing the need for specialists.
- Identify Additional Capabilities: highlight capabilities that have the potential to provide future value and can be supported by the solution. These capabilities may not necessarily be of immediate value to the organization (for example, a software application with features the organization anticipates using in the future).
.3 Requirements Allocation
Requirements allocation is the process of assigning requirements to solution components and releases to best achieve the objectives. Allocation is supported by assessing the trade-offs between alternatives in order to maximize benefits and minimize costs. The value of a solution might vary depending on how requirements are implemented and when the solution becomes available to stakeholders. The objective of allocation is to maximize that value.
Requirements may be allocated between organizational units, job functions, solution components, or releases of a solution. Requirements allocation typically begins when a solution approach has been determined, and continues until all valid requirements are allocated. Allocation typically continues through design and implementation of a solution.
.4 Describe Design Options
Design options are investigated and developed while considering the desired future state, and in order to ensure the design option is valid. Solution performance measures are defined for each design option.
A design option usually consists of many design components, each described by a design element. Design elements may describe:
- business policies and business rules,
- business processes to be performed and managed,
- people who operate and maintain the solution, including their job functions and responsibilities,
- operational business decisions to be made, software applications and application components used in the solution, and
- organizational structures, including interactions between the organization, its customers, and its suppliers.
7.5.5 Guidelines and Tools
- Existing Solutions: existing products or services, often third party, that are considered as a component of a design option.
- Future State Description: identifies the desired state of the enterprise that the design options will be part of, and helps to ensure design options are viable.
- Requirements (traced): define the design options that best fulfill known requirements.
- Solution Scope: defines the boundaries when selecting viable design options.
7.5.6 Techniques
- Benchmarking and Market Analysis: used to identify and analyze existing solutions and market trends.
- Brainstorming: used to help identify improvement opportunities and design options.
- Document Analysis: used to provide information needed to describe design options and design elements.
- Interviews: used to help identify improvement opportunities and design options.
- Lessons Learned: used to help identify improvement opportunities.
- Mind Mapping: used to identify and explore possible design options.
- Root Cause Analysis: used to understand the underlying cause of the problems being addressed in the change to propose solutions to address them.
- Survey or Questionnaire: used to help identify improvement opportunities and design options.
- Vendor Assessment: used to couple the assessment of a third party solution with an assessment of the vendor to ensure that the solution is viable and all parties will be able to develop and maintain a healthy working relationship.
- Workshops: used to help identify improvement opportunities and design options.
7.5.7 Stakeholders
- Domain Subject Matter Expert: provides the expertise within the business to provide input and feedback when evaluating solution alternatives, particularly for the potential benefits of a solution.
- Implementation Subject Matter Expert: use their expertise in terms of the design options being considered to provide needed input about the constraints of a solution and its costs.
- Operational Support: can help evaluate the difficulty and costs of integrating proposed solutions with existing processes and systems.
- Project Manager: plans and manages the solution definition process, including the solution scope and any risks associated with the proposed solutions.
- Supplier: provides information on the functionality associated with a particular design option.
7.5.8 Outputs
- Design Options: describe various ways to satisfy one or more needs in a context. They may include solution approach, potential improvement opportunities provided by the option, and the components that define the option.
