Of Asking and Telling – Requirements Interviewing Techniques for Business Analysis

Requirements Interviewing Techniques – the New Hot Topic

For reasons known to none, interviewing for requirements seems to be a hot topic for business analysts now-a-days. I don’t know why, but recently I have been getting inquiries from customers and prospects alike regarding this critical early or pre-project activity. The inquiries range from how to get the most out of a face-to-face requirements interviews to how to conduct virtual requirement interviews. As a result, I decided in my finite (trust me, extremely finite) wisdom to broadcast my response in writing as opposed to repeating myself on numerous phone calls that I would love to get from all of you.

Requirements Interviewing techniques are sufficiently complex that it will take a series of articles to cover at an appropriate level of detail, so this article will just give you an idea on one way to get started preparing for the awesome task of trying to get information from people who should know better. I mean, they should know more about the topic of the interview than you do, otherwise why do you want to interview them?

Preparing for a Requirements Interview

Very often, the first question people ask when it comes to requirements interviewing is, “Who should I interview?” Beyond being grammatically incorrect, this is actually the wrong place to start. You cannot answer this question until you have addressed a more fundamental one, namely “What do I need to know?” Without a reasonable answer to the “What …” question, identifying potential requirements interview candidates is next to impossible.

The answers to the “Who …” question will help you identify people whose buy-in you need for the project to succeed (aka: Stakeholders). The “What …“ question should lead you to the creation and maintenance of one of the simplest forms of documentation for any project – the Question File. This might sound silly, but it just may be the most important document you create for your project. All you have to do to get started is to recognize that there are things about the project that you know you don’t know.

Formatting a Question File

To initiate a question file you need a word processor. Come to think of it, a spreadsheet program will do just as well. Heck, if you want to go real low tech, something to scribble on and something to scribble with will work just fine. Simply put, create a table consisting of six columns. The first column will be skinny; it should just contain a number that identifies the question. Go ahead, be brave and label that column “ID” or something equally creative. The second column gets the header “Q-Date” from which you may correctly assume it will contain a date. As a point of procedure, I recommend dating each question so that you can keep track of when you became aware that there was something you needed to know and didn’t. This information will come in handy later in the process.

Column three will be wide as it describes something that you know you don’t know. I recommend that you formulate what you know you don’t know as a question. Express the question in a manner that any answer you get becomes a new fact that pertains to your project. Interestingly enough, that fact could spawn a whole host of new, more detailed questions. Don’t panic, that is actually a good thing. Remember, analysis is all about comprehension and the more you know you don’t know, the closer you are to comprehending. Just keep adding the new questions to the end of your question file. Trust me, the more questions you have, the more powerful this simple tool becomes.

Identifying Stakeholders

The fourth column is called the “Who” column. It is where you capture (in writing, not in person) the Stakeholder with the knowledge and the authority (either alone is not enough) to answer the question. You can identify the individual by name or by role/job title. If you cannot think of anyone that could give you an answer, try to think of anyone who might be able to point you in the right direction and write that person’s name in this column.

Recognize that you don’t actually have to be right when you identify the individual, but it is at least a good starting point. All you are documenting is that this person is your most likely target for getting closer to an official answer to this question at this time. The more you learn about your stakeholders, the more often you will be able to identify the right person.

Capturing Stakeholder Responses

The title for the fifth column is “Answer”. Make it wide so you can document whatever answer you get from the person named in the “Who” column. By the way, in case you don’t get an answer by the time you need it, it is also where you can document your assumed answer. Wait, did I just hear a swift intake of breath at the audacity of assuming you are going to make an assumption about something as important as this question? – Sorry about that, but experience shows it is sometimes the only choice you have. Your project is on a schedule and you may not have the luxury of letting the answer to this one question hold you up. If all else fails, be audacious and make the most likely assumption you can based on what you do know about the project. Just make sure that you document that this is an assumption. Make it bold, make it italic, make it a different color, but make the call.

By the way, I recommend telling the world – or at least anyone who might be impacted by this question – about your assumed answer. As a technique, you might consider sending them a simple email stating something like, “We needed to know this and since we have not been able to get a definitive answer, we are going to work under the assumption that … In the event that you disagree with our assumption, please let me know within ??? days to help us avoid rework caused by a faulty assumption.”

The sixth and final “A-Date” column is to document when you got the answer (or made the assumption). As opposed to leaving this space blank until they get a response, some people prefer to write down the deadline they gave the person tasked with providing the answer.

Measuring Your Uncertainty Level

If you had a question file for your project, you could perform magic tricks.  Just for example, you could sort your file on the “Answer” column and count how many questions you had answers to and how many were still open. The ratio of the two shows you how uncertain you are about the project, but beware. Early in the project, you could have very few questions but a high ratio of answers. Although the ratio is high, the small number of questions could signify that you simply have not yet recognized everything you don’t know about the project and be a sign of insufficient analysis.

If the file has grown significantly in a relatively short time frame, the ratio represents a reportable measure of your uncertainty about the project. As a final note, never expect to get all of your questions answered lest you become befallen with analysis paralysis. There will always be detail questions that no one can answer until the project has gotten much further along. Nonetheless, by capturing them, you have a weapon with which to combat later accusations of faulty or incomplete analysis.

The Interviewing Connection

You could sort the file on the “Who” column to determine whom you should be interviewing next. You might target the person for whom you have the most open questions. On the other hand, that might not be politically correct. Perhaps you should interview the highest ranking person whose name is on the list first to define or confirm the scope and purpose of the project. It is your call; the list simply gives you a quick method for identifying and positioning your stakeholders more efficiently. The actual questions in this file give you the basis of a great interview if they are properly sequenced and structured (again, more on this in a later article).

One Last Magic Trick

If you browse this file and compare the date you identified the question with the date you got a response, it might even tell you something about the priority of the project from the perspective of the individual identified in the “Who” column. If someone who is critical for project success is not responding to your requests for information, your delivery date could be in jeopardy. What is your strategy for dealing with that scenario?

Lastly, if someone new comes on to the project, this simple little question file could just be invaluable as a tool for getting them up to speed quickly and without you spending time telling them everything that is in the file. If this is not magic, it certainly is the next best thing for a business analyst.