Business Analysis Notes

Techniques BABOK Guide v3, 10.25

Interviews

5 min read · Updated

In short An interview is a planned conversation with one stakeholder, or a small group, to elicit information by asking questions and recording the answers. Done well, it uncovers goals, problems and workarounds that never appear in documents, and it builds the relationships the rest of your analysis depends on.

Based on: IIBA, BABOK® Guide v3, technique 10.25 “Interviews”; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 5; D. Leffingwell, D. Widrig, Managing Software Requirements, ch. 9; Yu. A. Maglinets, lecture notes (in Russian), lecture 3, retelling D. Marca and C. McGowan (SADT); H. Kastsevich, Requirements (sketchnote); D. Gobov, I. Huchenko, 2020 survey.

On this page

What it is#

Interviews are one-to-one or group. They can be structured, with questions written in advance, or unstructured: an informal conversation that, in Maglinets’s account, gets the respondent thinking creatively about an area the interviewer knows less well. Most real interviews mix the two.

In a 2020 survey of business analysts in Ukraine, Gobov and Huchenko found interviews and document analysis to be the most widely used elicitation techniques.

Match questions to the interviewee’s level#

The BCS book adjusts the questions to the interviewee’s position:

  • Strategic (senior managers): agree terms of reference and what management information they need.
  • Tactical (middle managers): targets, measures, controls and reporting; which processes run and who the key people are, but not the step-by-step detail.
  • Operational (people who do the work): exactly what happens today, problems and workarounds, documents used, bottlenecks. Treat their volume estimates with care and check them with data.

Ask context-free questions first#

Leffingwell and Widrig recommend starting with context-free questions: questions about the user’s problem that do not assume any solution, such as “Who is the user?”, “Who is the customer?” and “Do their needs differ?”. They keep you from steering answers toward what you already believe. Once the context is clear, add questions about a proposed solution.

When to use it#

Use interviews to understand individual goals and ways of working, to explore a domain early, to reach senior people, and for topics people will not raise in a group.

Use something else for numbers from many people (survey), group agreement (workshops) or a segment’s reactions (focus groups). The BCS book notes that people struggle to describe skills they perform automatically; for that, observation works better.

How to do it#

Prepare

  1. Choose who, and in what order. The sketchnote and the BCS book both suggest starting with the sponsor or senior people: they give context and open doors. Marca adds: pick people whose views really count, and agree in advance, ideally in writing, what each may decide, or a more senior stakeholder may later overturn what you were told.
  2. Set the purpose of each interview, from detailed requirements to building a relationship.
  3. Do your homework. Learn about the person and read relevant documents.
  4. Plan the questions. The BCS book suggests three areas: current functions the new solution must keep, current problems to fix, and new capabilities wanted. The last is usually the hardest, because it asks people to think beyond their experience. Plan your first question carefully; Marca notes it sets the tone.
  5. Book about an hour, which the BCS book and Marca both treat as a practical maximum. The BCS book suggests holding the first interview at the interviewee’s workplace: they feel at ease, documents are at hand, and you see the environment and its interruptions.

Conduct

  1. Open: introduce yourself, explain the project and the purpose of the interview, check the agenda and agree how you will take notes.
  2. Go from general to specific. Ask open questions. Never ask leading or yes/no questions; ask people to explain or summarize instead. Let them say what they want to say, not what you want to hear. If something is unclear, say so.
  3. Capture terms and relationships; a diagram or mind map makes good notes.
  4. Play back what you heard to confirm understanding.
  5. Close in time. Marca’s signals to wrap up: you have enough, answers stop being relevant, someone is overloaded or tired, or conflict is rising. Summarize, explain next steps and ask who else you should talk to.

Follow up

  1. Write up notes the same day, send them to the interviewee to confirm, and thank them.
  2. Log the top three needs. Leffingwell and Widrig suggest noting the three most important problems or needs after each interview; across a series, they converge into the core needs behind the requirements.

For group interviews, the sketchnote advises bringing a colleague to take notes, preparing an agenda, and meeting in person rather than on a group call.

Example#

The Workshop (a fictional chain of bike-repair workshops) is planning online booking. The analyst prepares to interview a workshop manager:

Text
Interviewee: Manager, central workshop (tactical and operational level)
Purpose:     How bookings and repairs flow today; problems and workarounds
Where/when:  At the workshop, Tuesday 9:00-10:00, before the morning peak
Read first:  Booking spreadsheet, job card form, last month's complaints

Open:          Who I am, project goals, agenda, how notes will be used
Context-free:  Who books repairs today? Who else depends on the schedule?
Current:       Walk me through a booking, from the phone call to the bike on the stand.
Problems:      Tell me about the last day when the schedule went wrong.
New:           If customers booked online, what would you need to see each morning?
Close:         Summary, next steps, "Who else should I talk to?"

Top three needs logged afterwards: see tomorrow’s bookings with bike types to plan mechanics; know when parts will arrive before promising a date; stop answering “Is my bike ready?” calls.

Common mistakes#

  • Leading or yes/no questions → ask open questions and let the interviewee explain.
  • Jumping to solutions → start context-free; discuss solutions later.
  • Only interviewing managers → cover strategic, tactical and operational levels.
  • Writing notes days later → write them up the same day and get them confirmed.
  • Unclear authority → agree whose word is final before you rely on an answer.

Checklist#

  • Interviewee, purpose and authority are clear; background reading is done.
  • Questions cover current functions, problems and new capabilities.
  • About an hour is booked, ideally at the interviewee’s workplace.
  • Opening, play-back and closing are planned.
  • Notes are written up the same day and sent for confirmation.
  • Top three needs and “who else to talk to” are recorded.

Sources and further reading#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.25 “Interviews”.
  • D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010, ch. 5 (levels of questioning, preparation, interview structure).
  • D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000, ch. 9 (context-free questions).
  • Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lecture 3.
  • D. A. Marca, C. L. McGowan. SADT: Structured Analysis and Design Technique (Russian edition, 1993), as retold by Maglinets (preparing, conducting and closing an interview).
  • H. Kastsevich. Requirements (sketchnote).
  • D. Gobov, I. Huchenko. State of Business Analysis in Ukraine 2020. DataArt, 2020.