Summary
You’ll have one agreed set of KPI definitions, a confirmed list of usable data sources, and a clear plan for the dataset, measures, and report pages so Power BI reporting matches the board pack.
You asked for help getting reporting into Power BI after a system change and a board pack wobble. We’ll pin down definitions, confirm what data you can actually use, and leave you with a build plan your team can deliver against. If you’d like to go ahead, the next step is a short booking call and a signed proposal.
We start with the questions that cause the arguments later, like what counts as “active” and which margin Finance signs off. Then we trace every KPI back to a field in a system you can access. Once the definitions and sources hold up, we map the dataset, measures, and report pages so the build is predictable.
Who you are working with
We’re a four-person BI team that gets called in when a business has been told to “move reporting into Power BI” and the first question is “what are we actually building.” We’ve spent years in the gap between Finance, Ops, and IT, where the spreadsheet version of the truth and the system version do not match.
People bring us in for the front-end thinking that stops rework. We don’t start with a pretty report. We write down definitions, tie each KPI to a source you can access, and spell out measure logic so Finance and Sales can point to the same line when questions come up.
The team
You’ll deal with the same four people throughout, so decisions stay joined up from definitions through to the model and wireframes.
Team
Harriet Collins, BI consultant. Harriet runs the KPI and definitions sessions and keeps the conversation tied to the board pack numbers, not the first chart someone wants to see.
Tom Hargreaves, Data modeller. Tom maps sources into a dataset shape that will hold up, and he flags where a table structure will block the measures you want.
Aisha Rahman, Power BI developer. Aisha writes the DAX specification and measure patterns so your build stays consistent across pages, reports, and future additions.
Ben Wilkins, Project manager. Ben keeps the work moving, lines up the right people for each session, and makes sure access requests happen before they become blockers.
Recent projects
Here are a few recent Power BI reporting blueprint engagements, showing the kinds of definition, data, and modelling problems we help teams lock down early.
Portfolio
Finance KPI definition reset. Aligned a board pack set of KPIs across Finance and Sales, replaced spreadsheet-only calculations with written measure rules, and produced a build plan that an internal analyst team delivered without changing scope.
New system reporting triage. Audited the post-rollout data sources, logged gaps and missing joins, and prioritised a first release set of measures that could be supported without manual exports. The team avoided a full report rebuild in month two.
Operations performance pack plan. Designed page wireframes and filter behaviour for an ops pack, specified a shared measures library, and set workspace structure and permissions so sensitive financial measures stayed controlled while ops self-served day to day.
“We stopped debating definitions and started using the same numbers in every meeting.”
Finance manager, a growing services firm
Our approach
This work is about removing unknowns before build starts. We’ll ask for specifics, write decisions down, and show you the trade-offs when a number can be defined two ways or sourced from two places.
1. Definitions workshop Week 1 Harriet runs a working session with Finance and the people who use the numbers. We turn your board pack KPIs into written definitions, including edge cases like credits, returns, and “active” status. You’ll leave with a definitions list we can test against the data. 2. Source walk-through Week 1 Tom and Ben walk through the systems and files that could supply each KPI. We document what tables exist, what keys join, what refresh looks like, and what access is needed. Where a KPI cannot be supported, we log the gap and the reason in a data gaps list. 3. Model and measures plan Week 2 Tom outlines the dataset and semantic model so your build has a stable shape. Aisha specifies the measures, including calculation logic, grain, and filter behaviour where it changes totals. We’ll review any contested definitions while they are still text on a page, not a chart. 4. Wireframes and handover Week 3 Aisha maps report pages, navigation, and core interactions so your team knows what to build first and how filters should behave. Ben pulls the work into a handover pack, including the governance and workspace plan, and we walk your team through it in a handover call.
KPI definitions pack
A written list of KPIs with agreed definitions, owners, and edge cases, so “margin” and “active customer” mean one thing across Finance, Sales, and Ops.
DATA SOURCE AUDIT AND ACCESS MAP
A source-by-source view of what data we expect to use, what access is required, who grants it, and any constraints like refresh limits or missing keys.
DATASET AND MODEL BUILD PLAN
A clear outline of the dataset structure and relationships, written so your internal team or partner can build the semantic model without guesswork.
Measures specification and library outline
A measures list with DAX logic notes, grains, and filter behaviour, so Finance can sign off the maths and developers can implement consistently.
REPORT WIREFRAMES AND NAVIGATION MAP
Wireframes for the key pages with navigation, slicers, and interaction notes, so build starts from an agreed layout and users get predictable behaviour.
GOVERNANCE AND WORKSPACE PLAN
A plan for workspaces, permissions, and ownership, including who can publish, who can certify datasets, and how you stop sensitive measures leaking into the wrong audience.
What it costs
Choose the tier based on how many sources and KPIs we need to pin down. If you are unsure, we will recommend the right fit after the Week 1 sessions.
Priced items
Next steps
If you’re ready to lock this in, we’ll book the workshop and send the access checklist so Week 1 can start without waiting on IT.
1. Sign the proposal and pay the 50% booking invoice. 2. Book the workshops and confirm attendees for Finance, Ops, and IT. 3. Share initial system access or nominate who will grant it, and we’ll begin Week 1.
Signature
Fee summary
Payment
50% is due to book the work when you sign. The other 50% is due when we hand over the finished Power BI reporting blueprint. Invoices are payable within 14 days.
Schedule. We run this over three weeks: Definitions workshop and source walk-through in Week 1, model and measures plan in Week 2, then wireframes and handover in Week 3. Dates are confirmed when booked.
Your inputs. Before Week 1, you will introduce us to the right people for KPI definitions and give us access to the systems in scope. If access is delayed, we will pause and replan rather than guess.
Data access. We will tell you which sources we expect to use and what access we need. If a key source is blocked by permissions, licensing, or an unavailable API, we will record it in the access map and adjust scope.
Changes
If you add new KPIs, sources, or report pages after we have agreed the Week 1 definitions, we will write the change down and price it before we do the extra work. Nothing runs on assumptions.
Sign-off points. We will ask for written sign-off on the KPI definitions pack and the measures specification before we finish wireframes. That sign-off is what stops “margin” or “active customer” changing halfway through build.
What you own. Once the final invoice is paid, you own the documents we produce for the Power BI reporting blueprint, including the KPI definitions pack, model plan, measures spec, wireframes, and governance plan. We keep our templates.
Confidentiality. We treat your data, numbers, and internal definitions as confidential. We will only share them within our four-person team working on your project, and we will not use them in marketing without your written OK.
