Is the role of business analyst an IT role, a business role, or both? How can the BA role be used to the greatest benefit of the organization?
This post is a follow-on to one in which I entertained the question of whether a Business Analyst’s (BA) requirements work is fairly labeled “requirements engineering”. I tend to favor the notion that it’s not. And not because I am a stickler for semantics, but because I would like to see the BA role become increasingly involved in business case development, and less exclusively as an information technology (IT) role.
Business Analyst as an IT Role
Today, the BA role seems to be joined at the hip with IT. My notion of why this is, is that IT sees the most immediate and conspicuous value-add. IT really feels the pain when business need is not communicated clearly. Numerous studies show that requirement inaccuracies that are corrected early on in the project can cost a mere fraction of what it costs in time and budget to correct them later [1, 2, 3].
Sure, business folk hate the bugs, delays and budget bumps, but they typically aren’t missing their tee times while IT delivery folks crank out 16 hour days and weekends to make up for misunderstanding what the business didn’t articulate very clearly in the first place. Business analysts provide IT with a clearer understanding of what the business needs, and can alleviate a great deal of that pain.
Through thorough elicitation and solid documentation, good BA can help the business trust their “techie” siblings to understand the business need and implement the right use of technology to meet it.
Business Analyst as a Business Role
What happens when business folks get a bit too comfortable in their solutions hats? The most trying projects are those where the business plays the role of solutions architect, and the BA plays the role of “waiter”.
Too often IT is forced to implement a predetermined technology solution that is just not the best choice. Despite the best of intentions, business folks have a tendency to mistake symptoms for causes, and to want to prescribe solutions instead of simply stating needs and objectives. These projects can be the most disastrous.
In cases like this, the BA role is virtually reduced to that of a waiter sent to take orders and carry them back to the IT kitchen. This, aside from being frustrating, nullifies much of the value that a BA can provide to the business. What the business may not realize is that they don’t need a waiter; they need a trusted advisor.
Business stakeholders sometimes fail to realize (in part due to the BA or Project Management Organization’s failure to articulate) that the great value of a BA is not just in the ability to crank out documents translating business-speak to tech-speak, but to help business stakeholders through the processes of identifying and prioritizing true (not necessarily perceived) business need, identifying SMART objectives for a solution, and helping them arrive at the right solution – which, notably, may or may not be IT-related.
I think one of our biggest sells as business analysts is to the business ownership. The higher up the corporate food-chain a BA can find a listening ear, the better. BA’s should primarily be experts on the business environment, and secondarily the IT environment (which is still very important inasmuch as it is a vehicle through which many of today’s business process solutions are addressed). This is not to say that the BA “knows best”, but that the BA will ensure that the proper processes for discovery, prioritization, and decision-making are followed, giving the business the best possible opportunity to succeed.
What does the future hold?
Will BA’s eventually find themselves residents of business units to perform an advisory role? Will they, as has the Project Management Organization, become an entity unto themselves? What will happen to the perception of the role at large? Will we see a divergence in the Systems Analyst and Business Analyst roles from the current blur of business/functional/systems/requirements/etc analyst roles?
Frankly, I don’t know what exactly will become of the role with which we are familiar today. I do feel that the role will continue to require business acumen and technical literacy, and I know that every company will continue innovate and build on past lessons to address their needs for the role as they see fit. In many smaller budget operations we’ll likely continue to see the systems analyst/business analyst hybrid. In other scenarios we’ll see the breakout.
As I indicated above, I think that organizations will realize the most value from the business analyst as he/she is included earlier and earlier in the business decision making process, and becomes more of a fixture within the business. Whatever the case, though, I trust that the market will properly guide the evolution of the business analyst role.
In the meantime, it’s an exciting time to be a business analyst and to participate in defining the role and making it what it has the potential to be. Here’s to enjoying the ride!
[1] “Building a Better Bug Trap”, The Economist, June 19, 2003
http://www.economist.com/science/tq/displayStory.cfm?Story_id=1841081
[2] Barry Boehm, Software Engineering Economics, Prentice-Hall, 1981
[3] Grady, Robert B. 1999. “An Economic Release Decision Model: Insights into Software Project Management.” In Proceedings of the Applications of Software Measurement Conference, 227–239. Orange Park, FL: Software Quality Engineering.
You have great points to reflect upon in this article. Recently, I have been doing a lot of thinking on the role of the business analyst.
This will probably always be a murky subject but I’m beginning to see some very distinct variations:
* Business Analyst – business focused
(this role/title currently exists in many organizations where it has nothing to do with technology – but simply performs analysis of the business to improve the processes and help the business make more money and reduce cost).
* IT Business Analyst – bridge between business & IT
(this role is more of the BA that helps the business solve problems using technology – identify and document the requirements for an information system)
* Systems Analyst – mostly IT/solution centric
(this is the analyst which, once requirements are Cleary defined, creates a functional solution by working with the IT Architect and with the technical team).
Of course – the reality is that most organizations just give the BA any title they can come up with in a jiffy while the actual expectations can indeed very from business only to very technical.
Any more thoughts?
– Adrian
Jonathan,
First of all, you have raised an issue that probably is the most steaming in the BA community. What are the BAs and where do they add value.
I had written on the same topic a few months back and that article can be found at:
http://bizvalu.blogspot.com/2007/03/glorified-secretary-is-that-what-ba-is.html
There’s a link to a paper that Kathleen Hass wrote, which I think is a must-read for every wannabe BA.
A good website though.
Rajeev
Thanks for stopping by, and for your comments, Adrian and Rajeev. It’s true that there are a lot of notions of what the BA role is now, and what it will become over time.
One of the things I enjoy about being a BA is that there is often flexibility to mold the role into what it needs to be in a particular environment.
I really think versatility is an important attribute for a successful BA in that in some places the role will emphasize technical know-how, in others project management skills will be at the forefront. To be as marketable as possible, we need to be able to apply core BA skills and concepts while adapting to the different, particular needs of a given business/technical environment.
I’ll definitely take a look at your article, Rajeev.