March IIBA – So That’s What A Business Analyst Is

Do you remember last Tuesday? Cincinnati got something like four feet of rain in about 15 minutes. I dreaded the drive from downtown to Blue Ash, and as traffic crawled along 71 North I figured I’d just hit the lateral and head home up 75. There was no way I was going to make the meeting in time. Traffic seemed to ease up just a bit right at the lateral, so I decided to keep heading North on 71 thinking I’d give it a try. I figured no one would show up and I could at least offer some support by being one of the few folks who would battle both the traffic and the weather. Boy was I wrong.

I arrived about 5 minutes late and walked in at the beginning of the speaker’s introduction. The place was nearly standing-room only with probably over 50 in attendance. And that was with a number of folks I knew who said they would not be able to make it. Kudos Melissa, you’re killin’ this thing with some great value-added material. I grabbed a seat in the back row next to a friend and former co-worker Beth Mindlin, and settled in for an hour’s discussion on The Roles and Relationships of the Business Analyst, Systems Analyst, and Project Manager. The discussion was so clear that the next day I could answer this LinkedIn question without blinking.

David J Hansen Ph.D., CBAP, and PMP, the Executive Director of Organizational Innovation and Learning for Babbage Simmel, spoke to us this evening. As David tells his story, he has spent many years in the business analyst role. One of his first IT systems analyst roles involved defining security around a system that supported legislative activities. The primary concerns in order of priority were that 1) The other side of the aisle couldn’t see information we produced, 2) Our constituents couldn’t see the information either, and 3) no one could hack it. Hmmmm…

Then David asked some questions. First, “How many people see themselves working as a BA?” About 2/3rds of us raised our hands. “How many know what one is?” Not so much. The BA role is defined more by ambiguity at this stage in the game. The title is widely used but meanings are all over the table. The IIBA tries to put definition around the field as a profession, and they’ve come a long way. In the end, requirements definition is the core of what a BA is. Overall, the definition is evolving.
Charles Slaven,

David cut his teeth on some fairly intense analysis projects. He served as an analyst for a Unicef system to allow anyone from any country in the world to give a tax deductible donation. A huge order concerning inter- and intra-national tax law. David also started the first community college in Albania. In case you’ve been living in a cave, the Balkans is a very tough neighborhood. He has helped design MRDD IT systems, child care eligibility systems, and has generally approached his analysts roles from the business side of the organization, and not IT.

What is a one sentence definition of a systems analyst? An IT centric role whose responsibility includes producing documentation to create usable software that solves problems. Most IIBA analysts come from the systems analyst perspective where IT develops applications to solve problems. For a solid primer on good advice for managing requirements, download babok version 1.6 from the IIBA. This version is free and contains 300 pages of current BA practices from around the world. The body of knowledge is not a standards document nor best practices. It is an evolution of current practices. You’ll find less than 8 pages about use cases yet over ½ the presentations at IIBA meetings are about use cases. What does this mean? Many business analyst roles serve in strategic parts of the organization, and not everyone works for IT.

Looking at section 1.6 of the babok, you’ll find the framework within which most BAs work. Enterprise analysis leads analyst activities on the front-end because for any project to succeed, the project must align with an enterprise’s purpose and the strategic functions of the business. Anything less and you’re assured failure – even if the project finishes on time, on scope, and on budget. IT in many organizations does not operate in the enterprise analysis space, and in some cases the CIO may not even find out about technology projects until the business decides on them.

The two long boxes in section 1.6 represent requirements planning and management and requirements communications. These functions continue for the length of analysis part of a project. Although the path is serial, get requirements -> analysis and documentation -> assessment and validation, it can iterate. How? People change and requirements change.

So what’s important about the enterprise analysis space? In the most basic sense, you need to base your project on enterprise needs otherwise the business will hang you out to dry. If a BA doesn’t do the enterprise analysis then you need to find documented evidence that someone has completed it. From the IT perspective, the systems analyst generally does the requirements analysis and validation and may go back to requirements elicitation, although requirements elicitation skills vary greatly from analysis and validation skills. Some BAs never work beyond the enterprise analysis space. IT BAs, or system analysts, may never ever work in the enterprise analysis space. One key for successful analysis is to ensure business value and alignment along the continuum of analysis activities.

