DELIVERABLE D1.1 Project Quality handbook

Transcription

1 DELIVERABLE D1.1 Project Quality handbook Project Acronym Emergency Responder Data Interoperability Network REDIRNET Grant agreement number Start date of the project 1 st March 2014 Duration 30 months, until 31 st August 2016 Date of preparation Author(s) Responsible of the deliverable Reviewed by Status of the Document 30 th April 2014, 25 th September 2015 (updated) Daniela Macáková, Peter Dohanyos Ardaco peter.dohanyos@ardaco.com Štefan Vanya (Ardaco), Peter Dohanyos (Ardaco), Tomas Kucharik (Ardaco) Final Version 2.0 Dissemination level PU - Public

2 Table of Contents 1 Executive Summary 3 2 Version history 4 3 Glossary 5 4 Deliverable context Purpose of deliverable Related Documents 6 5 Methodology used Methodology used Partner contributions 7 6 Project Quality Handbook Common understanding of REDIRNET vision Project management and Project Governance Structure establishment Description of the project governance structure Establishment of project management structures Decision Making Mechanisms and conflict resolution Risk Management Risk Management plan REDIRNET - Risk analysis from DOW Risk management process Quality management Quality management Issue Management Deliverables Preparation Procedure Deliverable definition Deliverable structure Deliverable preparation procedure Sensitivity of deliverables IPR management of REDIRNET foreground 24 D1.1 Project quality handbook Page 1

3 6.6 Project Reporting Periodic progress reporting Quarterly progress reporting Project Communication External communication toward the European Commission External communication toward third parties in the frame of dissemination activities Internal project communication Document management 27 7 Conclusion 28 8 Annexes 29 1 A. List of Deliverables 29 B. Deliverable Structure (Template) 29 C. List of Milestones 29 D. Quarterly Progress reporting 29 E. Risk Register (template) 29 F. Issue Log (template) 29 G. Reporting periods overview 29 D1.1 Project quality handbook Page 2

4 1 Executive Summary Establishment of project management procedures was the very first action in WP1 - Project management. The Project Quality Handbook gives a practical guidance to coordinator, coordinating bodies (Project Board, Technical Board) and project partners for project management and administration: Common understanding of project mission (subchapter 6.1) and success criteria should drive all work in project and allow keeping common views on various topics. List of Deliverables and Milestones is attached in Annex A and Annex C. Subchapter 6.2 provides information about project management structures based on DOW and Consortium agreement. Establishment of management structures (Project Board, Technical Board, REDIRNET Security Committee) is introduced based on nominations by partner organizations. Decision making mechanisms are in place and project partners are aware of possible conflict resolution techniques. Risk management responsibilities and mitigation strategy was defined in subchapter 0. Quality management in project (subchapter 6.4) is based on proven standards used by project partners for work similar to REDIRNET (management, research and technical development, analytical work). Quality will be under systematic control of WP leaders and coordinator. Deliverables preparation procedure is guidance for preparation of project outputs. Typical structure and process was defined. Template for preparation of deliverables is enclosed in Annex B. Project reporting was structured according to requirements of Framework Programme 7 and quality management on three levels Periodic reports / Quarterly reports. Overview of reporting periods is enclosed in Annex G and template for quarterly reporting is enclosed in Annex D. Project communication options were defined including the approach to make most of communication electronic to save financial and natural resources. Deliverable 1.1 Project Quality Handbook is a cornerstone document for professional management of project of this size and scope in Framework Programme Seven. D1.1 Project quality handbook Page 3

5 2 Version history Version Completion date Changes First draft of document, review by partners Final version of document Updated version based on the recommendation from review meeting mainly formal revision of main document and updated Annex B D1.1 Project quality handbook Page 4

6 3 Glossary CA Consortium Agreement DOW Description of Work FP7 7 th Framework Programme IPR Intellectual Property Rights PQH - Project quality handbook PMI Project Management Institute REA Research Executive Agency RSC REDIRNET Security Committee WP Work package D1.1 Project quality handbook Page 5

7 4 Deliverable context 4.1 Purpose of deliverable Deliverable D1.1 is one of the outputs of Task 1.1 and Task 1.2 and it contributes to fulfilling their objectives as explained further. The aim of PQH is to outline quality management structures and procedures, risk management and quality control mechanisms and to provide project consortium with the guidance for project outputs reporting. In a broad sense the purpose of the PQH is to ensure that all project deliverables and reports are submitted in due date and in required quality. The main objectives of deliverable: Express common understanding of project mission Establish project management procedures Put in place risk management and quality control mechanisms Create clear procedures for delivery of quality results Provide consortium with guidance for project reporting Provide consortium with templates for project outputs 4.2 Related Documents Binding documents for project implementation: Grant Agreement DOW REDIRNET work to be made Annex II relations with project sponsor (REA Brussels) Budget Consortium Agreement IPR provisions Project governance structure Administration details FP7 guides: reference_docs.html#fp7 o Guide to Financial Issues relating to FP7 Indirect Actions o Guidance Notes for Beneficiaries and Auditors o Amendments Guide for FP7 Grant Agreements o Guidance Notes on Project Reporting, Template for Periodic Report, Template for final report o Guidance notes on project technical review, Template for technical review o Guide to Intellectual Property Rules for FP7 project Accounting legislation, internal corporate rules, etc. D1.1 Project quality handbook Page 6

