Build and implementation of the OSPAR Data and Information Management System
The monitoring and assessments that take place within the context of OSPAR generate considerable amounts of data and information on the state of the North-East Atlantic. Some datasets cover several decades and represent an important asset for informing on-going decision-making processes.
United Kingdom-London: Information systems
2014/S 016-024505
Contract notice
Services
Directive 2004/18/EC
Section I: Contracting authority
I.1)Name, addresses and contact point(s)
OSPAR Commission
Victoria House, 37-63 Southampton Row
For the attention of: Emily Corcoran
WC1B 4DA London
UNITED KINGDOM
Telephone: +44 2074305200
E-mail: emily.corcoran@ospar.org
Fax: +44 2072423737
Internet address(es):
General address of the contracting authority: http://www.ospar.org
Further information can be obtained from: The above mentioned contact point(s)
Specifications and additional documents (including documents for competitive dialogue and a dynamic purchasing system) can be obtained from: The above mentioned contact point(s)
Tenders or requests to participate must be sent to: The above mentioned contact point(s)
I.2)Type of the contracting authority
European institution/agency or international organisation
I.3)Main activity
Environment
I.4)Contract award on behalf of other contracting authorities
The contracting authority is purchasing on behalf of other contracting authorities: no
Section II: Object of the contract
II.1)Description
II.1.1)Title attributed to the contract by the contracting authority:
Build and implementation of the OSPAR Data and Information Management System.
II.1.2)Type of contract and location of works, place of delivery or of performance
Services
Service category No 7: Computer and related services
Main site or location of works, place of delivery or of performance: No requirement to be located at contracting authority premises.
NUTS code
Service category No 7: Computer and related services
Main site or location of works, place of delivery or of performance: No requirement to be located at contracting authority premises.
NUTS code
II.1.3)Information about a public contract, a framework agreement or a dynamic purchasing system (DPS)
The notice involves a public contract
II.1.4)Information on framework agreement
II.1.5)Short description of the contract or purchase(s)
This tender is to carry out the build, implementation, maintenance and development of the OSPAR Data and Information Management System.
.
Responses should consider the build phase, implementation and requirements for long-term maintenance and development of the system. Reponses to this tender should build on work undertaken to date and based on decisions taken by the OSPAR Commission.
.
The monitoring and assessments that take place within the context of OSPAR generate considerable amounts of data and information on the state of the North-East Atlantic. Some datasets cover several decades and represent an important asset for informing on-going decision-making processes. A previous contract to develop options and specifications for an OSPAR Data and Information Management System to enable the management, flow, interaction, use and communication of data, information and knowledge that would be interoperable with other data and reporting initiatives recommended:
.
a. the decentralised way in which OSPAR data sets are managed is appropriate and should continue, the specifications build on this premise to (a) ensure that all data streams have the necessary infrastructure and metadata standards to allow interoperability and (b) that the data could then be drawn on by a centralised system.
b. that critical preparatory work is required to improve data management.
c. two scenarios for consideration using a modular approach, enabling development to be undertaken in phases, according to ambition and available resources.
d. that there are significant costs for OSPAR to continue with business as usual;
e. the development and implementation of an information and data strategy would reduce costs associated with assessments of data and increase the accessibility and potential use of OSPAR data by Contracting Parties for delivering other obligations, including but not limited to the EU Marine Strategy Framework Directive (MSFD).
.
The system will be critical for realising ambitions of integrated spatial analysis, or developing more innovative assessments likely to be required to deliver ecosystem-based assessments. It has been recommended that the OSPAR information system should enable the interrogation of various datasets (both within and outside OSPAR) and present the results of assessments in a highly visual manner to make them understandable for decision-makers and external audiences.
.
A task group has been set up within the OSPAR Coordination Group to guide the development of the system. A strategy for data and information management was adopted in 2013.
.
Additional context:
.
Assessment and monitoring are key activities of the OSPAR Commission. This section sets out how the data and information are generated, how they are used (a) within and (b) outside OSPAR as well as current challenges in data management and use.
a. Data use within OSPAR:
Monitoring and assessment data are collected by Contracting Parties to fulfill obligations under OSPAR to deliver joint assessment and monitoring and includes contribution to the OSPAR Quality Status Reports (QSR), decadal integrated assessments on the quality of the marine environment of the North-East Atlantic, interim-assessments and periodic evaluations. All OSPAR measures (Decisions and Recommendations) also require implementation reporting, generate data sets and compliance reports.
The OSPAR Convention itself also specifies a range of data, monitoring, and reporting obligations. Annex VI to the OSPAR Convention provides for cooperation in monitoring programs across these thematic areas, joint quality assurance arrangements, the development of scientific assessment tools, and the preparation of assessments. The data release arrangement principles stated in Annex III of OSPAR’s 2005 Rules of Procedure state that:
i. OSPAR is committed to making as much information as possible publicly available;
ii. data-handling arrangements should be properly documented;
iii. quality-controlled and comparable data sets are available for use; and
iv. data-handling arrangements should make efficient use of resources, be clear and transparent, while protecting the privacy and confidentiality of individuals and commercial interests.
In 2010, a renewed Strategy for the Joint Assessment and Monitoring Programme (JAMP) was adopted to provide a framework for developing OSPAR’s monitoring and assessment programmes, with an emphasis on supporting work to implement the MSFD. In July 2011, a Report on Data Handling and Assembling within OSPAR was prepared by the Secretariat to assess the current situation, particularly in relation to Annex VI and JAMP. Key findings of the report included that: data streams were established at different times and are at differing levels of maturity; data are handled by different data handlers (e.g. OSPAR Commission Secretariat, specialised data centres, Contracting Parties) using different handling process, formats and standards; data reporting formats are inconsistent and may not always be adequate to deliver the information OSPAR needs; coordinated QA/QC processes are not in place for many data streams; there is no metadata system nor transparent link with final products; and data are held in different formats in different locations, with varying levels of accessibility.
.
b. Data use outside of OSPAR:
Data reported to OSPAR is also used by Contracting Parties to report against, national, regional and international obligations. It is the aspiration that data collected under the auspices of OSPAR should, where appropriate, contribute to the data and information needs for implementation of the EU Marine Strategy Framework Directive (MSFD), in particular of Art.19.3 (With regard to access to environmental information, Directive 2003/4/EC of the European Parliament and of the Council of 28 January 2003 on public access to environmental information (1) shall apply.
In accordance with Directive 2007/2/EC, Member States shall provide the Commission, for the performance of its tasks in relation to this Directive, in particular the review of the status of the marine environment in the Community under Article 20(3)(b), with access and use rights in respect of data and information resulting from the initial assessments made pursuant to Article 8 and from the monitoring programmes established pursuant to Article 11.
No later than six months after the data and information resulting from the initial assessment made pursuant to Article 8 and from the monitoring programmes established pursuant to Article 11 have become available, such information and data shall also be made available to the European Environment Agency, for the performance of its tasks ).
Since marine regions or subregions are shared both between EU Member States and also with non-EU countries, the MSFD states that ‘where practical and appropriate, existing institutional structures established in marine regions or subregions, in particular UNEP Regional Sea Conventions [including OSPAR] should be used to ensure such coordination’. With this emerging role for the OSPAR Convention, there is an urgent need to ensure that existing data streams are interoperable and fit for purpose, and to streamline monitoring and assessment processes, to avoid duplication of effort in assessment and reporting.
At the European level, the INSPIRE Directive established data infrastructures for spatial information established and operated by EU Member States, to ensure that they are compatible and usable in a Community and transboundary context. To facilitate use of OSPAR data by a wider audience and to meet MSFD reporting requirements, OSPAR must strive to achieve INSPIRE compliance.
The OSPAR Convention also provides a regional framework for Contracting Parties to work together towards fulfilling their obligations under other international conventions and processes. Examples include the Convention on Biological Biodiversity (CBD) and the UN Regular Process for Global Reporting and Assessment of the Marine Environment, including Socio-economic Aspects (the World Ocean Assessment). In this broader context, interoperability with similar systems, e.g. those implemented through other Regional Seas Conventions, would also be desirable.
.
Responses should consider the build phase, implementation and requirements for long-term maintenance and development of the system. Reponses to this tender should build on work undertaken to date and based on decisions taken by the OSPAR Commission.
.
The monitoring and assessments that take place within the context of OSPAR generate considerable amounts of data and information on the state of the North-East Atlantic. Some datasets cover several decades and represent an important asset for informing on-going decision-making processes. A previous contract to develop options and specifications for an OSPAR Data and Information Management System to enable the management, flow, interaction, use and communication of data, information and knowledge that would be interoperable with other data and reporting initiatives recommended:
.
a. the decentralised way in which OSPAR data sets are managed is appropriate and should continue, the specifications build on this premise to (a) ensure that all data streams have the necessary infrastructure and metadata standards to allow interoperability and (b) that the data could then be drawn on by a centralised system.
b. that critical preparatory work is required to improve data management.
c. two scenarios for consideration using a modular approach, enabling development to be undertaken in phases, according to ambition and available resources.
d. that there are significant costs for OSPAR to continue with business as usual;
e. the development and implementation of an information and data strategy would reduce costs associated with assessments of data and increase the accessibility and potential use of OSPAR data by Contracting Parties for delivering other obligations, including but not limited to the EU Marine Strategy Framework Directive (MSFD).
.
The system will be critical for realising ambitions of integrated spatial analysis, or developing more innovative assessments likely to be required to deliver ecosystem-based assessments. It has been recommended that the OSPAR information system should enable the interrogation of various datasets (both within and outside OSPAR) and present the results of assessments in a highly visual manner to make them understandable for decision-makers and external audiences.
.
A task group has been set up within the OSPAR Coordination Group to guide the development of the system. A strategy for data and information management was adopted in 2013.
.
Additional context:
.
Assessment and monitoring are key activities of the OSPAR Commission. This section sets out how the data and information are generated, how they are used (a) within and (b) outside OSPAR as well as current challenges in data management and use.
a. Data use within OSPAR:
Monitoring and assessment data are collected by Contracting Parties to fulfill obligations under OSPAR to deliver joint assessment and monitoring and includes contribution to the OSPAR Quality Status Reports (QSR), decadal integrated assessments on the quality of the marine environment of the North-East Atlantic, interim-assessments and periodic evaluations. All OSPAR measures (Decisions and Recommendations) also require implementation reporting, generate data sets and compliance reports.
The OSPAR Convention itself also specifies a range of data, monitoring, and reporting obligations. Annex VI to the OSPAR Convention provides for cooperation in monitoring programs across these thematic areas, joint quality assurance arrangements, the development of scientific assessment tools, and the preparation of assessments. The data release arrangement principles stated in Annex III of OSPAR’s 2005 Rules of Procedure state that:
i. OSPAR is committed to making as much information as possible publicly available;
ii. data-handling arrangements should be properly documented;
iii. quality-controlled and comparable data sets are available for use; and
iv. data-handling arrangements should make efficient use of resources, be clear and transparent, while protecting the privacy and confidentiality of individuals and commercial interests.
In 2010, a renewed Strategy for the Joint Assessment and Monitoring Programme (JAMP) was adopted to provide a framework for developing OSPAR’s monitoring and assessment programmes, with an emphasis on supporting work to implement the MSFD. In July 2011, a Report on Data Handling and Assembling within OSPAR was prepared by the Secretariat to assess the current situation, particularly in relation to Annex VI and JAMP. Key findings of the report included that: data streams were established at different times and are at differing levels of maturity; data are handled by different data handlers (e.g. OSPAR Commission Secretariat, specialised data centres, Contracting Parties) using different handling process, formats and standards; data reporting formats are inconsistent and may not always be adequate to deliver the information OSPAR needs; coordinated QA/QC processes are not in place for many data streams; there is no metadata system nor transparent link with final products; and data are held in different formats in different locations, with varying levels of accessibility.
.
b. Data use outside of OSPAR:
Data reported to OSPAR is also used by Contracting Parties to report against, national, regional and international obligations. It is the aspiration that data collected under the auspices of OSPAR should, where appropriate, contribute to the data and information needs for implementation of the EU Marine Strategy Framework Directive (MSFD), in particular of Art.19.3 (With regard to access to environmental information, Directive 2003/4/EC of the European Parliament and of the Council of 28 January 2003 on public access to environmental information (1) shall apply.
In accordance with Directive 2007/2/EC, Member States shall provide the Commission, for the performance of its tasks in relation to this Directive, in particular the review of the status of the marine environment in the Community under Article 20(3)(b), with access and use rights in respect of data and information resulting from the initial assessments made pursuant to Article 8 and from the monitoring programmes established pursuant to Article 11.
No later than six months after the data and information resulting from the initial assessment made pursuant to Article 8 and from the monitoring programmes established pursuant to Article 11 have become available, such information and data shall also be made available to the European Environment Agency, for the performance of its tasks ).
Since marine regions or subregions are shared both between EU Member States and also with non-EU countries, the MSFD states that ‘where practical and appropriate, existing institutional structures established in marine regions or subregions, in particular UNEP Regional Sea Conventions [including OSPAR] should be used to ensure such coordination’. With this emerging role for the OSPAR Convention, there is an urgent need to ensure that existing data streams are interoperable and fit for purpose, and to streamline monitoring and assessment processes, to avoid duplication of effort in assessment and reporting.
At the European level, the INSPIRE Directive established data infrastructures for spatial information established and operated by EU Member States, to ensure that they are compatible and usable in a Community and transboundary context. To facilitate use of OSPAR data by a wider audience and to meet MSFD reporting requirements, OSPAR must strive to achieve INSPIRE compliance.
The OSPAR Convention also provides a regional framework for Contracting Parties to work together towards fulfilling their obligations under other international conventions and processes. Examples include the Convention on Biological Biodiversity (CBD) and the UN Regular Process for Global Reporting and Assessment of the Marine Environment, including Socio-economic Aspects (the World Ocean Assessment). In this broader context, interoperability with similar systems, e.g. those implemented through other Regional Seas Conventions, would also be desirable.
II.1.6)Common procurement vocabulary (CPV)
48810000, 72322000
II.1.7)Information about Government Procurement Agreement (GPA)
The contract is covered by the Government Procurement Agreement (GPA): no
II.1.8)Lots
This contract is divided into lots: no
II.1.9)Information about variants
Variants will be accepted: yes
II.2)Quantity or scope of the contract
II.2.1)Total quantity or scope:
The respondents to the call should provide information on the basis of constructing the system using proprietary software. The OSPAR Secretariat does not have the capacity for the ongoing support required to maintain open source options. Where open sources options are considered a viable option, this should be outlined along with consideration of availability of OSPAR based resources.
Scenarios considering the hosting of the system should include consideration of Cloud and physical server based options. Provision should be made of ongoing costings of maintaining a physical server based option in comparison with a cloud based option- this can include the sub contraction of a service provider.
Due to the decentralized nature of OSPAR data management, not all raw data is held by the OSPAR Secretariat. Data is therefore fed to the system via the following three routes:
a. Data Centres, e.g. ICES;
b. hosted by a Contracting Party, e.g. MPA data from France; or
c. directly sourced from data streams compiled in house.
Because of this, a single point upload tool will not be fit for purpose as not all raw data will be directly accessible; the module must be able to handle direct data services from sources external to the Secretariat, as well as direct upload by the system administrators. There is variation in the way data is offered from the numerous sources; the system must therefore be flexible enough to cope with this and to allow the addition of new connections over time.
The following are a list of key modules, with explanations, that the Consultants Report outlined as being needed as a minimum to achieve the goals of implementing the system. This list is not exhaustive; it is merely a guide as to the minimum expected functionality:
Upload tool – A mechanism for data upload- a possible solution would be an FTP based routine. This should allow passing of data onto the web server through an associated basic web interface for upload within the web application to incorporate the data into the database. The web interface could allow manual entry of associated metadata unique to the dataset though the upload routine and should populate the metadata catalogue simultaneously, utilising as much as possible, automated methods. Quality control and validation against agreed reporting formats (to be provided) should be applied at this stage, including functionality to allow administrators to update and adapt validation routines as necessary. Data will be supplied to the tool in the native format for each data stream. Adjustment of the reporting format and therefore the structure that is passed to the upload tool must be adaptable as updates and adjustments to the reporting format are anticipated over time.
Data management tool – This tool is expected to take the form of an interface page where administrators can manage data and services associated with individual data streams. There will be full access to all individual data entries published through the interface- a full listing of data uploaded to the system along with editing capabilities for metadata and removal of entries should be generated.
There should be a ‘holding area’ for data which has been passed through the quality assessment and quality control module, prior to data being published online. This will allow revision and correction of data before publication to the active site once it has been signed off by the responsible body.
Included should be functionality for provision of new data services, editing of existing services and deletion of those that are no longer relevant. Within this, there should be functionality that allows active services to be monitored by the administrator- i.e. to check that services are available and working and an interface for any issues to be resolved.
Map layer creation tool – This tool should automatically convert assessment product data into map layers that can be served online through the map interface. These layers will be made available through both ODIMS and other applications (via web services). There should be an interface for the administrators to oversee this process. This is a technical module that is required in the back-end of ODIMS to enable delivery and visualisation of the data.
Map styling tool – This tool will allow the data administrators to style the map layers created using the ‘map layer creation tool’. The tool should be web based, structurally similar to the rest of the application and should immediately update the styles of data layers when applied.
Web application – This is the basic website landing page of ODIMS which includes the design and lay out of; home, about, help and bibliography pages. All other modules are to sit within the framework of this web application.
This will be a web based user facing introduction to the OSPAR Data and Information Management System which will include clear direction to the Map Viewer along with other supplementary information. Branding of the page is to follow the standard OSPAR template and colour scheme.
Data download functionality – Users will be able to search and download raw data and assessment product data layers in a variety of native formats along with associated metadata. This is to include, where possible, a geospatial format as well as the standard format of the data stream. The method of search will be based on spatial location (selection by area) but should also include a keyword based search function and more advanced search functionality where the chosen software supports this. The management of OSPAR datastreams is decentralised, it is therefore important that OSPAR data held externally to the Secretariat should also be easily accessible via the data download tool. OSPAR data is both spatial and non-spatial and user accessibility should be considered for both.
Assessment product data services – A webpage should be developed allowing users to search for data services. For each data service metadata and documentation on how to access the services will be displayed, including code snippets and recommended software. This will be aimed primarily at technicians aiming to use the data services for analysis or including the data in their own websites. The feature service should be described using an ISO standard, to be confirmed and to be in line with the chosen base software, e.g. Geonetwork. Provision of WFS and WMS services are classed as a minimum requirement.
Map viewer – A map viewer will be developed which will allow users to view each of the data streams and assessment products in a geospatial format. Navigation will include panning and zooming around the OSPAR region with functionality allowing users to click on data layers to find out additional information. The map should take the form of an interactive visualisation of the region using the latest web mapping technology. From the map, the user should be able to access the ‘raw’ assessment product data so they can use the data in their own analysis. Where available, the user should be able to link to data services. The ability to access non-spatial data should be taken into account. This could take the form of a separate interrogable metadata catalogue, or utilising the map viewer.
System training – Provision should be made for training of the administrators in the structure and use of the system. Training should include provision of a manual and is deliverable upon completion of the contract.
Anticipated tasks and products:
The response to the call should incorporate the following elements:
a. Detailed technical specification document for the data and information system
b. System architecture: description of the underlying database system, reasoning for the choice, rejected options and implications for systems operations (does OSPAR have sufficient existing capacity to operate and maintain the chosen option?)
c. System infrastructure, taking into consideration a cloud based approach
d. Implementation plan: an action plan for the build and maintenance phase.
e. Detailed project budget breakdown (on the basis of the recommendations of the Consultant’s report, and the guidance from OSPAR in the anticipated scope for this first phase, the expectation would be that the maximum budget would be in the region of £250 000 for the build, implementation and first two years of maintenance)
f. Project timeline, including milestones for consultation/ interaction with the OSPAR Information System Task Group/ update with relevant OSPAR subsidiary bodies/ iterative consultation process of product;
g. Costed proposal for on going maintenance post build phase- including itemised costings of likely required works and technical support.
h. Examples of relevant previous experience.
Estimated value excluding VAT: 257 000 GBP
Scenarios considering the hosting of the system should include consideration of Cloud and physical server based options. Provision should be made of ongoing costings of maintaining a physical server based option in comparison with a cloud based option- this can include the sub contraction of a service provider.
Due to the decentralized nature of OSPAR data management, not all raw data is held by the OSPAR Secretariat. Data is therefore fed to the system via the following three routes:
a. Data Centres, e.g. ICES;
b. hosted by a Contracting Party, e.g. MPA data from France; or
c. directly sourced from data streams compiled in house.
Because of this, a single point upload tool will not be fit for purpose as not all raw data will be directly accessible; the module must be able to handle direct data services from sources external to the Secretariat, as well as direct upload by the system administrators. There is variation in the way data is offered from the numerous sources; the system must therefore be flexible enough to cope with this and to allow the addition of new connections over time.
The following are a list of key modules, with explanations, that the Consultants Report outlined as being needed as a minimum to achieve the goals of implementing the system. This list is not exhaustive; it is merely a guide as to the minimum expected functionality:
Upload tool – A mechanism for data upload- a possible solution would be an FTP based routine. This should allow passing of data onto the web server through an associated basic web interface for upload within the web application to incorporate the data into the database. The web interface could allow manual entry of associated metadata unique to the dataset though the upload routine and should populate the metadata catalogue simultaneously, utilising as much as possible, automated methods. Quality control and validation against agreed reporting formats (to be provided) should be applied at this stage, including functionality to allow administrators to update and adapt validation routines as necessary. Data will be supplied to the tool in the native format for each data stream. Adjustment of the reporting format and therefore the structure that is passed to the upload tool must be adaptable as updates and adjustments to the reporting format are anticipated over time.
Data management tool – This tool is expected to take the form of an interface page where administrators can manage data and services associated with individual data streams. There will be full access to all individual data entries published through the interface- a full listing of data uploaded to the system along with editing capabilities for metadata and removal of entries should be generated.
There should be a ‘holding area’ for data which has been passed through the quality assessment and quality control module, prior to data being published online. This will allow revision and correction of data before publication to the active site once it has been signed off by the responsible body.
Included should be functionality for provision of new data services, editing of existing services and deletion of those that are no longer relevant. Within this, there should be functionality that allows active services to be monitored by the administrator- i.e. to check that services are available and working and an interface for any issues to be resolved.
Map layer creation tool – This tool should automatically convert assessment product data into map layers that can be served online through the map interface. These layers will be made available through both ODIMS and other applications (via web services). There should be an interface for the administrators to oversee this process. This is a technical module that is required in the back-end of ODIMS to enable delivery and visualisation of the data.
Map styling tool – This tool will allow the data administrators to style the map layers created using the ‘map layer creation tool’. The tool should be web based, structurally similar to the rest of the application and should immediately update the styles of data layers when applied.
Web application – This is the basic website landing page of ODIMS which includes the design and lay out of; home, about, help and bibliography pages. All other modules are to sit within the framework of this web application.
This will be a web based user facing introduction to the OSPAR Data and Information Management System which will include clear direction to the Map Viewer along with other supplementary information. Branding of the page is to follow the standard OSPAR template and colour scheme.
Data download functionality – Users will be able to search and download raw data and assessment product data layers in a variety of native formats along with associated metadata. This is to include, where possible, a geospatial format as well as the standard format of the data stream. The method of search will be based on spatial location (selection by area) but should also include a keyword based search function and more advanced search functionality where the chosen software supports this. The management of OSPAR datastreams is decentralised, it is therefore important that OSPAR data held externally to the Secretariat should also be easily accessible via the data download tool. OSPAR data is both spatial and non-spatial and user accessibility should be considered for both.
Assessment product data services – A webpage should be developed allowing users to search for data services. For each data service metadata and documentation on how to access the services will be displayed, including code snippets and recommended software. This will be aimed primarily at technicians aiming to use the data services for analysis or including the data in their own websites. The feature service should be described using an ISO standard, to be confirmed and to be in line with the chosen base software, e.g. Geonetwork. Provision of WFS and WMS services are classed as a minimum requirement.
Map viewer – A map viewer will be developed which will allow users to view each of the data streams and assessment products in a geospatial format. Navigation will include panning and zooming around the OSPAR region with functionality allowing users to click on data layers to find out additional information. The map should take the form of an interactive visualisation of the region using the latest web mapping technology. From the map, the user should be able to access the ‘raw’ assessment product data so they can use the data in their own analysis. Where available, the user should be able to link to data services. The ability to access non-spatial data should be taken into account. This could take the form of a separate interrogable metadata catalogue, or utilising the map viewer.
System training – Provision should be made for training of the administrators in the structure and use of the system. Training should include provision of a manual and is deliverable upon completion of the contract.
Anticipated tasks and products:
The response to the call should incorporate the following elements:
a. Detailed technical specification document for the data and information system
b. System architecture: description of the underlying database system, reasoning for the choice, rejected options and implications for systems operations (does OSPAR have sufficient existing capacity to operate and maintain the chosen option?)
c. System infrastructure, taking into consideration a cloud based approach
d. Implementation plan: an action plan for the build and maintenance phase.
e. Detailed project budget breakdown (on the basis of the recommendations of the Consultant’s report, and the guidance from OSPAR in the anticipated scope for this first phase, the expectation would be that the maximum budget would be in the region of £250 000 for the build, implementation and first two years of maintenance)
f. Project timeline, including milestones for consultation/ interaction with the OSPAR Information System Task Group/ update with relevant OSPAR subsidiary bodies/ iterative consultation process of product;
g. Costed proposal for on going maintenance post build phase- including itemised costings of likely required works and technical support.
h. Examples of relevant previous experience.
Estimated value excluding VAT: 257 000 GBP
II.2.2)Information about options
Options: no
II.2.3)Information about renewals
This contract is subject to renewal: no
II.3)Duration of the contract or time limit for completion
Starting 28.4.2014. Completion 30.6.2016
Section III: Legal, economic, financial and technical information
III.1)Conditions relating to the contract
III.1.1)Deposits and guarantees required:
III.1.2)Main financing conditions and payment arrangements and/or reference to the relevant provisions governing them:
Payment arrangements to be negotiated.
III.1.3)Legal form to be taken by the group of economic operators to whom the contract is to be awarded:
III.1.4)Other particular conditions
III.2)Conditions for participation
III.2.1)Personal situation of economic operators, including requirements relating to enrolment on professional or trade registers
III.2.2)Economic and financial ability
III.2.3)Technical capacity
III.2.4)Information about reserved contracts
III.3)Conditions specific to services contracts
III.3.1)Information about a particular profession
III.3.2)Staff responsible for the execution of the service
Section IV: Procedure
IV.1)Type of procedure
IV.1.1)Type of procedure
Open
IV.1.2)Limitations on the number of operators who will be invited to tender or to participate
IV.1.3)Reduction of the number of operators during the negotiation or dialogue
IV.2)Award criteria
IV.2.1)Award criteria
The most economically advantageous tender in terms of the criteria stated below
1. Budget. Weighting 20
2. Evidence of relevant previous experience. Weighting 20
3. Feasible project timeline including projected completion date. Weighting 15
4. Knowledge of the role of OSPAR within the North East Atlantic. Weighting 5
5. Experience of relevant policy drivers and associated data infrastructures, including EU. Weighting 15
6. Understanding and consideration of OSPAR capacity. Weighting 10
7. Understanding of existing infrastructure including data and information management within OSPAR. Weighting 15
IV.2.2)Information about electronic auction
IV.3)Administrative information
IV.3.1)File reference number attributed by the contracting authority:
ODIMS
IV.3.2)Previous publication(s) concerning the same contract
no
IV.3.3)Conditions for obtaining specifications and additional documents or descriptive document
Time limit for receipt of requests for documents or for accessing documents: 3.3.2014 – 17:00
Payable documents: no
Payable documents: no
IV.3.4)Time limit for receipt of tenders or requests to participate
20.3.2014 – 17:00
IV.3.5)Date of dispatch of invitations to tender or to participate to selected candidates
IV.3.6)Language(s) in which tenders or requests to participate may be drawn up
English.
IV.3.7)Minimum time frame during which the tenderer must maintain the tender
Duration in months: 12 (from the date stated for receipt of tender)
IV.3.8)Conditions for opening of tenders
Persons authorised to be present at the opening of tenders: no
Section VI: Complementary information
VI.1)Information about recurrence
This is a recurrent procurement: no
VI.2)Information about European Union funds
The contract is related to a project and/or programme financed by European Union funds: no
VI.3)Additional information
VI.4)Procedures for appeal
VI.4.1)Body responsible for appeal procedures
VI.4.2)Lodging of appeals
VI.4.3)Service from which information about the lodging of appeals may be obtained
VI.5)Date of dispatch of this notice:21.1.2014