Ask most people what a business analyst does and you’ll get an answer about documentation.
Writing specs, keeping the traceability matrix current, running things through a change control process.
That’s the visible part.
The part that actually determines whether a program lands is much less visible, which is sitting with people until you understand their work well enough to describe it back to them.
Get that right and the document mostly writes itself.
Get it wrong and you’ve produced a very tidy record of things nobody told you.
📄 Why the source material lets you down
Every project starts with a pile of existing material.
Procedures, policies, a process map from 2019, a spreadsheet somebody maintains privately.
It’s worth reading, though you shouldn’t trust it.
Here’s what that material typically gets wrong.
- Procedures describe the intended path, rarely the exceptions
- Policies state a rule without the cases where it’s quietly waived
- Old maps reflect a system that’s been upgraded twice since
- System configuration shows what’s possible, not what people use
- Private spreadsheets exist precisely because the official process doesn’t work
None of that is anyone’s fault.
Documents drift because work changes faster than documentation does.
Which means the current state lives in people’s heads, so that’s where you have to go.
👥 Talk to more people than the project plan names
The stakeholder list gives you the official contacts.
Useful for approvals, less useful for accuracy.
The version of the process a manager describes is usually the version they designed, not the version their team runs.
So widen the net.
- The person who does the task 40 times a day
- Whoever handles the complaints when it goes wrong
- Someone who joined 3 months ago, because they still remember what was confusing
- The team 2 steps downstream who receive the output
Four short conversations across those roles will give you a more accurate picture than 1 long session with the most senior person available.
🔁 Give people room to keep talking
A habit that gets better information than any prepared question list.
When an answer comes back thin, repeat the last few words as a question, then say nothing.
“It goes off to procurement for checking.”
“For checking?”
Then wait through the pause.
Almost always, they’ll continue.
“Well, in theory.
Under $2,000 we do it ourselves, though if it’s a new supplier it has to go through anyway, which takes about a week.”
That’s an exception, a threshold, plus a service level, none of which you’d have got from a yes or no.
The silence feels longer than it is.
Sit through it.
🏷️ Say the difficult thing yourself
Some resistance isn’t about you, it’s about what came before.
A rollout that went badly and got blamed on the wrong people.
The suspicion that mapping someone’s work is the first step to cutting it.
Weariness at being the third project this year asking identical questions.
Leaving that unspoken doesn’t remove it, it just makes people careful.
Putting it on the table works better.
“It sounds like the last change here didn’t go the way anyone hoped.”
“It seems like you’ve explained this a few times already.”
Offer it gently, then leave the pause alone.
Don’t soften it with reassurance straight away.
If you’re wrong they’ll correct you, which tells you something.
If you’re right, the conversation changes character within a minute.
🤔 Questions that open things up
Yes or no questions confirm your assumptions rather than testing them.
Swap them for questions that need thinking about.
- “What happens when this goes wrong?”
- “How would you design this if it were up to you?”
- “What takes the longest in your day?”
- “What am I missing here?”
That final one is worth using in every session.
Experienced people often hold back because correcting an analyst feels like criticism.
Asking directly gives them permission.
✅ The agreement that actually holds
Watch for the difference between 2 replies.
“You’re right” is a signal the person wants to move on.
Nothing has been confirmed, nothing will hold, you’ll find out at UAT.
“That’s right” means you’ve described their world accurately enough that they recognise themselves in it.
So finish every session with a summary.
Say it back in their words, including the awkward bits you might be tempted to tidy up.
Then check whether you’ve got it.
Put the same summary at the top of the requirements document, 3 or 4 plain lines, because most people will read that even when they skim the rest.
🙅 Let people push back easily
Chasing agreement is a trap.
Agreement given under time pressure disappears the moment the meeting ends.
Try this instead when something’s gone quiet.
“Would it be a problem if I wrote it up the way I’ve described?”
Saying no to that is easy, quick, almost automatic.
The correction comes attached, which was the point.
People who feel free to disagree tell you considerably more than people who feel cornered.
🤝 What it comes down to
The notation, the templates, the traceability, all learnable inside 6 months.
Getting people with competing priorities to tell you the truth about their work takes years.
That’s the part the requirements depend on.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
