Power BI Dashboard and Report Development: How to Write a Clear Brief

01 / Users and decisions

Start with the people and the actions

List the audiences separately. A finance director reviewing month-end performance needs a different view from an analyst investigating transactions or a procurement manager chasing overdue approvals.

For each audience, write down the question they need answered, when they will use the information and what they will do next. Include the number of users, their familiarity with Power BI and whether they work on a laptop, phone or shared meeting screen.

Choose the essential decisions for the first release. Put additional countries, historical analysis and future integrations into a separate backlog, with a named person responsible for approving scope changes.

02 / Measures and accountability

Define each KPI before agreeing the visuals

A label such as “spend”, “savings” or “on-time approval” is not a complete definition. Record the calculation, business meaning and owner of each measure.

• Calculation and scope: numerator, denominator, unit, currency and exclusions.
• Time rules: reporting period, relevant date, calendar and treatment of late changes.
• Interpretation: target, threshold and the action a change should trigger.
• Approval: the business owner who will resolve disputes and sign off the result.

For on-time approvals, agree whether the denominator includes all items due in the period or only completed items, how reopened items count and whether weekends affect the deadline. Bring worked examples and a trusted comparison report so those choices can be checked.

03 / Source data and readiness

Explain where the data comes from

List the systems, files, tables or approved interfaces needed, together with their owners and access arrangements. Provide representative samples, field definitions, expected volumes and the history required.

Specify what one row represents: an invoice, an invoice line or an approval event. Identify the keys that connect sources, such as supplier and entity identifiers. Mixing different levels of detail can produce misleading totals.

Be explicit about duplicate records, missing dates, inconsistent supplier names and spreadsheet adjustments. Agree which issues must be fixed at source, which transformations belong in the reporting solution and who owns each task. If access or quality is uncertain, ask for a discovery stage before committing to the full build.

04 / Deliverables and layout

Specify the report experience, not just the charts

In everyday conversation, “dashboard” often means any reporting screen. In Power BI, a dashboard is a single-page canvas in the Power BI service, often using tiles from reports. A report has one or more pages and supports filtering and deeper exploration. Microsoft explains the difference between dashboards and reports.

State whether you need an interactive report, a service dashboard or both. An overview page within a report may meet the need without a separate dashboard.

Sketch the journey from summary to detail. Define page purpose, default filters, comparisons, drill-through and navigation. Include any mobile layout, export or meeting-pack requirements, plus accessibility needs such as readable labels and meaning that does not depend on colour alone. Review a simple wireframe with representative users before polishing the visuals.

05 / Access and distribution

Agree who can see and change what

Create an access matrix covering viewers, editors, administrators and external users. For each group, specify which entities, regions or teams they may see, how they receive the report and whether they may export or reuse the underlying data.

If users must see different rows, describe the required row-level security (RLS) rules and test identities. A country manager might see one country while a group finance user sees all entities. Include users who should see no data.

Confirm workspace roles carefully: Microsoft’s RLS guidance explains that workspace Admin, Member and Contributor roles are not restricted by RLS. Ask IT and the delivery team to confirm the sharing method, licensing and access-removal process before sign-off.

06 / Refresh and freshness

Say when the figures must be ready

“Daily refresh” does not say how current the information needs to be. Specify the source cut-off, reporting deadline, time zone and acceptable delay. For example, figures through the previous working day may need to be ready for a 09:00 UK review.

Separate source availability from the time Power BI finishes updating. Agree how users will see the last successful refresh and the period covered, what happens after a failure and who investigates.

Ask the developer to recommend the connection and refresh approach against those needs. Confirm any gateway, credentials, capacity and licensing dependencies; feasible behaviour varies by configuration, as Microsoft’s data refresh guidance explains. Request frequent updates only where the decision needs them.

07 / Validation and sign-off

Agree what will count as accepted

Acceptance criteria should describe evidence, expected results and an approver. “The report looks right” is too subjective to close a project confidently.

• Accuracy: reconcile agreed periods and entities to approved source totals, with an explicit tolerance and explained differences.
• Business rules: check blanks, duplicates, cancelled transactions, reopened items and period boundaries.
• Usability: representative users complete the priority tasks with the intended filters and navigation.
• Security and operation: test permitted and denied access, refresh completion and failure handling.
• Performance: agree response-time targets using specified data volumes, devices and realistic user conditions.

Name the people performing user acceptance testing, their available review dates and the person authorised to sign off. Record defects and distinguish fixes from new requirements. Agree how unresolved issues affect release.

08 / Ownership after launch

Include handover in the scope

Identify the business owner and technical support owner. Specify the editable report and model files, measure definitions, source mappings, access rules and refresh instructions your team needs to maintain the solution.

Include training, administrator handover, credential ownership, a support period and a route for future changes. Confirm who handles source-system changes or new KPIs. Set a review date to check whether people use the report and whether it supports the intended decisions.

An illustrative brief

From a broad request to a useful requirement

The following is a fictional finance and procurement example, not a client result.

The next discussion can resolve data quality, page layouts, performance targets, budget and milestones. It starts from a shared business requirement.

Your starting point

Copyable Power BI briefing checklist

Select and copy the text below into your project brief. Fill in the answers and mark unknowns with an owner and a date for resolution.

POWER BI DEVELOPMENT BRIEF

[ ] Business purpose and decisions this will support:
[ ] Users, team sizes, report owner and sign-off owner:
[ ] First-release priorities and explicit exclusions:
[ ] KPIs: definition, formula, unit, period, exclusions and owner:
[ ] Targets, thresholds and action when a measure changes:
[ ] Data sources, owners, access and representative samples:
[ ] Data grain, history, joins and known quality issues:
[ ] Responsibility and timing for data fixes:
[ ] Deliverables: report pages, service dashboard or both:
[ ] Layouts, filters, drill-through, mobile and export needs:
[ ] User groups, permitted data and RLS test scenarios:
[ ] Workspace, distribution method and licence assumptions:
[ ] Source cut-off, freshness deadline, refresh and time zone:
[ ] Gateway, credentials, monitoring and failure owner:
[ ] Reconciliation totals, tolerances and edge-case tests:
[ ] User tasks, response-time targets and test conditions:
[ ] Acceptance evidence, approvers and defect process:
[ ] Documentation, source files, training and handover:
[ ] Ongoing support, change ownership and review date:
[ ] Budget, milestones, dependencies and open questions:

Use the completed brief to ask each delivery partner to state assumptions, exclusions, dependencies and acceptance evidence in its proposal. This makes the conversation about a usable reporting solution, with a clear basis for delivery.