8 5 Methodology used 5.1 Methodology used Project quality handbook was created based on best practice experience from previous collaborative FP7 projects of project partners. The scope of project quality and management handbook has been drafted by project coordinator. In the next step, this draft was discussed on the kickoff meeting in Bratislava on 26 th March 2014 during WP1 presentation. Finally the deliverable was reviewed by a person outside the preparation team and his remarks were implemented by deliverable responsible person. This deliverable is Public and its final version is going to be published on the project website. Due to confidentiality and IPR issues, some deliverable parts don t include all facts but it is necessary to read them in relation with other project documents mentioned in chapter 4.2 such as Consortium Agreement or Description of Work. Methodology of Project quality handbook is based on PMI standards. The main deliverable document is supported by Annexes that contain the following information: List of Deliverables Deliverable structure (template) List of Milestones Quarterly Progress reporting (template) Risk register (template) Problem log (template) Reporting periods (overview) This document can be updated based on the lessons learned in REDIRNET. 5.2 Partner contributions Ardaco as the beneficiary in charge of D1.1 has created the deliverable structure, concept and first complete draft of Chapter 6 Project Quality Handbook. In the next step it was reviewed by other beneficiaries. Remarks by partners were incorporated online via the SVN document management system. D1.1 Project quality handbook Page 7

9 6 Project Quality Handbook 6.1 Common understanding of REDIRNET vision REDIRNET - Emergency Responder Data Interoperability Network, will provide a decentralized framework for interoperability for first responders systems based on a public meta-data gateway controlled by the agencies themselves via a REDIRNET socio-professional web. Agencies will be able link up to partner agencies of their choice and operational need; they will also be able to manage the scope of such interoperability. To help set up these link-up arrangements REDIRNET will be enhanced with semantic web methods in accordance with the vocabulary and processes of the user community. Inter-operating agencies will need only to develop one gateway (to REDIRNET) leading to a cost effective solution; agent technologies will also be developed to facilitate the integration of user systems into REDIRNET. A content management system is software that allows you to create and manage webpages easily by separating the creation of your content from the mechanics required to present it on the web. ReDIRNET META-DATA Gateway Aim of REDIRNET project is to provide a Common Meta-Data Gateway combined with a socio-professional networking system where each agency can set the visibility and controllability of its data per partner agency and per data field. D1.1 Project quality handbook Page 8

10 6.2 Project management and Project Governance Structure establishment Description of the project governance structure Project governance structure was outlined in Description of work. Governing structure is based on democracy, co-determination and clear leadership and responsibility. Main management tasks are the coordination of scientific work and review of project deliverables, ensuring the common vision of the project, the integration of heterogeneous business cultures and general administration of project. The responsible persons are nominated in line with Consortium agreement provisions. Individual roles are described in detail in this section below. Project Coordinator Ardaco, a.s. Coordinator is responsible for the general administration and running of the project. Coordinator personnel: Peter Dohányos for technological/scientific aspects (until Stefan Vanya); Peter Dohányos for administrative, financial and legal aspects (until Daniela Macáková). D1.1 Project quality handbook Page 9

11 Main responsibilities of Coordinator: Liaising with the European Commission and facilitating audits; Collating all deliverables, milestones and technical reports; Management of contractual, ethical, legal and financial information; Organizing and chairing Project Board meetings; General administration. Only the coordinator is allowed to communicate with the European Commission. Project Board The project Board has been empowered to ensure the overall success of the project and resolve any contractual issues within the consortium and for the European Commission. The Board is responsible for overseeing the development of the project and reviewing its progress in accordance with each work package, milestone, objective and deadline. The board will follow a gated management system which will enable them to control the direction and speed of the project, by signing off the completion of each work package and the performance of each partner involved. The project Board consists of 1 senior representative from each Partner in the Consortium, who is authorized to make decisions on their organizations behalf to avoid any unnecessary delays. Main responsibilities of Project Board: Ensure the overall success of the project and resolve any contractual issues within the consortium; Review the progress of work packages in accordance with each work package, milestone, objective and deadline. Project Board must approve any change with respect of the DOW. Technical Board The Technical Board will support the project Coordinator by monitoring the progress of each of the work packages and coordinating activities between each of the Work Package leaders on monthly basis (teleconference or personal meeting). The Technical Board is responsible for managing the project risk log and contingency plans and will therefore also be acting as the project Risk Manager. The technical board consists of WP leaders and will be chaired by Project Coordinator. Main responsibilities of Project Board: Monitors the progress of each work package and coordinates activities between Work Package leaders; Is responsible for managing the project risk log and contingency plans; Consists of WP leaders and will be chaired by Project Coordinator. Technical Board acts as the principal executive body of the project. D1.1 Project quality handbook Page 10

