Deliverable D1.1
Quality Guidelines

1. ABBREVIATIONS


CA Consortium Agreement
DL Deliverable Leader
EAB External Advisory Board
EC European Commission
EU European Union
GA Grant Agreement
PC Project Coordinator
PP Project partner
PR Partner Reviewer
SC Steering Committee
TL Task Leader
WP Workpackage
WPL Workpackage Leader

2. INTRODUCTION

The present document contains a summary of internal guidelines defined to assure a
correct, timely and smooth implementation of activities to be performed under the project
ERA FABRIC ‘’Framing And Bridging Regional research and Innovation ecosystems
Capacities for a renewed ERA’’ during its whole duration.

They have been defined taking into consideration the formal obligations set out in the project
Grant Agreement signed with the EC and in the Consortium Agreement jointly signed by all
project partners.

The aim of the guidelines is to guarantee that objectives are met in the most effective and
efficient way. They are developed within the scope of Work package 1 of the Project
according to the project description and all applicable rules and guidelines.

The Quality Guidelines provide general rules, structures and procedures for the delivery of
outputs focusing in particular on deliverables, online and offline meetings, bearing in mind
each partner’s different way of operating and finding a common quality assurance system.

They are presented as an handbook containing the basic forms of documents to be used
and clarifying policies, systems, and procedures adopted to implement and improve the
Quality Management System with a special attention to Risk management. These guidelines
establish general principles to be followed by the partners in the day-to-day activities of the
project, with the goal of maintaining uniform quality control procedures and continuously
monitoring their execution. However, it is understood that specific details may be discussed
and decided upon at a later stage, following the decision taken at Steering Committee level.

3. Governance Structure

The organisational structure of the project consortium comprises the following Consortium
Bodies:

The Steering Committee (SC) which is the decision-making body of the consortium.
The Project Coordinator (PC) which is the legal entity acting as the intermediary between
the Project Partners (PP) and the Granting Authority (the EC).
The Work Package Leader (WPL) which is the coordinator of the respective Work Package
(WP).
The External Advisory Board (EAB) which assists and facilitates the decisions made by
the Steering Committee.

 

3.1 Steering Committee (SC)

The Steering Committee is the highest and final decision making board in the project
governance. SC is composed by one representative of each PP authorised to deliberate,
negotiate and decide on all matters listed in Section 6.3.7 of the Consortium Agreement.

The SC works under the coordination of the PC who chairs all meetings of the Steering
Committee, unless decided otherwise by the Steering Committee

The SC monitors and assess the actual progress of the project.

 

3.2 Coordinator (PC)

The project coordinator perform all tasks assigned to it as described in the Grant Agreement
and in the Consortium Agreement.

The Project Coordinator has the following roles:

  • the only official channel for interaction with EU, regarding: submission of
    deliverables, reports (including financial statements and related certification) and
    relationships of consortium with third parties;
  •  monitoring appropriate implementation of actions (progress, compliance with GA/CA,
    milestones achievement, deliverables production, timely reporting, administration
    aspects);
  • assurance of integration of the single WPs in agreement with the WPLs;
  • preparing the meetings, proposing decisions and preparing the agenda of Steering
    Committee meetings, chairing the meetings, preparing the minutes of the meetings
    and monitoring the implementation of decisions taken at meetings;
  • overall coordination of internal communication, keeping the address list of PPs and
    other contact persons updated and available and transmitting promptly documents
    and information connected with the project;
  • administering the financial contribution of the Granting Authority, taking care of
    financial accounting, cost claiming and managing payments to PPs;
  • establishing and maintaining contacts with EAB members, ensuring that a
    non-disclosure agreement is executed between all PPs and each EAB member.

 

3.3 WorkPackage Leader (WPL)

