COMMISSION STAFF WORKING DOCUMENT

Guide for the procurement of standards-based ICT — Elements of Good Practice

Accompanying the document

COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS

Against lock-in: building open ICT systems by making better use of standards in public procurement

TABLE OF CONTENTS

1........... Introduction. 4

1.1........ The purpose of this Guide. 4

1.2........ Definition of standards. 5

1.3........ Procuring ICT that is based on standards and other technical specifications — Action 23 of the Digital Agenda  5

1.3.1..... Procurement practices. 6

1.4........ Structure of the Guide. 7

2........... Assessing standards. 9

2.1........ The benefits of standards and other technical specifications. 9

2.2........ What to look out for 9

2.3........ What to do. 11

2.3.1..... Develop and maintain expertise on standards and other technical specifications relevant to each area of ICT  11

2.3.2..... Competence centre on standards and ICT technical specifications. 12

3........... Developing an ICT strategy. 13

3.1........ What to do?. 13

3.1.1..... ICT strategy. 13

4........... Engaging with the market and evaluation of products. 15

4.1........ What to do. 15

4.1.1..... Find out what standards and other technical specifications are supported by the market 16

4.1.2..... Work with the market to develop suitable solutions. 16

4.1.3..... Use information from the engagement process to develop technology-neutral specifications. 16

4.1.4..... Undertake periodic evaluation of ICT products and publish this information. 16

5........... Developing practical advice. 17

5.1........ What to do. 17

5.1.1..... Develop lists of recommended standards and other technical specifications as part of an ICT strategy  17

5.1.2..... Develop templates and ready texts to refer to standards and other technical specifications. 18

5.1.3..... Develop templates for IPR provisions in procurement documents. 18

5.1.4..... Provide training on ICT public procurement 19

5.1.5..... Monitor calls for tenders for ICT procurements to detect recurrent problems and identify ways to resolve these problems. 19

6........... Understanding ICT needs. 20

6.1........ What to do?. 20

6.1.1..... Understand the need for interoperability. 20

6.1.2..... Understand your legacy systems and try to change the parts that are causing lock-in. 21

6.1.3..... Consider the need for the use of the data generated or stored by the new purchase. 21

6.1.4..... Consider the need for public access by businesses or citizens. 22

6.1.5..... Consider the need to change suppliers or products in the future. 22

7........... Long-term business appraisal 23

7.1........ What to do?. 23

7.1.1..... Plan ahead. 23

7.1.2..... Develop options. 24

7.1.3..... Conduct a business appraisal of the options. 24

8........... Long-term budgetary planning. 26

8.1........ What to do?. 26

8.1.1..... Accurately account for future costs and benefits. 26

8.1.2..... Communicate budgetary needs. 26

9........... Write procurement documents. 28

9.1........ What to do?. 28

9.1.1..... Be aware of the legal framework. 28

9.1.2..... Avoid unnecessary use of brand names and proprietary technical specifications but reference the appropriate standards or other technical specifications. 28

9.1.3..... Include all necessary requests for openness to avoid lock-in. 29

10......... Evaluation and feedback. 30

10.1...... What to do?. 30

10.1.1... Write up case studies of procurement exercises to share best practice. 30

10.1.2... Learn from experience and adapt centralised and local advice accordingly. 31

11......... Conclusions. 32

Appendix 1: Example texts. 33

Appendix 2: Sources of information. 36

Appendix 3: Costs of implementing the measures proposed in this Guide. 40

1.           Introduction

The Digital Agenda is Europe’s strategy for a flourishing digital economy by 2020.[1] It outlines policies and actions to maximise the benefits of information and communications technology (ICT) for all. Several actions are devoted to improving standard-setting procedures and increasing interoperability. Europe must ensure that, as far as possible, new IT devices, applications, data repositories and services interact seamlessly everywhere. The guidelines presented in this document are the result of one of these actions of the Digital Agenda, namely Action 23, which aims to ensure, through guidance, the appropriate use of standards in ICT public procurement to alleviate lock-in.[2]

1.1.        The purpose of this Guide

This Guide is designed for use by procurement officials, IT managers, strategists and architects within public organisations, and policy makers at a wider government level.

It is intended to help those actors who are responsible for both planning and purchasing ICT systems and services under the EU procurement directives to ensure fully effective competition following best procurement practice, in particular by

· Minimising the risk of becoming locked in to particular suppliers for unduly long periods, and

· Making the best use of ICT standards.

The Guide does not give a list of recommended standards for use by public authorities when planning and procuring ICT goods and services. This would not be possible since the standards most relevant to each awarding authority will vary according to particular functional needs and the wider set of systems the procured system has to interact with. However, the Guide does:

· Offer recommendations on elements of best practice in ICT procurement, with practical examples.

· Suggest some concrete ways in which procurement documents and contracts for ICT might be expressed. The selection process and the acceptance of results are not covered, however.

· Give references to sources of more detailed procurement guidance and information.

This Guide is intended to help public authorities procure ICT goods and services, and is not intended as legal advice. Those responsible for procurement should ensure that all recommended stages comply with national and EU legal requirements, and seek legal support wherever necessary.

1.2.        Definition of standards

EU Regulation 1025/2012 (amending Directive 98/34)[3] (the Standardisation Regulation) defines a ‘standard’ as ‘a technical specification adopted by a recognised standardisation body, for repeated or continuous application, with which compliance is not compulsory, and which is one of the following:

· “international standard” means a standard adopted by an international standardisation body,[4]

· “European standard” means a standard adopted by a European standardisation organisation,[5]

· “harmonised standard” means a European standard adopted on the basis of a request made by the Commission for the application of Union harmonisation legislation;

· “national standard” means a standard adopted by a national standardisation body;’.

Standards may be referenced in procurement documents in accordance with the Public Procurement Directive (see article 23 of Directive 2004/18/EC).[6] However, Articles 13 and 14 of the Standardisation Regulation also allows ICT technical specifications (see Article 13) to be referenced in public procurement that meet the requirements set out in Annex II  to the Regulation (market acceptance, no conflicts with European standards, process used to develop standard was open and transparent, and the standard is maintained, available, and IPR licensed under FRAND). Those ICT specifications are identified by the Commission after consultation of the European Multi-Stakeholder Platform on ICT standardisation .

.

1.3.        Procuring ICT that is based on standards and other technical specifications — Action 23[7] of the Digital Agenda

Under Directive 2004/18/EC, the technical specifications that shall be set out in the contract documentation, such as contract notices, contract documents or additional documents, must afford equal access of economic operators to the procurement procedure and shall not have the effect of creating unjustified obstacles to the opening up of public procurement to competition. To this end, these technical specifications shall be formulated either in terms of performance or functional requirements or by reference to technical specifications defined in Annex VI of the Directive which are, in order of preference, national standards transposing European standards, European technical approvals, common technical specifications (including ICT technical specifications under Article 13 of the standardisation Regulation), international standards, other technical reference systems established by the European standardisation bodies or — when these do not exist — to national standards, national technical approvals or national technical specifications relating to the design, calculation and execution of the works and use of the products.

When a public authority is overly dependent on a single vendor for its ICT systems, there will be a lack of competition for the provision of these systems and value for money might not be achieved in the long term. Symptoms of possible lock-in include excessive use of specific brand names of products in procurement documents, and requests for backward compatibility with proprietary systems of which only a few suppliers have knowledge. Usually this also means that procurement documents need to make use of the paragraph 8 in Article 23 of Directive 2004/18/EC: "Unless justified by the subject-matter of the contract, technical specifications shall not refer to a specific make or source, or a particular process, or to trade marks, patents, types or a specific origin or production with the effect of favouring or eliminating certain undertakings or certain products. Such reference shall be permitted on an exceptional basis, where a sufficiently precise and intelligible description of the subject-matter of the contract pursuant to paragraphs 3 and 4 (of Article 23) is not possible; such reference shall be accompanied by the words 'or equivalent'. It is one of the aims of this Guide to prevent the use of Article 8 as much as possible.

