How are you solving business challenges with low-code/no-code tools?

Very cool Alan. The replacing and/or integrating with legacy systems cost-effectively is a huge win for companies who are willing to embrace the low code/no code tools.

Totally agree Ryan. Thanks for sharing and laying it out so nicely. What kinds of solutions are you creating these days and what are your favorite go-to tools?

In my previous organisation we adopted SharePoint and Nintex to encourage unit/department level automation and productivity through end-user applications. Out of the initiative we also ended up building some enterprise wide apps using the same tools; such as one for managing continuous improvement ideas, where staff could put forward ideas and have their peers, comment, like, and volunteer to assist with implementation. Last one I worked on was a project resource onboarding tool. The business challenge was that staff seconded to projects sometimes fell off the usual performance management and HR cycles. The onboarding app ensured that PM's continued to provide performance feedback to Line Managers and that HR adjusted their payroll to the project etc. Many business units started to use the tools to create their own process automations and to assist them, we created a small COE to provide support if they experienced technical difficulties in development or deployment of their apps.

What great examples of how you brought it into the whole organization. Thanks for sharing. For creating your CoE, what insights or tips can you share on that topic?

Thanks Jaime. Impressive stat by Forrester "75% of software houses will adopt low-code." What has your experience been creating or using either low-code or no-code tools?

YES

Great question Jody. Here are my top 3 insights/reflections, from implementing the CoE:

1) Start small and build on successes. Executive buy-in and access to funding was a huge challenge at first. To get over this we had to get some small wins and 'sell' the heck out of the returns to engage interest and eventually get funding for the CoE. (Find the most interested Exec, deliver benefits for them and use that support and success to grow)
2) Choose the right people for the CoE. You need folk that are entrepreneurial and that can manage in chaos. No matter how much you train business-users to build their own tools, or how simple the tech seems, remember that there are folk that struggle with formatting an email. Your CoE team has to be able to effectively manage and guide these types of users without them getting frustrated and scuttling the initiative (which can cost credibility, support and funding)
3) Have some rules in place. At the end of the day, the tools that are built have to be auditable and risk managed. It pays dividends in the long run to have some rules, guidelines and standards in place to help manage this. For example, in addition to user support guides, my team created a document that outlined some basic rules around SharePoint/Nintex usage such as department administrator roles, data governance and access control for applications built using the tools etc. (always be prepared for the 'what if' questions from Internal Audit and others)

One of my other early lessons, was to be agile, use agile techniques, but not to call it agile. There was still so much misunderstanding around what agile actually is, that it often detracted from what we were actually trying to accomplish.

Hope this helps.

Great tips and insight. Thanks so much for sharing!