Each Work Package has a designated Work Package Leader (WPL) responsible for:

  • coordinating the Tasks of the Work Package assuring the active involvement of the
    partners in the implementation of the activities and in the production of the
    deliverables of the coordinated WP in compliance with the established deadlines and
    indications given by the Steering Committee;
  • ensuring the quality control of the Tasks and the Deliverable of the Work Package
    the WPL is responsible for;
  • preparing the corresponding high-quality Work Package periodic Reports and
    Deliverables respecting timing and milestones. For this purpose, they will gather all
    contributions needed from the Partners involved in the Work Package
    implementation, starting from the Task leaders (TL);
  • dealing with all issues concerning the implementation of activities described in Annex
    I of the Grant Agreement;
  • monitoring all project activities in order to have regularly an up-to-date idea of state of
    progress of the project, the performance of the concerned PPs responsible for the
    activities of the work package;
  • timely informing the Coordinator of any changes and adjustments to the original Work
    Plan, related to the leaded work package, at any time deemed necessary, in order to
    discuss the issue at the Steering Committee;
  • supporting the Coordinator in handling any disagreement that may arise among the
    Parties involved in the work package execution.
 
 

3.4 External Advisory Board (EAB)

The EAB is appointed and steered by the Steering Committee. The EAB, composed of up to
5 experts in compliance with gender equality criteria.

 

The EAB members are allowed to participate in Steering Committee meetings upon
invitation but have not any voting rights.

 

Finally at Partner level specific persons are identified to take care of:

  • General project management
  • Administrative tasks, controlling and financial management
  • Communication and dissemination tasks

The Project List of Contacts will contain for each PP the staff assigned to each WP specifying their role.

4. OPERATIONAL PROCEDURES 

FOR MEETINGS

In the ERA-FABRIC Project meetings can be arranged at different levels: 

SC meetings, to be held at least every six months, mainly in presence, involving all  PPs. A first calendar will be agreed during the kick-off meetin; 

WPL meetings to be held on-line at least every 2 months, involving all WPLs; 

WP meetings, to be held on –line at any time the WPL consider useful involving the  relevant PPs. 

 

4.1 SC meetings 

4.1.1 Representation in SC meetings 

Any PP: 

  • should be present or represented at any SC meeting;
  • may appoint a substitute or a proxy to attend and vote at any meeting;
  • shall participate in a cooperative manner in the meetings;
  • could be supported by technical experts providing the technical contribution on  the implementation of the activities and on the quality of the products. The technical experts participate in the meetings of the Steering Committee without  having the right to vote.

4.1.2 Convening SC meeting 

The chairperson of the Coordinator convenes ordinary meetings of the Steering Committee  at least once every six months and shall also convene extraordinary meetings when  considered necessary and decided by the SC itself. 

4.1.3 Notice of a meeting 

The chairperson shall give written notice of a SC meeting to each PP as soon as possible  and no later than 14 calendar days preceding an ordinary meeting and 7 calendar days  preceding an extraordinary meeting. In case of in-presence meeting, the written notice shall  be given at least 1 month preceding the meeting including also indicative starting and closing  times and practical information about the venue provided by the hosting PP supporting the  travel organization. 

4.1.4 Sending the agenda 

The chairperson shall prepare and send each PP an agenda no later than 14 calendar days  preceding the meeting, or 7 calendar days before an extraordinary meeting. The agenda will  include clearly the expected contribution from each PP.

4.1.5 Adding agenda items 

Any agenda item requiring a decision by the PPs must be identified as such on the agenda. 

Any PP may add an item to the original agenda by written notice to all of the other PPs no  later than 7 calendar days preceding the meeting and 2 days preceding an extraordinary  meeting. 

During a meeting of the Steering Committee the PPs present or represented can  unanimously agree to add a new item to the original agenda. 

4.1.6 Meeting format 

SC Meetings of the Steering Committee may also be held by tele- or videoconference or  other telecommunication means. 

4.1.7 Meeting minutes 

The chairperson produces minutes of each SC meeting which shall be the formal record of  all decisions taken. He/she sends draft minutes to all PPs within 10 calendar days of the  meeting. 

Decision taken during the SC meeting for are summarized in following format, indicating for  each specific topics, final decision, PPs addressed, affected WPs and, if necessary, a  reasonable deadline for the completion of the action or solution of the issue that has  emerged. 

N. 

Topic 

Decision 