Evidence from a survey of procuring authorities[8] carried out to prepare this Guide shows that at least 40 per cent of respondents perceive some degree of lock-in arising from either a lack of interoperability and compatibility between existing and new systems or solutions, or from a lack of transferability of data and information between old and new systems.[9] These perceptions of lock-in were supported by suppliers, 26 per cent of whom reported evidence of lock-in in public sector ICT calls for tenders, or felt that the calls they had seen would serve to perpetuate existing lock-in.[10]

1.3.1.     Procurement practices

The existence of lock-in and excessive influence of legacy systems can lead public procurers to engage in poor procurement practices that restrict the ability of suppliers to participate in calls for tenders. These difficulties have been highlighted in recent research.[11],[12] They include:

· Problems in using standards and other technical specifications appropriately in procurement documents.

· The use of brand names and proprietary technical specifications to identify products and systems that only certain vendors or suppliers can provide.

· Requirements for the new ICT purchase to be compatible with previously purchased products or systems, which can favour the original suppliers and thus restrict competition, while increasing the risk of vendor lock-in.

In the context of Action 23 of the Digital Agenda, the European Commission has collected best practices on how to use standards and other technical specifications in the procurement of ICT, since their appropriate use will help alleviate lock-in. The resulting guidance is provided in this document.

1.4.        Structure of the Guide

The Guide follows the structure shown in Figure 1. It distinguishes three different organisation levels important for procuring ICT systems based on standards or other technical specifications and removing lock-in.

· At centralised level general applicable knowledge is developed and agreements are developed that are important for all public authorities. This knowledge and agreements will be made accessible through an ICT strategy and architecture, lists of recommended standards and technical specifications, assessments of standards and technical specifications and products that implement them, templates and ready texts to use when writing public procurement documents and training on ICT procurement.

· The local level represents the activities of one particular public authority that needs to plan several procurements. The outcomes of these activities will result in a description of the ICT needs, long term evolution plan of ICT systems and services, and budgetary choices which are necessary to be done before an individual procurement can take place.

· The individual level is the level of one particular public procurement. The activities done at centralised level and local level should help to make it easier for civil servants to write procurement documents in a manner that will lead to more competition and choice. The outcome will be the procurement documents and feedback on the centralised and local activities.

Each of the activities will be described in a separate chapter.

Figure 1: The activities involved in procuring ICT systems based on standards and other technical specifications

2.           Assessing standards

2.1.        The benefits of standards and other technical specifications

A key benefit of standards and other technical specifications in ICT is their role in facilitating interoperability. They define the minimum specifications of a technology, which, if faithfully implemented, can enable products, systems and services developed by different suppliers to communicate and transfer data. Procuring a product from one supplier that is based on standard technology should help to ensure that future purchases are not limited to the original supplier, as others are also able to implement the technology.

2.2.        What to look out for

The standardisation landscape is very diverse and choosing the right standards or other technical specifications can be complicated. Procurers should be aware that:

· Standards and technical specifications can be implemented in different ways. Standards and technical specifications are often presented in natural language (and supplemented with some representation of the specification in a formal and/or semi-formal language). The team implementing this technical specification needs to interpret this and encode it in a software system. It is not uncommon that different people may interpret a given specification in a different way because some specific details in the specification are not sufficiently precise described, or the inherent complexity of the specification. Example: SQL (Structured Query Language) is a database querying language created in the seventies, and standardised by ISO in 1987 (ISO 9075). However, interoperability problems between major products still exist due to different interpretations of the standard, due to room for interpretation and the complexity of the standard. There remains the possibility of lock-in for suppliers using this standard[13]. 

It is therefore important that a standard or technical specification also provides a reference implementation or a conformance test, so that claims of software providers regarding the extent to which they implement a standard or technical specification can be neutrally assessed, and there will be less risk for lock-in.

· Almost all standard-setting organisations produce both effective and widely implemented standards, and some that never achieve market-place acceptance. It is therefore not possible to judge the value of a standard simply by virtue of it being a formal standard. Example: the IETF TCP/IP specification became much more widely implemented than the ISO OSI standard, despite the fact that ISO has produced many other very successful ICT standards.

· Furthermore, while standards set by formal standard-setting organisations go through a formal development process, they may not contain all information needed for general implementation. Example: ISO/IEC 29500, ISO/IEC 26300 and ISO 32000 for document formats reference information that is not accessible by all parties (references to proprietary technology and brand names, incomplete scope or dead web links). This can have an effect on the interoperability of products implementing the standard, if the missing information cannot be found outside of the standard.

· On the other hand, specifications developed by industry that have not been through a standard-setting process can be made available on an open and non-discriminatory basis and implemented across the market. Example: Universal Serial Bus (USB) is a technical specification developed by an industry consortium. A not-for-profit organisation was set up: USB Implementers Forum (USB-IF). Free access to published specifications and licensing (on royalty-free terms for core specifications) is publicly available for adopters. USB-IF membership provides additional benefits including free compliance/interoperability testing, a USB vendor ID and use of the logo. Interestingly, following an initiative of the European Commission in 2009, one of the several plug formats (Micro-USB) has been chosen as the standard plug for mobile phone chargers sold in the European Union due to the broad market implementation of USB.

· There are technologies and specifications that appear to be widely implemented but have not passed through a standard-setting process (i.e. through a standard-setting organisation or an established alternative forum or consortium) and in reality could be implemented by only a few suppliers. These are not considered technical specifications within the meaning of Article 23.1.a) of the Procurement Directive. Procuring products that implement these increase the risk of being locked into a limited number of suppliers or vendors.

· The intellectual property rights (such as patents) essential for implementing technical specifications can be made available to implementers through a range of models. Many technical specifications are made available on fair, reasonable and non-discriminatory (FRAND) conditions, which may or may not entail royalty payments. Some technical specifications are made available on a strictly royalty-free basis under other licensing conditions. The way in which a technical specification is licensed may affect the use of products or solutions that implement it, and procurers should take account of this in the specific context of each ICT purchase to ensure the licence meets their ICT needs. As an example, FRAND licenses create barriers for Open Source projects to implement the technical specification.[14] . 

· There are a large number of standards and technical specifications that overlap. Selecting ICT products implementing only certain technical specifications may exclude alternative products implementing different technical specifications that may better support functional needs.

· The costs of accessing the standard or technical specification: corresponding documentation can generally be made available either without charge or for a small fee. This will depend on the standard-setting organisation’s business model. High access costs can deter some providers from accessing and using the technical specification.

· The cost and practicality of implementing the technical specification: Market demand: a technical specification’s value will be higher in terms of interoperability and avoiding dependence on a single supplier if it is mature and widely supported by the market.

· The development of the technical specification: if all stakeholders have the same possibility of contributing to its further development, and public review is part of the decision-making process, then it is more likely that it will not favour certain suppliers.

· In general, standards and other technical specifications are of varying quality and are always liable to change. 

However, the benefits of using standards and other technical specifications are numerous and public authorities should use them as fully as possible when specifying procurement documents. In order to do this the following steps are recommended.

2.3.        What to do

What to do?

Develop and maintain expertise on standards and other technical specifications relevant to each area of ICT

Who should act?

For efficiency reasons, it is beneficial to maintain knowledge of standards and other technical specifications centrally within a country or region, and to make it easily accessible to all procuring authorities. The most suitable organisation would be the one that also represents the country in the European Multi-Stakeholder Platform on ICT Standardisation.

2.3.1.     Develop and maintain expertise on standards and other technical specifications relevant to each area of ICT 

Expertise on standards and other technical specifications relevant to different areas of ICT should be developed and maintained. This should include information on the various products and suppliers that implement a technical specification and the effects of this implementation. Technical specifications can be assessed using the Common Assessment Method Standards and Specifications (CAMSS).[15] Using this methodology will ensure that knowledge of technical specifications can be easily shared with others. In general, cooperation with IT managers from other organisations is recommended in order to share experiences and expertise.

