Foreword 1

SYSTEM ERROR Fixing the flaws in government IT

Justine Stephen, James Page, Jerrett Myers, Adrian Brown, David Watson and Sir Ian Magee

2 Foreword

Foreword

Government IT offers many challenges but, it seems, few solutions that satisfy everyone. There is a well-documented history of too many high-profile and costly failures. This is rarely the fault of the underpinning technology: policy complexity, late additions to already-long lists of requirements; inadequate change management processes; and a failure to bring users fully in to the picture, all play their part. As with many organisations, there remains a critical dependence on legacy systems for large transaction processing, with the consequent need to deal with interoperability between systems. These issues haven’t suffered from a lack of analysis: the National Audit Office; the Public Accounts Committee; and many other commentators all have opinions and viewpoints on what needs to be done to put matters right. However, the plain fact is that problems continue, despite forceful recommendations from powerful groups about how to improve the process so that government does better.

Meanwhile, as this report brings out, the possibilities IT offers for wholly transforming people’s lives increase exponentially with each passing year. The pressure to produce more for less is a dominant theme for delivering public services; and the Coalition’s plans are wide-ranging, and demanding of innovative and inventive solutions. It is clear that something has to change: government IT cannot be stuck in a time warp, when all around, commercial organisations are responding to very similar imperatives. What was right for the 1980s is unlikely to be acceptable today.

The good news is that on the basis of the substantial research described in this report, we are convinced that there is a much better way forward for government IT. We have been indebted to many people, notably the Taskforce members who have steered our work, and whose names are listed in the ‘About the Taskforce’ section; to the Home Office and the Metropolitan Police, whose co-operation around a real project utilising agile development techniques opened their eyes, and ours, to the possibilities which rapid development offers; to the seventy or so people whom we interviewed, from public, private and voluntary sectors; and to all those who participated in the several workshops and seminars we ran at the Institute. Finally, none of this work would have been possible without the generous sponsorship provided by Research in Motion.

In the end, the recommendations are the entire responsibility of the co-authors, all of whom played a significant part in this. We could not, however, have got this far without the many people who played such a large part in helping us.

Sir Ian Magee, CB Senior Fellow, Institute for Government

Contents 3

Contents

About the Taskforce 4

About the authors 7

Acknowledgements 8

Executive summary 9

1. Introduction 16

2. The case for change 19

3. The solution: platform and agile 30

4. Building the platform 36

5. Agile projects 47

6. Conclusions and recommendations 58

Bibliography 61

Annex A: Methodology 65

Annex B: Procurement, contracting and the Gateway Review process 68

Annex C: Case studies 76

Annex D: Survey of Public Sector CIOs 96

4 About the Taskforce

About the Taskforce

The Institute for Government established a high level Taskforce of government and private sector CIOs, senior civil servants and thought leaders to provide expert support and guidance on how to radically improve government IT.

Chair: Sir Ian Magee – Institute for Government Ian is a Senior Fellow at the Institute for Government. Until 2005, he was Second Permanent Secretary at the Department for Constitutional Affairs and Head of Profession for Operational Delivery for the whole Civil Service. He has been a CEO of three different executive agencies, including the Information Technology Services Agency which provided IT products and services for DSS.

Ian conducted a review of criminality information for the Home Secretary (2008) which was about more effective and innovative sharing of criminality information among appropriate agencies, to improve public protection. Ian has a special interest in public sector leadership, is a Companion of the Chartered Management Institute, and a fellow of the Sunningdale Institute.

Ursula Brennan – Ministry of Defence Ursula is the Permanent Secretary at the MOD. She is responsible for the effectiveness of all MOD’s activities as a Department of State and is the senior civilian policy adviser to the Defence Secretary.

As the department’s Accounting Officer, Ursula is personally accountable to parliament for the efficient use of defence resources and the regularity and

propriety of defence expenditure. Prior to joining the MOD, Ursula was Deputy Permanent Secretary and Director General Corporate Performance at the Ministry of Justice, having previously led the review to create the structure for the new Ministry of Justice.

Ursula has also held senior positions at Office for Criminal Justice Reform, Defra and the former Department of Health and Social Security (DHSS). While at DHSS she led the strategy on welfare to work and benefits fraud, and was for a time a director of the Information Technology Services Agency.

About the Taskforce 5

Roger James – University of Southampton and Computiv Roger brings technology led innovation to research led, information intensive industries which include defence, academia and pharmaceuticals and life sciences. His 30 year career journey from developer to CIO included CAP, IBM, Glaxo, Napp Pharmaceuticals, The British Library and The University of Westminster.

Roger is also a Visiting Professor at Southampton University with a research practice in the semantic web, social media and user generated content. Key results have been delivered in patient health and a student led ‘Wikipedia’ approach to the development of corporate systems. From the consultancy Computiv Roger brings this work to market for clients such as ARM, BP, BT and AZ on innovation, corporate agility, systems thinking and knowledge management.

John Keeling – John Lewis Partnership John is the Director of Computer Services for the John Lewis Partnership. In this role he is responsible for all shared IT infrastructure, shared systems, and all shared IT services for the John Lewis Partnership. Prior to joining John Lewis, John spent 10 years as independent contractor / consultant working on major project development for Prudential, Cable and Wireless, Shell UK Oil and Waitrose.

With technology increasingly at the core of major business change programmes, he views good project management, clear success criteria and engagement with the business and sponsors as key to success. John’s interest and focus centres on how to blend the necessary processes and discipline with common sense, flair, innovation and the intangible nature of people engagement.

David Lister – National Grid David is the Group CIO at National Grid, responsible for the considerable IT infrastructure underpinning the utility company’s operations. Prior to this, David was the global CIO and chief architect at RBS and he has also held senior positions at Reuters, Boots, Glaxo Wellcome and Guinness.

6 About the Taskforce

Bill McCluggage – Cabinet Office Bill joined the Cabinet Office as Deputy Government CIO in September 2009. He is also Director of ICT Strategy and Policy within the Office of the HM Government CIO with overall responsibility for the formulation, development and communication of cross-Government ICT strategies and policies. On behalf of the Government CIO and CIO Council he chairs the CTO Council and CTO Delivery Group.

Bill joined the Cabinet Office from the Northern Ireland Civil Service (NICS), where he represented Northern Ireland on the Government’s CIO Council and was the Senior Information Risk Owner (SIRO) for the Northern Ireland Civil Service. Prior to joining the NICS he held a number of senior positions in private sector companies, including IT Director for Harland & Wolff Heavy Industries in Belfast and prior to that served in the Royal Air Force.

Bill is a Chartered Engineer and Member of the Institution of Engineering and Technology. In June 2008 he was appointed a Visiting Professor within the School of International Business at the Ulster University, Magee Campus.

Tom Steinberg – mySociety Tom is the founder and director of mySociety, a non-profit, open source organisation that runs many of the best-known democracy websites in the UK. These include the parliamentary transparency website TheyWorkForYou and the somewhat self-explanatory FixMyStreet. mySociety’s missions are to build websites which give people simple, tangible benefits in the democratic and community aspects of their lives, and which teach the public and voluntary

sector how they can use technology better to help citizens.

Previously Tom has worked in the Prime Minister’s Strategy Unit (2001-2003) and as an advisor to the Conservative Party (2009). Tom is also a member of the recently established Public Sector Transparency Board.

John Suffolk – (formerly) Cabinet Office John spent five years as Her Majesty’s Government Chief Information Officer and leader of the CIO Council (2006 – 2010). He has a background of over 25 years' experience in IT and major transformation programmes. John has worked in the engineering and financial service industries and has extensive experience in delivering IT-enabled change.

About the Taskforce 7

Annette Vernon – Home Office Annette is currently on sabbatical from her role as the Home Office CIO. A civil servant since 1984, Annette worked her way up through the technology career ladder from coding and design rapidly rising to Director and CIO positions. She has worked across a variety of Government areas including former Department of Health and Social Security, the Courts Service, Constitutional Affairs, the NHS and most recently as CIO in the Identity and

Passports Service. She has won multiple awards for innovation and was a driving force behind the Home Office ‘hack days’.

About the authors

Justine Stephen is a Research Analyst at the Institute for Government. Prior to this she was a consultant with Deloitte’s Technology Integration practice, working on high profile change projects across the public and private sector.

James Page is a Senior Researcher at the Institute for Government. Previously, James was a manager at PricewaterhouseCoopers LLP and has also worked at the former Department for Education and Skills' Innovation Unit and at the think tank Demos.

Jerrett Myers is a Senior Researcher at the Institute for Government. He was previously Research Coordinator at Oxford Policy Institute and prior to that worked in the Canadian civil service.

David Watson was an Intern at the Institute for Government up until February 2011, working on the Institute’s strategic review and its improving government IT project.

Adrian Brown is a Fellow at the Institute for Government and leads the Institute's work on improving public services and IT. He joined the Institute in March 2010 from McKinsey & Company's public sector practice.

Sir Ian Magee is a Senior Fellow at the Institute for Government. Until 2005, he was Second Permanent Secretary at the Department for Constitutional Affairs and Head of Profession for Operational Delivery for the whole Civil Service.

8 Acknowledgements

Acknowledgements

The authors would like to acknowledge the advice and support received from the many people who have helped make this report possible.

The Taskforce provided us with invaluable guidance throughout the project and introduced the team to many new avenues of investigation.

The ‘live’ agile project would not have been possible without the vision and persistence of several individuals, in particular Jennifer Rigby, James Buckley, Sarah Heseltine, Robert Step and Bob Chatterton at the Home Office and Gary Miles, Russ Middleton and Nick Downing at the Metropolitan Police. John Wright, Duncan Green, Jason Smith and James Yoxall from Indigo Blue provided the hands-on support and agile expertise.

We interviewed over 70 people during the course of the project from across Whitehall, the IT industry and the private sector. It is impossible to thank them all by name, but the team would like to particularly acknowledge the contributions from Mike Brass at the Institute for Government, Steve Dover and Damian O’Gara at the Department for Work and Pensions, Simon Fitzgerald at CIFAS, Stephen Messenger and Mary Henson at DSDM Consortium, Mark O’Neill at the Department for Culture, Media and Sport, and Steven Railton and Darren Thorpe at the Ordnance Survey.

Finally, none of this work would have been possible without the generous sponsorship provided by Research in Motion. We would like to thank Elizabeth Kanter and Erica Fensom at Research in Motion and Martin Lejeune at Open Road.

Executive summary 9

Executive summary

“IT in government is as difficult as it gets”1

Information technology (IT) continues to revolutionise the world in which we live at a breathtaking pace, fuelled by the exponential development of computer processing power and the growth of the internet. In the last decade we have witnessed extraordinary advances that have changed the way we interact with each other, consume media, work, shop and play. These were mostly in ways that were unpredictable.

– Ian Watmore

Getting the best out of government IT is extremely challenging. Despite costing approximately £16bn per year,2

Most attempts to solve the problems with government IT have treated the symptoms rather than resolved the underlying system-wide problems. This has simply led to doing the wrong things ‘better’.

government IT seems locked in a vicious circle: struggling to get the basics right and falling further and further behind the fast-paced and exciting technological environment that citizens interact with daily.

Working with a Taskforce3

This report shows how government IT can turn the vicious circle into a virtuous one. Driving efficiencies and supporting innovation should become mutually reinforcing themes.

comprising departmental chief information officers (CIOs), top private sector CIOs and IT thinkers, the Institute for Government has observed and reviewed the trialling of a live IT project, interviewed over 70 leading IT experts, and reviewed the evidence from international and private sector case studies. While the focus of the report and its recommendations are aimed at central government departments and arms length bodies, the principles and the approach can be applied throughout the public sector and will require the support of suppliers to help shape the future of government IT.

1 Quoted in Mark Say, ‘The Information Man’, Government Computing, 19:2, 2005, p. 16 2 Latest total spend based on the estimate in the Operational Efficiency Programme final report. 3 The Taskforce members are Sir Ian Magee (Institute for Government), Ursula Brennan (Ministry of Defence), Roger James (Computiv and University of Southampton), John Keeling (John Lewis Partnership), David Lister (National Grid), Bill McCluggage (Cabinet Office), Tom Steinberg (MySociety and Public Sector Transparency Board), John Suffolk (formerly Cabinet Office) and Annette Vernon (Home Office, on sabbatical)

10 Executive summary

The case for change There have been some notable government IT successes such as online vehicle road tax or the Department for Work and Pension’s (DWP’s) Payment Modernisation Programme

delivering direct payment of certain benefits to claimants’ accounts.4

Numerous reports and articles have pointed to a long list of problems: chronic project delays; suppliers failing to deliver on their contractual commitments; not designing with the user in mind; divergent costs for simple commodity items; incompatible systems; the high cost of making even basic changes; ‘gold-plating’ IT solutions; and failing to reuse existing investments. Moreover, there is a critical dependence on legacy systems, and the need to deal with interoperability between these systems increases cost and complexity.

However, the reputation of government IT has suffered from repeated high profile failures.

These problems have been widely rehearsed but proved stubbornly resistant to change. This is because government’s approach to IT is fundamentally flawed for our times.

Traditional linear IT project approaches, like the V-model and Waterfall, assume that the world works in a rational and predictable fashion. Specifications are drawn up in advance, ‘solutions’ are procured, and then delivery is managed against a pre-determined timetable. In reality, priorities change rapidly and technological development is increasingly unpredictable and non-linear.

Most government IT therefore remains trapped in an outdated model, which attempts to lock project requirements up-front and then proceeds at a glacial pace. The result is repeated system-wide failure.

Ironically, in areas where it may make sense to lock down choices, such as the procurement of commodity items or the implementation of common standards, government struggles. The strong departmental lines of accountability5

The solution: platform and agile

mean that while many government IT professionals recognise these issues, no one has the mandate to tackle them.

A totally new approach is needed that emphasises adaptability and flexibility while retaining the benefits of scale and collaboration across government. It is necessary to tackle two important aspects simultaneously – delivering government-wide efficiencies of scale and interoperability while facilitating rapid response and innovation at the front line. We describe these twin tracks as ‘platform’ and ‘agile’. This report demonstrates that by implementing both of these elements, government could see cost and time savings while delivering a more effective and flexible service.

4 National Audit Office, Delivering Successful IT-enabled Business Change, November 2006 5 See Simon Parker, Akash Paun, Jonathan McClory and Kate Blatchford, Shaping Up: A Whitehall for the Future, Institute for Government, January 2010

Executive summary 11

What do we mean by ‘platform’ and ‘agile’?

• We use ‘platform’ to refer to a shared, government-wide approach to simplifying elements of IT. The aim of the platform is to bear down on costs, reduce duplication and establish shared standards. The focus here is on commodity procurement, coordinating delivery of common IT facilities and services, and setting common and open standards to support interoperability.

• In the IT profession, ‘agile’ refers to a specific software development methodology. However, the principles can be applied to all IT projects. At its most basic level, agile techniques are about becoming much more flexible, responsive to change and innovative. Development is modular and iterative, based on user involvement and feedback. Early delivery of core working functionality is the priority.

There are tensions between a platform and an agile approach: treating items as commodities reduces cost but can limit flexibility; coordinating elements of IT across departments frees up resources but may move them further from frontline users; common standards support interoperability but also restrict the freedoms to innovate.

These potential drawbacks need to be carefully managed. Yet the relationship between platform and agile is not zero sum, where more of one means less of the other. The platform must address the basics effectively in order to free up specialist time and resources to take advantage of new opportunities. Equally, as agile approaches are used to explore new opportunities, innovations are scaled up and better technologies and approaches are fed into the platform more rapidly.

Areas of IT facing technological change or new ways of working are much more likely to deliver benefits when adopting an agile approach allowing innovation and experimentation to flourish. In contrast, with stable and mature technologies, or those areas where being at the leading edge offers little to government’s ability to deliver services, a platform approach may be the better option.

Establishing the platform

The platform will focus on the basic IT items across government that encourage interoperability and increase value for money by sharing infrastructure and reducing duplication. There is no final, stable solution for what is inside or outside the platform as it needs to evolve with technology. However, there is currently a great deal of government IT run separately by departments, which should be included in the platform. We suggest the following changes should be made:

• Commoditisation. IT should be purchased as commodity items across government and should include well established parts of IT infrastructure (e.g., non-specialist PCs, printers, low tier storage and standard servers) and basic versions of software (e.g., common desktop applications, human resources and finance packages).

12 Executive summary

• Coordination. IT to be managed once across government should include common support functions (e.g., first line helpdesks for basic systems and training for shared systems), shared IT infrastructure (e.g., data centres) and more specialist applications used across different departments.

• Common standards. This is a complex area, but government should start by considering which standards are currently being used most widely across the public sector. Supplementing this, government can look to existing industry standards or those published by internationally recognised bodies.6

A platform approach does not imply a large recentralisation of government IT. Rather, the platform approach recommends that delivery roles are distributed across the system to reflect the capacity and capability inherent in departments and sub-organisations. Lead departments should take responsibility for specific areas of the platform based on existing expertise or ease of set up.

However, where suitable open standards exist (such as those produced by the World Wide Web Consortium) government should promote their use.

Effective governance and accountability structures are vital for this approach to work. Because of its complex structure, government faces particular challenges around authority and accountability. Crucially, the centre must be able to establish which elements of government IT are part of the platform and manage compliance. The Government CIO should impose a strong ‘comply or explain’ model, with a clear escalation process up to the Public Expenditure Cabinet Committee where necessary.

Agile projects The cases and evidence reviewed for this report demonstrate that projects run using agile methods can deliver better outcomes at lower cost more quickly. Agile focuses on delivering useable functionality quickly, rather than a ‘perfect solution’ late.

The switch from traditional techniques to a more agile approach is not a case of abandoning structure for chaos. Agile projects accept change and focus on the early delivery of a working solution.

In general, agile projects follow four main principles: modularity; an iterative approach; responsiveness to change; and putting users at the core:

6 e.g., it may be appropriate to adopt the standards published by major internationally recognised standards bodies such as the Internet Engineering Task Force, the International Organization for Standardization, International Electrotechnical Commission, and the Telecommunication Standardization Sector ITU-T. The Telecommunication Standardization Sector (ITU-T) coordinates standards for telecommunications on behalf of the International Telecommunication Union (ITU).

Executive summary 13

• Modularity. Modularity involves splitting up complex problems and projects into smaller components and portions of functionality which can be prioritised. Each module should be capable of working both in a standalone fashion and in concert with other modules. This can reduce the time to delivery, enabling users to access the functionality of modules developed early, without necessarily having to wait until all of the original specification has been built. It can also make upgrades and changes easier as systems can be altered module by module or new modules can be added to the original design.

• An iterative approach. An iterative and incremental approach acknowledges that the best solution and means of delivering it are not always known at the start. By trialling in short iterations, receiving feedback and learning from mistakes a much more successful system can evolve than if everything is planned and set in stone at the outset.

• Responsiveness to change. Shorter iterations and regular reviews provide opportunities for changes to be made and priorities adjusted within an agile project. The solution is developed in line with a prioritised requirements list, with users and technical experts agreeing what they will focus on in the current iteration. Should the business needs change, or new technological solutions become apparent, the prioritisation of requirements on the list can be easily amended.

• Putting users at the core. Agile projects ensure that users or business champions are embedded within the project team. This enables the business to provide continuous input and refinement, ensuring that what is delivered meets their needs. It also demands that business users become closer to IT development than has sometimes been the case.

