International Collaboration on Research Data Infrastructure

Transcription

1 Project Acronym Project Title icordi International Collaboration on Research Data Infrastructure Project Number Deliverable Title Quality plan and Risk register Deliverable No. D1.1 Delivery Date 18/01/2013 Author Leif Laaksonen (CSC) ABSTRACT: The Quality plan and Risk register provides an overview of the organization and methodology for ensuring that project quality and risk management is maintained across the whole consortium and throughout the icordi project. icordi (312424) is a Research Infrastructures Coordination and Support Action (CSA) co-funded by the European Commission under the Capacities Programme, Framework Programme Seven (FP7).

2 DOCUMENT INFORMATION PROJECT Project Acronym Project Title icordi International Collaboration on Research Data Infrastructure Project Start 1st September 2012 Project Duration Funding 24 months FP7-INFRASTRUCTURES Grant Agreement No DOCUMENT Deliverable No. D1.1 Deliverable Title Quality plan & Risk register Contractual Delivery Date 12/12 Actual Delivery Date 1/13 Author(s) Reviewer(s) Contributor(s) Work Package No. & Title Work Package Leader Leif Laaksonen (CSC), Ilona Rantakallio (CSC) Francoise Genova (CNRS), Fotis Karayannis (ATHENA), icordi Executive Committee Rob Baxter (UEDIN-EPCC) WP 1 Project Management Leif Laaksonen (CSC) Work Participants Package Ilona Rantakallio (CSC) Estimated Person Months 7 Distribution Nature Public Report Version / Revision 1.0 Draft / Final Total No. Pages (including cover) Final 18 Keywords icordi-info@postit.csc.fi 2

