Solution Options Analysis

In my last article, I introduced an approach to evaluating technology solution options. In this article, I am going to take you through my recommended format for solution options analysis. I typically create this in PowerPoint since it is getting presented to someone (or some committee) for a decision. You can also create it as a document or even a page in the online knowledge repository of your choice (e.g., Confluence, Sharepoint). This format scales up and down based on the complexity of the decision. I have used this format for large product and platform selections prior to a solution architecture design and for less impactful decisions made in the context of a solution architecture design.

Most Important Takeaway from this Article

Before we dive in, I'd like to highlight something essential. A solution options analysis exists to analyze what differentiates the options and summarize those differences for the decision-maker(s). Comprehensive coverage of the options is not your goal. Not keeping a razor-sharp focus on the differences is the biggest mistake people make when performing options analysis. Anything you include in your analysis that is not a differentiator is noise that hides the pertinent facts and clouds the analysis.

Solution Options Analysis Overview

The table of contents for my approach looks like this. In the sections below, I will dig into each.

Solution Options Analysis: The Details

Title

Actually, I *am* going to explain the title. The title is a concise context-setter. Words matter, so you should select a title that will immediately get your audience in the right ballpark for what this document contains. I stick with tried and true:

• A catchy name for the options being analyzed (e.g., "Partner Batch Integration Platforms")
• Solution Options Analysis (literally that)
• Author's name. Everyone needs to know who to blame for this!
• Date. A surprisingly critical piece of information to put on everything. It will be even more important in 10 years when someone is trying to clean out your document repository.

Introduction

Any document you create should have an introductory section to build the anticipation you started developing with your title. The introductory section is the equivalent of "you are here" on a map. You need to accomplish two things with a solution options analysis introduction:

1. Quickly get your audience up to speed with the why and what of the situation.
2. Set the audience's expectations. What is their role in the solution options analysis and what is expected of them.

I include three important pieces of information in my introduction:

• A background that explains what led to the need for this decision. How did we get here?
• A bulleted list of items confirming the scope of this decision. What is covered and what is not covered in this analysis? e.g., Only external partner batch integrations are in scope. I cannot stress the importance of clear scope enough. Anything a solution architect does that should start with ensuring all involved parties agree on scope. (A good idea for any role really!) For functional product evaluations, I recommend you define scope with a Solution User Diagram.
• A clear statement of objective. What is the purpose of the analysis? For a solution options analysis, it will likely always be the same: "Select the best something," but since I always use the same introduction slide for different analysis tools, it is helpful to confirm the objective.

Context

I call the slide where I provide additional technology, process, or business requirement detail the context slide because it sets the context for the decision. Sometimes you can set enough context with the introduction slide. Other times you need to provide more detail to help guide the decision. You should select an approach for this that works best for the analysis you are performing.

If you are creating an options analysis for a component of a solution architecture, you might include a conceptual view of the whole solution and indicate where the component fits. If understanding the business process around the technology solution is useful, perhaps diagram a high-level process view.

Options Summary

Now that you have provided the table-setting necessary for your analysis, it is time for you to summarize the options that you evaluated. For the options summary, I use a tabular format with the following columns:

1. The ordinal number of the option. Is there because people love to refer to "Option 1," "Option 2," etc., so why not accommodate?
2. A memorable name for the option. You know how, on those house hunting shows, they give a "nickname" for each house (e.g. "The Evergreen Estate")? That is to make it easy for viewers to remember what the options are. It will help your audience remember the options under evaluation as you throw all the facts at them.
3. A brief description of the option. This summarizes what the option is. For product or platform selections, that is often pretty easy; it is the product name. However, often times, it will take a little more narrative to make an option clear. In all cases, the description should focus on what is different about this option compared to the rest.
4. It will be no surprise to anyone that the last thing I include is a visualization of the option. What shape that takes will depend on the nature of the analysis. For a product selection, I will often use a product logo. For solution architecture options analysis, I include snippets of conceptual architectures that highlight the differences in the architectures of each option.

I usually include a listing below the table of the ruled-out options to stave off people jumping in with what-about's when I review the options with them.

Option Analysis

This is the pièce de résistance of your solution options analysis: the slides with the summaries of each option. The goal of these slides is to depict the differences between the options to help a decision-maker decide which option to select. I can't stress this enough - anything on the slides that does not help differentiate between the options clouds the decision. You should include one slide per option. I format my option slides as follows:

• Slide Title. You can grab this right off your summary slide above - the number and memorable name for your option.
• Description. You can also copy this from the summary slide, but feel free to add additional details since you now have more space. Add details only if required to make the option clear. You should include any of the benefits, risks, or impacts of the option in the description, but should use it simply to describe the solution proposed by this option.
• Visual! You know I love diagrams. If there is a way to visualize this solution (in a way that makes it easily distinguishable from the others), include the visual here. It can be the same one you used on the options summary or something a slight bit more since you now have a bit more real estate.
• Indicators. I find it helpful to include visual indicators in the upper left highlighting critical inputs to the decision, like risk, complexity, timeline, or cost. These can be icons or dashboard-style charts.
• Benefits/Impacts/Risks. I prefer identifying the benefits, impacts, and risks of each option vs. the traditional pros vs. cons. First, I think pros vs. cons rapidly devolves into pro-con soup, with pros for one option being cons on another and vice versa. Secondly, benefits, impacts, and risks help guide your thinking to the salient data points that will help drive the solution options analysis. I list benefits on the left and impacts and risks on the right. Number the lists for easy reference when discussing.
  • Benefits. What business value will this option bring that the others will not?
  • Impacts. What are the implications of this option? What will be true and not a benefit if this is selected.
  • Risks. What are the uncertain outcomes that are problematic? Refer to my solution architecture risk series, starting with Solution Architecture Risk: A Primer for the fundamentals of thinking about risk.

Commonalities

So I have reinforced a few times the importance of focusing the analysis on the differentiators between the options as that makes it easier for the decision-maker to follow the trail of facts. I find adding a slide that highlights the benefits, impacts, and risks shared by all the options helps you:

1. Think through the similarities and differences between the options.
2. Avoid "what about" questions from your audience.

I put this slide before all the options slides (to avoid the "what about"), but it wouldn't have made much sense to you if I had explained common benefits, impacts, and risks, before I explained the options slides above.

Recommendation

You summarize here which option you are recommending. I often skip this and just highlight the recommended option on the option summary and in the options slide. Let the facts speak for themselves!

Next Steps

In many cases, an options analysis is presented to an executive to either make or ratify the decision. In those settings, the typical follow-up question is "So, now what?" You can handle the question like a champ if you think through it and include this slide in your options analysis.

Ruled Out

I also include a list of any options discussed but ruled out early in the process for one reason or another and therefore not part of the formal analysis. You keep this slide simple and include a table with the ruled-out options along with why each was ruled out.

Solution Options Analysis: What's Next?

Go forth and drive better decisions! I have used this solution options analysis approach on design decisions within the scope of solution architecture and a small consensus-driven decision approach to enterprise-level product decisions made presenting to an executive board. I have even used it to think through a decision myself! It scales up and down with ease.

In more complex options analysis scenarios, I do some detailed work scoring the options against a matrix of features (I will save the "Product Evaluator" for another day). Still, even in those cases, the format discussed here provides a great way to summarize the results for presentation.

As you set off to drive better, fact-based decisions, my final advice is to remember that solution architecture is storytelling, so even the options analysis has to tell the right story. So once you complete your analysis, review your presentation and make sure the story ends at the conclusion you expect. If it doesn't, either the story needs fixing or your conclusion does!