Affected WPs 

Responsibles 

Deadline

      



The minutes shall be considered as accepted if, within 7 calendar days from receipt, no PP has sent an objection to the chairperson with respect to the accuracy of the draft minutes by  written notice.  

The chairperson sends the accepted minutes to all the PPs, and to the Coordinator, who  shall retain copies of them and upload them in the Internal collaboration Platform, in the specific SC meeting folder.  

4.2 WP Leaders meetings 

WPLs will meet regularly at least at bimestrial level to refer about the state of implementation  of each WP. During the meeting each WPL illustrates the progresses made in last period,  detailing the next specific commitments and related responsible and deadline. 

During WPL meetings could emerge some issues to be put at the attention of the Steering  Committee.

The WPL meetings are chaired by the Coordinator and planned on a regular basis during SC  meetings. 

If necessary meeting dates can be modified. In this case the PC will send written notice to all  WPLs at least 1 week before the expected date, including a doodle poll to identify the most  convenient new date. 

The minutes of the WPL meeting will be prepared by the Coordinator in form a list having the following format:  

N. 

WP 

Topic 

Responsibles 

Progresses and Commitments 

Deadline

      



The PC send the WPL meeting minutes to all WPLs within 1 week after the meeting and  upload them in the Internal collaboration Platform, in the specific WPLs meetings folder.  

The minutes shall be considered as accepted if, within 1 week from receipt, no WPL has  sent an objection to the PC with respect to the accuracy of the draft minutes by written  notice. 

5. DELIVERABLES PRODUCTION PROCESS

Project deliverables are the key outputs to be submitted within the scope of a project,  therefore it is of utmost importance to put in place a quality assurance procedure, to be used  as a reference for their preparation, review and final submission. 

Each deliverable is produced within a specific WP and has a main responsible (DL  deliverable leaders) indicated in the “List of deliverables” in the project DoA- part A. 

The DL in collaboration with the WPL identifies the partners contributing to the Deliverable,  (starting from the relevant Task leaders) and for each partner specific reference persons  included in the Project Contact List. 

The DL is responsible for the collection of inputs from the relevant partners contributing to  the deliverable (CPPs) and for the final release of the deliverable. 

All members of the consortium will contribute to the reviewing processes. In particular each  partner identifies a person in charge for the Deliverable review at least 1 month before the  delivery date. The reviewers names and relative e-mail will be communicated to DL and will  be included in the Contact list for the Deliverable. 

Once the first draft of the deliverable is ready the DL sends it to all Partners reviewers (PRs), that are engaged in the reviewing process, that will be based on the Check-list for  Deliverables in Annex 1. 

The PRs are expected provide their feedback, including comments on major aspects,  recommendations for improvements and suggestions for minor changes using the track  change mode.  

The DL will prepare a second draft of the Deliverable, taking into consideration the  comments received by the PRs. At this stage, if necessary, a consultation on-line call will be  arranged with the relevant CPPs. 

Then the DL will send the second draft of the Deliverable to all partners for a final validation  and eventually release the final version of the Deliverable to be uploaded on the EU portal  by the Coordinator. 

The deliverable will be drafted out using the common template agreed at project level and  available in the internal collaboration platform. 

This template has a cover page containing the following information: 

  • Project name and number
  • Project Logo
  • Deliverable Name and number
  • Responsible Partner
  • Contributing Partners
  • Dissemination level
  • Planned date of Delivery
  • Date of Issue
  • Document version

Each deliverable shall contain an Executive summary, a Table of contents and an  Abbreviation list (if useful), an Introduction, the main part containing the specific content of  the document ending with a Conclusion chapter when relevant. 

At the end of the process the deliverable will be uploaded also in the appropriate repository  in the internal collaboration platform In the Deliverables folder. 

The timeline for the different steps in the deliverable production is provided in the table here 

below: 

Table 1: Timeline deliverable production 

WHO 

WHAT 

WHEN 

(deadline)

Deliverable leader 

Collects contributions from the involved  partners, drafts a first version of the deliverable  and sends it to all partners

3 weeks before  the delivery date

