Good Governance - effective use of IT

Written evidence submitted by IBM (IT 59)

1. Executive Summary

1.1 IBM welcomes the opportunity to submit this discussion paper to the Public Administration Select Committee (PASC), to be taken into consideration as part of the report "Good Governance: the effective use of IT". There are a great many excellent examples of good practice in IT in Government, many of which IBM and our business partners, including UK based small to medium enterprises (SMEs), are delighted to be involved in. Our experience of these successes informs our views on how Government, and the IT supply industry, could improve the use of IT in future.

1.2 In this document we highlight some of the main inhibitors to the effective use of IT in Government and we make proposals as to how the current situation might be improved. The areas identified are:

- Project initiation

- Contracting approach

- Appropriate methodology

- Collaboration and reuse

- Benefits realisation

1.3 For improvements to the current situation to be made, conditions need to exist that provide the necessary motivation for those impacted to undergo the discomfort of change. We believe that the current economic circumstances may create greater motivation to change than has been seen to date. We hope that the PASC’s report will be influential in helping Government seize this opportunity.

2. IBM background

2.1 IBM is a globally integrated technology company which operates in over 170 countries. Founded in 1911, we celebrate our centenary this year. In addition to being the world's largest IT and consulting services company, we are a global business and technology leader, innovating in research and development to shape the global future technology, business and broader landscape across society. In 2010, IBM filed nearly 6,000 patents in the US, leading the list of patent winners for the eighteenth consecutive year. We bring our researchers, technologists and business consultants from around the world to partner with governments, corporations, thinkers and implementers to solve real world problems, to help make the world work better and to build a ‘smarter planet’.

2.2 In the United Kingdom we have over 20,000 employees, bringing innovative solutions to a diverse client base to help solve their most challenging business problems. We work in partnership with the UK Public sector, at a national and local level, to help respond to challenges by applying commercial best practice, industry standard technologies, and world leading research and innovation, combined with decades of experience in the public sector.

3. Project Initiation

3.1 We believe that the cause of many underperforming public sector programmes may be rooted in the activities prior to any engagement with possible delivery suppliers. Often Government policy is defined without consideration of how best it could be implemented and how the costs of any enabling technology support could be reduced. Once policy has been decided, the areas of requirements definition and procurement governance are key to eventual success. The quality and appropriateness of the work completed in these areas has significant impact on the implementation of the programme and on the chances of the successful delivery of the envisaged operational benefit.

3.2 Governance

3.3 It is important that the correct governance for a programme is set up during project initiation. It is entirely reasonable to develop the delivery governance during the procurement, with input from suppliers. However, if, during initiation, governance is not put in place to allow the operational team, rather than the procurement function, to have overall control of the procurement there a danger that the procurement becomes a "slave to the process". While there is a need to adhere to the OJEU procurement regulations, the target must be to address the operational need.

3.4 As we have seen following the outcome of the General Election in 2010, the operational need can change substantially during the life of a procurement. In our experience there is a bias towards focusing on procurement policy and process in Government procurement, rather than on operational benefits, behaviours and outcomes. This needs to be addressed if better results are to be achieved. Unless there is operational control of the procurement it is entirely possible that the wrong decision, for the Departmental or Agency objectives and for the taxpayer, may be made.

3.5 In 2006 the National Audit Office completed a report, "Delivering successful IT-enabled business change", that recommended that programmes focused on ensuring senior level engagement, on acting as an intelligent client and on realising the benefits of change. This advice still appropriate but is often ignored.

3.6 Although some senior decision makers have gained a greater understanding of what is needed to ensure that projects and programme are delivered effectively, many are given this responsibility without the experience and background to be effective SROs. The mantra that "there are no such things as an IT projects, but only business change projects" is gaining some support, but there is some way to go to achieve universal acceptance and for business leaders to be comfortable and confident that they can take on these responsibilities successfully.

3.7 Requirements

