Power BI project plan documents usually describe the wrong project. They list the dashboards somebody asked for, name a go-live date, and say almost nothing about the work that actually consumes the weeks: agreeing what each number means, and extracting it from systems that quietly disagree with one another.
That is why so many rollouts arrive late while everyone insists nothing went wrong. Nothing did go wrong technically. The plan simply scheduled the visible part — the reports — and left the invisible part, the reconciliation and the definitions, to be discovered in flight. A good Power BI project plan front-loads exactly that discovery, and a good requirements checklist is what forces it into the open before anyone commits to a date.
This guide sets out the plan structure that works, phase by phase, and the requirements checklist that goes with it: the business questions, the data questions, the governance questions, the roles, the timeline, the risks and the acceptance tests. Our data visualisation and data warehousing teams run these projects for UK businesses every month, and if you are still costing the work, the companion guide to Power BI implementation cost covers the budget side in detail.
Table of contents
- Why a Power BI project plan fails before the first dashboard
- What every Power BI project plan must contain
- The six phases of a Power BI project plan and what each delivers
- Power BI project plan requirements: the business questions
- Power BI project plan requirements: data and technical questions
- Governance and security requirements in your Power BI project plan
- Roles, RACI and the resourcing a Power BI project plan needs
- Timeline and milestones: how long a Power BI project plan really takes
- Risks and assumptions every Power BI project plan should name
- Measuring success after your Power BI project plan is delivered
- Frequently asked questions about a Power BI project plan
- References
Why a Power BI project plan fails before the first dashboard
Failure here is rarely dramatic. There is no outage, no rejected architecture, no vendor dispute. The project just keeps needing one more fortnight, and the reason is almost always something the plan never mentioned.
The demo was built on an export, the rollout is not
Nearly every Power BI initiative starts with a prototype somebody assembled from a spreadsheet in an afternoon. It looks finished. It has no refresh schedule, no security model, no reconciliation against the ledger and no owner. Turning it into a production asset is the entire project, and estimating from the prototype is the single most common mistake a Power BI project plan makes.
Requirements arrive as a wish list of charts
When you ask stakeholders what they need, they describe visuals. Ask instead which decisions they make each week and what evidence would change those decisions, and the list shortens dramatically. A requirements checklist built from decisions produces perhaps six reports where the wish list produced thirty, and the six get used. Anchor the Power BI project plan to that shorter list.
Nobody owns the definition of the numbers
If finance, sales and operations each define revenue differently, somebody has to arbitrate before a single measure can be written. That arbitration is a business process, not a technical task, and it routinely adds weeks to a Power BI project plan that budgeted zero for it. The dashboard is usually the first place anyone has compared the definitions side by side.
The plan has no exit gate between phases
Without a defined gate, phases overlap until the whole project is simultaneously 80% complete and unfinishable. Each phase in a Power BI project plan needs one named person who can say “this is signed off” and one artefact that proves it — a metric definition document, a profiling report, a passed reconciliation test.
What every Power BI project plan must contain
A plan that survives contact with a real business has seven sections. Anything shorter is a schedule, not a plan, and a schedule cannot tell you whether you are allowed to move on.
Scope written as decisions, not deliverables
State which recurring decisions the platform supports and who makes them. “Weekly stock replenishment decision, made by the operations manager every Monday” is scope. “Inventory dashboard” is a wish. Everything downstream in the Power BI project plan — sources, granularity, refresh timing — falls out of the decision statement rather than being argued separately.
A named owner for every source system
Each source needs one person who can grant access, explain the schema and confirm which records count. Without that name in the Power BI project plan, week two turns into a search for whoever understands the ERP, and that search is usually the first slip in the schedule.
Acceptance criteria that mention reconciliation
“The report is complete” means nothing. “Revenue in the report matches the finance ledger for the last three closed months, to within £50” is testable, and it is the clause that stops a dashboard being quietly distrusted after launch. Write reconciliation tolerances into the requirements checklist, not into a verbal understanding.
A phase structure with a gate at the end of each
Phases without gates blur. Give every phase a deliverable, a reviewer and a date, and make the next phase conditional on the previous one being accepted. This is the mechanism that turns a Power BI project plan from a wall chart into a control.
| Plan section | What it must state | Evidence it is done |
|---|---|---|
| Scope | Decisions supported, audiences, explicit exclusions | Signed scope statement naming what is out |
| Metric definitions | Formula, filters, grain and owner per measure | Definition sheet approved by finance |
| Data sources | System, owner, access route, refresh window | Connection tested from the build environment |
| Architecture | Storage mode, semantic model, workspace layout | Model diagram reviewed and agreed |
| Security | Row-level rules, sharing model, licence assignment | Security matrix tested with real accounts |
| Acceptance | Reconciliation tolerances and performance targets | Test pack passed and countersigned |
| Run and support | Refresh monitoring, change route, ongoing owner | Handover document accepted by the owner |
The six phases of a Power BI project plan and what each delivers
Most successful UK engagements follow the same six-phase shape. The names vary; the sequence does not, because each phase produces the input the next one needs.
Phase 1 — Discovery and KPI definition
Interview the decision-makers, not the report requesters. Produce a decision register, a draft metric definition sheet and a prioritised backlog, which together become the opening section of the Power BI project plan. This phase ends when finance has agreed the formulas in writing. Microsoft’s own Fabric and Power BI adoption roadmap treats this alignment work as a precondition rather than an afterthought, and so should your plan.
Phase 2 — Data assessment and source profiling
Connect to every source and profile it: row counts, null rates, duplicate keys, date ranges, referential gaps. The output is a data readiness report that lists what is usable, what needs cleaning and what simply does not exist yet. Nasty surprises found here cost days; found in phase four they cost weeks, which is the whole argument for putting profiling early in a Power BI project plan.
Phase 3 — Semantic model and transformation build
Build the star schema, the relationships and the DAX measures. Microsoft’s star schema guidance is the reference point, and deviating from it is the most reliable way to produce a model that performs badly and cannot be extended. This is the phase where an experienced modeller earns their rate.
Phase 4 — Report build and iterative review
Build in short cycles with the actual users in the room. Two review sessions per report, a week apart, catches more than a formal UAT phase at the end. Reports are quick once the model is right; if this phase is slow, the model is wrong and you should go back rather than push on.
Phase 5 — Governance, security and testing
Apply row-level security, set up the workspace and deployment structure, run the reconciliation pack and confirm refresh performance under real data volumes. Test with borrowed accounts from each security role, not with an administrator account that sees everything.
Phase 6 — Go-live, training and handover
Publish, train by audience rather than by feature, and hand over a document that says who owns each dataset and how a change gets requested. A Power BI project plan that stops at publication leaves an orphaned platform, which is how good builds decay within two quarters.
| Phase | Typical duration | Key deliverable | Exit gate |
|---|---|---|---|
| 1. Discovery and KPI definition | 1–3 weeks | Decision register, metric definitions | Finance signs the definitions |
| 2. Data assessment | 1–3 weeks | Data readiness report | Every source profiled and rated |
| 3. Semantic model | 2–6 weeks | Star schema and DAX measures | Measures reconcile to source |
| 4. Report build | 2–5 weeks | Reviewed report set | Users accept each report |
| 5. Governance and testing | 1–3 weeks | Security matrix, test pack | Reconciliation passes |
| 6. Go-live and handover | 1–2 weeks | Training and handover pack | Named owner accepts the platform |
Power BI project plan requirements: the business questions
This half of the checklist costs nothing to complete and prevents most of the rework in a Power BI project plan. Run it before anybody opens Power BI Desktop.
Which decisions must the reports support?
List each recurring decision, its owner, its frequency and the evidence that would change it. If a proposed report does not appear against any decision, it is a nice-to-have and belongs in a later phase — that single test usually removes a third of the backlog.
How is every metric defined, precisely?
For each measure, capture the formula in words, the filters applied, the grain, the currency and calendar treatment, and the person who owns the definition. Revenue net of returns, excluding intercompany, on invoice date, is a different number from revenue on despatch date, and both will be defended.
What granularity and history does each audience need?
A director wants monthly trends over three years; a supervisor wants yesterday by shift. These are different models, and pretending otherwise produces a slow report that satisfies neither. Record the required grain and the required history separately for each audience.
Who sees what, and what must they never see?
Capture the restriction rules in business language now — “regional managers see only their own region”, “salary data is finance only”. These become row-level security rules in phase five, and retrofitting them after the model is built is expensive.
What does “correct” look like on day one?
Agree the reconciliation source and the tolerance. Without it, launch day becomes an argument about whether the numbers are right, and the platform never fully recovers from that first impression.
Power BI project plan requirements: data and technical questions
The technical half is where the estimate lives. Every unanswered question here is an unpriced risk in your Power BI project plan.
Source system inventory and access
For each system, record the owner, the access method, the environment you will connect to, whether a gateway is required, and how credentials are managed. On-premises sources need an installed data gateway, and arranging one through a change process is frequently the first real dependency the plan hits.
Refresh frequency, latency and windows
Ask what decision depends on freshness, then set refresh against that rather than against a preference for real time. Microsoft’s data refresh documentation sets out the limits per licence tier, and those limits shape the architecture more than most people expect.
Historical depth, volume and growth
Capture row counts today and expected growth over three years. A model that is comfortable at forty million rows behaves differently at four hundred million, and the storage mode decision — import, DirectQuery or a mix — follows directly from these figures.
Data quality rules and reconciliation
Define what a valid record looks like, what happens to orphans and duplicates, and which system wins when two disagree. This is data management and analytics discipline rather than reporting work, and it is the single largest determinant of how long phase three takes.
Environment, deployment and change route
Decide now how a change moves from development to production. Deployment pipelines exist for exactly this, and a plan without a promotion route ends up with people editing reports in production on a Friday afternoon.
| Category | Question to answer | Evidence of a real answer |
|---|---|---|
| Decisions | Which recurring decisions does this support? | Decision register with named owners |
| Metrics | How is each measure defined and by whom? | Definition sheet countersigned |
| Sources | Who owns each system and grants access? | Named contact plus a tested connection |
| Freshness | What decision depends on how current the data is? | Refresh schedule mapped to decisions |
| Volume | How many rows now and in three years? | Row counts profiled from source |
| Quality | Which system wins when two disagree? | Written precedence and matching rules |
| Security | Who must never see which rows? | Restriction rules in business language |
| Acceptance | What tolerance counts as reconciled? | Agreed figure and comparison source |
Governance and security requirements in your Power BI project plan
Governance is where a reporting exercise becomes a platform. It is also the part a Power BI project plan most often defers, and deferring it is what produces four hundred workspaces and no certified dataset.
Row-level security and who authors the rules
Row-level security is straightforward to implement and hard to specify. The rules belong to the business, the implementation belongs to the modeller, and both need to appear in the Power BI project plan with a test case each. Microsoft’s row-level security guidance covers the mechanics; the specification is yours to write.
Workspace structure and deployment pipelines
Agree a naming convention, a workspace per domain rather than per person, and a development-test-production path using deployment pipelines. Retrofitting this later means moving content and breaking links, so it belongs in phase one even though it delivers nothing visible.
Certified datasets and a single version of each number
Endorsement lets you mark one dataset as the authoritative source and discourage duplicates. Without it, three teams build three versions of the same measure and the platform loses the argument it was built to end. Decide who can certify, and what evidence they need before doing so.
Audit, retention and data protection duties
Personal data in a report carries the same obligations it carries anywhere else, and the ICO’s data minimisation guidance applies to a dashboard exactly as it applies to a database. Treat cybersecurity and access review as recurring operational tasks with named owners, not as a one-off configuration step, and align them with your wider IT governance approach.
Roles, RACI and the resourcing a Power BI project plan needs
The resourcing question that sinks projects is not “do we have a developer” but “does the business have time”. Half the effort in a Power BI project plan is business effort, and it is rarely booked.
The roles you cannot outsource
An executive sponsor who can settle a definitional dispute, a data owner per source system, and a set of end users who will attend reviews. No consultancy can supply these, and their absence shows in a Power BI project plan within a fortnight.
The roles you can bring in
A data engineer for extraction and transformation, a modeller for the semantic layer and DAX, a report designer, and a part-time delivery lead. On smaller engagements two people cover all four, which is fine as long as the plan does not assume they can work in parallel with themselves.
How much time the business actually needs to give
Budget roughly one day per week from the sponsor’s team across the build, concentrated in phases one and four. A Power BI project plan that shows business input as a single two-hour kick-off is not a plan; it is an assumption that will be tested and found wanting.
| Role | Accountable for | Typical time commitment |
|---|---|---|
| Executive sponsor | Settling definition disputes, funding | 2–3 hours per fortnight |
| Data owner per source | Access, schema knowledge, record rules | Half a day per week in phases 1–2 |
| Finance representative | Signing metric definitions and tolerances | 1 day total, front-loaded |
| Data engineer | Extraction, transformation, refresh | Full time in phases 2–3 |
| Semantic modeller | Star schema, relationships, DAX | Full time in phase 3 |
| Report designer | Layout, interaction, accessibility | Full time in phase 4 |
| Platform administrator | Workspaces, licences, security, refresh | Ongoing, part time |
Timeline and milestones: how long a Power BI project plan really takes
Elapsed time is driven by source complexity and business availability, not by the number of reports. Two projects with identical report counts routinely differ by a factor of three.
The shape of a typical eight to twelve week delivery
A departmental build with two clean cloud sources and agreed definitions runs four to six weeks. A cross-functional build touching an on-premises ERP, a CRM and a spreadsheet estate runs ten to sixteen. The difference is almost entirely phases two and three, so weight the Power BI project plan accordingly.
What reliably makes it longer
Undocumented legacy schemas, seasonal business availability, unresolved metric disputes, and any dependency on a third party for access. Each of these deserves a line in the risk register of your Power BI project plan with an owner and a trigger date.
Milestones worth putting in front of a board
Definitions signed, data readiness accepted, first measure reconciled, first report accepted, security tested, platform handed over. These six are meaningful to non-technical stakeholders because each one is binary, which is exactly what a steering group needs.
Risks and assumptions every Power BI project plan should name
Every plan carries assumptions. The difference between a good and a bad Power BI project plan is whether those assumptions are written where a sponsor can read them.
Risks that appear on nearly every engagement
Source data quality below expectation, key personnel unavailable, definitions reopened after sign-off, and refresh performance failing at production volume. Naming these up front changes the conversation when one lands, because it is then a known risk materialising rather than a surprise.
Dependencies you do not control
Gateway installation through a change board, third-party vendor access to a hosted system, licence procurement, and the finance close calendar. Each has a lead time measured in weeks, and each should carry a date by which it must be resolved before the schedule moves.
Assumptions that quietly become change requests
That the ERP has a usable API, that historical data is complete, that one definition of a customer exists, that the business can review within five working days. Write each one down and have the sponsor acknowledge it — this is the cheapest form of strategic IT planning available.
| Risk | Likelihood | Practical mitigation |
|---|---|---|
| Metric definitions reopened mid-build | High | Written sign-off gate before modelling starts |
| Source data quality below expectation | High | Profile every source in phase two, before estimating |
| Gateway or access delayed | Medium | Raise the change request in week one |
| Refresh too slow at real volume | Medium | Load-test with full history before go-live |
| Business reviewers unavailable | Medium | Book all review sessions at kick-off |
| Adoption stalls after launch | Medium | Train by audience and retire the old reports |
Measuring success after your Power BI project plan is delivered
A plan that ends at publication cannot tell you whether the investment worked. Define the measures inside the Power BI project plan before launch, while nobody has a reason to argue about them.
Adoption measures
Weekly active users by audience, reports opened per user, and the number of legacy spreadsheets retired. The last one is the honest measure: if the old spreadsheet is still being maintained, the platform has not replaced anything.
Quality and reliability measures
Refresh success rate, time to refresh, and the number of data disputes raised per month. A falling dispute count is the clearest evidence that the definitions in your Power BI project plan actually settled the arguments they were meant to settle.
Business outcome measures
Time saved preparing the weekly pack, decisions made earlier in the cycle, and any measurable operational effect the reports were built to enable. Tie these back to the decision register from phase one and the cost optimisation case writes itself.
Frequently asked questions about a Power BI project plan
How long should the planning phase itself take?
One to three weeks for most mid-market builds, and that time is the cheapest part of any Power BI project plan. Less than a week means the definitions have not been tested; more than a month usually means the scope is too broad and should be split into two deliveries.
Do we need a data warehouse before we start?
Not always. Small builds with two or three clean sources work directly against them. Once you have several systems, meaningful history or heavy transformation, a warehouse pays for itself quickly — and the assessment in phase two tells you which situation you are in.
Who should own the Power BI project plan internally?
Someone from the business with authority over the numbers, supported by IT rather than led by it. A Power BI project plan owned purely by IT tends to deliver technically correct reports that nobody uses, because the decisions were never the starting point.
What should we do if the definitions cannot be agreed?
Escalate to the sponsor with the two competing definitions written down, and ask for a decision rather than a discussion. Build both only if the business genuinely needs both, and label them unmistakably in the report.
How much of the plan changes if we adopt Microsoft Fabric?
The phases and the requirements checklist in your Power BI project plan do not change. What changes is the architecture in phase three and the licensing decision, since capacity-based licensing alters both cost and capability at scale.
When should we plan the second phase of work?
At handover, not before. Six weeks of real usage tells you far more about what to build next than any backlog written during discovery, and it keeps the second Power BI project plan grounded in evidence.
