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.