12 Work package leaders Each Work Package has been allocated a Work Package Leader that is responsible for delivering the objectives outlined in the Work Plan. Main responsibilities of Work package leaders: Ensure timely achievement of all objectives and milestones outlined in the DOW; Ensure the preparation of WP related deliverables; Initiation of corrective action for deviations in the WP; Preparation of Activity and Progress Reports to Technical board about activities progress and possible critical issues; Arrangement of regular technical meetings as required for their WP. Work package leader acts as single point of true for the work package activities. Dissemination and Exploitation Manager The role of the Dissemination and Exploitation Manager is to ensure public outputs during the project lifetime and the future and commercial success of the project. Dissemination material such as technical papers and presentations must be approved and submitted to the relevant journals and technical institutions. In addition he is responsible for organizing and attending conferences and trade shows to disseminate the scientific and technical results of the project. Main responsibilities of Dissemination and Exploitation Manager Manages public outputs during the project lifetime; Is responsible for fulfilling the dissemination plan defined in DOW; Ensures preparation of dissemination materials; Manages the dissemination in relevant journals; Manages the REDIRNET presence on conferences and trade shows. Aurel Machalek of University Luxembourg has been appointed to the position of REDIRNET Dissemination and Exploitation Manager. Advisory Boards REDIRNET User group will consist of emergency communication professionals in different EU member states who will evaluate proposed and performed work on various stages of the project system analysis and design, system implementation and performance monitoring. REDIRNET Security Committee (RSC) was established to assess the sensitivity of information handled by the project (as specified in chapter 6 of DOW). D1.1 Project quality handbook Page 11

13 6.2.2 Establishment of project management structures Project partners are represented in the Project Board as follows: Name Peter Dohányos from 01/08/2014 Stefan Vanya till 31/07/2014 Organisation ARDACO Geoff Naldrett Jean-Christophe Deprez Borka Jerman Blažič Mikel Uriarte Itzazelaia Kamil Knotek from 01/04/2015 Roman Šabata till 31/03/2015 BAPCO CETIC JOZEF STEFAN INSTITUTE NEXTEL PRAMACOM Ladislav Hluchý Aurel Machalek Pavol Homola UISAV UNIVERSITY OF LUXEMBOURG VERDE Project partners are represented in the Technical Board as follows: Name WP1 Leader Peter Dohányos from 01/08/2015 Daniela Macáková till 31/07/2015 WP2 Leader Shaun O Neill WP3 Leader Oscar López Pérez Organisation ARDACO BAPCO NEXTEL WP4 Leader Jan Šídlo from 01/04/2015 Kamil Knotek till 31/03/2015 PRAMACOM WP 5 Leader Tibor Szarka WP 6 Leader Peter Dohanyos from 01/08/2014 VERDE ARDACO D1.1 Project quality handbook Page 12

14 Stefan Vanya till 31/07/2014 WP7 Leader Aurel Machalek UNIVERSITY OF LUXEMBOURG REDIRNET Security Committee (RSC) members: Name Richard Margala Organisation ARDACO Shaun O Neill Jean-Christophe Deprez Tomaž Klobučar Mikel Uriarte Itzazelaia Dušan Plánovský Emil Gatial Aurel Machalek Pavol Homola BAPCO CETIC JOZEF STEFAN INSTITUTE NEXTEL PRAMACOM UISAV UNIVERSITY OF LUXEMBOURG VERDE D1.1 Project quality handbook Page 13

15 6.2.3 Decision Making Mechanisms and conflict resolution The Consortium Agreement provides a set of basic rules for decision-making mechanism as well as for the responsibilities and obligations taken on by the partners and the different governing bodies. The Project Board will have the most senior decision making responsibility, where the each member of the Board has 1 equal vote. Each individual partner will be responsible for their work towards the WP leaders of the work packages they are participating in. All partners have their own internal quality assurance processes that will be used for internal quality management. Each level of management within the project will be able to take decisions accordingly with cooperative and agreement-seeking approach. If this fails the difference in opinion will be escalated to a more senior level. The decision making structure is shown in table below: Management level Responsibility magnitude Responding to: Work package Leader Technical Board Dissemination and Exploitation Manager Project Coordinator Work package tasks and all decisions impacting the deliverables of a work package. Project-level scientific and technical issues, for which contingency actions exist Dissemination and exploitation issues where contingency actions exist Project financial and management issues where contingency actions exist Technical Board Project Board Project Board Project Board In the event of a contingency action not existing for a conflict or action which will render the project unable to complete a deliverable on time and to a budget, the conflict will be presented and discussed within the next project Board Meeting. Conflict resolution Coordinator, supported by WP leaders, is the primary mediator in the case of any conflicts which can cause deviations from work plan and which can result in failing to achieve the objectives of project. Any conflict arising within the project will be solved in accordance with the rules and procedures which are defined in Consortium Agreement. In any underperformance assessed by coordinator, he will report it to General Assembly and European Commission. Management of Knowledge and IPR The partners will respect the confidentiality of facts, information, knowledge, documents or other matters communicated to them as confidential. These aspects and rules of EU Commission in area of intellectual property rights are included in the consortium agreement (CA) by defining in detail rights and obligations of each partner with respect to the Intellectual Property Rights (IPR). D1.1 Project quality handbook Page 14

