The Traditional Business Analyst

For many years the traditional Business Analyst was all there was.

I was one. 

Turning vague business aspirations into detailed paragraphs of text inside a structured document of pre-determined sections (functional requirements, non-functional requirements...) is time consuming work and progress is easy to measure. 

Easy that is until all the Stakeholders are required to "sign off" on what has become a formidable document.

How did all those conversations about the new system become this legal contract?

These days its very rare for all the Stakeholders to give the document the necessary attention to understand the detail so they can all form an accurate vision of how the new system will operate.

And its very rare for the system builders, working from those signed off requirements, to deliver a system that operates exactly how each Stakeholder visualised it would.

But if you can guarantee these two rare outcomes then the choice of a traditional Business Analyst was a good one.

But only if: in the time it took to write the requirements, go out to tender for the build, select the technology and system integrator, build the system, test the system, train the users and go live, in the time it took to do all that,  nothing outside of the project changed.  For example, the business operations did not change or the vision that each business manager had for the new system did not change, or the business managers themselves did not change.

So, before you hire a traditional Business Analyst, to quote Clint Eastwood, "are you feeling lucky" ?

Not many people feel that lucky, which is why there is more demand for the Agile Business Analyst.