The causes of failure are almost always upstream of where the symptoms appear. A practitioner’s view on what separates the programmes that scale from the ones that quietly stall.

When a Power Platform programme is visibly in trouble - costs spiralling, security blocking go-live, adoption flatlining, a pilot that refuses to scale - the instinct is to look for the cause in the present. A delivery problem, a skills gap, the wrong partner. Almost always, it is none of those. The cause sits months upstream, in decisions made before a single app was built, at the point when the programme felt like it was going rather well.

That is the uncomfortable truth about this platform: most programmes that fail are lost at the start, not in delivery. The technology rarely lets you down. What lets you down is what you assumed before you began.

The most dangerous phase is the one that feels best

This is hard to see in the moment, because the early stage of a Power Platform programme is the most encouraging part. The tools demo brilliantly. A maker builds something genuinely useful in an afternoon. Momentum is real and visible to everyone. And precisely because building is so easy, planning starts to feel optional - even pedantic. Why labour over requirements and readiness when you could simply build?

The answer is that the things which decide success or failure are invisible at that stage. They surface later - as cost, as risk, as a wall you hit the moment you try to scale - and by then they are expensive to fix. The cheapest moment to get them right is the one moment everyone is most tempted to skip.

The mistakes that decide the outcome

After enough programmes, the failure modes become familiar. They are not exotic, and they are rarely technical. They are the same handful of upstream decisions, made on assumption rather than evidence.

Building before defining success. The most common starting error is to begin with the platform rather than the problem. A programme launches because Power Platform is available and the appetite is there - not because anyone has agreed what success looks like or how it will be measured. Vague problems produce vague solutions, scope creep, and automations nobody really needed. “We automated forty processes” is an activity, not an outcome; if no one can say what those forty processes saved, the number proves nothing. Without an agreed measure of value, the programme can never prove it worked - and anything you cannot prove, you eventually struggle to fund.

Choosing a licensing model before understanding usage. Licensing gets picked early, on the basis of the first price someone saw, long before anyone understands who will actually use what. Then the bill arrives. The classic version is buying per-user licences for an automation that should have been licensed per flow, or discovering that unattended automation needs an add-on no one budgeted for. The wrong model chosen on day one compounds for years - and it is almost never the platform that was expensive, but the assumption underneath it.

Treating governance as something to add later. Governance feels like bureaucracy when you have ten apps, so it is deferred. By the time you have three hundred - undocumented and scattered across ungoverned environments - governance is no longer a policy decision but a clean-up operation. Sprawl, shadow IT and data-loss risk are not failures of the technology; they are the predictable result of scaling adoption faster than control. Retrofitting governance costs many times what designing it in would have.

Engaging security and infrastructure too late. Information Security and the network team are brought in near go-live, to approve what has already been built - and that is when the programme meets the connector that will not be approved, the firewall that blocks the endpoint, the locked-down device that will not run the desktop agent. A late “no” from a function that should have been a partner from week one is among the most common causes of a stalled launch. The requirement did not change; it was simply discovered too late to design around cheaply.

Assuming readiness rather than measuring it. Every organisation believes it is more ready than it is. Readiness is not a feeling; it is a set of specific, answerable questions across business, data, security, infrastructure, governance, licensing and adoption. The programmes that stall are the ones that never asked them - not because the answers were bad, but because the gaps went unseen until they became blockers. A “we’re not sure” surfaced early is a finding you can plan around; the same gap discovered late is a crisis.

Picking the wrong first project. The instinct is to aim the first project at the most visible, most painful, most political process - the one that will impress. It is usually the worst possible choice. The hardest, most contested process is where you have the least control over the variables and the most stakeholders able to derail you. The programmes that build momentum start with something winnable: valuable enough to matter, simple enough to deliver, and visible enough to earn the credibility that funds everything after it. Spend your first win carefully.

Mistaking a pilot for a programme. A successful pilot proves the technology works. It proves almost nothing about whether you can scale it. The leap from a working proof of concept to production-grade, governed, supportable delivery is where a great many programmes quietly die. Without an operating model, application lifecycle management and an environment strategy, the very things that made the pilot fast - informality, a single enthusiastic maker, no process - are what make it impossible to scale.

Why capable teams keep making the same mistake

None of this is a competence problem. Capable, experienced teams make these mistakes constantly, and they do so for a structural reason: Power Platform inverts the usual relationship between difficulty and risk. In traditional development, the sheer difficulty of building forces planning - you cannot get far without it. Low-code removes that difficulty, and with it the natural checkpoint that planning used to provide. The ease of building creates a false signal that the hard parts are behind you, when in fact the hard parts - cost control, governance, security, scale - have not yet begun. Add the organisational pressure to show fast momentum, and the temptation to skip the unglamorous upfront work becomes almost irresistible.

There is a second, quieter dynamic once a programme is moving. Early momentum creates its own gravity: having shipped a few quick wins, no one wants to be the person who pauses to ask the awkward readiness questions. Slowing down to plan can feel like a vote against the very success everyone is celebrating. So the questions go unasked, the assumptions harden into the architecture, and the programme accelerates confidently towards the wall it cannot yet see.

Success is decided before delivery begins

The remedy is not more caution or slower delivery. It is a short, deliberate discovery before the build - the discipline of converting assumptions into evidence while changing your mind is still cheap. That means defining what success looks like, mapping your data and integration reality, engaging security and infrastructure as partners from the outset, choosing governance and licensing models against real usage, and honestly assessing where you stand before committing budget.

This is not a heavyweight exercise. It is a matter of weeks, and it pays for itself many times over by surfacing the expensive surprises while they are still cheap to address. The questions are not difficult. They are simply rarely asked at the point where the answers still change the outcome. And as Copilot and agentic AI add new layers of capability - and new, consumption-based ways for cost and risk to escape control - the gap between the programmes that planned and the ones that assumed is only going to widen.

The best programmes are a little boring at the start

The strongest Power Platform programmes are, frankly, a little boring at the beginning. They spend time on definition, evidence and design before anyone gets the satisfaction of building. That patience is exactly why they scale - and exactly why, months later, they are not the ones explaining to a steering committee why the costs ran over, the security review failed, or the pilot never reached production.

Power Platform will not fail you. But what you assume before you begin very well might. Get the start right, and the rest is delivery.

VE3 helps organisations get the start right - translating ambition into an evidenced, costed, risk-assessed plan before budget is committed. Our free Power Platform Readiness Framework assesses where you stand across eleven domains, turning the assumptions that sink programmes into findings you can act on. Get in touch with us to know more.