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

A common question: what do you do when there's no business analyst on the IT team? It might seem like the difference is tiny — whether they're there or not — but it's not that simple. A few months ago I started a Telegram channel to share my take on the underside of IT: the stuff that usually hides behind the pretty words about a friendly team and corporate training. I've spent most of my career working as an analyst, so I'm speaking from experience.

From here on I'm assuming that by default you're a systems analyst and there's no business analyst on the team — which means client interviews land on you. Let's walk through a step-by-step algorithm: how I see it and what I pay attention to myself.

Step 1: Preparation

1.1 Study the available information:

• gather every document you have about the project and the client: business plan, technical specs, current business processes, and so on;
• get familiar with the history of the relationship with the client and past projects, if there are any;

1.2 Define the goal of the interview:

• decide what you want to learn from the client at this stage;
• put together a list of questions and topics to discuss;

1.3 Prepare the materials you'll need:

• get a notebook, a voice recorder, presentations or diagrams ready — anything that will come in handy during the interview;

Step 2: Running the Interview

2.1 Build rapport and trust:

• start with a short round of introductions and create a friendly atmosphere;
• explain the goal of the interview and what outcomes you're hoping to get;

2.2 Listen carefully:

• give the client room to talk freely about their needs and expectations;
• don't interrupt and don't jump to conclusions before the client has finished;

2.3 Ask clarifying questions:

• dig into the details. Start with open questions that invite a full answer, then narrow things down with pointed ones where the answer comes down to "yes" or "no";

2.4 Document the information:

• capture the key points — clearly and in a structured way;
• write down the requirements, constraints, priorities, and deadlines the client mentioned;

Step 3: Analyzing What You Collected

3.1 Organize the information:

• after the interview, organize everything you collected into structured documentation;
• build a list of requirements and tasks based on what you heard from the client;

3.2 Analyze and interpret the data:

• identify the client's key points, requirements, and goals;
• spot the potential risks and problems that could come up over the course of the project;

Step 4: Feedback and Confirmation

4.1 Confirm the data you gathered:

• reach out to the client to clarify and confirm the requirements and data you collected;
• make sure all sides understand and agree on the results of the interview;

4.2 Produce the documentation:

• put together a document covering the client's requirements and expectations;
• make sure the document is easy to read and accessible to everyone on the team.

This algorithm brings structure to the interview and helps you pull out of the client the things a project can't move forward without. And it works well beyond IT — anywhere there's a client and a contractor. Keep in touch with the client throughout the whole project: requirements will change, and new ones will show up. Just remember the golden rule — every new requirement shifts the entire scope of work along with it.

Thanks, everyone, and see you next time!

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP