Business Analyst Projects That Prove You Can Do the Job (With Real Datasets)

Looking for a BA job is like entering a rabbit hole because all the job postings either have too many expectations (unrealistic) or they demand experience. But the problem is that most entry-level candidates have the same response: a course certificate, a few tool names, and nothing concrete to show. And this is why having a good project portfolio counts when you’re just entering the field.

This guide contains 10 projects using real public datasets, with a clear business problem to solve in each one. For every project, you’ll have to define the requirements, identify the stakeholders, create the relevant process documents, choose the tools for the analysis, and connect your findings to a business outcome. You’ll also have a clear idea of what the finished project demonstrates to a hiring manager.

The projects focus on the core work of a business analyst: requirements, stakeholders, processes, and business outcomes, with data supporting the analysis. You’ll work through each part of the problem before getting to the final analysis and recommendations. And in the end, it’ll give you projects with enough depth to discuss in an interview and build into a credible business analyst portfolio.

Why Projects Are Necessary for Freshers Applying to BA Roles

Don’t get it wrong; certifications are a great way to validate your skills, and while gaining one, you get to explore so many themes and practice that eventually it becomes an important part of your knowledge in the field. But when it comes to practicality, even you know that handling things head-on is the only way to understand your progress. Let’s say you have a well-made BRD; now this will signify that you know how to start with a business complaint, question it properly, develop requirements, and then implement something that a development team could implement. 

So now when you work on a Business Analysis project, you’ll get to put your knowledge to the test and, better yet, refine your skills! You could start with a business problem, work out what the stakeholders need, analyse the existing process, document the requirements, and then develop a solution that connects back to the original business goal. Your project should show how you moved from the initial problem to the final recommendation, rather than simply listing the tools you used.

After all this practice, you’ll have plenty of things to talka bout in your BA interview. When an interviewer asks, “Walk me through a project you worked on,” you can take them through the problem you started with, the questions you asked, the requirements you gathered, and the decisions you made. Three well-documented projects can give you three such stories, with enough detail to explain your thinking and the work you actually did.

Hence, as a fresher, you should concentrate on 2 to 3 excellent projects. Make sure each one has clear requirements, process flows, decisions, assumptions, and recommendations. A smaller portfolio with projects you can explain properly will give you more to work with in an interview than a long list of shallow projects.

Check this roadmap for a step-by-step guide: Business Analyst Roadmap 2026: From Beginner to Job-Ready. 

What Makes a Project a Business Analyst Project (and Not a Data Analyst Project)

The dataset itself does not make a project a business analyst project. The question you ask, and the output you produce do. A data analyst could utilize sales data to find out what occurred, what trends there were, or what will occur. A business analyst would utilize the same information to understand what changes have to be made, who the changes affect, what is required to implement the changes, and how the changes will be measured.

The business analyst project examples later in this guide follow the same principle: each one focuses on a business problem, the requirements behind it, and the artefacts needed to support the solution. 

The question is: Could developers or operational teams act upon my results the next day? A good business analyst case study would do more than just draw charts or dashboards but also generate requirements, changes in process, or backlogs that could be implemented.

That is precisely why the projects have to make use of the language and artefacts that are employed by the BA, including AS-IS/TO-BE processes, elicitation, functional/non-functional requirements, business rules, acceptance criteria, and requirement traceability.

There is still plenty of room for data analysis. A good BA can use SQL or Excel to validate assumptions, quantify a problem, or support a recommendation. The analysis strengthens the requirement; it does not replace it.

Same Data – Two Different Projects

Dimension	Data analyst project	Business analyst project
Core question	What happened? What will happen?	What should change, and is it worth it?
Main output	Dashboard, report, model	BRD, user stories, process map, RTM
Success measured by	Accuracy, insight quality	Adoption, business outcome, requirement clarity
Typical tools	SQL, Python, Power BI, Tableau	Excel, SQL, Jira, Confluence, Lucidchart, Figma
Stakeholder role	Consumer of the output	Source and approver of the requirement
Ends when	The insight is delivered	The change is built, tested and validated through UAT

