I’ve been trying to watch / listen to the witness sessions of the Commons Select Committee on the “Use of IT” that have been taking place over the last two weeks. The strongest theme that I detect in these sessions is the bemusement that past governments and past projects have failed to address the issues.
One word that keeps on coming up in the discussions is ‘agile’. As always there are many explanations of what it is and I can’t help but feel that none of the explanations seem to provide the select committee with the eureka moment that people need to understand what it means and why it is different from the status quo. I wonder whether an explanation in terms of the management of risk might help a little.
Agile project management and the management of risk
For the sake of understanding what agile means, particularly from the perspective of management and strategy, let’s consider IT projects and the management of risk.
There is a strong tradition in some areas of management that says that management is about control. In other words, a well managed project is a project that is well defined, fully costed and running to plan. If a project fails, then the response is that the project was not controlled enough; it was not properly defined at the beginning; it was not properly monitored throughout; it was poorly costed and lacked strong management.
This view of management has been the driving force for many standards and methodologies that government has adopted over the years to keep projects in check and ‘ensure value for money’. But as we all know, history shows that, in a lot of cases, this simply hasn’t worked.
In reality, so called government ‘IT projects’ are often massive ‘change projects with an IT element’. These projects are massively complex and inherently highly risky. Just like risk in the financial markets that risk can be managed, but however it is packaged up and hidden away it will not go away.
Let’s take this analogy of financial investment a little further. Imagine that you are given some money to invest in equity in an area of the market that is highly risky but has the prospect of significant returns. Do you:
Invest all you money in one company, locking yourself into an agreement that prevents you from selling your investment for five years; or
Spread your risk across a number of companies, ensuring that you can sell your investment at any time and re-invest it somewhere else if the market changes or you realise that you made the wrong decision in the first place.
Now, imagine that, for some bizarre reason, you take the first option and you invest everything in one company. Would you reduce your risk if you took two years to decide which company to invest in and you ask each company to set aside a considerable period of time and resource in making detailed projections of where the company would be in five years time?
Okay, I hope it’s clear to see that this analogy bears remarkable resemblance to the traditional government approach to contracting out IT projects. I also hope it is clear that, when seen as a task of managing risk, the second option is clearly the way to go.
The second option is, in effect, the ‘agile’ approach. You diversify your risk and you reduce your risk by simplifying a big problem into a large number of smaller problems. You push against those who say that a project is inherently large and find ways of building a small working part of it very quickly. You push against those who say that everything needs to be produced by one company or team and use existing open standards as a way of guaranteeing interoperability. In this way you prevent ‘lock-in’, you open up projects to a much larger number of smaller development teams, and you encourage cooperation, experimentation and innovation.
I hope, for a few people, this explanation might help to bring a better understanding of some of the problems of government IT projects and why an open and ‘iterative’ (under whatever name) approach is crucial if government is to manage its risks and deliver the real potent for a huge return.