16 Decision Making Mechanism The Project Board has the most senior decision making responsibility, where the each member of the Board has 1 equal vote. The Project Board shall be chaired by the Co-ordinator's representative. Any decision requiring a vote at a Project Board meeting must be identified as such on the agenda, unless there is unanimous agreement to vote on a decision at that meeting and all Parties are present or represented. Any decision required or permitted to be taken by the Project Board may be taken in accordance with the above: o in a physical meeting or a meeting via teleconference and/or via ; or o without a meeting but with prior notice of at least 7 days, and without a vote, provided that, in such case, (i) a consent in writing, setting forth the decision taken, is signed by the representatives of the Parties with not less than the minimum number of votes necessary to take such decision at a meeting at which all Parties entitled to vote on such decision were represented and were voting, and (ii) the consent has been delivered for signature to all Parties' representatives. The Project Board shall not deliberate and decide validly unless at least two-thirds of its members are present or represented ("quorate"). In voting, each Party shall have a number of votes equal to the percentage that its Project Share bears to the total cost of the Project. Decision making in Project Board (section in CA) In the case of Section (b), decisions shall be taken unanimously by all of the Parties In the case of Section (c), the decision shall be taken by 75% of the votes of the non-defaulting Parties present or represented by proxy at a quorate meeting In the case of Section (h), the decision shall be taken by 75% of the votes of the Parties present or represented by proxy at a quorate meeting In the cases of Sections (a), (d), (e), (f) (g) and (i), decisions shall be taken by a majority of 75% of the votes of Parties present or represented by proxy at a quorate meeting, provided that a Party whose scope of work, time for performance, costs, Project Share or liabilities would be changed, or whose information would be published, disclosed or disseminated, or whose name would be included in a press release, may veto such decisions on Scope (section ) (b) making proposals to the Parties for the review and/or amendment of the terms of the GA in accordance with the provisions of Article II.36 thereof and this CA; (c) deciding within a period of 30 days after having received any proposal made by the Technical Board that the Project Board should propose to the Parties (other than the Defaulting Party) to serve notice on a Defaulting Party in accordance with Section and deciding to assign the Defaulting Party's tasks to specific entity or entities (preferably chosen from the remaining Parties); (h) deciding upon proposals from the Technical Board to propose to the Parties that they enter into a Project Cooperation Agreement with the parties of another project; (a) deciding upon any proposal made by the Technical Board for the allocation of the Project's budget in accordance with the GA, and reviewing and proposing budget reallocations to the Parties; (d) deciding upon any proposal made by the Technical Board for the launching of competitive calls if required by the terms of the GA, and the entering into the GA and this CA of new Parties for participation in the Project; (e) deciding upon any change and exchange of work packages between the Parties and proposing corresponding amendments to the GA; D1.1 Project quality handbook Page 15

17 Decision making in Project Board (section in CA) reasonable grounds. Scope (section ) (f) giving approval pursuant to Section and, where necessary, indicating any conditions associated with such approval; (g) deciding upon procedures and tools for the marking and handling of information exchanged between Parties in the performance of the Project; (i) deciding upon proposals from the Technical Board for the plan for using and disseminating Foreground. Technical Board: Any decision required or permitted to be taken by the Technical Board may be taken in accordance with the below: o in a physical meeting or a meeting via teleconference and/or via ; or o without a meeting with prior notice of at least 7 days and without a vote, provided that, in such case, (i) a consent in writing, setting forth the decision so taken, is signed by the Technical Board members having not less than the minimum number of votes that would be necessary to take such decision at a meeting at which all Technical Board members entitled to vote on such decision attended and were voting, and (ii) the consent has been delivered for signature to all Technical Board members. The Technical Board shall not deliberate and decide validly unless a majority of three fifths (3/5) of its members are present or represented ("quorate"). Where decisions are to be taken unanimously, all Technical Board members must be present or represented at the meeting. Each Technical Board member shall have one vote. Decision making in Technical Board (section in CA) In the case of Section (b) the decision shall be taken unanimously by all of the Technical Board members who are representatives of non-defaulting Parties In the cases of Sections , (a), (c), (d), (e), (f) and (j), decisions shall be taken by a majority of 75% of the votes of the Technical Board members present or represented by proxy at a quorate meeting, provided that in case of Section (c), (d) and (e) a Technical Board member who represents a Party whose scope of work, time for performance, costs, Project Share or liabilities would be changed, or whose information would be published, disclosed or disseminated, or whose name would be Scope (section ) (b) within 10 days after having been informed by the Coordinator thereof, making proposals to the Project Board that the Project Board should, within a period of 30 days, propose to the Parties (other than the Defaulting Party) to serve notice on a Defaulting Party in accordance with Section and that the Project Board decide to assign the Defaulting Party's tasks to specific entity(ies) (preferably chosen from the remaining Parties); (a) making proposals to the Project Board for: allocating the Project's budget in accordance with the GA; reviewing and proposing budget reallocations to the Parties; (c) without prejudice to Section 4, proposing to the Project Board the plan for using and disseminating the Foreground in accordance with Articles II.29 and II.30 of the GA; (d) implementing Article II.12.1 of the GA and deciding upon press releases and (without prejudice to Section 4.4) D1.1 Project quality handbook Page 16

