"So, where does the Business Analyst role end and the Project Manager role begin?" asked a concerned student in a recent Introduction to Business Analysis class. "I see lots of opportunity for toes to be stepped on if we implement these things in my organization!"

Business Analysis has only recently gained recognition as its own discipline, and many organizations are learning about it in an attempt to make it a part of their project structures. As the student above realized, making this new role work in any organization will include determining precisely who should be responsible for what activities, and where the limits of each person's responsibilities and authority lie. This should not be surprising; although the role is new, the activities that it represents are not.

What is "Business Analysis"?

Business Analysis has only recently gained recognition as its own discipline. The International Institute for Business Analysis (IIBA^TM) was formed in 2003. They published draft version 1.6 of the Business Analysis Body of Knowledge (BABOK)^TM in July 2006 and promise version 2.0 (the first non-draft version) imminently. They also recently created and administer the Certified Business Analyst Professional (CBAP^TM) certification.

The BABOK defines six "Knowledge Areas" which define what a professional BA should know and be able to do. Taken together, they form a set of qualifications for BAs, and provide a foundation for defining that role and how it fits into each organization's structure.

• Enterprise Analysis: Analyzing and modeling the organization's business processes and identifying opportunities to improve them, leading to initiation of projects. (The other five Knowledge Areas operate within the context of each project.)
• Requirements Planning and Management: Planning and managing the requirements activities for a project, and managing the requirements themselves, including requirements change control and scope control.
• Requirements Elicitation: Working with people and other sources to understand and identify all requirements information that is relevant to the project.
• Requirements Analysis and Documentation: Organizing, structuring and understanding the elicited requirements; putting them into an appropriate form, and performing necessary verification and validation on them to ensure their goodness.
• Requirements Communication: Planning and implementing all requirements-related communication activities, including elicitation, validation, reporting status, resolving conflicts, and gaining approval.
• Solution Assessment and Validation: Collaborating with the technical and QA teams to ensure that the results of the project fully satisfy the needs embodied in the requirements.

In these Knowledge Areas, the "Requirements" are not just for software systems; they are for the entire "Solution," whatever it may comprise. These requirements may be for software to be written, enhanced, or purchased and integrated. They may also be for processes, procedures, forms, training, documents, or anything else that is needed.

Why is the BA's Role An Issue?

There is nothing new about business analysis. The activities that are defined in the BABOK have been with us for as long as we have been undertaking projects. Nothing new has been added, and those activities are pretty much what any of us would expect. The only difference is that they are the responsibility of the BA instead of some other project member ... or possibly no one at all. And this is precisely why the BA's role can be a problem.

To the extent that these activities have been ignored or given too little emphasis in an organization, the addition of the BA role means that they will finally receive the attention they should have been receiving all along. This new focus can correct many of the causes of past project failures, improving the likelihood of successful projects in the future.

But many of the BA's activities have probably not been ignored. They have likely been attended to with reasonable care by the Project Manager, the System Analyst, members of the user community, members of the technical team, or even the Quality Assurance Analyst. The creation of the BA role can be a threat to those people who traditionally have assumed responsibility for what are now considered to be BA activities.

Indeed, the software industry as a whole has not provided the guidance we need to resolve this issue. The BABOK's definition of the BA's role invites conflict by overlapping in significant ways with:

• The Project Manager's role as defined by the Project Management Body of Knowledge (PMBOK^®).
• The Software Engineer's role as defined by the Software Engineering Body of Knowledge (SWEBOK^®).
• The Software Tester's role as defined by a variety of Bodies of Knowledge being promoted by different testing and quality organizations.

How Should We Implement the BA Role?

The only way to solve the conundrum of the overlapping role definitions in the various BOKs is to apply a bit of pragmatism. Look at how things work on projects in your organization, fix what is broken, and don't change what works well. Use the BABOK as a guide, and for each BA activity:

1. Identify who in the organization is responsible for that activity today. Your new BA role is a natural home for any BA activity that has been slipping through the cracks.
   
   
2. Find out if those who have been doing the activity feel it should be their job. For example, software developers will often take on the requirements analyst role grudgingly, only because no one else does it. Your new BA role is a natural home for any BA activity that the current owner wishes to be rid of.
   
   
3. Determine if the activity has consistently been accomplished well. Often, people perform activities for which they are not well suited or trained, or for which they lack the necessary resources or time. Your new BA role is a natural home for any BA activity that is not a good fit for other roles.
   
   
4. Decide if there any other compelling reasons to move responsibility for the activity from its current owner to the new BA role. If not, then it should probably stay as it is.

The BA role can be an important addition to your organization's structure, but only if it is designed in a way that provides real benefit over business as usual. By applying these four steps, you can determine how to implement the BA role in the way that is best for your organization.

^TM "IIBA", "Business Analysis Body of Knowledge", "BABOK" and "CBAP" are trademarks of the International Institute of Business Analysis. ^® "Project Management Body of Knowledge" and "PMBOK" are trademarks of the Project Management Institute. ^® SWEBOK is an official service mark of the IEEE.