A practical guide to commissioning Power BI
Power BI Implementation Services: What Should Be Included from Discovery to Handover?
A useful implementation takes more than a finished report. Define the delivery, responsibilities and evidence needed to move from discovery to a service your team can run.
At a glance
Agree the whole journey
- Discover and prepareScope, data readiness and delivery dependencies.
- Build and validateModelling, governance and evidence-based testing.
- Launch and ownRollout, training, support and handover.
On this page
Power BI implementation services should cover the route from an agreed business need to a reliable, governed reporting solution with clear ownership. That includes discovery, data preparation, modelling, testing, rollout and the skills needed to operate it after launch.
When comparing proposals, look for tangible deliverables, client dependencies and approval points at each stage. A report may be complete while access, refresh, documentation or support arrangements remain unresolved.
This guide focuses on the wider implementation. For the detailed requirements behind individual dashboards and reports, use our guide to writing a clear Power BI reporting brief.
01 · Establish the scope
Discovery: agree the outcome and the boundaries
Discovery should produce a shared delivery plan, not simply a list of reports. Identify the business problem, the first user group, the decisions the solution will support and what a successful first release looks like. Include business sponsors, operational users, data owners and IT early.
Ask for a prioritised scope, an outline architecture, dependencies, risks and named decision-makers. Agree what is excluded: source-system changes, historical data cleansing, new integrations and ongoing support can each materially affect cost and timing.
Before moving on: both sides should understand the proposed first release, who can approve it and which assumptions still need testing. If data access is uncertain, use a bounded discovery phase before committing to a fixed build estimate.
02 · Establish the foundations
Data readiness: prove the sources can support the solution
A working connection does not establish that data is ready. The supplier should inspect representative records, history, volumes, identifiers and update patterns. Missing supplier codes, duplicate transactions or inconsistent entity names should appear in a documented issue log, with an owner and a treatment for each issue.
Confirm the route from source to Power BI, including any preparation layer, gateway requirement, credentials and refresh dependencies. Agree how source changes, failed loads and late data will be detected and handled. Make recurring infrastructure and licensing costs visible.
The client’s role: provide approved access, source-system expertise, representative samples and a person authorised to resolve data questions. Decide whether each quality issue will be corrected at source, handled in transformation or accepted as a documented limitation.
03 · Build a reusable foundation
Modelling: make the numbers consistent and maintainable
The semantic model is the layer that organises data and business calculations for reporting. The implementation scope should include its design, transformations, relationships, shared measures and documentation, rather than leave these hidden inside a finished report.
Ask how the model will handle the level of detail in each source, financial periods, organisational hierarchies and changes over time. For example, purchase-order lines and invoice lines cannot safely be treated as though they are the same record.
Microsoft’s star schema guidance explains why fact and dimension tables, consistent grain and well-designed relationships matter for model usability and performance. The supplier should explain the choices in business terms and reconcile key totals to agreed source records.
04 · Make control explicit
Governance: decide who can access, change and share content
Agree ownership and access before rollout. The design should cover workspaces, user groups, distribution, authoring permissions and any restrictions on the records different audiences can see. Ask the supplier to demonstrate access using representative user accounts, including a user who should be denied access.
Confirm the appropriate licensing and capacity for the intended audience, security requirements and release approach. Identify who approves sharing, manages membership and reviews access when people change roles. Where row-level security is required, include its configuration and validation in the scope.
Governance should fit the organisation’s existing policies and the scale of the solution. Microsoft’s implementation planning guidance covers these wider decisions, including workspaces, security, gateways and administration.
05 · Agree the evidence
Testing: validate the whole service before sign-off
User acceptance testing needs more than a demonstration of attractive pages. Agree test scenarios and expected results during discovery, then test the data, calculations, access, refresh process and main user journeys together.
- Accuracy: reconcile agreed totals and investigate differences, including exclusions and rounding.
- Security: check permitted and restricted views for representative roles.
- Reliability: test refresh, failure handling and recovery with realistic dependencies.
- Usability and performance: check everyday tasks using representative data volumes and agreed response expectations.
Keep evidence, a defect log and retest results. Name the business approver and agree which issues block release, which can be accepted and who owns any remaining work. Do not leave acceptance as “the dashboard looks right”.
06 · Release with a plan
Rollout: move into production in a controlled way
The supplier should document how development, testing and production will be separated, how versions are retained and how changes reach users. Choose an approach proportionate to the solution and available licensing; a complex release pipeline is not automatically necessary for a small deployment.
Start with a representative pilot group where practical. Agree the release window, user communications, access checks, support contacts and a fallback plan. Decide when existing reports can be retired, and whether a parallel run is needed to build confidence in the new numbers.
Microsoft’s content lifecycle guidance extends beyond deployment to support, monitoring and retirement. A supplier’s proposal should make that transition explicit.
07 · Prepare people to use it
Training: distinguish users, report owners and administrators
Training should reflect what each group will actually do. Users need to find the right content, interpret it, apply filters and raise questions. Internal report owners need to understand definitions and make agreed changes. Administrators and support teams need the operational steps for access, refresh and incident handling.
Ask for practical sessions using the delivered solution, supporting notes or recordings, and time for questions. Include process owners where users may be unclear about the underlying business process as well as the technology.
Agree how adoption will be reviewed after launch: for example, whether intended users can complete their main tasks and whether old spreadsheet workarounds are still needed. Attendance alone does not demonstrate readiness.
08 · Make ownership sustainable
Handover: leave a service the client can own
Handover should start during delivery. Name a business owner for priorities and definitions, a technical owner for the model and reports, and an operational owner for access, refresh and support. One person may hold several roles, but none should be assumed.
Request editable project files and agreed source artefacts, model and transformation documentation, a data dictionary, release instructions, test evidence and an operational runbook. Confirm where these are stored, the client’s rights to use and change them, and how authorised staff will manage credentials without relying on a departing individual.
Define any initial support period: its duration, coverage, response expectations and exit criteria. Separate defect correction from new features. The final check is practical: can the receiving team manage access, investigate a failed refresh and make a controlled change?
Implementation in practice
Reporting sits within a wider working process
In Denova’s global VAT team case study, an embedded developer brought files, approvals and task tracking together using Power Apps, Power Automate and SharePoint. A Power BI report gave stakeholders visibility of VAT task status.
The project involved mapping the existing process, demonstrating the solution early and adapting workflows when additional VAT categories and edge cases emerged during testing. Training also surfaced questions about the underlying business process.
It illustrates why implementation needs space for stakeholder feedback, testing and learning alongside the technical build. The case concerns a wider Power Platform solution with Power BI reporting as one component.
See how process mapping, testing and training shaped a solution that included Power BI reporting.
Copy into your scope document
Power BI implementation services checklist
Use this checklist when reviewing a proposal or planning delivery. Copy it into your working document and add a named owner, target date and approval evidence for each stage. Tick a stage when the agreed deliverables have been accepted.
| Check each stage | Supplier delivers | Client provides |
|---|---|---|
| [ ] Discovery | Supplier deliversAgreed scope, delivery plan, assumptions, risks and acceptance gates. | Client providesSponsor, user representatives, priorities, budget and decision-makers. |
| [ ] Data readiness | Supplier deliversSource assessment, quality log, connection and refresh design. | Client providesApproved access, samples, source experts and data issue owners. |
| [ ] Modelling | Supplier deliversDocumented model, transformations, shared measures and reconciliations. | Client providesBusiness definitions, reference totals and decisions on exceptions. |
| [ ] Governance | Supplier deliversWorkspace, access, distribution and licensing recommendations. | Client providesIT and security policies, user groups and approval owners. |
| [ ] Testing | Supplier deliversTest plan, results, defect log and retest evidence. | Client providesTest users, expected results, time for UAT and a sign-off owner. |
| [ ] Rollout | Supplier deliversRelease plan, versioned artefacts, fallback and support route. | Client providesRelease approval, communications and pilot participants. |
| [ ] Training | Supplier deliversRole-based sessions, user guidance and administrator walkthroughs. | Client providesAttendees, internal champions and time to practise. |
| [ ] Handover | Supplier deliversEditable files, documentation, runbook and agreed support terms. | Client providesNamed business and technical owners, storage and ongoing capacity. |
Make dependencies visible. If access, data corrections or client decisions are delayed, agree how the delivery plan changes. “Client to provide data” is too vague without a source, owner and date.
Before appointing a supplier
Compare the scope behind the price
Ask each supplier to separate discovery, build, rollout and ongoing support, and state the assumptions behind the estimate. Check what happens when testing reveals an additional requirement: who assesses the impact, approves the change and updates the plan?
Confirm third-party costs, documentation, editable artefacts, internal training and post-launch support explicitly. The right scope depends on your starting point; an established Power BI environment may need targeted work, while a first implementation needs more foundations.
A strong proposal makes the client’s commitments as clear as the supplier’s deliverables. Both are necessary for a solution that can be used and maintained.
Plan the next step
Trackbacks/Pingbacks