18 Decision making in Technical Board (section in CA) included in a press release, may veto such decisions on reasonable grounds. Scope (section ) joint publications by the Parties with regard to the Project; (e) deciding upon the technical roadmaps with regard to the Project; (f) deciding upon any proposed designation of a third party in charge of part of the management of the Project; In the cases of Sections (g) and (h), and in other cases not referred to in Sections or , decisions shall be taken by the majority of the votes of the Technical Board members present or represented by proxy at a quorate meeting, provided always that a Technical Board member who represents a Party whose scope of work, time for performance, costs or liabilities would be changed, or whose information would be published, disclosed or disseminated, or whose name would be included in a press release, may veto such decisions on reasonable grounds. (j) evaluating opportunities for co-operation with other projects and proposing to the Project Board that it proposes to the Parties that they enter into a Project Cooperation Agreement. (g) deciding upon measures in the framework of controls and audit procedures to ensure the effective day-to-day coordination and monitoring of the progress of the technical work affecting the Project as a whole; (h) management and progressing of the Project; (i) proposing to the Project Board procedures and tools for the marking and handling of information exchanged between Parties in the performance of the Project; (k) generating, updating and distributing to the Parties, a schedule of proposed meetings of committees of standards organisations relevant for the potential submission of Foreground as standards proposals. At the request of any Party, the Technical Board shall (i) generate and distribute to the Parties, a schedule of proposed meetings, or (ii) update and re-distribute, a schedule already generated by the Technical Board, by entering on the schedule, any meeting to which the Party wishes to submit any Foreground as part of a standards proposal, provided the Party informs the Technical Board, in writing, of the date of the meeting at least three months in advance. (l) monitoring the progress of each of the work packages and coordinating activities between each of the Work Package leaders on regular basis (teleconference or personal meeting). (m) managing the project risk log and contingency plans and will therefore also be acting as the project Risk Manager also. REDIRNET Security Committee (RSC) was established to assess the sensitivity of information handled by the project (as specified in chapter 6 of DOW). It consists of a group of representatives from the consortium and it involves end-users with sufficient knowledge of security issues. Each partner has its one representative. The RSC will assess the sensitivity of all deliverables before publication with special focus on possible weakness of the communication system as well the nature of data tested by the end users during demonstration and test with real first responders. Level of dissemination of the related deliverables, reports and publications will be verified with their actual content as limited to the consortium and involved end-users. Special clause 24 in the Grant Agreement was included and monitored by the consortium and REA project and legal officers. D1.1 Project quality handbook Page 17

19 6.3 Risk Management Risk Management plan The project quality handbook puts in place a formal risk management plan for this project. WP leaders will be responsible for ensuring that threats to the successful delivery of the projects objectives are assessed and managed through successful mitigation strategies as part of their normal business processes. The Project Coordinator will be responsible for the Risk and Contingency Management of the overall Work Plan. Each Work Package Leader is required to maintain risk logs on quarterly basis that contain expected risks and an issue log of events that have actually happened. The Project Coordinator will use this information to identify any issues and potential risk which may occur across the different Work Packages. The probability of a risk occurring will be estimated along with the individual and communicative impacts of the risk on the remainder of the project deliverables. Every quarter an evaluation of the project performance against its deliverables will be undertaken, enabling an assessment of the projects progress to be made. These risks will be recorded in a risk register (template is in Annex E), submitted to the Project Coordinator and Technical Manager as part of the quarterly progress reporting and will be reviewed and updated during the project REDIRNET - Risk analysis from DOW The risks identified in DOW will be put into Risk register and reviewed and updated during the project: WP Risk category and description Probability Impact WP3, WP5 WP2, WP3 Legal: The legislation in some countries would not allow integration with a system operated in another country Organizational: In engaging with end-users there is the risk that some information e.g. time dimensions and costs sought by the project whilst not confidential is not wholly available in the public domain and thus accessible to the project. This may have a negative impact on project work in later WPs. Public confidence in first responders and public safety & security concerns are likely to be quoted as why such information is not freely available; organisational and individual professional reputations will also be factors as well. Some of the above could be challenged as not real reasons for releasing information. However the project, when engaging with users, will have to accept whatever limitations on access to information an agency or an individual decides. It should also be remembered that the project exercises no Medium Medium Medium Medium Avoidance / mitigation strategy or contingency plan The trusted components of the system will be under full control of the organization. The early consultations with foreign experts and public authorities. The systems readiness for EU certification. - build upon and positively develop existing trusted relationships - Quality and in-depth research to be undertaken by all project partners - Project partners to ensure such information is generalised / anonymized in terms of source if requested by agency/individual - Certain findings from WP2 and WP3 are to be restricted in terms of their circulation D1.1 Project quality handbook Page 18