Like any management innovation, there are plenty of challenges in adopting an agile approach. We have identified three in particular: changing organisational cultures to support agile techniques; governance issues, including approval processes and Gateway reviews; and commercial complications, particularly in relation to procurement.

Implementing agile will require support from senior level leaders as well as the IT communities in each department to be successful. It will also require training, tools and a clear demonstration that it works.

14 Executive summary

Recommendations To begin to achieve this, government needs to do the following.

Think in terms of platform and agile The platform must standardise and simplify core elements of government IT. For any elements of IT outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform.

Recommendation 1: The Government CIO should govern which elements of government IT fall within the platform and which should remain outside for agile development. To do this effectively, the Government CIO must operate independently of departmental interests.

Use the platform to drive efficiencies but keep delivery decentralised The platform must manage the well-established elements of government IT by: bearing down on the cost of commodity items; reducing duplication of services and infrastructure; and setting common standards to support interoperability across the system. The centre will need to manage certain aspects of the platform (strategy, policy, common standards and benchmarking in particular) but delivery should reflect and build on the capacity and capability distributed across the system.

Recommendation 2: The platform should focus relentlessly on three areas: commoditisation, rationalising the management of common elements of government IT and setting common standards.

Recommendation 3: Delivery of elements in the platform should be undertaken by lead departments, on behalf of the government as a whole.

Recommendation 4: Clear governance and escalation structures are required to resolve disputes between lead departments and other departments. The Government CIO should be the first point of arbitration and the Public Expenditure Committee should provide the ultimate point of authority.

Support and foster agile principles By adopting an agile approach to IT projects, government can radically improve outcomes on IT projects. Projects can be delivered more cheaply and rapidly while also delivering better solutions.

Recommendation 5: During 2011/12 all government departments should run several upcoming projects using agile development principles. The exact number should be guided by the size of the department and collectively be weighty enough to act as a real catalyst for change within the department.

Executive summary 15

Recommendation 6: Future IT and project management training for government employees should include a significant component of agile methods training. Departments should also help develop agile ‘centres of excellence’ to provide support, resources, training and coaching.

Recommendation 7: All departments should review governance, project approval processes and legal arrangements to ensure that they can be made to work with agile projects. As part of this the Cabinet Office should investigate and implement an assurance process to replace the Gateway Review for agile projects.

Recommendation 8: Government departments should ensure that all future supply contracts can be made to work with a more flexible and iterative approach to development. This should include licensing and supplier change requests. This review should be led by the centre in order to avoid duplication at the departmental level.

Take steps now and expect to refine the approach over time The scale of government IT is enormous. Faced with such complexity, the lesson inherent in the principles of agile is not to try and develop a perfect roadmap for change up-front but to work up plans iteratively and to refine the approach over time based on user interaction and feedback. Our analysis suggests that even small steps towards developing the platform and using agile techniques will deliver real benefits. ‘Quick wins’ will help to build support for change early on while developing a longer term plan. No system is perfect and no system is immune to change. Having a more flexible and agile system is the best way to keep adapting to the shock of the new.

16 Introduction

1. Introduction

“640KB ought to be enough for anybody” – attr. Bill Gates

The accelerating IT revolution Whether or not these were Bill Gates’ actual words in 1981,7

Computing is currently undergoing a fourth wave of change.

the quote neatly captures the near impossibility of predicting the future when it comes to information technology.

8

The fourth wave (2008–present) has been characterised as ‘IT everywhere’. This is the move from IT being viewed as ‘grey boxes’ to an invisible and ubiquitous service. It aims to connect everything in an increasingly personalised manner, spurred on by the proliferation of embedded technologies, mobile computing and an explosion of content.

The first wave (1956–1976) saw the introduction of centralised mainframe computers, the second (1976–1992) saw the rise of personal computers, which evolved into a third wave of networked computing (1992–2008).

Social networking characterises the nature of change in IT today. Ten years ago, social networking was virtually unknown. In 2010, 43% of UK internet users posted messages to social networking and blog or chat sites.9 In less than seven years, Mark Zuckerberg, the founder of Facebook, has wired together a twelfth of humanity into a single network, creating a social entity with a ‘population’ almost twice as large as the United States.10

Businesses and other organisations have been quick to exploit this new medium. Many now have a social media profile and are developing mobile applications to enable them to engage with the public in a more personal and direct fashion.

Social networking is just one example that demonstrates how IT continues to shape the world around us in profound and unpredictable ways. As a result, the potential for IT to help government become more efficient, effective and user-friendly is vast, not simply by increasing efficiency but by fundamentally changing the relationship between citizen and state.

7 Bill Gates denies having ever said this; see Eric Lai, ‘The “640k” Quote Won't Go Away – but Did Gates Really Say It?’, Computerworld, 23 June 2008 8 HP, Enterprise Services IT Trends: The Fourth Wave is Here, March 2010 9 Office for National Statistics, ‘Internet Access’, ONS Opinions Survey, August 2010 10 Lev Grossman, ‘Person of the Year 2010’, Time, December 2010

Introduction 17

Around the world governments are using technology to help them deliver better services, be more transparent and accountable, and connect more directly with their citizens.

In 2005, Canada launched ‘Service Canada’, a multi-channel programme to help the public access a wide range of government services. The website groups services and information around life events like finding a job, retiring or having a family, rather than on departmental lines. Citizens are also able to use their Service Canada accounts to access information and update personal details for their Employment Insurance, Canada Pension Plan or Old Age Security. Survey results indicate that this format works well, with 84% of respondents expressing satisfaction with the service.11

The US government has taken steps towards radical transparency of its IT programmes. The Federal IT dashboard

12

In Malaysia, the government has used technology to help leverage benefits of scale and streamline processes in its single portal for government procurement.

allows the public to see the spend and progress status of every Federal IT project. Citizens can view the summaries and interactive data views, or drill right down into the detail of each project. Furthermore, each project is linked to a named CIO and their full contact details, enabling citizens to call those responsible to account directly.

13 As a result, the price the government pays for goods and services has been reduced by up to 30%, while procurement timelines have been cut from an average of 6 months to as little as 20 days.14

The UK has also started to innovate with sites such as

data.gov.uk, DirectGov and the Government Gateway. However, despite these examples, there is a sense that government always appears to be one step behind when it comes to making the most of new technology. In this report we will argue that this is far from inevitable and by following some well established principles there is no reason why government cannot join the IT revolution rather than watching from the sidelines.

Getting the basics wrong So why does government seem to lag behind when it comes to IT? Rather than being at the cutting edge, most of government IT appears to be locked in a vicious circle of inflating costs and increasingly outdated services.

Government now spends an estimated £16bn15

11 Service Canada,

on IT, yet the recent Operational Efficiency Programme states: “Overall savings of around 20 per cent of the estimated £16 billion annual

Service Canada Client Satisfaction Survey: 2008 Survey, Government of Canada, March 2008 12 US Government, IT Dashboard, Accessed January 2011 13 ePerolan is the mandatory portal for all government procurement in Malaysia 14 Malaysian Government, ‘ePerolehan Saving Govt Millions of Ringgit’, May 2010 15 HM Treasury, Operational Efficiency Programme Final Report, April 2009

18 Introduction

expenditure (£3.2 billion) should be achievable without compromising the quality of frontline public service delivery.”16

Government IT also moves very slowly, characterised by programmes like the National Programme for IT (NPfIT), the Single Payment Scheme for the Rural Payments Agency, the National Offender Management Service’s C-NOMIS project and ID cards. These all had delivery timelines of multiple years and in some cases ended up being scrapped or radically stripped back. Slow bureaucratic processes also impede the rate of progress.

Time for a fresh approach These problems are not new, yet attempts to fix the existing system have not been transformational. It is time for a new approach to government IT, which can turn the vicious circle of costs and failures into a virtuous one. Driving efficiencies and supporting innovation should become mutually reinforcing themes rather than contradictory ones. The scale of government should be used to its advantage, with the varied expertise and innovations occurring across the wider public sector harnessed more widely throughout the system.

This report sets out how to do this based on the twin concepts of a common platform (a system-wide approach to standardise, simplify and commoditise) and implementing agile principles (using resources in a more evolutionary and responsive way to seek the best solutions). While the report and its recommendations are focused on central government departments and arms length bodies, the principles and the approach can be applied throughout the public sector and will require the support of suppliers to help shape the future of government IT. The concepts of platform and agile, their interactions and benefits are set out in more detail in Chapter 3. Chapter 4 examines how a common government platform could be implemented, while Chapter 5 goes into more detail about how agile techniques and principles can be applied successfully within a government setting. Chapter 6 concludes with the report’s main findings and recommendations.

First, we explore in more detail the recurring issues with government IT and set out the case for change.

16 HM Treasury, Operational Efficiency Programme Final Report, April 2009

The case for change 19

2. The case for change

“The history of such [IT] procurements has not been good, with repeated incidences of overspends, delays, performance shortfalls and abandonment at major cost” – Improving IT procurement, NAO report17

Damning newspaper headlines and critical government reports all point to a pattern of repeated problems in government IT. It would be wrong to ignore some of the considerable successes, such as the introduction of congestion charging and Oyster cards within London, or the Department for Work and Pension’s (DWP’s) Payment Modernisation Programme for benefits,

18

While many commentators like to focus on the failure rates of government IT projects

but these must be set against the many high profile failures and delays.

19

So what exactly goes wrong with government IT?

this can be misleading. ‘Failure’ can be very useful if it is the result of experimentation and innovation that helps systems to learn and improve. As the examples below indicate, the real problem is that too many government IT failures occur on a massive scale and are only recognised as failures late into the process. There is no doubt that government IT is currently failing, and not in a good way.

Below we have listed some of the key symptoms of failure. This is not an exhaustive list, nor do the same issues occur in every government IT project. Instead it is intended to highlight the scale and breadth of the challenge and the room for potential improvement.

Government IT professionals will be familiar with these examples and the issues they highlight20

17 National Audit Office,

and we recognise that many have worked hard to respond to the lessons arising from these and other case studies. Yet the failures do not end. This chapter will argue that this is because the government ‘best practice’ advice, when it comes to managing IT projects, actually reinforces this circle of project failure.

Improving IT Procurement: The Impact of the Office of Government Commerce’s Initiatives on Departments and Suppliers in the Delivery of Major IT-enabled Projects, November 2004 18 National Audit Office, Delivering Successful IT-enabled Business Change, November 2006 19 For example, the 2009 Chaos report indicates that only 32% of projects succeeded. However, there have been critiques of this figure (e.g., www.cs.vu.nl/~x/chaos/chaos.pdf). 20 For instance, see Edward Leigh, An Open Letter to my Successor as Chair of the Committee of Public Accounts, Committee of Public Accounts, 29 March 2010

20 The case for change

Symptoms of failure Project delays Government IT projects have become notorious for running far behind schedule and failing to deliver the expected benefits. The C-NOMIS system developed for the National Offender Management Service (NOMS) is a clear example.21

Many people we spoke to during the development of this report pointed to the fact that Official Journal of the European Union (OJEU) procurements take an average of 77 weeks,

In 2004 the new NOMS organisation aimed to create an end-to-end offender management system. The expected delivery date of the new system was January 2008, but by July 2007, with £155m already spent, the system was two years behind schedule and the estimated lifetime costs had nearly trebled to £690m. The Minister of State imposed a moratorium while options were considered. Work restarted on a scaled-back version of the system in 2008 and is still ongoing.

22

Commercial and supplier problems

so most large projects are ‘late’ before they have even started.

For many large IT projects, the government has struggled to keep suppliers on board or hold them to their original delivery commitments. The National Programme for IT (NPfIT) has experienced both of these issues in its attempts to deliver new IT systems for the NHS. In April 2007 Fujitsu, which was the primary contractor for the South region, pulled out of the programme leaving officials at Connecting for Health struggling to replace them. The programme was also forced to re-baseline the contracts for the North, Midlands and East Strategic Health Authorities region23 after the original release plans for major systems like Lorenzo24 proved undeliverable. In January 2010 it was reported that NPfIT had run up a bill of £39.2m for ‘legal and commercial support’ alone.25

Not locking down costs on the basics

Sir Philip Green’s report26

21 National Audit Office,

highlights that government often pays different amounts for the same IT goods and services across its departments and agencies. For example, laptop prices ranged from £353 to £2,000 indicating either a lack of commoditisation or a failure within departments and agencies to extend the best negotiated rates to other public sector

The National Offender Management Information System, March 2009, and Public Accounts Committee, The National Offender Management Information System, June 2009 22 Angeline Albert, ‘Collington to Slash £13 Billion Common Spend by 25 per cent’, Supply Management, 25 November 2010 23 The rebaselining process resulted in the 'Penfield' Agreement signed in 2009 24 See http://lorenzo.isoftplc.com/ 25 Michael Savage, ‘Labour's Computer Blunders Cost £26bn’, Independent, 19 January 2010 26 Sir Philip Green, Efficiency Review by Sir Philip Green, 2010

The case for change 21

colleagues. A recent National Audit Office (NAO) report27 also highlights the variations in the cost of IT items that occur within existing collaborative agreements and within single framework agreements. By using multiple suppliers and intermediaries for single commodity items,28

Incompatible systems

government is not fully leveraging the potential economies of scale.

A commonly cited barrier to ‘joined-up’ government is that the IT systems across government are incapable of communicating with each other. An NAO report on reducing administrative errors at DWP notes that this can also occur within a single department: “Different computer systems were used to process benefits but they did not communicate well with each other.”29 The report noted that within DWP there were approximately 140 core processing systems, and that “many of the computer systems are relatively old and standalone, such that they are difficult to update and information is not readily accessible between the different systems”.30

Departments often collect basic data in different ways on different systems. These system incompatibilities, usually arising from a proliferation of legacy systems, can lead to duplication of work and an increase in errors due to the problems with transferring information from one system to another. Even where technical issues can be overcome, divergent business processes often act as a barrier to compatibility and interoperability. The NAO review of the Department for Transport (DfT) shared services programme finds that “[i]n practice, the Department delivered a design blueprint but could not agree a common set of underpinning business processes”.

31

High cost of change

A proliferation of systems can also contribute to the exceptionally high cost of making even basic changes as the changes have to be replicated and synchronised across multiple systems. Furthermore, many systems have not been designed with future changes in mind and it can be technically difficult to update them. In DWP even simple changes to the system can be problematic. The NAO points out: “Benefit processing systems are not designed in a way that allows simple changes to the screen display. To add a screen field would require significant work to ensure the processing code understands the messages being keyed in.”32

27 National Audit Office and Audit Commission,

A Review of Collaborative Procurement Across the Public Sector, May 2010 28 Within central government, the 460,000 desktops and 60,000 laptops were being purchased from 13 different suppliers, in some cases via an intermediary rather than direct from the manufacturer. 29 National Audit Office, Minimising the Cost of Administrative Errors in the Benefit System, November 2010 30 National Audit Office, Minimising the Cost of Administrative Errors in the Benefit System, November 2010 31 National Audit Office, Shared Services in the Department for Transport and its Agencies, May 2008 32 National Audit Office, Minimising the Cost of Administrative Errors in the Benefit System, November 2010

22 The case for change

Additionally, a large proportion of IT expenditure is devoted to maintaining and updating legacy systems. Developing interoperability between legacy systems and new services and applications is a complex and costly undertaking.

These issues are exacerbated by the high costs of change control procedures that are written into many fixed price contracts.

Over-customisation and little reuse The public sector often builds bespoke solutions or selects systems with features far beyond what is absolutely necessary for the work being performed. For example, the Virtual Court System developed by the Ministry of Justice included a bespoke ‘scheduling tool’ for booking courts despite the fact it was little more than a room booking system containing publicly available information. This pilot is now set to be rolled out for a further trial year despite an evaluation showing that this ‘cost-cutting measure’ actually increased the costs involved.33

The Single Payments Scheme for the Rural Payments Agency was another expensive and overcomplicated solution. This £350m system had over 100 consultants working on it, yet the system only needed to make payments to a relatively small number of farmers (116,000). NAO Director Philip Gibby noted that it was a small enough scheme that payments could have just been recorded on a spreadsheet.

34

These bespoke systems typically cost much more than a standard ‘off-the-shelf’ commercial option and the levels of customisation and bespoke design makes it much harder for them to be reused by others or to be fully interoperable with other systems.

Not designed with the user in mind As well as overcomplicated and bespoke solutions, there are many examples of government IT solutions which are difficult for the end customers to use. The Prism system in the Foreign and Commonwealth Office (FCO) was intended to replace and integrate 30 existing separate finance, payroll, personnel and procurement systems in more than 200 FCO posts worldwide, but reportedly left many staff “at their wits’ end”.35 Staff complained that “in the FCO’s long history of ineptly implemented IT initiatives, Prism is the most badly-designed, ill-considered one of the lot”.36

33 Ministry of Justice,

As with many of these issues, the problems are not exclusively

Virtual Courts Pilot: Outcome Evaluation Report, December 2010. Economic modelling suggests that a roll-out of virtual courts across London based on the structure and performance of the pilot would cost more than it would save over a ten-year period. 34 Tony Collins, ‘The NAO’s Most Serious Criticism of any IT-based Project?’, Computer Weekly, 15 October 2009 35 Committee of Public Accounts, Foreign and Commonwealth Office Annual Report 2004–05, House of Commons, 15 February 2006 36 Letter in FCO News and Views, Issue 60, November 2005

The case for change 23

confined to IT. For example many people, especially those most vulnerable, find interactions with government to be confusing and unintuitive.37

Obsolete requirements

IT systems can act to compound these issues. Rather than being designed from a user perspective, they are often considered from a system or hierarchical perspective with the users having little direct input into the design process.

In addition to these basic symptoms of failure, government risks falling further and further behind in unlocking the potential offered by new technologies. Because the rapid pace of change in technology is constantly creating new ways of doing things, government needs to be much more responsive and quick to adapt. Whereas in previous decades, most IT requirements might remain valid for years, the pace of progress has accelerated to the extent that the half-life38 for a set of requirements may only be a matter of months.39

Government’s failure to keep up with this rate of change carries significant risks. The 2009 Gray report on Ministry of Defence procurement notes “we confront new threats which will not wait for our current development timescales to evolve answers, such as the emerging threat of cyber-attack. Those who would attack us in new or unconventional ways are unlikely to wait for our sclerotic acquisition systems to catch up in order to adequately address their threats.”

40

The recent PAC report on HM Revenue & Customs (HMRC) in Box 1 illustrates what can happen when changes are identified early on and there is no capacity to adapt to this change.

37 For example, Dealing with the Tax Obligations of Older People, HC 141, Session 2009-2010, outlines how older people struggle to understand their tax obligations. 38 By half-life we mean the time required for half of a set of specifications to become redundant. 39 Recent research has suggested that while the requirements of a project in the 1980s typically had a half-life of a decade or so, by 2000 this had fallen to two to three years. It is estimated that today; specifications have a half-life of about six months (cited in Susan Atkinson and Gabrielle Benefield, ‘The Curse of the Change Control Mechanism’, The Society for Computers & Law, February 2011). 40 Bernard Gray, Review of Acquisition for the Secretary of State for Defence: An Independent Report, October 2009

24 The case for change

Box 1: The development of the National Insurance and PAYE Service system

Source: House of Commons Committee of Public Accounts, HM Revenue and Customs’ 2009–10 Accounts. Eighteenth Report of Session 2010, 12 October 2010

Many analyses, but the problems persist There is widespread awareness that government IT (like the IT in many private sector businesses) could be much better but somehow all the old problems seem stubbornly resistant to change. There is no shortage of official and unofficial reports demonstrating where individual projects have gone wrong. Similar analyses and explanations for the failures continue to be published.

The list of commonly attributed root causes is extensive, summarised as follows by the OGC/NAO publication ‘Common Causes of Project Failure’:41

41 Office of Government Commerce, Common Causes of Project Failure, OGC Best Practice, 2005

The National Insurance and PAYE Service (NPS) consolidates all of an individual’s pay and tax details into a single record to reduce over and underpayments of tax. The implementation of the NPS was deferred twice and then encountered delivery problems with software and data quality. HMRC does not know the full costs of the implementation of the NPS or the exact amounts of tax involved. However, estimates suggest £1.4bn of tax was underpaid and there is £3bn of overpaid tax to be refunded.

The department attributes most of the problems to the quality of the data, the complexity of delivering the system with significantly higher levels of automation and insufficient involvement of end users at each stage of its development. In many ways, the system appears built to fail when specifications are drawn up in advance, solutions are procured, and then delivery is managed against a predetermined timetable.

As the Permanent Secretary points out: “The vast majority of the system works. It does what it was asked to do... but also, you specify you want something back here in 2003, you have nearly 400 changes in that time and then you have delivery in 2009. So, sometimes you get what you ask for, but it is not necessarily exactly as you need it. There are very few programmes that I have known that cover a length of period and a scale like this where you get exactly what you set out to get first time.”

The case for change 25

“1. Lack of clear links between the project and the organisation's key strategic priorities, including agreed measures of success.

2. Lack of clear senior management and Ministerial ownership and leadership.

3. Lack of effective engagement with stakeholders.

4. Lack of skills and proven approach to project management and risk management.

5. Too little attention to breaking development and implementation into manageable steps.

6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).

7. Lack of understanding of, and contact with the supply industry at senior levels in the organisation.

8. Lack of effective project team integration between clients, the supplier team and the supply chain.”

These causes are valid, but the repetition of the same criticisms time after time tells its own story. The official responses to these issues focus on implementing existing ‘best practice’ processes more effectively rather than considering whether the proposed solutions may need to change.

Existing ‘best practice’ solutions do not deal with the fundamental issues at the heart of government IT. By implementing the same flawed project techniques in an increasingly rigid fashion, these traditional solutions can act to exacerbate the problems further.

System level flaws As noted in Installing New Drivers,42

In the 1970s the Central Computer Agency exercised strong central controls, with direct ownership of approximately 80% of computers in government. However, problems with this approach led to greater decentralisation in the 1980s with the Central Computer and Telecommunications Agency losing its controls and departments establishing their authority to select their own systems. From 1995 to 2004 there was a recentralisation with the

the pendulum has swung several times between tight central controls for IT and greater departmental autonomy.

42 Michael Hallsworth, Gareth Nellis and Mike Brass, Installing New Drivers: How to Improve Government’s Use of IT, Institute for Government, December 2009

26 The case for change

Central Information Technology Unit in Cabinet Office followed by the creation of the Office of the e-Envoy reporting directly to the Prime Minister. However, this too was soon scaled down and rebranded as the e-Government Unit. The current era in government IT has been characterised by collegiality and the establishment of the consensually run CIO Council.

These shifts have generally been reactive, based on recognition that the system (whether under tight or loose control) is not working well in some fundamental areas including leveraging economies of scale, working with suppliers and encouraging interoperability. For example, the Operational Efficiency Programme (OEP) points out that only about 7%, or £12bn of all public sector procurement is carried out by the 45 professional buying organisations, such as OGC Buying Solutions, and “[h]aving invested in these delivery mechanisms, government must now maximise the value they deliver”.43 It concludes that for the nine categories of common spend,44

In a recent report, the NAO warns that the value for money of 43 major government projects worth around £200bn is at risk because of significant weaknesses in the government’s commercial skills and expertise.

80 per cent of Government Departments and Agencies’ expenditure that is not locked into existing contracts should be channelled through collaborative strategies. Participation in this scheme should be mandatory.

45 Currently, strong departmentalism is a major factor in preventing a more joined-up and efficient approach to many elements of government IT. Yet the answer is not simply to revert back to centralisation. The key is to stop lurching reactively between extremes and simply continuing the power struggle between departments and the centre (an issue which goes well beyond IT).46

Flaws in traditional project methods

It is easy to understand why traditional methodologies have been followed in the past. The V-model or Waterfall approaches (Figure 1) appear to be the logical response to the core challenges facing any project: the desire to come up with the best solution and deliver it in the most effective way.

Under these traditional approaches, the best solutions are considered to be those that capture all the requirements up-front and design a solution to incorporate as many of them as possible. The greater the depth of the requirements, the more the solution will fit the business need.

43 HM Treasury, Operational Efficiency Programme Collaborative Procurement 2009, p. 4 44 These commodities are bought by more than one organisation across the public sector. They include ICT, energy, fleet, office solutions, travel, professional services, facilities management, food and construction. 45 National Audit Office, Commercial Skills for Complex Government Projects, 2009 46 See Simon Parker, Akash Paun, Jonathan McClory and Kate Blatchford, Shaping Up: A Whitehall for the Future, Institute for Government, January 2010

The case for change 27

From these detailed requirements, the shape of the whole solution can then be developed. By planning and designing in as much detail as possible at the outset, showing exactly how everything fits together, the number of errors discovered in the later test phases are reduced.

In a perfectly predictable world these approaches would work very well. In the real world, in which requirements, technologies and ministerial priorities are constantly evolving, they quite literally build failure in to the system.

Figure 1: The V-model

The V-model and Waterfall methodologies were developed in the 1970s and 1980s respectively to provide a more structured approach to project planning and system development.

Both follow a linear process, where one section must be completed before the next stage of the process can begin.

In the V-Model the first step is to gather all the requirements. These are then turned into a set of technical specifications which guide the high level and detailed design stages. Only once the design has been fully signed off does development work begin. Once a solution has been developed, it goes through various stages of testing from checking individual bits of code through to a full integration test with other systems. Only after all these stages of testing have been completed are the users once again brought back into the process to test the solution.

Source: Ed Liversidge, ‘The Death of the V Model’ Harmonic Software Systems Ltd, December 2005

28 The case for change

Changing requirements The traditional practice of planning everything up-front is highly effective as long as the plan will not need to change mid-way through. In the vast majority of cases, the complex nature of the problems that government is tasked with means that this criterion is impossible to meet.

This is not a problem unique to government, but a simple reflection of the complex and changing nature of the environment for many IT projects. Changes of leadership, new priorities and initiatives, as well as new technological options, often lead to changes being required mid-way through a project.

Government is frequently tasked with tackling ‘wicked issues’, such as reducing child poverty or combating antisocial behaviour, where no one can be certain what the best solution is. For these kinds of complex problems, the best way to determine what works can often be to experiment, learn and improve as you go in an evolutionary approach. However, government IT has rarely supported this iterative and exploratory style of developing solutions. When uncertainty is high, ‘locking down’ solutions is exactly the wrong approach and virtually guarantees that a sub-optimal solution will be developed.

‘Gold plating’ In an effort to avoid the cost of change control processes, business users are encouraged to try and define all their requirements in as much detail as possible during the initial specification stage. This inevitably results in unnecessary ‘gold-plating’ of requirements as the initial specifications are seen as the only opportunity to request functionality.

Increasing outsourcing may also have reinforced this tendency: a preference for fixed price work, with the full set of requirements agreed at the start and steep penalties for alterations, creates contractual and financial barriers to making changes. This single window for requirements leads business users to request any and all functionality that they think they might want rather than focus on their core needs.

Suppliers rarely have an incentive to question the validity of requirements. Additional complexity enables them to command bigger fees; the greater the specialisation of a system, the more likely suppliers’ knowledge of the system will be called on to maintain or update the system.

Massive projects The resulting excess of requirements, combined with the desire to fully use all the potential of technological solutions on offer, has led the public sector to design larger, more complicated solutions than might be necessary.

While this is partly a desire to provide universal access and common standards for public services, the UK government carries out a lot of projects that other, less centralised administrations would devolve to a state or regional level. This results in solutions being

The case for change 29

developed and deployed at a national scale. The size of the projects in turn limits the pool of suppliers to those who government believes are capable of delivering in this way.

A less than intelligent customer Users are typically only involved in the V-Model development process right at the start when they specify requirements and at the end when they test the complete product. Business analysts or consultants often have a role in translating the business requirements into a technical specification for the IT department or supplier, adding another dividing layer between ‘the business’ and IT. When the IT provision is outsourced, this divide is widened further. As a result, many business users have little conception of how easy or difficult their stated requirements might be to deliver or the process that development might have to go through to make a change.

By outsourcing a large part of government IT, the public sector has also lost much of the knowledge and skills required for it to act as an intelligent customer. It has become unable to judge objectively whether it is getting a good deal from suppliers, especially as the siloed nature of government make it difficult to obtain comparative figures for reference. Working with suppliers who lack insider knowledge of the department also means that the requirements have had to be specified in a greater level of detail to try and prevent requirements being ‘lost in translation’.

The 2010 IT strategy for government points out that while “approximately 65% of central government ICT is outsourced to the private sector... government has not always managed these relationships effectively”.47

Rigid implementation of methodology

In some respects, the public sector is a victim of its own success in adopting these traditional methodologies. While Waterfall and the V-Model are also used extensively outside government, the private sector is often more inclined to take shortcuts or apply the process more flexibly if they can perceive an advantage from doing so.

The public sector tends to be much more rigorous in applying the prescribed process – a situation which has been exacerbated by analyses of government IT failures, which call for closer adherence to procedures.

Conclusion Rather than trying to patch a broken system, we recommend a radically new approach to government IT, a system that can both deliver the efficiencies of scale needed to meet the current financial challenges while freeing up departmental and front-line public sector staff to apply their expertise to the most pressing business problems.

47 HM Government, 2010 Government ICT Strategy, January 2010, p. 15

30 The solution: platform and agile

3. The solution: platform and agile

“The reverse side also has a reverse side.” – Japanese proverb

Taken together, previous recommendations on government IT can paint a contradictory picture. Government should drive efficiencies of scale, yet be more local. Government needs much greater in-house IT expertise, but should take advantage of outsourcing. Government should promote standardisation but encourage innovation. Government must manage risks but also support experimentation.

Yet government IT need not be trapped in simple ‘either/or’ dichotomies. Government needs to get the basics right and grasp new opportunities.

Platform and agile – what and why? The terms ‘platform’ and ‘agile’ have both been used to describe a range of different concepts so it is important to be clear about what we mean.

Platform By ‘platform’ we mean a system-wide approach to standardising and simplifying shared elements of government IT. The aim here is to get the basics right by bearing down on costs, reducing duplication and providing some standards and rules to support interoperability.

The core activities of a platform approach should be:

• Commoditisation. As Sir Philip Green’s report48

• Coordination. In government there are many common IT functions and support services which are replicated for each department and agency. It makes sense for these elements to be coordinated and managed in a more efficient way, reducing duplication across departments and focusing expertise on the solution.

highlights, government can achieve large cost savings through bulk buying of commodity goods. This could be applied much more widely to parts of government IT like basic office hardware devices and software as well as network bandwidth or server space.

• Common standards. For elements of IT to be interoperable, they need to follow common standards. By making the standards open, anyone can participate with valid ideas and innovations. Building on this, if common standards are enforced it is possible to ensure that these innovations can be used by all without having to be individually reworked for each organisation.

48 Sir Philip Green, Efficiency Review by Sir Philip Green, 2010

The solution: platform and agile 31

For those wary of another swing of the pendulum back towards centralisation, ‘platform’ can sound a lot like ‘centralise’. However the proposed approach is not trapped in the simple logic of centralise or decentralise. Having a common platform does not imply having centralised delivery of every item within it, as the Centre does not currently have the skills and capabilities to perform this role. Past experience also warns against the costs, delays and risks of setting up new structures at the centre. Rather, we suggest that delivery would be shared across the system, with lead departments identified based on capacity and capability. This is discussed further in Chapter 4.

Agile Agile means adopting an approach to IT that emphasises flexibility, responsiveness to change and innovation. This is achieved through modular and iterative development based on user involvement and feedback.

Within the IT profession, agile refers to a specific software development methodology (discussed in further detail in Chapter 5). However, the principles of an agile approach can be applied much more widely to projects.

Compared with traditional tools and methods, agile offers a fundamentally different approach to tackling business problems, as summarised in Figure 2. Where the traditional approach favours complete solutions developed in a linear fashion, agile encourages a modular approach using short iterations to learn and adapt. Instead of trying to lock down requirements and minimise changes up-front, agile encourages continuous experimentation, improvement and reprioritisation. The approach to user involvement also differs fundamentally. The traditional approach favours heavy user engagement up-front to determine and lock down detailed specifications and at the end to test the final product. In contrast, agile embeds users in the process for the duration of the project, making them an integral part of the development team rather than a constituency to be consulted.

This will present a challenge to departments, which are likely to have a scarcity of experienced people from the user community. Yet, as our research in the private sector and elsewhere has found, this is an essential ingredient of success for agile. And the prize is great – flexibility, cost saving and a more streamlined approach to developing fit for purpose IT.

32 The solution: platform and agile

Figure 2: Comparing an agile approach with traditional IT project management

The balance between platform and agile Rather than being in tension, we believe that the concepts of platform and agile are mutually reinforcing. Getting the basics right across government allows departments to avoid reinventing the wheel and instead focus their attention on using IT to help solve the business challenges they face.

Nevertheless, we recognise that some trade-offs are inevitable. If items are commoditised, it might not be possible to alter them in a way to support the latest innovation. While agreed standards support interoperability, they also constrain freedoms to innovate in different directions. If services are managed and coordinated across different departments, this may make them more remote from frontline users’ expertise and experiences.

In simple terms, deciding whether a particular aspect of IT (e.g., the procurement of server capacity) should be part of the platform or left up to departments requires a judgement about where the greatest value lies. Consolidating servers across government will certainly increase utilisation and reduce cost but may limit departmental flexibility.

This report does not seek to set out a comprehensive blueprint detailing every aspect of what will be in the platform. These decisions should be made on a case-by-case basis by the Government CIO in conjunction with departmental CIOs. There are, however, two main factors that are often strong predictors of where the greatest value lies: predictability and specialisation:

• Predictability. Where requirements are tightly defined and unlikely to change, a platform approach is more suitable. In contrast, complex problems with rapidly

The solution: platform and agile 33

changing requirements or technologies are much more likely to deliver better outcomes more rapidly by adopting an agile approach.

• Specialisation. Products or services that can be used ubiquitously across government are likely to benefit from a platform approach. The results of our CIO survey indicate that there is a desire for more control and coordination than at present in this regard with ubiquitous items; 72% of departmental CIOs wanted greater control and mandation for ubiquitous elements of IT.49

Figure 3: Degrees of specialisation

Figure 3 sets out the levels of specialisation for government IT.

How the platform and agile can support each other A critical principle in effective IT is that today’s innovation becomes tomorrow’s commodity. In the commercial sector, promising innovations such as early word processor packages have been swept aside by mass market commodity products like Microsoft Word. It is this ruthlessness of survival, to become platform or to become obsolete, which allows agile and

49 For more details see Annex D, ‘Survey of public sector CIOs’.

Specialist. Where products or services must be specific to one organisation and cannot be easily commoditised or managed as part of a shared service. This could include areas such as car tax discs and vehicle licensing, or developing a user interface design for a particular audience.

Sector or industry. Where products or services are used by a cluster of related organisations with minimal customisation. The cluster adopts common standards for some key areas. For example, in the education sector there are various commercially available school administration systems, while for heath, numerous sector-specific systems have been developed both commercially and under state-led initiatives across the world.

Ubiquitous. In many areas, products or services can be used ubiquitously across organisations with minimal surface level customisation. The same open standards are used by all wherever practicable to maximise interoperability. This might include services such as low tier storage, commodity items like standard desktops or laptops, or common systems and applications like word processing software or payroll and timesheets programmes.

34 The solution: platform and agile

platform to support each other. Where an innovation has failed to achieve widespread adoption, yet remains a key component in the existing infrastructure, it absorbs valuable resources and acts as a barrier to change. The platform helps resolve this tension by getting basic IT items adopted across the system and freeing up time and resources for specialists to focus on new opportunities.

To act fully in the interests of government, an agile approach requires a light touch form of coordination at a system level. The development of an IT strategy by the Government CIO should act as a guiding beacon to ensure that agile project opportunities are explored in line with the broad direction and objectives of government as a whole.

To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives. It should be easy for groups tackling similar problems to identify each other and merge where appropriate. Where possible, the outcomes of agile experiments should be open for all to see and learn from, and there must be a clear mechanism for escalating the best and most widely applicable ideas so they either become part of the platform, or form a more specialised centre of excellence for their sector. The central Skunkworks unit could act as a catalyst for change by highlighting best practice and scaling successful innovations. This is discussed in more detail in chapter 5.

Existing elements of the platform also need periodic challenge. As technologies and polices move on, parts of the platform may need to be adjusted and updated. Consequently, user feedback on existing parts of the platform should be supported by lead departments and the Government CIO. Experts should also be encouraged to test out new approaches to platform items (such as virtualisation or migrating applications and data to a private or government cloud set up) on a very small scale with non-critical items. Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.

Like any new conceptual approach, the principles need to be translated into practice. Chapters 4 and 5 demonstrate in more detail how platform and agile can improve government IT and show how they can be practically applied.

The role of the centre and departments Clarity of roles and responsibilities will be vital if the approach described above is to be adopted successfully by government. Specific roles are described in more detail in chapters 4 and 5 and set out in Figure 4. In summary:

• The Government CIO is responsible for the overall IT strategy for government. This includes striking the right balance between platform and agile approaches and determining which departments should lead particular elements of the strategy. This role is further described in Chapter 4.

• The CIO Council includes each of the departmental CIOs and should co-own the government IT strategy with the Government CIO.

The solution: platform and agile 35

• Each department should include agile champions who are responsible for promoting the adoption of more agile approaches. These could be supported by agile centres of excellence which work across departments to support agile projects by providing mentoring, training, resources and tools. This is described further in Chapter 5.

• Lead departments take responsibility for driving particular aspects of the platform in which they have expertise.

Figure 4: Key roles in government IT

Conclusion Government needs to adopt a dual approach to IT that incorporates platform and agile. Platform is a system-wide approach to standardising and simplifying shared elements of government IT. Agile emphasises flexibility, responsiveness to change and innovation. We believe these two approaches can be mutually reinforcing. Making this happen will require clear roles and responsibilities between the different actors within government as well as robust governance mechanisms.

In the next two chapters we explore, in detail, what implementing a platform and agile approach means in practice.

Key

PS(X) – Public Expenditure Committee

ERG – Efficiency & Reform Group

PBOs – professional buying organisations

36 Building the platform

4. Building the platform

“Different public services seem to exist in parallel worlds... they tend to operate in silos.” 50

The issues arising from departmental silos are well documented, and government IT reflects many of these problems. If departments are able to work more closely together, government IT should cost less and deliver more. This cross-Whitehall collaboration will not happen by itself. A platform for government IT is required that clearly describes where the value of coordination is highest and how it will be managed in practice.

– David Cameron

This is not an argument for blind centralisation. Instead we are calling for a rethink of the roles and responsibilities of all the actors in the system and how they relate. The role of the Government CIO in particular will be crucial.