There are a number of useful sources to consider in keeping up to date with the development of standards and other technical specifications. First of all, there is the work done in a number of Member States to publish lists and catalogues of standards and other technical specifications with recommendations as to their quality and openness. However, these are often developed within a particular national context and may not be applicable to every public organisation.

Also, different ICT domains have already developed a great deal of knowledge about technical specifications, for instance in areas such as eHealth, transport, eAccessiblity and eProcurement. Information and links to all these sources are included in the Appendix.

In this context, it is also important to understand that only standards from a formal standardisation organisation or a technical specification that has been identified by the Commission after examination by the European Multi-Stakeholder Platform for ICT Standardisation may be used in public procurements. The European Multi-Stakeholder Platform will assess the process used to develop the standard against certain criteria, e.g. that the process was open and transparent. The assessment by the Multi-Stakeholder Platform is not as wide-ranging as that proposed in the CAMSS methodology.  An important difference is that CAMSS takes into account the specific business needs of the authority doing the assessment, while this is not the case in the assessment of the Multi-Stakeholder Platform

On the other hand, if the assessment of a technical specification produced by a forum or consortium has led to the conclusion that this specification would be good to use for certain procurements, but has not yet been assessed by the Multi-Stakeholder Platform, then the Multi-Stakeholder Platform should be informed that this is a candidate for assessment. Once approved by the Commission, this ICT technical specification can be used in the future in public procurement.

2.3.2.     Competence centre on standards and ICT technical specifications

Some countries, regions and sectors have set up competence centres on standards and other technical specifications, providing information on issues associated with the use of these specifications. Examples include Single Face to Industry[16] in Sweden and the Standardisation Forum in Norway.[17] These centres can give advice upon request, but also maintain catalogues of technical specifications to be used in specific procurement documents. Procurers and IT managers should access these centres for information and advice where they exist. However, each country/region/sector should organise knowledge on standards and other technical specifications in a manner that fits best their organisation.

3.           Developing an ICT strategy

The second activity shown in Figure 1 is to define an ICT strategy. It will define the strategic direction of the authority’s main ICT components and their interfaces and the actions required to ensure that all ICT systems fit within this strategy. Sometimes this is also called ICT architecture, or reference architecture. Standards and other technical specification will play a role in the description of the interfaces.   

Having an ICT strategy can be a good way of coordinating ICT decisions across organisations and governments. This is important given the need to involve many parts of public organisations in purchasing decisions early enough to understand the full implications of the procurement and address any risks. These include legal departments, IT managers and chief information officers (CIOs), procurers and wider public sector strategists, as well as those users directly affected by the ICT to be procured.

ICT procurement decisions taken within the context of a strategy are likely to result in purchases that meet the needs of the authority as a whole, rather than only those of individual departments. This is particularly relevant when migrating to new systems or solutions where the move is most cost-effective if undertaken on a wide scale. The development of ICT strategies can also lead to further rationalisation of ICT infrastructure in departments, limiting duplication and promoting sharing and reuse of services while allowing flexibility.

3.1.        What to do?

What to do?

Develop an ICT strategy that defines the strategic direction of the authority’s main ICT components and their interfaces and the actions required to ensure that all ICT systems fit within this strategy

Select which standards and other technical specifications support the ICT strategy

Who should act?

The definition of ICT strategies should be considered by CIOs and leaders with a clear view of the needs of the organisation or sector. However, all others involved (IT managers, procurement officials and end users) should be aware of the strategy and how they contribute to and are affected by it.

3.1.1.     ICT strategy

The development of an ICT strategy can be one way of coordinating ICT systems across organisations and governments, not only to agree on which standards and technical specifications will be used, but also to agree on principles which the authority considers important for the delivery of its ICT services, such as:

· All citizens should input their data only once; if another government service needs the same data then they should be retrieved automatically.

· A standard format is used for interaction with citizens.  .

· Increased interoperability between public sector ICT systems is necessary.

· If there is lock-in, a plan has to be developed to resolve it.

· Public sector information should be made available according to certain standards or other technical specifications, in order to make it easier for organisations/citizens to use this information to develop services.

· Documents that have to be archived for a long period should be stored in a standard format[18].

All these principles may be implemented by making proper use of standards or other technical specifications.

Example ICT strategies and architectures are provided in Appendix 2. The procurement of ICT, including the standards and other technical specifications used, would be carried out so as to realise these goals.

4.           Engaging with the market and evaluation of products

This is an important step in the procurement process, as it enables public authorities to consult the market and to examine alternative solutions in the market place. Transparent market engagement can encourage the participation of a wide range of firms, and can help the procurer develop options that are feasible and best meet ICT needs. In addition, market engagement is an important step in assessing what are the best standards and other technical specifications in terms of market support and quality.  

It should be noted that any initial consultation of the market, e.g. technical dialogue, would have to be on condition that the seeking or accepting of advice does not have the effect of precluding or distorting competition.

Finding out what the market can provide may be an iterative process that both draws on and feeds into other steps such as defining needs or deciding on what standards and other technical specifications to use. The need for market engagement should therefore be considered in procurement planning from the beginning. It should be pursued both at centralised level, for general needs, and at local level, for specific needs.

4.1.        What to do

What to do?

Find out what standards and other technical specifications are supported by the market

Work with the market to develop suitable solutions

Use information from the engagement process to develop technology-neutral specifications

Undertake periodic evaluation of ICT products

Who should act?

Finding out what the market can provide would be the task of IT managers and CIOs, depending on the level at which the procurement decision is taken. If an ICT strategy is being developed, the market engagement will need to be at a high level, e.g. led by the CIO.

As an example of guidance on how to effectively and transparently engage with market participants, we refer procurers to DETE Ireland’s Buying Innovation: the 10 step guide to smart procurement and SME access to public contracts.[19] Important steps to highlight are:

4.1.1.     Find out what standards and other technical specifications are supported by the market

Procurers and IT managers should consult with suppliers and supplier bodies, for example at suppliers’ conferences, to enable suppliers to help select relevant standards and other technical specifications, provide feedback on their feasibility and affordability, and gear up to respond to future procurements that will reference the technical specifications selected.

Understanding the market, the companies within it and their ability to meet the technical specifications is an important step in encouraging supplier innovation. Care should be taken when the market is dominated by a few large players, as this may influence the selection of standards or other technical specifications.

Different types of technical specifications (e.g. based on their licensing regimes) will have different effects on market entry depending on the nature of the ICT domain. 

When considering specifications that have not been developed by a recognised body and/or are not publicly available, the relevant intellectual property rights must be checked in order to avoid de facto discrimination, which may result in only a single bid, or very few bids, being received.  

4.1.2.     Work with the market to develop suitable solutions

It may be useful to communicate long-term ICT procurement plans to the market to give suppliers time to react and develop solutions meeting the organisation’s needs. This is particularly important for solutions that require currently unavailable levels of interoperability. This will include informing the market of particular standards and other technical specifications that have been adopted by the organisation, or the ones that will not be accepted.

4.1.3.     Use information from the engagement process to develop technology-neutral specifications

Care should be taken to ensure that the development of procurement options, and the accompanying technical specifications used in procurement documents, is not unduly influenced by the suppliers that have been involved in discussions.

4.1.4.     Undertake periodic evaluation of ICT products and publish this information

Objective evaluation of ICT products implementing standards and other technical specifications should be undertaken on a regular basis, in order to be able to take into account new and unknown products that could satisfy the ICT needs of public authorities. Information about evaluated ICT products should be made available to all public authorities, so that evaluations are not duplicated.

Additional information sources for engaging with the market are provided in the Appendix.

5.           Developing practical advice

ICT strategies and architectures and the knowledge gained through the assessment of standards and other technical specifications and engagement with the market should lead to practical advice on which standard or other technical specification can be used in which situation.

5.1.        What to do

What to do?

Develop lists of recommended standards and other technical specifications as part of the ICT strategy

Develop templates and ready texts to refer to standards and other technical specifications

Develop templates for IPR provisions in procurement documents

Provide training on ICT public procurement