3.8 The definition of requirements, both in their content and their level, and the manner in which they are contracted is absolutely critical to the success of a programme. As we will discuss in this paper, the area of requirements has not only been a major inhibitor of effective IT in Government in the past, but could also compromise the "Agile" development approach Government is looking to take in the future.

3.9 If requirements are generated outside solid operational governance and are not grounded in the timescales and financial reality of the programme, then there may be a tendency to "gold plate", i.e. to specify everything that is possible, rather than to be "good enough". The security arena is often an area where excessive constraints may distance the programme from the original operational need.

3.10 "Gold plating" adds complexity, duration and risk to the delivery of a programme. This not only increases the chance of failure but also reduces the number of possible suppliers, potentially excluding SMEs. One method to reduce the impact of excessive requirements is sensible prioritisation based on operational need balanced against cost impact. This should be coupled with the expectation within the stakeholder group that a new system will not be "everybody’s answer to everything".

3.11 A further significant point in relation to avoiding "gold plating" is that it should be accepted that IT systems are best placed to automatically handle the majority of cases that are relatively straightforward and that the minority of cases that are highly complex may be better handled with some manual intervention. This is often called the "80:20 rule". Accepting that the IT system will not address the minority of highly complex cases allows the system design to be greatly simplified and costs therefore reduced.

3.12 Requirements should be generated with the anticipated development methodology in mind. If "Agile" is to be used there should be high level, outcome based, business requirements that the supplier should be contracted to meet. If it is helpful, lower level requirements can also be documented, but these should be advisory unless strictly required for minimum interoperability purposes. "Agile" development does not work with two thousand requirements against which a supplier is contacted to deliver, with complex change processes and punitive penalties for delay or deviation. Even in traditional "waterfall" development, we are not convinced that the vast requirements documents generated by Government, and their associated client side advisers, are helpful.

3.13 Closely associated with the issue of excessive requirements detail is the length of time spent in the project initiation phase. A key factor in the ability of a programme to deliver its intended business requirements, especially in the fast moving world of IT, is the time between the inception of the operational vision and the commencement of the development. Excessively lengthy and detailed requirements gathering phases may impact this ability.

3.14 We would propose the time boxing of the requirements work stream be considered. To assist with this, client side advisers should be engaged on a fixed price basis to build requirements with specific success criteria applied as per the delivery contract.

4. Contracting Approach

4.1 Once an OJEU procurement has commenced and potential suppliers engaged, sometimes behaviours are exhibited that, while intended to improve the chances of success of a programme, may have the opposite effect. In this area we would highlight:

- Risk aversion

- Financial and contractual solution

- Procurement duration

4.2 We understand that Government is recruiting a Chief Procurement Officer and that this position will combine the role of CEO of the procurement agency, "Buying Solutions", and the head of procurement in the Cabinet Office's Efficiency and Reform Group. We hope that the mandate of this role will address the issues in the current procurement processes discuss below.

4.3 Risk

4.4 Overall, we find that Government procurement is becoming increasingly risk averse. Procurement officers and advisers tend to follow an approach of endeavouring to drive all possible risk to the supplier. In our view, risk should be owned by the most appropriate party, with other parties assisting in the mitigation. Forcing suppliers to take inappropriate risks, e.g. transfer of liabilities from existing Government contracts unseen by the supplier, at a minimum will lead to additional costs and time to deliver.

4.5 As with most aspects of a programme, the factors we discuss in this paper are interconnected. Risk aversion also drives the "I need to know exactly what I’m buying" approach that can create lists of two thousand requirements, as discussed earlier. A system designed to pass risk to one party, without also encouraging the other party to work to mitigate that risk, is doomed to failure.

4.6 The Committee will be aware that the Government can never fully subcontract risk to its suppliers. As we have seen time after time, in the eyes of the media and the citizen, if a supplier fails on a major programme then so does the Government. Many press stories of "Government IT disasters" reinforce this point. There is therefore a need to have a more sensible discussion about the appropriate allocation of risk.

4.7 Financial and Contractual Solution