This chapter starts by describing how the platform elements of commoditisation, coordination and common standards can improve government IT. It then explores the roles and supporting governance structures that will need to be set up to maintain the platform.

Commoditisation Commoditisation means avoiding bespoke solutions unless they are clearly required. This can cover hardware such as laptops, software such as email systems, and services such as network bandwidth or managed server capacity.

The benefits of commoditisation The most obvious advantage of commoditisation is the potential for cost savings through bulk buying. According to the NAO, there is currently significant variation in the amount paid for common items. For example, the minimum and maximum price paid for liquid crystal display (LCD) monitors in central government departments varies by 169%.51

Moreover, the NAO points out that public bodies are incurring unnecessary administration costs by duplicating procurement activity. It estimates that around one in five of all notices advertised in the OJEU in 2008 (equating to more than 2,500 public sector tendering

50 David Cameron, The Conservative Approach to Improving Public Services, January 2007 51 National Audit Office, A Review of Collaborative Procurement Across the Public Sector, May 2010

Building the platform 37

exercises) were unnecessary and could have been covered by existing framework agreements52

However, cost savings are not the only advantage that commoditisation provides. An estate largely comprising commodity items is much easier to manage than one made up from a wide portfolio of bespoke systems. Commoditisation also makes it easier to govern the connections and interfaces between different parts of IT as there are fewer permutations to consider. Commoditisation can also increase the impact of innovation. If a new use for a commodity item is discovered or if a new plug-in module of functionality is developed, it can be immediately rolled out across the whole of government rather than having to be adapted for each bespoke system or variation.

.

Commoditisation: getting started As a priority, government should specify the relevant items of IT that should be purchased as commodity items across government. This should include:

• well-established parts of IT infrastructure (such as non-specialist PCs, network bandwidth, low tier storage and standard servers)

• basic versions of software (such as common desktop applications, and human resources and finance packages)53

• components or modules of functionality (such as business logic layers, workflows tools and ID assurance)

An audit of current purchasing contracts should be conducted as soon as possible, building on Sir Philip Green’s report and the NAO and Audit Commission’s joint review of collaborative procurement across the public sector.54

Purchasing options will also need to be established. Even when dealing with basic commodities, there will still need to be a small number of variations to accommodate simple differences in requirements (for example, non-specialist PCs with more or less memory and processing speed, or printers of different size, speed and finish quality).

From this, the Efficiency and Reform Group (ERG) should conduct an examination of differentials in cost with a view to finding the best commercial deals available.

52 Framework agreements cover the procurement of a particular type of good or service from pre-approved supplier(s) over a fixed period of time. The agreement usually sets some of the terms and conditions under which the supplier will enter into contracts with customers. 53 In our CIO Council survey we asked respondents to list the three items where there should be greater coordination or mandation across government. Seven out of 18 respondents identified commodity items. None recommended a more decentralised approach to this. 54 NAO and Audit Commission, A Review of Collaborative Procurement Across the Public Sector, May 2010

38 Building the platform

As set out in the Operational Efficiency Programme final report, collaborative procurement should take place through strengthened professional buying organisations (PBOs) and other collaborative arrangements that extend across the public sector.55

The review of commodities options should also strongly consider where it might be possible to use open source alternatives. This is in line with the Government’s current approach

Along with a single gateway for purchasing commodity items, it is important to have a single procurement team to negotiate on behalf of government as a whole. As Philip Green’s report indicates, drawing together the best skills and experience is critical. Deals should aim to beat even the best prices already in place as a result of the combined economy of scale.

56 and similar moves towards open source are being adopted by other governments.57 Many open source offerings do not charge licence fees. For example Microsoft Office’s most basic business package retails for over £200 per licence58 yet where government users do not require all of the more advanced functionality provided by this package, open source communities like OpenOffice56

could provide more basic word processing, spreadsheet, and presentation solutions with no license costs59

It should be noted that open source does not always mean ‘free’ and some open source products have commercially run accreditation and support arrangements

.

60

Coordination

which are designed to meet many traditional concerns relating to security and maintenance support. However, open source is also fundamentally more compatible with an agile approach as innovative changes and additions to the source code can be made directly without having to go through a proprietary solution’s owner or incur costly change requests.

Coordination refers to the benefits that can be gained from working together across government. This goes beyond commoditisation to include the provision of shared services

55 HM Treasury, Operational Efficiency Programme Final Report, April 2009 56 Deputy Government CIO Bill McCluggage noted “The government is now looking to work on an open source implementation group. We will be looking at how open source could feature in our new ICT strategy” See Kathleen Hall ‘Government tells major IT suppliers - we want more open source software’, Computer Weekly, February 2011 57 For example, the Australian government recently released new policy guidance which aims to strengthen the consideration of open source software See Australian Government Department of Finance and Deregulation Australian Government Information Management Office Circular December 2010. 58 Microsoft Office Home and Business 2010 retails for £239.99 (on 10 February 2011) on the Microsoft UK website. On the same date the Microsoft Professional package was on sale for £429. Microsoft has advised us that Government receives a ‘considerable discount’ on the retail price but did not provide precise figures. 59 Support costs as part of total cost of ownership would still have to be considered. 60 For example Red Hat commercially supports and helps develop Linux open source products.

Building the platform 39

and encouraging departments to work more closely together in the development and management of solutions.

The benefits of coordination The current, decentralised approach to government IT has meant that departments and agencies are developing IT solutions in isolation. However, there are many commonly shared elements of IT which can be solved and managed once across government. Stripping out duplication has the potential to deliver enormous benefits for government. It can reduce costs by leveraging economies of scale, focus expertise and investment, increase accountability for more effective delivery, and reduce issues with interoperability.

A recent review by the Danish government found that providing a shared service centre for finance, salary and travel and a separate centre for IT services would free up resources and reduce costs, while maintaining or improving service levels and increasing professionalisation. This would result in annual savings of approximately €78 million, with IT accounting for more than half of the savings.61

Coordination: getting started

Government should specify the relevant items of IT that should be managed once, or a small number of times, across government. This should include:

• common support functions (such as first line helpdesks for basic systems or the provision of training for shared systems)

• IT infrastructure (such as data centres)

• coordination of common business processes

• shared sector-level software (applications used by specialists but not unique to a specific organisation)62

A review of existing provision of these items should be conducted across government. Again, as part of ERG’s role in controlling IT spend, differentials in cost and performance should be clearly benchmarked. The Government CIO and CIO Council should then set a clear strategy for the shared management of services across government based on the capability and capacity in the system.

61 Andreas Wester Hansen, Shared Service Centres in the Danish Central Government, Ministry of Finance, Denmark 62 In our CIO Council survey we asked respondents to list the three items where there should be greater coordination or mandation across government. Seven out of 18 respondents identified data centres, five infrastructure and four shared services. None recommended a more decentralised approach to any of these areas. See Annex D for further details.

40 Building the platform

For example, the DWP already has a shared services offering, providing accounting, debt management, payment resolution, purchase to pay and employee services to the Cabinet Office, the Department for Education and the Child Maintenance Enforcement Commission. A potential next step would be to see whether these offerings could be extended across the rest of government. Similarly, because of its relative size and data storage and processing requirements, DWP appears to be in a strong position to develop and run data centres on behalf of departments more widely.

Common standards Common standards simply mean that everyone works to the same set of rules or principles. They can include security or quality standards and technical standards on how systems should be developed or particular aspects of their specification.

The benefits of common standards The interoperability benefits that common standards can bring are clear. When people in the same department use divergent standards it is very difficult for different systems to share information and increases the risk of errors where attempts are made to convert information based on one standard to another. So if, for instance, common standards were developed on how government handles ID assurance, all departments would be able to trust that assurance procedures carried out by one department would meet certain minimum criteria without them having to rerun their own assurance procedures.

The Joint Information Systems Committee (JISC)63 recently undertook a study to evaluate the benefits of adopting a common data model for sharing information about researchers, projects, outputs and funding decisions across the UK higher education sector. At present, this information is fragmented and often stored in incompatible formats, increasing the cost of submitting and monitoring grant applications. The study concludes that if higher education institutions could adopt a single standard interface based on a common data standard known as the Common European Research Information Format, it would obtain savings of between 25% and 30%.64

In another example, a recent study of four major UK supermarkets and four of the largest product suppliers analysed product data and data practices in the participating companies. The study showed that if product data was better synchronised throughout the supply

63 JISC is an organisation that assists UK colleges and universities in the innovative use of digital technologies, helping to maintain the UK’s position as a global leader in education. 64 Stuart Bolton, The Business Case for the Adoption of a UK Standard for Research Information Interchange, Stuart Bolton Solutions, July 2010

Building the platform 41

chains, it would significantly reduce the cost of workarounds and shrinkage, saving the grocery industry at least £1bn over five years.65

Common standards: getting started

Most business units, departments or organisations would welcome common standards – but only if their standards were going to be used.66

Government should make sure that the standards it adopts are open standards wherever practicable. Open standards are those that are freely available to the public and should not prescribe proprietary tools or supporting systems. In some cases, it may be appropriate to adopt the standards published by major internationally recognised standards.

While there are existing industry standards that can be adopted for many areas of IT, consideration should also be given to whether other standards have been more widely used in government and how easy it is for different departments to change their standards.

67 However, as these bodies charge royalties, they cannot be considered fully open standards. Where possible, industry-level open standards (like those produced by the World Wide Web Consortium68

As a first step, government should review what standards are currently being used across the public sector. This information should be made available as widely as possible to inform future development. Where possible and practical, for instance where there is already high usage of a suitable standard, this should become the default standard for government, and be enforced. The government’s plan to ‘crowd source’ recommendations for standards

) should be adopted.

69

Where suitable open standards exist, government should promote their use

should also be used to inform the decisions on what standards to adopt.

70

65 GS1 UK,

, compelling organisations to justify their actions if a proprietary or bespoke standard is adopted. As with

Data Crunch Report: The Impact of Bad Data on Profits and Consumer Service in the UK Grocery Industry, October 2009 66 In our CIO Council survey we asked respondents to list the three items where there should be greater coordination or mandation across government. Seven out of 18 respondents identified common standards. None recommended a more decentralised approach to this. 67 e.g., it may be appropriate to adopt the standards published by major internationally recognised standards bodies such as the Internet Engineering Task Force, the International Organization for Standardization, International Electrotechnical Commission, and the Telecommunication Standardization Sector ITU-T. The Telecommunication Standardization Sector (ITU-T) coordinates standards for telecommunications on behalf of the International Telecommunication Union (ITU). 68 See www.w3.org/standards/ 69 See the Cabinet Office Business plan, item 1.2.iii, for further details. 70 The government has recently taken steps towards this, issuing a policy note stating: “When purchasing software, ICT infrastructure, ICT security and other ICT goods and services, Cabinet Office recommends that Government departments should wherever possible deploy open standards in their procurement

42 Building the platform

the enforcement of commoditisation or shared services, moving towards a system of agreed and open standards will require clear roles and expert governance.

Roles and governance of the platform Setting up, implementing and maintaining the platform will require new roles, responsibilities and governance processes. Of particular importance is the role of the Government CIO, who must provide overall leadership to the wider government IT community. However, most resources will remain in departments, with lead departments taking ownership for particular aspects of the platform.

The role of the Government CIO The Government CIO is responsible for the overall IT strategy for government. Core parts of this strategy should be setting the balance between platform and agile and setting out the vision for the platform, detailing aspirations for the short, medium and long term.

For example, the Government CIO might determine that data storage should be part of the platform. The long term aspiration might be to have a single government tiered storage offering, run by a single lead department and hosted in the optimal sites for resilience, security and access. However, the short and medium strategy might involve interim steps of consolidating existing storage provision into clusters or moving certain non-sensitive low-tier storage onto public cloud services.

The Government CIO will also be responsible for translating this strategic vision of the platform into concrete policies, for example, determining who will be the lead department for each element of the platform and ensuring that all the procurement decisions, management decisions and detailed standards developed by the lead departments form a cohesive architecture and are in line with the overall IT strategy.

The Government CIO must also be able to judge performance and value for money in the platform in a detailed and accurate way. The Government CIO should be supported in these activities by input from the CIO Council and the ERG in Cabinet Office. The CIO Council and ERG should provide advice on the capabilities of departments, information on current spend and potential for savings, benchmarking of performance and updates on any large projects undertaken as part of the platform. Figure 5 outlines the role more fully.

specifications.” Cabinet Office ‘Procurement Policy Note – Use of Open Standards when specifying ICT requirement’. January 2011

Building the platform 43

Figure 5: Role of the Government CIO

Lead departments We are not proposing that the centre grows to take on the various elements that might benefit from being included in the platform. Departments should instead be tasked with taking the lead on particular elements of the platform based on existing expertise or ease of set up.

The effectiveness of the government CIO is critical to the success of the platform and agile approach. The person in this position should:

• act as head of the IT profession in government including chairing the CIO Council and sitting on the panel for senior IT appointments; he or she should also support the development and roll-out of agile training

• develop the government’s overall IT strategy, setting out the overall direction for government IT along with a high level system architecture for developing the platform

• govern the balance between platform and agile by identifying those elements that are included in the platform and the process for deciding how the platform will evolve over time; this person would also be responsible for ensuring that elements of the platform and agile innovations were aligned to the overall IT strategy

• hold the departmental CIOs accountable for following the overall IT strategy, including the extent to which elements of the platform such as commodity procurement and standards are adhered to

• ensure the quality of IT services, including identifying lead departments to take ownership of particular elements of the IT strategy where appropriate and continual benchmarking of performance

• represent the UK government on IT matters for example in high level liaison with industry or other governments around the world

• stay abreast of the latest technologies and opportunities to help provide challenge and suggest improvements to departmental IT strategies, and have a good awareness of the agile innovations developed within government

44 Building the platform

The platform elements under each lead department should be run in the interest of government as a whole rather than based on siloed priorities. Once the platform elements are clearly established and run as a service, it may be worth revisiting whether they should be run at arm’s length from the department to avoid any potential conflict of interests.

It is not enough simply to name a lead department for an area of the platform and assume that it will always be the best place for that delivery element to sit. Progress should be actively monitored, feedback sought and required improvements acted on. This requires cost and performance details to be available in an accessible and transparent format.

Compliance and escalation processes There is no escaping the fact that departments will sometimes need to put their individual requirements to one side for the benefit of government as a whole. This makes highly effective governance structures a necessity. Enforcing common rules across the platform for lead departments (as service deliverers) and compliance by other departments (as service users) will require effective leadership, accountability and escalation processes to resolve disputes.

As noted in Installing New Drivers,71

Consensus based on active support is in many ways the ideal for the platform. However, there is a need for greater ‘hard power’ when departments (either as lead departments delivering services or as a department using services) decide not to comply with the rules. Cabinet Office has recently established a moratorium on spend and considered inserting requirements in departmental ‘statements of internal control’. While useful, these are relatively blunt instruments, which can block some spending but cannot ensure that departments act in a value-driven way.

the key problem is with authority at the centre. Currently, the Government CIO heads the CIO Council, which facilitates change but cannot mandate it, and is supported by a small Office of the Government CIO with no formal powers and strictly limited resources. Thus the Government CIO is able to set out government strategy and take the lead on specific initiatives but is left to ‘sell’ the benefits of joint initiatives. Other countries have grappled with these concerns and in some cases have adopted a stronger central approach. The Australian Government’s model is described in Box 2.

A more effective approach would be to combine this with a strong ‘comply or explain’ model for departments, with reputational damage incurred for non-compliance. The Government CIO should set out acceptable reasons for non-compliance and act as the first level of arbitration. If the situation is still not resolved, either the Government CIO or the minister of the affected department should be able to escalate the issue to the Public Expenditure

71 Michael Hallsworth, Gareth Nellis and Mike Brass, Installing New Drivers: How to Improve Government’s Use of IT, Institute for Government, December 2009

Building the platform 45

Committee (PS(X)) for a final decision. The seniority of this escalation route should help ensure that departments only consider deviating from the platform approach when there is an exceptional case to be made. This model would apply to central government departments and their arms-length bodies while local public sector organisations would be given the opportunity to ‘opt in’.

To strengthen this process further, we recommend that all departmental spending on IT is published in an accessible format to the general public, meeting and where possible exceeding the commitments made in the Transparency Agenda. Where the escalation process is used, the details of the case from the department and the judgement of the PS(X) should also be made available for public scrutiny and comment.

Box 2: Australian ‘opt-out’ model

Sources: Department of Finance and Deregulation, Australia Process For Administration Of Opt-Outs From Whole-Of-Government ICT Arrangements. Independent Review of Implementation of the ICT Reform Program June 2010

Conclusion This chapter has set out a vision of the platform for government IT based on commoditisation, collaboration and common standards. We believe the benefits of such an approach are significant but recognise that moving towards that vision will require pragmatism in the near term.

Achieving quick wins where the return on investment is high and the changes are relatively easy to implement should be the top priority. However, in more complex or costly areas a phased approach might be more suitable. For example, rather than immediately switching all government organisations over to the new commodity desktops or printers, commodity items can be introduced on more of a natural wastage basis in line with planned refresh cycles or new procurements.

The Australian Government introduced a compliance process to ensure government agencies would conduct IT with a whole-of-government view. In its ‘opt-out’ model, an agency can only apply to opt out of the whole-of-government approach if it follows a strict set of criteria such as where compliance would undermine national security or where implementation is not legally possible. Only cases meeting these criteria would be considered for an opt-out. The agencies would then have to provide a clear business case supported by financial analysis of the impact of opting in and out.

The cases would have to go via a senior civil servant board and get final approval from an established group of senior ministers. A recent independent review of this process found: “This process appears to have been effective in ensuring that agencies adopt a more disciplined approach to complying with whole-of-Government ICT policies.”

46 Building the platform

Where it would be prohibitively expensive to adapt existing legacy systems to meet common standards, it may be more sensible to publish the discrepancies between the legacy standards and the platform standards transparently. This could mean highlighting any tested workarounds, and waiting until the legacy system is replaced or overhauled before adopting the platform standards. Shared service offerings can be built up over time as existing service contracts expire or where break clauses exist.

Agile projects 47

5. Agile projects

“The best laid schemes o’ mice an’ men / Gang aft agley.”72

We recommend that government adopts a much more agile approach to IT for one simple reason: it works.

– Robert Burns

The review of case studies for this report has found that adopting an agile approach can deliver tremendous advantages over traditionally run IT projects in cost, speed and end results. Owing to their iterative and adaptive nature and focus on user involvement, agile projects characteristically deliver solutions with high user acceptance and are right up to date with the current needs of the business. As a senior manager at a FTSE 100 company told us, “[T]he benefits of this change [adopting agile] can improve delivery performance, in terms of cost, quality and speed, by a factor of 20.”

Although the private sector is leading the way, we have drawn on a growing body of evidence demonstrating that agile can deliver significant benefits for projects of all sizes and levels of complexity when applied in a government setting. Experiences at DWP, the Ordnance Survey, and our own project with the Home Office and Metropolitan Police all show that agile can deliver impressive results.

What is more, agile need not be restricted to the margins of IT development, such as minor application development or the odd website. The principles of the agile approach can be applied to almost any IT project and could also be considered for non IT-related applications. As several leaders from FTSE 100 companies told us, the principles can be applied to virtually any business problem.

Agile principles Agile may have originated as a software development tool, but many of its principles can be used much more widely. Projects should be modular,73

