How to modernize internal processes with Power Platform

What if I told you that you don’t need a team of developers and designers to modernize your internal processes. Sure, they don’t hurt. But what you really need is people who understand your business and the process you want to modernize. Or sometimes just one person, inside your own company.

I know what I am talking about because I was that one person. I started my Power Platform journey as a citizen developer, starting from scratch and building one app at a time and learning on the go.

My first ever app was a simple application form, a relatively easy project to start with. I watched some YouTube tutorials and dived in. I was surprised how easy it was.

After my first app I was ready start Power Platform revolution within the company since I was able to see the benefits instantly. The development was fast and agile, we were owning the data as well as the product, it was secure and the best part; the apps worked on every device ❤

I’m still on that journey, making the Power Platform revolution to happen. I want to empower people to build apps and to modernize their own internal processes the same way I did.

The process of modernizing processes?

Modernizing internal processes is a process on its own, and it follows the same steps as a traditional software development. Good news if you’re a developer as there is nothing new for you.

But if you’re just entering the world of citizen developership, you might want to get familiar with this process before jumping in. I learned this the hard way, and that is why I wanted to write this blog post. I want to help others succeed where I failed.

So without further ado, here’s a kick-start guide of software development for all the future citizen developers out there. You got this ?

The 7 steps of software development

Building an app is much more than just writing code. Software development is a process and its goal is to produce quality apps fast with the lowest possible cost.

There are several different methods of software development. You’ve probably heard about waterfall method or agile. However, usually all the methods still contain the same seven key steps: ideation, analyzing, planning, development, testing, publishing and maintenance.

It’s up to you how you want to approach these steps as there are no fixed rules. The steps can even occur in parallel.

1.      Ideation

Sometimes it is blatantly obvious what you need to modernize. Sometimes you need to sit down and prioritize a bit. What I suggest is to start with the simplest process first, for example forms are very easy targets for modernization. Here are some prompts to get your ideation going.

What process…

• annoys the end users the most
• is unreasonably complicated
• takes considerable amount of time to complete
• still relies on Excel (or even paper!)

If you are new to Power Platform and you have never build an app from scratch before, don’t get too ambitious. Usually you can divide a larger process into smaller sub-processes and and build them one by one, combining them all in the end.

During this ideation phase you may need to dive into developing as well. Just a teeny tiny bit though, in a form of a POC. Let’s say you have an awesome idea for what to modernize, buy you’re not entirely sure if you can make it happen with Power Platform. POC stands for a proof of concept; you implement a small part of the process to verify that it can be done. You certainly don’t want to learn this later, so if there is anything that sounds risky, create a POC first.

2.      Analyzing

Once you have chosen the process, it’s a very good idea to thoroughly analyze it. It’s not exciting nor very hands on, but I promise you that you get better results if you take the time for it.

Start by mapping the process, from start to finish, as it is. Make sure to include every step, every piece of information required and every person needed. If you are not an expert on the process yourself, make sure that the stakeholders are ready to invest their time on this.

If the process is simple, a short numbered list can easily get the job done. If the process has different branches or conditions to consider, it’s better to use tools to visualize it. Whether it’s a pen and paper, physical whiteboard on the wall or a fancy digital tool, it’s totally up to you. As long as you can come up with a clear flowchart of the process.

When you understand the whole process as it is, it’s time to take a critical look:

• Are there steps that are not needed but are there for silly legacy reasons?
• Is the process involving more people than it should?
• Are you collecting information that is not needed anywhere?
• Is the process still relying on paper forms or Excel?

This is the time to not only to modernize but also to optimize and simplify, in other words, to design a better process for everyone. Open a discussion with the stakeholders, remind them that you can do more than just recreate the old process using new tools. Discuss with the end users as well, try to figure out what parts of the process are most complicated or time-consuming for them. And don’t forget that there may be parts of the process that already work well, so make sure you don’t accidentally make those worse!

3.      Planning

By this step you should have a pretty solid idea of the new, modernized process. Usually the process can be divided into tasks (and sometimes also sub-tasks) and this is the point where we need to decide how and where we manage these tasks.

Microsoft Planner is a simple solution for task management, but basically any task manager works for the purpose. You might think that you don’t need a task manager if you are working alone, but trust me. It makes your job easier when you have a clear view of what tasks you’ve finished and what you still have waiting in the backlog. Sharing the plan with stakeholders is also a good way to increase transparency, as they don’t have to pester you when they want to know how far the app is and you can work without disruptions.

