Most Power Platform programmes do not fail because of the technology. Microsoft has done the hard part. The platform is mature, the integrations are extensive, and the tooling is more capable today than at any point in its history. Programmes fail because the wrong things were assumed before a single environment was provisioned or a single licence was bought.

The assumptions are rarely dramatic. They accumulate quietly, in the gap between what was discussed in a meeting and what was actually verified. A licensing model chosen without modelling the user population. A DLP policy left as a default because nobody asked who owned it. An on-premises data gateway that was never confirmed as a requirement until the integration architect raised it six weeks into build.

By then, the cost to correct is not the cost of the original decision. It is the cost of everything built on top of it.

The single most common finding in a VE3 pre-discovery engagement is not a technology gap. It is an assumption that was never turned into a verified answer.

The Assumption Problem Is Structural, Not Accidental

Organisations approach Power Platform in one of two ways. The first group starts with a proof of concept: a small team builds something useful, it gains traction, and before long there is a business case for a broader programme. The second group procures a full programme from the outset, often off the back of a Microsoft licensing review or a broader digital transformation initiative.

Both paths share the same structural problem. The enthusiasm of early delivery compresses the time spent on the questions that matter most. Business leaders want to see output. Procurement teams want to see a scope. IT teams want to get into build. In that environment, assumptions fill the space that verified answers should occupy.

Research consistently shows this pattern at scale. Organisations that deploy without governance policies in place from the start typically discover that 20 to 30 percent of existing flows violate enterprise data handling requirements. Rescue engagements routinely uncover 40 to 60 percent more Power Platform assets than IT leadership estimated, including shadow apps connecting to production data and critical flows with no monitoring, no designated owner, and no support path.

These are not edge cases. They are the predictable output of programmes that moved from aspiration to build without working through the questions in between.

The Assumptions That Cause the Most Damage

Not all assumptions carry the same weight. Some surface early and are cheap to correct. Others sit beneath the surface until they intersect with delivery, at which point they are expensive, time-consuming, and sometimes programme-threatening to resolve.

The following categories consistently produce the highest-cost corrections.

Licensing model chosen before usage is understood

Choosing the wrong licensing model is the single most common cost mistake in Power Automate deployments. The per-user Premium licence, the per-flow Process licence, and the unattended RPA add-on each serve materially different scenarios, and the economics between them diverge sharply depending on user volumes, automation frequency, and whether processes need to run without a logged-in user.

The M365 E3 and E5 seeded entitlements add further complexity. Standard connector flows are included, but the moment a flow touches a premium connector such as SQL Server, Dataverse, or any third-party API, the free tier ends and a paid licence is required. Organisations routinely discover this not in planning but when a flow breaks in testing because a premium connector was added mid-build.

Unattended RPA is the most frequently under-budgeted line item. Each concurrent unattended bot requires the Process licence plus an unattended add-on, and if Microsoft-hosted machines are used, there is an additional cost per bot per month. Organisations that size their automation programme around process count rather than concurrency consistently over-spend or under-provision.

DLP and tenant governance left as defaults

Every Power Platform tenant has a default environment. Every licensed M365 user can create apps and flows in it. Without a deliberate environment strategy, the default environment becomes the place where everything gets built: proof-of-concept apps that connect to production databases, flows that route sensitive data through personal connectors, automations that no individual in IT has reviewed.

DLP policies control which connectors can be combined in a flow. Absent explicit configuration, they do not prevent business connectors from being paired with personal ones. The downstream risk is not theoretical: a finance analyst who builds a flow that exports budget data to a personal OneDrive folder is exercising a capability the platform allows by default. The compliance exposure only surfaces at a GDPR or audit review, by which point the flow may have been running for months.

Remediating DLP policy gaps after apps and flows are in production is significantly more complex than establishing policy at the outset. Changing a connector classification in a live DLP policy can break existing flows immediately, forcing a triage of everything in the affected environment before the change can be applied.

InfoSec and procurement brought in too late

Information Security and procurement are rarely involved in the early scoping of a Power Platform programme. They are typically engaged once there is something concrete to review: an architecture document, a licensing proposal, or a build plan. By that point, the decisions that would have been shaped by their input have already been made.

The consequences are predictable. InfoSec raises questions about conditional access policies, connector approvals, and CASB tooling that inspect or block Power Platform traffic. These are legitimate concerns that need to be resolved before go-live, but resolving them against a build that did not account for them is a redesign exercise, not a review.

In regulated environments, ISO 27001 and Cyber Essentials controls introduce additional architecture constraints. Organisations operating under these frameworks that do not involve their compliance function at discovery stage consistently encounter rework in the final phases of delivery.

The on-premises data gateway treated as a configuration detail