All PRs 

Read the deliverable draft and send a revised  version to the deliverable leader

2 weeks before  the delivery date

Deliverable leader 

Arranges a consultation on-line meeting if  necessary, processes the comments received  from partners and sends and eventual second  version to all partners for a final ok

1 weeks before  the delivery date

Deliverable leader 

Receives feedbacks from partners, release the  final version of the deliverable and send it to the  Coordinator

2 days before the  delivery date

Coordinator 

Upload the deliverable in the EU platform Upload the deliverable in the repository in the  internal collaboration platform

delivery deadline

6. INTERNAL COMMUNICATION

To ensure effective internal communication in the project, PPs will agree on the use of digital  channels, such as: virtual communication spaces, specific distribution lists and virtual  calendars. The Internal collaboration Platform will be a structured online repository on  Google drive to be used also for storing all project related documentation.  

Final decision on internal communication means will be taken during the Kick-off meeting.

7. RISK MANAGEMENT  

7.1 General principles 

Risk management in the ERA_FABRIC project has the overall objective of assuring: timely execution of project tasks, milestone achievements and reporting delivery, 

avoidance of defaulting situations by early identification of risks and proposal for their  mitigation; 

having in mind that timely awareness and consequent reactions to potential problems are  crucial for a smooth project implementation. 

The approach to risk management consists of the following five steps: 

  1. risk identification, the main goal of this step is to uncover risks before they actually  arise; 
  2. risk assessment, risks identified in the previous step are assessed taking into  account the probability of occurrence and the level of severity; 
  3. potential risk treatments, for each identified and assessed risk, possible risk  treatments are proposed; 
  4. detailed risk management plan, risk management plan consists of a description of  risks, assessment and treatment procedures, risk indicators, appropriate mitigation  measures and respective responsible persons; 
  5. risk reviewing and continuous evaluation, risk management plan is reviewed  along the entire course of the project. 

Is assumed that Project management will include a continuous monitoring of risks (of both  internal and external origin) focusing on all factors that are critical to the success of the  project. The risk management plan starts form the preliminary analysis carried out during the  project proposal elaboration and included in Part A at the “ List of Critical risks” paragraph. 

 

7.2 Risk identification procedures 

Risks should be reported by any partner as soon as detected: the earliest a risk is detected  the easiest will be minimizing its impact. 

Partners are invited to submit risks anytime using the Risks Identification Table that will be  available in the internal collaboration platform containing the following information fields: 

    • Nature: this field indicates which type of category the risk belongs to. One or more of  the following categories must be selected:
      • Formalisation: risks related to a bad definition of requirements, bad  interpretation of data and / or a lack of inclusion of experts and reference  entities;
      • External: risks related to external inputs, data, technologies, introduction of  new laws of European or national scope, governance framework. Legal  issues will be classified under this category;
      • Organizational: risks related to general workflow of the project;
      • Technical: risks related to technical aspects of the project such as expected  inputs for a certain work package needed earlier than defined in the project  schedule.
    • Description of the risk: this field is used to establish the border conditions of the  risk. Partner has to explain in detail: the risk origin, the trigger for the risk to become  a reality and the risk that the Project is facing;
    • Affected WPs: WPs affected by the possibility of the risk to happen; Observation period: estimation of the time span in which the risk may arise; 
    • Likelihood: a quantitative evaluation of the probability of the risk to concretize during  the Project; 
    • Severity / Impact: a quantitative evaluation of the effect of the risk on the Project  should it happen; 
    • Risk factor: a comprehensive quantification, both in terms of likelihood and impact,  of the importance of the risk for the Project management; 
    • Proposed mitigation action: this field is used to define the proposal of actions to be  undertaken in order to mitigate the probability of occurrence of the risk and its  eventual impact. 

The Risk report must be submitted to Coordinator and Affected WPLs.

7.3 Risk analysis procedures 

