Power Platform governance
Why Power Platform governance fails after the pilot
The pilot worked because a small group understood the problem. Production is different. Ownership, support and information controls now matter as much as the app itself.
Most Power Platform governance problems do not start with a bad app. They start when a useful prototype becomes important before the organisation has agreed who owns it, how it is supported or what risk it carries.
The pilot hides the hard questions
A pilot usually has a clear sponsor, a small user group and a developer who knows the solution in detail. That is enough to prove that an idea can work. It is not enough to run a service safely.
The questions change when more people depend on the solution. What happens when the flow fails? Who can change it? Which data does it use? What is the route for a user who has a problem? If those questions have not been answered, the pilot has not failed. The transition has not been designed.
Five controls that need to exist before scale
The controls do not need to be complicated. They do need to be visible and consistently applied.
- Named ownership: a business owner and a technical owner for each important solution.
- Environment discipline: a clear distinction between development, test and production.
- Information and permissions: an understanding of what data is used and who can access it.
- Support and change: a route for incidents, changes and decisions when the original developer is unavailable.
- Lifecycle decisions: a way to retire, replace or improve solutions that are no longer needed.
Governance is a delivery system, not a document
A governance manual will not fix an estate if delivery teams cannot use it. The useful question is whether a team can make a better decision because the control exists.
That usually means a small number of patterns, clear approval points and a risk-based approach. A business-critical case management app needs more control than a personal productivity flow. Treating them as identical creates either unnecessary friction or inadequate assurance.
What leaders should ask next
Start with the solutions people rely on. Ask which ones would create operational disruption if they stopped tomorrow. Then ask whether the owner, permissions, support route and recovery position are clear.
This produces a more useful starting point than counting apps or publishing another set of principles. The aim is to identify the material gaps and agree what should happen first.