These are some of the most frequently used business analyst tools, which include data analysis, documentation, collaboration and process mapping. 

For more insight into how these two positions differ, consider what the scope of a data analyst is compared to a business analyst. If you’re still deciding between the two roles, check how a data analyst’s role differs from a business analyst.

If the analytics side is what actually appeals to you, you can start with these data analyst project ideas. 

The 8 Artefacts a BA Portfolio Is Actually Judged On

Before embarking on project building, it is important to understand what a hiring manager looks for.

1. Business Requirements Document (BRD)

A BRD records what a business wants to fix or achieve through a project. You start with the business problem, speak to the people affected by it, and document what they need from the solution. The document gives the project team a shared understanding of what needs to be built, why it is needed, and what the finished solution should accomplish.

2. AS-IS / TO-BE Process Map

This shows how a process works today and how it should work after the proposed change. It demonstrates that you can spot bottlenecks, unnecessary steps, and opportunities for improvement.

3. Stakeholder Matrix + RACI

The stakeholder matrix highlights those who are interested, impacted, and responsible, whereas the RACI highlights decision-making responsibilities. Both of these indicate that you know your people in terms of requirements.

4. User Stories + Acceptance Criteria

Your portfolio should also include user story examples that demonstrate how you transform the requirements into actionable needs. An effective story will be descriptive enough for a developer to act on it without seeking clarification.

5. Requirements Traceability Matrix (RTM)

A requirement traceability matrix (RTM) associates every requirement with its business objective and related test case. This demonstrates that requirements can be managed throughout the process of development and not lost after documentation.

6. Business Rules Catalogue / Decision Table

These documents transform the logic into clear rules that are quantifiable. They are most helpful where various decisions hinge on aspects like the nature of the customer, transaction amount, or whether there is an approval.

7. Wireframe / Low-Fidelity Prototype

A wireframe provides stakeholders and developers a visual illustration of the solution proposed. The wireframe proves that it is possible to describe requirements visually instead of describing everything in writing.

8. KPI Definition Sheet + Executive Dashboard

This connects the proposed change to measurable business outcomes. It demonstrates that you are thinking beyond implementation and considering whether the solution actually improved the business.

Deliverables Reference

Artefact	What it proves to a hiring manager	Produced in project(s)	Rough time to build
BRD	You can turn a business problem into scoped requirements	P1, P4, P6	6 – 10 hrs
AS-IS / TO-BE process map	You can analyse a process end-to-end	P1, P5, P6, P7	3 – 5 hrs
Stakeholder matrix + RACI	You understand roles, decisions and stakeholders	P2, P7	2 – 3 hrs
User stories + acceptance criteria	Developers can understand and implement your requirements	P3, P4, P9	4 – 6 hrs
RTM	You can connect requirements to objectives and testing	P3, P6, P9	2 – 4 hrs
Business rules/decision table	You can document conditional business logic clearly	P4, P6	2 – 4 hrs
Wireframe / low-fi prototype	You can communicate a solution visually	P3, P8	3 – 5 hrs
KPI sheet + executive dashboard	You can measure whether a change worked	P4, P8, P10	4 – 8 hrs

Tools You’ll Need For BA Projects

Excel or Google Sheets can be used for numerical analysis and RTM, while SQL is needed when you want to verify your assumptions using the underlying data. Process maps can be done using Lucidchart, draw.io, or Miro; Jira will handle your backlog and user stories; the BRD can be put into Confluence or Notion; and the wireframes using Figma should be sufficient.

Free tiers are sufficient for the projects in this guide, so paid tooling is not a prerequisite.

Also, one small detail makes the portfolio feel much more professional: name and version your files like workplace deliverables. For instance, BRD_v1.2_ReturnsProcess.docx is far stronger than final_BA_project_new.pdf. Add dates and maintain versions so a reviewer can see how the work evolved.