4.8 We believe that Government should not treat all major IT projects in the same manner. A systems integration "build – deliver" contract is different to a "run – operate" contract with different risk profiles, skills, commercials etc. There are many contractual and financial solutions open to Government and there is a need to move away from current contracting practices should Government wish to reap the benefits of an "Agile" methodology.

4.9 We would propose a focus on the operational outcomes, rather than day rates. The supplier who can give the highest confidence in delivering the best operational outcomes needs to be balanced in selection against the lowest total cost at point of Contract signature. The trend to decisions based mainly on price at point of Contract appears signature to be increasing; we suggest that this may be overly simplistic.

4.10 Connected with a risk-averse approach is the tendency to make contracts as punitive as possible. We believe that this drives the wrong behaviour, forcing suppliers to expend excessive effort managing the contract rather than working with Government to produce the deliverables and achieve the desired outcomes. In a similar manner, if suppliers are squeezed too hard on price, to the level of unprofitability, they may err towards delivering the contractual minimum, thus reducing the chances of a successful operational outcome.

4.11 We would emphasise again that in the event of a contract breaking down, Government’s ability to financially punish the supplier does little to mitigate the political embarrassment of the failure to deliver key parts of the Government’s policy agenda and consequent adverse press coverage. We recommend a move towards creating a contract that facilitates success, rather than one to be relied on in failure. In summary, excessively onerous contracts and low margins may look good at Contract signature, but they also add risk and may not deliver over the duration of a programme.

4.12 On a behavioural point; we have noticed on occasion that the adversarial style adopted in some procurements tends to spill over into implementation. We would caution against the extremes of this style of procurement as, having spent a year or more "across the table" it can be hard to then get "around the table" to work as partners to implement.

4.13 Duration

4.14 Continuing the theme in Section three on the time taken to develop the requirements, this is compounded by the lengthy duration of many procurement exercises. With both project initiation and procurement phases often taking well over a year, the original (highly prescriptive) requirements may be as much as three years old at contract award. In the fast moving IT arena this means that the contract can be semi-obsolete at the start of delivery.

4.15 This situation may lead to a large number of change requests precisely at the time when the supplier is ramping up the programme. Compounding this may be punitive delay payments which drive the supplier to continue to advance the development in parallel to the assessment of the impact of the changes to existing requirements. Such activities compete for key resources such as the Design Authority and the Programme Manager, leading to further distraction, risk and unmet expectations.

4.16 Supplier behaviour at this time may be driven by the risk that the Contracting Authority rejects some or all of the changes, and holds the supplier to the original plan with associated penalties. The danger is that, with both parties trying to do two activities at once, neither activity is completed successfully.

5. Appropriate Methodology

5.1 Increased use of "Agile" methodology

5.2 There has been much discussion recently about the use of "Agile" methodology in Government, including the recent "System Error" report by the Institute for Government [1] . We are broadly in agreement with the report. However, there are two areas we wish to highlight. Firstly, we do not believe that "Agile" methodology can deliver effectively under the Government’s current contracting approach, and secondly we are concerned that "Agile" should be appropriately applied to IT projects that can benefit from it, and not seen as a "silver bullet" approach to all contracts.

5.3 Relationships, trust, collaboration and joint team commitment are key to the success of an "Agile" approach. This is often not understood by procurement and legal departments, and contracts are written which drive behaviour in the opposite direction.

5.4 Fixed price contracts, penalty clauses, rigid quality measures which force development teams to work on low operational value fixes, rather than a gem of new functionality which would provide significant value, are also at odds with the "Agile" approach.

5.5 A commercial model that reflects whole joint team collaboration will create a more productive delivery engine. If one party is incentivised financially to make a case that another party has worked less productively, or has not delivered a pre-requisite, then this drives behaviours away from some of the underlying principles of "Agile" methods.

5.6 A development approach that meets the high level operational requirements, and time / price boxes the development of the detailed requirements is necessary. A move away from contracts that articulate every detail of the solution at Contract signature is necessary for "Agile" development to be effective.

