Workshop: Stakeholder Interviews

Workshop: Stakeholder Interviews #

At this point, you may have some rough ideas about what kind of mobile app you want to build. Well, there are many different features you can try to support, and many non-functional requirements that you can target, but how do you know which ones are actually useful? Meeting with your stakeholders is the best way to find out.

In this workshop, we will talk about tips for interviewing stakeholder to discover their needs and constraints. We will also run practice interviews with each other. The goal is to leave the workshop with (1) a few concrete requirements items of your app, and (2) an actionable procedure for turning your project idea into concrete requirements items.

Interviewing Stakeholders for Requirements Elicitation #

Interviewing your (mostly customer-side) stakeholders is a classic requirements elicitation technique. They are especially good for getting an overall understanding of how stakeholders complete (or not complete) certain tasks, and how they expect to interact with a future system (that is, your app) to complete those tasks. Do note that interviews don’t necessarily discover all the edge cases or deeper domain rules, which you should complete with other requirement elicitation techniques (e.g., observation, prototypes, etc.).

Typical interview format #

Stakeholder interviews are usually semi-structured meetings, where the interviewer (you) bring a list of topics, listen to what the interviewee (the stakeholders) says, and probe based on that. A common agenda is:

  • A brief intro and context (~5min);
  • The elicitation process (length varies, 30-60min or even longer);
  • Wrap-up (5-10min), when you summarize the main points and (optionally) agree on follow-ups.

In terms of participants, there is no hard rule on the number of interviewers and interviewees. Some tips and considerations are:

  • Identify different groups of stakeholders (users/sponsors/operators/…), interview one group of stakeholders at a time, and try to do at least interview per major group.
  • One interviewee is typical because it’s easier to go deeper in the conversation; small group interview can also be useful to get aligned viewpoints.
  • On the interviewer side, there are several roles (that can be played by the same person or different persons): interviewer (asking questions), note-taker, and optionally observer (monitoring interviewee’s reactions and asking follow-up questions).
  • Avoiding having too many people on the interviewer side because it can be overwhelming; 2 persons (one main interviewer and one supporter) is usually a good balance.

Interview tips #

  • Clarify the interview context so that the conversation stays focused:
    • Scope (“Today, I’d like to focus on [task/scenario] and walk through how it works end-to-end.”)
    • Purpose (“My goal is to understand how you do this today and what constraints you’re working under.” (don’t pitch a solution yet))
    • Stakeholder role (“To make sure I’m hearing the right perspective, can you tell me what your role is in this process / what part do you directly handle?”)
  • Start concrete, then generalize: begin with real incidents/experiences/events, then ask about the “ideal future” only after you understand the current workflow.
  • Mix open-ended questions (to encourage interviewees to share their experiences) and closed questions (to confirm details).
  • Avoid leading questions: ask about goals, constraints, and tradeoffs before proposing features.
  • Listen for non-functional requirements and make them concrete (with follow-up questions).

Questions to ask #

Starters:

  • What was the last time you did X?
  • Can you walk me through the typical workflow you do X?
  • What parts are most error-prone or frustrating?
  • What constraints do you have to follow (policies, tools, time)?
  • What does “good” look like here, and how would we measure it?
  • What are the top 3 things you need from a future solution?

Follow-ups:

  • non-functional requirements (“fast/reliable/easy/…”) -> ask about measurable specifics (e.g., “What is an acceptable response time?”)
  • clarifying terminology -> When you say “[term]”, what exactly does that include/exclude?
  • workflow details ->
    • What happens right before/after this step?
    • How often does this happen (per day/week/month)?
  • limitations of current solution and needs ->
    • What usually goes wrong here?
    • What’s the impact when it goes wrong (time/cost/risk/customer impact)?
    • What do you do today as a workaround when this fails or is slow?
  • priority ->
    • If you could improve only one thing first, what would you pick (and why)?
    • Among the constraints, what must never happen?

Wrap-up:

  • Here’s what I heard… did I get that right?
  • What did we not cover that could become a problem later? -> may potentially lead to a follow-up conversation after the interview

You’ll do two short interviews with a buddy group. In round one, one group interviews while the other acts as the stakeholder. Then, you switch roles and repeat.

  • Each project team should split into small groups of 1-2 students. If you are running multiple project ideas in the team, each group can focus on one of them.
  • Each group finds a buddy group from a different project team.
  • Interview Round 1 (group A interviews group B): 20-30min
  • Take a short break for 5min. The interviewer group can use this time to clean up a bit their notes.
  • Interview Round 2 (group B interviews group A): 20-30min
  • The interviewer group in round 2 can use ~5min to clean up their notes. You can also do a quick debrief with your buddy group to discuss the interview process and feedback.

In each interview (since time is a bit limited):

  • Before the interview, agree on: interviewer’s focus scenario and the interviewee’s stakeholder role being played.
  • During the interview, aim for depth over breadth: one concrete workflow with good probing is better than ten shallow questions.