Using interviews to elicit requirements

- There was a time in my career as a business analyst when I thought I could be more productive meeting with the entire project team to elicit and build shared understanding of requirements. I'm also an extrovert, so the group meetings were fun for me. Then I realized that all the large group meetings were not helping with the quality of my requirements. Things were going unsaid and I didn't have trust for my stakeholders. They didn't really all agree with one another as they seemed to in the meeting. I made a switch to interviewing as well as these big group meetings, and it made a big difference in my results. Interviews help us build powerful relationships with stakeholders. Interviewing stakeholders in small groups or one-on-one can help us understand the problem or opportunity, build relationships, and understand the potential solution from each person's unique perspective. There may be many different people to interview on a project, depending on the situation and the context. Let's look at some common roles you'll interview and why you might interview each of them. First, the sponsor. The sponsor of the project is often interviewed to understand the problem or opportunity from a leadership perspective. You want to make sure you understand the vision and goals the sponsor has in spending time and money to fix the problem or address the opportunity. Sometimes other leaders may be able to share this information with you as well. Understanding the context and perspective of the sponsor can help us understand what success looks like. You need to understand how what you are working on aligns to higher level goals, objective, and strategies of the organization. Another role you'll interview are the leaders and managers of the areas impacted, as they have a unique perspective to the problem and opportunity. They understand how the problem or opportunity impacts their area of responsibility from an operations, product, systems, and people perspective. It's important that you get time with them and understand how their concerns and ideas fit into the sponsor's vision. The users of the solution have key insight into the problems and opportunities and have yet another unique perspective that leaders and sponsors may not be aware of. These users often have all kinds of frustrations and ideas for how to improve the solution. Since they're the ones using the solution, we need to ensure that what we develop will meet their needs along with the leaders' and sponsors' needs. Building relationships with key users through interviews will help you better understand their perspective and willingness to use the new solution. Finally, the subject matter experts of the solution, system, process, or product you're working on. The subject matter expert, or sometimes referred to as SMES or SMEs have detailed knowledge about the solution, and can connect information from users and leaders that may not otherwise be easily connected. You will need their perspective that contains a deeper level of knowledge about the product or solution as a whole. Sometimes SMES and users or leaders are the same person. The roles may overlap. I want to give you a word of caution in your interviews. Stakeholders also often talk about their requirements in terms of the detailed design of a solution. For example, a manager of a processing area may ask for a new button a screen for a system that their team uses. They many not think that the interview is needed since they already know what they want. When enlisting requirements, it is critical to understand the underlying need driving the desire for the new button on a screen, and understand the context of why it's needed. Often the solution given by the leader is only part of the technical solution, causing unintended errors if we don't fully understand the need. There may also be other options and alternatives to solve for the problem that may be cheaper, faster, and not impact other usergroups. It's your role as a requirements analyst or business analyst to dig in and understand what the underlying need is, and ensure the solution is complete, and will not negatively impact other users. Elicitation is about discovering requirements, and even though at times, it may seem like your stakeholders can tell us exactly what they want, digging in with these approaches to interviewing often reveals a lot more information that can make the difference in a successful solution. Now that you know who to interview and why, you'll need to understand your unique project type, and how it provides additional context to your interview. Use the exercise file to guide you through some sample project types and interviewing rationale.