5.7 Of course, this approach means that Government needs to accept some level of risk. This is contrary to the recent contracting approach, which has been to move as much risk as possible the suppliers. As mentioned in Paragraph 4.6, we would argue that some level of risk always remains with Government.

5.8 Our experience is that "Agile" is now frequently the first choice of approach for many types of projects, but not necessarily all. Historically we have seen "Agile" very successfully applied to prototyping, and small projects with unstable requirements, where input from business users was vital as the project progressed. Over time, the use of "Agile" has expanded successfully in to larger scale projects, and in fact it is now widely used in IBM's software development laboratories, including in the UK, to produce industrial strength, high quality software products. However large systems integration projects (particularly those which involve complex integration of legacy systems - such as a number of the government's IT projects), are challenging regardless of approach, and "Agile" methods may need to mature further to cope adequately with these. One of IBM's responses to reduce the risk of "Agile" on such projects has been to develop and deploy a number of enhancements (such as our '"Agile" with Discipline' approach [1] ). We would be pleased to share our expertise in this field with Government.

6. Collaboration and Reuse

6.1 Political Mandate

6.2 Collaboration and reuse are the routes to increased productivity, decreased risk, and decreased time to deliver. However, the most powerful force for collaboration is generally beyond the control of suppliers. Considerable will is needed at the highest levels in Government to make use of solutions cross-Departments and Agencies, and the determination to enforce this requirement, despite special pleading from Department and Agencies..

6.3 Collaboration usually requires some level of pain and compromise, which are not always evenly distributed, to reap the benefits. Additionally there are the thorny issues of budgets and control: not every Department can be the shared service supplier. There is huge potential for re-use of existing services and for the establishment of shared services in Government, for example the consolidation of Government infrastructure, however we see little evidence practical steps to achieve this at present.

6.4 Architecture, methodology and tooling

6.5 Coordination across Departments and Agencies is currently voluntary. Organisations such as the CTO Council do not have the mandate to insist on standardisation and, therefore, the success of initiatives such as common architecture is patchy. However, before a reference architecture is rolled out there are easier opportunities such as common methodology and tooling. These significantly aid reuse, reducing time and cost to implement and increasing productivity. To cite an example; we would propose that the elements of a common data model necessary for practical interoperability, i.e. a common definition of data entities, would be a key item for the CTO Council, or other suitable organisation, to develop and enforce.

6.6 In designing and implementing IT systems, it is important to consider the wider impact of these on other existing systems, since any new system will need to integrate with other systems. From an IT perspective this integration demands consistency of, for example, definition of data entities as per Paragraph 6.5. Where such consistency does not exist, a significant degree of complexity is introduced. Also, at a day-to-day operational level, integration requires consistency of business processes, for example HR and financial, without which inefficiencies occur.

6.7 This is an area where IBM has direct experience. Our Unified Method Framework, implemented company wide, provides a single framework to enable a common language among all our practitioners delivering business solutions. This has been hugely successful in accelerating our shift to asset based services and facilitating the reuse of knowledge and assets (services as well as architecture) via a consistent, integrated approach.

6.8 Open standards and source

6.9 We fully support the UK Government in its move to ensuring open standards are used to ensure modular, flexible solutions and avoid proprietary lock-in. We are currently assessing the standards survey, but we believe it is likely that actual priorities and mandates will need to be restricted to standards affecting interoperability. Such an approach will simplify the proposal in the number of standards and allow a simple, clear definition of open standards. In turn, this will maximise the benefits to the public sector and minimise the costs of interactions with Government and between other parts of the public sector. At the same time a strong mandate limited to standards for interoperability will promote local flexibility.

6.10 Open standards, adopted by many vendors, reduce the risk of lock in to a single supplier, offer flexibility in terms of access to a wider set of capabilities, and reduce costs. Skills and support for solutions delivered through open standards are typically more common in the market place, and so wider competition delivers better value for money. Moreover widespread adoption of open standards allows the reuse of assets throughout the eco system, further delivering standardised approaches and reducing costs and risk.