If you want to explore more tools for this role, then you can start with: SQL Roadmap 2026

10 Business Analyst Projects With Real Datasets

How do you turn a dataset into a proper BA project? Start with a business problem. From there, you have to question what is actually happening, make decisions based on what you find, and leave behind the documentation another team would need to act on.

The 10 projects below use public datasets you can download and turn into practical BA case studies, from process redesign and requirements gathering to business rules, prioritisation and technical specifications.

Each project has its own initial state and different artefacts. That is deliberate: a good business analyst portfolio should show range, not ten dashboards which are all the same. 

Project 1: E-Commerce Returns and Refunds

An online retailer is receiving complaints about slow refunds. Customers can initiate returns through different channels, while support, warehouse, and finance each own part of the process.

Your first job is to establish the AS-IS process. Map what happens from the moment a customer requests a return to the moment the refund is completed. Use the transaction data to identify cancellation and return-related patterns, then use those findings to investigate where delays or unnecessary handoffs could occur in the assumed process.

Then redesign the workflow. Your TO-BE process map should show who owns each step, what information moves between teams, and where automation could remove manual work.

The portfolio case study should finish with a BRD, process maps, and a small business case estimating the potential reduction in processing time.

Public dataset: UCI Online Retail II

Tools: Excel, Lucidchart/draw.io, Word or Confluence

Skills demonstrated: process analysis, requirements documentation and stakeholder thinking.

Project 2: Bank Term-Deposit Campaign

A bank has run a large telemarketing campaign but cannot clearly explain which customer segments are worth targeting. Using the UCI Bank Marketing dataset, investigate the campaign results and prepare a recommendation for the marketing team.

Before conducting your analysis, identify who your stakeholders will be that you need to talk to. The marketing department will be interested in conversion, the call-center manager in agent productivity, and the compliance department in customer contact.

Your portfolio should include a stakeholder matrix and RACI, an elicitation question set, clearly defined campaign KPIs, and a one-page management recommendation. Document the assumptions behind your recommendation rather than presenting the dataset as if it tells you the answer automatically.

Public dataset: UCI Bank Marketing

Tools: Excel, SQL, PowerPoint/Google Slides

Skills demonstrated: stakeholder analysis, elicitation, and turning evidence into a business recommendation.

Project 3: Healthcare Appointment Reminder Feature

The product team has one sentence in its backlog: “Reduce patient no-shows.”

Turn that into a proper requirement.

Analyze the problem using the Medical Appointment No-Shows Dataset and then design the process for appointment reminder and rescheduling. Start your analysis by identifying the patient’s journey and then identify what needs to be done before, during, and after the reminder process.

Next, create an epic and write it down in terms of user stories. Each story must have acceptance criteria that can be understood by a developer and a tester without referring to you for clarification.

For example:

As a patient, I would like to be reminded of my appointment in advance so that I may confirm or reschedule it if required.

The completed case study should include user stories, Gherkin acceptance criteria, low-fidelity wireframes, and the RTM. Use Jira for the backlog and Figma for the prototype.

Public dataset: Medical Appointment No-Shows

Tools: Jira, Figma, Excel

Skills demonstrated: requirements elicitation, user stories, acceptance criteria, and UAT thinking.

Project 4: Telecom Retention Rules

A telecom company wants its agents to make more consistent retention decisions. At present, agents decide manually which customers receive discounts.

This project is about business rules, not building a churn model.

Use the Telco Customer Churn dataset to identify the customer characteristics relevant to the decision. Then translate the business strategy into explicit rules: who qualifies, which offer they receive, what the maximum discount is, and when an agent needs approval.

Represent those rules in a business rules catalogue and decision table. Include exception scenarios too. What happens when a customer meets two rules? What happens when required information is missing?

Finish with a KPI definition sheet showing how the business would know whether the new rules improved retention without unnecessarily increasing discount costs.

Public dataset: Telco Customer Churn

Tools: Excel/SQL, Word, Jira

Skills demonstrated: business rules, decision logic, and translating analysis into implementable requirements.

