I noticed a while ago that if you go to the International Institute of Business Analysis web page, click on “About”, and then go to What is a Business Analyst? you get a blank page.Okay, so you if then actually click on the “What is a business Analyst” on the blank page, you then find out:
A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.
I think if you boil that down to it’s essence you get a good starting point, but it doesn’t really get to the core value. “enable the organization to achieve its goals” is the core value proposition in that definition, but that’s every employee’s goal, so it doesn’t seem that interesting. So I’m setting that one aside and making my own (it wouldn’t be deconstructing the role if I didn’t start with an alternate position).
A business analyst facilitates turning ideas into working software, and evaluates the success or failure of that software against the business goals.
You could tweak the “working software” part depending on exactly what sort of business the BA was working in, but that’s the one that’s right for us (we build the customer-facing website for a financial institution). It’s a wide open definition, because I see the BA role as the glue that brings teams and ideas together. Modern software development teams should understand the business, the domain, the problems, and should be perfectly capable of sitting next to an actual business person to define requirements or stories. But in a large organization, just finding and keeping track of the real business owners who deeply understand the business model can be a full time job.
So my working theory is that the modern BA is a coach, relationship builder, secretary, gopher, project manager, etc.. It’s a broad skill set, and one that’s challenging to find or develop in people. The other option is to retreat into documents. Talk to the business people, turn what they say into written requirements, and hand them over to developers. I think that’s not the way to go. The BA role sits in what I think is the best place to manage the end to end life-cycle of a system.
May 15, 2008 8:09 am at 8:09 am
Hey Rob – I agree with your analysis! I’ve BA’d for 15 years now, and my best roles have been where the BA is embraced as an end-to-end lifecycle resource starting pre-project with the business case and continuing all through right to the floorwalking support for the users following implementation and into the project closedown reviews/lessons learned – with all the thorny design and technical bits in between! The worst experiences have been where the BA is treated as just a step in the lifecycle whereby documentation is written then thrown over the wall to the developers to work out what’s REALLY needed – what a waste! Good luck in your new role