72 From the poem, ‘To a Mouse’, written by Burns in 1785

iterative, responsive to change and have users at the core.

73 Modularity is a good practice design principle rather than a specific principle associated exclusively with Agile Software Development. In practice, an agile approach is likely to be modular by default. As agile practitioner and author Kirk Knoernschild put it: “Modularity is a key ingredient of agile architecture. Modularity ensures that development teams understand architectural dependencies that are going to inhibit or accommodate change. Simply embracing an attitude of change is not enough. We must also be able to accommodate change efficiently. Modularity allows the development team to envision and manage change

48 Agile projects

The origins of the agile principles described here are based on those guiding the Agile Software Development methodology first developed in the 1990s.

This broad development approach has subsequently evolved into several specific methodologies such as Scrum, DSDM Atern and Extreme Programming. The overarching ideas behind them all are expressed within the 2001 ‘Agile Manifesto’,74

While this was written specifically with software development in mind, we believe that the core principles can also apply more broadly to IT-enabled business change projects. The basics of an agile approach are set out in Figure 6.

which stresses the delivery of results, customer collaboration, good communications and responsiveness to change as its core priorities.

Figure 6: The agile approach

Modular Modularity involves splitting up complex problems and projects into smaller components and portions of functionality, which can then be prioritised. Each module should be capable of working in a standalone fashion and in concert with other modules. This can speed up the time to delivery, enabling users to access the functionality of modules developed early without necessarily having to wait until all of the original specification has been built. It can

more easily, meaning they’ll be able to make the change they want to make when they want to make it.” See Kirk Knoernschild ‘Agile Architecture Requires Modularity’, June 2009 74 The Agile Manifesto can be found at www.agilemanifesto.org

User involvement throughout

Initial requirements

Design / amend

Build

Test

Evaluate / update

Iteration release

Agile projects 49

also make upgrades and changes easier as systems can be altered module by module or new modules can be added to the original design.

The US Department of Defense explains the approach as follows: “A fundamental step is to partition the design into a hierarchy of individual modules (both hardware and software) with well defined interfaces based on open standards, such that the inputs and outputs of a module are effectively isolated from the specific design utilized inside that module. Thus, so long as interface requirements are satisfied, changes can be made within a module without impacting higher level system functionality and reuse of modules is enabled.”75

Iterative

An iterative and incremental approach acknowledges that the best solution and means of delivering it are not always known at the start. By trialling in short iterations, receiving feedback and learning from mistakes a much more successful system can evolve than if everything is planned from the outset.

The Cabinet Office cites the Microsoft Office package pointing out that “Microsoft did not attempt to build all the functionality of Word 97 into the first release of Word; they created a simple version with a usable set of facilities, which was then built on to create later versions”.76

Agile projects take this incremental release process a stage further. Rather than annual releases after a system has gone live, iterations start right at the development stage and occur much more frequently. Users are shown prototypes and invited to use beta versions of the system as early as possible. This helps to identify problems and refine the design at the earliest possible point.

Each iteration can have a duration as short as two weeks. This gives users a clear sense of the progress made and can allow the business to rapidly make corrections or call a halt if the development is not proceeding as they hoped.

75 Defense Science Board, Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology, Department of Defense, March 2009, p. 53 76 Cabinet Office, Successful IT: Modernising Government in Action, 2002, p. 32

50 Agile projects

Responsive to change Shorter iterations and regular reviews also provide opportunities for changes to be made and priorities adjusted within agile projects. Managers of many agile projects create a ‘long list’ containing aspects of the system’s functionality, which are then prioritised on the basis of business needs and technical feasibility. The solution is then developed in list order, with users and technical experts agreeing what is targeted for delivery within the current iteration. Should the business needs change or new technological solutions become apparent, the list order can be easily amended with all stakeholders being made fully aware of the projected impacts of any changes.

Users at the core Within an agile project, users or business champions are embedded within the project team. This enables the business to provide continuous input and refinement, ensuring what is delivered is fit for purpose and aligned to business priorities. The Office of Government Commerce estimates the user commitment for a traditional project to be approximately 15%,77

How agile can improve government IT

whereas in an agile project users (or a business champion) should be a full time member of the team.

By adopting an agile approach to IT projects, government can realise a wide range of benefits.

More for less With the current focus on reducing public sector costs, an agile approach can actually deliver more for less. The prioritised approach to agile means that what is needed is delivered, stripping out the cost of delivering non-essential items. It can also help overcome the inertia arising from traditional practices of needing 100% agreement from all the stakeholders for all requirements (see Box 3).

As the approach empowers project teams to make decisions, it can reduce the often time-consuming decision-making associated with traditional processes. As there are embedded users within the team communications between IT and the business are much quicker and more effective. This can help to speed up the pace of progress.

The modular and iterative nature of the process can also allow users to start to realise the benefits of the solution much earlier. By prioritising areas of the highest business value and removing the need for every part of the solution to be delivered together, the delivery timelines for key functionality can be brought forward.

77 Office of Government Commerce, Application Development Modularity

Agile projects 51

At DWP, the timeline to deliver the new universal credit system using a traditional approach was expected to be 2015. By adopting a more agile approach, the programme managers now hope to be able to deliver the essential functionality by 2013.78

Box 3: Prioritising requirements at a large government agency

Source: Institute for Government interviews. See Annex C Case Study 1 for further detail.

SME involvement A modular approach will also help government achieve its goal of involving more small and medium sized enterprises (SMEs) in IT projects.79

Greater flexibility and control

By breaking programmes up into smaller modules, government’s choice of supplier is no longer limited to a few larger suppliers. Furthermore the iterative nature helps to reduce risks of using smaller or newer entrepreneurs and suppliers as the government is not locked in to high-cost extended contracts.

Those considering agile for the first time are often concerned that they will have less control over the project. Instead, the reverse is often true. Rather than the illusion of control provided by highly detailed specifications and stage gates, agile enables the business to regularly review the success of the project against the tangible results delivered and encourages corrections where required. An agile approach is also built specifically around the concept that changes do occur. Rather than trying to prevent the inevitable, it provides a means for changes to occur in a constructive fashion. This is illustrated by Box 4.

78 See Annex C case studies. 79 Government aims to award 25% of all contracts to SMEs. See Cabinet Office, Plans to Open up Government to Small Businesses, 1 November 2010

A large government agency aimed to improve their online services.

Using a traditional approach, the agency staff tried several times over a four year period to put their services online. Despite spending over £1m, they were unable to complete the first stage gate of the investment approval process, which required full agreement from all stakeholders.

By adopting an agile approach the staff were able to prioritise and adjust their requirements during each iteration. Within a year they had developed and implemented a fully working platform for only £650k.

52 Agile projects

Box 4: Home Office and Metropolitan Police identity fraud prevention80

Source: Institute for Government interviews. See Annex C Case Study 10 for further detail.

80 IndigoBlue Consulting Ltd is an independent consultancy specialising in large scale agile adoption and CIFAS is a not for profit organisation whose members share information of confirmed cases of fraud with the intention of preventing further fraudulent activity.

In partnership with the Home Office, Operation Amberhill at the Metropolitan Police and IndigoBlue, the Institute for Government sponsored a project to explore how agile principles could be implemented within a government setting.

Operation Amberhill was set up to record details of known false identities and to disseminate this information to public and private sector organisations to prevent them being used for further criminal activity. While Amberhill was able to use CIFAS to share information with certain organisations, legal complications meant that key departments were unable to make full use of this system. Developing a public sector version of CIFAS was also ruled out as prohibitively expensive. The team at Operation Amberhill had to use basic shared spreadsheets and manual validation processes to capture and share data. With the number of cases rapidly approaching the data limits of their Excel version, an alternative solution was urgently needed.

Prioritised and modular

Rather than try to solve all the problems in one go, it was agreed that the most immediate priority was to create a database system that Amberhill could use to overcome the team’s data capacity concerns and improve their quality assurance processes. However, the system was also built in a modular fashion so that more advanced functionality, including the potential for other departments to interact directly with the system, could still be added in the future. The initial modules of the system were successfully delivered and are now being used by the Amberhill team.

Flexible and controlled

Operation Amberhill found that agile gave them suitable control. Despite the relatively simple nature of the solution, 23 new requirements were added within the first two week iteration alone. The users and departmental sponsors were able to make informed changes to the prioritisation of functionality as the intended business needs shifted and some elements became more or less urgently required. One user said: “In 25 years of service I have never known a project to develop at such a startling rate. This is even more impressive when you take into account that all decisions have been made in [a] calm and considered manner with no less importance being given to every stage, in spite of the time restraints.”

Agile projects 53

Better end solutions Users are embedded within the project team under an agile approach, and this dramatically reduces the risks of requirements being misunderstood. Rather than technical experts, with no clear understanding of the business situation trying to interpret items from a specification document, the business users can clarify any queries directly. Similarly, if a requirement appears to call for a more expensive or complicated option, the technical expert can check directly with the business user whether this is strictly necessary or if an alternative option would be suitable. This continual input from users places them at the centre of the design process, helping to ensure that the end product will be as intuitive and usable as possible. The ability to amend the priorities to the current business needs mean that agile solutions are designed to be truly fit for purpose.

Failing small and failing fast Running smaller projects in an iterative, incremental way presents an opportunity for departments to control the flow of money to projects based on the value and benefit gained from the development. The approach provides a mechanism to cancel or amend projects where diminishing returns have been identified and mitigates the risk of large-scale failure. In short, it provides a way to fail small and fail early.

Making agile work in government: challenges

Adopting any new system within a single government department, let alone across the whole of government, is a major challenge. The existing governance and commercial processes, not to mention the fundamental mindset shift required, pose specific and difficult challenges. Yet this change is possible. None of the challenges outlined below are insurmountable and the benefits agile can bring make it worth the effort.

Cultural challenges The transition from a traditional method of project management to an agile approach can be far from straightforward. Often the sequential, structured approach, characterised by slow decision-making and a regular need for consensus, can become deeply embedded into mindsets and organisational routines.

A recent international survey of close to 5,000 respondents indicated that the three most significant barriers to the adoption of agile are the ability to change organisational culture, general resistance to change, and the availability of personnel with necessary skills.81

Governance issues

The legacy of a structured and hierarchical approach can result in reluctance among employees to take on responsibility for decisions. A senior manager on the DWP Accelerated Service Delivery project had to encourage his team to accept this level of empowerment,

81 Version One, State of Agile 2010, 5th Annual Survey. Analysis.net Research

54 Agile projects

reassuring them, “If you make a decision and fail – I will take responsibility, however, if you make a decision and succeed – you claim the credit.”

Existing project approval process can also act as a barrier to the adoption of agile. These processes often require full business cases in order to gain authorisation from funding boards. These boards may look to the level of detail within the specification as an indicator of whether the project proposal has been carefully thought through and are often reluctant to accept the unfixed requirements or uncertain solutions of an agile approach.

Commercial complications Commercial processes can also act to reinforce these barriers to agile. A preference for fixed price contracts to deliver a particular solution reinforces the tendency for both sides to demand a high level of detail up-front. This runs contrary to the preferred model of funding for agile projects, where much smaller fees will be agreed on a time and materials basis and contracts can be halted after any iteration. In an increasingly litigious environment, it can be difficult to move from the false security of agreeing requirements contractually towards an agile approach, which requires more of a partnership approach to problem solving.

Government is also constrained by EU procurement directives specifying that IT contracts above £105k are required to be advertised in the Official Journal of the European Union (OJEU) and subject to open tender. While OJEU is sometimes considered a barrier to agile contracts being granted, this is not necessarily the case. By using agile, smaller and less expensive projects are required. This could mean that fewer projects have to go through the OJEU process overall. Several key issues surrounding the OJEU processes and agile are explored in more detail in Annex B.

Making agile work in government: enablers

Based on the experiences of the case studies reviewed and interviews with agile specialists we have identified several important factors to a successful transition to a more agile approach.

Support from senior leadership The initial support a new initiative receives can be critical to its eventual success. Within hierarchical organisations, the level of senior sponsorship can act as a crucial motivator for the rest of the organisation. As ministers set the agenda for their department, their buy-in to the change is essential. Within government, each department should appoint a dedicated high-profile ‘agile champion’ to build and sustain the momentum for change.

It is also absolutely essential that the department understands it must commit its best people as embedded agile team members in order to reap the benefits of this approach. The input of users or business champions is crucial to delivering successful agile solutions; if the skills and knowledge of the embedded user are poor, then the end solution will reflect this.

Agile projects 55

Show it works Success breeds success. The quickest way to overcome scepticism of agile is to demonstrate that it works. Each department should choose several upcoming projects to be set up and run using agile. These projects should be in areas that will generate the most compelling results. Participants in successful agile projects can often be the most convincing advocates to others within the organisation.

For example, a senior manager at a large manufacturing organisation reflected on his experience with agile saying: “I was sceptical, now I would fight ‘tooth and nail’ anything that threatened working this way.” In the Home Office project, a Detective Constable at the Metropolitan Police Service highlighted how this approach has differed from previous experience saying: “When initially approached about this project I was sceptical as the actual benefits/value which would result... I was expecting to receive something, not necessarily what I wanted, in the middle of next year.” After having been through this process he remarked, “I would personally recommend this type of working to my peers in the future.”

Take a cross-Whitehall approach To provide the most value, government as a whole must be able to benefit from agile innovations. To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives. It should be easy for groups tackling similar problems to identify each other and merge where appropriate. Where possible the outcomes of agile experiments should be open for all to see and learn from. As there are cross-cutting issues and opportunities that do not sit naturally under a departmental banner, there is a clear role for the nascent government Skunkworks to take the lead in coordinating a cross-government approach. See Box 5.

There must also be a clear mechanism for escalating the best and most widely applicable ideas so they either become part of the platform, or form a more specialised centre of excellence for their sector. DWP has established its innovative ‘Ideas Street’, which aims to gather new ideas and sort them based on a virtual stock exchange.82

Scaling up this kind of approach could help identify the most useful agile innovations across government. Using information like this, Skunkworks could act as a channel up to the Government CIO. This would help ensure that the platform is continually and constructively challenged to absorb the latest successes.

82 GC News, ‘DWP Considers Opening Up Ideas Street’, Guardian Professional, 23 September 2010

56 Agile projects

Box 5: Skunkworks

Source: Institute for Government interviews

Amend the supporting processes While existing commercial and governance processes can act as barriers to adopting agile, none are insurmountable. A good starting point for departments is to set up a clear process for allocating seed-funding for initial agile pilots and small scale experiments. Seed funding should be small scale (well below the OJEU limit) and allocated in short time-limited blocks. This process should not require detailed specifications, but any project must demonstrate tangible success at the end of each iteration or face cancellation.

Governance processes should also be amended in line with agile principles. The current Gateway Review process is designed for larger programmes run using traditional sequential methods and emphasises fixing problems with the project processes rather than judging whether the project is still worthwhile and ending it if necessary. Though agile projects are designed to be self-assuring, a light touch, proactive assessment process could help ensure agile is being used to achieve the best outcomes. See Annex B for further details on this. The Cabinet Office should investigate and implement a replacement assurance process that is compatible with agile principles.

The government has pledged to create a small IT development team in the Cabinet Office that can develop low cost IT applications in-house and advise on the procurement of large projects. It will tackle cross government IT projects in six week delivery cycles. Products will be released under Open Source License and the team will work with counterparts to promote agile delivery across government.

The intention is to undertake strategic engagement with IT enabled programmes and projects in order to integrate agile thinking into projects from the outset. This is a strong departure from the traditional way the Cabinet Office engages with IT projects in departments.

Skunkworks aims to promote a community of internal and external developers and entrepreneurs to work with, support and grow the function. It will engage members through collaborative problem solving and commissioning solutions to challenging IT problems.

Agile projects 57

Embed the changes To make the change sustainable, agile will need to become embedded in the culture and processes of the organisation. Centres of excellence and formal training can help retain the focus on agile best practice techniques as Box 6 illustrates. Clear visibility and communication of the benefits that agile has delivered within the organisation can also help solidify support for the approach. The eventual aim should be to make agile the default for any project.

Box 6: Agile centres of excellence

Source: Institute for Government interviews. See Annex C Case Study 6 and 7 for further detail.

Conclusion As this chapter has demonstrated, agile delivers substantial benefits, which government can and should pursue. This change is not just desirable, but also necessary.

Agile is about not just cost savings or faster delivery times, but also a new approach to helping business to operate. Traditional linear project methods may have been adequate for situations where there were static requirements and a clear picture of the solution, but they are not suitable for the rapid changes and solution exploration needed by departments today.

The current system does not provide the public sector with the flexible tools it needs to tackle complex political issues. At its most fundamental, IT is a tool to be used by the business to help it work effectively and explore new opportunities.

Government’s toolset is no longer fit for purpose – it needs to be more agile.

Two global banks have established central support in the form of ‘agile centres of excellence’. These central units support agile projects by providing mentoring, training, resources and tools. As some of the key causes of agile failure are lack of experience and external pressure to follow traditional waterfall practices, these centres of excellence can provide vital support to project teams. Their establishment also signals the priority placed on agile development and helps to overcome cultural barriers to further adoption.

58 Conclusions and recommendations

6. Conclusions and recommendations

Government IT is a long way from the cutting edge. The current combination of consensual departmentalism and the traditional Waterfall and V-model project approaches to projects have created a vicious circle in which government fails to get the basics right and so gets bogged down, unable to take advantage of emerging technologies and ways of working. Government then falls further behind.

Doing the same things better has failed to transform government IT. A fundamental rethink is required.

Think in terms of platform and agility The platform must be designed to standardise and simplify core elements of government IT in order to bear down on costs and reduce duplication across the system. It should also establish some common standards to support greater interoperability and to facilitate more joined up IT across government. Responsibility and risk for the elements of IT not covered by the platform should be devolved to departments and from departments to projects using agile principles for rapid, iterative development.

Platform and agility are not contradictory and when the links between them are well understood and exploited, can be mutually reinforcing. The goal should be to use agile approaches to explore new opportunities with successful innovations scaled up more rapidly across the system and new technology passing into the platform as it becomes better established.

Recommendation 1: The Government CIO should govern which elements of government IT fall within the platform and which should remain outside for agile development. To do this effectively, the Government CIO must operate independently of departmental interests.

Use the platform to drive efficiencies across the system but keep delivery decentralised The platform must ‘assimilate’ the well-established parts of government IT by bearing down on the cost of commodity items, reducing duplication of services and infrastructure, and setting common standards to support interoperability across the system.

Rather than getting trapped in a simple dichotomy of centralisation versus decentralisation, the platform should combine shared approaches across the system with a distributed network of delivery. The centre will need to lead on certain coordinating aspects of the platform including strategy, policy, common standards and benchmarking, but delivery should reflect and build on the capacity and capability in the system.

Conclusions and recommendations 59

Recommendation 2: The platform should focus relentlessly on three areas: commoditisation, rationalising the management of common elements of government IT and setting common standards.

Recommendation 3: Delivery of elements in the platform should be undertaken by lead departments, on behalf of the government as a whole.

Recommendation 4: Clear governance and escalation structures are required to resolve disputes between lead departments and other departments. The Government CIO should be the first point of arbitration and the Public Expenditure Committee should provide the ultimate point of authority.

