The Cabinet Office’s introduction of an ICT Strategy which, amongst other things recommends the wider adoption of agile methodologies in the development of public sector IT systems represents a sea change in government thinking.
This and the commitment to the use of a broader range of IT suppliers, through initiatives such as the SME agenda, are to be applauded. This change of mindset seems to indicate a genuine commitment to innovation, rather than a token change. Methods such as agile development can drive real efficiency gains in the public sector with commensurate reduction in government spending.
However, without clear leadership, and change in procurement practices and programme governance, government organisations will find it difficult to evolve from the more usual prescriptive fixed-price/fixed-requirement procurement approach. The introduction of agile methods in the development of government IT solutions will require equally radical changes to government procurement – the processes and the mindset of those operating them.
Agile Approach
The impact of the public sector budget cuts on IT spending is tangible, leaving central and local government, education, justice, and NHS actively assessing new options to reduce the cost of the IT associated with their businesses. This is particularly true in the case of solution development of which there is a poor record of delivery in the public sector. So the spotlight is not only on cost; these organisations are also under ever greater pressure to achieve project success, and to minimise the massive overspend and project failure that has appeared to blot many public sector IT projects over the last two decades.
The Government’s response has been positive. The Cabinet Office’s IT strategy published in April 2011 recommended a raft of options designed to improve performance and minimise the risk of over-runs, over-spend and project failure. A key tenet of this strategy is the use of agile development, an iterative approach that splits projects into smaller, manageable pieces, and relies upon continuous user engagement to ensure the solution meets requirements.
Agile can also play a central role in reducing development risk, reducing the chance of project failure and improving the realism of stakeholder expectations. By providing early and regular visibility of system features, and promoting the ongoing involvement of business users, the scope of the solution can be better tuned to what the business actually needs (as opposed to what developers may think they need) and early visibility of possible limitations can be revealed.
Agile Approach
The impact of the public sector budget cuts on IT spending is tangible, leaving central and local government, education, justice, and NHS actively assessing new options to reduce the cost of the IT associated with their businesses. This is particularly true in the case of solution development of which there is a poor record of delivery in the public sector. So the spotlight is not only on cost; these organisations are also under ever greater pressure to achieve project success, and to minimise the massive overspend and project failure that has appeared to blot many public sector IT projects over the last two decades.
The Government’s response has been positive. The Cabinet Office’s IT strategy published in April 2011 recommended a raft of options designed to improve performance and minimise the risk of over-runs, over-spend and project failure. A key tenet of this strategy is the use of agile development, an iterative approach that splits projects into smaller, manageable pieces, and relies upon continuous user engagement to ensure the solution meets requirements.
Agile can also play a central role in reducing development risk, reducing the chance of project failure and improving the realism of stakeholder expectations. By providing early and regular visibility of system features, and promoting the ongoing involvement of business users, the scope of the solution can be better tuned to what the business actually needs (as opposed to what developers may think they need) and early visibility of possible limitations can be revealed.