Do Business Analysts Need a Portfolio? What to Include and How to Build One
A recruiter at a London-based consultancy told me about a hiring round last year for a junior BA position. Forty-two candidates made the phone screen. All had reasonable resumes. Most had an ECBA or were studying for one. A few had relevant master's degrees.
One candidate — a former hotel operations manager — emailed a follow-up after her phone screen. She attached a two-page PDF: a stakeholder register and a requirements document she had built from a case simulation. Five stakeholders with tailored engagement strategies. Seven functional requirements with testable acceptance criteria and MoSCoW prioritization. A scope statement that explicitly addressed a conflicting stakeholder dynamic.
The recruiter forwarded it to the hiring manager with one line: "This one actually did the work."
She got the offer. Not because the artifacts were flawless. Because she was the only candidate out of forty-two who showed deliverables instead of just describing skills.
Developers have GitHub. Designers have Dribbble. Data analysts have Tableau Public. Business analysts have no standard platform for proving they can do the work. Most BA applications are a resume, a cover letter, and a certification logo. The hiring manager takes your word for it.
That is a problem for everyone. But it is an enormous opportunity for you. Because while experienced BAs rely on job titles and years of tenure to signal competence, you can do something most of them never bother to: show the actual work.
This guide covers whether you need a portfolio (you do), what goes in it, how to create portfolio-worthy artifacts when you have no clients, and what hiring managers are actually evaluating when they look at your work.
The Short Answer: Yes, You Need One
Let me make the case with a hiring manager's reality.
A junior BA posting at a mid-size company receives 80 to 200 applications. Perhaps 30% meet the basic qualifications. The hiring manager needs to narrow those 50 resumes to 8 phone screens. Every resume claims communication skills, analytical thinking, and stakeholder management. Every resume lists Jira and Confluence in the skills section.
Now imagine one of those 50 resumes includes a line at the bottom: "BA Portfolio: Three case-based projects with stakeholder registers, requirements documents, and process models available at [link] or upon request."
That resume goes into a different pile. Not because the portfolio proves the candidate is brilliant, but because it proves the candidate is serious. They have invested time in producing deliverables. They understand what BA work looks like in practice. And they are confident enough to show it.
In a 2025 survey by the IIBA, hiring managers were asked what they valued most when evaluating entry-level BA candidates. Certifications ranked third. Relevant experience ranked first (obviously). Demonstrated ability to produce BA deliverables ranked second. A portfolio is how you demonstrate that ability when your experience column is empty.
What a BA Portfolio Is Not
A portfolio is not a collection of your training certificates. It is not screenshots of Jira boards. It is not a list of tools you know how to use.
A portfolio is a set of artifacts — documents and diagrams you have created — that demonstrate structured thinking applied to a business problem. Each artifact should show that you can take messy, ambiguous, conflicting information and turn it into something clear, organized, and actionable.
It is also not a 40-page document. Hiring managers will spend five to ten minutes on your portfolio at most, probably during the window between your phone screen and your in-person interview. Two to three focused projects with clean, readable artifacts will outperform ten superficial ones.
The Five Artifacts That Matter
Not all BA deliverables carry equal weight in a portfolio. Based on what hiring managers actually ask about in interviews, and what junior BAs produce in their first 90 days, here are the five artifacts that matter most.
1. Stakeholder Register
This is the first thing many interviewers ask about: "How did you identify your stakeholders?"
A strong stakeholder register includes each stakeholder's name, role, department, interest level, influence level, and attitude (supportive, neutral, resistant). But what separates a good register from a great one is the engagement strategy column. Anyone can list stakeholders. The BA skill is knowing what to do with each one.
A weak engagement strategy says: "Keep informed via email updates." A strong one says: "Schedule a pre-budget meeting to present ROI analysis before the formal review, addressing her concern about expenditures above the $75,000 threshold. Frame recommendations as phased investments with measurable milestones."
The difference is specificity. The first could be copied from a template. The second demonstrates that you have read the evidence, understood the stakeholder's motivations, and designed an approach that addresses their specific concern.
In your portfolio, include stakeholder registers from at least two different case scenarios. This shows range. One project might have five stakeholders with straightforward dynamics. Another might involve conflicting priorities, a resistant executive, and a budget constraint that forces trade-offs. The second scenario is the one that will generate interview questions.
2. Requirements Document
This is the core BA artifact. A requirements document that demonstrates clarity, structure, and traceability tells a hiring manager more about your capability than anything else in your portfolio.
What to include: a purpose and scope statement that defines what the project will and will not address, functional requirements with unique identifiers (FR-001, FR-002), non-functional requirements with measurable targets (not "the system should be fast" but "search results should return within 3 seconds for databases up to 50,000 records"), MoSCoW prioritization with rationale for each priority level, acceptance criteria that are testable, and a traceability column linking each requirement back to the stakeholder or evidence source it came from.
The scope statement is particularly important for career switchers to get right. In real projects, the biggest BA failure is scope creep. A well-written scope statement in your portfolio signals that you understand this. If your case scenario involves a stakeholder pushing for a complete system replacement while the project sponsor wants focused improvements, your scope statement should acknowledge that tension and explain the decision.
3. Use Case Model
Use cases show that you can think through how a user actually interacts with a system, including what happens when things go wrong.
A strong use case includes a primary actor, preconditions, a main flow with six to eight numbered steps, at least two alternate flows (what happens when the search returns no results? What happens when multiple records match?), postconditions, and business rules with specific thresholds.
The alternate flows are where you demonstrate analytical depth. The main flow is the happy path — anyone can document that. The alternate flows show you have thought about edge cases, error handling, and user frustration points. These are the scenarios that become bugs and support tickets when nobody documents them, and hiring managers know it.
4. Process Model (BPMN or Flowchart)
A visual artifact breaks up the text-heavy nature of a BA portfolio and demonstrates a different skill: the ability to map how work flows across roles and systems.
Include at least one current-state ("as-is") and one future-state ("to-be") process model. The as-is model documents how things work today, including the inefficiencies. The to-be model shows how they should work after your recommendations are implemented. The gap between the two is where the business value lives.
Use standard BPMN notation if you know it, or a clear swimlane diagram if you do not. Label every decision point. Show handoffs between roles. Annotate the bottlenecks or pain points you identified.
What makes a process model portfolio-worthy is annotation. A bare diagram says you know how to use Lucidchart. A diagram with callouts explaining "this handoff adds 3 days to the process because the approval is manual and the approver is in a different timezone" says you understand the business problem behind the process.
5. Analysis Summary or Recommendation Brief
This artifact ties everything together. It is a one-to-two-page document that summarizes your analysis and makes a recommendation.
Structure it as: the business problem (two to three sentences), key findings from discovery (what the evidence revealed), your analysis (root causes, conflicting priorities, constraints), your recommendation (what to do and why), and implementation considerations (phased approach, budget implications, risks).
This document demonstrates the skill that matters most in a BA career: the ability to synthesize information from multiple sources into a clear recommendation that a decision-maker can act on. It is the artifact that most directly answers the interview question "walk me through how you would approach this problem."
"But I Have No Client Work"
This is the career-switcher objection, and it is the wrong framing.
Junior developers build portfolio projects without clients. They build a to-do app, a weather dashboard, a personal blog. Nobody asks "but did a real client pay you to build that to-do app?" The portfolio proves they can write code. The client comes after.
Business analysis works the same way. The portfolio proves you can produce deliverables. The client project comes after the hire.
The most effective way to build portfolio artifacts without client work is through case simulations. These are structured scenarios that put you in the BA seat for a realistic business problem. You receive a briefing, review evidence (emails, meeting notes, stakeholder interviews, data), conduct analysis, and produce deliverables.
The key is realism. A case simulation that gives you a vague prompt like "document requirements for a CRM system" produces weak artifacts because there is no evidence to work with. A simulation that gives you five stakeholders with different priorities, email correspondence with specific data points (14.2-second search response time, 8,000 duplicate records, a $75,000 budget ceiling), and interview transcripts with conflicting perspectives produces artifacts that look like real work — because the thinking required is real.
This is, incidentally, how I would build a portfolio from scratch if I were switching careers today. I would find a structured case scenario — the kind where you get a briefing, review actual evidence documents, work through a discovery and analysis process, and produce deliverables that get evaluated. BAvolta's Case Lab is built around exactly this workflow: you step into a BA role on a realistic project, produce the artifacts, and get AI-powered feedback on what is strong and what needs work. But the principle applies regardless of the tool. The scenario needs to be detailed enough that your artifacts require genuine analytical thinking, not just template-filling.
You can also build your own scenarios. Pick a business problem you understand from personal experience. Your gym's booking system is terrible? Document the requirements for a better one. Your apartment building's maintenance request process is chaotic? Map the current workflow, interview a few residents (with their permission), and write a recommendation brief. The scenario does not need to be complex. It needs to demand structured thinking.
Your Portfolio Is Your First BA Project
Here is the insight that most portfolio guides miss entirely: the process of building a portfolio is itself a business analysis exercise.
Think about it. You need to understand your stakeholder (the hiring manager) and what they value. You need to gather requirements (what artifacts do they expect? what level of detail?). You need to prioritize (which projects go in, which stay out). You need to present information clearly and professionally (documentation). And you need to manage scope (two to three strong projects, not eight mediocre ones).
If your portfolio demonstrates good BA thinking in its content AND in its structure, you have proven the skill twice without the hiring manager even realizing it. A portfolio with a clear table of contents, consistent formatting, one-paragraph context for each project, and artifacts organized from most impressive to supporting detail — that is a BA who understands information architecture. A portfolio that dumps twelve unformatted documents into a Google Drive folder is a BA who will produce the same chaos on your project.
This reframe should change how you approach the entire exercise. You are not "making a portfolio." You are producing a deliverable for a stakeholder with specific needs and limited time. That is the job.
How to Present It
The format matters less than the structure. A simple website, a curated PDF, or a Notion page can all work. What matters is how you organize the information.
Every project in your portfolio needs three things. First, a context paragraph: what was the scenario, what was the business problem, what was your role. This is the equivalent of a project brief — it orients the reader before they see the artifacts. Second, the artifacts themselves: clean, professionally formatted, with clear labels. Third, a reflection note: one to two sentences on what you would do differently or what you learned. This signals self-awareness, which is a trait hiring managers value in junior BAs because it predicts how quickly you will improve.
Order your projects strategically. Lead with the one that best matches the industry or role type you are targeting. If you are applying to a financial services company, put the CRM enhancement case first. If you are applying to a healthcare organization, lead with any health-related scenario.
Keep the total portfolio under 15 pages if it is a PDF, or under four scrolls if it is a website. Hiring managers spend five to ten minutes on a portfolio. Respect their time and they will respect your work.
What Hiring Managers Actually Evaluate
When a hiring manager opens your portfolio, they are not grading it like a professor. They are looking for three signals.
Signal 1: "This person can organize complexity." If your requirements document is well-structured with clear identifiers, consistent formatting, and logical grouping, the hiring manager sees someone who can bring order to chaos. If the document is a stream-of-consciousness paragraph with no structure, they see someone who will create more confusion than they resolve.
Signal 2: "This person uses evidence, not assumptions." If your stakeholder engagement strategy references specific concerns from the evidence ("Diana's primary concern is ROI for expenditures above $75K, so we will present a cost-benefit analysis before the formal budget review"), the hiring manager sees someone who grounds their decisions in data. If your strategy is generic ("maintain open communication with all stakeholders"), they see someone who fills in templates without thinking.
Signal 3: "This person understands trade-offs." Business analysis is fundamentally about trade-offs. Budget versus scope. Speed versus quality. One stakeholder's priority versus another's. If your portfolio shows you identifying a conflict (stakeholder A wants a full system replacement, stakeholder B wants focused improvements) and recommending a resolution with rationale (focused improvements now with the replacement documented as a Phase 2 consideration, supported by timeline and budget constraints), the hiring manager sees someone who can navigate real project dynamics.
These three signals matter more than the length of your portfolio, the specific tools you used, or whether the scenario was real or simulated. A two-project portfolio that demonstrates all three signals will outperform a five-project portfolio that demonstrates none of them.
The Interview Connection
Your portfolio is not just a resume attachment. It is interview preparation material.
Every artifact in your portfolio is an answer to an interview question you have not been asked yet. "How do you handle conflicting stakeholder requirements?" Point to your stakeholder register where two stakeholders had opposing views and explain your engagement strategy. "How do you write testable requirements?" Open your requirements document and walk through three acceptance criteria, explaining why each one is specific and measurable. "How do you decide what's in scope?" Show your scope statement and explain the trade-off you made.
Prepare to discuss every artifact in your portfolio as if you produced it last week. You should be able to explain why you made every decision: why you prioritized this requirement as "Must Have" and that one as "Should Have," why you chose this engagement approach for a resistant stakeholder, why your use case includes that specific alternate flow.
The combination of a portfolio and the ability to discuss it intelligently is the career-switcher equivalent of three years of on-the-job experience. It is not a perfect substitute. But it is enough to get hired by a manager who values thinking over tenure.
The Minimum Viable Portfolio
If you are overwhelmed by the scope of what I have described, start here. A minimum viable portfolio for your first BA job application needs two projects with three artifacts each:
Project 1: A stakeholder register (4 to 5 stakeholders with specific engagement strategies), a requirements document (5 functional requirements with acceptance criteria, 2 non-functional requirements), and a use case model (1 primary use case with at least 1 alternate flow).
Project 2: A different scenario. A stakeholder register, a process model (current state and proposed state), and a recommendation brief summarizing your analysis and proposed approach.
Two projects, six artifacts. That is enough to demonstrate range, structured thinking, and the ability to produce professional BA deliverables. Build from there as you complete more training or gain real project experience.
Start Building
A certification tells a hiring manager you have studied business analysis. A portfolio tells them you have practiced it. In a field where the entire job is about producing clear, structured, evidence-based deliverables, there is no better proof of capability than showing you have already produced them.
You do not need a client to build one. You do not need years of experience. You need a realistic business scenario, the discipline to work through it rigorously, and the professionalism to present your artifacts clearly.
The career switchers who get hired are not the ones who studied the hardest. They are the ones who produced the most evidence.
BAvolta's Case Lab puts you through realistic BA scenarios and you produce the exact artifacts described in this guide — stakeholder registers, requirements documents, use cases, and more. Your work is reviewed with AI-powered feedback so you know what's strong and what needs improvement. The BA Fundamentals course covers the underlying skills. Module 1 is free.