Solve Problems
A little recap from the previous posts - We’ve inspired some people to start their journey to transform their processes, themselves, and their organisation…. We’ve worked out how we’re going to support their education through formal learning, connecting them with others, and teaching them to learn whilst they’re solving problems….. But how do they solve those problems? Can we give them some help with a way to approach this and some of the things they might think about. YES!!! Of course we can! And coincidentally that’s exactly what today’s blog post is about! 😁
This is another big topic so I’ve had a good think about how I structure this and start bringing it to life. It may look like it’s complicated but let me explain and give examples to show how it’s scalable and some of these things can be REALLY light touch. Then in later posts I’ll start building out a bit more of the detail.
Are you sitting comfortably? Then I’ll begin 😊
If it’s something very simple it might be as easy as a use case idea popping into your head and you start clicking and typing. But what if you don’t have a use case idea? Or your use cases are getting a bit more complicated and you need to start to think how you make it efficient and effective, scalable and supportable, or how you’ll work to improve and evolve it.
I’ve drawn how I see this puzzle fitting together:
The core of it all is ideation - How could we look at what we do and come up with some ideas for the type of opportunities we can solve using Power Platform or Copilot?
Then how do we break that idea down and design how we’ll tackle it? What components are involved? What does the data look like? What do any screens look like? Once we’ve worked it out how do we built it in the best way we can, and build it fast and well.
We’re ready to release it to our users - how do we best do that? Is there any formality? Do we have to tell anyone?
And now that people are using it, or the latest version of our ‘thing’, how do we have to support our users when things don’t go as planned,
and work with them to improve our solution, what we’re doing, and how we’re doing it.
(Those eagle-eyed of you, or those who might have been in IT Service Management) might recognise the style of diagram as being the same as how the ITIL framework is often displayed. The principles are similar in places but have some different areas of focus and different levels of detail.)
Let’s bring our model to life a bit better by fleshing it out!
Firstly, like The Hitch Hikers Guide to the Galaxy says - DON’T PANIC! 😁
Against each section I’ve put some examples of things we can consider but remember that these are just examples and not every use case is going to need everything, and there are different levels of detail we can go to depending on the size / complexity / risk of the solution we’re looking to build.
Let me explain what this might look like in it’s simplest form…
1) Ideation - My first use case might be the one that inspired me to start exploring the platform. I might have seen a story about how someone automated one of their daily activities and I might do something very similar.
2) Design - If I’m automating my own simple activity I probably don’t have to map the process but I might have to think about what is going to trigger my activity, and what I want to do.
3) Build - Once I understand enough to put hands on keyboard / mouse - I can try to make life as easy as possible - Does Power Automate have a template that does what I need, or something similar? Could I get a copy of the solution that inspired me? Could I ask Copilot functionality to create it for me?
4) Deploy - Before I put it live can I test it to make sure it does what I intend? (Especially if my solution is to be used by multiple people) . If it’s a bit bigger do I need to document what I’ve done so others can understand it, or could take it over if needed?
5) Support - If it’s just for me… I don’t need to consider support model. If it’s used by others how will they know to report issues to me? How will I manage access to my solution if people request access?
6) Improve - How am I going to work with my users to get their feedback and take on board their ideas and suggestions?
At this simple level there’s not a great deal to do… It’s more of a thought exercise to evaluate different considerations. As the size / complexity / risk increases in line with our T-Shirt model the level of detail or formality will increase.
In future posts I’ll dig into each of these areas deeper and share some ideas on how you can approach these! Stay tuned!