Learn Power BI with: Power BI Roadmap: Data Cleaning, Modeling, DAX and Charts

Project 5: Marketplace Seller Onboarding

A marketplace is growing, but new sellers are taking too long to become active. Verification, catalogue setup, payment configuration, and fulfilment are handled by different teams.

Treat the problem as a process investigation.

Use the Olist dataset to understand seller and delivery patterns, then use those insights to build a realistic seller-onboarding scenario. Map the assumed current-state workflow, marking every handoff, approval, and duplicated data-entry point. 

The key output is not another analysis chart. It is a proposed onboarding process with a defined ownership structure and SLAs. Specify what happens when a seller misses the SLA and who gets the escalations.

In your case study, provide the AS-IS and TO-BE processes, stakeholders/RACI matrix, as well as SLAs and requirements for the redesigned process.

Public dataset: Brazilian E-Commerce Public Dataset by Olist

Tools: SQL, Excel, Miro/Lucidchart

Skills demonstrated: process mapping, operational analysis, and SLA design.

Project 6: Loan Origination Automation Assessment

A lender wants to reduce the time taken to process loan applications. Management suggests automating the entire workflow.

As the BA, your job is to challenge that assumption.

Using Lending Club data for context, build a realistic loan-origination scenario and map the assumed current-state process. Then classify each activity as automate, assist, or keep human-controlled. Consider processing time, risk, regulatory sensitivity, and the type of judgement involved.

For every automation candidate, document the expected benefit, associated risk, and assumptions behind the assessment. The resulting automation assessment matrix becomes the foundation for your recommendation.

Your final case study should include the AS-IS/TO-BE process, automation assessment, BRD, business rules, risk and assumption log, RTM, and a short cost-benefit analysis.

Public dataset: Lending Club loan data

Tools: Excel, SQL, Lucidchart, Word

Skills demonstrated: requirements analysis, process improvement, and evaluating automation responsibly.

Project 7: Citizen Grievance Redesign

Assume that a citizen files a complaint against the government, but they are unaware whether their complaint is assigned, investigated, or settled.

Instead of coming up with a new screen straightaway, map the whole service experience first.

Identify the people involved on either side of the service delivery: citizens, call center personnel, departmental officers, and senior administrators. Show what the citizen experiences alongside the internal activities required to resolve the complaint.

The output would be a service blueprint, along with the requirements for visibility, escalation, response SLAs, and access and language support. 

Use a relevant dataset from India’s Open Government Data Platform to ground the case in a real public-service context.

Public data source: data.gov.in

Tools: Miro/Lucidchart, Excel, Word

Skills demonstrated: service design, stakeholder analysis and working with complex organisational processes.

Project 8: UPI Feature Prioritisation

A fintech product team has more potential UPI features than its engineering team can deliver in the next release.

You have been asked to help decide what gets built first.

Use NPCI UPI statistics and RBI payment data to establish the opportunity. Then define the user problem, identify the relevant stakeholders, and create a feature backlog.

Prioritize the backlog with the use of RICE or MoSCoW methods. The significant evidence for the portfolio is your rationale in explaining why one feature is an MVP and why another one is not.

Convert the decision into a package consisting of your prioritized backlog, MVP scope, success-metrics tree, user stories, and a low-fidelity prototype.

Public data sources: NPCI and RBI

Tools: Excel, Figma, PowerPoint

Skills demonstrated: prioritisation, requirements management and business judgement.

Also Read: Product Manager Roadmap 2026: A Path for Tech Professionals

Project 9: Account Aggregator Integration

This is the technical project in the set.

A lender currently asks customers to upload bank statements manually and wants to retrieve financial information through India's Account Aggregator ecosystem.

Start by reading the relevant ReBIT technical specifications and RBI requirements. Trace the consent journey and identify what data the lender needs, what happens when consent is revoked, and how the system should behave when an API call fails.

