home
Home » Requirements Management

What is a Business Analyst?

Submitted by alsant1 on Tue, 2007-07-03 09:59.

by Al Santucci, Holly James and Debbie Gencarelli

The Search for a Business Analyst
Thoughts from a Recruiting Manager

The Casey Group is a professional services firm specializing in custom software development and outsourcing. Our search for Business Analysts led us to the International Institute of Business Analysis and, subsequently, to the Requirements Networking Group. What we discovered was that, while the Business Analyst function has matured over the years into a specialty discipline, it still means different things to different people, employers and practitioners alike. From the standpoint of a staffing manager for a professional services firm, this is how we see it.

What is a Business Analyst?

This proved to be a more difficult question than we thought it would be. And the answer, as for so many things, is “…it depends.” In our attempt to fully define the requirements of the position in order to locate the most qualified individuals, we spoke to hiring managers, Project Managers and Technical Architects. The problem we ran into was that there is not just one concept of a Business Analyst. And even within the Business Analyst function, there are different sub-functions that can evolve as specialties in and of themselves. There is a continuum from a Lead Analyst to an analysis tool expert technician. Sometimes we look for one person who can perform all the functions, oftentimes we need a team.

AttachmentSize
What is a Business Analyst.pdf124.21 KB
» login or register to post comments | printer friendly version | 5179 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Business Analysis is a skill set

Submitted by brian.mclean on Wed, 2007-07-04 01:18. *

What I find compelling about the IIBA's work to professionalise the BA role is that for the first time there is a definition of the set of skills (the toolbox, if you like) that one has to have to operate as a Business Analyst. If I can prove I have those skills then I will continue to describe myself as a BA.

This is entirely separate to the title I hold in a business. In any team I participate in I am expected to bring a certain set of skills to the table. Regardless of my title at the time, if the team requires the skills that are peculiar to a BA, then that is what I bring. I may use the whole toolbox, or just a few required techniques, but in a bigger picture beyond my current role I remain a Business Analyst.

