Getting simple ICT shouldn’t be complicated


Keep it Simple

My husband likes, on occasion, to cook. He doesn’t call it cooking of course: it’s culinary creation, during which he somehow manages to use every single herb and spice in the cupboard, even if he is only making an omelette. His opinoins is that because we have a lot of ingredients, to a lesser or greater degree we should make use of them.

I was reminded of this when I sat through a presentation about the latest piece of software being touted to me recently. The salesman took us through what it could do, ring all of its bells and blowing its whistles, and over the course of three hours showed us how his many other customers live their lives by the information they put in and get out of this master system.

Not once did he really think of asking us what we actually needed it to do.

The spec we were developing is simple enough; we need a system to hold some information, allow members of the public to leave some comments and to hold different types of information in an easily searchable system. In essence we want something no more complicated than a simple dating website.

Instead the presentation we received from this salesman – and many before him – took us through pages of different reports it could churn out, how they could change the logo (oooohhhh……..) to our own, how they could accept more than one user logging on at the same time, some strange collaboration software seemingly bundled in and a suite of other less useful options, along with three different modules which could be plugged in to do even more random stuff.

Essentially, he didn’t understand that just because we could, doesn’t mean we should.

This focus on the technology behind ICT tools rather than what we actually want it to do seems to be endemic at my council. I have lost count of the number of systems over the years which have promised that they will be game changers, that if only everyone uses them to their fullest extent then the worries of the world will melt away, and that all such use will take is a three day training course (delivered at additional expense of course).

If the late, great Steve Jobs taught us anything, it’s to look at what we are trying to do first, and then make the technology fit around that. According to legend, after the disappointing launch of MobileMe he called his team together, asking them “Can anyone tell me what MobileMe is supposed to do?” Having received a satisfactory answer, he continued; “So why the **** doesn’t it do that?”

That simple thinking too often goes out of the window when we look at developing or procuring council ICT projects. Everyone is so focussed on the sales pitch, on agreeing a four hundred page technical specification and tieing everything together in one neat but fictional single sign-on utopia that they end up with systems which meet the interests of the people developing it rather than the needs of their service or our residents.

Take intranet sites for example. Ask many users what they want on an intranet site and they will keep things simple: a directory of phone numbers for council officers, easy access to some news about the council in general and some links to any templates they need.

Corporately, to this list is added every policy and procedure there is, along with guidance and signposting so as it can be said that everyone has access to all of the council information they need.

So why then do we end up with intranet sites providing weather reports, news feeds and links to our e-mails? Some have whole areas dedicated to managing downloads, others also have links to photos taken several years ago which are useless.

As with all of our work, we need to trim much of our ICT functionality back to what we and its users need it to do. If we want a system to allow people to check their library books in online, let them do that and don’t then also expect them to use it to produce a graph showing the number of other people who had borrowed that book; if the system is there to deliver news updates to them then it shouldn’t also be trying to track whether or not they were sticking to their diet by counting their calories.

If we keep in mind what we need ICT to do rather than getting sidetracked by all of the other things it could do, we can concentrate on making this work better than eer before. We have less time and money than ever: focussing both will result in far better systems.

We should start thinking along the lines of “would Apple do this?” rather than “if only everyone uses all of the features here, our problems are solved!”.  Let’s keep it simple.

Welovelocalgovernment is a blog written by UK local government officers. If you have a piece you’d like to submit or any comments you’d like to make please drop us a line at: welovelocalgovernment@gmail.com

Explore posts in the same categories: We love the Council

Tags: , , , , , , ,

You can comment below, or link to this permanent URL from your own site.