The central portfolio artefact is an integration requirements specification. Support it with a field-level data mapping, sequence diagram, error-handling matrix, and RTM linking requirements to the relevant regulatory requirements.

Use Postman to explore API behaviour where appropriate.

Sources: ReBIT and RBI

Tools: Excel, Postman, draw.io/PlantUML, Word

Skills demonstrated: technical requirements, API understanding and regulatory traceability.

Project 10: State Skilling Programme Monitoring

A state skilling programme collects large amounts of information from training centres but cannot clearly determine whether those programmes are improving employment outcomes.

Do not begin by designing a dashboard.

Start with the business objective. Define what success means, then work backwards into the information management needs of the programme director, centre manager and other stakeholders.

Develop a KPI tree linking the objective of the programme to the indicators that can be measured. Define the definition, owner, source, refresh period, and decision for each KPI.

Only then design the reporting layer. The final portfolio piece should contain the KPI definition sheet, data-quality requirements, stakeholder-specific reporting requirements, and dashboard wireframe.

Public data sources: MoSPI and World Bank Open Data

Tools: Excel, Power BI/Tableau, Word

Skills demonstrated: KPI design, requirements analysis, and connecting business objectives to reporting needs.

Which Project Should You Start With?

Not every beginner needs to start with the same business analyst project. The right choice depends on what you already know and, more importantly, which part of the BA role you still need to practise.

If you're looking for business analyst project ideas, start by choosing a project that lets you practise the specific BA skill you still need to develop. 

If you're a non-technical fresher from B.Com, BBA, BA or MBA, start with Project 2: Bank Marketing, followed by Project 1: E-Commerce Returns. Both can be completed primarily with Excel and documentation, so you can focus first on understanding stakeholders, business problems, and requirements rather than learning a new technical stack. 

If you are an engineer or tester considering a BA career change, begin with Project 3: Healthcare Appointments Feature, and follow up with Project 5 or Project 9. You are likely technically sound; your next step is developing the skill to communicate technical knowledge in requirements that everyone understands.

If you already work in operations, support, banking, or a process-heavy role, start with Project 6: Loan Origination or Project 7: Citizen Grievance Redesign. Your existing understanding of workflows and operational problems gives you an advantage. The project should show that you can structure that experience using BA methods and artefacts.

If you're also exploring how to break into a data-adjacent role without experience, see this guide on breaking into data roles with no prior experience.

A simple rule for your portfolio

Aim for three projects:

• One Foundation project to demonstrate basic BA documentation and process analysis.
• One Intermediate project to demonstrate requirements, prioritisation or stakeholder management.
• One Advanced project to demonstrate technical requirements, automation or complex process analysis.

And finish them in order. One completed, well-documented project is worth more than three half-built repositories.

The “No Real Stakeholders” Problem and How to Handle It Honestly

A self-directed BA project can have a real dataset and a realistic business problem, but it does not have a real stakeholder. Nobody actually disagreed with your requirement, changed the scope halfway through the project, or rejected your BRD. Interviewers know that. Trying to present a self-directed project as a real client engagement is more likely to hurt your credibility than help it.

What they actually want to see is whether you understand the limitation and know how a BA would handle it.

1. Use a Proxy Stakeholder

You do not need to invent a stakeholder. Find someone who can reasonably play the role for your project.

For instance, if you are developing a bank marketing project, a person who has knowledge about call center operations can become a subject-matter expert. Hold an interview for 30 minutes, note down the date, his role, and your questions to him.

That gives you something concrete to discuss: what you initially assumed, what the proxy stakeholder challenged, and what you changed as a result.

2. Keep an Assumptions Log

Some requirements will inevitably be unvalidated. Document them instead of presenting them as facts.

For example:

Assumption: Refunds above ₹5,000 require finance approval.

Status: Unvalidated.

Validation required: Confirm with the finance controller.

This will make your projects even more realistic to showcase, while you’ll get to understand the challenges as well. At work, BAs regularly have to manage incomplete information while waiting for the right stakeholder.

