How a business analyst learns the business: elicitation techniques

There are many techniques that business analysis professionals use to learn about the business, including:

• Review existing documentation

• Observation

• Interviews

• Surveys and questionnaires

• Facilitated sessions

• Focus groups

• Competitive analysis

• Interface analysis

BAs should learn and practice as many of these techniques as possible. Experience will help in determining which technique is the most appropriate for each situation. BAs should think about making the best use of their stakeholders’ time. Choose techniques that are the most efficient and most effective based on your understanding of the individual stakeholders.

Review Existing Documentation

This is the best technique for BAs to use first. Reviewing existing material helps the analyst by introducing the terminology used by the business. It also helps the analyst formulate questions to ask stakeholders. Read system or software documentation, employee procedure manuals, policy handbooks, etc. Read anything you can find that might give you some insight into the business and most importantly the workers. Look at forms, screen layouts, and reports. A BA should not waste stakeholder time asking questions when answers to those questions are readily available in existing documentation.

When reviewing documentation, be aware that not everything you read will be 100% accurate and up to date. Plan to verify facts with stakeholders. Even when the documentation is incomplete or out of date, you will gain important information from reviewing it.

Case in Point

When I started one of my jobs as an analyst, I was told that my first project was a rewrite of an old, purchased software package. As with any new job, the first few days were slow; I learned login procedures, filled out employee payroll forms, and learned the names of my co-workers. I browsed the bookshelves in the IT area and found an old, dusty binder titled with the name of the software system that we were planning to replace. I took the manual to my desk and reviewed it. It was the original user manual that the vendor had delivered with the software package many years ago. The pages were yellow and it was clear that no one had used this manual in a long time, but I didn’t have any specific assignments yet so I read it—cover to cover. I learned much about the business itself; it was a mortgage origination system. I was exposed to terminology and learned the meanings from the usage and context. I learned about the core data elements from the screen layouts. I learned workflow from the procedure descriptions. Without intending to, I was learning the as is environment. I was aware that the manual was old and probably out of date, so I didn’t rely on its specific information. I just used it to become familiar with the business area.

Later that week, I was invited to attend a project kickoff meeting where the project manager expected me to listen and learn about the project and meet the key stakeholders. They began to discuss the possible outcomes of the project and some of the problems with the old system. Since I had familiarized myself with some of the business terminology, I understood most of the discussion. I was able to participate and ask a couple of useful questions because I had just finished reading the manual. When I first spoke up, my project manager gave me a strange look, wondering what I could possibly have to say that would be of use in my first week on the job. But when I made a relevant comment and asked a specific question about the old system, the business stakeholders looked pleased. One of them later complimented the project manager on what a good hiring decision she had made by bringing me on board. I was able to start participating and bringing value to the project within one week of employment!