The Business Analyst's First Five Questions in a Technology Project

A solution is not a requirement

A stakeholder might ask for a new application when the real issue is a delayed approval, duplicated data entry or unclear responsibility. The analyst's job is to understand the outcome before helping a team decide whether software is needed.

Question one: What decision or action should improve?

Ask what people will do differently when the project succeeds. 'We need a dashboard' is a proposed tool. 'Supervisors need to identify overdue orders before dispatch' is a clearer business outcome.

Question two: Who experiences the problem?

Map the people using the process, those affected by it and those responsible for exceptions. Speak to frontline staff rather than relying only on a manager's summary. Differences between the official workflow and daily practice often reveal important requirements.

Question three: What happens today?

Walk through a real example from beginning to end. Identify each handoff, system and manual workaround. Measure waiting time or correction rates where defensible, and separate observations from assumptions.

Question four: What constraints matter?

Consider privacy, accessibility, cost, existing contracts, staff skills and offline access. A fast tool that exposes sensitive customer records may be a poor solution even if the interface looks modern.

Question five: How will we know it worked?

Agree on acceptance criteria and measures before implementation. What test cases demonstrate success, and who signs off? Include exceptional cases rather than only a perfect demonstration.

Make the analysis usable

Document a concise process map, a glossary and a list of prioritised user needs. A junior analyst can create immense value by making conflicting assumptions visible before development begins.

Action: Interview two people about the same workflow and write down where their descriptions disagree. That discrepancy is often the beginning of useful analysis.