6.11 Looking forward, and acknowledging the need for a more joined up approach, the single biggest cost inhibitor to integration of systems is the transformation of data needed when it passes between non-standard systems and processes. Not only is the cost of integration and support significant, but the constant retranslation of data brings in a high risk of data corruption. Once data becomes corrupted, and the integrity questioned, then the impact becomes even larger.

6.12 This combination of wider choice, better competition, and more available skills, made possible through the use of open standards, also delivers the benefit of decreased time to delivery. Better understood development processes allow more rapid production, and therefore enable a much more interactive and inclusive development cycle. End users can see functionality demonstrated faster, and changes can be incorporated with much lower cost. This negates the need to front load all requirements, as otherwise requirements specification is typically the only time users currently get to request functionality. The direct result is that suppliers are not required to build "gold plated" over-complex solutions with questionable functionality, rather to symbiotically develop a user based solution.

6.13 On "open source", the UK government's commitment to delivering a level playing field is welcomed - giving significant confidence in the execution of policies that have long been subject to doubt. We look forward to working with the Government on its successful implementation. It should be recognised that open standards and open architectures are key enablers of open IT markets for both open and closed source solutions.

6.14 COTS ‘v’ Bespoke

6.15 We recommend COTS products or reuse of existing systems rather than bespoke development, if possible. Bespoke systems are often unique implementations and therefore there is no directly comparable prior experience that can be built upon. COTS products have been implemented several times in similar situations. Maintenance of, and enhancements to, COTS packages are frequently easier and more cost effective.

6.16 However, the relative benefits of implementing, maintaining and enhancing a COTS package when compared with a bespoke system can only be achieved if Government does not request that the COTS package is significantly customised and changes made to core functionality, to meet the particular circumstances. This brings the worst of both worlds – attempting to make a COTS package into a bespoke system and the consequent increases in development and support costs.

6.17 It is a mistake to think that the implementation of bespoke systems, where the system is designed to match the existing needs of users and the existing processes, is always more advantageous than the implementation of a more generic system, which may require working practices to change to be more in line with best practice processes in use elsewhere. The former assertion is based on the, often false, assumption that existing working practices are optimal. Often an organisation would benefit from the change in business processes, even taking into account the change management challenges that this brings. This emphasises, again, the need for the engagement of senior business people in the initiation phase and in the ongoing requirements specification and governance.

Benefits Realisation

6.18 Driving the savings from effective IT

6.19 Ensuring that focus is maintained on achieving the operational benefits that are sought from the IT system is essential, as opposed to simply a focus on the delivery of the IT system itself, as these are ultimately the real benefits that the Government will obtain from the system. For example, there is little point in achieving a successful "go–live" of an IT system, if the benefits sought such as staff redeployment, channel shift and asset reduction, for example real estate, are not driven out as well.

6.20 It should be recognised that, according to UK Public sector productivity reports [1] , benefits realisation is currently limited in most public sector ICT projects, even those rated as successful in technical terms.

6.21 Government needs to retain (or build) sufficient skills to be an intelligent client, without excessive reliance of client-side advisers who may not always be entirely motivated by the need to deliver in the fastest, least complex manner commensurate to the task. This should allow for the staff, facilities and technical reductions that the IT delivery facilitates. In our experience this does not always happen. Success should be assessed on clearly defined measures of benefit delivered, converted to a financial position, or social or operational outcome, as appropriate

6.22 When re-engineering IT, benefits realisation should consider the full spectrum of possibilities, including the management model, methods, technical design, resource pooling etc. IBM’s own re-engineering, which continues to evolve, provides a prime example of such a programme.

7. Additional Material

7.1 There is a wealth of information on de-risking and optimising IT programmes with many and varied opinions. The Lovelace Lecture "The Sins of IT Projects and why they can fail" [1] presented by Maurice Perks, IBM Fellow, is a recommended example.

April 2011