Monitor calls for tenders for ICT procurements to detect recurrent problems and identify ways to resolve these problems

Who should act?

This type of advice should be developed by CIOs and leaders with a clear view of the needs of the organisation or sector. However, all others involved (IT managers, procurement officials and end users) should contribute by sharing best practices.

5.1.1.     Develop lists of recommended standards and other technical specifications as part of an ICT strategy

One type of practical advice can take the form of lists of recommended standards and other technical specifications from which public authorities can choose for their specific situation.

However, Article 23 of Directive 2004/18/EC states that technical specifications can be requested by name in procurement documents but must be followed by the clause ‘or equivalent’ to ensure the principle of non-discrimination. Hence,  the ‘or equivalent’ clause will allow suppliers to offer products based on equivalent technical specifications. Contracting authorities cannot reject the tender on the ground that this is not the technical specification to which it has referred. It is for the supplier to prove the equivalence, through appropriate means (by a technical dossier of the manufacturer or a test report from a recognised body).

This obligation is particularly relevant in the context of a diverse and rapidly changing ICT landscape –– public authorities should give equal consideration to newly developed technologies to meet new technological needs.

5.1.2.     Develop templates and ready texts to refer to standards and other technical specifications

For common ICT needs, where branded products are often used, descriptions of the products in performance-related and non-proprietary terms would make it easier for procurers to avoid the inappropriate use of brand names. These templates or ready texts would be particularly valuable for (small) procuring departments with limited access to IT expertise but responsible for procuring common ICT products.

5.1.3.     Develop templates for IPR provisions in procurement documents

5.1.3.1.  Licensing for sharing and re-use

Another type of advice to be developed concerns IPR. If the system to be procured should be re-used by other public authorities or redistributed in any other way it is important to include the right IPR provisions in the procurement documents. This can be an important consideration for public authorities in the interest of making the best use of public funds,[20] but it should also be noted that such openness will make the price of the system itself higher.

When an ICT application developed or put together to meet the needs of a public authority could be distributed, re-used, improved, modified, translated into another language or localised for another country, public authorities should require their ICT suppliers to grant them the licensing conditions to do so.

It is important that opportunities for re-use or sharing are identified before the procurement process; this applies to sharing or re-using both existing and future assets. In this way, the necessary licence conditions can be identified and incorporated into the procurement process. 

If the supplier does not write the whole application source code, but combines or adapts existing components covered by various copyright licences, the supplier should confirm that these licences allow the public authority to distribute the application. An example of how such licence conditions could be requested in procurement documents is provided in the Appendix: Example text 1.

Because different solutions will include different IPR licensing models (based on the type of technical specifications and components used), public authorities should be aware that requesting certain licence conditions to meet their needs may limit the range of solutions that can be offered. For example, requesting the ability to re-use software may restrict solutions incorporating proprietary software.

5.1.3.2.  Other IPR considerations

Licensing models relating to individual standards or technical specifications should also be checked, as they will affect the specification's use under different business models. As an example, some FRAND-licensed technical specifications are not compatible with some Open Source Software licences. Therefore, the authority needs to check that the standards and other technical specifications they request will not unintentionally limit the types of solutions that can be provided.

Public authorities should also be aware of the IPR relating to all other parts of the solution provided by the supplier to ensure that they can use the results of the contract as they wish. An example text that could be used in contracts to specify the ownership of IPR is provided in the Appendix: Example text 2.

5.1.3.3.  Indemnity

Public authorities should be aware of the need for the supplier to indemnify the authority against possible IPR infringements relating to the supplier’s solution. Such indemnification may be different under different business models (for example, provisions relating to open source software may be different to those relating to proprietary software) and the authority must consider this when requesting indemnification in the contract, as this may affect the type of solution offered. An example of the way in which indemnity could be requested is presented in the Appendix: Example text 3.

5.1.4.     Provide training on ICT public procurement

In order to create sufficient awareness of the risks and disadvantages of lock-in situations and how procurement of ICT can be done in a more open way by using standards and other technical specifications, the organisations developing the ICT strategy, assessing standards and other technical specifications and developing practical advice should also provide training courses for local public authorities and individual procurers.

5.1.5.     Monitor calls for tenders for ICT procurements to detect recurrent problems and identify ways to resolve these problems

The demand for (and therefore value of) ICT procurement advice will be influenced by the awareness of the need to procure ICT based on standards or other technical specifications. The monitoring of calls for tenders for ICT procurements is an effective way of raising awareness of the need for advice. As an example, the advice centre set up under the Dutch NOiV programme[21] attached a great perceived advantage to its role of monitoring public sector calls for tender and providing unsolicited feedback and advice to the public authorities involved. This included cautions to the authorities on the use of brand names or other restrictive mechanisms, or the failure to reference recommended standards or other technical specifications where appropriate.[22] Experience from the programme suggests that public authorities would not actively seek advice on the use of standards and other technical specifications in ICT procurement if they did not see any problems with the way the procurement documents were drawn up. In most cases, it was only after a public authority had been challenged on procurement documents that it sought further advice on how to make the procurement process more open and competitive.   

Also, suppliers can report poor procurement practices to the central service offering such advice, with the hope of challenging the public authority concerned before the tender process is over (and thus avoiding costly legal fees). In the Dutch experience, a number of small suppliers sought the help of the advice centre.

6.           Understanding ICT needs  

The activities described in chapters 2, 3, 4 and 5 are all carried out at centralised level. However, understanding ICT needs should be addressed at the local level of the public authority needing to procure new ICT systems or services.

It is important to ensure that the ICT purchase meets the requirements of individual users, the organisation and the wider public service. The objectives of the purchase (e.g. creating, recording or storing data, connection with other systems, use by internal staff; interaction with citizens, etc.) will influence the appropriate standards and other technical specifications to be used.

6.1.        What to do?

What to do?

Understand the need for interoperability

Understand your legacy systems

Consider the need for the use of the data generated or stored by the new purchase

Consider the need for public access by businesses or citizens

Consider the need to change suppliers or products

Who should act?

This activity should be undertaken by the department that will use the ICT solution to be procured to ensure that it is fit for purpose. This must be done together with IT managers to ensure that the ICT needs are correctly translated into technical specifications (within the meaning of Article 23.1 of the procurement Directive), and together with legal and procurement experts to ensure that the ICT procured can be used as required by the public authority.

6.1.1.     Understand the need for interoperability

If the ICT purchase is intended to connect to other systems within an organisation or across government, procurers should be aware of any common standard or other technical specification that the purchase should implement to achieve the required interoperability. This will be particularly important for information transfer (e.g. data, file formats), to ensure that information can be exchanged across the public sector. The ICT strategy described in chapter 3 should provide further guidance on specific choices to be made. 

6.1.2.     Understand your legacy systems and try to change the parts that are causing lock-in

Legacy systems, such as those built over time through continuous addition of proprietary products and modules or renewal of licences, can constrain current and future ICT purchases if compatibility with, or knowledge of, the existing proprietary system is required. This may have the effect of favouring a limited number of vendors, suppliers or providers of such products or services. Legacy systems pose even more of a problem when new additions have to be produced or can only be licensed by the same vendor due to lack of standardisation in the original system. This can lead to technical reliance on the original vendor or service provider beyond the timeframe of the initial contract, thus limiting future competition.

Therefore, public authorities should consider moving away from current systems causing lock-in to ones that are more open and based on standards or other technical specifications and that will facilitate the use of products and services from multiple vendors or service providers.

The cost of ‘breaking the locks’ of legacy systems can be significant in the short term, but should be considered alongside the future benefits of more open systems within the business appraisal. A long-term plan will be needed.

6.1.3.     Consider the need for the use of the data generated or stored by the new purchase

Consideration should be given to how the information received, generated or stored by the new ICT purchase will be used both now and in the future (in some cases, access to data may be needed for a very long time). The inputs and outputs of the system or application should be preferably be in a file format according to a standard or other technical specification, or otherwise in an open file format specification to enable them to be accessed and used without reliance on the original application that created them. This is extremely important if data are to be archived for a long period. Public authorities have in the past archived data in proprietary formats that after a number of years are no longer supported by vendors, making their documents unreadable.[23] In order to prevent this, some governments require information to be created and exchanged in formats such as ODF[24]  and HTML[25].

