Search for business analyst portfolio examples and you will find a dozen articles telling you to include a stakeholder register, some process diagrams, and a requirements document. Almost none of them show you one.
That is the whole problem. You already know a portfolio should contain artifacts. What you cannot tell, sitting at your kitchen table on a Tuesday night after your actual job, is whether the thing you just wrote is any good. Is your stakeholder register the kind a hiring manager nods at, or the kind that gets you a polite rejection?
So this article does the thing the others do not. Below is one complete portfolio project, written out in full. Same fictional company throughout, five linked artifacts, including the assumptions and open questions that most templates leave out. Copy the structure, replace the domain with something you know, and you have a portfolio piece.
If you are earlier in the process and still deciding whether a portfolio is worth building at all, start with do business analysts need a portfolio and come back here.
What a hiring manager actually looks at
Before the example, it helps to know what you are optimising for. The scan takes about ninety seconds and it goes roughly like this:
- Is there a business problem, stated in numbers? Not "improve the booking process." Something with a baseline and a target.
- Do the requirements trace back to that problem? A requirements list floating free of any stated need reads as an exercise. A requirement you can walk backwards to a business objective reads as work.
- Are there assumptions and open questions? This is the single strongest signal. Real analysis happens with missing information. A document with no unknowns in it was written from a template, not from thinking.
- Did you make a decision anyone could disagree with? Ranking a waitlist by wait duration rather than by revenue is a choice. Choices are what you get interviewed about.
- Is it finished? One project taken all the way through beats five that stop after the stakeholder register.
Notice what is not on that list: volume, polish, tooling. Nobody is grading your diagram software.
The project brief
Everything below is built on one simulated engagement. Simulated, and labelled as such, which matters and which I come back to later.
Meridian Dental Group operates 14 clinics. Across the group, 14% of booked appointments end in a no-show. Each missed 45-minute slot represents roughly 180 EUR of lost chair revenue. The Clinical Director wants the no-show rate at or below 8% within two quarters. There is no budget for additional front desk headcount. The practice management system, DentiSoft, is staying.
That is four sentences and it already gives you a measurable objective, a constraint, and a fixed system boundary. If you write your own brief, spend the time to get this paragraph right. Everything downstream inherits its quality.
Artifact 1: Stakeholder register
The mistake in most portfolio stakeholder registers is that they list people. A register that lists people is a contact sheet. A register that records what each person needs and how you plan to work with them is analysis.
| Stakeholder | Role in the change | Influence | Attitude | What they need from me | Engagement approach |
|---|---|---|---|---|---|
| Dr. Anita Rasmussen | Clinical Director, project sponsor | High | Supportive | Confidence the target is reachable and that clinical quality is untouched | Fortnightly 30-minute update, decisions escalated here |
| Marcus Bell | Regional Operations Manager | High | Neutral | Proof this does not add work to clinic managers | Walkthrough of the to-be process before sign-off |
| Priya Shah | Front Desk Lead, Sunnyvale clinic | Low formal, high practical | Skeptical | To be consulted, not informed. She has been asked about no-shows twice before with nothing changing | Two shadowing sessions, co-design the front desk queue with her |
| Tomas Lind | IT Manager, two-person team | Medium | Resistant | A realistic estimate of his team's involvement, early | Named as reviewer on integration requirements, no surprises |
| Wendy Okafor | Group Controller | Medium | Supportive | The 180 EUR figure defended, and a cost line for messaging volume | One-page cost and benefit note before budget approval |
| Dental hygienists (6 represented) | Affected by schedule changes | Low | Mixed | Predictability. Filled slots must not arrive without notice | Represented via clinic managers, one direct session |
| Patients, 25 to 40, working | Primary user segment | None | Unaware | A way to reschedule that does not involve phoning during work hours | Five interviews, recruited from recent no-shows |
| Patients, 65+ | Second user segment | None | Unaware | Not to be pushed onto channels they do not use | Three interviews, channel preference is a hard question |
| DentiSoft account manager | Vendor, API owner | Medium | Unknown | A clear written integration request | Contact via Tomas, not directly, to protect the relationship |
Two things to point out, because they are the parts you should steal.
First, Priya's row. "She has been asked about no-shows twice before with nothing changing" is not a field in any template. It is the sort of thing you only learn by asking, and putting it in the register tells a reader you did. Change fatigue is a real risk on this project and it is now visible.
Second, the two patient segments are separated. Collapsing all patients into one row would have hidden the most interesting requirement in the whole project, which is the channel default in FR-07 below.
For the techniques that produce this kind of detail, see the five requirements elicitation techniques post.
Artifact 2: As-is process and problem analysis
Short, numbered, with pain points tagged so requirements can reference them later. You do not need a beautiful diagram. You need a traceable one.
As-is: appointment reminder and no-show handling
- Patient books at reception or by phone. Receptionist enters the appointment into DentiSoft.
- DentiSoft sends one automated SMS 24 hours before the appointment. [PP-01]
- The SMS is one-way. There is no way for the patient to confirm, reschedule, or cancel from it. [PP-02]
- If the patient does not arrive, the receptionist marks the appointment as a no-show manually, sometimes at the end of the day, sometimes not at all. [PP-03]
- The slot stays empty. No one is called, because no waitlist exists in any usable form. [PP-04]
- Monthly, the clinic manager exports a no-show report. The numbers are known to be under-counted because of step 4. [PP-05]
Pain point summary
| ID | Pain point | Consequence |
|---|---|---|
| PP-01 | Single reminder, 24 hours out | Too late to rebook the slot even if the patient responds |
| PP-02 | One-way messaging | Patients who know they cannot attend have no low-friction way to say so |
| PP-03 | Manual no-show marking | Front desk workload at the busiest moment of the day |
| PP-04 | No waitlist | Every cancellation is a permanently lost slot |
| PP-05 | Unreliable reporting | The 14% baseline is itself suspect, likely understated |
PP-05 deserves a comment, because this is the sort of finding that gets talked about in an interview. The project's own baseline metric comes from a process the analysis has just shown to be unreliable. That does not stop the project. It does mean the first measurement after go-live will not be comparable to the baseline, and the sponsor needs to hear that before, not after.
Artifact 3: Requirements
Numbered, layered, and traceable in both directions. Business requirement at the top, stakeholder requirements beneath, then functional and non-functional requirements that each point back to a pain point.
Business requirement
BR-01 Reduce the group no-show rate from 14% to 8% or lower within two quarters of go-live, without additional front desk headcount.
Stakeholder requirements
| ID | Requirement | Source |
|---|---|---|
| SR-01 | Front desk staff must be able to fill a cancelled slot without making outbound calls one at a time | Priya Shah |
| SR-02 | Patients must be able to confirm, reschedule, or cancel without phoning the clinic during opening hours | Patient interviews, 25 to 40 segment |
| SR-03 | Operations must see no-show rates by clinic, weekday, and appointment type, refreshed daily | Marcus Bell |
| SR-04 | Clinicians must not have slots filled without notice appearing in their day | Hygienist session |
Functional requirements
| ID | Requirement | Traces to |
|---|---|---|
| FR-01 | The system shall send an appointment reminder at 72 hours and again at 24 hours before the scheduled start time | PP-01, BR-01 |
| FR-02 | Each reminder shall include a single-use link allowing the patient to confirm, reschedule, or cancel the appointment | PP-02, SR-02 |
| FR-03 | When a patient cancels 24 hours or more before the start time, the system shall release the slot to the waitlist queue for that clinic and appointment type | PP-04, SR-01 |
| FR-04 | The system shall offer a released slot to up to five matching waitlist patients simultaneously, with a 90-minute response window, and shall book the first patient to accept | PP-04, SR-01 |
| FR-05 | The system shall set appointment status to No-show automatically 20 minutes after the scheduled start time when no check-in has been recorded | PP-03, PP-05 |
| FR-06 | The system shall provide a no-show report segmented by clinic, weekday, and appointment type over a rolling 90 days, refreshed daily | PP-05, SR-03 |
| FR-07 | Patients with no recorded channel preference shall receive SMS. Patients flagged as no-SMS shall receive email. No patient shall be contacted on a channel they have opted out of | SR-02, 65+ segment |
| FR-08 | When a slot is filled from the waitlist, the assigned clinician's schedule view shall show the new booking with a "filled from waitlist" marker | SR-04 |
Non-functional requirements
| ID | Requirement | Rationale |
|---|---|---|
| NFR-01 | 99% of reminder messages shall be dispatched within five minutes of their scheduled send time | A late 24-hour reminder is worse than none |
| NFR-02 | Patient-facing links shall expire 30 minutes after the appointment start time and shall expose no clinical information beyond date, time, clinic, and appointment type | GDPR, health data minimisation |
| NFR-03 | The waitlist offer flow shall be fully usable in a mobile browser with no app installation | Both patient segments, adoption risk |
Assumptions, constraints, and open questions
This is the section that separates a portfolio from a template, so do not skip it.
- Assumption: DentiSoft exposes an appointment write API. Unconfirmed. Owner: Tomas Lind. If false, FR-03 through FR-05 need redesign and the timeline moves.
- Assumption: The 180 EUR per-slot figure is contribution, not gross revenue. To be defended with Wendy Okafor before it appears in any business case.
- Constraint: No additional headcount. This is why FR-05 automates the status change rather than adding a front desk step.
- Constraint: Messaging cost scales with FR-01 doubling reminder volume. Cost line needed before approval.
- Open question: If a patient reschedules, may they land with a different clinician? Clinically this may matter for treatment-in-progress. Escalated to Dr. Rasmussen, blocking FR-02.
- Open question: Should patients with repeated no-shows be excluded from waitlist offers? Proposed business rule BR-15 below, not yet agreed.
- Out of scope: Billing changes, annual recall campaigns, and online booking for new patients.
Artifact 4: Use case
One use case, written properly. Not eight written thinly. This one covers the most interesting flow in the system, which is also the one with the most ways to go wrong.
UC-03: Claim a released appointment slot
Primary actor: Waitlist patient Supporting actors: Scheduling service, DentiSoft PMS, front desk queue Preconditions:
- The patient has an open waitlist entry for a given clinic and appointment type
- The patient has a verified contact channel
- A slot has been released (see UC-02) at least 24 hours before its start time
Trigger: A slot is released to the waitlist queue.
Main flow
- The system identifies waitlist entries matching clinic, appointment type, and clinician availability.
- The system ranks matching candidates by waiting duration, longest first.
- The system sends a slot offer to the top five candidates simultaneously and opens a 90-minute response window.
- The patient opens the offer link.
- The system displays the slot: date, time, clinic, appointment type, clinician.
- The patient selects Accept.
- The system verifies the slot is still unclaimed.
- The system books the appointment in DentiSoft and closes the waitlist entry.
- The system sends a confirmation to the patient and withdraws the four outstanding offers.
- The system posts the booking to the clinic's front desk queue and marks the clinician's schedule per FR-08.
Alternate flows
- 4a. Patient declines. The system records the decline, keeps the waitlist entry open, and immediately extends the offer to the next-ranked candidate.
- 7a. Slot already claimed. The system informs the patient the slot has been taken, keeps their waitlist entry open, and confirms they remain in the queue.
- 3a. Fewer than five matching candidates. The system offers to all matches. If no matches exist, the slot returns to public online booking.
Exception flows
- 8a. DentiSoft booking call fails. The system retries twice at 30-second intervals. On continued failure it flags the slot for manual booking in the front desk queue and informs the patient that the clinic will confirm by phone within two hours. The slot is held, not released.
Postconditions
- Success: the slot is booked, the waitlist entry is closed, four offers are withdrawn, the clinician's schedule is updated, and the front desk is notified.
- Failure: the slot remains released, no double booking exists, and the front desk holds an open action.
Business rules
- BR-14 A patient may hold only one open waitlist entry per appointment type.
- BR-15 (proposed, not agreed) A released slot shall not be offered to a patient with two or more no-shows in the preceding 90 days.
Exception flow 8a is the part worth your attention. Deciding to hold the slot rather than release it on integration failure prevents double booking at the cost of possibly wasting the slot. That is a trade-off, it is defensible either way, and it is exactly the kind of thing an interviewer will pull on. Which is the point of putting it there.
Artifact 5: The one-page summary
This is the page a hiring manager actually reads. Everything above is what they read if this page works. Put it first in your portfolio.
Meridian Dental Group: reducing appointment no-shows Simulated project. Company, data, and stakeholders are fictional.
Situation. 14 clinics, 14% no-show rate, roughly 180 EUR lost per missed slot. Target of 8% within two quarters, no new headcount, existing practice management system stays.
What I did. Mapped the as-is reminder and no-show process, identified five pain points, ran stakeholder analysis across nine groups including two distinct patient segments, and produced traced requirements plus one detailed use case for the highest-risk flow.
What I produced. Stakeholder register, as-is process with pain point analysis, layered requirements (1 business, 4 stakeholder, 8 functional, 3 non-functional), and use case UC-03 with alternate, exception, and business rules.
The decision I would defend. Ranking waitlist offers by waiting duration rather than by appointment value. It is slower to revenue but it is the version front desk staff can explain to a patient who asks why someone else got the slot. Adoption risk outweighed the margin.
What I would do differently. I built the requirements before confirming the DentiSoft API. Three functional requirements now depend on an unverified assumption. I would have made that call before writing FR-03.
That last line is not weakness. It is the most credible sentence on the page.
What makes a portfolio credible, and what makes it look fake
Opinions here, formed from looking at a lot of these.
Label simulated work as simulated. On the first page, in plain language. Hiring managers can tell within thirty seconds, and being caught implying that a practice project was a real engagement ends the conversation. Labelled simulation costs you nothing. Nobody expects a career switcher to have shipped enterprise change.
Show the decision, not the document. Two candidates both submit a use case. One submits a filled template. The other submits a filled template plus one sentence explaining why they held the slot instead of releasing it. Only one of them gets asked a follow-up question, and follow-up questions are how interviews go well.
Keep assumptions and open questions in. The instinct is to remove them so the work looks complete. Resist it. Analysis that ends with no open questions was performed on a problem that did not exist.
One project, finished. Five stakeholder registers for five different companies proves you can fill in a table five times. One project carried from brief to use case proves you can think across a whole engagement. Depth beats breadth, badly.
Fictional numbers are fine if they are stated. The 180 EUR figure is invented. What matters is that BR-01 references it, FR-04 exists because of it, and you can explain the chain out loud.
Never use real confidential work. If you have relevant material from your current employer, rebuild the pattern on a fictional company. Do not anonymise and republish. It is a fireable thing in many contracts and it reads as poor judgement even when it is legal.
Skip the dashboards. A lot of the advice you will find on this topic quietly drifts into data analyst territory: Power BI, SQL, Tableau. Those are a different role with a different portfolio. If you are targeting BABOK-style business analysis roles, your artifacts are requirements and models, not visualisations. Worth being clear about the distinction before you spend forty hours on the wrong thing. The BA vs project manager vs product owner comparison covers the neighbouring roles.
Five other project briefs you can use
Do not reuse Meridian Dental. Every reader of this article now has it. Pick one of these instead, or better, invent one from an industry you already know, because domain familiarity is the one advantage career switchers actually have.
- A 40-branch gym chain wants to cut monthly membership cancellations. Strong on process analysis and stakeholder conflict, since sales and retention have opposing incentives.
- A regional logistics firm moves from paper proof-of-delivery to a driver mobile app. Strong on non-functional requirements. Offline mode, signature capture, and patchy rural coverage make NFRs the centre of the project rather than an afterthought.
- A university replaces email with a ticketing system for student administration queries. Strong on workflow and service levels, with a genuine conflict between departments who each want their own queue.
- A B2B SaaS company introduces self-serve refunds. Strong on business rules and edge cases. Partial refunds, annual plans mid-term, and chargebacks give you plenty to model.
- A municipal library replaces its room-booking spreadsheet. Deliberately small. If this is your first attempt, start here and finish it rather than starting something ambitious and abandoning it in week two.
How to present it
Keep the delivery boring so the work is the interesting part.
- Format. A public Notion page or a single PDF. Both work. A PDF survives being forwarded internally, which is often how it reaches the hiring manager.
- Order. One-page summary, then stakeholder register, as-is process, requirements, use case. Summary first, always.
- On your resume. One line near your contact details: Portfolio: [link] (1 simulated project, 5 artifacts). Setting the expectation of one project stops it reading as thin. See how to write a BA resume with no BA experience for where this sits on the page.
- In the interview. When asked about it, do not narrate the documents. Open with the decision. "The interesting part was the waitlist ranking. I went with wait duration over appointment value, and here is why." That reframes you from someone who completed an exercise to someone who made a call. More on this in preparing for a BA interview with no BA experience.
Frequently Asked Questions
Can I use a simulated project in a business analyst portfolio?
Yes, and for career switchers it is usually the only option. Label it clearly as simulated on the first page. What is being assessed is your reasoning, not whether you had access to a real enterprise programme.
How many projects should a BA portfolio contain?
One, taken all the way through. A single complete project with a summary, stakeholder analysis, process model, traced requirements, and a detailed use case demonstrates more than five partial ones.
What if my relevant experience is confidential?
Rebuild the pattern on a fictional company rather than anonymising real documents. Publishing employer material, even with names removed, is a contractual risk and reads badly regardless.
Do I need SQL, Power BI, or Tableau for a business analyst portfolio?
Not for BABOK-aligned business analysis roles. Those tools belong to data analyst portfolios. If job descriptions you are targeting emphasise dashboards and querying, you are looking at a different role and should build a different portfolio.
How long does one portfolio project take to build?
Roughly eight to twelve hours of focused work if you already understand the artifacts. Most of that goes into the brief and the requirements traceability, not the writing.
Is a portfolio better than the ECBA certification?
They do different jobs. The certificate signals you have studied the framework. The portfolio shows you can apply it. For career switchers competing against people with actual BA job history, applied evidence tends to matter more in the interview room. We covered the trade-off honestly in is the ECBA worth it in 2026.
Build the artifacts, not just read about them
The gap between reading a worked example and producing one is larger than it looks. You will get halfway through your own stakeholder register and hit a question this article does not answer.
That is what BAvolta's Case Lab is for. You work a realistic case through briefing, discovery, analysis, and artifact completion, then get structured feedback on what you produced. The artifacts land in your portfolio as you go, so you finish with something to link on a resume rather than a completion certificate.
Case Lab sits behind an account. If you want to see how the material is built before creating one, try a free lesson, no signup needed. If you are still mapping out the sequence, the full career switch roadmap is the better starting point.