20 WP Risk category and description Probability Impact WP3 WP4 authority or governance over public safety and civil protection agencies Financial: There will be more travels required to negotiate and find solution to non-technical interoperability limitations than originally planned in the budget Technical: It would not be possible to follow some standards because of their complexity or technical limitations inhibiting their innovative use WP6 Technical: The interoperability platform because of rigorous security mechanisms will not have sufficient performance as required by users WP3, WP5 Management: Many deliverables in month 29 and 30 might raise capacity problems at the partners. Medium Medium Medium High Medium Low High Medium Avoidance / mitigation strategy or contingency plan The travels will be carefully planned and the reasons for a travel instead of e.g. teleconference will be analysed. The opportunities to reuse a single travel for multiple meetings will be used. The events where discussions on more than one topic could be initiated will be preferred (e.g. workshops). Strict following the standards does not have direct influence on fulfilling of project objectives, the eventual deviations will be discussed in the appropriate standardisation comities. It will be openly presented that the enhanced security mechanisms might influence the performance of the system so that user s expectations are realistic. The more powerful hardware platform is the easiest solution but the optimizations of software modules will be preferred. The deliverables D3.4, D3.5, D3.6, D4.4, D5.2, D5.3 and D5.4 will be prepared continuously in the course of the project and will have internal mid-term releases. At the end of the project they will by consolidated and delivered Risk management process If any risk identified, it should be reported to WP leader and Project Coordinator. Identified risks will be reviewed periodically during teleconferences and GA meetings. D1.1 Project quality handbook Page 19

21 The process will include: Planning WP Leaders review the project requirements and plans; Identification - Techniques used to identify risks may include experience, workshops, structured interviews, work breakdown structures and network analysis. Once identified, risks are validated and entered into the risk register. A qualitative analyses of the risks are then conducted, and they are ranked according to their probability impact scores; Mitigation - To identify mitigation actions and re-assess the risk, leading to a reduction in the severity of risk. Depending upon the risk, the mitigation strategies may include identifying alternative or additional resources, suppliers, technology and skills; Risk review the risks will be reviewed as part of quarterly progress reporting by the Technical Board. 6.4 Quality management Quality management Each Consortium Member will be responsible for the quality of their individual contributions to this project: Change management - changes against plan (DOW) should be reported to project coordinator Issue management - any issues with impact to project implementation should be reported to WP leader and Project coordinator This Handbook recognises that a range of Quality Processes and Standards will be in place with the Consortium Members. The Consortium Members will, therefore, work according Quality Processes and Standards they adopted. Examples include: Quality systems such as ISO 9001:2000 Testing and calibration such as ISO Security management such as ISO Project management such as PMI Health, Safety and Environment Legislation These processes and standards will be used throughout the project lifecycle. Project specific processes related to deliverables and milestones are described later in this Handbook. Each Consortium Member will be responsible for the quality of their individual contributions to this project. As part of their project team, each Consortium Member will identify and maintain a representative for quality for their contributions to this project. The Project Coordinator and Project Board will work with the quality representatives to address any quality issues with individual contributions to the project. The Project Coordinator will be responsible for the review of the project and progress towards the project milestones as described later in this Handbook Issue Management For the purpose of REDIRNET project an issue is defined as an occurrence that if left unchecked would have an adverse effect on the quality or timely delivery of a deliverable or end product. The Project Coordinator and Project Technical Board must be kept aware of all significant issues. D1.1 Project quality handbook Page 20

