A GDS approach to internal systems? Please?

it-fed-upThe Government Digital Service is the UK government’s solution to the issue of ensuring that government services are accessible and usable for citizens online. Quite rightly they have received plaudits for their approach to service design and delivery.

This is set out in the service standard, a list of 26 criteria that digital services should meet. It’s a great list.

Having worked at pretty much every level of government there is, I certainly appreciate the need for citizen facing services to be of high quality. But that experience also makes me wonder just how much could be achieved if a similarly robust standard were taken to the design of systems used internally by government departments, councils, and so on.

Actually, make that all large organisations, regardless of sector.

After all, how much in cashable savings could be achieved if it took a minute rather than half an hour to log a leave request, or book some travel?

Or how about the design of some of the big applications that people use to do their work – big lumbering databases with godawful user interfaces which give everybody their dim view of technology and what it can do in the workplace?

I was chatting to Meg Pickard about this yesterday and she confirmed the vital importance of the end user need. Part of the issue here, Meg felt, was that internal systems such as the ones we were talking about were invisible to the public, and so demonstrating value to citizens is difficult – it could be perceived by some negatively, as civil servants spending time and money designing pretty tools for themselves.

There is also a potential danger that this discussion – venturing into areas marked by signed saying “Danger! ERP!” – could be seen as ocean boiling territory.

However, how hard would it be for a simple, usable travel or leave booking system to be built as an agile prototype and shared amongst organisations, just to prove it could be done?

After all, the app-ification of IT demonstrates that having single use applications tends to work pretty well for most people, rather than vast monolithic systems that try and use the same process to achieve different tasks.