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
Date: 2013-06-25
Institutions: European Commission
Subjects: information society, information technology, public contract, standardisation, user guide

EUROPEAN 
COMMISSION 

Brussels, 25.6.2013  
SWD(2013) 224 final 

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 

{COM(2013) 455 final} 

EN 

   EN 

 
 
 
 
  
 
 
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. 

1.1. 

1.2. 

1.3. 

Introduction .................................................................................................................. 4 

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

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

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-in21 

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 

COM/2010/0245, see 
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52010DC0245R(01):EN:NOT. 
http://ec.europa.eu/digital-agenda/en/pillar-ii-interoperability-standards/action-23-provide-guidance-ict-
standardisation-and-public. 

6 

 
 
                                                 
 
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 237 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  specifications 
(including  ICT  technical  specifications  under  Article  13  of  the  standardisation  Regulation), 
international  standards,  other  technical  reference  systems  established  by  the  European 

technical  approvals,  common 

3 
4 
5 
6 
7 

OJ L 316, 14.11.2012, p. 12–33  
These are ISO, IEC and ITU. 
ETSI, CEN and CENELEC. 
OJ L 134, 30.4.2004, p. 114–240 . 
http://ec.europa.eu/digital-agenda/en/pillar-ii-interoperability-standards/action-23-provide-guidance-ict-
standardisation-and-public. 

7 

 
 
 
                                                 
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 authorities8 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: 

8 
9 

10 

11 

12  

http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/study44-survey1results.pdf. 
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. 
‘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. 
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. 
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)  

8 

 
 
 
 
                                                 
• 

• 

• 

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.  

9 

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

10 

 
 
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: 

• 

• 

• 

13 

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 standard13.   

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 

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

11 

 
 
                                                 
• 

• 

• 

• 

• 

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.  

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

12 

 
 
                                                 
• 

• 

• 

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 

15 

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

13 

 
 
 
                                                 
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 Industry16 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. 

16 
17 

http://www.sfti.se/sftistartsida/in_english_1. 
http://standard.difi.no/english. 

14 

 
 
                                                 
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 

15 

 
 
 
 
 
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 
format18.  

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. 

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. 

16 

 
 
 
                                                 
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: 

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%20
10 %20Step%20Guide.pdf. 

17 

 
 
 
 
                                                 
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 
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. 

require  currently  unavailable 

for  solutions 

important 

that 

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 
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. 

implementing  standards  and  other 

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

18 

 
 
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).  

19 

 
 
 
 
 
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 

20 

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

20 

 
 
                                                 
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  programme21  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.     

21 

22 

Netherlands  Open  in  Connection,  the  programme  implemented  to  encourage  the  adoption  of  open 
standards  and  open  source  software  among 
the  Netherlands,  see 
https://www.ictu.nl/archief/noiv.nl/index.html. 
Based on an interview with the head of the advice centre. 

the  public  sector 

in 

21 

 
 
                                                 
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 

22 

 
 
 
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 ODF24  and HTML25.  

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. 

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. 
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59302. 
http://www.w3.org/TR/1999/REC-html401-19991224/. 

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

23 

 
 
 
                                                 
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 

is  recommended 

that,  where  possible,  organisations 

test  such  applications  for 
It 
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. 

27 

28 

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. 
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). 

24 

 
 
                                                 
 
 
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? 

Plan ahead 

Develop options 

What to do? 

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 

29 

For  example, 
change.com/adkar.html. Please note that this is an example only and many other models exist. 

the  ADKAR  Change  Management  Model:  http://www.strategies-for-managing-

25 

 
 
 
                                                 
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 

technical 
specifications (as mentioned in the discussion above, these should be open for access 
and implementation by all interested parties). 

implement  certain  standards  or  other 

to 

•  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 

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. 

26 

 
 
   
                                                 
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. 

27 

 
 
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. 

28 

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

29 

 
 
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? 

Be aware of the legal framework 

What to do? 

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 

30 

 
 
 
 
 
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. 

31 
32 

ITK-beschaffung: http://www.itk-beschaffung.de/en/introduction.html. 
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. 

31 

 
 
 
                                                 
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: 

