Why do requirements interviews never pan out as they are planned – and how do I prepare for that? I’m looking for the following kind of help regarding how to prepare for these interviews and what I can pay attention to in order to make the most of them.
My information project, centered around management reporting within a firm, is currently in it’s definition stage. All my stakeholders are managers of greater or lesser scope.
I had my previous two interviews planned out quite extensively, but on both occasions my interviewees both went off in completely different tangents, delivering quite interesting results. I completely ignored the question flow I had prepared, and tried to go along with the interviewees. But instead of going towards a common concept that can be developed on, I feel that I get in-depth pictures of each individual’s local information requirements.
How can I conduct an interview that helps me get the participants on board and thinking towards a common solution, but doesn’t inhibit their own thoughts which deliver me interesting material on data sources, formatting and communication paths?
5
I’ve found requirements gathering to go most smoothly when done in three stages:
- Get together to let the stakeholders talk only about the problem. You want to gather as much information as possible about what the problem is with the current way they are doing things, only talking about potential solutions if it helps frame the problem better. They need to get it off their chest anyway, and attempting to keep stakeholders from talking about the problem is usually futile, so you may as well plan for it. Also, non-programmers find it easier to talk in these terms, so you get a better idea of the requirements if you welcome this part of the discussion.
- Either yourself or in a smaller, more technical group, you translate the problem statement into some rough drafts of possible solutions, creating more than one option if necessary.
- Get back together with the stakeholders to let them poke holes in the proposed solutions. Make it clear how you’ve taken their problem description into account. Refine the requirements together until everyone is happy, which might take more than one meeting. Again, non-programmers find it easier to discuss a concrete proposal than to imagine potential abstract solutions.
Usually when people have problems, it’s because they’re trying to skip step 1 and cram steps 2 and 3 into the same meeting.
1