Analysis Paralysis

One of the more difficult decisions to make in an IT development project is how much analysis of requirements is required before any actual coding is done.  Actually, I’ll make a minor adjustment to that statement: in a perfect world, knowing how much analysis and discussion of requirements is required is not a completely straightforward decision.  I am deeply suspicious of anyone who resides at either end of the spectrum of this dilemma – all the more so when they prove to be intractable in their views.

Whether there’s an Agile/XP evangelist saying let’s just jump in and start coding without actually analysing what we’re trying to achieve or some hidebound bureaucrat who isn’t happy until everyone is bleeding from the eyes (and probably still wants to keep going even then) – sticking to some orthodoxy no matter what is likely to end badly.  So what does this BA think is the ideal amount of analysis?

You should do as much analysis as is required but no more than that.

That statement isn’t half as glib as it might seem.  The real issue is that “how much analysis is required?” is the wrong question.  The right question is “What are we trying to achieve?”  And just to head off the Agile zealots, I’m not talking about definitively answering “what will the end product be” before starting any coding.  The important thing for the business to know before they start wasting developers’ times is what are the desired outcomes?  Not how it’s going to be done but what the business needs to achieve for the project to be a success.

As a BA, it’s a constant struggle to stop people on the business side from leaping straight to “We should use this software and have this sort of widget and all the buttons should be cornflower blue.”  At the early stages when the scope of a project is being set, the analysis should ideally be limited to “what do we want to achieve and why is it important?”  In almost all cases these conversations can and should be completely technology-neutral so there’s no need to drag developers into endless brain-storming sessions.

When it comes down to it, the non-IT side of a business should almost never consider technology when analysing requirements for IT projects.  That’s the role of the technical team.  Scope-level discussion should almost always steer clear of technical issues (apart from any mandatory compatibility issues) but even documentation of detailed Business Requirements and Functional Specifications can be done without focusing on technical details.  These documents should be telling you exactly what their names suggest: outcomes the business requires and what functions the system will have to perform to deliver on those requirements.  Both of these can be analysed in depth without dictating the technology to be used.

So at the end of the day, the “right” amount of analysis is going to differ from situation to situation.  If you’re following an Agile-type approach with rapid iterations then analysis probably only needs to progress to the scope level.  Define what outcomes you want at the level of “this is in – this is out” and go for it.  But be very wary of anyone telling you any up-front analysis or design is too much.  How can you possibly know when you have succeeded if you have nothing to measure your output against?

While I lean towards much more analysis that the average Agile devotee would advocate, I’d run a mile from anyone who wants to saddle me with crippling never-ending design and analysis processes.  Nothing will crush the life out of a worker like a death march with no end in sight. 

If you can’t define what it is you actually want to achieve then you need more analysis.  If you are in the 10th hour of meetings to discuss what particular shade of green will most inspire customers without having developed a functional prototype to see if the solution is even viable then you are wasting valuable time and brain power with analysis paralysis. 

Do what is required.  Nothing more.  Nothing less.