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.
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.
The table of contents for my approach looks like this. In the sections below, I will dig into each.
|Title||You don't expect me to explain a title, do you?||Required|
|Introduction||Provides background, scope, and objective details.||Required|
|Context||Additional information needed to make a decision - could be a process diagram, architecture view, or a list of features.||Optional|
|Options Summary||A dashboard of the options considered.||Required|
|Commonalities||A summary of the aspects of the options that are common.||Required|
|Option Analysis||One slide per option considered, providing the benefits, risks, and impacts for each.||Required|
|Recommendation||A summary of the recommendation, although the recommendation can also be indicated on the options slides!||Optional|
|Next Steps||Pretty self-explanatory: the steps to complete the decision or what happens next once the decision is made.||Optional|
|Ruled Out||Detailed about any options that were ruled out before the options analysis even began!||Optional|
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:
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:
I include three important pieces of information in my introduction:
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.
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:
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.
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:
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:
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.
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!
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.
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.
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!