In addition, governments are increasingly making their data available to anyone who would like to use these data, since public sector information has great economic potential and may lead to innovative new services.[26] This can also lead to requirements on the format of the data, since if they are made available to third parties according to standards or other technical specifications, it will be easier for innovators to build new services.

6.1.4.     Consider the need for public access by businesses or citizens

It is important that citizens and businesses wishing to access public sector ICT are not restricted to using certain branded products or applications, and are allowed to use their preferred system to access eGovernment services. 

An important consideration here is the accessibility of public ICT websites for people with disabilities, for example blind and partially sighted people, many of whom need assistive technologies to access websites (which must be interoperable). Public authorities should be aware of the possibility of discriminating against people with disabilities, and should take web accessibility into account in designing their websites.[27]

It is recommended that, where possible, organisations test such applications for interoperability with a range of interfaces and data formats. A number of online tools are available to website developers to test the accessibility of websites on multiple browsers. These typically create screenshots of a website as viewed in several popular browsers.[28]

Even when there are no technical specifications for interoperability (for example in the case of innovative, custom-made applications), a requirement to ensure maximum public access for citizens may be included as an option and the costs of providing this taken into account within the business appraisal. 

6.1.5.     Consider the need to change suppliers or products in the future

It is important that procurement decisions do not lead to organisations being unintentionally tied to certain products or suppliers. The ability to change products or suppliers should be included in one of the procurement options (as this requirement may have cost implications for the solutions procured).

This is particularly important for contracts for ICT services (e.g. for the development and/or maintenance of IT systems). Suppliers, such as system integrators, who develop and manage custom-made systems can retain all the information about the system and make it very difficult to migrate to another supplier in future to maintain or upgrade the system. 

It should therefore be avoided, where possible, to commission excessively bespoke and complex solutions, as these are both very costly and increase the risk of supplier lock-in.

Procurement documents should always provide for knowledge handover at the end of the contract period. Example texts that could be included in procurement documents to avoid lock-in with regard to data and services are provided in the Appendix: Example text 4 and Example text 5.

7.           Long-term business appraisal

Once the ICT needs have been identified, there will be several options for meeting these needs with new procurements. A business appraisal should be conducted to consider the full costs and benefits of a number of options so as to avoid unnecessary expenditure and choose the option offering the greatest value for money over the long term.

7.1.        What to do?

What to do?

Plan ahead

Develop options

Conduct a business appraisal of the options

Who should act?

This activity should be undertaken by the department that will use the ICT solution to be procured. For developing the options, it can work together with IT managers.

7.1.1.     Plan ahead

ICT purchases should be planned ahead to allow time for proper identification of needs. Purchases that need to be done in a hurry (for example, near the end of a contract or licence period) carry the risk of an existing contract being renewed without full consideration of alternative options.

In order to move away from legacy systems that cause lock-in, a long-term implementation plan may be required. This could include engagement with the market to identify the most feasible solution, which might require the procurement of services to modify the existing system, or the procurement over time of elements that are compatible with both the existing system and the standards or other technical specifications that the public authority would like to use for its ICT systems. 

Coordination with other public sector organisations is important to ensure that the new system is interoperable with those with which connections are required. In the case of legacy systems that extend across organisations, a higher level of coordination will be needed (through the ICT strategy) to ensure that change happens at all levels. The use of a formal change management process may help, taking into account both the technical and non-technical elements of moving away from legacy systems creating lock-in.[29]

7.1.2.     Develop options

Depending on ICT needs there may be a number of options to consider for procurement. These will vary significantly according to whether ICT hardware, software, services or the development of bespoke systems are being procured.

In order to minimise the risk of long-term dependence on a single supplier or service provider, options should include the adequate level of openness of the product or service. This could be achieved by:

· Requiring the purchase to implement certain standards or other technical specifications (as mentioned in the discussion above, these should be open for access and implementation by all interested parties).

· Including in the options a requirement for the supplier or service provider to ensure the desired openness in the absence of suitable standards or other technical specifications. This could include requiring the data produced by the system to be available in an open format; or requiring the developer of a system to bear the costs of handing over the necessary documentation to another developer at the end of the contract (thus including 'exit costs' in the price of the contract).

When considering different options, it must be noted that supplier or service provider dependence can occur in many situations, even when the ICT system is not physically acquired, but rather an ICT service is procured (e.g. through outsourcing or moving to the cloud). Provision for openness must therefore be considered in all types of ICT procurement.

 

7.1.3.     Conduct a business appraisal of the options

A business appraisal should be carried out taking into account as far as possible all the costs arising from needs and user requirements. There are likely to be trade-offs between different needs and requirements, so a number of options should be developed and their relative costs and benefits assessed. Clear and useful guidance on how to conduct a business appraisal is provided by the UK Treasury’s Business Case Guidance website and Green Book.[30]

Important components of an appraisal include:

· Consideration of the whole life costs of the ICT options. These include costs of maintenance, operation, changes and upgrades over the life of the purchase (and not just the life of the initial procurement contract). With a view to avoiding lock-in, exit costs are very important. These refer to the costs likely to be incurred in moving to another supplier or product in the future. As an example, the up-front costs of an option using, say, non-standard proprietary technology that cannot be implemented by other suppliers may be lower than a more open solution, but when exit costs are taken into account the more open solution may provide better value for money. On the other hand, non-proprietary products that are relatively cheap to purchase may incur substantial operational costs over their lifetime.

· Other costs of change. These could include training and support of staff (particularly with systems that have bespoke user interfaces), overcoming managerial inertia and coordinating with other departments or public sector organisations.

· The timeframe for the contract. The use of a specific vendor should not be implied after the timeframe provided for in the contract. Awareness of the likelihood of being tied to the vendor should be taken into account and reflected in the contract timeframe. Constraining future purchases to be compatible with existing products is likely to favour the original vendor and restrict competition.

· Consideration of the risk profile of the organisation. Some options may seem more risky than others (for example, choosing a smaller supplier instead of a large well-known one, or a less widely implemented standard). This should be acknowledged and appropriate weights attached to the costs of the options to adjust for the risk. That an option appears riskier than others does not imply that it should be dismissed without assessment of all other factors.

· Benchmarking of costs. Comparing the costs of different options may not be straightforward, particularly with more complex purchases. Wherever possible, examples of similar purchases should be obtained from other public organisations, the private sector and other Member States in order to inform cost assessments. Of particular importance will be examples of exit costs incurred in the past, when organisations have migrated systems.

The Appendix includes an example of an investment appraisal undertaken by the Swedish National Police in order to decide on what ICT infrastructure to procure.

8.           Long-term budgetary planning

Many public sector organisations now operate under more limited budgets. They are also pre-planning their expenditures in various ways. During the ICT procurement planning phase, it is thus important to consider and communicate the budgetary needs. This is particularly important if the upfront costs of the procurement are likely to appear greater than the short-term benefits.

8.1.        What to do?

What to do?

Accurately account for future costs and benefits

Communicate budgetary needs

Who should act?

Long-term budgetary planning should be undertaken by those involved in the planning of the ICT procurement. They could include end users, IT managers and procurement officers.

8.1.1.     Accurately account for future costs and benefits

Within the business appraisal, evaluators should consider the short- and long-term costs of all options and discount future costs and benefits to present values to enable an equal comparison.

When comparing new options against existing systems, information will need to be collected on the current and expected future costs of existing systems.

Benchmarking exercises or information sharing with other organisations may help inform assessment of the costs of being locked in and the costs and benefits of moving to more open systems.

8.1.2.     Communicate budgetary needs

Particularly in situations where large upfront costs need to be incurred to bring long-term benefits, it is important to communicate the rationale behind the decision clearly to those responsible for organisational finances. The costs of breaking the locks of legacy systems may seem high in comparison with leaving the system as it is, even though future benefits may outweigh the costs in the long term. An appraisal of the options, taking into account all future costs (including exit costs) and benefits, therefore may well be an important tool in obtaining budgetary approval.