I always prefer to setup my Planner buckets using the popular Kanban board style. It’s very straight-forward and visual. There are many ways to name the buckets, but usually the logic is the same.

Here are the bucket names I like to use:

1. Backlog: Untouched tasks.
2. Next in queue: Tasks I have prioritized to tackle next.
3. Work-in-Progress: Tasks I am currently working on.
4. Testing/Feedback: Tasks that require testing and/or are waiting for feedback.
5. Done: Tasks that are finished!

First make a task list of all the required features. This will be your backlog. Prioritize up to three tasks and move them to the “Next in queue” bucket. These are the tasks you want to tackle first.

When you start a task, move it to the Work-in-progress bucket to indicate others (or yourself) that you are currently working on it. And so on and so forth (or back, don’t forget that tasks can move backwards as well…).

4.      Designing & developing

The database is the backbone of the app. It should be implemented first since the rest is build on top of it. This is an important decision, so don’t rush it. What is a sufficient database now might not be scalable enough for the future.

Here are some common database options:

• Excel files stored in OneDrive or in SharePoint (10/10 do not recommend)
• SharePoint lists and libraries (easy to get started with but comes with some limitations)
• Common Data Service (CDS)
• Azure SQL Database

After you’ve decided what you want to use as a database, you naturally need to create it. Hopefully during the analyzing phase you did a a good job mapping out the required information and can create all the tables and columns in a whim. If not, go back to the drawing board to design your database. It’s usually either really difficult or really annoying to change anything afterwards, so try to make it right on the first try.

When your database is up and running, and preferably has some sample data, it’s time to build your MVP.

MVP

MVP, in this context, stands for minimum viable product. It has many different definitions but to simplify: it’s the first draft of your app that contains only the core features and not much else. And by “much else” I mean that it’s not necessary pretty nor user friendly. It just contains the critical features that carry the process from start to finish.

I made it sound simple, just throw the features in there! But usually this is the phase where you meet your first obstacles and have to figure out your way around them. Sometimes Power Platform is not yet where you would like it to be and you have to get a bit creative with your solutions. I’ve never met a real showstopper myself though, I’ve always been able to find a perfect solution in the end, either by doing vigorous google searching or asking around.

When you have your MVP ready, you can go ahead and introduce it to your stakeholders. A fully functioning app (albeit not pretty) helps them to envision the finished product and confirm that you are going to the right direction.

MLP

I have to confess that I learned the term MLP while writing this blog post. But it’s the perfect term to describe what comes after MVP.

MLP stands for “minimum lovable product”.

You have your MVP and it works. But it’s not pretty and it’s probably not very user friendly either. It’s more like a sad frame of an app, waiting for more meat. It’s time to make it lovable.

But what makes an app lovable?

When it comes to internal processes, you don’t really have to win over customers. You already have them, whether they like the app or not. So you can focus on making your app at least somehow pleasing to look at (we are not all designers here, understandably) and easy to and effortless to use.

It’s up to you how you want to start approaching the lovable state of your app. I usually like to finish one feature (or a screen if one screen contains multiple features) at a time, in the priority order, polishing the user interface and paying much, much more attention to the user experience.

Theme

If you are building an app for a wider audience, you should follow the brand guidelines of your company. This also ensures that the organization-wide apps have unified look and feel.

Timo Pertilä has written good blog posts about the things to consider when outsourcing the app design (also a good read if you are designing the theme yourself) and how to create your own custom themes. I highly recommend reading them both.

Giving Power Apps a face lift

Power Apps and custom themes

Interface

When it comes to designing the user interface, remember that you don’t have to start from scratch. Actually, you shouldn’t. Don’t try to do something crazy and unique as that is rarely user-friendly. Try to stick with what has been proven to work or what people are used to. You don’t want your app users to get frustrated, they need to be able to easily figure out how the app works.

If you prefer prototyping before getting your hands dirty, there are plenty of free tools to try out. Check out Fluid UI for example, it has wireframes for iOS and Android so making a a pretty mockup app is fast and simple.

You can also spend a moment to study the guidelines for iOS and Android mobile user interface guidelines:

iOS Human Interface Guidelines
Android Material Design

5.      Testing

