Case in Point

I worked for an organization that provided emergency road service to customers having car trouble. When I was assigned to help rewrite the payment processing system for this business area, my IT director insisted that I “ride along” on a few of the emergency calls to observe the work being performed. I couldn’t understand why I needed to watch cars being towed to be able to develop a payment processing system. It was winter in the Midwest and sitting in a tow truck in the cold for several hours held no appeal for me. My director arranged my “ride along” for one day in February. I don’t have the space here to tell all of the stories from that day, but I can tell you that it was an education I will never forget.

Before the ride along, I drafted a new payment form that required the tow truck driver to fill in the VIN (vehicle identification number). This is a unique 17-character code, a combination of letters and numbers that gives a lot of information about the vehicle (e.g., model year, country of manufacture, engine type). I was convinced that this valuable data could be used for future analysis, like which models of cars were most frequently breaking down. A brilliant idea from a young, ambitious BA—right? Wrong!

One day sitting in the passenger seat of a tow truck dispelled that notion entirely. As we began to travel to help the customers who called, I saw that requiring tow truck drivers to find and correctly record a long series of digits in these conditions was unreasonable. One vehicle in distress was buried under 15 inches of ice. Chipping away at the ice on the windshield to find the VIN would have taken an hour! Another call took us to a high-crime area which was very desolate. We didn’t want to spend any more time there than was necessary to jump-start the vehicle. I really didn’t care about the VIN of that car! I asked one driver if he would mind supplying the VIN on his payment tickets, and he just looked at me and laughed. I also learned that on a busy day, some of these drivers work 16 hours straight digging cars out of snowdrifts and hauling them miles to the chosen repair facility. Taking time to fill in a lot of details on a payment form would slow the service to our customers.

In addition to challenges in getting the VIN, the drivers had to fill out these payment forms while wearing heavy gloves, during rainstorms and snowstorms, at night, etc. They just wanted to fill in the bare minimum of information necessary to get their payment and then move on. Our final design incorporated lists of items that could simply be circled and boxes to be checked. My ride along showed me that understanding the business environment was the key to developing a new system that improved rather than slowed the business process.

Interviews

Interviews are most appropriate for eliciting requirements with one or two individuals at a time. These conversations allow the analyst to learn about the existing business and/or talk about possible improvements. For an interview to be successful, the analyst must carefully plan the questions and the focus of the conversation. An interview can be as short as 15 minutes or as long as 2 hours. The analyst must estimate how many questions can be covered in the allotted time. Having reviewed existing documentation, the analyst can develop very pointed questions to confirm his or her understanding of the overall business functions. Then he or she can ask more detailed questions on a particular topic. Planning ahead is critical for conducting productive interviews.

The BA should prepare an agenda for each interview. It may not be necessary to share the agenda with the stakeholder, but it is critical for the BA to plan the order of topics to be covered and to estimate the time to be spent on each one. The agenda or plan must include a clear objective—what you are trying to accomplish during the session. For example: “I would like to come away from the interview with a clear understanding of why the accounting department categorizes vendors and the list of categories currently used.” Without a clear objective, an interview can turn into a conversation, meandering in many directions and not meeting project needs. Stakeholders are very busy, so business analysis professionals must make the very best use of their time. When a subject takes longer than the allotted time, ask the stakeholder for another appointment. Don’t assume that he or she can spend more time with you than originally planned.

To prepare for an interview, the BA should familiarize himself or herself with the individual being interviewed. Where does the stakeholder report in the organization? What is his or her title? How involved has he or she been with the project? Will this work be significantly impacted by the project? Is he or she a decision maker? Understanding the position of the interviewee allows the BA to develop questions that are at the proper level (see Chapter 2).

Note taking during an interview is extremely important. Few BAs are able to remember the complex answers given by stakeholders. Develop a note-taking system that allows you to paraphrase or “shorthand” the information. One useful technique is to listen for the core requirements components (data, process, external agents, and business rules, which will be discussed further in Chapter 6) and jot those components down. Even a BA with an excellent memory should take notes. Note taking lets the stakeholders know that responses are being heard and recorded. This is a signal to them that their answers are important and that you are listening carefully. These skills are discussed in Chapter 7.

Following up after an interview is polite and often yields additional information. It also allows the BA to confirm his or her understanding of the topics discussed. The BA can phone or e-mail a quick “thank you” and ask the interviewee if he or she has any more thoughts after the interview. Often, people will continue to think about the questions asked and may realize that they didn’t completely or accurately answer. It is common to hear a stakeholder say “Oh, I forgot to tell you about . . .”

Asking stakeholders for any follow-up thoughts may result in a requirement for exception processing or an unusual business transaction. These are the types of requirements that may have been missed in past projects, costing organizations thousands of dollars in rework or production problems.