Sometimes, when you or your team are trying to solve a problem, you find that you’re going round in circles and getting nowhere. There is always a reason why every solution is wrong, or you’re worried that if you start working on one solution it’ll turn out to be a dead end. You get into a cycle of thinking more and more about the details, where everything could go wrong, and then you realize you’re overthinking the whole thing. You ask for more information, and if and when it arrives then it too gets analyzed and you find you’re no closer to an answer than before. The whole process just goes on and on, with no apparent end in sight, and no actual results to show for it.
This is “Analysis Paralysis”.
It’s been rightly described as an “anti-pattern”, i.e. a thing you really don’t want to happen, but it happens everywhere from committees and councils, management teams and software and hardware development teams.
So what can you do when it happens to you? I have three approaches that I usually take:
1. Approach The Situation Pragmatically
You’re not producing anything, but you’re still being paid so you’re already costing your employer money.
Starting with that, it can’t get much worse unless the results you produce are REALLY bad. As my ‘A’-level Applied Maths teacher, Mr Ellis, used to say about solving the seemingly insurmountable problems in the course: “If you don’t know where to start, just start!”. So just start on something; if you’re not on the right path, you’ll find out pretty quickly and then you can take a different approach. You’re much less likely to produce really bad results if you constantly check that you’re headed towards a solution to the problem.
2. Limit The Time You Spend On Investigation
Try setting aside a block of time to investigate possible solutions. Don’t just discuss them or just think about them, actually work on some proofs of concept. In agile software development, this is called a “spike”: a time-boxed story, or task, which allows more investigation to be done and potential solutions to be explored. It’s similar to the previous approach (1), but is limited in time, typically to a few days. At the end of the spike you would expect to have a firm idea of the approach you will take to solve the problem. Then you can start to implement that solution.
3. Take a Step Back
Overthinking the problem isn’t helping, so take a break. Everyone has had ideas just pop up in their mind while they’re wandering around a store, taking a shower, watching television, or something else. This happens when you least expect it, so why not try to encourage it? Take a break - grab a coffee, take a walk around the building, go home early. Once your mind is away from the problem, you may well come up with a great solution. One of my Computer Science lecturers used to recommend the following method of debugging software: “Take a printout to the pub, read it, drink a couple of pints of Dogbolter*, and all will become clear”. It works for Analysis Paralysis too.
Hopefully at least one of these approaches will work for you when Analysis Paralysis strikes. Often just starting something, not necessarily the thing that turns into the actual solution, will help and then everything will start moving along. Remember that if you stick to proof-of-concepts to start with, or at least small changes, you shouldn’t end up doing anything drastic or irreversible, and you’ll manage to start producing a solution.
* - At the time, Dogbolter was an almost legendary dark beer brewed by the Firkin pubs in London, rumoured to have such a high alcohol content that landlords refused to sell more than half a pint (10 fl oz) at a time. In reality it was just 6% ABV, but still a very nice beer.