Some enterprise analysts move into the requirements elicitation space. Elicitation means to pull out or draw out as you and I both know requirements aren’t just lying around to be picked up. In comparison, the work educate derives from eductive, or drawing out. So as you draw out requirements you educate the organization about the needs driving this particular product or service. Throughout the elicitation process, the BA gains more and more buy-in, and through iteration support grows. The process creates real stakeholders. Enterprise analysts generally have strong elicitation skills because enterprise analyst skills are heavy on communication skills and high on people skills. In contrast, BAs coming from IT have a difficult time moving into the requirements elicitation space because their historical skill set involves data and things rather than people. Successful projects integrate analysts from both sides of the spectrum so all aspects of a project gain representation.

The BA is responsible for tasks, knowledge, and techniques required to 1) identify business needs, and 2) determine solutions to business problems. These two requirements split the knowledge area map in half. No one person can handle both sides of the equation well. The typical BA handles the front end, and the more familiar Systems Analyst generally covers the back end. These two roles think think about the problem domain entirely differently. Think about the different kinds of errors that can occur in any system. Take alpha and beta errors. An alpha error missing something that could fail, and a beta error is missing something that could succeed (think try, try until you succeed). The systems analyst focuses on alpha error as they find places to make a system fail. The business analyst, especially one in the enterprise analyst space, focuses on beta error, or to do whatever it takes to succeed – collect 100 ideas to find the 5 that matter. A team needs both types of analysts in order to get a full solution to a real problem. On front end an analyst may gather a lot of information that will be pitched. At some point a project manager stops collecting information and moves all documentation to the systems analyst to find patterns and develop and validate a solution. The PM’s job then becomes delivering the required product or service within the time frame, scope, and budget (PMBOK, 3rd edition).

Although it happens a lot, requirements elicitation is not the job of a project manager. The analysts should deliver requirements to the PM when the project starts. As things go today, a PM is lucky to even have a charter, and they wind up building the airplane while it’s in flight. Suffice to say that the PMI is really glad to see the IIBA.

In the end, it takes teamwork to identify business needs, determine solutions to business problems, and deliver the required product service or result within constraints. To get an end-to-end view grab the free babok, and grab the PMBOK from Amazon (where you’ll find a better price). The two bodies of knowledge complement each other. You’ll notice that the PMP has strong interpersonal skills: effective communation (exchange ideas), influencing the org (get things done), leadership (develop a vision and strategy, motivate a team to achieve the vision), motivation (energize people for high performance), negotiation and conflict management (confer to reach agreement), problem solving (alternatives for decision making). All of these skills are pragmatic and focused on getting a job.

Assumed BA skills include facilitation, communication, conflict resolution, negotiation, relationship, questioning, systems thinking, escalation, logic, leadership, coaching, facilitation long-term goal setting, motivational , appraisal, interviewing, role definition, behavioral coaching, cultural awareness, delegation, success planning. You’ll find all these outlined in the babok glossaries. These skill lean heavily toward enterprise analysis and requirements elicitation, but they are also important to the systems analyst, otherwise the systems analyst is reduced to doing blackbox development without business interaction.

The enterprise analyst identifies business opportunities, builds a business architecture and framework, and determines the optimum project investment path for an organization. An investment path provides a defense and justification for your efforts, and you’ll be called to account at some point for the business value of your project.

That was essentially it for David’s talk on the relationships between the project manager, business analyst, and systems analyst. You can reach David at dhansen@babsim.com or 614 481-3939.

Andy

Advertisements

~ by Andy on March 24, 2008.

2 Responses to “March IIBA – So That’s What A Business Analyst Is”

  1. If only it were so simple! Ha!

    As an analyst by desire and a PM by need, I have experienced true satisfaction in the role of an analyst. When I first started out, I found the more and more people looked at PM as the next step in the career ladder for an analyst. I never wanted to be a PM and never found that option appealing to me.

    The company that recognizes the unique contributions of both the analyst and the PM is hard to find. But yet, what seems to be more elusive is finding the company that is willing to fund both activities.

    Here’s to all the analysts out there!! (IMHO, the most satisfying IT job!)

  2. I think the role of the Business Analyst will continue to evolve and become more defined in the future. The career is still fairly new to the IT industry. But as more Companies move towards the offshore/outsource model for development the need for BA’s who can truly understand the needs and goals of the business will only increase.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: