Power Platform Enablement Strategy and Vision

This is a big topic… A huge one… So I’m going to have to split this up. I’m going to start with an over arching post and will then circle back round at a later date and do some follow up activities - If there are questions / comments / ideas I’ll do my best to factor those in :)

So… Where to start… The approach I’m going to use to break this down is to talk about Vision, Strategy, Roadmap, and OKRs and we’re going to think about Power Platform in our organisation as a ‘Product’ rather than a ‘Project’.

What’s the difference? If we initially think of a project to implement Power Platform it will generally follow the Iron Triangle of Project Management and have fixed scope, cost / resources, and time - It’s goal is to define these up front and not to deviate from them without a formal change control. Once we reach the end of the time, or the budget…. It stops, as may the momentum of the change and our adoption and enablement of the organisation if we’ve not been able to do enough..

Whereas when starting our Power Platform journey we don’t necessarily know the size of our scope, or all the activities that we need to do, or how long it will take - We’re ultimately changing culture and behaviours… So we likely have a fixed set of resources / budget but we need to be able to flex the scope and have an ever evolving backlog of items we want to do, This backlog will be prioritised depending on pull from the organisation, and this will alter the time. Or if we want to accelerate we need to increase the resourcing / budget.

So this is how we’ll look at it - a living, breathing, Product that we need to nurture and grow and monitor, act and adapt to! I’m going to structure this around this model - Vision, Strategy, Roadmap

Vision, Strategy, Roadmap, OKRs

Vision

This is the long term mission of our Power Platform - Inspiring, Achievable, Documented, Communicated, and Emotional - We want people to not only understand it and be motivated by it, but also to be able to imagine how it will feel when achieving it.

When I think of a vision I think of JFK’s speech on 25th May 1961 - “I believe this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to Earth.”

‘This nation’ - The group engaged

‘Commit itself’ - Focused intent!

‘Before this decade is out’ - Time bound

‘Landing a man on the moon’ - Goal

‘And returning him safely to Earth’ - Success Criteria

What could that look like in the context of Power Platform for an organisation? It depends!

Perhaps something like “To empower and support every member of our organisation to have the option to transform themselves, and their careers, whilst improving processes through new digital skills”? Perhaps something else? You need to shape this for your organisation and what’s important and meaningful to them.

However we might need to break down that vision statement into some key messages that speak to our target groups and tell them what it means to them

How is it going to change how they work? How does it help them? Why is it important to them?

OK, so we have a vision which may evolve as we see more, reach further, our ambition grows. Now on to our Strategy!

Strategy

Rather than the plan that many people call a strategy this is a definition of where we’re going to target use of the platform to achieve value, and how we’re going to implement it. What are the choices we’re going to make that we believe will achieve our Vision?

  1. Where are we going to target the platform? Certain business units? Certain Geographies? Certain roles? Everywhere?

  2. How do we define, deliver, maximise value? (See my previous post on Value to get some thoughts on this one!)

  3. What are the costs we need to factor in? Licensing? Capacity? Resourcing? System connectivity costs?

  4. What is our plan for growing Power Platform adoption in the organisation?

Essentially - Where are we going to position Power Platform? How do we ‘win’? Is it better than another option? Is it cheaper? Is it faster? Etc.

We’re going to come back to some of these in a follow up post, I promise!!

Roadmap

This is a tool to align the organisation - We can describe a phase of this journey as going from X to Y by Z - From our start point, to our next target point, in a specific timeframe.

To show our direction and our priority activities and where they fit in the bigger picture. Let’s use a picture to bring this idea, and what X and Y might be, to life.

This diagram shows how I view the maturity journey of a Power Platform implementation.

Along the bottom axis we have that maturity score based on the Microsoft Power Platform Maturity Model. You may notice that although it’s numerical, I’ve shown it as not being linear. 100 to 200 is a small fairly simple jump, 200 to 300 is double that jump and a bit more effort, 300 to 400 double the gap from 200 to 300, and so on…

The vertical axis is adoption by the organisation - We can look at this through adoption of solutions by users across our organisation rather than adoption by makers as we’re using this as a gauge of impact.

We can then look at the blue line - these are simple every day use cases - Small or medium sized use cases - relatively simple, non-business critical, low risk - the type of solutions that may be made using standard connectors to M365 connectors like SharePoint using seeded Power Platform licensing through their Office license. The line shows that our Citizen Developers likely start with these types of use cases and adoption grows over time but will bottom out - Not everyone will be a maker, people, and their ambitions, will outgrow simple data sources like SharePoint. There’s limit to the impact that can be delivered.

The purple line shows the higher value, more complex, more sensitive, more critical processes - The type of use cases that are likely to be built on Dataverse, SQL, Core Business Systems, Custom Connectors etc and therefore built by data schema designers, security modellers, IT developers, etc. and also need Premium licenses for makers and users. Many organisations go through common phases:

  • A small number of premium licenses available to run CoE or have limited experimentation.

  • Then a blip of ‘activation energy’ where the outcome is a decision to invest in some more licenses to experiment with targeted, high value, use cases to prove value

  • Once value of premium licensing is proven there is some activation energy needed to build a backlog and create a business case that drives the decision making to invest in Premium licensing for their org.

  • Then solution adoption, and use case value, can spike as high value use cases for the whole organisation can be delivered. More advanced Citizen Developers can start to use premium data sources like Dataverse to extend their solutions.

By describing this maturity journey we’re able to build our roadmap around goals and outcomes, what we want to achieve, the capabilities we want to develop, how we want to work, rather than features and functionality, solutions and technology.

If we think about how we started this section and managing Power Platform as a product we should think about our roadmap as being an agile series of short timeframe (and so lower risk, higher achievability) steps towards our vision, focusing on enabling value at every step of the way!

OKRs - Objectives and Key Results

The last topic I’m going to give an overview in this post is how we structure delivering our Power Platform implementation to ensure we’re clear on what we’re doing, why, and how our actions are moving us towards our vision.

This picture shows how we can break things down to align them. We start with our vision which is likely to be a multi-year journey. As we said earlier the strategies are defined to achieve that vision. We then need to plan our roadmap around those shorter time frame, lower risk, higher achievability, objectives. Shorter time frame could be a year, but we might break them down further.

An Objective is what you want to accomplish. A good Objective is significant, concrete, action-oriented and inspirational.

Key Results are how you will accomplish that Objective. Good Key Results are specific, timebound, aggressive yet realistic measurable and verifiable. Can be set quarterly and evolve as work progresses.

An example could be an objective like - Finance function to build a citizen developer capability to transform local business processes

Key Results might be

  • Build Power Platform capability in 25% of the Finance function by end of Q2

  • Generate backlog of 20 use cases each with a time saving of 1 FTE of resource

  • Gain approval for team of 5 dedicated Power Platform resources whose cost is self funded through business savings.

Each of these would have an owner who is responsible for achieving those results. The Key Results would be broken down into specific activities needed by whoever is part of the team delivering it and should own that individual activity

For example - if the Key Result was the first one about building Power Platform capability we might define activities including things like:

  • Define training path

  • Produce Training materials or source training provider

  • Promote Power Platform

  • Promote sign up for training courses

  • Etc.

As with the overall agile product approach - Focus on the right priorities is the key to success and moving forwards at pace and delivering incremental value! It will likely be difficult as “everything is a priority” but aim to limit the number of goals you choose to focus on to 3 -5. Microsoft provide a nice summary and guidance on ‘OKR Super Powers’ to find out more

Hopefully this brings to life how you can use OKRs to structure breaking down your platform implementation down into individually owned activities and monitor them to achieve our objectives, strategy, and ultimately vision.

There’s a lot in this topic and more to unpack in a coming posts! I hope this has got your brain whizzing on how we might approach our Power Platform Vision, Strategy, and Roadmap. As always, please share it with friends or colleagues if you find it useful!

Previous
Previous

Top Down vs Bottom Up Enablement

Next
Next

PP Value Hypothesis