Technical Options Appraisal – Pre-requisites and structure

Technical Options Appraisal – Pre-requisites and structure

I have been recently involved in a Technical Options Appraisal (TOA) activity and this blog is about the perquisites, structure and scope of the appraisal. This blog should help a reader who is planning to undertake an options appraisal and leverage for an existing structure.

I have been in technology industry for more than 15 years and in an architect (some form of it) role for last 7 years. I have found that any technology choices you make, you always have to justify it over and over again. Technical Options Appraisal is a good activity to justify the technology decision and the rationale behind it. But the challenge is that to have a good TOA, one would need time and understand the level of depth and audience it is addressing.

The challenge is to start with clear objectives and scope and then keep within those during the duration of the appraisal.

In another blog () I cover lessons learned from my experience around technical options appraisal and how to get best out of it.

Before kicking off.

Technical Options Appraisal is an activity to evaluate technical solution options for a problem domain. This can be an extremely challenging effort if not started well with clear definition and scope. Below are high level pre-requisites before you start any appraisal.

1.     Have a fixed business domain for appraisal - If the domain is moving then the appraisal cannot hold its ground and the researcher is always fighting moving targets. Understanding of scope is key and any changes to it should be controlled through change control.

2.     Target model - Is the solution going to be used as a commodity service or a solution to solve a single problem. This has a massive impact on the options chosen.

3.     Organisational strategy for a solution - Organisations usually have preference toward a certain direction for procurement and Solution architecture. This usually come to question of “Re-use before Buy before Build”.

4.     Approach for Technical Options Appraisal -  The approach needs to be agreed beforehand for conducting a TOA. For example, approach of getting long-list of options to short-list with evaluation criterion, input from partner stakeholders, etc.

5.     Assessment criteria – Assessment criteria is key for appraisal as it will define the parameters against which the options are being evaluated. Each criterion is evaluated for business domain and standards in which the organisation operates. This covers both functional and non-functional criteria and depending on the problem domain and stake holder it covers additional information for business continuity.

6.     Time box – TOA activities can take a lot of time, especially if interaction with various vendors are required. Time box directs the amount of work required as well as amount of information presented in the TOA.

7.     Key stakeholder map – This map highlights who is involved as stakeholder for the solutions proposed and signoff as business and technical authority.

8.     Level of depth required for information gathering – This is key to successfully complete the TOA. The depth of level should be consistent across all the evaluation criteria and present a complete story.

All the above need to be agreed with key stakeholder before meaning full progress can be made on the TOA.

Structure of Option Appraisal.

The structure of options appraisal can differ based on audience and the time available to conduct the appraisal. This can be from an informal email (not recommended) to a document which covers details around option appraisal.

Section	Description
Purpose	This section explains the purpose of the document, time frame it is conducted and any limitation the document operated under (e.g. dependence on previous research or dependence on exiting solution for integration). This also shows the approach of the document i.e. Risk Based approach and/or weighted approach.
Executive Summary	This is the section which will be most read. This section contains high-level business domain, approach for TOA, Option under evaluation and summaries of assessment with recommendation.
Target Architecture	This section contains the target architecture under which the options will operate. The target architecture will help in deriving the assessment criteria which will be explained in this section. Some views like Capability View, Application Component view and Information Flow view are helpful in providing a user with right level of context.
Approach	This section contains details around approach on options appraisal. It explains how the research is carried out and how the information is gathered.
Candidate Options List	This section contains the solution option list with explanation and assumptions for each solution. This also contains information on solution architecture and high-level costing (if required).
Appraisal	This is core part of the document where appraisal of each option proposed is done against an evaluation criteria. The appraisal criteria needs to be agreed before the appraisal takes place, each criteria has a weighting attached and at the end option evaluated based on fitness. More details on the content of the Appraisal section is below.
Summary	This section almost mimics Executive Summary section where summary of the appraisal is presented.
Recommendation	This section contains the recommendation of an option(s) based on the findings from the document.

Appraisal Section in detail.

The appraisal section is dependent on the audience of the TOA as well as the time provided for the appraisal. Below is not the finite list of assessment criteria and should be adjusted to audience and depth of information to be presented.

Criteria	Description
Functional Fitness	This section shows functional fitness of the options based on user needs analysis.
Non-Functional Fitness	This section shows functional fitness of the options based on non-functional requirement.
Entry & Exit	The activities required to move to and exit from the solution (on and offboarding).
Sustainability	The capability and capacity of the team required to support the solution. This includes transition to, operation of and transition from the solution. This also reviews the solution from an environmental sustainability perspective.
Total Cost of Ownership	Overall cost of the solution. The cost also includes cost outside technical costs.
Strategic Alignment	Strategic alignment with published strategies for the organisation
Intellectual Property	Considers if there is an impact on being able to reuse any developed elements widely. As well as associated costs for reuse or barriers based on licensing.
Procurement Rules	Evaluation of potential procurement routes to deliver the options.
Timescales	Evaluation of the timescale required for each option and in particular how it compares with known available timescales.
Dependencies	The dependencies for each option in order to identify any particular risks an option has in this area.
Training	The training required to deliver or support each option in order to identify any particular risks an option has in this area.
Communications	Comparison of the communication with stakeholder requirements for each option in order to identify any particular risks an option has in this area.
Warranty & Indemnity	Warranty and indemnity implications for each option.  This is in order to identity any risks associate with an option.
Service & Support	Considers how each option will be supported as well as what management information must be reported.
Compliance	Evaluates the options for compliance against known legislation, regulations and organisational standards.
Assurance	Identifies how each option will be assured within the prevailing governance processes.
Risks	Risks of the options, based on the information above.  Expectation is that this will be a long list covering all the options.

Closing the Appraisal.

To close the appraisal, it is paramount that information is distributed to key stakeholder with the risk associated and the recommendations. A timeframe is created to make a decision so that this doesn’t go into a spiral of question/answer session.

The primary objective for a technical options appraisal is to make an informed and transparent decision about selection of a technical solution. This document should provide the relevant information to make that decision and support future queries.