Support and foster agile principles The evidence reviewed for this report is clear cut – organisations that pursue agile development at scale are unequivocal on the positive effect it has had on the business as a whole. However, they are also clear that the challenge of implementing this approach should not be underestimated and that comprehensive support is required to embed the changes. Government departments face special challenges given their size and focus on highly complex problems. To this end, strong leadership and support from both the Cabinet Office and senior departmental management is essential to move towards a more agile approach to IT delivery.

Recommendation 5: During 2011/12 all government departments should run several upcoming projects using agile development principles. The exact number should be guided by the size of the department and collectively be weighty enough to act as a real catalyst for change within the department.

Recommendation 6: Future IT and project management training for government employees should include a significant component of agile methods training. Departments should also help develop agile ‘centres of excellence’ to provide support, resources, training and coaching.

Recommendation 7: All departments should review governance, project approval processes and legal arrangements to ensure that they can be made to work with agile projects. As part of this the Cabinet Office should investigate and implement an assurance process to replace the Gateway Review for agile projects.

Recommendation 8: Government departments should ensure that all future supply contracts can be made to work with a more flexible and iterative approach to development. This should include licensing and supplier change requests. This review should be led by the centre in order to avoid duplication at the departmental level.

Take steps now and expect to refine the approach over time The scale of change required in government IT is enormous and is complicated further by a web of interdependencies and institutional barriers to reform. Faced by such complexity, the

60 Conclusions and recommendations

lesson inherent in the principles of agile is not to try to develop a perfect roadmap for change up-front but to work up plans iteratively and to refine the approach over time based on user interaction and feedback. Our analysis suggests that even small steps towards developing the platform and using agile techniques will deliver real benefits. Starting with ‘quick wins’ will help to build support for change early on, while developing a longer term plan. No system is perfect and no system is immune from change. Having a more flexible and agile system is the best way to keep adapting to the shock of the new.

Bibliography 61

Bibliography

Albert, A., 2010. Collington to Slash £13 Billion Common Spend by 25 per cent. 25th November 2010, Supply Management

Atkinson, A., and Benefield, G. 2011. The Curse of the Change Control Mechanism. February 2011, The Society for Computers and Law

Australian Government Information Management Office, 2010. Open Source Software Policy. (Canberra: Australian Government Information Office)

Bolton, S., 2010. The Business Case for the Adoption of a UK Standard for Research Information Interchange. JISC

Cabinet Office, 2002. Successful IT: Modernising Government in Action. (London: Cabinet Office)

Cabinet Office, 2011. Business Plan. (London: Cabinet Office)

Cabinet Office, 2011. Procurement Policy Note – Use of Open Standards when specifying ICT requirement. (London: Cabinet Office)

Cameron, D., 2007. The Conservative Approach to Improving Public Services. The Conservative Party

Collins, T., 2009. The NAO’s Most Serious Criticism of any IT-based Project? Computer Weekly

Committee of Public Accounts, 2006. Foreign and Commonwealth Office Annual Report 2004–05. (London: House of Commons)

Defense Science Board, 2009. Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology.

Department of Finance and Deregulation, 2009. Process for Administration of Opt-Outs from Whole-Of-Government ICT Arrangements (Australia: Department of Finance and Deregulation)

Dunleavy, P., Margetts, H., Bastow, S., and Tinkler, J. 2008. Digital Era Governance: IT Corporations, the State and E-government. (Oxford: Oxford University Press),

GC News, 2010. DWP Considers Opening Up Ideas Street. 23rd September 2010, Guardian Professional

Gray, B., 2009. Review of Acquisition for the Secretary of State for Defence: An Independent Report. (London: Bernard Gray)

Green, P., 2010. Efficiency Review by Sir Philip Green. (London: The Cabinet Office)

62 Bibliography

Grossman, L., 2010. Person of the Year 2010. December 15th 2010, Time Magazine

GS1 UK, 2009. Data Crunch Report: The Impact of Bad Data on Profits and Consumer Service in the UK Grocery Industry. (London: GS1 UK)

Hall, K., 2011. Government tells major IT suppliers - we want more open source software. 23rd February 2011, Computer Weekly

Hallsworth, M., Nellis, G. and Brass M., 2009. Installing New Drivers: How to Improve Government’s Use of IT. (London: Institute for Government)

HM Government, 2010. 2010 Government ICT Strategy. (London: HM Government)

HM Treasury, 2009. Operational Efficiency Programme Final Report. (London: HM Treasury)

HM Treasury, 2009. Operational Efficiency Programme Collaborative Procurement. (London: HM Treasury)

House of Commons Committee of Public Accounts, 2010. HM Revenue and Customs’ 2009–10 Accounts. (London: House of Commons)

HP Enterprise Services, 2010. IT Trends: The Fourth Wave is Here. HP

Knoernschild, K., 2009. Agile Architecture Requires Modularity. 15th June 2009, TechDistrict

Lai, E., 2008. The “640k” Quote Won't Go Away – but Did Gates Really Say It? June 23rd 2008. Computerworld

Liversidge, E., 2005. The Death of the V Model. Harmonic Software Systems Ltd

Malaysian Government, 2010. ePerolehan Saving Govt Millions of Ringgit

Ministry of Finance, Denmark, 2009. Shared Service Centres in the Danish Central Government (Denmark: Ministry of Finance)

Ministry of Justice, 2010. Virtual Courts Pilot: Outcome Evaluation Report (London: Ministry of Justice)

Mohamed, A., 2007 Do Gateway Reviews Produce Results. 15th May 2007, Computer Weekly

National Archives, 2006. The Public Contracts Regulations 2006. (London: National Archives)

National Audit Office, 2004. Improving IT Procurement. (London: National Audit Office)

National Audit Office, 2006. Delivering Successful IT-enabled Business Change. (London: National Audit Office)

National Audit Office, 2008. Shared Services in the Department for Transport and its Agencies. (London: National Audit Office)

Bibliography 63

National Audit Office, 2009. Commercial Skills for Complex Government Projects. (London: National Audit Office)

National Audit Office, 2009. The National Offender Management Information System. (London: National Audit Office)

National Audit Office, 2010. Minimising the Cost of Administrative Errors in the Benefit System. (London: National Audit Office)

National Audit Office, 2010. A Review of Collaborative Procurement Across the Public Sector. (London: National Audit Office)

Office of Government Commerce, 2004. OGC Faster Procurement Process Study. (London: Office of Government Commerce)

Office of Government Commerce, 2005. Common Causes of Project Failure. (London: Office of Government Commerce)

Office of Government Commerce, 2007. The OGC Gateway Process: A Manager’s Checklist. (London: Office of Government Commerce)

Office of Government Commerce, 2008. Procurement Capability Reviews. (London: Office of Government Commerce)

Office of Government Commerce, 2009. OGC Gateway Process Review 0: Strategic Assessment. (London: Office of Government Commerce)

Office of Government Commerce, 2010. Policy and Standards Framework Online Portal. (London: Office of Government Commerce)

Office of Government Commerce, Application Development Modularity. (London: Office of Government Commerce)

Office for National Statistics, 2010. Internet Access. (London: Office of Government Commerce)

Organ, J. 2003. The Co-ordination of E-government in Historical Context, Public Policy and Administration, 18:2

Parker, S., Paun, A., McClory, J., and Blatchford K., 2010. Shaping Up: A Whitehall for the Future. (London: Institute for Government)

Public Accounts Committee, 2009. The National Offender Management Information System. (London: House of Commons)

Reinecke, I., 2010. Independent Review of Implementation of the ICT Reform Program. (Canberra: Australian Government of Finance and Deregulation)

Savage, M., 2010. Labour's Computer Blunders Cost £26bn. 19th January 2010, The Independent

64 Bibliography

Say, M., 2005. The Information Man, Government Computing, 19:2

Service Canada, 2008. Service Canada Client Satisfaction Survey: 2008 Survey. (Canada: Government of Canada)

The Standish Group, 2009. Chaos report. (Boston, USA: The Standish Group)

Version One, 2010. State of Agile 2010, 5th Annual Survey. Analysis.net Research

Websites Agile Manifesto, 2011. <www.agilemanifesto.org>

All About Agile, 2011. <www.allaboutagile.com>

Data, 2011. <data.gov.uk/>

DirectGov, 2011. <www.direct.gov.uk/en/index.htm>

eperolehan, 2011. <home.eperolehan.gov.my/home/>

Government Gateway, 2011. <www.gateway.gov.uk/>

IT Dashboard, 2011. <it.usaspending.gov/>

JISC, 2011. <www.jisc.ac.uk>

Lorenzo, 2011. <lorenzo.isoftplc.com>

Microsoft UK, 2011. <emea.microsoftstore.com/UK/en-GB/Microsoft/Office-Home-and-Business-2010>

Red Hat, 2011. <www.europe.redhat.com>

Annex A: Methodology 65

Annex A: Methodology

The project was initiated to look at how government could improve its use of IT. The research focused on several main questions:

• What are the key challenges facing government IT?

• To what extent can a different (platform approach83

• To what extent can a different (agile

) relationship between the centre and departments resolve these challenges?

84

Taskforce

) approach to IT projects resolve these challenges?

The Institute for Government established a high level Taskforce of government and private sector CIOs, senior civil servants and thought leaders to develop a set of recommendations on how to radically improve government IT.85

• provide overall strategic direction

Meetings were held over the course of six months, during which time Taskforce members were asked to:

• provide specialist input

• contribute to the Taskforce recommendations

• advocate on behalf of the Taskforce by promoting its work

83 We use ‘platform’ as a description of a shared, government-wide approach to simplifying elements of IT. The aim of the platform is to bear down on costs, reduce duplication and establish shared standards. The focus is on commodity procurement, coordinating delivery of common IT facilities (such as data centres) and services, and setting common standards to support interoperability. 84 An approach that uses modular and iterative development based on user involvement and feedback, which prioritises early delivery of core working functionality. 85 Sir Ian Magee (Institute for Government), Ursula Brennan (Ministry of Defence), Roger James, John Keeling (John Lewis Partnership), David Lister (National Grid), Bill McCluggage (Cabinet Office) John Suffolk (formerly Cabinet Office), Tom Steinberg (MySociety and Public Sector Transparency Board) and Annette Vernon (Home Office, on sabbatical).

66 Annex A: Methodology

Live agile pilot project As part of the research, we established a pilot project to demonstrate whether an agile approach to IT can resolve a long standing policy issue facing government: improving information sharing on identity fraud. This project was run by the Metropolitan Police Service in collaboration with the Home Office and the consultancy Indigo Blue.86

This project tasked a small team with a mix of policy, project management and technical skills to work in the Home Office for a period of three months to develop a system of information sharing to reduce identity fraud. The project was designed to generate evidence about the barriers to effective government IT, while using an agile approach to project management. The team aimed to create a working product as early as possible by using incremental development and incorporating feedback from the business users throughout. The work was split into two main phases:

Phase 1: Preliminary scoping and requirements gathering (weeks 1–4):

• assessing options for fraud prevention including costs of system design and any technical challenges

• confirming management support for the option chosen

• determining initial user requirements and technical specifications

Phase 2: Iterative development and testing (weeks 5–15):

• developing an iterative solution with user feedback

• developing prototype(s)

• considering feedback and new requirements contributing to the next iteration

• making a go-live ready product available

• implementing the solution

Interviews, workshops and surveys To explore key challenges facing government IT, we also undertook semi-structured interviews with several academics and technology journalists, 28 senior government IT managers, 9 senior private sector IT managers, 12 external IT experts, 14 government IT suppliers and two IT solicitors. The intention was to gain a wide range of perspectives on the issues.

86 IndigoBlue Consultancy Ltd is an independent consultancy specialising in large scale agile adoption.

Annex A: Methodology 67

We held four workshops with a range of experts and commentators on government IT. This included:

• a supplier workshop hosted by the intellect trade industry to gain supplier input

• a workshop with the Board of the DSDM Consortium87

• a workshop that showcased a series of IT projects using agile development including the Cabinet Office Skunkworks with Mark O’Neill (Chief Information Officer, Department for Communities and Local Government, Department for Culture, Media and Sport, and Skunkworks), the Department for Work and Pensions Accelerated Service Delivery Programme (Steve Dover, Corporate Director of Major Programmes) and the Home Office Information Sharing to Prevent Identity Fraud Project (John Wright, Senior Consultant, Indigo Blue, and Sarah Heseltine, Home Office)

to gain advice on implementing agile development techniques

• a workshop that looked at the role of the Centre of Government in IT with speakers Ian Watmore (Chief Operating Officer, Cabinet Office), Annette Vernon (CIO, Home Office, on sabbatical), John Keeling (IT Director, John Lewis Partnership) and Roger James (Computiv and University of Southampton)

• a workshop co-hosted by the DSDM Consortium that reviewed how agile development is being used in a range of organisations. Speakers included Colin Macandrew (Centrica), Nigel Edwards (General Dynamics), David Hayles (Ministry of Defence), Richard Rolt (Napp Pharmaceuticals), and senior managers at a global universal bank, a FTSE 100 bank, a large publishing company, and a large manufacturing organisation.

We conducted site visits to Napp Pharmaceuticals, the Ordnance Survey, John Lewis Partnership and the Department for Work and Pensions. These visits looked at how these organisations address key challenges facing IT projects.

We surveyed 27 public sector CIOs using an online questionnaire that resulted in 18 responses. The questions and responses are contained in full in Annex D.

We reviewed the emerging literature, blogs and conference material on the use of agile development techniques in government as well as the literature on the role of the centre in large multidivisional organisations.

87 DSDM Consortium is a non-profit advocacy organisation that since 1994 has focused on defining, promoting and continuously evolving a best-practice framework for agile project management, development and delivery.

68 Annex B: Procurement, contracting and the Gateway Review process

Annex B: Procurement, contracting and the Gateway Review process

Procurement The public sector procurement process is governed by a series of rules and regulations set out by the EU (Directive on the OJEU process), the British Parliament (Public Contracts Regulations 2006) and individual government departments.88 It is also subject to scrutiny through the Gateway Review Process and Procurement Capability Reviews carried out by the Office for Government Commerce.89

EU procurement law is often seen as a barrier to procuring agile projects but the timescales imposed by the EU Directives account for less than 10% of the 77 week procurement period.

90

The procurement process can undermine agile projects in two ways. First, when detailed specifications are used it can restrict the freedom to innovate. Second, the long timelines associated with the procurement process can restrict the ability to deliver production ready solutions rapidly.

EU legislation requires public sector organisations to publish tenders valued above a certain financial threshold (normally £105k) for a set period of time (normally about 30 days). This process is part of the larger procurement and contracting process that is set out in Figure 7.

In order to allow the freedom to innovate that an agile process requires, it is important to establish high-level rather than detailed specifications to tender. If the project exceeds the initial scope set out in the OJEU advertisement, the procurement process will have to be repeated. However, an advertisement that is broad in scope can have its precise specifications defined as the project progresses.

The legislation stipulates that the subject of the contract, “must be described in a manner such that it fulfils the use for which it is intended by the contracting authority” with the further caveat that the technical specification must be set out “in terms of performance or functional

88 Office of Government Commerce, Policy and Standards Framework Online Portal, July 2010 89 Office of Government Commerce, Procurement Capability Reviews 90 According to the OGC, the only timescales imposed by the EU Directive is the requirement to publish the tender advertisement and the award notice in the OJEU. See Office of Government Commerce, Faster Procurement Process Study, November 2004

Annex B: Procurement, contracting and the Gateway Review process 69

requirements provided that the requirements are sufficiently precise to allow a supplier to determine the subject of the contract and a contracting authority to award the contract”.91

Basing the procurement decision on the ‘most economically advantageous tender’ faces similar problems to that of contracting where there is no fixed specification. However, objective criteria such as whether or not the development will be test-driven, the kind of tests, whether there will be a central repository of code, and others can all constitute grounds for objective comparison. This can help ensure that agile projects are procured in a fair, competitive way that conforms to OJEU guidelines.

91 National Archives, The Public Contracts Regulations 2006

70 Annex B: Procurement, contracting and the Gateway Review process

Figure 7: OGC procurement process

Source: Office of Government Commerce, OGC Faster Procurement Process Study, Annex B, November 2004.

Annex B: Procurement, contracting and the Gateway Review process 71

To reduce the amount of procurement time associated with an open tender, government departments can set up a framework agreement with a supplier. Framework agreements are umbrella contracts with providers, which set out terms and conditions under which specific purchases can be made during the length of the agreement (normally a maximum of four years). Individual contracts can be arranged within these agreements consisting of a limited number of iterations. If a supplier on the framework agreement cannot deliver a service, it is possible for the supplier to add other specialist organisations (often SMEs) to deliver part of the service.

A further option is to reduce the size of projects to come in under the OJEU threshold. This reduces the need to publish in the OJEU, but does not avoid some of the problems with the decision points in the procurement cycle set out in Figure 8. The real challenge is to develop fast decision making and approvals through improved governance and contract negotiation.

Gateway Review Process The OGC Gateway Process examines programmes and projects at key decision points in their lifecycle through a process of peer review. The process is initiated at the request of departments and is designed to provide independent guidance to senior responsible officers, programme and project teams based on the review of documentation, and interviews with stakeholders. Success criteria vary from project to project but the review process poses questions around risk and stakeholder management, definitions of expected benefits, and relevance to existing projects and departmental goals.92

The review uses a traffic light system of green, amber and red. A green light is awarded if the project is on track, an amber light is given if the IT project should go forward, but recommended actions should be carried out before the next review, and a red light means that problems need to be fixed before moving on. The intention is to fix the problems rather than stop the project.

Considering these questions at relevant stages is intended to improve visibility of project progress and provide assurance that the project is delivering to plan.

93

The review is initiated when a government department submits a risk assessment for the project. The OGC then assembles a review team providing expertise in project management, which normally takes eight weeks to organise.

94

• The first stage provides a strategic assessment of the direction and planned outcomes of the programme.

This is followed by a planning meeting to share information, clarify the issues and confirm which stakeholders to interview. The Gateway Review Process typically has six stages.

92 Office of Government Commerce, The OGC Gateway Process: A Manager’s Checklist, April 2007 93 Arif Mohamed, ‘Do Gateway Reviews Produce Results’, Computer Weekly, May 2007 94 Office of Government Commerce, The OGC Gateway Process: A Manager’s Checklist, April 2007

72 Annex B: Procurement, contracting and the Gateway Review process

• The second stage focuses on the business case and the justification for the development.

• The third stage reviews the delivery strategy and is conducted prior to any approach to prospective suppliers or delivery partners.

• The fourth stage focuses on the investment decision where the full business case and the governance arrangements are reviewed prior to committing to funding a supplier.

• The fifth stage focuses on reviewing how ready the organisation is to go live with the project and the required business changes.

• The final stage reviews whether the desired benefits of the project are being achieved.

The staged reviews can be repeated at various points during the project lifecycle and the initial stage review is typically repeated at least three times.

There are three main challenges to using agile under this process. First, the timelines are inappropriate to agile projects. Where an agile approach focuses on providing production ready software every two weeks, the Gateway Review process will struggle to keep pace. Although the reviews themselves take a matter of days, the initial planning meeting has a lead time measured in months. Second, it rests on the assumption that there are clear ‘gates’ between different project components. For example, it assumes that a full business case can be developed prior to contracting with a supplier whereas in an agile approach there is considerable flexibility on scope to be agreed between the contractor and the department. It also assumes that the ‘go-live’ date is segmented from the rest of the development, whereas the agile approach aims to provide early delivery and integration with business processes (or realignment where necessary), and incremental development. Third, it does not provide an appropriate failure regime. As the Gateway review seeks to fix problems rather than stop projects, this runs directly counter to an agile approach, which allows projects to fail small and fail fast.

