How to Interview a Client When You're the Analyst on an IT Team (a Checklist)

When a team has no dedicated business analyst, client interviews often fall to the systems analyst. The job is not simply to record a list of requests. You need to understand the problem, its context, the constraints, and what a successful outcome would look like. This checklist covers the work before, during, and immediately after the conversation.

Step 1: Preparation

1.1 Review the available context:

• collect the product brief, current process maps, specifications, metrics, and previous decisions that are relevant to the topic;
• review the history of the initiative and identify the stakeholders;
• separate known facts from assumptions and open questions.

1.2 Define the goal of the interview:

• decide what decision or outcome the interview should support;
• prepare topics around the current process, desired outcome, users, constraints, priorities, and risks;
• keep the scope realistic. One interview rarely covers an entire product well.

1.3 Prepare useful working materials:

• bring notes, a process sketch, or a prototype if it will make the discussion more concrete;
• record the conversation only with explicit consent and in line with the company’s data-handling rules.

Step 2: Running the Interview

2.1 Set the frame:

• introduce the participants, explain the purpose of the meeting, and state the expected outcome;
• clarify who can make decisions and whose input still needs to be checked afterward.

2.2 Listen for the need behind the proposed solution:

• let the client describe the problem in their own words;
• when they propose a solution, ask what problem it solves and how that problem is measured today.

2.3 Ask clarifying questions:

• begin with open questions, then narrow the discussion;
• cover the main flow, alternatives, and failure paths;
• ask about data, integrations, quality attributes, dependencies, deadlines, and success measures where they matter.

2.4 Document the information:

• capture decisions, constraints, priorities, and unresolved questions;
• assign an owner and a due date to every follow-up action;
• close by summarizing what you heard and invite corrections.

Step 3: Analyzing What You Collected

3.1 Structure the material:

• separate business goals and user needs from solution requirements;
• link requirements to scenarios, constraints, and sources;
• do not turn every comment into an engineering task. Some points still need validation.

3.2 Check for gaps and contradictions:

• look for disagreements between stakeholders, ambiguous terms, and hidden dependencies;
• record risks, assumptions, and questions for other subject-matter experts;
• check whether the intended outcome can be understood and tested unambiguously.

Step 4: Feedback and Confirmation

4.1 Confirm your understanding:

• send a concise meeting note with decisions, open questions, and next steps;
• explicitly confirm anything that changes scope, architecture, timing, or commitments to users.

4.2 Update the team’s working artifacts:

• move confirmed information into the format the team actually uses: a backlog, specification, process model, or decision log;
• preserve the links between the need, requirement, acceptance criteria, and implementation work;
• make the material accessible to the people who will design, build, and verify the solution.

This process does not replace domain knowledge or interviewing experience, but it reduces the chance that important context disappears between the meeting and the backlog. Stay in contact with the client as the work progresses. New requirements do not always reshape the entire project, but their effect on scope, timing, cost, and risk should be assessed explicitly.

One request, four questions

Suppose a customer says: “We need an AI assistant so staff stop interrupting experts.” A technology has been named, but the problem is not yet defined. I would ask:

Question	What it reveals
Show three recent questions sent to an expert	Which real scenarios recur
Where did the employee look first?	Whether the issue is access, search, documentation, or judgement
What happens if the answer is wrong?	Where a suggestion is enough and where approval is required
How will we decide whether the pilot helps?	The outcome to compare with the existing process

An AI assistant may still be the right answer. Or the relevant documents may be inaccessible, contradictory, or insufficient without an expert’s authority. These are different problems, and a model does not automatically resolve them.

What remains after the meeting

A useful record connects a confirmed fact, its source, and an open question. For example: “Staff ask about the application procedure; the support lead provided examples; frequency and time spent still need measuring.” That is more precise than “everyone wastes time searching.”

The next step should test a specific assumption: collect anonymised requests, verify access, or run a sample search. The interview ends with a path to a justified decision rather than a promise to build everything mentioned.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP