Originally posted on Linkedin
Knowing what needs to be built is the tip of the spear in a transformation program. If your requirements are clear, then everything else is easier. If they’re not, everything suffers.
They’re also typically weighted to junior people in the team. They need to grow a thick skin quickly, asking hundreds of ‘stupid’ questions, reading outdated documentation and observing processes that do not match at all what the manual suggests.
They’re often matched with business stakeholders who are already busy with day jobs, unable to give the time and focus that’s needed. Often they’re the ones jammed in the middle between multiple groups that want different things, but need to agree on a standard approach. Passive aggressive stakeholders who don’t turn up, often contradict themselves and sometimes blatantly say “I don’t agree with this program” is par for the course. Yet our BA’s soldier on.
They interview, workshop, document, diagram, demo, present, test, spreadsheet, data cleanse, iterate and need to learn an entire function, business, sometimes even industry, in a matter of weeks, and get it in a format that business stakeholders can understand, and developers can build on. They know that there is hidden complexity that needs to be understood, or the system won’t function. It starts completely blurry, but with hard work, the requirements emerge.
The industry is shifting from the business analyst to a more co-designed approach, but in my mind there will always be the need for the relentlessly curious, upbeat, thick skinned business analyst who turns up every day and doesn’t rest until they know the business better than their stakeholders.
To all the unsung business analyst heroes I’ve ever had the pleasure to work with, THANK YOU. You make or break an implementation, and every successful implementation has the traces of good business analysis across every function that hits every user every day.