Managing Analysis Paralysis

What is Analysis Paralysis?

Analysis Paralysis is based on the premise that by delaying decisions or committing to a particular direction, there's more time to gather new information, conduct analysis and present recommendations to the business. This premise only holds true for a while though. At some point, the law of diminishing returns sets in – the extra information collected and the extra time devoted to analysis no longer add any significant value to the project.

The Analysis Paralysis phenomenon is commonly associated with the waterfall methodology. It happens when an analyst decomposes the problem domain into its constituent parts and is uncertain of when and where exactly to stop analysis. During this state of paralysis, the analyst keeps going at the issue without making any headway. Instead of decomposing the situation until the problem is fully understood, the analyst focuses excessively on achieving a state of perfection and completeness, at the risk of exceeding the project deadline and turning in deliverables that are either unnecessarily detailed or too difficult for stakeholders to understand.

How do you know when analysis is enough?

It is difficult to judge when you've done enough analysis. The truth is that you’ll never have “enough” requirements; there will always be one tiny detail you forgot to include or didn’t think was necessary. Once you get past the fallacy that requirements can be complete, you can then get into the zone of focusing on the objectives of the project.

Analysis Paralysis is based on the underlying fallacies of the Waterfall Methodology and happens easily when:

• There is information overload. The analyst is bombarded with all sorts of information from numerous sources and spends an excessive amount of time making sense of it all.
• Excessive focus is placed on completing analysis before design and coding begin.
• The analyst attempts to achieve perfection and completeness of the analysis phase.
• The goals of the analysis phase are not clearly defined and the expectations surrounding the deliverables are fuzzy.
• There is inadequate planning and monitoring of the analysis phase.
• Design and implementation issues are introduced into the analysis phase.
• The analyst is in a new domain or a new environment and still trying to figure out "all there is to know" about it before making a decision.
• No time frame has been defined for the analysis phase.

Barbara Carkenord in her book, 7 Steps to Mastering Business Analysis, equates Analysis Paralysis to an infinite programming loop and identifies 3 common causes:

1. Setting out with an answer to a problem and then finding out based on your research, that your answer is wrong. To address this, you look keep looking for more evidence to either support your original theory or more information to propose a new theory.

2. You have come up with a recommendation you don't expect others will like. Consequently, you keep searching for more evidence necessary to back up your proposition for when you meet with them.

3. A lack of confidence in your work.

Analysis Paralysis results in a prolonged analysis phase where the cost of analysis exceeds the budget and the deadline. It may also result in the creation of overly complicated analysis models that stakeholders cannot relate to and an excessive revision of analysis models.

Symptoms of Analysis Paralysis

• You have an excessive urge to continue gathering information for more analysis. You keep thinking there's more information “out there” and that you need it to move ahead.
• You can’t decide how many models or techniques will suffice and when you eventually do, you’re not sure what level of detail is appropriate.
• You take a significant amount of time to make decisions, if at all.
• You indulge in repetitive tasks. You keep checking and re-checking what you’ve already checked and researching what you’ve already researched.
• You focus excessively on complex scenarios or exceptions that do not happen frequently. Unravelling that complexity takes most of your time.

Preventing Analysis Paralysis

To avoid this situation, an incremental development or agile approach should be adopted, in which the details of the problem and solution are learned during the course of developing the software. This negates the need to analyze “everything” in advance.

Stakeholders should be involved in the analysis phase. This will ensure that the analyst focuses on the creation of models that are comprehensive and easy for stakeholders to understand. These models should be validated with stakeholders as often as necessary.

In situations where the incremental approach to software development cannot be adopted, there's definitely some value in planning the analysis phase, defining the objectives of the phase and identifying what level of detail is suitable for the project before analysis begins.

Defining the scope of the project can also help in ensuring that the analyst remains on track throughout the analysis phase. If you are analyzing a situation and find yourself going round and round in circles with no clear way out, take a step back, remind yourself of the objectives of the project and ask yourself whether those objectives can be met with the set of requirements you have.

Define your goals and deliverables before starting the analysis phase and the time it will take to get the task done.

Define the success criteria for completing the analysis phase to ensure that the right results are achieved within the deadline.

Curing Analysis Paralysis

Once you notice you’re in a loop, walk away. Discuss it with someone or take a coffee break from the mental hassle. When you come back, you’ll see things differently. Barbara sums it up nicely by stating, “Step away from the details, change your perspective and you’ll see things differently.”

Analysis paralysis can have a detrimental effect on the success of your project if left to fester. Knowing the signs ahead of time will help you combat it if and when it happens.

View a summary of the techniques for managing Analysis Paralysis:

Analysis paralysis from Business Analyst Learnings