There’s a version of business analysis that’s mostly solitary.
You read the old documents, you sit through a few meetings, you write up what you heard, then you send it around for comment.
It produces requirements that look fine on the page.
It also produces the requirement everyone signs off, nobody argues with, then quietly ignores once the system is live.
The difference between a document that holds up and one that doesn’t is rarely the template.
It’s how much real conversation went into it.
🗣️ Requirements live in people, not in documents
Nothing you need is written down anywhere.
The old procedure describes what should happen, not what does.
The system shows what’s possible, not what people actually use.
The policy states the rule, not the 3 situations a month where the rule doesn’t fit.
All of that sits in someone’s head, usually someone who’s never been asked properly.
So the skill isn’t documentation, it’s getting people to talk.
That means talking to more people than the project plan lists.
The named stakeholder gives you the official version.
The person doing the work daily gives you the real one.
The new starter tells you which bits were confusing, which is usually where the requirements need to be sharpest.
🔁 Let the silence do some work
Here’s a small habit worth building.
When someone gives you a thin answer, repeat their last few words back as a question, then stop talking.
“It just gets approved by the manager.”
“By the manager?”
Then wait.
Most people will keep going, usually straight into the part you needed.
“Well, technically.
But if he’s away it goes to the team leader, unless it’s over $10,000, then it has to wait.”
That’s 3 requirements you’d never have written from the first answer.
The pause feels awkward for about 2 seconds.
It’s worth sitting through, because people fill silence with detail.
🏷️ Name what’s going on in the room
Some stakeholders aren’t difficult, they’re carrying something you haven’t been told about.
A previous system change that went badly.
A worry that documenting their work is a step towards removing it.
Frustration at being the third project this year asking the same questions.
Pretending it isn’t there just makes people polite instead of useful.
Naming it clears the air quickly.
Something like “it sounds like you’ve been through this before, and it didn’t go well”.
Or “it seems like there’s some history here I’m not across”.
Say it gently, then stop.
Don’t rush in with reassurance, because the pause is what makes it land.
If you’ve read it wrong, they’ll correct you, which is still information.
If you’ve read it right, the conversation gets noticeably more honest.
🤔 Ask questions that need thinking about
Closed questions get you closed answers.
“Does the claim go to finance next?” gets a yes, which confirms your assumption without testing it.
Better questions start with how or what.
- “How does this work when the system’s down?”
- “What’s the hardest part of this for your team?”
- “How would you handle this if it were your call?”
- “What am I missing here?”
That last one earns its place in every session.
It gives experienced people permission to correct you without it feeling like a challenge.
They’ll tell you things they wouldn’t volunteer, because you’ve asked for them directly.
✅ Chase the right kind of agreement
There’s a difference between 2 responses that took me a while to notice.
“You’re right” means the person wants the meeting to end.
Nothing has been confirmed, nothing will stick, you’ll find out in UAT.
“That’s right” means you’ve described their situation accurately enough that they recognise it.
That’s the agreement that survives.
So summarise before you finish any session.
Play it back in their words, messy parts included, then check.
If it comes back as “not quite”, you’ve just avoided documenting the wrong thing.
Put the same summary at the top of the requirements document too.
Three or four plain lines describing what you understood.
Most people will read that properly even when they skim the rest.
🙅 Make it easy for people to disagree
New analysts chase agreement, which is a mistake.
Agreement given under pressure evaporates the moment you leave the room.
It’s better to make disagreement safe.
“Would it be a problem if I wrote it up the way I’ve described?”
Saying no to that is quick, low effort, almost automatic.
The correction arrives with it, which is what you actually wanted.
🤝 Where it lands
Templates and notation are learnable in a few months.
Getting a room full of people with competing priorities to tell you the truth takes longer.
That’s the part that decides whether the requirements hold up.
Collaboration isn’t a soft add on to business analysis.
It’s the method.
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
