There are many reasons why businesses large and small should be considering low code platforms for future app development; not only do low code tools increase agility and decrease costs, they shorten the development cycle and help manage change while mitigating risk. The end result is a faster, more productive business with a far more fulfilling and seamless customer experience – which can only be a good thing at a time when consumers are pickier than ever and one of the few differentiators between one company and another is reputation.
Low code isn’t no code, however. It still requires a good degree of foundational work before it can be a game changer in your organisation. You need to get all of your ducks in a row before you can leverage it to its highest potential.
Having worked with a lot of businesses across diverse industry verticals, there are three pieces of advice that I repeat to everybody – regardless of organisation size and complexity – that I’m certain will be helpful to anybody considering a low code platform in the near future. Even those who are already using low code may find future development projects are faster and easier when the three rules below are applied to each project in isolation.
1. Talk to people who are “at the coalface”
One common mistake I see businesses making when considering a process change is not interacting with employees on the frontline. Senior management will approve or even define the implementation without talking to the people “at the coalface”, which not only alienates the team but may actually prove harmful to the way work is performed. In order to understand a process – and to improve it – you need to ask and take advice from the people who actually do it day in and day out. This should be your first port of call when considering a low code platform, as well as any sort of process management.
2. Go back to basics and document your processes
Once you have buy-in from your project sponsors and intelligence from your workforce, it’s time to map out and document the processes that you wish to transform using low code. It’s important to document these processes in two ways: as they are and how you would like them to be. After all, you can’t change something if you don’t know where you are starting from. Get a clear perspective of the end-to-end process and document it, clearly and concisely, so that every member of your team – down to the most junior – can understand and accept the strategic goal of the implementation. Look for errors and areas that you can improve, places where you can be more efficient. This sort of fluid planning will pay dividends when you come to actually build your low code application. It’s a long process, for sure, and could well take longer than the implementation itself, but take your time to get it right first time; it will be worthwhile.
3. Educate managers on what the process actually was – and will now be
Now that you have your new processes mapped out, it’s time to present and educate your management team on how the new process actually looks; you’ll be surprised how often managers don’t understand the processes they oversee. When they aren’t deeply involved in the day to day work it can be easy to miss things. Go back to basics here – get a whiteboard and pen, draw out the new process and make sure people understand, and above all show them the tangible benefit of the new way of doing things. It’s crucial that you do this before you start implementing any new technology. Get the humans on board, and the machines will follow.
When (not if) things go wrong, MTTR is more important than MTBF. Mean Time Between Failures (MTBF) is an indicator that is often used to…Read More