Avoiding Analysis Paralysis

As practitioners of business analysis, we have a wide range of tools at our disposal.

A quick internet search will uncover hundreds of tools and techniques that we can use to understand our organization’s current situation, diagnose any problems, search for opportunities, understand organizational and stakeholder needs and help to achieve the outcomes that our stakeholders are aiming for. Some of these tools are very lightweight, others are far more detailed and structured. Our organizations might mandate certain approaches or methodologies that suggest or imply certain techniques are used in a certain order, but it is still for us as practitioners to choose the right tool for the context we find ourselves in.

With so many techniques at our disposal it is very easy to find ourselves like the metaphorical ‘kid in a candy store’, there is always more analysis that could be done! It is always possible to draw another model, or to refine an existing model. Or to polish an existing document or think of another exceptional scenario that we should plan for. I know I am certainly ‘guilty’ of zooming in to a diagram time and time again to straighten every line and align every single box. Perhaps this is valuable in some contexts, but in many this really is overkill.

This is a difficult balance that many of us face as analysts. It seems that we are inherently ‘wired’ to embrace the detail. To polish further, to ask ‘what if…’ and ‘what could go wrong?’. Yet there is a law of diminishing returns. Doing any appropriate analysis well will de-risk a project. Doing more analysis will likely de-risk it further, but eventually we get into ‘analysis paralysis’. The additional effort required to reduce risk is so great we actually create more risk by causing unnecessary delays (which delays any potential benefit and risks our competitors overtaking us). Ever had stakeholders express skepticism about business analysis because it will ‘slow things down’? Perhaps they’ve experienced ‘analysis paralysis’ in the past…

Focusing on what stakeholders value

In order to avoid this pattern occurring, it’s crucial that we spend time truly understanding the outcomes that our organization and its stakeholders value the most. This includes understanding the type of change being proposed and the amount of risk that they are prepared to take. If we’re making a small, low-risk, predictable change to a single process, the best approach might well be to do some quick impact assessment and providing the business accepts the risk, then just do it. Quickly defining and implementing the change in a controlled way will be our best way of learning and understanding how customers react to it. If the project involves safety-critical changes to a manufacturing process then more detailed analysis is likely to be appropriate.

A key point here is that it is absolutely crucial that we spend time not just talking requirements but also talking outcomes and risk appetite. After all, it’s crucial that we remember that stakeholders don’t particularly want our requirements artefacts. They don’t want story cards or well written entries on a requirements management system. They want delivered, valuable change… and the approach that we take should navigate them towards this. Carrying out just enough analysis at the right time is crucial. However, this is easier said than done!

It’s all about context

The analysis approach that we take and the tools that we use will affect the level of project risk. What is appropriate depends a lot on the organizational context. As practitioners we need to ‘own’ these decisions. It is easy to assume that ‘we’re following xyz methodology therefore we must use << a particular technique>> and we must do << a particular set of activities >>’. Yet in the vast majority of cases, these methodologies provide a guide, a ‘backbone’ on which we can add to (and subtract from) depending on the particular circumstances. Considering the two outcomes below, I’m fairly sure a sponsor would value outcome X over outcome Y:

Of course, these are not mutually exclusive outcomes and I am not arguing against structured approaches. However, we should use structure deliberately and when it makes sense. In complex and complicated environments there is no ‘one size fits all’ approach. Along with our project colleagues, we need to be prepared to adapt, learn, and have a laser-like focus on the outcomes that our stakeholders want.