Last week, the Commons Select Committee on the Use of IT interviewed Local and Central Government departments and the largest supplier to government which also was the only large supplier willing to take part as a ‘public’ witness. This week they questioned the government minister but I haven’t got round to watching that yet as the video stream requires me to watch in real time and be physically in front of a computer with the appropriate plugins installed. I would have preferred to be able to watch it at double time on the bus!
The local government representatives, though they may not be representative, largely demonstrated an understanding and engagement with issues even if, in one case, they found it hard to express that in ways that could be understood by the committee.
Central government departments
The representation from the central government departments gave me considerable cause for concern. If I were responsible for their current projects I would be asking lots of questions. Here are a number of the comments that rang warning bells:
- 60% of the current project is being done in an agile way, the other 40% (core infrastructure) is not.
- “legacy systems are not suitable for agile”
- The advantage of using an existing supplier is that you can re-use skills and people and existing knowledge.
For clarity, I should explain why these rang warning bells:
One of the key benefits of agile is the ability to deliver a very early release of a product ‘end-to-end’ within a short time-scale. The act of doing this de-risks a project immensely and the act of failing to do this is a much less expensive way of discovering that something is wrong! You can’t deliver an end-to-end early release if the core infrastructure is not part of the system. So, there may be apparently valid reasons why this project cannot be 100% agile, but those reasons, or the decisions made in response are a sign of a problem.
It simply isn’t true that legacy systems aren’t suited to agile management / development techniques. In many respects, renewing (‘refactoring’) legacy systems is a task that benefits hugely from the principles of agile. In particular, agile provides skills and techniques for reducing the cost of change and one of the big problems with legacy systems is their cost of change. So, this quote, from one of the key leaders in the public sector, tells me that they simply do not understand what ‘agile’ means or can do.
Continuity is clearly a great way of retaining knowledge and skill. I think government should be doing a lot more to retain skill and I think procurement practices tend to enforce the throwing away of knowledge and skill, ultimately at the expense of the public who pay for everything. But you cannot, on the one hand claim to be running a procurement process that is even handed and at the same time argue that re-using the same supplier enables you to re-use skills, people and existing knowledge.
Integration, centralisation and efficiencies of scale
Anyway! All of these evidence sessions to date have thrown up enough material to write a book which is why it’s taken me another week to write anything coherent.
But, I’ve been saved because this week I reached page 57 of the “Written Evidence” document - the submission of Andrew Hardie which very effectively expresses my views on almost everything. To be honest, this is quite disconcerting at first, but also very encouraging as writing has never been my strong-point! To quote one of his points which I agree with wholeheartedly but which is a point made by few if any of the other contributers:
Perhaps, the greatest fallacy in both government and private sector ICT systems implementation is that greater systems integration is the answer. It isn’t. The more tightly you couple ICT (or, indeed, any) systems together, the greater the speed, range and impact of problems and side-effects become and the harder it is to change the resulting monolithic systems, precisely at the time when ever greater agility is needed.
There is a constant push to standardise systems in government to obtain ‘efficiencies of scale’ through more efficient procurement or through the wide use of identical software. This push for standardisation and efficiency almost always results in a decision to roll out a massive IT project. The conversation appears to go something like this:
A: We mustn’t have any more huge IT projects that cost too much and go wrong.
B: I totally agree.
A: Okay, so how are we going to reduce costs in IT projects.
B: Well, we are aware that there are lots of departments re-inventing the wheel with different IT systems that do fundamentally the same thing. We need to standardise the systems they are using and cut the outrageous costs of this duplication which is caused principally by a failure of communication between departments. The left hand doesn’t know what the right hand is doing!
A: Yes, I totally agree. It’s shocking!
B: Okay, so lets set up a project to consolidate all the systems together into one standard system.
A: Fine. Go ahead!
Yes, in the course of a few sentences they have moved from deciding not to have a huge IT project to setting up a new one, yet the flaw in the argument seems hard for government to spot!
There are all sorts of costs of complexity associated with interactions with people. Very rarely do multiple departments actually do the same thing. When you try to bring everything they do together into one system you typically end up with a system that is far too complex or a system that doesn’t meet the needs of the people you are producing it for.
The fundamental flaw in the argument above is the belief that different departments are actually doing precisely the same thing. In reality, if you talk to the users, you will find lots of differences in need and use and common practice. If you want to make the users more efficient at doing their work then you need the system to be tailored to their need not imposed on them from above.
The more complex flaw is that they criticise the departments for not communicating without recognising the additional cost and complexity introduced by requiring departments to communicate with each other! Failure to communicate is a cheap argument that is almost guaranteed to be accepted as grounds for criticism. But communication takes time and we almost universally suffer from too many meetings and not enough doing.