After the submission of the risk, Affected WPLs (involving TL if considered relevant) are  asked to place comments on the risk submitted, especially about the quantification of the  likelihood and impact. The quantification of project risks is performed considering the most  likely outcome scenario for all identified risks. This procedure encompasses the definition of  values for:  

    • Likelihood measurement: this measurement describes the perception of the  probability that the selected risk affects the project in an estimated amount of time  (observation period). This information will be used by the relevant WPL and the  Project Coordinator for prioritizing the actions that will help to mitigate the risk.  Possible values of this field are:
      • 5. CERTAIN: is affecting / will affect the project;
      • 4. PROBABLE: not certain, but is likely to affect the project.
      • 3. POSSIBLE: could affect the project 
      • 2. UNLIKELY: will probably not affect the project
      • 1. VERY UNLIKELY: virtually certain not to affect the project.
      •  
    • Severity/Impact Measurement: this measurement describes the perception of the  impact if the risk were realised. Possible values of this field are:  
    • 5. EXTREME Catastrophic effect – the majority of targets will not be met  across the project;
    • 4. MAJOR relevant effect on project performance –-critical targets will be  missed;
    • 3. MODERATE Moderate effect on project performance – local performance  targets will be missed;
    • 2. MINOR Minor effect on project performance – limited effect on targets;
    • 1. NEGLIGIBLE Insignificant effect.<
      •  
  • Risk factor: the result of multiplying Likelihood and Severity gives as result a number  from 0 to 25 (Risk factor) that enables to prioritize the risk importance. 
                    •  

7.4 Risk management procedures 

This part of the process of risk management is aimed at defining and put in place a risk  management plan containing appropriate measures to avoid, mitigate or accept the risks.  

Three possible policies can be applied in order to deal with risks: 

  • Avoid the risk: some risks may be avoided with an adjustment to the project  schedule or approach; 
  • Mitigate the risk: the majority of risks will need a mitigation action to manage them  and try to minimize their impact in the project development. If this strategy is chosen,  then it is necessary to define and describe the mitigation action for managing that  risk. That implies making considerations and detailing when those actions will be  executed and by which partner(s). 
  • Accept the risk: a very small number of risks will be accepted. The acceptance of a  risk means that all the actions that can be applied to minimize the impact are more  expensive in time and resources that accepting the consequences of that risk. 

The risk mitigation strategy with specific tasks must be managed as any other project task.  This includes securing the resources, assignment to individual project team members,  motivating the involved project team members, overseeing and controlling the execution of the tasks and finally measuring and reporting the progress of risk mitigation. A mitigation  plan foresees the description of:  

  • actions;
  • time schedule of that actions;
  • responsible partners for those actions, ie identify a leader to manage the risk. 

The final definition of the risk management plan will be made by the risk management board,  that is defined, according to the relevance of the Risk Factor as follows:

 

 

If Risk factor is lower than 5: Coordinator and Affected WPL 
For Risk factor between 5 and 9: WPLs Board 
For Risk factor between 10 and 25: Steering Committee 
The risk log is handled by Task 1.3 Leader: UNIST.

 

Annex 1: Checklist for deliverables

1. Overall technical evaluation of the deliverable 

Does the deliverable contain new, or  value added information? :             € Yes € No

Are there any major technical errors,  omissions, lack of necessary details? :              € Yes € No

How do the results compare with the  state of the art and/or parallel activities?              € Well € Poor

What value does the document add to  the project partners?              High Low 

 

2. Executive summary. Are the following questions clearly asked and answered?: 

Which problem(s) and key questions of interest to intended readers are addressed? :            € Yes € No

What are the expected main benefits of this deliverable? :            € Yes € No 

What are the results contained in this deliverable? :             € Yes € No

Who are the main consumers for this deliverable, e.g. who should read it? :             Yes No 

Why should I read the deliverable? :              Yes No

 

3. Introduction  

Is the purpose of the document clearly  stated :            € Yes € No 

Is the technical subject properly introduced? :            € Yes € No 

If necessary, is there a guide to the  reader (document structure, short  description of chapters and  

relationships)? :            € Yes € No 

If necessary, are there statements on  technical assumption, readers’  prerequisites, relationships with other  documents or parallel activities:             € Yes € No

 

Scroll to Top
Skip to content