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.
User stories are the strongest way you can capture requirements for your digital service and are another key component in taking a user centric approach to design.
Rather than the old way of doing things, of producing a specification document outlining every single feature that a product needs to have, user stories focus on the needs of the users of that product, and specifically on their outcomes.
This focus goes a long way towards producing services that are usable and deliver end to end, rather than breaking down halfway through because a feature ‘works’ technically, but doesn’t do what is expected or needed.
Additionally, user stories can be a great way to bring a product to life when describing it to stakeholders. It really demonstrates a new way of talking about digital services and technology, and can be very meaningful to non-technical folk, giving confidence that you’re doing the right thing.
In a multi-disciplinary team, the user stories are usually the domain of the product manager, written with the input from the rest of the team. If you don’t have all the roles in your team, then do try to have a single person responsible for the compilation of user stories – and try to have someone non-technical doing it, to avoid the temptation to leap into solutionising too soon.
Writing a good user story follows a certain format:
As a…
I need to…
So that…
For example:
As a new, and busy resident who drives to work in the town centre
I need to apply for a parking permit online
So that I don’t run up loads of parking fines
That’s quite a high level example (often referred to an ‘epic’ story), so we can probably come up with a more granular user story:
As a resident who has applied for a parking permit online
I need to be proactively kept informed of the progress of my application
So that I don’t need to keep contacting the council
Note that the user story doesn’t explicitly state here what the solution is. The focus is on the outcome that the user needs, not the technology that will enable it.
Additional information for a user story might include the prioritisation of that story, so the team know how important it is to get that story completed, and also the size – how much effort is likely to be needed for the story.
Here’s some tips for writing good user stories:
Keep them small. If they start getting to wide in scope, treat them as an epic and break them down into smaller stories
Avoid the temptation of repeating your ‘I need to’ in your ‘So that I can’ – which is a really common error. For instance – ‘As a manager, I need to access my team’s performance dashboard, so that I can view the perform dashboard’
Don’t treat individual technical pieces of work as user stories. They might be important to the project, but that doesn’t mean they directly contribute to meeting a user need, and doing so can clog things up and spread confusion about what the outcome of the project is intended to be
Try following the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) formula for producing good user stories. It’s a handy framework to ensure your stories are what you and your users need. Read more about that here.
To make life easier, here is a simple template for writing user stories. Feel free to amend it any way you like!
