Build Your Own
Business Intelligence System

Do not use a course dataset. Find your own — a public dataset, your own workplace data with permission, or an open government release. The choice is part of the assessment: a dataset with a real question behind it is worth more than a large one.

• The dataset is not one supplied by this course
• You can state, in one sentence, the decision your report will inform
• You have named a specific person or role who would use it
• The data is genuinely messy enough to require cleaning — if it is already perfect, it is not testing the skill
• You have the right to use and publish findings from it

Every transformation is a decision, and every decision needs a reason. Keep a cleaning log as you go — reconstructing it afterwards is far harder and always less honest.

• Applied Steps are renamed to describe intent, not the default action name
• Every row you removed is justified in writing
• Nulls are handled deliberately, with the reasoning stated
• Data types are set explicitly, with locale considered where it matters
• You can state the row count before and after cleaning, and account for the difference

Fact tables and dimension tables, properly related. If your model is one flat table, it will not pass — this is the single clearest signal of whether someone understood Module 4.

• At least one fact table and two dimension tables
• A proper date table, marked as a date table
• All relationships one-to-many, single direction unless you can justify otherwise
• No bidirectional filtering you cannot explain
• Columns not needed for analysis or display are removed
• A screenshot of Model view is saved for the case study

Not every measure you can write — the ones that answer the question. A model with eight well-chosen, correctly-defined measures beats one with forty.

• Every KPI has a written definition in plain English
• Measures use DIVIDE, not the division operator, wherever a zero denominator is possible
• At least one time intelligence measure that works correctly
• Every base measure validated against the source data independently
• Measures are organised in a display folder or a dedicated measures table

This is the phase most people skip. Build exploratory visuals, follow what surprises you, and be willing to find that your original hypothesis was wrong.

• You investigated at least one thing that surprised you
• You checked whether an apparent pattern survives segmentation
• You can name one finding you did not expect at the start
• You identified at least one thing the data cannot tell you

Apply Modules 7, 8 and 9. The test is whether someone who has never seen the data can read your main page and correctly state the headline finding within thirty seconds.

• Chart types chosen by the question, not by variety
• A clear visual hierarchy — the most important thing is unmistakably the most prominent
• No misleading axes, no unnecessary dual axes, no 3D anything
• Interactions are deliberate — you have used Edit interactions where needed
• It works at the size it will actually be viewed at
• Accessible colour contrast, and alt text on non-decorative visuals

The dashboard is half the deliverable. The case study is the half that gets read by recruiters, and the half that proves you understood what you built.

• A written case study covering problem, data, cleaning, model, findings and limitations
• The model diagram is included as an image
• KPI definitions are listed
• You state explicitly what the analysis cannot support
• It is readable by someone non-technical

Record yourself walking through it in five minutes, or present it to someone. This is the part that transfers directly to an interview, where you will be asked to do exactly this.

• You can explain your modelling decisions without notes
• You can explain any measure you wrote
• You can answer "why did you choose that chart?" for every visual
• You can state one thing you would do differently with more time
• The whole walkthrough fits in five minutes