Analysis paralysis and decision avoidance occur all too frequently and commonly in the business and solution analysis and design process. It wastes time and money. Analysis paralysis occurs when you cannot escape the analysis stage – you are always looking for more information and for perfection. Decision avoidance and evasion occurs when there is a decision making request/response loop as there are seemingly endless requests for more information – there are always requests for more details, additional options and more clarifications. There are two possible loops: 1. Analysis Loop – where analysis never finished. Analysis and design do not want to let go – always looking for perfection and want to retain ownership. 2. Decision/Analysis Loop – where decision making is deferred because of requests for more analysis. Fear of decision-making is masked by endless requests for more information and options. You cannot avoid analysis but do not perform analysis is isolation without a business and solution context The Conceptual Solution Architecture framework focusses on the core functional and system components of the solution. This enables effective decision-making on the available options implementation time-frames, implementation approaches and likely budget requirements. Effective analysis and solution design minimise the Solution Space while maximising the size of Requirements Space encompassed within it. You need to measure the progress of analysis and design and decision making to identify when progress is stalling. The IT function needs to be a lens concentrating solution need onto solution options. It needs to successfully mediate between the business as the originator of a solution need and the solution provider, either internal or external or both. The IT function needs to be good at moving from analysis and option identification to an implementation decision quickly and effectively. You need a systematic, structured and measurable approach to decision making. Decision making that follows a systematic approach is be more productive and results in better decisions.

1. Stopping Analysis Paralysis
And Decision Avoidance In
Business Analysis And
Solution Design
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney

2. The enemy of a good plan is the dream of a perfect plan.
It is even better to act quickly and err than to hesitate until the time of
action is past.
Carl von Clausewitz
A good plan violently executed now is better than a perfect plan
executed next week.
George S. Patton
November 1, 2016 2

3. Need For Solution Exists Because …
• I have a problem
• There is an opportunity
• I have received a directive
• I want to be able to do what I am currently unable to do
• I cannot do what I want
• I need to be able to do something
• A solution is a Resolver, a Provider or an Enabler
• An originator will identify the need for a solution
• The IT function must work with the originator to provide a
usable answer to the solution need
November 1, 2016 3

4. Solution Definition Journey Stages
November 1, 2016 4
WHY?
WHAT?
HOW?

5. Why, What And How
• WHY?
− Why is the solution being looked for: a problem, an opportunity, an obligation?
− Why has the situation requiring a solution arisen?
− Why are we here?
− Why do it?
− Why not do it?
• WHAT
− What are the options?
− What can be done?
− What is being looked for?
− What must it do?
• HOW
− How should it be done?
− How should it operate?
− How can it be delivered?
November 1, 2016 5

6. Uncertainty Increases Analysis Paralysis And
Decision Avoidance
November 1, 2016 6
What?
How?
High
Uncertainty
Low
Uncertainty
Low
Uncertainty
High
Uncertainty
Zone Of Greatest
Analysis Paralysis
And Decision
Avoidance

7. Goal Of Analysis And Design Is To Reduce
Uncertainly
• Reduce uncertainty in the What and How
• Reduce number of viable and realistic solution options
November 1, 2016 7

8. Need To Start With The Objective Defined And
Focused On
• The objective is to define and implement a solution that
meets the originator’s requirements
November 1, 2016 8

9. Analysis Paralysis And Decision Avoidance
November 1, 2016 9
Analysis
and Design
Never Escape
Analysis
Stage –
Always
Looking For
More
Information
and
Perfection
Decision
Making
Decision Making
Request/ Response
Loop For More
Information –
Always Looking For
More Details,
Additional Options,
More Clarification
Never Escape
Decision
Stage

10. Characteristics Of Analysis Paralysis And Decision
Avoidance
• Two possible loops:
− Analysis Loop – where analysis
never finished
• Analysis and design do not want to
let go – always looking for
perfection and want to retain
ownership
− Decision/Analysis Loop –
where decision making is
deferred because of requests
for more analysis
• Fear of decision-making is masked
by endless requests for more
information and options
November 1, 2016 10
Analysis
Loop
Decision/
Analysis
Loop

11. Clearing The Analysis Paralysis And Decision
Avoidance Hurdles
November 1, 2016 11
Clear The
Decision
Avoidance
And Evasion
Hurdle And
Avoid Getting
Trapped
Clear The
Analysis And
Design
Paralysis
Hurdle And
Avoid Getting
Trapped
Move To Implementation,
Service Introduction,
Transition To Production
Plateau
Analysis And Design
Can Be Viewed By
Some As A Trough Of
Despair

12. Analysis And Design
• Analysis is more than gathering, cataloguing and managing
requirements
• The objective of analysis is to provide one set of inputs
into solution design options
• Analysis and design are not sequential activities with a
handoff and barrier between each
November 1, 2016 12