Independent, expert scrutiny is a valuable part of successful project management, but the current OGC framework imposes a significant cost on departments and uses a model that is at odds with the key principles of agile development, particularly flexibility to changing requirements and rapid delivery of a product. A project adopting an agile approach exhibits many of the qualities the Gateway Review Process espouses, including high visibility of progress and close relationships between stakeholders. While there is an important role to be played by an independent governmental review process, the Gateway process should be reviewed by the Cabinet Office to ensure that it can accommodate agile projects.

Annex B: Procurement, contracting and the Gateway Review process 73

Figure 8: The Gateway Review Process

Source: Office of Government Commerce, OGC Gateway Process Review 0: Strategic Assessment, July 2009

74 Annex B: Procurement, contracting and the Gateway Review process

Contracting Contracts aim to ensure that a transaction is fair, secure and predictable. In a traditional contract for the supply of goods and services, this is done by producing a highly detailed specification of the transaction. Where the supplier does not produce a good that meets this specification, the customer has recourse to legal action against the supplier. The intention is to limit the risk borne by the customer.

However, in an environment where it is difficult to identify, agree and articulate requirements well in advance, such detailed specification is not feasible. It can lead to costly change requests and to polarised interests when the customer is required to justify why a proposed change is within the predetermined specification. While agile development has several intrinsic features that mitigate risk for the customer (including limiting the liabilities to brief ‘timeboxed’ periods and smaller amounts of funding, delivering early so that working solutions are available sooner, and collaborative teams that increase visibility of progress), it is important to exercise careful risk management in contracting.

Some organisations have used time-and-materials arrangements with a fixed price for a set of iterations to permit the required flexibility in specification. As the customer is remunerating on the basis of cost of time, if the project is no longer delivering value further iterations do not need to be undertaken. The customer and supplier agree on the high level requirements and the process for achieving them. Sometimes quality metrics such as the number of tests completed on a product or the velocity (the rate at which the project is proceeding measured in terms of business value delivered) are agreed in the contract. By agreeing on this rate of delivery of business value the customer can be more certain that they will be receiving the outcomes they prioritise before each iteration.

There is often a ‘calibration phase’ in which the supplier establishes the velocity at which they can deliver the project by completing a set of iterations. If this is too low for the customer, the contract can be terminated. This sets a benchmark that the team is expected to meet in each subsequent iteration. To incentivise increased velocity, financial incentives can be used for early delivery. The contract might be described as fixing the capacity for delivery of business value, where this is agreed before the project begins. The effectiveness of this contract relies on the customer being able to measure the progress of the project and sanctions being able to be brought against a supplier violating the defined rate of progress. An additional method of mitigating risk is to use test-driven development, which means that the product is fully tested throughout its development.95

95 Rather than extensive documentation alone, there is a working system with the criteria for operation embedded in it. The consequences of changes are easily seen because they will trigger test failures – this makes changes easier to enact but means that other suppliers can quickly understand a system and build on it.

Annex B: Procurement, contracting and the Gateway Review process 75

A further strategy to mitigate risk is by ensuring that alternative contractors are available to complete work. Multi-supplier arrangements can be used to ensure that each contractor can take over should one underperform. It is also useful to build skills transfer into projects. In some arrangements, suppliers are incentivised to up-skill the staff at the customer organisation. This helps to ensure that the customer is able to conduct and supervise projects in the future.

76 Annex C: Case studies

Annex C: Case studies

The case studies reviewed for this report come from a range of different industries dealing with highly complex issues, different regulatory requirements and a changing technology landscape. In several cases, the organisations have used multi-supplier arrangements with some using external developers.

This review demonstrates several points. First, agile development can produce significant gains. As a senior manager at Centrica, points out, “[T]he benefits of this change can improve delivery performance, in terms of cost, quality and speed, by a factor of 20.”

Second, agile is often rolled out with the support of a broader structural change and requires a cultural change within the organisation for the benefits to fully take hold. At a large media company, a more sophisticated charging mechanism incentivised the business units to focus on their priorities more closely, which was itself aided by an agile approach. At Napp Pharmaceuticals, boards have actively encouraged a culture of empowerment through the use of rapid decision making, often via email.

Third, the use of agile can unravel without leadership and strong central support. At both a FTSE 100 and a global universal bank, centres of excellence have been created to provide support, coaching and training for agile projects. At a large government agency, an investment review process has been adopted that provides seed-funding for smaller scale projects with less specification in order to demonstrate success earlier. Perhaps the most important message coming from these case studies is that the principles of modularity, incremental delivery, experimentation and active user involvement can be applied across virtually any IT-related business problem.

These case studies are based on interviews with senior managers in the organisations. In some cases, the organisations requested anonymity for commercial reasons.

Case Study 1 A large government agency

Case Study 2 A large manufacturing organisation

Case Study 3 Ministry of Defence with General Dynamics

Case Study 4 Napp Pharmaceuticals

Case Study 5 A large media company

Case Study 6 A FTSE 100 Bank

Case Study 7 A major international bank

Case Study 8 Centrica

Annex C: Case studies 77

Case Study 9 Guardian News & Media Ltd

Case Study 10 Operation Amberhill

Case Study 11 Department for Work and Pensions

Case Study 1: A large government agency

What the organisation says: “The approach is radically different to a waterfall based project management methodology. On an individual/team level – The intense and forced ‘closeness’ of an Agile approach quickly forges an effective and motivated team. Self-managing teams increase accountability and the focus moves people past the need to ‘word smith’ and finalise requirements catalogues, moving the project away from long, onerous and valueless signoff loops. From a customer perspective – the customer sees rapid results, and is involved with what the project will deliver. They are part of the team rather than an outsider. Discussions around what will be delivered by when (scope) are much easier to facilitate as they are based on fact. Faith and trust is built between the customer and the delivery team, Agile creates a ‘we are in it together’ attitude rather than the traditional business versus delivery team model that waterfall sometimes promotes.”

Situation

Organisation description: • An executive agency and non-ministerial department with more than 1000 staff.

Challenges: • Decision makers were unable to reach agreement on the full set of requirements for

a large scale project to create a comprehensive online ordering system. While 80% of the requirements were uncontested, the gateway process required a full set to be agreed prior to development. This process continued (on and off) for a period of four years and cost over £1 million, resulting in little usable outcome.

Objective: • To demonstrate that it would be possible to deliver all business products online by

using an agile development approach.

Transition Selection of methodology:

• The failure of the traditional waterfall approach provided an impetus for a new methodology with high-level support. With the assistance of an industry expert the organisation carried out workshops to develop familiarity with the new approach and gain enrolment from key stakeholders.

78 Annex C: Case studies

Implementation: • Initially a seven person team began work on the project and within three months this

team doubled in size. The industry expert supported the delivery team throughout the project.

Barriers: • The major technical challenge has been the infrastructure elements to the project

which traditionally have very long lead times on purchasing and implementation (when compared with rapid two week iterations).

• There was significant difficulty in initial iterations with defining ‘user stories’ as there was a strong culture of everything needing to be 100% correct and agreed by everyone before it could be progressed to the next stage. This applied equally to business and technical resource; it took six to seven iterations (about three months) to get over this difficulty as trust was built in the team and the approach.

Impact • Agile provided a working platform for a total cost of about £650k: less than the cost

of the incomplete requirements document in the old process.

• The project has acted as one catalyst for a broader culture change where the business has adopted agile principles such as incrementalism, prioritisation, lean thinking and rapid delivery of flexible products and services. To date, only one project has adopted a fully agile approach, with around one-third of major projects now using some aspects of agile.

• At an organisational level, the agency now has a well formed and capable project team, which can easily adapt and quickly reprioritise and plan much more effectively than in a waterfall based approach. This means the team can take advantage of new opportunities identified or evolve its solutions based on problems encountered or new and emerging business requirements.

• Budgeting and governance processes within the organisation have changed to accommodate and encourage more agile projects in the future – for example through incremental investment approval. The new investment approvals process involves obtaining early permission to fund development immediately without a fully specified business case being approved, although a robust justification must still be provided. The project is given permission to spend at a particular rate over a period of time. The projects will return to the Investment Board at specified intervals for further ongoing approvals and to update on progress.

Annex C: Case studies 79

Case Study 2: A large manufacturing organisation

What the organisation says: “It is an exciting, stressful, inspirational and rewarding way to work that really ‘fired up’ the team members who wanted to be there, owned the problem and cared about the solution, had an unfailing ‘can do’ attitude, wanted to deliver for the team not for themselves, and relied mainly on peer pressure and peer support. It was a real change in culture.”

Situation

Challenges: • A large group of stakeholders found it difficult to articulate requirements and the

extended circulation of documents to develop specifications caused delays.

Objective: • To introduce a method of working on a business solution that avoided the delays and

costs associated with formulating up-front requirements and subsequently changing them.

Transition Selection of methodology:

• The repeated underperformance of the traditional methodology encouraged the organisation to adopt an agile methodology for a project involving more than 100 people in several countries for several years and involving two other companies. The project accounted for 15% of the entire IT spend.

Implementation: • In order to encourage buy-in, the organisation drafted its own version of an agile

methodology through the use of workshops and with the support of independent consultants, using champions to support it. Industry consultants provided coaching for 12 months.

Barriers: • The culture change required effective communication, engagement and discussion to

build understanding and buy-in. Drafting company-specific versions of the method took time, but increased buy-in from the organisation.

Impact • The organisation now finds itself delivering what it said it would, when it said it

would, on major transformation projects enhancing IT support. This has changed business processes, allowing a collaborative but controlled definition of requirements and benefits that deliver reliable, thoroughly tested products.

80 Annex C: Case studies

• Technological decisions are made early in order to ease implementation and they are treated as part of the context the project operates in.

Case Study 3: Ministry of Defence with General Dynamics

What the organisation says: “The chief difference between a DSDM (agile) approach and a ‘traditional’ project is the explicit acceptability of failure (fail early) and the flexibility (within clearly defined limits) of what the final outcome will look like. The biggest single mind-set change is the denial of ‘slip’ in delivery dates, preventing the traditional engineer’s mindset of ‘just a little more time will do it.”

Situation

Organisation description: • The MoD’s Defence Equipment and Support is responsible for spending £14bn

annually to acquire and develop equipment and services, including ships, aircraft, vehicles and weapons, information systems and satellite communications.

Challenges: • The Defence Acquisition Change Programme (DACP) highlighted the fact that

threats facing the military require greater agility and responsiveness and that there is an increasing divergence between MoD and commercial technology cycles, resulting in obsolescence and undermining innovation. It was therefore important to reduce the length of acquisition cycles.

Objective: • To deliver a £3m system to integrate the land, sea and air communications for

combat operations through a multi-supplier arrangement.

Transition Selection of methodology:

• Agile was identified for pilot application by the DACP designed to bring about a radical improvement in acquisition performance.

Implementation: • The approval of the change programme gave the project the backing of the corporate

centre. As project participants had no prior experience with the agile approach, short training courses were undertaken and a facilitator from Keith Richards Consulting provided coaching.

Annex C: Case studies 81

Barriers: • Establishing a common understanding of the nature of agile was complicated by the

involvement of four separate organisations.

• A technologically closely related project was subject to a higher degree of financial and risk scrutiny than the monetary value warranted because of the lack of perceived assurance in the agile methodology. The project involved four separate organisations and the contract specified a limited number of high-level requirements, increasing risk exposure. The MoD ultimately had to rely on developing a high quality, collaborative relationship with suppliers to provide assurance that the contractors would continue to deliver functionality beyond the bare contractual minimum.

Impact • The project was delivered on time to cost and budget. It demonstrated that agile can

be successfully applied to a collaborative, multi-organisational project to deliver a technically complex military capability and required more customer involvement than usual.

• The lead contractor, General Dynamics, now uses agile development techniques for its internal IT capabilities.

Case Study 4: Napp Pharmaceuticals

What the organisation says: “There has to be the right culture for Agile, or Iterative development to succeed. This is from all sides. There has to be a culture of taking responsibility and not being afraid to make decisions, but understanding when the decision may be out of your sphere of control. Project Boards, when they need to make decisions, must make them quickly without undue delay or bureaucracy (quite often these will be done via email).”

82 Annex C: Case studies

Situation

Organisation description: • Napp Pharmaceuticals is a pain medication company with sales exceeding £100m

and a staff of around 1,000.

Challenges: • The previous processes employed at Napp were unwieldy and bureaucratic. Users

were not adequately involved in the software development phase of projects and this led to requirements being misunderstood and the wrong systems being delivered.

Objective: • To introduce iterative development while maintaining the control and project

management appropriate to the organisation and a highly regulated industry.

Transition Selection of methodology:

• While agile had been introduced and promoted by a senior manager in the IT department it did not provide a full set of benefits until a set of organisational changes were introduced.

Implementation: • DSDM (agile) was introduced in an iterative way. The initial step was to separate the

project management method from the software development lifecycle. A light version of the PRINCE II project management framework was introduced that could be used on all projects, whether they were IT or pure business projects. Next, the organisation started introducing agile and DSDM techniques, particularly close collaboration, communication and interaction with the business users throughout the project. Iterative development (where solutions prototypes were developed and early feedback gathered) was applied. This allowed the team to converge on the right solutions and they gradually fixed time available so that only those requirements that would add value were developed. This was also dependent on the right project portfolio process – the organisation runs a quarterly process where all project requirements are assessed and reviewed and resource is assigned for a three-month period. So what may have been a large project in the past becomes a series of small projects.

• Where project boards need to make decisions quickly, this is often done via email.

Barriers: • This approach requires a lot of input from the business users throughout the process

and also requires the project team to be disciplined in terms of ensuring that only the items that add business value will be developed and that there is no scope creep. The projects also require a lot of commitment and energy from those involved.

Annex C: Case studies 83

• The business users have had to understand that they may not get everything they originally asked for and that there is a time limit on the project. Normally this is self-fulfilling as they are seeing the solution development constantly and they realise what they originally wanted is actually not what they need today.

• The stakeholders have to understand that they may not get the status of the project in the same way – there is not a rigid plan that is being followed, rather progress is measured by how much (potential) business value has already been created. Normally the fact that they can see a working system gives them sufficient confidence. They also have to let the project team ‘get on with it’ and not interfere too much. Again, the trust is built by the solution being visible early on and throughout.

Impact • The systems implemented now meet users’ needs more fully than before and these

business users have become ‘ambassadors’ for the IT department by requesting additional work from them. The internal IT team are becoming the supplier of choice, whereas previously the users may have looked for solutions outside the company.

• The relationship between the IT department and the business improved, with a greater degree of mutual trust.

• The focus on business value has increased efficiency as effort is more concentrated around what is needed.

Case Study 5: A large media company

What the organisation says: “Whilst the company was coming from a chaotic rather than a formalised approach such as PRINCE2, the agile approach was very different and has transformed the reputation of the central department that develops and manages the web sites for all brands within the company. Benefits include faster turnaround, stronger business relationships, better products (more appropriate features for the users), better quality, reduced risk on projects, better reputation for delivery, and as a result more visitors to our web sites and higher revenues.”

Situation

Organisation description: • The company has an annual turnover of £400m and a highly decentralised structure

with each of 60 brands setting their own priorities and having control over profit and loss.

84 Annex C: Case studies

Challenges: • It is a fast moving organisation in a rapidly changing digital market. IT development

was undertaken in an unstructured and ad hoc manner resulting in delays, poor visibility of project progress, unclear priority setting and significant disruption to websites.

Objective: • Agile was intended to align the IT department with business units to provide a quick,

lightweight way of prioritising, collaborating on, and managing tasks.

Transition Selection of methodology:

• A senior manager with prior experience using agile had been appointed to the IT position and advocated its use. It was introduced to organise the IT delivery that was characterised by chaos and a lack of structure.

Implementation: • Agile was implemented across the organisation’s web-development projects

alongside a more fine-tuned charging system. Development teams are organised around key products and are multidisciplinary and co-located. A business user works within the teams to set priorities and assist development.

Barriers: • The first three months of the transition resulted in complaints due to the fast paced

change. Organisational issues such as co-location and cultural factors around openness to change were overcome by open communication and demonstrated success.

Impact • Website traffic has doubled and the cost of development has almost halved, from

£5.5m to £3.5m. Other benefits include faster turnaround, stronger business relationships, better products (more appropriate features for the users), better quality, reduced risk on projects, and better reputation for delivery. Better company websites have attracted more visitors and resulted in higher revenues. The close relationship between the central IT department and the business units (which pay for the centralised services such as hosting, development and applications) allows brand teams to design their websites without having to ‘reinvent the wheel’ each time.

Annex C: Case studies 85

Case Study 6: A FTSE 100 bank

What the organisation says: “‘The Agile methodology welcomes change and accepts it. It doesn’t encourage or look for it but recognises it as ‘part of the process of delivery’. The business greatly values this aspect. They also enjoy having complete control as to what is being delivered from Sprint to Sprint. The benefits have been enormous, consistent delivery, early warning of issues, flexibility of approach and more resilient testing.”

Situation

Organisation description: • The global bank has a multibillion pound annual turnover with several thousand

offices in numerous countries.

Challenges: • Faced with an increasingly turbulent environment the bank wanted to explore new

avenues of project management with particular emphasis on increasing its ability to deliver.

• It was not uncommon to have a set of consultants or a business analyst write long documents detailing system requirements. These documents relied on the unrealistic assumptions that business could fully articulate requirements in a static environment.

Objective: • To improve delivery (and being seen to deliver consistently) was the principal driver

for this change.

Transition Selection of methodology:

• A multimillion pound project to handle trades processing was selected to pilot the agile approach with a number of interfaces and integration challenges.

Implementation: • A small team with agile experience was recruited to run the initial project. A central

unit has been set up to support agile projects within the company by offering mentoring, training, resources and tools.

86 Annex C: Case studies

Barriers: • There was a ‘healthy scepticism’ about whether this new approach would work

because it was radically different from the traditional method. Its success has led to further adoption of agile and a need to maintain the agile ‘brand’ by providing training and accrediting agile projects.

Impact • The benefits have included consistent delivery, early warning of issues, flexibility of

approach and more resilient testing.

• At least eight multimillion pound projects are being run using agile methods, with many others in the pipeline.

Case Study 7: A major international bank

What the organisation says: “Adoption of Agile thinking in our delivery approach is allowing us to plan in a more structured way, but also allow our plans to be dynamic with a greater level of discipline and visibility with respect to requirements, estimation, prioritisation, acceptance and deployment.”

Situation

Organisation description: • The major international bank employs over 80,000 people worldwide with an annual

turnover of approximately £25bn.

Challenges: • The bank works in a highly fluid environment, and had used a very ad-hoc approach

to planning and delivery with design, acceptance and deployment managed in an unstructured way, causing volatility in requirements.

Objective: • To structure planning in a dynamic environment allowing IT to provide better

support to business priorities.

Transition Selection of methodology:

• Agile is being adopted as the delivery approach for a strategic risk calculation platform used by front office, middle office, regulatory and back office finance teams. It is globally deployed across multiple locations and lines of business.

Annex C: Case studies 87

Implementation: • An Agile Centre of Excellence has recently been set up to support this initiative

across the bank. Much of the focus is ensuring in the first instance that project teams have permission to utilise agile practices, and backing this up by building a coaching and mentoring network across the organisation made up of both internal and external coaches. The other key area of support is providing teams with a catalogue of resources which teams and individuals can draw on.