17 Comments on “Getting simple ICT shouldn’t be complicated”

  1. Andreane Thomas Says:

    Too true too much time seems to be spent on what the IT system should do & not what we, the client, actually need it for.


  2. I agree with this 100% but why doesn’t it happen? Because keeping things simple is one of the hardest things you can do, especially in an organisation that’s not wired for that kind of thinking. This is compounded when you’re dealing with suppliers that are also kitchen-sink thinkers. In general suppliers think that they can get more business and make more money by providing more stuff. In general they’re right because most customers see the supposed advantages more than the costs of overblown software and systems.

    “What’s so hard about being simple?” could easy fill a book but there are a few common factors:

    – People don’t realise that when you add something you take something away. Your increase in literal functionality gets traded off against clarity, ease of use, ease of learning and user satisfaction.

    – People find it hard to make decisions. Tell your children that they can have 30 Christmas presents and they’ll happily start writing lists. Tell them that they can have only one — within reason, anything — and they’ll probably hate you forever. It’s so much easier to throw in the kitchen sink than think through what you really need.

    – You can’t predict the future. Trying to anticipate hypothetical future needs is a great way to buy a ton of junk that you don’t need now and won’t ever need. But if your procurement process is lengthy and cumbersome and you’re going to have to live with a new system for several years it’s tempting to grab everything you can because you know you won’t have a chance to do it later.

    For corporate IT I’d recommend:

    – Start small. Purchase or build the minimum system you need to meet your current needs and build it up from there when necessary and not before.

    – Choose or build modular systems that can be extended when necessary rather than having to throw out the whole system and trade up.

    – Use systems that can talk to each other. Follow the Unix philosophy of systems that do one thing well and can easily be combined with other systems to produce toolchains and capabilities that are much greater than the sum of their parts.

    – Streamline procurement. Build in preferences for small systems and short-term contracts. Try to make it as cheap as possible to change your mind and to trade up when future needs change rather than forcing people to stick with systems that no longer suit them.

    – Hire some good developers (Hi!). Many useful small systems can be quickly and cheaply built in-house in far less time and for far less money than buying a commercial product. When that system needs a small change you can quickly and cheaply just make it rather than being at the mercy of an external supplier to do it. They could take months or they might not be interested in doing it at all.

  3. localgovalso Says:

    I’d agree with both of these, and I suspect we’ve had the same company giving the same sales pitch as the OP.

    We went down the contracted developer focussing on specific functions in the end; this hasn’t been without difficulties (because the flexibility means you enter the world of rapidly shifting priorities and there have been some notable delays as everyone gets their ‘bit’ in, although I grant that is a project management failing at our end – not mine, I’d stress) but is certainly preferable to ending up with a behemoth of a system which the public and members ignore and officers loath.

  4. LGWorker Says:

    I’m sure I’ve come across systems in Councils that were built by Councils coming together and saying this is what we need (or did I dream that?).

    The only thing I would say is can we have systems that talk to each other! I’m fed up of having to use three different systems to do one job because they won’t talk to each other and when the team was three different separate teams (restructures merging us into one), they all procured systems that don’t talk to each other.


  5. The IT supplier should scope out the requirements of the client and explain how their system will fit these requirements and more importantly what aspects of their system will not be able to meet their requirements.


  6. I sincerely hope this wasn’t us 😮


  7. I sincerely hope it wasn’t me. 😉


  8. […] This post started life as a comment at We Love Local Government. […]


  9. […] some respects this harks back to recent discussion around keeping ICT systems simple. GIS may have a world of functions and uses that only it, in all of its ponderous and grinding […]


  10. […] demos are often too long and they shouldn’t be. This great post from We Love Local Government hit a nerve. The post inspired us to set out some principles for how we […]

  11. Ben Unsworth Says:

    I can personally vouch for both Delib and Adrian Short in making excellent software that does one thing very well 😉


  12. […] This post started life as a criticism during We Love Local Government. […]


  13. […] blogged before about the proliferation of overengineered and bloated software systems which are incompatible with each other, each requiring a different and constantly changing […]


  14. […] something we’ve spoken about for a while now, and it looks like we’re not alone.  According to Liam Maxwell when he spoke […]


  15. […] iterative approach is one we have been advocating for in the online world; there is no real reason why the positive lessons cannot then be taken to the […]


Leave a comment