Apr
13
The BA Role in Organizations
April 13, 2006 |
Over on BPMS Watch, Bruce Silver quotes a friend of his as saying:
I’d quibble only about the role defs for “business analyst” (a common misnomer in vogue in IT today that should be titled “requirements analyst” since they don’t really analyze the business or assist the business in developing strategies, workplace design, etc.) and “process analyst” (being a technically oriented position - when there are already a bunch of process analysts out here and our primary role is doing all that stuff that the business analyst doesn’t do… more involved with business consulting/planning/operations design, etc.).
And, lest you shoot back something along the lines of “well, that’s just your opinion”, I submit to you that the IIBA (International Institute of Business Analysts) defines their role pretty much exactly as we do here at my workplace and everywhere else in North America that I have visited or otherwise know about.
I was there when the IIBA definition was developed, and that’s not quite right.
The IIBA definition of the business analyst job role was designed, in part, to support the certification process. That meant that we had to define it in such a way as to say what was unique to that job role in the organizations our members belong to. The definition isn’t meant to state that a BA only does requirements definition, but rather that a person who does not define requirements for the solution to a business problem is not a business analyst.
Through BoK 2.0, it’s likely that we’ll focus on problems that have an IT component. However, the long term goal of the IIBA is to make the certification useful for non-IT solutions as well. We also need to lay the groundwork to improve the practice of verifying that IT and other solutions actually produce the results that they’re supposed to.
It’s true that many BAs don’t do the work to validate that the systems that get built for a business actually do add business value, although the results of our latest task survey suggest that a substantial minority are at least putting together business cases and developing metrics to track the return on investment. In the next few years, I hope that becomes a majority.
Comments
3 Comments so far
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats
Thanks for the insight into the IIBA’s definition.
I have to say that I think your focus on what isn’t a BA doesn’t help the debate on what the role is very much.
I also think it’s disappointing that the IIBA is going to focus on IT business analysts at the expense of others. The perceived differences between “technical” business analysts and “businss” business analysts seems to be where most of the angst is at the moment.
Craig,
I’m not sure what precisely you’re looking for. I think the definition is in fact very helpful. We needed something that would help us look at marginal cases, and functions that are often assigned to BAs, and determine which of them we would seek to address.
In that regard it’s been an extremely useful definition.
In terms of how the BA fits into organizations, the IIBA has done surveys of hundreds of BAs and we used the results of those surveys as a major input into our work. I’m quite comfortable with asserting that the BABOK (especially in version 2.0) reflects the spectrum of work performed by BAs in organizations worldwide.
Based in part of that survey, we concluded that the overwhelming majority of BAs work solely in a project environment and that those that did not (e.g. business architects) represented a different group of people who needed to be addressed separately. On the other hand, the distinction between “business” and “technical” BAs is only significant in very large organizations, statistically speaking. The BABOK will, as a result, be focused on the role of business analysis within a project and assumes that BAs should understand the processes, policies and information systems that the organization is trying to implement.
Gentlemen, I believe the true measure of the sucess of a BA is Business Analyst is whether a project output adds value to business needs. If you want to read more, see my blog - will the real BA please stand up?
http://bacorner.com/?p=9#more-9