(Here's hoping I pass certification.... :)

» login or register to post comments

It's not the first time

Submitted by ScottWAmbler on Fri, 2007-07-06 01:20. *

There have been a wealth of books over the years describing the vision, at the time, for the skills that a BA should have. These books, at the time, had a far greater range of acceptance than what I currently see in practice for the BABoK. Don't get caught up in all the marketing surrounding the BABoK.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM Rational

» login or register to post comments

That's a little cynical ;)

Submitted by brian.mclean on Fri, 2007-07-06 05:44. *

I hear the warning, Scott, and appreciate where you're coming from.

In South Africe (although I'm sure the problem is not unique here) the defition of BA is very flakey and varies widely. We have some top people who have done good work in this area, but still for many companies / teams the BA is the guy that writes all the documentation and takes the fall when the system doesn't quite work.

The attractive thing about the BABoK is that we can subscribe to an industry-wide vocabularly and set of principles. Not that we kill everyone with the book, or that we become religious about following the rules, but it gives me an edge in filling a role in which most have previously guessed there way through.

Idealistic? Perhaps, but as long as I don't assume that because I have a BoK I am king of the world and unshakable, I find real value.

» login or register to post comments

Take the Fall... and older books

Submitted by dwright on Fri, 2007-07-06 14:52. *

" ...BA is the guy that writes all the documentation and takes the fall when the system doesn't quite work."

Hmm, does not sound like a happy situation. BA's have to stand up for themselves, but we are usually seen as a non-controversial role.

To Scott A,
What were the titles of some of those BA books you mentioned? I have found few such books in the past, and never liked the ones I did find. The were usually about softer skills, like communicating with the business, running a JAD session; nothing wrong with that, but it ain't unique to Business Analysis. What was usually missing was what a good requirement looked like, and how to know when you have the good ones.

David Wright
Member, IIBA
"As a general rule the most successful man in life is the man who has the best information."
Benjamin Disraeli (1804 - 1881)

» login or register to post comments

System Analysis and Design

Submitted by ScottWAmbler on Sat, 2007-07-07 08:43. *

There were several books in the 70s and 80s with titles like "System Analysis and Design" or "Structured Analysis and Design" which covered the modeling gambit at the time.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM

» login or register to post comments

Books

Submitted by dwright on Sat, 2007-07-07 22:15. *

Right, Yourdon and DeMarco et. al... a lot of Data Flow Diagrams.

David Wright
Member, IIBA
"As a general rule the most successful man in life is the man who has the best information."
Benjamin Disraeli (1804 - 1881)

» login or register to post comments

And other stuff...

Submitted by ScottWAmbler on Sun, 2007-07-08 11:05. *

There was also a lot of material on data modeling, flow charting, tables, structure charts, UI stuff, ...

And there was good advice for interviewing, running JADS, prototyping, ...

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM

» login or register to post comments

Business analysis - more than just IT

Submitted by KathleenMD on Wed, 2007-07-11 08:47. *

I've been reading this thread with interest and the thing that strikes me is that you are still looking at tha BA as an IT role (i.e. whitin the context of an IT solution).

One area that is now getting more attention in the BaBOK as well as the BA community is the role of the BA in entreprise analysis. We have to remember for a project to succeed, requirements need to be fleshed out and, more importantly client expectations need to be put into a realistic perspective and that, way before a solution is even agreed upon. This is not often done judging by the project success rates out there.

This is where the BA is most effective and, as a company, this is where we chose to put the BA role, as a unit within the business area. Business is not always cut and dried, nor is it always logical. You therefore need someone to bridge the more emotional aspect of a project (business) with the binary application (IT solution)

My soapbox rant done, I do believe that the skills and methodology on the market is applicable to all projects, whether the solution is IT or procedural, including the Agile approach that is a great tool to manage client expectations by breaking down massive projects into more realistic phases.

However, what I've read so far, and the books you have proposed, tend to concentrate only on the disjointed aspects of business analysis, and most of them from a distinctively IT perspective.

Though great strides have been made for IT to understand business, it has not, from the bibliography out there, captured the reality of business analysis the way I am living it everyday.

At this point the BaBOK is the only document that is actually trying to put it all of those aspects together...it should not be waved off so easily.

Kathleen Mac Duff
IIBA member

» login or register to post comments

What is our scope? and where do we report?

Submitted by dwright on Sat, 2007-07-14 19:57. *

(1)I will be the first to admit/pronounce that what I do as a business analyst falls within the realm of information systems. When I consider enterprise architecture and/or analysis, it is still within the context of information management. What I read about EA often implies it is the basis of actually running/managing the whole enterprise, that the business needs EA if it is going to be truly successful; until I see otherwise, I think that is overstating the case, and can cloud the real benefit of architecture for information systems.

(2) Where should BA's be placed in the organization? I think the usual choice between Business and IT is a red herring. The real partition of activities in a company is between operations and projects. The former is running the business while the latter is changing the business. It has just evolved that many (majority?) of project activities are IT-related, so the people doing the IT projects are grouped together, including the BAs, while the rest of the company keeps things going, Even within IT, there is a separation between development/maintenance and actual system operations... and long before IT, companies had both operations and projects; consider the old-style time and motion studies, projects carried out by specialists to improve (change) the company's operations. These days we have Six Sigma Black Belts running process improvement projects, without IT (and without BA's) if there is no information system component to the improvement.
In any case, organizational structures come and go while the work itself stays much the same. That's OK, because org charts organize actual people, and the way people inter-relate to get work done changes over time, but when was the last time a re-org actually changed your job itself?

David Wright
Member, IIBA
"As a general rule the most successful man in life is the man who has the best information."
Benjamin Disraeli (1804 - 1881)

» login or register to post comments

BA Resources

Submitted by weeza on Tue, 2007-07-24 13:06. *

There are several resources that one can access to determine what a requirement is, how it is gathered, what is documented as a requirement and how it is documented. Two authors that offer methodology in these areas are Karl Wiegers, and the Volare Methology by Robertson & Robertson. You should find these authors provide information about current techniques and trends. I agree there some great references from the 70's and 80s, but outdated for enterprise analysis, object oriented analysis and more.

Documenting requirements is a critical part of the someones role, and there is a skill related to writing requirements, but I believe the emphasis in many cases is overstated in some cases. The tasks that lead to documenting requirements is the softer skills you mentioned needed to complete the process collecting and negotiating requirements between IT and Business, just to name a few, that are the critical to the end product, refering to the document.

I agree that these soft skills are played by other roles outside of the BA, including where BAs exist but are either underutilized or do not have the skill set to perform the skills that are softer in nature.

Pat Perry
IIBA Member

» login or register to post comments

  Sponsored Announcements & Special Offers


FREE Web-based Requirements Management (not just a trial, no time limit)
Lighthouse is a web-based IT project workspace for managing requirements, change requests, project scope, and much more. Lighthouse also automates traceability through the entire life cycle so you will always know the impact of change requests and whether requirements have been built, tested and fulfilled. Free for 5-users, sign-up today.

Download a free trial of ActiveVOS for BPM application development for a chance to win an ultra-portable Lenovo IdeaPad S10 netbook
With the ActiveVOS Business Process Management system (BPMS), the creation of compelling business process applications is compatible, scalable and affordable for everyone from the developer to the business analyst. Download a free, 30-day supported trial of ActiveVOS for the chance to win a Lenovo IdeaPad S10 netbook. No purchase necessary. Download ActiveVOS today at www.wheel-of-function.com.

Writing Use Cases with Word and Excel? Suffered enough?
Create use cases, requirements, diagrams, test cases, and screen prototypes - in one easy-to-use tool. Generate Word and Excel specifications automatically. Consistent, traceable requirements in less time. Try CaseComplete FREE for 30-days.


© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group