In this project management tutorial Angela shares her perspective on what went wrong in the Challenge 2 vignette.
- Isn't this one an interesting scenario and one that commonly happens? In this scenario, I met with the operations manager to understand what the pain points are and the goals to the automation efforts. It's so common that the interviewee jumps to the solution. It's a tough place to be in a requirements interview. So, what went wrong? First, probing questions were not a focus in the dialogue. The requirements analyst did not ask any high-impact probing questions.
Another thing that happened is this scenario would likely result in a lot of missed requirements that end up postponing the project or creating a long list of defects and enhancements after the go live. One big issue is that the stakeholder gives us the solution and design and the requirements analyst did not stop to bring back the dialogue to the needs. They allowed the dialogue to continue into the technical design before understanding the needs in better detail.
Another issue is that the requirements analyst took an order taker mentality, where this is assumed that the stakeholder knows exactly what they need. The requirements analyst should take a more exploratory and discovery oriented approach to understanding the problem domain in more detail, before focusing on how the problem will be solved. When stakeholders come with solutions, they're typically not vetted, analyzed, and thought out in a lot of detail.
They're simply a way to express what they are thinking and do not really give us the critical information from the many perspectives needed. This causes missed requirements, defects, and backlogs of requests after go live. A great interview mentality for a listening requirements assumes that the stakeholder's ideas are just options and ideas, but not the final solution design or final requirements. The requirements come before the design or the design has a large risk of missing the mark on what is truly needed.
Stakeholders commonly express their needs in terms of solutions and designs, and it's our role to catch this and redirect the conversation back to the deeper layers of the problem and requirements. All designs are derived from requirements and interviews are the critical points where this boundary can get blurred. Missed requirements happen due to an inaccurate focus on design first. So, let's go get the real requirements.
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