13. Too Much Or Too Little Analysis
• What level of risk associated with (apparently) incomplete
analysis can be tolerated?
• Can information gathering/analysis/study go on so long
that the underlying situation has changed?
• How much analysis is too much or too little?
• How many requests for more information and analysis
represent valid concerns rather than decision avoidance?
November 1, 2016 13

14. Requirements Are A Means To An End
• Stop analysis becoming a bottleneck with ever more
detailed requirements being documented without and end
in sight
November 1, 2016 14

15. You Cannot Avoid Analysis
• But do not perform analysis in isolation without a business
and solution context
• Analysis cannot capture the business functional
requirements of solution without a conceptual solution
architecture framework
− This provides a structured approach and background with which
to gather requirements and to assist the business identify what
they are likely to use in and need from the solution in terms of its
overall operation and use
November 1, 2016 15

16. Analysis And Design Can Be Difficult
• Uncertain, undefined or multiple mixed objectives
• Lack of coherence on what is needed among stakeholders and
affected parties
• Unarticulated needs
• Lack of clarity of what is really needed
• Complexity – large number of components, interactions,
connections, processes, stakeholders
• Heterogeneity among stakeholders and affected parties
• Opposition from some stakeholders and affected parties
• Time and cost constraints
• Unpredictability, uncertainty and change in what is being
analysed
November 1, 2016 16

17. Conceptual Solution Architecture Framework
• The CSA focusses on the core functional and system
components of the solution
− The complete solution will consist of much more than this
• This enables effective decision-making on the available
options implementation time-frames, implementation
approaches and likely budget requirements
• It defines functional separation of systems, services and
applications to be implemented or modified
• It implicitly contains possible implementation options that
narrow decision options
• It allows key design questions to be raised and answered
November 1, 2016 17

18. Any Complete Solution Consists of:
• Zero or more of {Changes to Existing Systems}
• + Zero or more of {New Custom Developed Applications}
• + Zero or more of {Information Storage Facilities}
• + Zero or more of {Acquired and Customised Software Products}
• + Zero or more of {System Integrations/Data Transfers/Exchanges}
• + Zero or more of {Changes to Existing Business Processes}
• + Zero or more of {New Business Processes}
• + Zero or more of {Organisational Changes}
• + Zero or more of {Reporting and Analysis Facilities}
• + Zero or more of {Existing Data Conversions/Migrations}
• + Zero or more of {New Data Loads}
• + Zero or more of {Training and Documentation}
• + Zero or more of {Central, Distributed and Communications Infrastructure}
• + Zero or more of {Sets of Installation and Implementation Services}
• + Zero or more of {Cutover/Transfer to Production}
• + Zero or more of {Operational Functions and Processes}
• + Zero or more of {Parallel Runs}
• + Zero or more of {Sets of Maintenance, Service Management and Support Services}
• + Zero or more of {Application Hosting and Management Services}
November 1, 2016 18

19. Scope Of Complete Solution
November 1, 2016 19
Acquired and
Customised Software
ProductsChanges to Existing
Systems
New Custom
Developed
Applications Information Storage
Facilities
System
Integrations/Data
Transfers/Exchanges
Changes to Existing
Business Processes
Organisational
Changes
Existing Data
Conversions/
Migrations
New Data Loads
Training and
Documentation
Central, Distributed
and Communications
Infrastructure
Sets of Installation
and Implementation
Services
Cutover/Transfer to
Production
Operational
Functions and
Processes
Parallel Runs
New Business
Processes
Reporting and
Analysis Facilities
Sets of Maintenance,
Service Management
and Support Services
Application Hosting
and Management
Services

20. Conceptual Solution Architecture
November 1, 2016 20
Functional
Component
Functional
Component
Functional
Component
Functional
Component
Functional
Component
Functional
Component
Actor
Actor
Actor
Actor
Actor

21. Conceptual Solution Architecture
• Define key functional components and actors and their
interactions
− Initial view that can be elaborated and refined
• Key requirements can be identified using this framework
• Solution options – automated, manual, integrated,
multiple point – can be explored
• Recognise areas where decisions are required
November 1, 2016 21

22. Requirements Space And Solution Space
• Minimise Solution Space while maximising size of
Requirements Space encompassed
• You do not deliver requirements
• You deliver solutions that encompass multiple interoperating
elements that enable business processes that allow
requirements to be complied with
• Solution Space maximises the requirements complied with
while minimising its scope and complexity and therefore its
cost, delivery time and risk
• Analysis and design is concerned with finding an optimal
Solution Space
• There may be many Solution Space options – analysis and
design needs to focus on finding the most viable ones quickly
and the deciding on the one(s) to pursue
November 1, 2016 22