The existence of an overarching ICT strategy may be helpful here in providing additional support when setting out the case for a particular ICT purchase.

In organisations that work within annual budgets, the need for large upfront investment will have to be communicated well in advance.   

9.           Write procurement documents

This advice addresses individual procurers, as represented in the lowest level of Figure 1.

In writing the procurement documents for the ICT to be purchased, all the elements of best practices that have been developed in activities at the centralised and local level should be used and will come together.

9.1.        What to do?

What to do?

Be aware of the legal framework

Avoid unnecessary use of brand names and proprietary technical specifications but reference the appropriate standards or other technical specifications

Include all necessary requests for openness to avoid lock-in

Communicate budgetary needs

Who should act?

The drafting of calls for tender could be a collaborative approach involving different actors at different stages. For example, IT managers may draw up technical specifications, procurement officers can address the general aspects of the tender documents and legal experts can advise on legal aspects.

9.1.1.     Be aware of the legal framework

Procurers must be aware of the legal framework that governs the referencing of standards in procurement documents. For a discussion on how to refer to standards, see also sections 1.2 and 5.1.1.

9.1.2.     Avoid unnecessary use of brand names and proprietary technical specifications but reference the appropriate standards or other technical specifications

Where possible, use templates to help describe the ICT product or system in technology-neutral terms. There are templates for certain products that can be used. Examples include Germany’s BITKOM guides on wording procurement documents in a non-proprietary manner for desktop PCs, notebooks and servers.[31]

And, although they deal primarily with open source software, the OSOR guidelines also contain suggested model texts for the inclusion of standards or other technical specifications in procurement documents.[32]  

9.1.3.     Include all necessary requests for openness to avoid lock-in

Other requests for openness may be made in the procurement documents (in addition to requiring the new ICT purchase to implement or be interoperable with certain technical specifications). These can be included in the award criteria or functional requirements of the technical specifications. 

Bidders may be requested to indicate the costs required to make the solution open to alternative suppliers after the end of the contract period. Example texts are provided in the Appendix.

Care should be taken when assigning weights to different cost categories in the procurement documents, as these could encourage distortions in the way costs are reflected.

10.         Evaluation and feedback

It is important to draw lessons for future procurement from each procurement process and to share best practice and lessons learned. The effect of using certain standards or other technical specifications can be assessed, as well as the accuracy of any cost benchmarking exercises. This evaluation can also be used to assess suppliers in the market in terms of the extent to which they have met required technical specifications in their products or solutions.

Part of the evaluation process could be to assess how the outcome of the procurement exercise meets the wider ICT strategy of the organisation (e.g. how successful was it in enhancing interoperability; or ensuring accessibility?). 

A further useful role of evaluation could be in planning future procurement exercises, for example drawing up a timetable of upgrades and contract renewals to fit in with other procurement exercises, or to identify likely break points where new standards or other technical specifications might impact decisions to buy, upgrade or renew.

Another useful evaluation parameter could be the number of procurement procedures (if any) having been the subject of litigation, arbitration or complaints.

Finally, the feedback provided by those cases, together with the result of the benchmarking exercises, should be integrated in procurement training actions and in the adaptation of practical advice.

10.1.      What to do?

What to do?

Write up case studies of procurement exercises to share best practice

Learn from experience and adapt centralised and local advice accordingly

Who should act?

The drafting of tenders could be a collaborative approach involving different actors at different stages. For example, IT managers may draw up technical specifications, procurement officers can address the general aspects of the tender documents and legal experts can advise on legal aspects.

10.1.1.   Write up case studies of procurement exercises to share best practice

Case studies could include the following elements:

· What standards or other technical specifications were used and what effect this use had.

· How well the procured product or solution was designed and delivered. 

· How the overall costs of the procurement compare to the initial benchmarking exercise, and what adjustments need to be made to future benchmarking exercises.

It may be appropriate to disseminate best practice to other public organisations, including those in other Member States.

10.1.2.   Learn from experience and adapt centralised and local advice accordingly

The experience gained with individual procurements should be fed back to all other activities at centralised level, especially the ‘develop practical advice’ activity, in order to improve it and keep it up to date.

11.         Conclusions

Lock-in is a complex problem to address, which cannot be dealt with only by public procurement. The advice given in these guidelines promote long-term change, providing a strategy on how public authorities, over time, can overcome their lock-in situation without jeopardising business continuity. It requires a long-term commitment at all levels of decision making to make this happen. In Figure 1, we illustrate that by identifying activities that have to be carried out at different levels of the organisation. The need for this commitment at all levels was clearly stated in presentations by experts in the field during a workshop on this topic at the Digital Assembly of 2011.[33] Also required is the development of an extensive amount of knowledge on ICT strategies and standards and other technical specifications, which is an activity that needs continuous work in order to keep up to date with developments in the (fast-moving) ICT market.

The advice given here is just the beginning of a process. Member States that read this will be encouraged to develop specific versions of the guidelines to reflect the choices they make in order to have an efficient and flexible basis for their ICT systems. However, in developing their own guidelines, Member States should consider the value of a common approach across the EU and wherever possible encourage the use of the same standards and technical specifications, in order to come closer to a digital single market.

Appendix 1: Example texts

This Appendix includes examples of text that could be used in procurement documents to achieve various aims. We emphasise that the examples provided are for illustrative purposes only. Readers of this document are recommended to seek legal advice where necessary.

Example text 1: Requesting licences for sharing

“The supplier will grant that the purchasing authority has the right to distribute the delivered application under the European Union Public Licence (EUPLv1.1 or later) or any licence(s) providing the rights stated in the Article 2 of the EUPL.”

Example text 2: General IPR conditions

The ownership of all copyright, trademarks, trade names, patents, and all other intellectual property rights (“IPR”) subsisting in the graphics, website layout, surface content, logos and devices, and the rights to the domain name(s), manuals, training materials or presentations shall vest and shall remain vested in the Commissioners absolutely.

The Commissioners, or the acknowledged owner, shall be and remain the sole owners of all IPR in all data, material, documentation or information inputted, loaded or placed onto the System in any manner, reports generated by or from the System, material or documentation placed on the System, outputs, and end-products.

The successful Tenderer will be required to  indemnify the Commissioners against third- party claims relating to the Commissioners’ use of any software, hardware or intellectual property.

All pre-existing IPR shall remain the sole property of the Party who owned, acquired or developed such IPR.

Bespoke, custom-built and fully managed eTendering system for a government website 

Example text 3: Requesting indemnity

The Contractor shall ensure that any necessary consents and/or licences for any software, instrument, modality or methodology are obtained and in place before use for the purposes of this Agreement (to include but not be limited to ensuring that the Client is vested with all necessary rights so as to enable the Client to enjoy the benefit of the Services for its business purposes). The Contractor hereby indemnifies the Client and shall keep and hold the Client harmless from and in respect of all and any liability, loss, damages, claims, costs or expenses which arise by reason of any breach of third-party Intellectual Property Rights in so far as any such rights are used for the purposes of this Agreement.

Services procurement template from Ireland eTendershttp://www.etenders.gov.ie/guides/Guide_Download.aspx?id=3364

Example text 4: For software systems where the data need to be migrated to future systems from a different provider

In order to ensure that a competitive tender can be used to select another potential provider after the lifetime of the solution supplied under this tender, an anti-lock-in requirement must be met. All technical specifications, interfaces, protocols or formats implemented by the supplied solution and required for the full use of all data created or maintained using the supplied solution during its lifetime must be made available to providers of equivalent technologies who may be awarded a subsequent contract, with no additional costs. Any costs required for migration of data must be borne by the supplier of the supplied solution. Such costs may be minimised by ensuring that the supplied solution uses only , interfaces, protocols or formats that:

1. are implementable by all potential providers of equivalent technologies

2. are developed through an open and transparent process