22 Issue reporting will be through the quarterly progress reports, or where more urgent action is necessary, by direct correspondence between the respective Partner through the WP Leader and the Project Coordinator. Issues will be reported, investigated, solved and actioned at the quarterly reporting cycle or, if necessary, as they occur. The issue log will be maintained according to a template at Annex F of this PQH. The issue log is to be completed and updated by the WP leader and submitted with the quarterly progress report to the Project Coordinator. 6.5 Deliverables Preparation Procedure Deliverable definition Project deliverable is a tangible result of specific activity or more activities in REDIRNET project. It is often related to reporting the result of project task in a consistent document to the project sponsor (REA). Particular deliverables fulfil one or more project objectives. Deliverables are not an end in themselves. They are the physical outputs that enable the Objectives to be achieved. REDIRNET project deliverables are listed in Annex A. Most of REDIRNET deliverables are in the form of a written report, which can encompass extensive amounts of information and data. Beneficiaries should do their best to keep documents concise with clear value added Deliverable structure REDIRNET project deliverables will have common structure described in Annex B. This approach may ease the understanding of deliverable purpose, methodology and added value to both internal team and EC review team. Deliverable structure description: Chapter Objective Extent 1 Executive summary Explains relevance of deliverable to overall project objectives and specific added value. 2 Version history Summarizes history of main changes in the document. 1 page maximum Concise, not limited 3 Glossary Explains acronyms used in the document. Not limited D1.1 Project quality handbook Page 21

23 4 Deliverable context 4.1 Purpose of deliverable 4.2 Related Documents 5 Methodology used 5.1 Methodology 5.2 Partner contributions 6 Main contents of deliverable Subchapters: 6.1 subchapter subchapter 2 Keep the team aware of the purpose of deliverable, its objectives and context. Identify related documents inside project and outside. Explain methodology used to create the deliverable and individual roles of partners. Make the understanding of resource use easy. Body of deliverable. Introduces results of task(s) and new findings. Includes graphs, diagrams and maps of knowledge. 1 page maximum 1-2 pages maximum Concise, not limited 7 Conclusion Summarizes the overall conclusion of deliverable - main achievements, recommendations, issues, etc. 1 page maximum 8 References References used in the document. Not limited 9 Annexes List of annexes Not limited Type and size of font to be used in the deliverable: Heading 1: Font: Arial 16, Bold Heading 2: Font: Arial 12, Bold Heading 3: Font: Arial 11, Bold Table of contents, Text: Font: Arial 11 The template of deliverables is in Annex B of PQH. D1.1 Project quality handbook Page 22

24 6.5.3 Deliverable preparation procedure Purpose of deliverable preparation procedure is to put in place a procedure supporting quality in the project delivery. Its implementation should avoid shortage of time, resources and internal review. Typical schedule of deliverable preparation should be as follows: (1) Planning (deadline 2 months from the related task start) Beneficiary in charge identifies a person responsible for deliverable (Deliverable Author) Deliverable Author: Creates a document based on deliverable template on SVN repository; Defines deliverable context and methodology (Chapter 5 and Chapter 6). (2) Main contents creation (during entire task lifetime) Deliverable Author works with co-authors (all partners represented in respective tasks) on Chapter 6 using task results; Regular updates of the document on SVN repository before the monthly Technical Board meeting/tele-conference. (3) First complete draft (deadline 6 weeks before submission date) Deliverable Author is responsible for achieving this deadline; Chapter 6 Main contents of deliverable is drafted completely; Chapter 1 Summary is drafted. (4) Review of first complete draft by work team of task (deadline 4 weeks before submission date) All partners enhance specific parts in chapter 6 and 1; The review at this stage is primarily for content, technical accuracy and feasibility. (5) Pre-Final review by Author (deadline 2 weeks before submission date) Deliverable Author approves/rejects partner contributions in the document, makes final changes. (6) Final review by Project Coordinator and Technical Project Manager and Submission to NEF (submission date = last day of due month in DOW) Includes spell-check, formatting and final contextual changes Sensitivity of deliverables The sensitivity of deliverables under preparation will be considered by Project Board during their regular meetings: In general dissemination level of deliverables will be taken from the DOW; Proposed changes of dissemination level against the DOW must be presented to the Project Board with appropriate justification; Project Board either refuses the change or mandates Project Coordinator to communicate the change to European Commission. D1.1 Project quality handbook Page 23