3. Show a Decision You Could Have Made Differently

A portfolio project can look artificial when every decision leads neatly to the final solution. Add at least one genuine trade-off.

For example, you might compare two options for the returns process:

Option A: automate every refund below a defined threshold.

Option B: keep manual approval but introduce an SLA.

Then explain why you selected one, what it improves, and what it costs. This demonstrates that you understand BA work as a series of business decisions and trade-offs, rather than simply producing documentation.

4. Simulate Stakeholder Pushback

Take one of your requirements and challenge it from another stakeholder's perspective.

For example:

Requirement: Automatically approve refunds below ₹5,000.

Finance objection: Automated approval could increase fraudulent refunds.

Your response: Introduce additional validation checks and an exception route for unusual transactions.

You can keep these scenarios in a one-page stakeholder pushback appendix. It gives an interviewer something concrete to question you about and shows how you think beyond the happy path.

What About “Real-Time Projects”?

Be careful with projects advertised as "real-time" or "live projects" by training providers. A recycled case study does not automatically become real-world experience because someone labels it that way.

A self-directed project using a public dataset, documented assumptions, and honest stakeholder simulation is easier to defend in an interview because you actually understand every decision in it.

If an interviewer asks whether you had a real stakeholder, don't try to blur the distinction. Say:

“This was a self-directed project, so I didn't have a real product owner. I used [X] as a proxy stakeholder for elicitation and logged every unvalidated assumption. If I had access to the actual finance team, these are the three requirements I'd expect to revisit.”

That answer does not make the project less valuable. It shows that you understand the difference between portfolio evidence and professional experience. And that distinction is exactly what makes the project credible.

Using AI to Draft Requirements: What It Does Well and What It Can't Do

AI can make parts of a BA's documentation work considerably faster, but it does not remove the need for business analysis. Used properly, it is a drafting tool. The BA still has to decide whether the requirement is correct, relevant, and actually workable.

Where AI Helps

An LLM can handle much of the repetitive work involved in creating a first draft. For example, you can use it to:

• create the initial structure of a BRD
• convert a business statement into user-story format
• suggest alternative acceptance criteria
• draft a data dictionary from column names
• identify possible edge cases
• rewrite a technical requirement for a non-technical stakeholder, or the other way around

For Project 1, you could use AI to create the initial BRD structure and then track how much you changed after reviewing the actual business problem. That exercise is useful because it makes the difference between drafting and analysing visible.

Where the BA Still Has to Think

An LLM cannot be aware of the fact that the head of operations is responsible for the budget, or the specific team refuses the requirement since it would add a stage to a very crowded workflow. Requirements are influenced not only by logic but also by organizational limitations.

AI can also produce requirements that sound professional but say very little:

“The system should be user-friendly.”

A BA needs to turn that into something measurable and testable.

Prioritisation has the same problem. An AI tool does not automatically know which requirement matters most when two departments have conflicting priorities or when the delivery deadline changes.

There is an even bigger risk in regulated work. AI can confidently invent a compliance rule that does not exist. For projects involving lending, payments, or other regulated processes, every such requirement needs to be verified against the actual source.

And from hereon, your role as a BA will go from creating the first draft to questioning it properly. What is missing from the requirement? Is there enough information to support it? Who needs to sign off on it, and how will the team test whether it has actually been met? These are the parts where you still need to apply your own judgement.

Be Transparent About AI Use

Do not try to fake that every line in your portfolio was typed manually. Include a small note in the project README about AI-assisted work, mentioning which parts were done by AI and which were not. 

For example:

AI use: Used AI to structure the initial BRD and generate acceptance-criteria alternatives. All business rules, assumptions, priorities, and final requirements were reviewed and validated manually.

That gives an interviewer a much better basis for judging your BA skills than simply claiming you did not use AI at all.

AI is already changing what entry-level professionals spend their time doing. Scaler's India AI Workforce Report 2026 provides further context on how AI is reshaping work in India.

How to Present a Business Analyst Project So It Counts

