How Management Ratonale fails at IT (and what to do instead)

Apparently 70% of the Met Police's IT systems are obsolete, and it takes people half an hour to log in. But can the sustained, ongoing perspective of driving up "efficiency" by driving down costs bring a solution about? What does this quote, from the Chair of the Budget and Performance Committee, really mean:

The Met cannot afford to go on like this. Its forthcoming strategy must address these problems while focusing on the potential that new technology offers, to drive down costs while increasing productivity and boosting public confidence.

 As an engineer, it feels like none of these are particularly good primary reasons to improve the performance of a system.

For a start, potential is always around us, as the very nature of technology and progress. Making things worse is generally only done as an experiment in failure, in order to learn. Not as an end in itself. So duh, citing potential doesn't really mean much.

"Driving down costs", "Increasing productivity" and "Boosting confidence" - aren't these all just the effect of technology on other domains? As an engineer, there is no inherent economic value of making something "better" - but others may (and will) apply translations to turn change into measurement. Time is money, sure, but engineers focusing on saving money are not doing an engineering job.

Similarly, you wouldn't get a very useful system if you started out with "public confidence" as a primary use case.

So what does make a good rationale for planning an IT system? How can we bring about useful change without getting sidetracked into secondary effects? What model of management might encourage and reinforce this?

Sword and Shield

From a client-facing engineer's perspective, there are two key processes/perspectives needed, if engineering is to be a success. I'd say these are true of any engineering task, or project.

The first is having a clear goal - and if not, then deliberately specifying resources as experimental. Knowing what you want to achieve is the first key to getting a system running. Without this, how you get there becomes confused. As above, this needs to be a practical goal, not an abstract side effect. "Save me money" is not a technical goal. Nor is "Fix this problem". Users taking half an hour to log in is not a system problem, but just the way the system runs right now. It's only a problem if you're in a hurry.

The second is puzzle solving ability. If you're in a pickle, then you need a way to work out a solution, rather than wandering blindly around hoping for a solution based on luck. Puzzle solving is lacking in a world full of politics and plans. But without it, any attempt to change the system is worthless - even dangerous.

Problem solving is about analysing the system, and working out why it's doing what it's doing. It's about understanding, rather than wishful thinking. In fact, it's the opposite of wishful thinking. There are no wishes - and once you understand what's going on, there's not much thinking to do either.

Management as Spies

It seems amazing that management love plans, dashboards and reviews in order to find out what their people are doing. But have little in the way of understanding what the system that's being built by those people is doing. This is like an army general sending spies into their own camps to root out dissent, rather than finding out what the forces across the river are intending.

If management want to really improve productivity and cut costs etc etc, then it's not just a long term IT strategy they need, but a long term puzzle solving strategy. Costs are always relative, to both short and long term. Finding a solution that works isn't based on numbers though.

Tackling 400+ systems is an insane task, ie. it would send anyone insane. And having a crazy general leading you is fair grounds for becoming a Conscientous Objector. Any management looking to make real, sustainable changes needs to a) know what its "battles" are - ie. use the puzzle solving aspect to figure out just what the key problems affecting work are, and b) wield wisdom in choosing which battles to pick first - ie. which clear goals are the most important.

The second of these might well be based on other needs - deadlines, cash flow, etc. But in identifying such battles, one needs to be careful not to confuse needs with engineering process (that is, the two should be separate), and secondly to be clear on where that needs come from, to avoid confusion in the future (or during the work to unpick it).

Everything else will probably fail.

"Forget the data."

Holy crap, Emma Mulqueeny's (@hubmum) blog from yesterday on the next challenge for Open Data is possibly the. Best. Thing. I. Have. Read. In. A. Long. Time.

In particular:

Open data? Awesome, and we are making tracks.

Open Government? HARD, and we are not banging on that door yet."

and:

So what’s the next challenge for Open Government data?

Forget the data.

Find a way to enable these revolutionary ideas, apps, websites and widgets that save time, money and mind-numbing frustration from those who have to engage with government.

Do that, and only that.

This is the conversation we need to be having. Why? Not to work out "how to do it", but because it questions what is valuable and necessary in government.

Open data isn't a technical thing. It's about relevance. If you could do everything, what would you do? If you were hungry, would you eat, or would you talk about how to find out what the best thing to eat is and what the best way of eating it is?

"Open data" that lacks a medium for turning creative use into real-world change is irrelevant. It's what bad businesses do - they invent a million great things, but never actually want people to use them. Instead they use them as examples to tout how great and creative they are, in the strange hope that a people will think a symbol of progress is as good as progress itself.

Until, that is, someone comes along and not only has a better idea, but also actually builds it. For everyone to use.

Is that difficult? Of course - building stuff requires foresight, management, flexibility and the wisdom of knowing what your goal is. Do people do it all the time? Look around you.

Open data needs to be about other things now - including how it's funded, what the audiences are, and what the future holds. But none of these are about data. None of these are technical. We already have a society that runs on data, so data itself isn't a new paradigm.

We can't keep thinking of open data - and possibly even our entire creative efforts - as some kind of "continual prototype". We need to apply it like we applied sewage systems and electricity.

We need to understand that this isn't just about making the game easier to play, but about a whole new game.