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.