A well-researched BA project should not end up buried at the bottom of your CV or stored in an inaccessible folder. In fact, recruiters must be able to get a sense of the problem you solved, and the decision and rationale behind it, in a matter of minutes. Display your project as if it is professional-level, but make sure that it is self-directed.

Writing It on Your Resume

Don't turn a project into a paragraph. Give each one two or three bullets, with each bullet answering some combination of four questions: What was the problem? What did you do? What did you produce? What changed?

For example:

E-Commerce Returns Process: Mapped a 12-day refund process across four teams and identified three unnecessary handoffs. Designed a TO-BE workflow that modelled a reduction in cycle time to five days; documented the recommendation in a BRD and BPMN process maps.

If the result is modelled rather than actually measured, say so. A projected five-day cycle time is useful evidence; presenting it as an observed business result when it wasn't would be misleading.

Keep self-directed work under a Projects heading. Never put it under Experience or create a fictional company to make the project look more impressive. That shortcut can undermine the credibility of everything else on the resume.

Also name the artefacts. BRD, RTM, user stories, acceptance criteria, BPMN, stakeholder matrix and similar terms tell a recruiter immediately what kind of BA work you have actually done.

And give them somewhere to verify it. A working project link is part of the project, not an optional extra.

GitHub vs a Portfolio Site: where to actually put it

You don't need a sophisticated website. You need a place where a recruiter can understand the project and open the evidence without asking for permission.

GitHub is perfectly suitable for BA work if you treat the repository as a documentation archive rather than a coding exercise. A clean project could look like this:

project-name/

├── README.md

├── documents/

│   └── BRD.pdf

├── diagrams/

│   ├── AS-IS.png

│   ├── TO-BE.png

│   └── source-file

├── data/

│   └── dataset-source.md

└── sql/

    └── analysis.sql

The README is the important part. Give the reader the business problem, scope, approach, key decisions, artefacts, and lessons learned before asking them to open individual files.

A portfolio website works better with visual content. In case your project contains wireframes, service blueprints, or a number of process maps, then creating a Notion, Google Site, or something similar will be a much more convenient choice for you.

You don’t have to pick just one. Use GitHub as the archive and a simple portfolio page as the front door, then link both from your LinkedIn Featured section.

There is one hard and fast rule: anything that you turn in must be accessible without a login or access request. A perfect BRD that a recruiter cannot view is effectively invisible.

Talking about it in an interview when it wasn't for a real client

The interview should sound less like a presentation and more like a discussion regarding a business problem.

Don't start with:

"I used Excel, SQL, and Power BI..."

Start with:

"The problem I was investigating was a long refund cycle involving four teams. I mapped the existing process, found three major handoffs, and then redesigned the workflow."

The tools can come later. The interviewer is trying to understand how you approached the problem and why you made particular decisions.

Prepare two versions of every project:

• 90 seconds: problem → approach → key decision → outcome
• 5 minutes: requirements → stakeholders → assumptions → trade-offs → artefact

Then rehearse three questions that are likely to expose whether you actually understand your project:

“Why did you scope it that way?”

“What would you change if you did it again?”

“Which requirement were you least confident about?”

Do not hesitate to mention that it is self-directed. Say it early and explain how you compensated for the missing stakeholder. If you used a proxy stakeholder, show the elicitation notes. If you made assumptions, show the assumptions log. If you had to choose between two solutions, explain the trade-off.

Finally, keep one number ready that you feel is worth showing. It could be estimated cycle-time reduction, hours of manual work removed, or another relevant business measure. If the figure is modelled, state the assumption behind it.

That combination matters more than making the project look like something it wasn't. A recruiter should finish the conversation knowing what you analysed, why you made your decisions, and what evidence supports your work.

Six Mistakes That Make a BA Portfolio Look Fake

A portfolio does not become convincing simply because it contains BA terminology. These six mistakes can make even a well-designed project look like a template exercise.

