In this project management tutorial Angela shares when interviewing should be used as a technique for gathering and eliciting requirements. She explains who to interview and for what purposes, also comparing interviewing with other techniques.
- 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 more 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.
Besides being the most common technique for eliciting requirements, 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. I hear a lot from analysts that they do not have access to meet with a sponsor. Others have very good access. Regardless of your situation, 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, objectives, 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. Now don't forget about the users of the solution. 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 frustations 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 S-M-Es, 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 on a screen for a system that their team uses.
They may not think that the interview is needed since they already know what they want. When eliciting 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 user groups.
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. I hope you find these reasons useful in your requirements elicitation. 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. Think about the projects you work on and how you can apply these concepts to your project and interviews. Take a look at the exercise file listing the project types and what you need to know from those that you interview. Use the exercise file to guide you through some sample project types and interviewing rationale.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Choosing to use interviews
- Selecting the right person to interview
- Planning interview questions
- Building rapport in an interview
- Choosing probing questions
- Listening and taking notes
- Analyzing and reviewing notes before following up