3. have no restrictions on re-use, and require no payments for re-use

Example text 5: For systems where the system itself needs to be maintainable by a different provider

In order to ensure that a competitive tender can be used to select another potential provider after the lifetime of the solution to be supplied under this tender, an anti-lock-in requirement must be met. All interfaces, protocols or formats implemented by the supplied solution and required for the full use of all data created or maintained using the supplied solution during its lifetime must be made available to providers of equivalent technologies who may be awarded a subsequent contract, with no additional costs. Any costs required for migration of data shall be borne by the supplier of the supplied solution. Such costs may be minimised by ensuring that the supplied solution uses only interfaces, protocols or formats that:

1. are implementable by all potential providers of equivalent technologies

2. are developed through an open and transparent process

3. have no restrictions on re-use, and require no payments for re-use

Furthermore, all documentation needed in order to provide full support for the supplied solution must be made available to any subsequent provider. Any costs of preparing such documentation shall be borne by the provider of the supplied solution.

More examples for sharing and reuse may be found in Deliverable 2.1 Standard "Sharing and re-using" clauses for contracts[34], developed in the context of ISA Action 4.2.5. Sharing and re-use strategy.

Appendix 2: Sources of information

This Appendix lists useful sources of information to complement the text of the Guide.

General procurement guidelines

Other references to procurement best practice. At EU level, these include:

· European Commission (2007) ‘Guide to dealing with innovative solutions in public procurement: 10 elements of good practice’,[35] Commission staff working document SEC(2007) 280

· DETE Ireland’s Buying Innovation: the 10 step guide to smart procurement and SME access to public contracts.[36]

Sources of information for the assessment of standards and other technical specifications

The Common Assessment Method Standards and Specifications (CAMSS)[37] has been developed under the Interoperability Solutions for European Public Administrations (ISA) programme run by the European Commission. CAMSS enables assessments of standards and other technical specifications for ICT interoperability to be shared across Member States

CAMSS offers a neutral method to assist Member States in their assessment of the technical specifications needed to develop interoperable national and cross-border eGovernment services. CAMSS aims to ensure that public administrations can assess and select the most relevant standards and technical ICT specifications for their needs. CAMSS comprises 1) a process, 2) a set of criteria and 3) an assessment library. The CAMSS process describes how to complete an assessment from start to finish using CAMSS criteria. Completed assessments are to be made available in an assessment library to help Member States share and re-use assessments.

Examples of organisations publishing lists that may be of wider interest include:

· The Netherlands Standardisation Forum, which maintains lists of mandatory and recommended open standards.[38]

· The Danish OIO Committee, which maintains a list of open technical specifications and recommendations on their applicability and usefulness.[39]

· The Norwegian Agency for Public Management and eGovernment (Difi), which maintains the Standardisation Forum, a body that provides information on mandatory and recommended technical specifications for the Norwegian public sector. The technical specifications are available from an online catalogue.[40]   

· The French RGI (Référentiel Général d’Interopérabilité), which references standards and other technical specifications that are recognised and supported by standards bodies, and recommended for use by French public authorities. All technical specifications are available online.[41]

· The Malta Information Technology Agency (MITA), which includes the specifications and technologies that have been adopted, or are being considered for adoption, by the Government of Malta in an Adopted Specifications List. This is available on MITA’s website.[42]

· The catalogue of ICT standards of Spain[43].

Development of standards in specific domains

Below are listed some areas of work for which specific standards are currently being developed:

· The 2010-2013 ICT Standardisation Work Programme, provides an overview of ongoing standardisation work.[44]

· Work in the area of eAccessibility under European Commission Mandate 376, which aims to develop a toolkit of recommended technical specifications and templates for procurers to include in procurement documents.[45]

· CEN provides a number of documents that are likely to be relevant to procurers in this respect, mainly in the form of CEN Workshop Agreements (CWAs).[46] These include documents covering:

· Electronic invoicing.[47]

· Electronic procurement.[48]

· Electronic catalogues, and links to classifications used for private and public procurement.[49]

· The PEPPOL project provides information about standards and other technical specifications used for electronic procurement (e-Procurement).[50]

· In the transport domain:

· Open traffic systems: Urban Traffic Management and Control (UTMC) specification in the UK. It  provides technical specifications for shared data (i.e. data communicated between applications of a UTMC system, or between a UTMC system and an external system)[51]

· Open Communication Interface for Road Traffic Control Systems (OCIT) in Germany, Austria and Switzerland, which provides technical specifications for communication between systems[52]

· Smartcard systems: ITSO standard owned by the UK government to avoid proprietary smartcard systems in UK cities. ITSO is a government-backed non-profit organisation which sets a common technical standard to enable interoperable travel[53]

· There is a similar standard called Calypso in other countries of Europe. Calypso is the international electronic ticketing standard for contactless smart cards, originally designed by a group of European transit operators. It ensures multiple sources of compatible products, and enables interoperability between operators[54]

ICT strategies and architectures

The Smartcities’ guide to ICT architectures is another useful source and provides case studies of architectures in the Netherlands, Sweden and Norway.[55]  

In addition, the work of the ISA programme on National Interoperability Frameworks[56] is highly relevant. 

Engaging with the market

The Netherlands Open in Connection website has guidance on communicating with suppliers on the use of open standards, and includes a template manifesto letter to suppliers.[57]  

The Netherlands Open in Connection website provides additional guidance on evaluating suppliers.[58]

Migrating from a lock-in situation

The case study below provides an example of a public authority undertaking a full business appraisal to move away from a proprietary system.

A 2009 study by OSOR.eu investigated the overhaul of the Swedish National Police ICT server infrastructure to move from proprietary to open source software and hardware. The overhaul concerned (i) the application server, (ii) the database, (iii) the operating system of the servers and (iv) the CPUs of the servers. The changeover was the result of a comprehensive case study made in 2006 following realisation that the use of proprietary products created lock-in and was expensive. The study found that using open source products would reduce lock-in and consequently the total cost of ownership from € 40 m to € 21 m over 2006-2011, in addition to improving performance.

As the migration was on a large scale, the changeover process was carefully planned. The first phase, the ‘implementation project’ (2007), involved the procurement of X86 standard hardware and support for the MySQL database and the Linux operating systems, as well as the development and installation of appropriate solutions. The second phase, the ‘migration project’ (2009 onwards), involved the actual migration of 33 legacy systems to the new ICT platform over a two-year period. This phase has required interaction with various stakeholders to convince them of the merits of the new infrastructure. Interaction with experts to devise the optimal migration procedure is also recommended in each instance.[59]

Appendix 3: Costs of implementing the measures proposed in this Guide

The costs of complying with this Guide include the costs of setting up an organisation to develop ICT strategies, to assess technical specifications and develop recommended lists, to develop templates and ready texts and to provide other forms of advice, including training. The upper bound to these costs, extrapolated from numbers received from public authorities already procuring ICT systems based on standards and other technical specifications, and estimated for all Member States together, is some € 53 million.[60]

Using the results of the Commission study estimating the benefits of the procurement directives,[61] it is estimated that doubling the number of bidders could result in a 9 % decrease in contract values in EU public procurement. Given that the total annual value of EU ICT public procurement is some € 78 billion and the maximum total cost of applying this Guide is € 53 million, the number of bidders need be increased by only 0.7 % in order to achieve an offsetting reduction in contract value. Feedback from the 2012 Survey[62] and interviews suggest that this would not be unreasonable, with the majority of respondents indicating that increased use of standards and other technical specifications in public procurement would increase the ability of firms to participate in calls for tender.

[1]               COM/2010/0245, see            http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52010DC0245R(01):EN:NOT.

[2]               http://ec.europa.eu/digital-agenda/en/pillar-ii-interoperability-standards/action-23-provide-guidance-ict-standardisation-and-public.

[3]               OJ L 316, 14.11.2012, p. 12–33

[4]               These are ISO, IEC and ITU.

[5]               ETSI, CEN and CENELEC.

[6]               OJ L 134, 30.4.2004, p. 114–240 .