Remember to do testing during developing as well. I’ve added testing here as a “next step” after developing, but most often they overlap. You can start testing performance when you have built features, and you can do usability testing when you have an user interface. The sooner you find out the possible problems, the easier and faster they are to fix!

Performance testing

Canvas app Monitor helps you to find and diagnose performance problems by logging all activities in your app as the app runs. I periodically click-through basic tasks in the app I’m building to make sure that there is nothing funny going on under the hood. The Monitor gives me just the right amount of data in a simple format so I can catch bugs and performance issues early.

But testing should not be all about technical performance. Sure, it’s good that your app is fast and reliable, but it’s not much use if your users don’t understand how to use it. And that’s when usability testing enters the picture.

Usability testing

Usability testing is a quick way to see how easy your app is to use. In usability testing you give realistic tasks to real end-users (for example to make a new expense claim) and see how they perform the task.

If you are completely new to the topic of usability and usability testing, here are two quick reads I recommend:

10 Usability Heuristics for User Interface Design
Usability 101: Introduction to Usability
Usability Testing 101

I like to do usability testing in quick, iterative rounds:

I invite 2-3 end-users and ask them to perform the same task in the app. I observe how they perform and collect feedback.

After a completed round I go through my notes and make adjustments to the user interface if needed.

If adjustments were needed, I invite new participants with fresh eyes to perform the same task again. Usually three rounds per task is enough to detect and fix the possible usability problems.

Now you might think that why does the usability even matter because the users most likely don’t have an alternative for the app. Building app for an internal process is indeed less brutal than building a global ecommerce site… But the time your users spend figuring out how your app works is time away from the work they should be doing. Never underestimate the importance of usability!

6.      Publishing

Publishing apps is super easy, barely an inconvenience. It’s as simple as clicking a button, literally. However, before you hit that publish button, you should make sure that the end-users have access to all the databases used. If your database is a list in SharePoint, the end-users need suitable permissions to it. The app itself grants no rights.

If this is the first Power Apps app in your company, the end-users probably need some educating as well. Using apps embedded in SharePoint or Teams is usually relatively easy and intuitive from the end-user point of view but for mobile use you probably need to craft a short how-to guide and figure out how to distribute it.

Now, I hope your app is easy to use and doesn’t require a manual. But the users should still know who to contact in case there are problems with the app, questions about the process or maybe even feedback to share. You can add this information inside the app as well (and maybe even a contact form).

When a new app is launched, it’s normal that new bugs come to light or to realize that something needs a bit of fine-tuning. Publishing is rarely the end of the project, sometimes if feels like a fresh start.

End-users can sometimes be very active reporting problems or giving feedback. Bugs should obviously be fixed as fast as possible, but everything else should be added to the backlog to validate later. Never make big changes to the app while end-users are still new to it. People are always resistance to change and obviously the old way of doing things is suddenly better if the other option is being forced to learn something new. Give them time.

7.      Maintenance

Documentation is not sexy but it’s important.

Here is a very minimum list of things you should write down:

• Process owner and his/her responsibilities
• Technical owner and his/her responsibilities
• How to get support (technical and non-technical)
• List of user rights, workflows and databases
• Flowcharts of the parts of the process that might be hard to understand
• Future plans for the app, such as new features or integrations

Whenever I write documentations, I keep in mind that they are not only for me. I imagine that the documentation is for someone who someday might have to pick up the project and add new features or fix something. What would be helpful information in that case? And obviously, that someone can one day be me as well. The more you build, the more you start to forget, and it’s good to have something to backup your own memory!

One part of the maintenance is also to go through the backlog tasks periodically. For example after publishing you probably received at least some ideas of how to make the app better and put them to the backlog. Find time to validate these tasks and to implement the ones that are worth it.

Ready to get started with Power Platform?

I assume not, but let me explain.

In the beginning I told you that you don’t need a team of developers and designers to modernize internal processes. That only one person, you, can be enough.

But after reading through all the seven steps of software development, you are probably now thinking “okay, I need to be an analyst, a project manager, a developer, a designer, a tester and who knows what else, is that even possible?”

It is possible.

But you don’t have to master everything from the day one. That is the beauty of Power Platform. You can start with what you have, no matter how little it is, and keep building on that. Because the more you do, the more you learn, and the more you learn the more you want to do.

You just need to get started and trust the process ?

And hey, if you need help, we’re here too.