Business intelligence & dashboards

The problem this solves

Dashboards fail for predictable reasons, and almost none of them are technical. The requirement was gathered from the wrong person. The metric meant something different to finance than it did to operations. The layout answers a question nobody asks weekly. Or it was built beautifully, shared once, and never mentioned again because nothing was done to make it part of anyone's routine.

I treat a reporting project as a behaviour-change project that happens to involve charts. The build matters, but so does knowing which decision the report is meant to support and who has to make it on a Monday morning.

What I do

Discovery and requirements

Workshops and one-to-one sessions with the people who will use the output. I am listening for the decision behind the request, the measures that genuinely move it, and the definitions that different teams are quietly disagreeing about. The output is a written requirements set with priorities and explicit non-goals.

Data source and semantic model design

A reporting layer designed so the same measure calculates the same way everywhere it appears. Published, certified data sources in Tableau or well-structured semantic models in Power BI, with the business logic held in one place rather than duplicated across twenty workbooks.

Dashboard design and build

Wireframes first, so we argue about layout while it is cheap. Then a build focused on clarity: sensible defaults, restrained use of colour, drill paths that follow how people actually investigate a number, and performance that does not make users wait.

Rollout and adoption

Training sessions pitched at the actual audience, quick-reference documentation, and a plan for embedding the report into existing meetings and routines. Adoption is measured, not assumed.

Self-service enablement

Where you want teams building their own views, I set up the guardrails that make that safe: certified sources, a template and style guide, naming conventions, a publishing process, and training for the people who will become your internal builders.

How an engagement runs

What you get

• Working dashboards in your own Tableau or Power BI environment, not a demo instance
• A documented data model with measure definitions and refresh logic written down
• A style guide and template so future reports look and behave consistently
• Training material for both viewers and any internal builders
• A handover pack covering maintenance, known limitations and next steps

Common starting points

A first executive dashboard for a leadership team currently running on spreadsheets. A rebuild of a reporting estate that has grown to hundreds of workbooks nobody trusts. A migration from one BI tool to another, done as an opportunity to prune rather than a like-for-like copy. Or simply unpicking why the numbers in two reports disagree.

Questions I get asked

Do you work in Tableau or Power BI?

Both. I am Tableau Desktop Certified Associate and work in Power BI daily. If you have not chosen yet, I will help you pick based on your existing stack, licensing and internal skills rather than personal preference.

Our data is a mess. Should we fix that first?

Usually not entirely. Waiting for perfect data is how reporting projects stall for years. It is normally better to build against what exists, let the reporting expose the worst quality problems concretely, and fix those in priority order. If the foundations really are unworkable I will say so early.

Can you work with our data engineers?

Yes, and I prefer to. A good chunk of my day job is the conversation between the business and the engineering team. I am comfortable writing requirements that engineers can act on and explaining constraints back to stakeholders without either side losing patience.