I’ve been involved in the implementation of low code in a couple of councils, and in the right circumstances it’s a great fit. In the panel session, I’ll be exploring what those circumstances are, and what some of low code’s pitfalls are, as well as what it is brilliant at.
I’m going to be chatting with the following ‘legends of low code’:
Kev Rowe, Croydon Council
Craig Barker, Cumbria County Council
Clare Evans, Tewkesbury Borough Council
Ben Evans, Ashfield District Council
Lee Gallagher, Hertsmere Council
Big thanks to Nick Hill for organising the panel – as well as being informative, it should be good fun too.
Something that I have found helps an awful lot is having a simple way to match identified user needs with the technology capabilities needed to meet them.
It helps in two main ways:
by encouraging people to consider the user needs they are trying to meet before thinking about technology solutions (always tempting, but dangerous!)
by reinforcing the message about capability-based technology delivery, as opposed to always thinking in terms of single monolithic systems
By considering user needs first, then identifying individual capabilities to meet them, it’s possible to come up with solutions that are more likely to succeed and can often be cheaper and quicker to implement.
A good example of when I used this was when I was advising on a new intranet project. The initial requirements list had all sorts of stuff in it – HR policies, telephone directory, social networking, better collaboration (whatever that means!), and loads of others.
I was able to break it down into the needs we were trying to meet, and then come up with the technology capavilities to meet those needs. I found that adding an extra translation layer betwene the teo – tasks – helped with doing this. Here’s an example below:
User need: I need to know if my pay will increase this April
Task: quickly and easily access details of pay grades and scales, via search or navigation
Technology capability: publish pages of content
Pretty obvious perhaps. But let’s look at another need:
User need: I would like to understand the organisation’s policy on remote working
Task: find and read a policy document
Technology capability: share and manage versions of documents
Now, traditionally both of these things are requirements for an intranet. But broken down in this way, we can understand that we need an intranet to publish pages of content, but perhaps for the sharing of formal documents, a more specific capability is needed?
I then add a fourth column, which outlines the potential technology to deliver the capability. In the latter case, this could be a system such as Sharepoint or Google Drive, which may already exist in the organisation.
By following this process through with all the identified user needs, you’ll end up with a list of what technology you’ll need, along with a map of what you already have that can do those things, and where you have gaps.
To make it super easy, here’s a Google Doc template, with a worked example for the intranet, that you can copy and make use of.
A few months ago, I recorded this chat with Kit Collingwood, from the Royal Borough of Greenwich, about her work at the council, the new digital strategy she authored, and how she and her team are tackling the many challenges facing those working in digital in local government.
If you just want the audio, you can grab that on Soundcloud.
Stefan at Strategic Reading said about this interview:
This video conversation is modestly billed as a CDO chat, but is actually a master class in strategy development and application. The approach is deceptively simple. Two people who bring both depth of experience and thoughtful reflection range over everything from rapid mobilisation in the face of a pandemic, through the vital importance of using data effectively, the challenges of dealing with dominant vendors, creating a team with the right balance of expertise and humility, and giving that team the support to design and build services which meet the needs of people outside and inside the organisation.
The mechanics of making digital change happen in an organisation can be really complicated. What works in one place may well not stick in another. It all depends on strategy, structures, politics and personalities.
One common approach is to have a clearly defined digital programme. In many ways it makes perfect sense: you have a strategy in place, and a programme to implement that strategy. Having a programme helps you bid for some (most likely capital) money to help make it happen, you get a clear timescale to work to, and some benefits (savings!) to realise – not forgetting a programme board to report back to the big-wigs on how you’re progressing. What’s not to like?
Let’s look at the pros:
Unlocks money ✅
Allows you to recruit people ✅
Buys technology ✅
Clarity of purpose ✅
Clear governance ✅
Sounds pretty good! But wait, there’s cons too…
Capital money will disappear ❌
Those people you recruit are only there for the length of the programme ❌
Have you set aside time and money to ensure your new digital products are transitioned to BAU support? ❌
What are you going to do about continuous improvement? ❌
How are you going to keep those big-wigs excited about turning up to your board, two years in? ❌
The admin overhead can be significant if you aren’t careful – who is updating the programme plan, and generating the highlight reports? ❌
You’re on the hook for those savings – are they really in your power to deliver? ❌
The last point is crucial and getting consensus on this early is vital. Capital funds for programmes are usually given on the basis of a business case – in other words, for every £1 invested, £3 is expected to be saved. But, whilst the money is funding digital activity, the savings won’t be coming from the digital team – they will be created within the departments where services are being redesigned. As part of a programme, there must therefore be absolute clarity on what savings are coming from where – and a willingness to offer them up when the time comes.
A digital programme brings focus, and resources. It will get you going for sure. The danger is that it is temporary and they rarely allow for the planning and investment needed to maintain a new digital estate in a business as usual situation.
They can also become real pressure cooker environments, causing stress, anxiety and burnout – so you do have to make sure you look after yourself and your team, especially in the run up to board meetings.
Sounds like I am pretty against digital programmes. Perhaps I am – my preference would always be to build a permament team to do this stuff. Make digital change the business as ususal! It takes out a lot of the stress and anxiety, and makes it far easier to embed digital ways of working, and the core concepts and culture of agile, user centred design and so on.
However, in the real world, creating a digital programme is a mandate to get things done, as well as a shortcut to funds, which means people and new technology, if you need it. If you do go down the programme route, then the two most important things to get in place, for me, are:
agreement and clarity on savings and where they come from
a plan for the transition to BAU for the new digital services, and a properly funded regime of continuous improvement.
