Before I attempt to answer this question, let me to provide you with some background on how my career as a BA developed.

I, like many Business Analysts, started my BA life having heard of the title 'Business Analyst', but not really knowing what it was about. Did I need to be computer literate? I certainly wasn't the go-to person to fix anyone's computer in my teen years (when personal computers were still somewhat of a luxury to own at home), that's for sure. Having completed high school, gained a business degree and worked in operational roles in funds management for several years, the prospect of a move into the world of projects as a BA seemed a little daunting. However, I had a hunch that the more I learnt about it the more I would like it, so, riding a wave of Y2K hype, I decided that it was the thing to do and took a leap of faith.

From Writing Requirements as a Junior BA...

In my first few years as a Junior BA, I spent most of the time writing business, functional and non-functional requirement definitions, as well as doing a lot of testing, including UAT – typically on a waterfall style project (agile was not yet king). The role seemed to be very 'system' centric. It was a kind of hangover from the 1960's and 70's, and developed from a gap where the developer in an organisation would largely dictate what changes were to be made in a business. At parties, if anyone asked me what a business analyst did, they would invariably follow the question with 'do you analyse businesses?', to which I would answer 'no' and then give a rambling explanation that my job involved changing systems or something like that. I was never able to really articulate what I did. Their eyes would glaze over.

In fact, not only was there a perception that it was system centric but also that it was the 'right-hand-man-to-the-Project-Manager' type role. In my world, back then, the PM did everything that related to project planning, estimating (with my input), change management, project communications and, of course, the Business Case. It was the holy grail of project artefacts. Something quite scary in its enormity and complexity. It was a bit of a mystery and it had immense power.  Hmmm, maybe one day I'd be a project manager and work on a business case. After all, it was the next logical step, right?

...to Taking a Holistic View and Solving Business Problems 

By 2010, consulting assignments in a wide range of industries, experience of working on many types of projects - both small and large - and involvement in capability uplift gigs gave me the confidence to walk into any environment in any industry and expect to get to the root cause of the problem at hand - and come up with a solution. Not only had I developed, but the business analysis industry had also developed. Suddenly, the role was not only about finding a potential system solution – but a business solution. It took a few years to break down old perceptions about the role, and realise that yes, a business analyst solved a business problem. It was finally understood, quite widely, that the solution may very well involve changing IT systems but could just as likely involve changing processes, and people's roles – right across an organisation. So, the scope of the Business Analyst's role was somewhat more holistic, or even strategic. Surely changing a process would change a system, just like a change in strategy would necessitate a change in either or both processes, roles and systems.

By this time, too most organisations found that their bottom line was being squeezed and of course the advent of agile methodologies drove the desire to do projects faster, possibly with less resources and therefore cheaper. Wanting more for less had become the norm. Those at the senior end of Business Analysis like myself were finding themselves looking at new position descriptions, or statements of work, reading 'be responsible for the Business Case', or even 'develop the Operating Model'. There had been a shift; the competencies that were once entrenched in the Project Manager's role were now slowly and surely transitioning to the business analyst's role. Just look at other dedicated project roles in the industry – Communication Managers, Change Managers, Implementation Managers – all once the domain of the Project Manager.

Embracing the New Strategic Role of the Business Analyst

Given the evolution of the business analyst into a more strategic role with many competencies and skill sets required (in particular the ability to think holistically about an organisation and how it is supported) wouldn't it makes sense to have the business analyst author this document, and therefore be responsible for it? If we think about the typical content of a business case, with options being a key element, a BA, probably working at a senior level, would be able to use their comprehensive skill-set to generate, shortlist and develop the options, assess the business, technical and financial feasibility, and work with stakeholders to negotiate and validate the business case.

The Project Sponsor has always had the complete authority for the business case and can either proceed or derail as new information comes to light at each decision gate of a project, but it now appears that authoring and being responsible for business cases (as opposed to just being an informant) is very much the domain of the business analyst. BAs always had the competencies to do it. It was just a matter of time before the old notions of what the business analyst actually does, and what they can actually do, was finally broken.

So, when approached at a party and asked what I do for a living, I now in fact do answer: 'Yes, I analyse businesses!'

Are you interested in updating your BA toolkit or training for a professional certification? Check out AssistKD's wide choice of business analysis courses.