Any Power Platform use case that integrates with an on-premises system requires an On-Premises Data Gateway. This is a known requirement, well documented by Microsoft. It is also one of the most frequently confirmed late in the engagement cycle.

The gateway requires a dedicated server or virtual machine, network access to the on-premises data source, and appropriate service account configuration. In organisations with change control processes and server provisioning queues, lead time for this infrastructure can be measured in weeks. A discovery that confirms the gateway requirement in week six of a planned ten-week build is not identifying a problem; it is documenting one that has already compressed the remaining timeline.

The question to resolve is simple: which of the target use cases connect to on-premises systems? Answered in pre-discovery, it costs nothing. Answered during build, it costs the programme.

CoE ownership assumed rather than agreed

A Power Platform Centre of Excellence is not a technology. It is an operating model: a defined set of owners, processes, standards, and governance mechanisms that allow the platform to scale without becoming ungoverned. It requires someone to own it, and that owner needs to be named before the programme begins, not appointed once delivery is complete.

Programmes that treat CoE establishment as a post-go-live activity consistently experience the same outcome. The platform grows, maker activity accumulates, and by the time governance is applied retrospectively, there are dozens of apps and flows in production that pre-date any standards. Rationalising that estate is significantly harder than governing it from the outset.

The question of CoE ownership also surfaces the broader question of maker governance: who can build, in which environments, against which data sources, subject to which approval processes. These questions have no good answers after the fact.

What a Pre-Discovery Engagement Surfaces

The purpose of a structured pre-discovery is not to produce a report. It is to convert assumptions into verified answers before those answers have a cost consequence.

A well-structured pre-discovery works across the full breadth of the programme: licensing model and cost, tenant and environment configuration, data and integration architecture, security and compliance obligations, infrastructure dependencies, governance design, user adoption planning, and ALM approach. These domains are interconnected. A decision taken in one domain routinely has consequences in another, and those consequences are only visible when the domains are assessed together.

The output is not a recommendation to proceed. It is a costed, risk-assessed, sequenced roadmap: which licensing model is genuinely cheapest for the specific usage profile, which answers trigger architecture or compliance constraints, and where the hidden cost and delivery traps sit. It is also a risk register, with named owners and mitigations, and a decision log that captures the rationale for architectural choices at the point they are made.

Organisations that complete this work before committing budget to build go to market with a procurement specification that reflects their actual requirements. Organisations that skip it discover their requirements mid-programme.

Key questions every organisation should verify before build begins:

What is the precise licensing model, and has it been modelled against actual user volumes and automation frequency?

Which use cases require premium connectors, and are those connectors approved under the current DLP policy?

Are any target systems on-premises, and has the gateway infrastructure been scoped and provisioned?

Has InfoSec reviewed the connector landscape and conditional access requirements?

Is CoE ownership named, and is there a maker governance model agreed before the first environment is created?

The Cost of Starting Without Answers

The argument for skipping pre-discovery is usually framed as speed. A discovery engagement takes time, and the pressure to demonstrate progress is real. What that framing misses is the cost comparison: the cost of a structured pre-discovery against the cost of the rework it prevents.

Licensing corrections mid-programme require re-procurement, re-provisioning, and in some cases redesign of flows built against the wrong licence model. DLP remediation in a live environment can break production flows and require a triage exercise before any governance change can be applied. Gateway infrastructure confirmed late compresses build timelines and introduces delivery risk. CoE governance applied retrospectively requires rationalising an estate that has already grown beyond easy management.

None of these costs are hypothetical. They appear in programme retrospectives with consistent regularity, described as surprises that were not surprises at all, but assumptions that were never tested.

How VE3 Approaches This

VE3's Power Platform pre-discovery and readiness framework works through over 100 questions across 11 domains, from licensing and security to RPA infrastructure and application lifecycle management. It is designed to surface the decisions that shape programme success before a single pound is committed to build.

The framework is available for any organisation to use independently. The value VE3 adds is turning the answers into a costed, risk-assessed, sequenced roadmap: understanding which answers trigger architecture constraints, where the hidden cost traps sit, and what the right delivery sequence looks like given the specific organisational context.

For Blue Light organisations and public sector bodies, the framework is available via Blue Light Commercial and established public sector frameworks, as a fixed-scope, time-boxed pre-discovery engagement.

About VE3

VE3 is a global technology and enterprise AI consultancy working with UK public sector and enterprise organisations on Microsoft Power Platform, automation (RPA), and Centre of Excellence programmes. Our discovery-led approach turns an unclear requirement into an evidenced, costed, and risk-assessed specification. To discuss how our Power Platform Pre-Discovery & Readiness Framework applies to your organisation, contact your VE3 representative.