3 DISCLAIMER icordi (312424) is a Research Infrastructures Coordination and Support Action (CSA) cofunded by the European Commission under the Capacities Programme, Framework Programme Seven (FP7). This document contains information on icordi (International Collaboration on Data Research Infrastructure) core activities, findings and outcomes and it may also contain contributions from distinguished experts who contribute as HLSF (High Level Strategic Forum) members. Any reference to content in this document should clearly indicate the authors, source, organisation and publication date. The document has been produced with the funding of the European Commission. The content of this publication is the sole responsibility of the icordi Consortium and its experts, and it cannot be considered to reflect the views of the European Commission. The authors of this document have taken any available measure in order for its content to be accurate, consistent and lawful. However, neither the project consortium as a whole nor the individual partners that implicitly or explicitly participated the creation and publication of this document hold any sort of responsibility that might occur as a result of using its content. The European Union (EU) was established in accordance with the Treaty on the European Union (Maastricht). There are currently 27 member states of the European Union. It is based on the European Communities and the member states cooperation in the fields of Common Foreign and Security Policy and Justice and Home Affairs. The five main institutions of the European Union are the European Parliament, the Council of Ministers, the European Commission, the Court of Justice, and the Court of Auditors ( Copyright The icordi Consortium See for details on the copyright holders. For more information on the project, its partners and contributors please see You are permitted to copy and distribute verbatim copies of this document containing this copyright notice, but modifying this document is not allowed. You are permitted to copy this document in whole or in part into other documents if you attach the following reference to the copied elements: Copyright The icordi Consortium The information contained in this document represents the views of the icordi Consortium as of the date they are published. The icordi Consortium does not guarantee that any information contained herein is error-free, or up to date. THE icordi CONSORTIUM MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, BY PUBLISHING THIS DOCUMENT. icordi-info@postit.csc.fi 3

4 GLOSSARY ABBREVIATION DEFINITION ATHENA BSC CNRS CSC DAITF DoW EC EU GA HLSF icordi PM PMO RDA UEDIN-EPCC WP WPL Athena Research and Innovation Center in Information Barcelona Supercomputing Center Centre National de la Recherche Scientifique CSC- IT Center for Science Data Access and Interoperability Task Force Description of Work European Commission European Union General Assembly High Level Strategic Forum International Collaboration on Research Data Infrastructure Person Months Project Management Office Research Data Alliance The University of Edinburgh Work Package Work Package Leader 4

5 TABLE OF CONTENTS 1 Executive Summary Quality Plan Document Management Deliverable lifecycle Producing the deliverable Authors Schedule Deliverable templates and instructions Reviewing the deliverable Reviewers Review schedule Review process Approving the deliverable Submitting the deliverable to the European Commission Disseminating the work Uploading the deliverables to the wiki and public website Dissemination of the work Internal Monitoring and Reporting Periodic reports to the EC Internal reports to the PMO Quarterly work package reports Quarterly financial reports Risk Plan Risk identification and management Identifying new risks: Roles and responsibilities Assessing the risk Reviewing and monitoring risks Reviewing existing risks Closing risks ANNEX A: icordi Deliverables ANNEX B: Internal Reporting Schedules icordi-info@postit.csc.fi 5

6 1 Executive Summary The Quality Plan defines the organization and the methodology that all partners shall apply throughout the icordi project when delivering project s documents and internal work progress reports. It forms a common standard to guarantee quality for the entire project lifecycle. Especially, this document describes the quality assurance process for the production, review, and approval of the deliverables which have to be submitted to the European Commission according to the icordi Description of Work (DoW). Several actions are described to ensure high quality of the project outcome like the deliverables e.g nomination of the authors in an early phase and nomination of two reviewers for each deliverable to ensure that the content is appropriate and meets the intent and that the topic is covered in a comprehensive manner. Quality plan covers also issues related to the internal monitoring and reporting for the Commission. Internal monitoring and reporting is done through quarterly reporting which consists of financial reporting and work package progress reports. This gives a comprehensive status view and early signals if corrective actions are needed. A project like the icordi with multi-level goals and linkage with global stakeholders, include also dynamic milestones and inclusion, reflecting the rapidly developing momentum in the research data field communities today. It is thus of high priority for icordi to create sustainable processes that are flexible enough to include changes in the global landscape. The risk plan defines the organization and the methodology which is used within the project to identify, assess, monitor and manage risks that might arise in the project. It defines the initial setup of a project-wide register of risks with analysis of their potential effect on the project, steps that have been taken or are planned to reduce the effect and steps to be taken should the risk transpire and create an issue for the project. Further, the risk plan provides guidelines to identify and manage new risks that might arise during the project. The risk plan introduces the dynamic icordi risk register and how it will be used in the project and in the icordi risk management process icordi-info@postit.csc.fi 6

7 2 Quality Plan The Project Management Office (PMO) is responsible for establishing the project quality process and ensuring that project quality is maintained across the whole consortium and throughout the project. The PMO also defines the quality standards for the project and supports the consortium to apply the defined procedures, tools, documents and templates, and monitors on a regular basis, the application of the Quality Plan through actions such as verification of documents and deliverables, participation in reviews and identification and analysis of quality performance indicators. This role is performed throughout the project lifecycle. The Quality Plan shall be applied by all partners and for all deliverables and internal reports. Consortium partners shall supervise and check the work performed by their own staff in accordance with the icordi Quality Plan. This Quality Plan should be interpreted with reference to the icordi Grant agreement No and its Annexes. Different events may cause the content of this document to be modified after its submission to the EC, creating an amendment of the document. For instance: evolution of project characteristics changes of techniques or tools Amendments to this document may be requested by any project partner but each amendment must be reviewed by the PMO and validated by the Executive Committee, before being submitted to the General Assembly (GA) for notice. 2.1 Document Management This section describes the quality assurance process for the management (production, review, approval, submission, and dissemination) of the 13 deliverables of the icordi project, as planned in its DoW approved by the Consortium. It defines standard rules and procedures related to documentation production that all partners shall apply throughout the project Deliverable lifecycle Each of the 13 icordi deliverables (see Annex A) which have to be submitted to the Commission within the next two years will have to undergo an internal review process to ensure their acceptance by the external reviewers and the Commission. For each deliverable, there will be at least two reviewers selected from a different institution than the one to which the deliverable lead partner and authors belong, with at least one of them not involved in the same work package. A member of the PMO is normally an additional reviewer. The PMO reviewer will also take care that the deliverable respects editing guidelines. To support the production of deliverables, the PMO will maintain a deliverable release schedule. This schedule will take into account the due dates of deliverables and the time required for the quality assurance procedure. This schedule will be maintained on the project wiki. The overview of a deliverable lifecycle is illustrated in Figure 1. This process is described more in detail in the following sections. The PMO has the responsibility to collect the deliverables, ensure that the internal reviews are performed in a timely fashion and that the deliverables are submitted to the Commission on schedule. icordi-info@postit.csc.fi 7

8 Figure 1: Deliverable Lifecycle icordi (312424) is a Research Infrastructures Coordination and Support Action (CSA) co-funded by the European Commission under the Capacities Programme, Framework Programme Seven (FP7).

9 2.1.2 Producing the deliverable All the deliverables should take the form of written reports and respect the few guidelines presented in this document Authors For each deliverable a responsible author shall be designated by the work package leader (WPL). This assignment should be made as early as possible, typically at the beginning of the period during which the results should be produced. This assignment must be documented in the wiki and communicated to the PMO. Co-authorship is possible provided it has been agreed by the work package leader. Contributors to the deliverable shall be clearly identified at the beginning of the document Schedule The author(s) of a deliverable shall either inform through the or upload to the wiki the Table of Contents of the deliverable and as much content as possible at least one month before the due date of the deliverable (which is typically the last day of the due month), and inform the appointed reviewers. The completed document shall be either sent by or uploaded to the wiki for review no later than fourteen days before its due date. Authors are encouraged to involve the reviewers in the production of the deliverables as early as possible. Utilising the project s wiki for deliverable production is highly recommended. If the author foresees that a timely production of the deliverable will not be possible, it is her or his responsibility to alert the WPL and the PMO immediately to enable corrective actions Deliverable templates and instructions Standard deliverable templates shall be used by all partners in order to produce standardised documentation. The PMO is responsible for providing the template for the deliverables. This template is a Microsoft Word document, named icordi-d0.0-0.docx and available on the wiki page icordi/templates. When starting working on the deliverable, this template shall be renamed icordi-dx.y-version.docx, where x.y is the deliverables number (e.g. 1.3) and version is an identification of the different versions freely selected by the author (but the same number shall be used in the deliverable title page). Version number shall be less than 1.0 in versions not submitted to the EC (version numbers above zero indicate that the deliverable is in process; version 1.0 is the version submitted to the EC.) In addition to the plain template, a template with clear formatting instructions is also available. The name of this document on the project wiki is icordi-deliverable-templateinstructions.docx. Authors should follow these instructions carefully, and contact the PMO in unclear cases. Each deliverable will have a classification attribute. This attribute defines the confidentiality level: PU = Public PP = Restricted to other programme participants (including the Commission Services) RE = Restricted to a group specified by the consortium (including the Commission Services) CO = Confidential, only for members of the consortium (including the Commission Services) icordi (312424) is a Research Infrastructures Coordination and Support Action (CSA) co-funded by the European Commission under the Capacities Programme, Framework Programme Seven (FP7).

10 2.1.3 Reviewing the deliverable Each of the 13 icordi deliverables which have to be submitted to the Commission within the two years of the project will undergo an internal review process to ensure their quality and compliance with the objectives set for each in the icordi DoW Reviewers The PMO, in collaboration with the Executive Committee, will appoint for each deliverable at least two reviewers. This assignment will be made as early as possible, typically at the same time when the author(s) of a deliverable is/are appointed. This information will be recorded by the PMO on the project wiki. The reviewers will be selected from a different institution than the one to which the deliverable lead partner and authors belong, and at least one of the reviewers will not be involved in the same work package. A member of the PMO will be included in the review process, ensuring in particular that document formatting is done according to the guidelines, and guiding the authors and reviewers in the document management process if necessary Review schedule The reviewers shall review the document for the technical aspects within five working days after the deliverable is due for review (i.e. 14 days before its due submission date). Should a designated reviewer be unable to perform the review within the required time frame, it is the responsibility of the PMO to identify a substitute. In order to facilitate the planning of the review process, the PMO will maintain on the wiki release schedules and timelines, and notify this to the reviewers, once they have been appointed i.e. several months before the due submission date of the deliverable. The remaining days before the due date will be used by the authors to address the comments of the reviewers and make the necessary corrections to complete the deliverable Review process When the author(s) feel that the deliverable is ready for review, they inform the work package leader. The work package leader then informs the reviewers that the document is ready to undergo formal review, mentioning its exact location in the wiki. The deliverable under review is noted in the wiki. The reviewer shall review the deliverable according to the following criteria: Content: The reviewer shall ensure that the content is appropriate and meets the intent, and verifies that the deliverable meets the requirements specified in the DoW. Correctness: The reviewer shall ensure that the deliverable is technically correct, clear, consistent, and testable or verifiable (if appropriate). Completeness: The reviewer shall ensure that the topic is covered in a comprehensive fashion and no sections are incomplete. The reviewer shall read the scope of the work package and the deliverable in the DoW, and list and describe any topic(s) or information related to the deliverable which appears to be missing. Further, the reviewer shall provide suggestions as to what topic(s) or information the author(s) can add to ensure that the scope of the deliverable is complete. The reviewer shall make clear comments and suggestions into the document to help the authors to complete the document. icordi-info@postit.csc.fi 10

11 Although typographical errors found during the review shall be identified and corrected, the emphasis of the review is in technical issues, not editorial issues. Reviewers are also encouraged to give their opinion as whether or not the results of the deliverable should be published also in another form (e.g. brochure, booklet, etc.). Reviewers shall also identify, whenever possible, the novel results that could be highlighted and provide suggestions for target audiences. Finally, the reviewer makes the decision if the deliverable can be approved with given modifications or whether the deliverable needs a re-review. In case a re-review is needed which should remain an exceptional case the reviewers, together with the author(s) of the deliverable and the PMO shall agree on a limited period of extra time allocated to the author(s) to complete the work, after which the deliverable will be again submitted to the reviewers Approving the deliverable Once the review has been completed, and the deliverable has been approved by both reviewers, the PMO will formally approve the deliverable, after consulting the leader of the work package to which the deliverable belongs. In exceptional cases, the PMO and the work package can consult the Executive Committee before approving the deliverable. As an example the Quality Plan and Risk Register should be approved by the Executive Committee, representing the interlinking with the operational work in and between the work packages Submitting the deliverable to the European Commission The PMO has the responsibility to collect the deliverables, ensure that the internal reviews are performed in a timely fashion and that the deliverables are submitted to the Commission on schedule and the document is placed in the internal wiki Disseminating the work The work conducted under the deliverable and its results shall be made available to relevant stakeholders within and outside the consortium Uploading the deliverables to the wiki and public website The PMO will upload each public deliverable to the wiki and to the public website after it has been approved by the EC, together with a brief abstract summarizing the document. PMO will send an to GA and Executive Committee each time a deliverable is uploaded to the wiki to make sure the horizontal exchange of knowledge between all partners is assured Dissemination of the work In order to disseminate as widely as possible the work conducted for the deliverable to the external stakeholders, appropriate options for turning the deliverable into a targeted dissemination material will be considered. These could be a press release, an article, a brochure, a poster, a video, or any other object that can convey in the most appropriate way the results of the work. In order to select the deliverables that are the most suitable for this objective, we will follow a three step process: Reviewers will be asked to indicate in their assessment whether they think the document or part of it could be published in another format, or which results could be highlighted and disseminated in another way. icordi-info@postit.csc.fi 11

12 If a follow-up publication is deemed appropriate, the PMO will contact the dissemination manager to investigate the different options available, their costs, and the expected efforts required to complete the work. The PMO will be responsible for deciding on the action to take and will organize, in collaboration with the dissemination manager, the necessary effort and actions. 2.2 Internal Monitoring and Reporting This section describes the guidelines for the project internal reporting process, which allows monitoring the progress of the project and detecting potential problems at an early stage when they can be corrected more easily. It is useful to distinguish between two categories of reports: periodic reports to the European Commission (every 12 months) o The first icordi review will be conducted after first 6 months internal reports to the icordi PMO (every 3 months) Periodic reports to the EC The EC requests from the consortium a project report every 12 months (defined in GA) and a final report after the project ends. All reports must be completed within 60 days after the period has ended in both cases. These reports, which contain information on the work performed and use of resources for each work package and partners, are sent to the EC by the coordinator. They are accompanied by financial statements (FORM C) which are submitted electronically to the EC (via the participant portal) by each partner Internal reports to the PMO Internal reporting of the progress of the project is done every three months and comprises two types of reports: a work package report a financial report These reports are for internal use only and are not sent to the EC. They are only intended to help the PMO and work packages leaders to monitor the progress of the overall project, work packages and to detect any risk or deviation from the plan at an early stage in order to take the necessary correcting actions on time Quarterly work package reports Quarterly work package reports shall be uploaded by work package leaders to the wiki no later than four weeks after the reporting period. Each work package leader is responsible for ensuring that their work package report contains appropriate information on the progress of the work and is delivered on time to the PMO. Quarterly work package reports shall contain a short summary report of the progress of the work package as a whole during the last three months. The summary will be based on input given by partners (see below). Each partner shall be asked by the leader of the work package in which it is involved to provide a short bullet list of the work performed during the last three months (i.e. partners have to fill in as many reports as the number of work packages they are involved in). Typically, this list will be written by the work package contact person within each partner. This list shall be updated to the wiki at least two weeks before the report is due. icordi-info@postit.csc.fi 12

13 Work package leaders check that reports from each partner corresponds the actual work done, and write a short summary (1-2 pages) of the work performed within their work package during the reporting period. The work package leader shall use the Microsoft Word template provided by the PMO Quarterly financial reports Quarterly financial reports shall be delivered to the PMO no later than three weeks after the reporting period. Each partner is responsible for ensuring that this report contains appropriate information and is delivered on time. Quarterly financial reports shall contain following types of information: Every quarter a detailed report of Person months (PMs) spent by the partner for each work package Every second quarter besides PMs also travel costs are reported CSC and BSC shall provide detailed reports of the use of the budget allocated to them for other costs The PMO is responsible for providing and maintaining the Excel spreadsheet template on which the information shall be compiled. This template is available on the wiki (Administration/ Reporting Internal reporting process and schedules are summarized in Annex B of this document. 3 Risk Plan The icordi Risk Register is a tool available and maintained on the icordi wiki. It is used within the project to identify, assess, monitor and manage risks that might arise in the project. A risk is an event which, when materializing, can have an adverse impact on the objectives of the project. The Risk Register acts as a central repository for all risks identified by the project and provide information such as the risk probability, its potential impact, and the measures that should be taken to reduce the probability of the risk to materialize or mitigate its impact (risk management plan). The first step of an effective risk management plan is to identify all risks associated with the project. The Risk Register is the repository in which all identified risks are documented and maintained, regardless of their category. The risks identified at the stage of the preparation of the project proposal and described in the Description of Work (DoW) form the basis of the initial Risk Register (Table 1), which includes recognized risks within a work package as well as project-level risks that impact on other WPs. Risks within a work package can be risks originating from a work package or risks having impact on a deliverable of a work package. Each risk in the Risk Register contains: A description of the risk. The work package(s), task(s)/subtask(s), or deliverable(s) primarily affected. Its proximity (short-, medium-, long-term). The probability of its occurrence (low, medium, high). The impact level in case that the event actually occurs (low, medium, high). The mitigation actions (the actions taken in advance to reduce the probability and/or impact of the event). A list of persons responsible of monitoring identified risks and mitigating them (risk owner(s)). icordi-info@postit.csc.fi 13

14 The icordi Risk Register is is available on the icordi wiki, at The Risk Register is a living document and shall be regularly maintained through the life of the project. 3.1 Risk identification and management All risks shall be clearly documented in the Risk Register. This section provides guidelines to identify and analyse new risks, besides those already documented in the Risk Register. The PMO is formally responsible for maintaining the Risk Register and, therefore, adding new identified risks to the register. When adding a new risk it should be described according to the procedures described Identifying new risks: Roles and responsibilities Roles and responsibilities in the icordi risk management process are summarized in Table 1. Table 1: Roles and responsibilities Role WP leader Risk owner Project Management Office (PMO) Executive Committee Responsibilities Identify new WP-level risks Track and review assigned risks together with the PMO Identify new project-level risks Track and review assigned risks together with the risk owners/wp leaders for WP internal risks and the Executive Committee for cross-wp risks Manage the risk repository (including closing) Define management plans for cross-wp risks. Make decisions for further actions for risks having significant impact All project team members have access to the icordi Risk Register, but the management of the repository remains the responsibility of the Project Management Office (PMO) and the risk owner(s). This will ensure the validity and completeness of the information in the register. Each risk gets a corresponding reviewer (risk owner) who is usually the leader of the work package (WP) in which the risk might occur, or which is in the best position to mitigate the risk and reduce its impact through the activities of its WP. It is the responsibility of WP leaders to identify WP-level risks, that is, risks that are affecting a specific activity of their WP (e.g., the release of a deliverable, the completion of a specific activity or task, the low level of engagement and contribution of a partner to an assigned task, etc.). When a new risk is identified, the WP leader shall inform the PMO, and the PMO shall inform the Executive Committee when the risk might affect several WPs. Quarterly reports written by WP leaders can also be used to identify new risks in a WP. Alternatively, less formal discussions can take place between a WP leader and the PMO, or between a WP leader and the Executive Committee. It is the responsibility of the PMO to identify risks at project level and, when such risks might have a significant impact on the project, inform the General Assembly about it for further actions. icordi-info@postit.csc.fi 14

15 The Executive Committee shall be the main place where newly identified risks affecting several WPs are discussed, and management plans proposed. Risk analysis and mitigation measures envisaged by the Executive Committee shall be reported to the General Assembly. The Executive Committee shall inform the General Assembly to take decisions for further actions concerning risks which are likely to have a significant impact (medium to high) if occurring Assessing the risk The PMO, together with the relevant WP leaders and risk owner(s), and in collaboration with the Executive Committee when the risk involves several WP activities, shall assess the risk by evaluating the probability and impact of its occurrence, and propose a management plan. This management plan shall describe how to reduce the probability of its occurrence or how to mitigate its impact by adequate actions. Exceptional conditions or issues will be handled by the General Assembly including risk assessment and mitigation to ensure rapid resolution or corrective actions, if necessary, together with the European Commission. 3.2 Reviewing and monitoring risks The Risk Register will be used throughout the project life to aid monitoring identified risks and mitigating them. Risk mitigation activities are pro-active and they seek to reduce the likelihood of occurring risk events. If a risk event occurs the corresponding management plans will be activated in order to reduce the impact of the risk. Table 2: Initial Risk Register Risk Type of risk Probability Impact Mitigation actions Risk owners Securing involvement of the US counterparts in coordination platform General risk WP2 Medium Medium Create a dialogue between NSF and EC Executive Committee Securing involvement of the HLSF members HLSF WP2 High Medium Reduce probability Executive Committee Too little participation of the US and European data practitioners RDA WP2 Medium High Increase the involvement of research communities. Follow-up and corrective actions as soon as realised. Executive Committee EU-US collaboration Specific risk WP1/WP2 Medium Medium Call for a NSF and EC dialog with the research communities involved Executive Committee icordi partners expect more development effort than the WP3 High Medium Manage expectations of icordi input, present as "facilitators" or "reviewers" rather than WP3 Lead icordi-info@postit.csc.fi 15

16 project can deliver, risking icordi reputation Prototypes become decoupled from relevant workshops, risking prototypes serve less purpose, workshops lose relevance Fitting into existing community workshops in an effective way proves challenging, risking lower overall impact from icordi presence Prototype developments take longer than expected, risking fixed workshop deadlines missed Weak engagement with DRIHM2US and ODIP as "external" projects, risking possible political fallout, lower overall "linkage" from icordi and lower project impact Outcomes of prototype demonstrations at workshops are lost, risking prototypes serve less purpose, "developers" Divert resource to bail out troubled prototypes while managing expectations if necessary WP3 Medium High Ensure workshops are planned as part of prototype activities; plan activities as crosscut of Tasks 3.1 and 3.2. WP3 High High Make earliest possible engagements with community workshop organisers. Create flexible template approach to have ready suggestions for workshop organisers WP3 Medium High Descope demos to hit fixed workshop timescales Seek alternative workshops in same theme if necessary WP3 Medium Medium Assign dedicated (UEDIN) icordi point of contact with each project WP3L work to restore relations, seek synergies and possible joint mini-projects if necessary WP3 High Medium Develop standard "workshop report" template to capture the key things we (think we) need Assess workshop WP3 Lead WP3 Lead WP3 Lead WP3 Lead WP3 Lead 16

17 weaker link with rest of icordi (esp. WP2) reporting, revise templates on regular basis Reviewing existing risks Together with the PMO the risk owner(s) tracks and reviews the risk periodically. The risk management is done iteratively. Every risk has a life cycle from the beginning up to its closure. In each phase of the life cycle, the status of the risk is (re-)assessed, including its probability and impact. Depending on the status of the risk, it may be necessary to implement alternative mitigation strategies, continue with existing strategies, or invoke contingency plans. The PMO will ensure the regular review of the risks through its regular meeting. Risks will also be regularly reviewed by the Executive Committee. Executive Committee members will be asked to review the risk register before each meeting and will have the possibility, together with the PMO, to bring any risk to the attention of the Executive Committee by proposing the review of a specific risk as an agenda item Closing risks If the risk review concludes that a risk has no relevance anymore, or if the probability of occurrence became negligible, it will be closed by the PMO by a status change in the Risk Register. The risk item remains in the Risk Register for future reference. icordi-info@postit.csc.fi 17

18 ANNEX A: icordi Deliverables # WP Dissemination Delivery Title level date D1.1 1 Quality plan & Risk register PU 4 D1.2 1 Periodic report, year PU 12 D1.3 1 Periodic report and final reports, year 2 PU 24 D2.1 2 First year report on DAITF Governance Setup PU D2.2 2 Second year report on DAITF Governance Setup PU 24 D2.3 2 Roadmap to achieve full interoperability of EU-US PU 12 data infrastructures D2.4 2 First year report on HLSF analysis programme PU 12 D2.5 2 Second year and final report on HLSF analysis PU 24 programme D3.1 3 First report on community collaboration activities PU 12 D3.2 3 Second report on community collaboration activities PU 24 D4.1 4 Dissemination & collaboration strategy PU 3 D4.2 4 First year report PU 12 D4.3 4 Second year report PU 24 ANNEX B: Internal Reporting Schedules Reporting period 1 September - 30 November December February 2013 Partners send financial reports Partners upload WP reports WP leaders upload WP report 21 December December December March March March March - 31 May June June June June - 31 August September 1 September - 30 November December February December March March - 31 May June September September December December March March June June June 31 August September September September 2014 icordi-info@postit.csc.fi 18