• Within the risk system development group itself, support has been given to hiring experienced practitioners and the adoption of an agile delivery approach is supported at a senior level.

Barriers: • The increased volume and frequency of conversation with business users has been

challenging.

• A very siloed approach to roles and responsibilities has led to requirements often being ‘thrown over the fence’ to development teams, resulting in a high number of ‘requirement defects’ found during acceptance testing. This is being resolved by encouraging teams to work as a group during design and planning workshops to ensure understanding of both requirement and acceptance criteria are shared at an earlier stage in the lifecycle. Estimation is also designed to be a transparent and shared process. Teams have had instruction on facilitating this process.

• Working with offshore teams has proved a challenge but ensuring the teams spend time physically together both in the UK and abroad has been helpful in improving a shared understanding of requirements, design and plans.

Impact • The transition to an agile way of working is at an early stage, but has improved the

speed of decision making and prioritisation across stakeholder groups. The organisation expects to reduce deployment time by 25–50%.

Case Study 8: Centrica

What the organisation says: “The approach is very different for an organisation, since it requires a fundamental change in emphasis, from long-range forecasting to rapid delivery with rapid feedback from users of the software. Most organisational governance strives to improve prediction, whereas Agile governance strives to improve value for money and speed of delivery. The benefits of this change can improve delivery performance, in terms of cost, quality and speed, by a factor of 20.”

88 Annex C: Case studies

Situation

Organisation description: • Centrica is a utilities company with an annual turnover of £22bn and in excess of

25,000 employees.

Challenges: • Centrica required faster time-to-market in its IT development than its governance

process would allow.

Objective: • To improve delivery of software, while reducing costs and time-to-market by moving

away from long-range forecasting to rapid delivery with rapid feedback from users of the software.

Transition Selection of methodology:

• The IT Director began running IT projects using agile principles in parallel to the traditional waterfall method.

Implementation: • While operating two simultaneous approaches for IT projects, the agile approach

outperformed the traditional method and was quickly adopted across the organisation.

Barriers: • The cultural legacy was the greatest barrier; internalising agile values was difficult

without experiencing the methods and suggests why senior managers are often more reticent than developers. Management of risk is a major concern, so good communication was necessary to resolve this

Impact • The change to agile has reduced delivery times in some cases from six to nine

months down to about eight weeks. The objective is to move even further so that teams are delivering in weekly increments.

• After a successful 12 months of using agile, the organisation continued to face internal pressure to use more traditional techniques involving greater documentation. It is now undergoing a process to ensure teams are using agile principles fully, partly by educating business stakeholders about the key benefits.

Annex C: Case studies 89

Case Study 9: Guardian News & Media Ltd

What the organisation says: “We introduced agile development in 2003 because the business was emerging from a particularly difficult and lengthy project, and [we] believed there ought to be a better way to do things. It has resulted in much more interaction between technical and non-technical stakeholders, both during the planning and during the development, providing greater trust that the business will get what they want. Overall, there is a much greater appreciation of roles and responsibilities across functional boundaries.”

Situation

Organisation description: • The Guardian News and Media (GNM) group owns the Guardian newspaper, the

Observer, the Guardian website, the Guardian Weekly and a number of business-to-professional services. The Guardian website is the second most popular UK newspaper website, with almost 34.6m unique users each month.

Challenges: • The business was emerging from a particularly difficult and lengthy project that had

a high level of specifications and limited return on investment, and believed ‘there ought to be a better way to do things’.

Objective: • To trial a new approach to development. The first agile work was on small

operational tasks, which then expanded into projects as confidence emerged. In 2006 the team embarked on their most significant project to date, focused first on redesigning the ‘Travel’ section and then the entire website.

Transition Selection of methodology:

• This was initiated by bringing in a new development manager heading a new body given freedom and responsibility to find a better way of working.

Implementation: • The editorial teams were asked to provide ‘a thousand tiny wishes’ that could more

easily be prioritised rather than ‘one big wish’. The initiative started with a lot of formality in 2003, and ramped up as confidence and understanding grew to a very rigorous approach in 2006–2008. The second part of the project involved using 104 people at its peak, with nine major launches, and working software released every two weeks. GNM is now much less dogmatic about the approach but maintains the core benefits.

90 Annex C: Case studies

Barriers: • Project managers were most resistant initially as they perceived loss of control, but

were largely told to run with it, and came to understand they were able to focus on the much more meaningful work of aligning the multiple technical and non-technical issues, while entrusting a lot of the development issues to the developers.

• Understanding among (mainly) the development team and others about how to run agile projects effectively was challenging. This process included educating users about unit testing, how to write good tests, how to pair-programme effectively, and how to plan. This was overcome partly by continually reflecting and changing, and making sure everyone could contribute to process improvement, and partly at one stage by bringing in skilled external practitioners to help deliver a particularly large project and enhancing internal skills. The skill-enhancing was an explicit part of the contract with one of the suppliers.

• The Corporate Centre was helpful in ensuring that key non-technical stakeholders from around the business could devote significant chunks of their time (and in many cases 100% of their time) to working alongside the technical people as integral parts of the team.

Impact • Almost all digital web projects use some kind of agile approach, which constitutes

about 70% of development activity within GNM by spend. Other (more enterprise/corporate) projects use some elements of agile.

• The result has been much more interaction between technical and non-technical stakeholders, during both the planning and the development phases. There has also been much lighter documentation, and non-technical stakeholders are able to delay decision-making and change their mind much later than before, resulting in much greater trust that they will get what they want. There has been more focus on business deliverables, much earlier visibility of results and much more confidence among developers that they will be able to do a good job technically. There has been a greater appreciation of across functional boundaries of each others’ roles and responsibilities.

Case Study 10: Operation Amberhill

What the organisation says: “It is clear that for the right project the ‘Agile’ method delivers success at a quick pace. However, the level of commitment required by all involved in the process will be integral on deciding whether this process will be effective. It is equally important that the correct individuals are identified at the earliest possible stage; this will mean that delays are kept to a minimum and will facilitate the decision making and development of the end product.”

Annex C: Case studies 91

Situation

Organisation description: • The Metropolitan Police Service is responsible for the safety of Greater London with

52,000 employees and annual expenditure of £3.5bn. Project Amberhill is part of the Metropolitan Police Service strategy to prevent and detect economic and specialist crime. The unit of 12 people analyses hard drives and discs of data from seized computers, printers and other IT hardware recovered from identity document factories. The false identity data is extracted and documents that may have been produced while the ID factory was in operation are captured. The likelihood is that these documents are in circulation across the UK. The false identity data is collated on a database and shared with the public and private sector via statutory intelligence gateways and bespoke information sharing agreements. The database is downloaded onto the Metropolitan Police Service Criminal Intelligence System and can also be checked by non MPS forces via their Force Intelligence bureau.

Objective: • To build and pilot a solution using agile development. The approach looked at the

reuse of existing systems which might provide solutions.

Transition Selection of methodology:

• The initiative was part of a short research project being undertaken by the Home Office’s Office for the CIO with the Institute for Government and agile consultancy Indigo Blue.96

Implementation:

The project was exploring how an integrated project team that uses rapid prototyping and user involvement could deliver a programme as part of a broader policy agenda. The policy issue was how to reduce fraud related to the use of genuine, but fraudulently obtained, identity documents. Development focused on the database Amberhill uses to collate and share fraudulent identity documentation.

• Following discussions and working closely with the team at Amberhill an expansive list of features was created and prioritised to focus on delivering a production system that could provide immediate business value without requiring all the requirements to be implemented. This initial delivery would enable multi-user data capture and eliminate the manual management of data collated on spreadsheets.

• The longer term incremental deliver strategy included additional requirements which were placed on the backlog.

96 IndigoBlue Consultancy Ltd is an independent consultancy specialising in large scale agile adoption.

92 Annex C: Case studies

• Requirements that did not relate to the initial delivery of core data entry, query and extract process were excluded from the detailed analysis and immediate development prioritisation discussion.

• Two week development cycles were set up with the intention of delivering the initial version of the software after four iterations.

• Prior to each iteration an analysis session was held with the Amberhill stakeholders. The purpose of these was to think through the next set of priorities and document the user requirements that would be considered for further planning.

• At the start of each iteration a planning session was held where the user stories were reviewed and the estimates on the stories and available development resource were considered. User stories were selected collaboratively by Amberhill, the development team and the Home Office.

• The next two weeks focused on implementing the selected user stories and building appropriate automated regression tests. This approach ensured that the impact of future change could be identified during the automated test and build process. Regular conversation with the Amberhill stakeholders enabled IndigoBlue to build test cases and clarify uncertainty over requirements.

• At the end of the two weeks, the developed software was demonstrated to stakeholders. Feedback and changes that were identified were agreed and incorporated into the selection of user stories for the next iteration.

Barriers: • The project demanded increased business involvement, which placed pressure on the

business users to juggle the requirements of the project on top of their day to day work load.

• As decisions needed to be made very quickly certain issues needed to be escalated further up the chain of command (e.g., data for sharing for experiment purposes, installation and service costs) and this had resulted in some minor delays.

• The speed of this project has managed to get a number of partners interested and committed, however a number of preconceptions related to the inability of organisations to share data across the public sector remain. The next stage of the process is to manage the database and show individuals the benefits and values of a joined-up system of information sharing between numerous organisations in the public sector.

• Deployment of the system onto the MPS network was initially thought to be highly costly and a timeline of six months was envisaged. However, given the state of readiness and strong business demand for its deployment, a work-around solution was developed by providing a four-computer network to host the application. At the

Annex C: Case studies 93

same time, the IT department is aiming to deploy the database onto the network under the normal processes following a longer timeline.

Impact • A fully system-tested web based application backed by an Oracle 11g database was

completed following four development iterations. It is expected that the application will reduce data entry and Quality Assurance times by 50% and eliminate the manual management of multi-user data entry across multiple spreadsheets. The data quality has been dramatically improved and the ability to generate extracts of data for third parties has been simplified.

• The deployed application enables the generation of a single spreadsheet per operation of data, which can be processed by researchers according to the current business processes.

• The project has been considered a great success by the stakeholders and further iterations are now planned.

• The Metropolitan Police Service felt there was progress much sooner than they had anticipated. One team member said, “the progression of the project is startling”. There was widespread enthusiasm for the results achieved to date, with one team member pointing out, “while this is an agile startup – this could go nationwide”.

• Pleased with the success, one of the business users stated, “In 25 years service I have never known a project to develop at such a startling rate. This is even more impressive when you take into account that all decisions have been made in [a] calm and considered manner with no less importance being given to every stage, in spite of the time restraints.”

Case Study 11: Department for Work and Pensions

What the organisation says: “By adopting an agile development approach, it has reduced the time it will take to deliver Universal Credit by almost half. Three key principles have guided our approach to delivering business benefit early: cooperative working through breaking down barriers, early integration through better dependency management and lightweight but proportionate governance.”

Situation

Organisation description: • The Department for Work and Pensions (DWP) employs around 80,000 people and

delivers benefits payments totalling £90bn per year.

94 Annex C: Case studies

Challenges: • The traditional approach to project management at DWP – ‘Business Change

Lifecycle’ (BCL) – is slow and cumbersome, and relies on a large number of deliverables that do not contribute to the final product.

Objective: • DWP was tasked with moving a specific type of benefit, Jobseeker’s Allowance (JSA),

from paper and counter-based services towards web-based delivery. This project required 80% of the benefits to be put online prior to a 50% channel switch from face-to-face contact. Savings would be generated by reducing processing times associated with face-to-face contact and telephony channels. As a result, the project was very time sensitive.

Transition Selection of methodology:

• There was recognition that the traditional approach would not deliver the outcome in the timeline available. DWP sought to utilise an approach that had lighter governance, more cooperative working and iterative development.

Implementation: • The senior management in the department was supportive of the approach and a set

of six eight-person teams, known as ‘Tiger Teams’, were set up to be integrated, multi-supplier, and multi-organisational, with all of the expertise required. They are co-located, work together daily, and share common goals towards clearly defined outputs and dependencies defined at the outset. This focuses the team towards achieving outcomes. The number of documentation deliverables (such as the IT service management strategy, the IT build strategy and the usability and accessibility compliance checklist) has been reduced by approximately two-thirds. The design and build process is not restricted to IT development but includes business products such as guidance and learning and development. An overarching business and solution architecture Agile Steering Group (ASG) provides coordination between agile teams and maintains the forward look of the operating model and IT solution.

Barriers: • A culture of empowerment had to be established around the project. A senior

manager had told teams, “if you make a decision and fail – I will take responsibility, however, if you make a decision and succeed – you claim the credit”. This process resulted in an increase in the number of decisions taken by teams and a greater level of empowerment.

Impact • The initial JSA project will not conclude until late 2011 but the organisation appears

to be on track to reduce the time to market by six months compared with the traditional waterfall BCL approach.

Annex C: Case studies 95

• The methodology is being used for the development of Universal Credit and the DWP expects this to cut delivery such that this major social initiative can be delivered and go live within the 2010 Spending Review period and the term of the current Administration.

96 Annex C: Case studies

Annex D: Survey of Public Sector CIOs

As part of the research for this report, the Institute for Government conducted an online survey of members of the government’s CIO Council.97

The response rate was 72% (18 out of 25 CIO council members completed the survey).

The aim of the survey was to solicit CIO views on how ‘tightly’ or ‘loosely’ elements of government IT should be controlled and the extent to which agile principles are already being used.

97 The sample was drawn from the Public Sector CIO Council and includes Birmingham County Council, Business Innovation and Skills, Crown Prosecution Service, Department for Children Schools and Families, Ministry of Defence, Department of Health, Department for International Development, Hampshire County Council, Ministry of Justice, MoJ National Offender Management Service, National Policing Improvement Agency, Metropolitan Police, Northern Ireland Civil Service, Office for National Statistics, Her Majesty’s Revenue & Customs, Scottish Executive, Department for Transport, Welsh Assembly Government, Department for Work and Pensions, DWP Group Applications Director, Driver and Vehicle Licensing Agency, West and Chester and Cheshire East Council, Environment Agency, Department of Communities and Local Government, and the Department for Environment and Rural Affairs.

Annex C: Case studies 97

Q1. Francis Maude has said government has to get the ‘tight–loose balance’ right. Where do you think the balance should lie in each of the three areas below?

Greater control & mandation

Greater coordination

Balance should remain

the same

Greater devolution of power &

responsibilities

Don't know

Specialist: Customised product or service specific to one organisation (e.g., car tax disc and vehicle licensing, non-commodity layers of the benefits processing system, user interface design)

0 (0%) 2 (11%) 9 (50%) 7 (39%) 0

Sector: Product or service used by a cluster of related organisations with minimal customisation. The cluster adopts common standards for some key areas (e.g., electronic patient records, school administration system, financial modelling tools).

2 (11%) 12 (67%) 1 (6%) 3 (17%) 0

Standard: Product or service used ubiquitously across organisations with minimal surface level customisation. The same open standards are used by all wherever practicable (e.g., low tier storage, HR & amp, payroll, office software, non-specialist PCs).

13 (72%) 3 (17%) 0 (0%) 2 (11%) 0

98 Annex C: Case studies

Q2. Please list up to three key areas in government IT where you feel there should be more coordination or mandation to drive greater efficiencies

Departments were invited to give free text responses, which have been coded.

Number of responses Percentage

Data centres

7 19%

Common standards

7 19%

Commoditisation

7 19%

Infrastructure (PSN)

5 14%

Shared (back office) services

4 11%

Others

6 17%

Total 36

Annex C: Case studies 99

Q3. Please list up to three key areas in government IT where you feel there should be greater devolution to a departmental or project level to enable innovation and flexibility

Departments were invited to give free text responses, which have been coded.

Number of responses

Percentage

Operations specific

8 28%

Procurement around SMEs 5 17%

None

3 10%

Security – specifically around mobile devices

3 10%

Others

10 34%

Total 29

100 Annex C: Case studies

Q4. From each pair of statements, please select the one which most closely reflects the working practices of your department

A Strongly reflect A

Slightly reflect A

Neutral Slightly reflect B

Strongly reflect B

B

Project teams are co-located to enable informal interaction

3 (17%) 7 (39%) 3 (17%) 4 (22%) 1 (6%)

Space for teams to work independently with structured communication between them

Core functionality is delivered early to introduce system as quickly as possible

1 (6%) 8 (44%) 2 (11%) 7 (39%) 0 (0%) Project is delivered when it is fully functional to promote take-up by users

Users are part of the core project team

4 (22%) 3 (17%) 1 (6%) 6 (33%) 4 (22%)

Professional, clearly delineated, client–provider relationship between IT and users

Project responsive to changes in specification

0 (0%) 7 (39%) 6 (33%) 4 (22%) 1 (6%)

Specification adhered to, ensuring consistency with, and facilitating integration into, other systems

Understanding of the required solution changes over time

0 (0%) 5 (28%) 3 (17%) 5 (28%) 5 (28%)

Project works to a well-defined brief and the team delivers the agreed solution

The project is run in short, time-boxed iterations

1 (6%) 3 (17%) 4 (22%) 5 (28%) 5 (28%)

The project is run in stages defined at the outset by the activity conducted in each

The project can easily be stopped at any point 1 (6%) 2 (11%) 8 (44%) 6 (33%) 1 (6%)

The project has the security of a full and committed timeline necessary to enable planning and delivery

The project team are empowered to make decisions

0 (0%) 1 (6%) 3 (17%) 7 (39%) 7 (39%)

Decisions are made with the full buy-in of the project’s stakeholders and follow clear governance processes

Annex C: Case studies 101

From each pair of statements, please select the one which most closely reflects the working practices of your department

A B

Decisions are made with the full buy-in stakeholders

The project has a full and committed timeline

The project is run in stages defined at the outset

The project works to a well-defined brief

Specification adhered to, ensuring consistency

Professional, clearly delineated, client-provider relationship

Project is delivered when it is fully functional

Space for teams to work independently

0% 20% 40% 60% 80% 100%

Project responsive to changes in specification

Understanding of the required solution changes over time

The project team are empowered to make decisions

Core functionality is delivered early

The project is run in short, time-boxed iterations

The project can easily be stopped at any point

Project teams are co-located to enable informal interaction

Users are part of the core project team

Strongly reflect A Slightly reflect A Neutral

Slightly reflect B Strongly reflect B

The Institute for Government is here to act as a catalyst for better government The Institute for Government is an independent charity founded in 2008 to help make government more effective. • We carry out research, look into the big

governance challenges of the day and find ways to help government improve, re-think and sometimes see things differently.

• We offer unique insights and advice from experienced people who know what it’s like to be inside government both in the UK and overseas.

• We provide inspirational learning and development for very senior policy makers.

We do this through seminars, workshops, talks or interesting connections that invigorate and provide fresh ideas. We are placed where senior members of all parties and the Civil Service can discuss the challenges of making government work, and where they can seek and exchange practical insights from the leading thinkers, practitioners, public servants, academics and opinion formers. Copies of this report are available alongside other research work at: www.instituteforgovernment.org.uk March 2011 © Institute for Government 2010 2 Carlton Gardens London SW1Y 5AA Tel: +44 (0) 20 7747 0400 Fax: +44 (0) 20 7766 0700 Email: enquiries@instituteforgovernment.org.uk The Institute is a company limited by guarantee registered in England No. 6480524 Registered Charity No. 1123926