Power BI Projects to Build for Your Portfolio

A Power BI portfolio is judged on skills a screenshot cannot show on its own: whether the model is built properly, whether the measures are correct, whether the report stays fast, and whether you can explain your decisions. Five projects that each prove a different skill beat fifteen dashboards that all prove the same one. This article gives you five, each with a real dataset you are allowed to use, the requirements that make it portfolio-grade, and what a reviewer will look for.

One practical point before choosing data. Power BI Desktop is free, but it runs only on Windows (Windows 10 or later, according to Microsoft's download page). If you work on a Mac, plan for a Windows machine or a virtual machine before you start.

Choose data you are allowed to publish

Licensing is easy to overlook. Microsoft's own Power BI sample workbooks are convenient, but their legal terms say you can use them for internal reference, with attribution to their provider. That is fine for practice and a poor basis for a public portfolio. The datasets below have clear licences or are published for public use. And never put employer or client data in a portfolio, even with names removed.

Project 1: A sales performance model with time intelligence

Data: the AdventureWorksDW data warehouse sample, published in Microsoft's SQL Server samples repository under the MIT licence. Restore it to a local SQL Server instance and connect to it, which is practice in itself. Our guide to connecting Power BI to SQL Server covers the connection.

What to build: a star schema with the internet sales fact table and the date, product, customer and territory dimensions. Add a report that answers "how are we doing against last year, and where is the change coming from?"

This project forces a detail that is easy to miss. The fact table joins to the date dimension on an integer key such as 20241231, not on a date column. Microsoft's guidance on date tables says that when relationships use a non-date key like this, and whenever you use the classic time intelligence functions, you must mark your date table as a date table. Power BI then checks that the date column is unique, has no blanks and covers a contiguous range. With that in place, the report needs three measures. The first sums the sales amount column of the fact table. The second evaluates the first inside CALCULATE, with SAMEPERIODLASTYEAR over the date column of the marked date table, which shifts whatever dates are in the filter context back one year. The third divides the difference by last year's figure using DIVIDE, which returns a blank, or an alternate value you supply, instead of an error when last year's sales are zero, which keeps visuals clean. Our articles on the star schema in Power BI and time intelligence in DAX go further.

A reviewer looks for: a clean model diagram with one-to-many relationships flowing from dimensions to the fact table, measures instead of implicit sums, and a year-over-year figure you can verify by hand for one month.

Project 2: Taxi operations with millions of rows

Data: the New York City Taxi and Limousine Commission trip record data. It is published monthly as Parquet files, typically with a two-month delay, and comes with data dictionaries and a taxi-zone lookup table. A few months of yellow-taxi trips add up to millions of rows, which is the point of this project.

What to build: an operations report showing trips, revenue and average fare by hour, weekday and pickup zone, with the zone lookup as a dimension.

The real exercise is performance. Download the files first. The Power Query Parquet connector reads from the local file system and Azure storage, not from a web URL. Then:

• Load only the columns the report uses. Every unused column costs memory.
• Set data types deliberately; a date-time with seconds has far more distinct values than a date.
• Use Performance Analyzer to find the slowest visual, fix it, and record the before and after timings.

Our guide to Power BI performance tuning explains what to change and why.

A reviewer looks for: a note of the model size before and after your changes, the timings, and your reasoning about which columns you dropped.

Project 3: A development indicators explorer

Data: the World Bank's World Development Indicators, licensed CC BY 4.0, updated annually and downloadable as CSV.

What to build: a report where a user picks an indicator, such as life expectancy or internet use, and compares countries and regions over time, with a drillthrough page for any single country.

This dataset is a Power Query exercise before it is a visualisation exercise. The download stores years as columns, so you will unpivot them into rows. It also mixes individual countries with regional and income-group aggregates, and the country metadata file in the download lets you separate them. Leave every step visible in the Applied Steps pane with a meaningful name, because reviewers can read them. Our Power Query tutorial covers unpivoting and step hygiene.

A reviewer looks for: a tidy long table, aggregates not double-counted in country totals, a working drillthrough, and a visible CC BY attribution to the World Bank on the report.

Project 4: A workforce report with row-level security

Data: generate it. A short script can create employees, departments, managers, hires and exits. Because the data is synthetic, you can publish it without any privacy concern. Say clearly in the README that it is synthetic.

What to build: a headcount and attrition report where each manager sees only their own department, using dynamic row-level security. Create a role whose DAX filter compares a user-mapping table to USERPRINCIPALNAME(), then test it with View as for several users.

Two facts from Microsoft's row-level security documentation belong in your write-up, because they are easy to get wrong. RLS applies only to users in the workspace Viewer role, not to Admins, Members or Contributors. And a user who can see a row can see every column in it; hiding columns needs object-level security instead. Our RLS guide walks through the setup.

A reviewer looks for: the role definitions, screenshots of "View as" for two different managers showing different numbers, and a sentence on how you would test it with real accounts.

Project 5: A report for a real person

Data: from someone who needs a report: a family business, a club, a college department or a non-profit. Use only data they own and agree to let you show, or show the report without the data.

What to build: whatever they need, which is the skill being tested. Hold a short conversation to agree the questions the report must answer. Build a first version, get feedback, and change it. Document that loop.

A reviewer looks for: the original request, the questions you agreed, what changed after feedback, and whether the person still uses the report. This project answers the interview question "tell me about a time you gathered requirements" better than a tutorial dataset can.

How to present the portfolio

A reviewer may not have Power BI Desktop installed, so make every project understandable without it:

• A README per project with the question, the data source and licence, a model diagram screenshot, the key measures with a one-line explanation each, and what you would do next.
• Screenshots and a two-minute screen recording showing the interactions: slicers, drillthrough, tooltips and "View as".
• The .pbix file in the repository for anyone who wants to open it. Keep the file small, or publish the report through the Power BI service if you have a licence.

Be careful with Publish to web. Microsoft's documentation warns that anyone on the internet can view a published report without signing in. That includes the detailed data behind it, even data the visuals only show aggregated. It is acceptable for openly licensed public data like projects 2 and 3. It is never acceptable for anything confidential, and it doesn't work at all for reports that use row-level security, so present project 4 through screenshots and video.

What this set proves, and what comes next

Together the five projects cover the modelling, DAX, Power Query, performance, security and stakeholder skills that Power BI roles ask for. When you can explain each design decision out loud, you are ready for technical interviews. Our Power BI interview questions show how those decisions get probed. The GloryTecks Power BI course builds five dashboards of this kind, including sales and HR reports, alongside Power Query, DAX and data modelling.