1. A dashboard with no requirement behind it. If the project ends with a dashboard but never explains the business problem or requirement it addresses, it is essentially a data analyst project with a BA label. An interviewer will usually spot that distinction quickly.
2. Requirements with no source. Every requirement should be traceable to a stakeholder input, an explicit assumption, or evidence from the data. If you cannot explain where a requirement came from, it will look invented.
3. No AS-IS process. Jumping straight to the TO-BE process makes it difficult to see what problem you actually analysed. Show the current state first, then explain why the proposed change is necessary.
4. Ten shallow projects. A portfolio full of one-page case studies does not demonstrate much depth. Three projects with complete requirements, process maps, decisions and supporting artefacts are far stronger.
5. A template with placeholder text still in it. Nothing can be more destructive to a seemingly completed BRD than having [Insert Company Name], [Project Manager], or other such template information on the page. Before publishing, review everything as if you are the recruiter receiving it. 
6. No stated limitation. Real projects have incomplete data, assumptions, and trade-offs. It is easier to believe in a project where everything worked as expected, and all requirements were clear, rather than in one which clearly states what could not be checked.

Before you release your project for use, make it available to someone who is not aware of it and have them tell you what problem your project solves. If they cannot do so within 30 seconds, then the documentation requires further refinement.

Conclusion 

Business analyst hiring is ultimately a documentation-and-evidence problem, not a certification problem. A certificate can show that you completed a course, but a real dataset, a realistic business problem, a documented assumptions log, and artefacts you can confidently walk through show how you actually think and work as a BA.

The best is that you don't need ten projects to prove that. Start with one Foundation project, download the dataset today, and resist the temptation to build the dashboard first. Map the AS-IS process, identify the problem it exposes, and document your assumptions. Once that project is complete and you can defend your decisions, move on to the next one. A small portfolio built with depth will always be more convincing than a large one built for appearance.

FAQs

1. What projects does a business analyst work on?

Business analysts are involved in process improvements, developing definitions for new products or features, integration of systems, automating manual processes, and developing reporting or monitoring systems. In all of these instances, the BA captures the requirements, records them, and ensures that the eventual solution addresses the business problem. 

2. How do I get business analyst experience with no job?

Complete two or three self-motivated projects utilizing open data sources and deliver work-like deliverables in the form of BRDs, process maps, user stories, and RTMs. Taking up the challenge to solve a process problem for an NGO or college society is another way of gaining stakeholder experience.

3. What goes into a business analyst portfolio?

An ideal portfolio will consist of a BRD, AS-IS/TO-BE process map, stakeholder matrix, user story with acceptance criteria, requirements traceability matrix, and either a dashboard or a wireframe. Two or three completed projects are more important than ten unfinished ones.

4. Where can I find real datasets for business analyst projects?

For Indian public data, start with data.gov.in. Kaggle and the UCI Machine Learning Repository offer business datasets, while World Bank Open Data and sources such as RBI, NPCI and MoSPI provide broader economic, financial and labour data. Most of these sources are freely accessible.

5. What's the difference between a business analyst project and a data analyst project?

A data analyst project typically ends with an insight, analysis or dashboard. A business analyst project ends with something the organisation can act on, such as a requirement specification, process change or prioritised backlog. The same dataset can support either; the question and final deliverable are what change.

6. How many projects do I need to get a BA job?

Three well-documented projects should be sufficient to get started with. The key is to have a good understanding of the choices you've made and your assumptions and compromises. Interviewers will go deeper into a project rather than look for multiple projects on your CV.

7. What do I put on my resume if the project wasn't for a real client?

Put it under “Projects,” and not under “Experience,” but be honest about the work that was done. You can quantify a modelled outcome as long as you clearly state the assumption, but never invent a client or employer to make a self-directed project look like professional experience.

8. What tools should a business analyst know?

Excel and SQL provide a solid foundation, while Jira and Confluence are used for managing backlogs and requirements. Lucidchart, draw.io, or Miro would be helpful for process maps, Figma for wireframing, and Power BI or Tableau for reports.