If you are trying to figure out how to become a business analyst, the first thing I would tell you is this: stop preparing to prepare. The instinct to enrol in a course, book a certification, or spend three weeks perfecting your CV is understandable, but it is almost always the wrong first move. What actually gets you into this role is getting close to real BA work, producing real outputs, and building something concrete to talk about. Everything else follows from that. Here is the 90-day plan I would use if I were starting from scratch today, built on 25 years of BA practice across government, utilities, health, education, and enterprise environments.
What the role actually requires you to do
Most descriptions of the BA role say something about being a bridge between business and technology. That is accurate and almost completely useless as a starting point. What a BA does on a real project, on a Tuesday afternoon, is talk to people who have a problem, figure out what the problem actually is rather than what people say it is, and document what a solution needs to do so that someone else can build or implement it. That core loop is the job. Everything else, the diagrams, the workshops, the requirements documents, the stakeholder registers, exists to support that loop.
If you understand that loop, you can start doing useful BA work almost immediately. If you do not understand it, you can hold every available credential and still struggle to add value on a live project. Understanding the full scope of business analyst roles and responsibilities gives you a mental model to hang your early observations on, and that matters more in month one than any syllabus does.
Days 1 to 30: Get close to real work
The fastest way to understand what a BA does is to find somewhere BA work is happening and position yourself inside it. If you are already working in an organisation, that means volunteering for any project that has a BA, a project manager, or a business improvement function. Offer to take notes in meetings, maintain action logs, or draft a process map for something you already understand from your current role.
I started my career as a GIS analyst at a consulting firm. I was not a BA. But when a BA on a water licensing project needed someone to document the current state process, I put my hand up. I sat in the stakeholder interviews, took the notes, drafted the swim lane diagrams, and got feedback on every version. That single block of work taught me more about requirements elicitation than anything I read in the following twelve months.
If you are not currently in an organisation with BA activity, find it elsewhere. Local government, non-profits, and community organisations regularly run projects with no formal BA resource and a genuine need for someone who can structure a problem and document a requirement. The work does not need to be paid. It needs to be real.
Days 31 to 60: Build two skills deliberately
By the end of your first month you should have some sense of what BA work looks like in practice. Now you target two specific skills that will make you immediately useful on any project.
- Requirements elicitation: This is the ability to ask questions that surface what a stakeholder actually needs rather than what they say they want. The gap between those two things is where most project failures begin. Start by reading about elicitation techniques, then practise them on something real. Interview a colleague about a process they find frustrating. Write down what they say. Then ask why five times and observe what changes. The answer is almost never what you started with.
- Process documentation: This is the ability to take what you observe or hear and represent it clearly in a format other people can use. A simple swim lane diagram showing who does what and in what order is more useful than a twenty-page narrative on most projects. Learn to draw one. Tools like Lucidchart or even PowerPoint are fine. The thinking matters more than the tool.
Spend this month doing both of those things on whatever project or volunteer work you have access to, and ask for feedback on every output you produce. Feedback is the only mechanism that closes the gap between trying and improving. If you want to understand how core BA skills map to real project situations, that is worth reviewing alongside your practical work during this phase.
Days 61 to 90: Write your first BRD and build your evidence base
By day 60 you should have real work to point to. Now you do two things: write a Business Requirements Document, and start turning your outputs into an evidence base for job applications.
Writing a BRD for the first time is genuinely hard. The structure is learnable. Knowing what quality looks like in each section is not obvious without experience. I have seen junior BAs produce documents that had all the right headings and almost no usable content, because they documented what stakeholders said rather than what the business needed.
The friction I hit on my own first real BRD came in the scope section. I had written a scope statement that was technically accurate but so vague it was meaningless. The project manager read it and told me it did not exclude anything. She was right. I had listed what was in scope without being specific enough for anyone to use it to push back on a change request. I rewrote that section three times before it was tight enough to serve its purpose. That experience is why I now spend more time on scope than on any other section of a BRD. If you want to understand how the BRD relates to other document types before you start, the comparison between a BRD and a Functional Requirements Document is worth a quick read.
Use the table below to understand what each section of a BRD needs to do and where first-time writers most commonly go wrong.
| BRD Section | What it needs to do | Common first-timer mistake |
|---|---|---|
| Document purpose | Explain why this document exists and what decision it supports | Written as a project description rather than a document purpose |
| Scope | Define what is included and explicitly what is not | Too vague to be used as a change control tool |
| Business context | Explain the problem being solved and why it matters now | Copied from the project brief without analysis |
| Stakeholder summary | Identify who has influence over the solution and what they need | Listed by name rather than role, outdated within weeks |
| Functional requirements | Describe what the solution must do in business terms | Written at too high a level to be testable |
| Non-functional requirements | Define performance, security, and quality constraints | Left blank or copied from a previous project |
| Assumptions and constraints | Document what is being treated as true and what limits the solution | Left empty, creating disputes later |
For your evidence base, take every piece of work you have produced across the 90 days and document it in a simple portfolio. A process map you drew. A set of requirements you elicited. A BRD you drafted. A workshop you supported. Even if the work was unpaid or informal, it is real. Describe each piece in terms of the business problem, your contribution, and the outcome. That framing is what turns volunteer work into interview material.
Where certifications fit in
I am not against certifications. The ECBA from the IIBA is a reasonable credential for someone starting out, and it gives you a structured framework for understanding the profession. But I would not pursue it in the first 90 days. I would pursue it after I had real work to contextualise what I was studying, because certifications mean more when you can connect the concepts to things you have actually done.
The question hiring managers ask when they see an entry-level certification is always the same: what have you done with it? If your answer is nothing yet, the credential does not move you forward. If your answer is that you used MoSCoW prioritisation in a requirements workshop and here is what happened, the certification becomes evidence of intentional learning rather than credential collection. If you are weighing up your certification options, the ECBA overview on this site covers what the credential involves and whether the timing is right for you.
What the job actually rewards
The BA role rewards people who are genuinely curious about how things work and why they do not work better. It rewards people who can sit with ambiguity, ask a question they do not know the answer to, and write it down clearly enough that someone else can act on it. None of that requires a degree or a certification. It requires practice on real problems. The sooner you find real problems to work on, the faster everything else follows.
Frequently asked questions
How long does it take to become a business analyst?
Most people can do useful BA work within three to six months of focused effort on real projects. Getting your first paid BA role typically takes six to twelve months depending on your starting point and how much real work experience you can build in the meantime. The single biggest factor is how quickly you get access to genuine BA activity rather than study alone.
Do I need a degree to become a business analyst?
No, a degree is helpful but not required. Hiring managers care more about whether you can demonstrate core skills: requirements elicitation, process documentation, stakeholder communication, and structured thinking. A portfolio of real work consistently outperforms a degree with no practical application behind it.
What is the best certification for a new business analyst?
The ECBA from the IIBA is the most widely recognised entry-level credential for aspiring BAs. Pursue it after you have some practical exposure so the concepts connect to real experience rather than sitting in isolation. Certifications carry more weight in interviews when you can link them to specific work you have done.
Can I become a business analyst without an IT background?
Yes, and many of the strongest BAs I have worked with came from non-technical backgrounds including social work, teaching, and administration. The core skills are analytical thinking and structured communication, not technical knowledge. You will pick up enough technical understanding on the job as long as you stay curious.
What should I put in a BA portfolio if I have no experience?
Volunteer for projects in your current organisation or community, document a process you know well, or write a requirements document for an improvement you have identified somewhere. The work does not need to be paid, it needs to be real and described in terms of the business problem and your specific contribution. That framing is what makes informal work credible in an interview.
Try Ash, Your Virtual BA
If you are working on your first BRD as part of building your portfolio, Ash can guide you through it section by section. Rather than staring at a blank template wondering whether your scope statement is tight enough or your requirements are written at the right level of detail, Ash asks you the same questions a senior BA would ask in a discovery session and builds the document as you answer them. It is the most practical next step you can take after reading this article. Try Ash Virtual BA.
Further reading
- How to become a Business Analyst? | IIBA® Business Analysis Blog
- How to Become a Business Analyst? | IIBA®
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.