23. Requirements Space And Solution Space
November 1, 2016 23
Requirements Space Solution Space

24. Requirements Space And Solution Space
• The selected solution may
not include all the stated
requirements
• Decisions are needed on
what can be included and
what cannot be included
• Delivery can be phased and
prioritised to maintain
solution momentum
November 1, 2016 24
Requirements and Solution

25. Solution
Delivery
November 1, 2016 25
Business
Stakeholders
Solution Architecture
IT Operations
Solution Design Process
Solution Design Process
Initial Concept
Of Need/ Goal/
Objective
Formal
Statement Of
Need/ Goal/
Objective
Stakeholder
Requirements
Collection and
Specification
Solution
Requirements
Collection and
Specification
Solution
Architecture
Design and
Specification
Implementation
Project
Initial
Architecture
Review and
Options
Analysis

26. The Solution Journey Involves Making Decisions
November 1, 2016 26
Decisions Need To Be
Made Along The
Solution Journey …
… To Change
Direction
… To
Cancel
The Solution Design, Development,
Implementation and Operation Journey Is Rarely
Easy
… On
Options and
Choices

27. Maintaining The Solution Delivery Momentum
• The solution journey must always progress
• Progress is achieved through decision making
• A solution journey that is not moving towards a resolution is in
an analysis/decision loop
• How to measure and identify analysis loops and
analysis/decision loops?
• Analysis and design are good and necessary activities
• Beware of false assertions of analysis paralysis where some
want to move straight to implementation without validation
• Too much analysis and design that does not demonstrate
progress to a decision is bad
November 1, 2016 27

28. Measuring Progress And Decision Making
• You need to measure the progress of analysis and design and
decision making to identify when progress is stalling
− What metrics to use
− How to report on them
• Identify lack of solution conceptual architecture options
causing delays in decision making
• When is analysis just refining the detail of a design that can be
done during implementation rather than uncovering necessary
complexity that contributes to solution design
• Need to include a measure of progress along the entire
solution journey as part of any solution delivery reporting
dashboard
November 1, 2016 28

29. Solution Delivery Phase And Deliverables
Project Stages/ Timeline
ProjectActivity/Function
Concept Initiate Plan Design Build Test Deploy
Manage
and
Operate
Project
Management
Business
Function
Business Analysis
Solution
Architecture
Implementation
and Delivery
Test and Quality
Organisation
Readiness
Service
Management
Infrastructure
and
Communications
Time
Business
Functions/
Roles
November 1, 2016 29

30. Solution Delivery Heatmap Progress Measurement
Approach
Solution Delivery Stages/ Timeline
SolutionDeliveryActivity/Function
Concept Initiate Plan Design Build Test Deploy
Manage
and
Operate
Project
Management
Business
Function
Business Analysis
Solution
Architecture
Implementation
and Delivery
Test and Quality
Organisation
Readiness
Service
Management
Infrastructure
and
Communications
Time
Business
Functions/
Roles
November 1, 2016 30
Measure Rate Of
Movement Through
Solution Delivery Stages
And Activities To Identify
Lack Of Progress And
Stalling

31. Decision Scale
November 1, 2016 31
Easy Decisions
• Those that are routine and frequent
• Low cost
• Low impact and few negative and serious consequences
• High level of comfort with decision context and background – comfort zone
• High level of confidence in outcome
Hard Decisions
• Those that are not routine and
infrequent
• High degrees of ambiguity, uncertainty
and risk
• Potentially high cost
• High impact and potentially large
negative and serious consequences
• Low level of comfort with decision
context and background – outside the
comfort zone
• Low level of confidence in outcome

32. Decision Avoidance
• Easy decisions are easy to make and have few negative
consequences
• Hard decisions are not easy and have potentially much
larger negative consequences
• Need to understand the difference between a real hard
decision – to progress or not to progress – and an
apparent hard decision – to delay or look for more options
or information – which just masks a failure to make a
decision
• Decision avoidance and evasion that masquerades as hard
decision making is surprisingly common
November 1, 2016 32

33. IT Needs To Excel At Focussing Business Needs On
To Solutions
November 1, 2016 33
Business Need
Solution
Business Need
Business Need
Solution
Solution

34. IT Lens
• The IT function needs to be a lens concentrating solution
need onto solution options
• The IT function needs to successfully mediate between the
business as the originator of a solution need and the
solution provider, either internal or external or both
• The IT function needs to be good at moving from analysis
and option identification to an implementation decision
quickly and effectively
November 1, 2016 34