[7]               http://ec.europa.eu/digital-agenda/en/pillar-ii-interoperability-standards/action-23-provide-guidance-ict-standardisation-and-public.

[8]               http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/study44-survey1results.pdf.

[9]               Although not directly related to the issue of standards, lock-in arising from institutional factors (e.g. staff familiarity with existing products) was noted by 25 per cent of respondents; and lock-in arising from service providers was noted by just under 20 per cent of respondents.

[10]             ‘D2 — Overview of Procurement Practices’. A report by Europe Economics for the European Commission, see http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d2-finalreport-29feb2012.pdf.

[11]             Research based on a review of relevant literature, a survey of procurers and ICT suppliers across the EU and an analysis of a selection of tenders. See Europe Economics (2011) ‘Guidelines for Public Procurement of ICT Goods and Services; D2 — Overview of Procurement Practices’, http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d2-finalreport-29feb2012.pdf.

[12]             http://kkv.se/upload/Filer/Trycksaker/Rapporter/uppdragsforskning/forsk_rap_2013-2.pdf (report of the Swedish Competition Authorities in Swedish, English summary: pages 10-12)

[13]             These examples are illustrations only and do not imply any recommendations to readers.

[14] http://ec.europa.eu/enterprise/sectors/ict/files/ict-policies/report-from-frand-os-conference-22nov12_en.pdf

[15]             https://webgate.ec.europa.eu/fpfis/mwikis/idabc-camss/.

[16]             http://www.sfti.se/sftistartsida/in_english_1.

[17]             http://standard.difi.no/english.

[18] In case a document is stored in a format that is only known by a specific  product, it can happen that future versions of this same product will not be able to read the format in which the document was stored, making the stored document unreadable.

[19]             Department of Enterprise, Trade and Employment (2011) ‘Buying Innovation: the 10 step guide to smart procurement and SME access to public contracts’, see http://etenders.gov.ie/Media/Default/SiteContent/LegislationGuides/25.%20Buying%20Innovation%2010 %20Step%20Guide.pdf.

[20]             JOINUP.eu is dedicated to supporting the sharing of software, semantic assets and open data

[21]             Netherlands Open in Connection, the programme implemented to encourage the adoption of open standards and open source software among the public sector in the Netherlands, see https://www.ictu.nl/archief/noiv.nl/index.html.

[22]             Based on an interview with the head of the advice centre.

[23]             Gamalielsson, J. and Lundell, B. (2011) Open Source communities for long-term maintenance of digital assets: what is offered for ODF & OOXML?, In Hammouda, I. and Lundell, B. (Eds.) Proceedings of SOS 2011:Towards Sustainable Open Source, University of Technology, Tampere, ISBN 978-952-15-2411-0, ISSN 1797-836X, see http://tutopen.cs.tut.fi/sos11/papers/cr6.pdf.

[24]             http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59302.

[25]             http://www.w3.org/TR/1999/REC-html401-19991224/.

[26]           http://ec.europa.eu/information_society/policy/psi/docs/pdfs/report/psi_final_version_formatted.docx

[27]             COM(2012) 721, see,            http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0721:FIN:EN:PDF and     http://ec.europa.eu/digital-agenda/en/news/proposal-directive-european-parliament-and-council-accessibility-public-sector-bodies-websites.

[28]             Examples include BrowserShots (http://browsershots.org/), BrowserCam (http://www.browsercam.com/), NetMechanic Browser Photo (http://www.netmechanic.com/products/browser-index.shtml), Litmus (http://litmus.com/) and AnyBrowser (http://www.anybrowser.com/index.html).

[29]             For example, the ADKAR Change Management Model: http://www.strategies-for-managing-change.com/adkar.html. Please note that this is an example only and many other models exist.

[30]             HM Treasury ‘Business Case Guidance’ http://www.hm-treasury.gov.uk/data_greenbook_business.htm and HM Treasury ‘The Green Book’ http://www.hm-treasury.gov.uk/d/green_book_complete.pdf Chapter 5 deals with options appraisal.

[31]             ITK-beschaffung: http://www.itk-beschaffung.de/en/introduction.html.

[32]             OSOR guidelines on public procurement of open source software IDABC European eGovernment Services (June 2010), https://joinup.ec.europa.eu/sites/default/files/studies/OSS-procurement-guideline-public-final-June2010-EUPL-FINAL.pdf.

[33]             http://ec.europa.eu/information_society/events/cf/daa11/document.cfm?doc_id=18502.

[34] https://joinup.ec.europa.eu/sites/default/files/ISA_Share_Reuse_D_2%201%20Standard%20Sharing%20and%20re-using%20clauses%20for%20contracts_final%20version.pdf

[35]             http://www.proinno-europe.eu/admin/uploaded_documents/procurement_manuscript.pdf.

[36]             Department of Enterprise, Trade and Employment (2011) ‘Buying Innovation: the 10 step guide to smart procurement and SME access to public contracts’, see http://etenders.gov.ie/Media/Default/SiteContent/LegislationGuides/25.%20Buying%20Innovation%2010 %20Step%20Guide.pdf.

[37]             https://webgate.ec.europa.eu/fpfis/mwikis/idabc-camss/.

[38]             Standardisation Forum, Assessment Procedure and Criteria for Lists of Open Standards, www.forumstandaardisatie.nl.

[39]             http://en.itst.dk/it-architecture-standards/standardisation/open-specifications/the-oio-catalogue.

[40]             http://standard.difi.no/english.

[41]             www.references.modernisation.gouv.fr/rgi-interoperabilite.

[42]             https://www.mita.gov.mt/MediaCenter/PDFs/1_GMICT_S_0071_Adopted_Technologies.pdf.

[43]            http://administracionelectronica.gob.es/recursos/pae_000022681.pdf

[44]             See http://ec.europa.eu/enterprise/sectors/ict/standards/work-programme/index_en.htm.

[45]             CEN, CENELEC, ETSTI, AENOR, Online Procurement Toolkit for accessible ICT products and services, p. 29, http://www.mandate376.eu/.

[46]             The European Committee for Standardisation (CEN) is a major provider of European standards and technical specifications. It is the only recognised European organisation under Directive 98/34/EC for the planning, drafting and adoption of European standards in all areas of economic activity, with the exception of electrotechnology (CENELEC) and telecommunications (ETSI).

[47]             http://www.cen.eu/cen/Sectors/Sectors/ISSS/Activity/Pages/eInvoicing_2.aspx.

[48]             ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eProc/cwa15236-00-2005-Feb.pdf.

[49]             http://www.cen.eu/cen/Sectors/Sectors/ISSS/Workshops/Pages/eCAT.aspx.

[50]             http://www.peppol.eu/.

[51]             http://www.utmc.uk.com/index.php.

[52]             http://www.ocit.org/indexE.htm.

[53]             http://www.itso.org.uk/.

[54]             http://www.calypsotechnology.net/).

[55]             Smart Cities ‘Creating Municipal ICT Architectures (2011): http://www.smartcities.info/files/Creating%20Municipal%20ICT%20Architectures%20-%20Smart%20Cities.pdf.

[56]             http://joinup.ec.europa.eu/elibrary/factsheet/national-interoperability-framework-observatory-nifo-factsheets-2012.

[57]             https://noiv.nl/leveranciersmanifest/.

[58]             http://http://noiv.nl/.

[59]             http://joinup.ec.europa.eu/elibrary/document/swedish-national-police-how-avoid-locking-yourself-while-saving-money-pdf.

[60]             http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d4-impact-assessment-prep.pdf.

[61]             The work centred on econometric analysis of the MAPPs database in order to quantify more precisely the benefits of good practice in procurement. This was part of the study carried out for DG MARKT ‘Estimating the Benefits from the Procurement Directives’. http://ec.europa.eu/internal_market/publicprocurement/docs/modernising_rules/estimating-benefits-procurement-directives_en.pdf.

[62]             http://cordis.europa.eu/fp7/ict/ssai/docs/study44-survey2results.pdf.