businessguys.jpgIs 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.