The Requirements Interview: Asking the Right Questions

Recently at work, we had to replace our project management tool. Our current software was outdated and becoming unusable. Updating to the current software’s latest version was one option, but we also wanted to look if there were any other options.

But how to decide? There were so many choices!

The answer? Create a set of requirements.

Involve People Through Interviews

One of the most important parts in researching requirements is to talk with people. It is people who are going to put content into the software, and people who will need information out of the software. Without people, the process grinds to a halt and looks like the deserted streets of a major city in a post-apocalyptic movie.

Interviews create a sense of ownership, increasing adoption success.

Another benefit in including people during the requirements gathering process is that they get to have their voice heard in what their needs are. That sense of ownership can help make change management easier later on.

Do Your Background Homework

Before we schedule an interview, we need to do some research so that we can effectively lead the interview and not waste people’s time.

Start by exploring the current tools, documentation, and processes. Focus on the what and why, not the how.

In my case, I wrote down all the types of data entered into the tool, who entered the data, and who pulled the data. I also noted why we were trying to capture the data and what business goals we were trying to accomplish.

Yes, we entered typical project tracking data such as start date, completion date, tasks, and milestones, which helped keep customer onboarding on track. But the real focus was our billable labor. We were having difficulty finding a way to meaningfully track and report the hours customers had purchased with time we had actually used, the time we had planned but not yet used, and unaccounted-for time that wasn’t even planned for. At the end of the quarter (and the end of the year), it always felt like a bit of a scramble to make sure everything was used or planned for. Our current tool worked, but could definitely be improved.

It’s also important to prepare a list of questions in advance. If you don’t have questions pre-prepared, you’ll spend mental energy thinking up the next question instead of actively listening to the interviewee. By having the questions written out ahead of time, you can concentrate on what’s being said before moving on to the next question.

Set Expectations

When you send the meeting notice, include the purpose, agenda, and anything else the person might need to know ahead of time.

Most of my co-workers had already given a verbal okay from a quick chat, and been informally briefed on what we’d be meeting about. In the meeting notice, I included the purpose: analyzing our current tool to find requirements for the replacement tool. After a lot of thought, I also decided to send a link to the requirements document I was building. On one hand, I didn’t want to pre-set their answers but on the other hand, seeing some of the requirements I had already might help them think more detailed.

Ask Open Questions

Open questions are generally who, what, when, where, why, and how. The answers start conversations, and are not easily answered by saying Yes or No. Be careful asking how questions: they can start getting too deep into details that aren’t part of the requirements.

Some of the open questions I asked were:

  • Who or where do you pull your information from?
  • Who uses the information after you enter it? Where does it go?
  • What are the reports you need to provide to upper management?
  • Tell me about the last time you were frustrated with the current process? Why?
  • Tell me about the last time you were happy with the current process? Why?
  • Can you give me an example of how that affects you?

Ask Closed Questions

Closed questions can usually be answered in just a few words. They are usually more factual in nature, or comparative to determine high and low importance.

Some of the closed questions I asked were:

  • Who should have write access? Who should have read access? Can customers have read access?
  • What file types do you provide to customers to show them their project milestone plan? To show them their billable hour purchase and use?
  • Is having a mobile interface important to you, so you can see your accounts while traveling?
  • Is it more important to attach files (such as an invoice) directly to the project, or would you prefer to link to an existing location?

Remember to Listen

Requirements interviews are still part of the research stage. Any solutions here are premature, though they can be captured for later. It’s important to really listen, and use all the body language that goes along with listening (even over the phone).

When asking questions. allow a quick break of silence while the interviewee thinks about an answer. Start talking too soon and the interviewee might not have time to think of a complete answer. If more than a moment passes, you might ask, “Would you like me to rephrase the question?”

Since my team was very geographically diverse, my interviews were done over the phone. (Well, really a headset attached to my computer.) Sometimes I took notes myself, and sometimes we shared screens and worked together in a common document. My goal the whole time was to be like an investigative reporter, questioning and learning objectively.

Next Steps and Other Actions

Other requirements actions can include job shadowing, brainstorming, and surveying, but only what it takes to get what you need without becoming trapped in analysis paralysis.

Once I had my requirements, I could look for themes and correlate similar answers into a final requirements package that could be validated and approved by a manager or subject matter expert.

Choosing a subset of software vendors to interview became simple and easy because I had a standard benchmark. Only one vendor was able to meet our billable time requirements, making it an easy choice.

Without the research and interviews, leading to a solid set of requirements, choosing a new project management software would have been more difficult, taken longer, been subject to opinion rather than business needs, and might have been fought by the employees who eventually would use it.

Although it might seem like a lot of work in the beginning, defining requirements pays off in the long run.

Resources