35. IT Does Provide Competitive Advantage
• IT does really provide competitive advantages to
organisations
• Business really does need IT to operate and grow
• Business can and does bypass the IT function if it does not
listen to the business and deliver solutions that enable
delivery of business objectives
• The business will look elsewhere for the necessary IT
solutions
• The consequence will be a fragmented and balkanised IT
solution landscape that is costly to operate and support
November 1, 2016 35

36. IT Solution Leadership
• IT needs to be good at solution delivery and provision
along the solution journey from initial need to service
introduction and transfer to production
November 1, 2016 36

37. IT Solution Leadership
• IT needs to provide leadership in decision making
• IT needs to focus business needs on solution options
• Mediate between business and solution provider, either
internal or external
• Lead the business through decision making process
• Make the transition from problem/need to solution
implementation and operation easier
• Engage with the complexities of the problem at an early
stage
November 1, 2016 37

38. Agile, Proto-Typing And Other Approaches
November 1, 2016 38
A So-Called Agile
Approach Can Be Seen As
A Way of Avoiding
Analysis And Design
Stalling By Parachuting
Directly On To The
Implementation Plateau

39. Agile, Proto-Typing And Other Approaches
• Jumping straight to implementation without considering
options may leave necessary ground untraversed
• Maybe consider looking before you leap
• Avoid a premature jump to a solution without
consideration
November 1, 2016 39

40. November 1, 2016 40
Using Agile Approach To Solution Delivery
• All too frequently seen as a panacea to solution delivery
problems
− It is not
− Agile is hard
• Agile has become fashionable without an understanding of the
effort involved
• Agile requires commitment, involvement and can be intense
and demanding
• Agile is suitable for only some components of solution delivery
• If you have current solution delivery problems, agile is probably
not the solution
− You need to fix the underlying organisational issues first

41. Solution Design Option Boundaries
November 1, 2016 41
Enterprise Architecture Defines the
Solution Technical Boundary
Business View
Data View
Technical View
Functional View
Implementation
View
Management
and Operation
View
Solution
Design
Solution
Design
Defines the
Solution
Scope
Boundary

42. Solution Design Factors, Limitations And Boundaries
• Core Constraints – concerned with essential solution
attributes
− Enterprise Architecture
− Solution Architecture Views/Dimensions
− Existing or New System
− Degree of Automation
• Extended Constraints – concerned with solution
implementation and operation
− Resources
− Finance
− Timescale
− Expected Life
November 1, 2016 42

43. Core Solution Design Factors, Limitations And
Boundaries
Degree of Automation of Solution
Solution
Design
Constraints
Enterprise Architecture Constraints
Use
Existing
System or
Create New
System
Range of
Solution
Options
November 1, 2016 43

44. Extended Solution Design Factors, Limitations And
Boundaries
• Other implementation and operation-related constraints
that will affect the solution options:
− Resources and their availability
− Timescale and urgency of solution
− Cost and available finance
− Likely duration of solution
November 1, 2016 44

45. Different Solution Designs And Options Can Comply
With Constraints Differently
November 1, 2016 45

46. Comparison Of Possible Options For One Solution
November 1, 2016 46

47. Creating The Conceptual Solution Architecture And
Solution Options
November 1, 2016 47
Why Is The
Solution being
Looked For ?
What Should The
Solution Do?
How Will The
Solution Do What
Is Needed?
How Will The
Solution Be Used?
What Could Go
Wrong With The
Solution
Could The
Solution Do
Anything Else?
Are There Any
Alternatives Or
Other Options?
Analysis Of Business
Context, Requirements And
Solution Options
Determination
Of Usability And
Utility
Identification Of
Components
And
Implementation
Options And
Choices

48. Approaches To Making Decisions
• You need a systematic, structured and measurable approach to
decision making
• Decision making that follows a systematic approach is be more
productive and results in better decisions
• Unstructured decision making waste time and effort
• Structured approach consists of:
− Appropriate and sufficient problem analysis
− Definition of evaluation factors
− Identification of alternative options and solutions
− Identification and evaluation of likely positive consequences of
solutions
− Identification and evaluation of likely negative consequences of
solutions
November 1, 2016 48

49. Approaches To Making Decisions
• Avoid factors that cause ineffective decision making
− The real decision maker is not known or unavailable
− There are multiple, possibly conflicting, decision makers
− Objectives cannot be plainly identified and clarified
− There are trade-offs to be agreed
− The key uncertainties cannot be understood
− The available and viable options cannot be agreed
− The measures of value cannot be agreed
November 1, 2016 49

50. Summary
• Always capture requirements in the context of a
conceptual solution architecture
• Need an analysis and design and decision-making
processes that focus on delivery
• Need a method for measuring progress through analysis
and design and decision-making
November 1, 2016 50

51. More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney
November 1, 2016 51