Stopping Analysis Paralysis And Decision Avoidance In Business Analysis And Solution Design
8 likes3,980 views
The document discusses overcoming analysis paralysis and decision avoidance in business analysis and solution design, emphasizing the importance of moving from analysis to implementation effectively. It identifies key reasons for needing solutions and outlines a structured approach to decision-making and solution delivery, highlighting the need to reduce uncertainty and focus on stakeholder requirements. The author advocates for utilizing a conceptual solution architecture as a framework to guide analysis and design processes, ensuring that business needs are met through structured decision-making and effective communication between stakeholders.
Stopping Analysis Paralysis And Decision Avoidance In Business Analysis And Solution Design
- 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