32 

 
 
 
 
 
•  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. 

33 

 
 
 
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. 

33 

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

34 

 
 
                                                 
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   

35 

 
 
 
 
 
 
 
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 

36 

 
 
 
 
 
 
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 contracts34, developed in the context of ISA Action 4.2.5. Sharing and 
re-use strategy. 

34 

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

37 

 
 
 
 
 
 
 
 
 
 
                                                 
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 
specifications 

information  for  the  assessment  of  standards  and  other  technical 

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: 

• 

• 

35  
36  

37 
38 

39 

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 

and 

procurement 

http://www.proinno-europe.eu/admin/uploaded_documents/procurement_manuscript.pdf. 
Department  of  Enterprise,  Trade  and  Employment  (2011)  ‘Buying  Innovation:  the  10  step  guide  to 
smart 
see 
http://etenders.gov.ie/Media/Default/SiteContent/LegislationGuides/25.%20Buying%20Innovation%20
10 %20Step%20Guide.pdf. 
https://webgate.ec.europa.eu/fpfis/mwikis/idabc-camss/. 
Standardisation Forum, Assessment Procedure and Criteria for Lists of Open Standards, 
www.forumstandaardisatie.nl. 
http://en.itst.dk/it-architecture-standards/standardisation/open-specifications/the-oio-catalogue. 

contracts’, 

access 

public 

SME 

to 

38 

 
 
                                                 
• 

• 

• 

• 

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 
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 

includes 

The catalogue of ICT standards of Spain43. 

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 

http://standard.difi.no/english. 
www.references.modernisation.gouv.fr/rgi-interoperabilite. 
https://www.mita.gov.mt/MediaCenter/PDFs/1_GMICT_S_0071_Adopted_Technologies.pdf. 

40 
41 
42 
43            http://administracionelectronica.gob.es/recursos/pae_000022681.pdf 
44 
45 

See http://ec.europa.eu/enterprise/sectors/ict/standards/work-programme/index_en.htm. 
CEN, CENELEC, ETSTI, AENOR, Online Procurement Toolkit for accessible ICT products and 
services, p. 29, http://www.mandate376.eu/. 
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). 
http://www.cen.eu/cen/Sectors/Sectors/ISSS/Activity/Pages/eInvoicing_2.aspx. 
ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eProc/cwa15236-00-2005-Feb.pdf. 

46 

47 
48 

39 

 
 
 
                                                 
• 

• 

• 

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 systems52 

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 travel53 

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 
operators54 

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  Frameworks56  is 
highly relevant.   

Engaging with the market 

49 
50 
51 
52 
53 
54 
55 

56 

http://www.cen.eu/cen/Sectors/Sectors/ISSS/Workshops/Pages/eCAT.aspx. 
http://www.peppol.eu/. 
http://www.utmc.uk.com/index.php. 
http://www.ocit.org/indexE.htm. 
http://www.itso.org.uk/. 
http://www.calypsotechnology.net/). 
Smart Cities ‘Creating Municipal ICT Architectures (2011): 
http://www.smartcities.info/files/Creating%20Municipal%20ICT%20Architectures%20-
%20Smart%20Cities.pdf. 
http://joinup.ec.europa.eu/elibrary/factsheet/national-interoperability-framework-observatory-nifo-
factsheets-2012. 

40 

 
 
                                                 
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 €
 21 m over 
2006-2011, in addition to improving performance. 

 40 m to €

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 

57 
58 
59 

https://noiv.nl/leveranciersmanifest/. 
http://http://noiv.nl/. 
http://joinup.ec.europa.eu/elibrary/document/swedish-national-police-how-avoid-locking-yourself-
while-saving-money-pdf. 

41 

 
 
 
                                                 
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  Survey62  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. 

60 
61 

62 

http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d4-impact-assessment-prep.pdf. 
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 
Directives’. 
from 
http://ec.europa.eu/internal_market/publicprocurement/docs/modernising_rules/estimating-benefits-
procurement-directives_en.pdf. 
http://cordis.europa.eu/fp7/ict/ssai/docs/study44-survey2results.pdf. 

Procurement 

Benefits 

the 

the 

42 

 
 
€