Updated: Jul 14
The Microsoft Power Platform is a great tool for tackling business challenges that cannot be solved using standard out-of-the-box apps. These challenges have bespoke processes that are specific to the your organisation and no-one else. When it comes to designing a bespoke solution, eliciting requirements can be complex which makes defining the problems and solutions difficult.
Compare to the Dynamics 365 applications, Customer Service for example, where generic case management processes can be applied and are usually very similar from organisation to organisation. It's easy to anticipate and understand what the requirements will be and what the solution will ultimately look like.
Throughout my consulting career I have noticed that people (myself included) often find eliciting requirements for a bespoke solution difficult. We struggle to align with the client, and also the developers, on what the requirements are and what the resulting solution will look like. It is difficult to know where, or how to start, the level of detail required, if everything has been captured, and how to write and communicate the requirements so that all project team members can understand etc. We can spend a lot of time on requirements gathering only to find out later in the project that they are not correct. We then proceed with change requests... it's horrible! Sound familiar?
To overcome this challenge I have developed a framework for gathering requirements for bespoke Power Platform solutions, called the Power Definition Framework. It breaks down the requirements definition process into manageable steps. Starting with a high-level overview and the progressively moving through the steps, each one building on the first with more detail. The aim of the framework is to quickly define requirements and get all project members aligned in order to get onto prototyping solutions as soon as possible. When it comes to bespoke solution, it doesn't matter how many questions we ask or how much analysis we do, people are normally not very good at telling us what they need. Its not until tangible prototypes are put into the hands of the end user that the real requirements and the intricacies come out. Be prepared to be flexible and iterate.
The Power Definition Framework has the following steps which we will walk through in this article:
Interviews and Observations
Swimlane Process Diagrams
Example Power Platform Scenario
To help explain this process I am going to use an example client in the construction industry who installs piles as part of the foundation for buildings and structures. On a building site they may have 100s of piles they need to install and as part of the installation work they need to record what they have done and document it to meet compliance requirements. This is a paper based process, very manual, time consuming, involving duplication of work and has a high risk of human error resulting in non-compliance.
Our client knew they had to do something and digitise the process but they just did not know what was technically possible or where to start... and this is where the Power Definition Framework starts.
Interviews and Observations
Before diving into any of the details around requirements or solution design it is important to understand the people you are designing for - the jobs they need to do, the challenges they have and the goals they are trying to achieve. This is most commonly done through interviews but it is also equally important to observe people in real world scenarios of the problem you are trying to solve. In the example of the construction client, we went on site with the site workers and observed them installing the piles and filling in a paper checklist as their record for compliance.
Interviews and observations are best done at two levels:
Business stakeholders / managers - the people who are responsible for the outcomes of a digital solution. They help frame the problem and will be able to set the objectives and success criteria.
Employees / customers - the people who are on the front line and will be the users of the solutions. They understand the details, the intricate challenges and will ultimately determine if the solution will succeed and achieve its objectives.
Once you have a better understanding of the people you are designing for you it is time to start documenting the processes you want to digitise. A journey map is a great way to visualise that you have a complete understanding of the situation.
Journey Map Template
I use the journey template below which triggers us to think about different aspect in order to understand the problems and design a complete solution from start to finish of a process.
This is how it works...
Start with defining the persona who is going to be the subject of the journey map. This could be an employee or customer. It is their journey that you are mapping out.
Define four high-level phases that capture the process (journey) from start to finish. Now you are ready to start filling in the map with sticky notes.
Actions - add all of the tasks or activities that the persona performs in each stage of the process
Interacting with - add the systems, tools or other people that that persona interacts with in each stage
Pain Points - add the problems that the persona encounters
Complete this exercise yourself and then present it back to the rest of the project team, stakeholders and users to get feedback, fill in any gaps and confirm that everyone is aligned on the process to be digitised and the high-level opportunities identified. The high-level opportunities usually go on to become the Features of the Product Backlog.
Journey Map Example
Using the construction client scenario, an example completed journey map is shown below for the pile installation checklist process from the point of view of the Site Engineer.
Journey Map Tips
Map out the current state process as it currently exists, you will work on future state in the next step.
Use one journey per process.
You can also have multiple journeys per process for different personas e.g. employee vs customer.
Or I sometimes will add in an extra Actions row to a journey to capture both employee and customer actions on the same journey, depending on the complexity of the process.
There are no hard rules around this, it's a high level visualisation that helps you make sure that you have a wholistic understanding and have considered everything you need to go to the next level of detail.
Swimlane Process Diagrams
The next step in the framework is to get further into the detail and start mapping out the technical requirements and solution components using swimlane process diagrams. While the journey map focuses on current state, the swimlane diagram should focus on defining the future state process.
Using the journey maps as input, start by defining the swimlanes. These often align to the Interacting with row from the journey map and should consist of both people and systems. Keep in mind that the swimlane diagram is focusing on future state so the systems that the user will be interacting with in the future will most likely be different to the systems they interact with now i.e. they will most likely be Power Platform components! For example, the construction scenario swimlanes look like the following...
Once the swimlanes are defined start adding the process steps. These often align to a combination of the Actions and the Opportunities from the journey map. For example, the beginning of the construction scenario looks like the following...
Swimlane Process Diagram Tips
Always include people, personas or roles as swimlanes and not just systems. I've seen swimlane diagrams that only include systems which takes the focus away from the people you are designing for. This often results in solutions that don't hit the mark with the users.
Don't be concerned if you are unsure of the details in the system swimlanes. You will likely come back and update these as you get into User Stories and the design of the solution starts to take shape.
If your diagrams are getting too large, consider breaking the process down into sub-processes.
Forming the Product Backlog
Before jumping into writing user stories it is a good idea to set your product backlog structure. Dani Kahil's recent article Azure DevOps Boards for Dynamics 365 or the Power Platform – Part 1 – STRUCTURING REQUIREMENTS gives a great overview of how to structure a product backlog in Azure DevOps. I structure my projects in the same way and usually map Epics, Features and User Stories to the framework using the following guidelines...
Epic = a business process / journey
Feature = an opportunity from the journey map
User Stories = a single step from the business process
The final step of the Power Definition Framework is to write User Stories which give the right level of detail to start detailed design or prototyping (build). The are also useful for communicating the requirements gathered back to the stakeholders and users in a way that they can understand and also act as the test scripts for testing the solution.
Using the people swimlanes as a starting point, writing a User Story for each step in the process is about the right level of detail. Start from the first step and work your way through the process until the end. This ensures that you have user stories that cover the entire process from start to finish, and that you aren't missing anything.
For example, take the Trigger checklist creation step from the Site Engineer swimlane.
As a Site Engineer, I want the pile installation checklist to automatically generate so that I save time not having to manually create checklists for each project.
The system swimlanes usually become the tasks or the things you need to build to implement the solution.
User Story Tips
If you are unfamiliar with User Stories, please, please read up on them as getting them right is incredibly useful. Getting them wrong is just a waste of time. I often refer people to this article from Mountain Goat Software as a great place to start.
Make sure your user stories contain acceptance criteria / conditions of satisfaction.
Include sketches and prototypes with your user stories to better communicate with the project team.
Update the swimlane diagram and tag the steps with the User Story number and a link to where your User Stories are written e.g. Azure DevOps. This helps stakeholders visualise where a User Story will happen in the process.
The Power Definition Framework is something that is extremely useful when aligning a project team on the requirements for a bespoke Power Platform solution. I am going to finish this article by re-iterating the key principles of the Power Definition Framework:
Start with a high-level understanding and progressively get into more detail. This ensures that you can see the full picture and know that you will have a good coverage of requirements across the solution, not missing anything out.
It is intended to be run very quickly, over a matter of days rather than months, with the aim to get prototypes into the hands of users as soon as possible - this is where the real requirements start to emerge.
It is intended to be flexible, change up the exercises, do what works for you and your team, use it for non-Power Platform solutions.
Work as a team. While you may complete some exercises on your own, make sure that you get feedback and input from the rest of the project team and end users at each stage of the framework.
Iterate through the framework exercises. For example when you start writing the User Stories they may highlight detail that changes the swimlane diagrams. Go back to previous stages and update them based on what you learn as you move through the framework.
If you have any feedback or comments I would love to hear from you.