During the kick-off of any new software project, a senior stakeholder will often produce a slide that explains why a high percentage of software projects fail. The intention is often to explain how the soon to be kicked off project will not fail. If you search for “Why software projects fail?”, you will find a variety of failure reasons, such as general people issues, time, lack of testing, unclear requirements, scope creep, inadequate communication, staff retention, poor risk management and more.
Can the historical reasons that traditional software projects fail also apply to Power Apps projects? Absolutely. But there are also reasons that Power Apps projects are more likely to fail compared to traditional pro-code projects. Here are some pitfalls to watch out for, combined with some practical tips to maximise your potential for success.
1. Don’t use the wrong no-code tools
“One of the things that limits our learning is our belief that we already know something.”
L. David Marquet, Turn the Ship Around: A True Story of Turning Followers into Leaders
Sometimes when you are used to using a hammer to hit a nail and it works, there is a temptation to only use the hammer and treat everything like a nail. For people with a Dynamics 365 background, there is a temptation to think in a model driven app centric way. But Flow, AI Builder, Canvas apps and Power Virtual Agents could present a more linear view to your users or a killer use case that captures your user’s imaginations. Model Driven applications and the concept of views and records can be tedious for some use cases where data needs to be entered quickly in a streamlined manner.
To mitigate this, try something new on every project that you work on. Just because you created a similar application last month doesn’t mean you can’t try to take a different approach.
2. Don’t say ‘Never Pro-Code’
The world is full of different 80-20 rules. The rule, also known as the Pareto Principle, is an aphorism which asserts that 80% of outcomes result from 20% of all inputs for any given event. In business, and when developing Power Apps, your goal should be to identify inputs that are potentially the most productive and make them the priority. Taking the same approach to app development, if you are not a pro-coder, there is a temptation to get something “nearly there”.
Developing low-code applications may not always mean that you can deliver an application in a fraction of the time that you can using traditional development methods. Its primary benefit is that it opens up the world of building apps to a whole new audience.
If you find yourself building an application and saying to yourself, “I’m almost there” repeatedly, it might be time to take a step back and realise you are entering the final 20% that can sometimes take longer to complete than the initial 80%. Take a break and get some advice from someone with a pro-code skillset or a different viewpoint. They may be able to write a module you can reuse in future PowerApps or help you take a different approach which may save development time for future PowerApp projects.
3. Don’t forget to tell a story
If you’ve just been trained to use PowerApps and you know what you are doing, there’s a temptation to get stuck right in and start building and configuring immediately. Certainly, that’s one of the main benefits of Power Apps – it allows business users to build apps to solve their own problems. If you are responsible for an isolated process you understand and want to automate, it’s likely you will succeed because you already have the knowledge you need.
However, the poet John Donne once said “no man is an island”, and it’s likely for anything more than a simple Power Apps project you’ll have to consider more than a single application user.
A good approach if you don’t know where to start is to pick a story and stick to it. By this I don’t mean traditional user stories which can be hard to engage people in the format “As I user I want to…”. Try and think of a wider story, give your character a name, a backstory and get into your fictional characters head. Discussing and documenting things in a different way will help you keep focus and help you make the right app design decisions early in the process. You might end up creating multiple characters in a story which will help you drive out the number of apps, screens and data sources you need.
4. Beware accumulation of Technical Debt
Once trained, it’s relatively easy to get a Power App up and running in a day. When you do this, you might make a quick decision to store your data in a SharePoint list, Microsoft List or Excel. Alternatively, you might think about the number of fields you need to capture and add them all to a single Dataverse table. You might put the application live after some testing, people start using it and the enthusiasm in the organisation grows. Before you know it, people are asking for more enhancements or more similar apps.
At this point, you need to take a step back and try to avoid accumulating Power Apps technical debt. In traditional software development, technical debt is “the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer”. Some technical debt is ok, a lot is bad. Often Power users don’t come from a data modelling background so may struggle with defining the appropriate data structures. If this is the case, it’s time to get some help in defining the right tables to support future enhancement and features. It’s also a good time to see if you can reuse existing table structures in Dataverse or Dynamics 365. You might realise the problem you are trying to fix has already been solved by Microsoft! Don’t reinvent the wheel.
5. Measure and Track Success Factors
Take a scenario where a team of new Power Apps developers works closely with business users to design a new app. The business users are asked for their requirements and those requirements are managed in a backlog, documented and signed-off. A no-code app to manage and automate workflow is provided quickly in an agile way, completes testing and everything goes live.
One challenge for these types of Power Apps projects is that because the development cycle and path to production is often so rapid, it’s common to move on to the next new shiny project and assume everyone is using it. A critical part of every Power Apps project should be to measure success after go-live. One measurement of success is to ensure that telemetry data is available for reporting – with this you can check how many users are using it every day. For Dataverse and Power Apps, success can be measured in some of the following ways:
- In the PowerApps admin centre, become familiar with the Dataverse, Power Automate and Power Apps reports to get an indication of end user usage at a high level. It includes performance, usage and errors aggregated at the environment level.
- To check if the new app is being used at a more granular level, connect your PowerApp to Azure App Insights. Here, you can check to see how many launches your app has had in production and start to ask nicely why the app isn’t being used any more.
- You can also hook your model driven application entities up to Azure App insights in bulk using the XrmToolbox Application Insights manager.
- Don’t forget to check in personally with your end users too. Sometimes because they were involved in the build or sign-off process, they may not want to admit they are not using the new app because it reflects on their effort during design. They may also have other reasons for not using it (too busy, other conflicting priorities etc.).
Having accurate indications of monthly active users won’t tell you if your application is helping your business, but not having any users means it definitely isn’t!
Don’t let these pitfalls stop you moving fast!
Having an awareness of some of the reasons Power Apps project might fail is the most important thing – you don’t need to prevent all of these issues at once before you get started. It’s important to use the platform for rapid application development and not get hung up process and procedure.
But planning for regular checkpoints in an app development programme will ensure that you have rigour and governance and ultimately a long-term strategy for low-code, no-code development.
Images courtesy of Unsplash