25 6.5.5 IPR management of REDIRNET foreground Processes of IPR and access rights management are defined in REDIRNET consortium agreement (CA). The CA: Defines the duties and competences of the established project bodies in relation to IPR management (Project Board and Technical Board); Specifies the Background of each partner brought to the project in order to achieve the desired results defined by REDIRNET project objectives; Defines the processes for Foreground IP management. The definition in CA assures the ownership of particular Foreground by the Party who carried out the work generating it. The REDIRNET CA also defines processes to manage the jointly generated Foreground; Specifies access rights to the specified Background and Foreground in line with guidelines for FP7 IPR management; Defines processes for non-disclosure of confidential assets (Non-disclosure agreement); Defines processes for the publication of project results. All the IPR related questions will be addressed in good faith discussions between the partners. 6.6 Project Reporting Periodic progress reporting Creation of Periodic progress reports is foreseen by the Grant agreement and Description of work. REDIRNET project is divided in 2 reporting periods: Period 1 March 2014 to May 2015 (15 months) Period 2 June 2015 to August 2016 (15 months) The Consortium is required to submit a periodic project report within 60 days after the end of the respective period as detailed by GA Annex II.4. The report is to include: An overview of the progress of work towards the project objectives, including achievements and attainment of any milestones and deliverables identified in the DOW; An explanation of the use of the resources; Financial statement from each Consortium Member together with a summary financial report consolidating the claimed grant of all the Consortium Members in an aggregate form based on the information provided at Annex VI (Form C) to the Grant Agreement. The periodic report will be collated by the project coordinator from the inputs listed above as provided by each Consortium Member. To achieve the required timescales, the project coordinator will require the following: D1.1 Project quality handbook Page 24

26 An overview of progress from each work-package leader and an explanation of resources within 30 days after the end of the respective period; Financial statements within 45 days after the end of the respective period Quarterly progress reporting Every project beneficiary submits the Quarterly progress report based on template in Annex D. This duty is for each active Work-Package. Partners submit to project coordinator on quarterly basis by 20 th day following the end of the relevant period: Q1 (Month 1 Month 3) Q2 (Month 4 Month 6) Q3 (Month 7 Month 9) Q4 (Month 10 Month 12) Q5 (Month13 Month 15) Q6 (Month 16 Month 18) Q7 (Month 19 Month 21) Q8 (Month 22 Month 24) Q9 (Month 25 Month 27) Q10 (Month 28 Month 30) Overview of progress reporting periods is summarized in Annex G. Quarterly progress reporting is an internal procedure serving for project management mechanisms. 6.7 Project Communication External communication toward the European Commission The project coordinator and his deputy will act as single point of contact at the external communication toward the European Commission for the whole project and for each project partner. The means of communication will be selected in line with the Grant Agreement. For common information sharing and explanative communication, standard s will be used if it s enabled by the Grant agreement at a given case. The Grant agreement also specifies contact details of project coordinator and the European Commission responsible person External communication toward third parties in the frame of dissemination activities The external communication toward third parties in the frame of dissemination activities will be managed by Dissemination and Exploitation Manager. The rules and restrictions of such communications are stated in Consortium Agreement signed by all the partners. The means of communication will consist of marketing materials on web pages or flyers. Also workshops and field D1.1 Project quality handbook Page 25

27 tests will be organised to inform stakeholder community about the partial or final results of the project. In case of dissemination activities and project publications, the beneficiary with the intention sends a notice with a link to document (preferably link to SVN document) to all partners involved at least one week before any publication. All partners have a chance to review the publication outcome. If anybody objects this publication, it is terminated until next Project Board meeting where the issue is resolved Internal project communication Internal project communication will be organised by the appropriate responsible person depending on topic: Communication related to project management topic will be managed by Project Coordinator or his deputy, Communication related to overall technical scope will be managed by Project Coordinator acting as Technical Coordinator of the project, Work package related communication will be managed by work package leader, Other communication among the partners can be organised ad-hoc. At the internal project communication all-level meetings can be organized by using electronic communication means such as video, web or teleconferencing within agreed times and representation. This is the way of reducing costs, effort and making the work as effective as possible. Personal meetings of the Project board and the Technical board should take place every 6 months and/or in the case it is the most suitable way to consult and proceed with project work. Collaboration tools Document server SVN for documents, ftp storage of project pictures Webpage Teleconferences (e.g. webex) Availability of partners (doodle.com) Communication The basic internal information flow practice includes the following: specialized mailing lists used for these groups: redirnet@lists.cetic.be all relevant contacts mailing list Every must be marked in its subject as follows: REDIRNET WP (number) - subject D1.1 Project quality handbook Page 26

28 6.7.4 Document management A web-based project document management tool such as SVN with differentiated access rights has been established: svn://svn.redirnet.eu/redirnet Process of files update: SVN update SVN Get lock SVN Commit Process of adding files: SVN + (adding a file to the repository) SVN Commit All Consortium Members are responsible for ensuring that backup copies of any data files essential to their work are adequately maintained. Masters and backup copies are to be stored in separate locations. Preferred formats of documents circulated in consortium and shared on SVN workspace is.pdf and MS Office D1.1 Project quality handbook Page 27

29 7 Conclusion Project quality handbook outlines the quality management mechanisms and provides guidance to REDIRNET reporting and deliverables. The PQH can be updated later based on the lessons learned in REDIRNET. D1.1 Project quality handbook Page 28

30 8 Annexes A. List of Deliverables B. Deliverable Structure (Template) C. List of Milestones D. Quarterly Progress reporting E. Risk Register (template) F. Issue Log (template) G. Reporting periods overview D1.1 Project quality handbook Page 29