How to Scope a BI Project: Define Your Data Brief Before the First Call
Work through this before your first call with a consultancy. The clearer your brief, the better the match — and the faster you move.
What problem are we solving?
Most BI projects fail not because the technology is wrong but because the scope was wrong. The consultancy built dashboards that answered questions nobody had, connected data sources nobody trusted, and used tools nobody maintained after the project ended.
This guide helps you define your data brief before you talk to a consultancy. A data brief is not a technical specification. It is a plain-language document that says: here are the decisions we need to make, here is where the data lives, and here is what we already know and do not know. Consultancies who receive a clear data brief come back with much more useful proposals.
Questions to answer before you start
Work through each question. If you can't answer three or more, you're not ready to brief a consultancy yet — and that's fine. Come back when you are.
Not all the questions they could ask, but the ones they ask every week or every month and currently cannot answer quickly or confidently. Write them down as questions: "What is our current monthly recurring revenue by customer segment?" is better than "we need revenue reporting."
List every system: your CRM, your ERP, your e-commerce platform, your accounting software, any spreadsheets that people maintain manually. Include the name of the system and approximately how much data is in it.
The most expensive part of many BI projects is not the technical work; it is resolving disagreements about what a metric means. Do you and your head of sales agree on what "active customer" means? If not, write down both definitions.
BI dashboards that are built for a VP but used by an analyst look very different from dashboards built for the analyst. Naming the users upfront changes what the consultancy builds.
A BI project built on bad source data produces confident-looking wrong answers. If you know there are data quality problems in a source system, say so now. It changes the scope significantly.
If your company runs on Microsoft 365, Power BI is often the natural default. If you have a strong preference for another tool, or if a previous consultancy left you with an existing setup, the consultant needs to know.
A dashboard that nobody maintains is a dashboard that stops being trusted within six months. Is there an internal person who will own this? Will you need ongoing support from the consultancy? The answer changes the scope and the budget.
Typical project shapes
Most projects fall into one of these shapes. Which one sounds closest to yours?
BI audit and roadmap
The consultant reviews your data sources, talks to the key stakeholders, and produces a one-page data brief plus a prioritised implementation roadmap. No dashboards yet, but a clear plan for what to build and in what order.
Single dashboard build
One working dashboard covering one functional area (finance, sales, or operations), connected to live data sources, with handover documentation and training for the people who will use it.
Multi-dashboard rollout
A coordinated set of dashboards across multiple functions, sharing a common data model. Usually includes a data warehouse layer to handle the integration between source systems.
Full BI implementation
New data warehouse, full dashboard suite covering all major functions, governance setup, team training, and ongoing support model. Usually only justified at 100+ staff.
Red flags to watch for
-
They jump to showing you Power BI demos before asking about your data sources.
Tool demos before data discovery means they are selling you the output before understanding the input. The right sequence is always: understand the business questions, map the data sources, then discuss tooling.
-
They cannot name the person who will actually build your dashboards.
Many BI consultancies pitch with a senior person and deliver with a junior. Ask specifically who will be doing the data modelling and who will be on your weekly check-ins.
-
Their proposal does not include a data brief or requirements phase.
A BI project that skips requirements gathering will build the wrong thing confidently. The first deliverable should be a written document describing what is being built and why, before any tool setup begins.
-
They quote a fixed price without seeing a single data source.
BI project effort is highly sensitive to data quality and data volume. Anyone quoting a firm price without a data discovery phase is either padding heavily to cover unknowns or will hit you with change orders.
Pre-submit checklist
Tick these before you hit send. Consultancies that get well-scoped briefs respond faster and with better questions.
- I have written down the five to ten questions leadership asks most often and cannot currently answer quickly.
- I have listed every data source (CRM, ERP, spreadsheets) and can grant access to a consultancy.
- I know who will use the dashboards and can involve them in a brief requirements conversation.
- I have identified any known data quality issues in source systems.
- I know who internally will own and maintain the dashboards after the project ends.
- I have a rough budget range in mind.
- I know if there are any time-sensitive events (fundraise, M&A, board presentation) that affect the timeline.
Ready to submit your brief?
Takes 5 minutes. We'll match you to 2–3 boutique BI & Data Analytics consultancies. You'll hear back within 48 hours.