Beyond the Mandate: How to Avoid Duplication Without the Force

is this the unicorn we’re looking for? (photo: James Kemp)

I was at the Holyrood Connect Public Sector Digital Leadership Exchange at the University of Edinburgh earlier this week and one of the common threads was whether certain things should have a mandate from the centre to avoid duplication of effort and to align services across government.

While this was mostly in a Scottish context, those doing the asking were mostly local government addressing the question to Cosla and Scottish Government people. It isn’t an unfamiliar question that goes round in the UK Government level either. There are a great many advocates internally and externally that think it would be simpler and easier just to set a central mandate on the important things from No.10 or Cabinet Office.
A Mandate seems an obvious answer, and like a lot of obvious answers it appears easy to implement and would save a lot of time and money reducing duplication across government.  I mean how many taxi licensing IT systems or planning application processes do we need across the UK?

Mandate – simple, attractive, and wrong.

There is a problem that needs to be solved, and there are real benefits to be achieved from reducing time and money spent on developing multiple systems. We shouldn’t immediately jump to the solution though.  Each problem should be clearly defined, the success criteria carefully chosen, and then we can move to generating as many options as we can imagine before choosing the right one for each specific problem.
In some cases there will be excellent existing systems that already do everything we need. In those cases we should most probably negotiate the best price we can get, and then licence it across the whole of government (UK, Devolved Governments, and local) that needs it. What is key though is taking the time to carefully choose the right tools and technologies before jumping in.

Co-Design before Mandate

In most cases it needs a co-designed solution to surface all the user needs across end users, government bodies, politicians and others involved in the service in question, whether as customers, service providers, decision makers, or accountable officers. This is the part that mandated services tend to drop first when pressed. If people need to use the service anyway they do this at their desks based on their own hierarchy’s needs. This leads to missing essential elements, whether in functional requirements or the responsiveness of the system to user needs. Especially the service providers in other parts of government.
I saw this myself in the initial implementation of a shared ERP from the Cabinet Office in 2012-14. The central team didn’t listen  to the requirements from the ALB I was an Enterprise Architect in. Their forced ‘solution’ broke a lot of the systems integrations we used in operations. I brought that experience to Cabinet Office a decade later when the replacement was needed and brokered a different approach as the director of the Shared Services for Government Portfolio.

Services So Good…

As well as getting out to co-design solutions with the people that will use the systems and services that result, you also need to make sure that the service you deliver is so good that people choose to use it. That’s more than throwing in all the requirements you’ve collected.  You need to work hard to simplify it so that it does what is needed, and no more. It should be driven by core needs, User Experience (UX) driven design, and made as simple and intuitive as possible to deliver positive outcomes.  Above all else it should just work for the purpose people need it for, and solve the whole of the problem for them.
You need to deliver it as cheaply as possible on a per user/organisation basis. This is tied to the point above. If it works well, and is cheaper than the alternatives then it will create a network effect as more and more organisations adopt it. That’s where you save the time and the money, but you need to keep an active development/maintenance teams to actively manage the service and do continuous improvement throughout its life. It’s not seen as flashy or interesting, but it is how you persuade the laggards to adopt the service, and everyone else to stay on it. As people use services they’ll find more value add things it could do, or ways they can streamline and simplify further, and you need to patch the bugs you only spot with real volume loading too!

When you must Mandate

That said, there are things that should he mandated. Standards, especially data schemas that drive interoperability or enable micro-service components to be used. Making your data portable and software agnostic are hugely valuable to all organisations, and especially public sector ones that have a duty of both transparency and stewardship of public funds. Reporting, collaboration,  and public accountability are also valid things to mandate. Everything else though should be through delivering effective solutions to specific problems that maximise the economies of scale that government has while ensuring the user needs at all levels are met.

Leave a Reply