You can learn the technical side of business analysis in about 6 months.
Requirements templates, process notation, user stories, traceability matrices, gap analysis.
It’s all learnable, all documented, all fairly consistent from one organisation to the next.
What takes years is the other part.
Getting a room full of people who disagree to tell you what’s actually going on, then agree on what to do about it.
That’s the part that decides whether a project lands.
Here’s what I’d focus on if I were starting again.
👂 Listening is a skill, not a personality trait
Most people think they listen well.
Most people are waiting for a gap to ask their next question.
Real listening looks different in practice.
You stop planning your response, you let silences sit, you follow what the person actually said rather than your agenda.
One habit worth building.
When someone gives you a short answer, repeat their last few words back as a question.
“It goes to finance for checking.”
“For checking?”
Then wait.
They’ll almost always keep talking, usually straight into the detail you needed.
- You get the exceptions nobody documents
- You don’t steer them toward your assumptions
- You look interested rather than interrogating
It costs nothing, takes 2 seconds, works better than a page of prepared questions.
🏷️ Name the thing sitting in the room
Every project has an unspoken tension.
A team that’s been burned before.
A manager who thinks the whole thing is a waste of budget.
Someone who suspects this ends with their role being automated.
Pretending it isn’t there doesn’t make it go away.
It just makes people polite instead of honest.
Naming it gently is far more useful.
- “It sounds like the last system change didn’t go well here”
- “It seems like there’s some history I’m not across”
- “It looks like the timing on this is difficult for your team”
Say it, then stop talking.
Don’t fill the pause with reassurance.
If you’ve got it wrong, they’ll correct you, which is still useful information.
If you’ve got it right, the conversation gets noticeably more honest from that point on.
🤔 Ask questions that need thinking about
Yes or no questions get you yes or no answers, which tell you very little.
Better questions start with how or what.
- “How does this actually work when the system’s down?”
- “What’s the hardest part of this for your team?”
- “How would you handle it if we did it that way?”
- “What am I missing here?”
These do 2 jobs at once.
They get you richer information, they also hand the other person some control over the conversation.
People engage more when they feel like a participant rather than a data source.
That last question, “what am I missing”, is worth using often.
It gives experienced people permission to correct you without it feeling like a challenge.
✅ Chase “that’s right”, not “you’re right”
There’s a difference between these 2 responses that took me years to notice.
“You’re right” means the person wants the conversation to end.
Nothing’s been agreed, nothing will stick.
“That’s right” means you’ve described their situation accurately enough that they recognise it.
That’s real agreement, the kind that survives a steering committee.
So summarise before you finish any session.
Play back what you heard, in their words, including the messy bits they might expect you to leave out.
Then check.
If it comes back as “not quite”, you’ve just avoided documenting the wrong thing.
🙅 Make it safe for people to say no
New analysts chase agreement, which is a mistake.
Agreement given under pressure evaporates the moment you leave the room.
It’s better to make no easy, then see what you get.
- “Is this a bad time to be asking?”
- “Have you given up on this piece of work?”
- “Would it be a problem if I wrote it up the way I’ve described?”
That last one is useful.
Saying no to a wrong description feels low effort, almost automatic.
The correction usually comes with it, which is exactly what you were after.
People relax when they know refusing is an option.
Relaxed people tell you more.
⚖️ Let people say what feels unfair
When a stakeholder digs in, it’s rarely about the requirement itself.
It’s usually about a sense that a decision was made somewhere else, by people who won’t live with it.
Ask them directly what feels unreasonable about the current approach.
Then change something small in response, if you can.
Word gets around quickly when someone actually adjusts a design because a team raised a concern.
You stop being the person collecting requirements.
You become the person worth talking to.
🤝 Where this leaves you
Technique gets you into the role.
People skills are what make you good at it.
Nobody remembers the analyst with the tidiest requirements document.
They remember the one who understood their job, asked decent questions, gave them credit afterwards.
That reputation follows you into every project after this one.
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
