Reactions to the IFG Report
After being part of the team that put the IFG report together on Systems Failure I am both encouraged by the response but concerned about the range of opinion. Opinion is good and democratic but often not helpful when it comes to being able to deliver something. In reacting to discordant voices the conditioned response is more likely to be either blind stridency on the part of the report authors or accommodation which leads to death by 1000 ideas as studied by Belbin on the collective IQ of teams..
Ideally the response is to synthesise a solution from as many differing opinions as possible but at the same time remain capable of coherent action. The love it / hate it opinion on agile forces the either/or dichotomy of managing which generates the pendulum swing of management fashion oscillating from one extreme to another. Discordant strident voices become the trigger for management fads and the reified “”my way”” is best simplify defies the reality of the problem being tackled.
As a skilled manager, or sane individual, you avoid the worst of extremes and learn by integrating the potential of new ideas with the practicality of the old ones. The passion of the zealots may inspire the heart but all too often they mess with the head. If in doubt try the simple diagnostic of “when good ideas go bad” where too much of a good thing become toxic – in the lab carrot juice can kill not because it is inherently toxic at low levels but in extremis the toxic limit is reached.
This thinking brings me to one of the key challenges and core peeves around IT. I also have a background in Operations Research (70’s discipline) or Systems Thinking (popular 00’s term for the same thing) so I recognise the need to understand the problem before rushing into a solution. And it is precisely ‘solutionology’ that generates much of the disconnect in IT generally, in big IT and big bad government IT. Einstein recognised this in his writing “If I was engaged in a really difficult task and had just one hour to live I would spend at least 55 minutes on trying to understand the problem as I know that once I understand the problem the solutions come easily“.
Recent material on scale would suggest that per-se scale is bad and certainly government IT see scale as special. Inherently it is neither bad nor special. Large and successful IT implementations dwarf both government IT and gives proof that scale does work – it also begs the question of your problem understanding, design and applicability in cases where it does not. But it should not provoke a luddite response as seems fashionable from some consultants. And before you condemn big failed IT projects (such as the national identity card) think first how big successful IT systems work (such as Visa or Google).
The report took some time to consider procurement. For me the damning statistic is to compare the average 77 weeks for major procurements and the 5 years in which Facebook has come from nothing to 25% of the US web traffic – or just 4 procurement cycles. It is here that the simple logic of agile – iterative learning the problem and progressively delivering solutions – can make a big difference, in the video I suggest that it is not failure of government IT that is bad, but it is the long, slow and expensive failure of government IT that sees the worst of all possible outcomes. Small companies, entrepreneurial outfits and researchers are not immune to failure – but they learn to fail fast and fail cheaply! Perhaps the successes would look after themselves if the failures could be managed cheaply, and whilst agile approaches handle success and failure equally well the established methods manage only success.
Although we had a number of discussions on risk here too Agile makes a difference. Simply by making the productive focus on workable components progress is evident and the need to ‘trust and verify’ can be managed around the tangible outputs and outcomes of work. Much of institutional attitude to risk is around proxy measures to verify hidden progress or measure inputs as a proxy for outputs. The academic theory of agile management draws from the manufacturing revolution in reducing queues, making work visible, eliminating waste, managing by outcomes and navigating by customer pull. It is only now being applied to IT development. Every supplier organisation should welcome this remembering, of course, that their reputation is sustained on the last thing they delivered.
From the comments there are already some terrific ideas, deep expertise and substantial knowledge that can help government IT but every idea is amplified by its integration with others as opposed to standing in splendid isolation. Drawing from Leon Walras’s economic theory of utility the best ideas are the product of the quality of the idea and its adoption …
