Download - D1.2 Project quality plan - SMOOTH platform€¦ · PP Restricted to other programme participants (including ... IPR log template ... production. a) Reports and Deliverables Reports

H2020-DS-08-2017: SMOOTH

Project No. 786741

Start date of project: 01-05-2018

Duration: 30 months

Revision: 02

Date: 31-07-2018

D1.2 Project quality plan

SMOOTH Deliverable 1.2

31/07/2018 Revision:0.2 Project Nº: 786741

of 20

Document Information

Document Name: Deliverable 1.2 Project quality plan

WP: 1

Revision: 02

Revision Date: 31.07.2018

Author: Rosa Araujo

Dissemination Level

Project co-funded by the EC within the H2020 Programme

PU Public x

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)

(Tick the corresponding dissemination level of the deliverable according to Annex I).

Approvals

Name Entity Date Visa

Author Rosa Araujo Eurecat 31/07/2018

Document history

Revision Date Modification

Version 1 17/07/2018 V1

Version 2 31/07/2018 V2

Executive summary

The purpose of this document is to act as a common reference for all project

consortium members throughout the entire project duration to enable successful

collaborative work and deliver high quality project results. The Project quality plan

defines the acceptable level of quality and describes how the Project will ensure

this level of quality in its deliverables and work processes



of 20

Index

Index 3

1.- Introduction .......................................................................................................... 4

1.- Quality Management ............................................................................................ 4

1.1.- Document production ............................................................................................. 5 1.1.1 Processing Tools and Document Standards ................................................ 5

1.2.- Assignment of the reviewers .................................................................................. 6 1.3.- Criteria for quality control ........................................................................................ 6 1.4.- Schedule and assignment for quality control on deliverables ................................ 7 1.5.- Special provisions for Demonstrators ..................................................................... 8

2.- Knowledge management and IPR ....................................................................... 9

3.- Risk Management .............................................................................................. 10

3.1.- Risk register .......................................................................................................... 11

4.- SMOOTH’s key performance indicators ........................................................... 12

5.- Conflict resolution ............................................................................................. 14

6.- Dissemination, communication and collaboration activities .......................... 14

6.1.- Dissemination ....................................................................................................... 15 6.2.- Communication activities ...................................................................................... 16

1.1.2 Social media ............................................................................................... 18 6.3.- Collaboration with other similar projects and initiatives ........................................ 18

7.- Annex: Templates .............................................................................................. 19

7.1.- Deliverable template ............................................................................................. 19 7.2.- Presentation template ........................................................................................... 19 7.3.- Risk register template ........................................................................................... 20 7.4.- IPR inventory register template ............................................................................ 20 7.5.- IPR log template ................................................................................................... 20



of 20

1.- Introduction

Based on the terms and conditions established in the SMOOTH Grant Agreement and its Annexes,

as well as in the Consortium Agreement, this document provides a single point of reference on the

quality assurance and quality control processes that will be adopted during the SMOOTH project.

The present Quality Management Plan describes the mechanisms that will be used throughout the

project. More specifically, it details the roles and responsibilities, procedures (risk and change

management, reporting, etc.), guidelines and best practices. It explains how the project will execute

its day-to-day activities from a quality perspective, and ensures that standards, processes, and

procedures are defined and their execution is continuously monitored, corrected when necessary

and improved.

The quality assurance and quality control processes described in this document aim at:

Supporting the project development and provide continuous feedback on the extent the

project objectives are accomplished;

Allowing the project results to be improved by comparing the identified objectives and the

established processes/means;

Supporting the project decision-making process by evaluating the results;

Monitoring the involvement of all project partners and other stakeholders;

Monitoring the means used and the level of efficiency with which the project

components are being implemented;

Identifying any risks and potential issues/obstacles related to the project

implementation, and proposing possible solutions.

This document is to be used as a guide for the SMOOTH consortium to ensure effective

collaboration, the highest level of quality of project results and to facilitate partners’ engagement

in the project activities.

The Project quality plan aims at ensuring that:

• The GA requirements and conditions have been fully applied and followed by all partners;

• The EU/national rules and procedures are taken into account in operational, administrative and

financial management;

• All rights and obligations defined in the Consortium Agreement are fulfilled;

• Project activities are carried out in accordance with the Work Plan and the assigned budget.

1.- Quality Management

Quality must be inherent in work. It is not a layer that can be added by reviewing a document

considered almost finished by its authors. The continuous progress assessment, close follow-up of

work, corporate tools, etc. are therefore fundamental for innate quality of work. Another important

base is the strict and sincere reviewing process on the project’s output, in particular deliverables,

regardless their classification as public/confidential/classified.



of 20

The process must follow objective criteria on scientific and technical excellence, expected

objectives, coherence with prior/following work and value for exploitation. Aspects such as

comprehension for non-experts shall be further taken into consideration, in particular for

publishable summaries of deliverables.

1.1.- Document production

SMOOTH provides templates with a standard visual image, to assist clear communication and

comprehension. These are available in the project repository at Redmine. The following are the

main guidelines for use in partner communication, documentation, reporting, and deliverable

production.

a) Reports and Deliverables

Reports and Deliverables will be produced in Microsoft Word: working drafts and editable working

copies will be supplied to partners as Word documents. After the peer review of a deliverable, the

author will send the final version in Word format. The Project Coordinator will revise the final

documents and submit the final PDF file. The final PDF version will also be made available to

partners and will be regarded as the definitive version of the Report or Deliverable. This is, overall

Deliverable responsible (the senior team member for the responsible partner identified in the DoA)

should have final editorial responsibility for (a) ensuring the overall integrity and consistency (both

technical and presentational) of the Deliverable; (b) making sure that all corrections proposed by

the internal review were made; and (c) closing the Word final version and sending it to the project

manager for final checking and delivery to the Project Officer.

Reports and Deliverables have a consistently styled cover sheet and structure (all fields MUST be

filled in), based on the template. All pages should be numbered and the document identification

number should be included in the header. All reports and deliverables should carry the logos of

SMOOTH and the EU emblem.

b) Financial Statement (Annex 4 of the Grant Agreement)

The customised financial statement template is provided by the PM in a Microsoft Excel file, using

the model of European Commission.

Any other Financial Reports or numerical records produced for electronic circulation between the

project partners or to the Commission should be prepared using Microsoft Excel.

c) Presentations

The Coordinator will provide templates for project presentations in order to facilitate their

production as well as to guarantee the consistency and quality of SMOOTH image.

1.1.1 Processing Tools and Document Standards

For the preparation of documents Microsoft Office (Word, Excel, and PowerPoint) should be used.

Graphics can be provided in any standard image format such as TIFF, GIF, PNG, and JPEG. Templates

for (Word) documents, (PowerPoint) presentations, financial statements (Excel) etc will be available

at all times at Redmine’. Final documents should also be made available in PDF format to ensure

that everybody can access and read them without making changes.



of 20

1.2.- Assignment of the reviewers

The cautious selection of critical reviewers is needed for integration, coherence and viability of the

output delivered regarding the project objectives. Every deliverable is to be reviewed by at least

one partner not authoring the document nor directly involved in its production and shall be selected

from the following:

the Project Coordinator

a team member that needs the content, e.g. as s/he continues the work/takes up the results

a team member strategically interested in this piece of work, e.g. for exploitation

an agreed external expert because of the S&T value s/he can introduce through revision

an agreed external stakeholder because of his valuable opinion and critical user-sight

The assignment of reviewers is done by the WPL. Then each WPL is responsible for the quality of

the deliverables produced in his WP and it is his/her obligation to get them reviewed according to

the agreed schedule and criteria. It is the responsibility of the Coordinator to make any

arrangements with external reviewers (confidentiality, briefing, delivery method…) on time.

The schedule and assigned review-PARTNERS are made available herein to all team members to

facilitate planning. The Coordinator will keep this list available in the shared workspace. This

identification is necessary to ensure quality of review and that the authors and reviewers can

communicate directly on comments made and their implementation for the improved version.

1.3.- Criteria for quality control

Reviewers give their feedback in a structured format, following common rules and agreed scientific

and technical criteria discussed by the WPLG. They shall provide constructive recommendations for

improvement which the deliverable owner integrates for improvement. Basic aspects to be

addressed by each reviewer are:

Completeness: Content must address all aspects related to the purpose but avoid

redundancy of information.

Accuracy: Content must be reliable, conclusions must match results produced and take

account of any assumptions made or restrictions imposed.

Relevance: Content must be focused on the key issues.

Depth: Content must have adequate depth but must nevertheless be presented in a concise

manner.

Adherence to template: The project output must be uniform in appearance and structure

(cooperate image).

Scientific acknowledgment: The project output must convey with the suitable scientific

citation.

A checklist and recommendations for review will be produced upon proposal of all WP Leader

inputs to ensure completeness and fairness of criteria. The original proposal will be made by the

Coordinator and included in an updated version and made available in Redmine.



of 20

1.4.- Schedule and assignment for quality control on deliverables

Here below, it can be consulted the list of deliverables with the corresponding reviewers, ordered

by due date of submission to the EC:

List of deliverables

Del. Due

No. date

D1.1 Project administrative toolset WP1 EUT R PU 3 UC3M

D1.2 Project quality plan WP1 UC3M R PU 3 EUT

D2.1 Requirements definition WP2 KUL R PU 6 ESBA, FBA

D2.2

First version of entry questionnaire

and design of Interactive

HandBook

WP2 EUT R PU 9 KUL, AEPD

D2.3 Final version of entry questionnaire WP2 EUT R PU 18 KUL, DVI

D2.4

Requirements assessment and

delivery of website and mobile app

of Interactive HandBook

WP2 KUL R PU 24 ESBA, FBA

D3.1

Design of algorithms for analysing

GDPR elements and document

complexity

WP3 NAVER R PU 9 EUT

D3.2 Open annotated data WP3 NAVER R PU 12 EUT

D3.3

Mono-lingual algorithms for

analysing GDPR elements and

document complexity

WP3 NAVER OTHER PU 15 EUT

D3.4

Multi-lingual algorithms for

analysing GDPR elements and

document complexity

WP3 NAVER OTHER PU 24 EUT

D3.5Report on how to extend the

features to another languageWP3 NAVER R PU 24 EUT

D4.1

Design of methods for data

ingestion, algorithms for personal

data identification and privacy risks

WP4 NEC R PU 9 EUT

D4.2

Interim version of methods for data


data identification and privacy risks,

and performance evaluation

WP4 NEC OTHER PU 15 EUT

D4.3

Final version of methods for data


data identification and privacy risks,

and performance evaluation

WP4 NEC OTHER PU 24 EUT

D5.1Design of website and mobile app

analysis moduleWP5 UC3M R PU 9 IMDEA

D5.2Interim version of website and

mobile app analysis moduleWP5 UC3M OTHER PU 15 IMDEA

D5.3Final version of website and mobile

app analysis moduleWP5 UC3M OTHER PU 24 IMDEA

D6.1 SMOOTH cloud platform design WP6 EUT R PU 9 LSTECH

D6.2Interim version of SMOOTH cloud

platformWP6 EUT DEM PU 18 LSTECH

D6.3Final version of SMOOTH cloud

platformWP6 EUT DEM PU 27 LSTECH

D7.1

Definition of SMOOTH validation

process and MEnts recruitment

strategy and results

WP7 EUT R PU 6 ESBA, FBA

D7.2Report of first evaluation of

SMOOTH platformWP7 FBA R PU 18 ESBA, LSTECH

D7.3Report of second evaluation of

SMOOTH platformWP7 FBA R PU 27 ESBA, LSTECH

D7.4Report of market capacity

assessment of SMOOTH platformWP7 LSTECH R PU 30 FBA, ESBA

D8.1 SMOOTH website WP8 EUT DEC PU 3 All partners

D8.2Report on the standardization

landscape and applicable standardsWP8 UNE R PU 6 IMDEA

D8.3

First year dissemination,

communication, exploitation and

standardisation report

WP8 ESBA R PU 12 UNE, IMDEA

D8.4

Second year dissemination,

communication, exploitation and

standardisation report

WP8 ESBA R PU 24 UNE, IMDEA

D8.5

Final dissemination, communication,

exploitation and standardisation

report

WP8 LSTECH R PU 30 UNE, IMDEA

D9.1 Data Management Plan WP9 EUT R PU 6 UC3M

D9.2 SMOOTH ELSA first year report WP9 KUL R PU 12 AEPD, NAVER

D9.3SMOOTH ELSA second year

reportWP9 KUL R PU 24 DVI, NEC

D9.4 SMOOTH ELSA final report WP9 KUL R PU 30 AEPD, DVI, NEC

ReviewersDiss. levelTypeLeadWP No.Deliverable name



of 20

1.5.- Special provisions for Demonstrators

Please note that when the deliverables describe a “Demonstrator” a high quality technical

documentation should be submitted. This report should describe all relevant requirements and

functions of the software. Besides, a technical evaluation should be performed and included in the

technical documentation.

Technical Documentation of Demonstrators

A report including the following sections, when applicable, should be submitted:

1. Description of the general objectives of the prototype, relating them to:

i. project milestones,

ii. innovation,

iii. user requirements,

iv. performance requirements.

2. Specification of the prototype in general and of the relevant components; unless it was

already done as a deliverable, in which case the number and name of the deliverable shall be

specified. The specifications must contain:

i. System requirements in terms of hardware and software (equipment and

configuration, operating system, development tools, etc).

ii. High-level description of the architecture, e.g. as a plug-in or library.

iii. Regarding the various components, the specification should include the

input/output and integration with other components.

iv. User interface specifications, if user interaction is planned.

v. Reference to any formal standards to which the product will have to

comply, together with any testing and certification requirements.

3. User or Programmer manuals as well as installation instructions; unless it was already done

as a deliverable, in which case the number and name of the deliverable shall be specified.

4. The results of the technical evaluation and a reasoned assessment of the performance

achieved. More details about the evaluation are given below.

5. Conclusions from the development and evaluation, including recommendations and future

enhancements.

6. Any available supporting material, as for example:

vi. block diagram(s),

vii. high-level specs,

viii. snapshots of the prototype,

ix. diagram with the positioning of the prototype in the overall project

solution(s) or system proposed.

The documents accompanying prototype deliverables are appraised by internal peer review. In the

following we describe the process of evaluating the prototype and reporting the results.

Technical Evaluation of Demonstrators

The effectiveness and good performance of the will be ensured by the appropriate development,

testing, integration with other project components and evaluation.

This implies that:



of 20

The criteria or standards must be identified, by which the performance of the prototypes

will be assessed

Monitoring the performance during the development must be ensured, and recording

compliance or deviation must be allowed for.

A rigorous evaluation is an important medium of assessing the actual and potential performance of

new processes and tools, and facilitates the gathering of performance data that may be needed for

further development. Thus the procedure that will be applied for all prototype deliverables is as

follows:

The research team responsible for each prototype will specify qualitative and quantitative

validation measures, including as appropriate simulations, tests, benchmark measurements, or the

advance on the state of the art as established by peer reviewed publications.

For each prototype the team should be able to describe: (a) the tests performed (b) the

performance criteria that were assessed and (c) the results of the tests.

Therefore, all reports accompanying the prototype deliverables will include a short section

setting out the authors’ evaluation, with a reasoned assessment (qualitative or quantitative as

appropriate) of the performance achieved, the tests and benchmark measurements applied, the

results, and advances (where apparent) on state of the art methods. This will include discussion of

the impact of factors such as dependency on input data, multiple factors and dependencies

between them, and any uncontrollable or un-measurable aspects.

2.- Knowledge management and IPR

As established in the DoA, IPR and results management will be handled through an IPR register.

This register will be formed by two sections:

1. An inventory: this section keeps track of the partners’ and third party’s IPR used in the

project.

2. The newly created IPR/results: this section identifies in the course of the project the output

and IPR produced by SMOOTH.

The template of the inventory will be based on the following original table, which will be made

available as an open spreadsheet in the shared workspace. It shall be overlooked in particular by

the WP and Task Leaders for Dissemination and Exploitation as any identified limitation will affect

their action and impact of work. The categories and items described in the list might be amended

throughout the project to better suit the actual IPR issues in this kind of Coordination and Support

Action.

Partner

who brings

in the IPR

Description of

the input,

material,

deliverable,

background…

WPs or

tasks

where it

shall be

used

Ownershi

p/access

right

situation

Specific limitations

and/or

conditions for

implementation

(Art. 25.2 GA)


and/or

conditions for

exploitation

(Art. 25.3 GA)



of 20

IPR register

The IPR log for newly created IPR focuses on capturing the output directly assignable to SMOOTH.

It shall identify the output, hence any debate of shares in case of joint ownership are subject to the

rules established therefore in the Grant and the Consortium Agreement. It will also be handled as

a spreadsheet in the Redmine to enable each team member to identify and report any potential

result. The list shall be overlooked and maintained by the WPL Exploitation. Any register shall be

commented at the GA meetings to ensure that the opportunities for future use of project output

are seized and partners agree on conditions and proposals for future use.

Authors,

owners,

collaborators

Description of the

output, including

format and

version, document

reference etc.

Associated

WP/task

Purpose for

project

implementat

ion

Purpose for

exploitation

objectives

Further

potential

application

IPR log

Being register files, the above mentioned inventory and IPR log will include standard fields in the

spread sheet such as date of register, person who registered the entry, unique identifier/reference.

The current format might be more elaborated with a separate document if deemed necessary.

3.- Risk Management

It is responsibility of each partner to notify about any event that impedes the correct

implementation of the project tasks or the consecution of its objectives. The risk is to be presented

in a structured manner and as complete as possible (Template) and at a first instance

communicated to the Coordinator.

The assessment of the criticality of the risk, responsibilities, options for response and action shall

be proposed by the WPL. The WPL shall report to the Coordinator in particular those risks, which

are qualified as high impact on the project work/output and with high probability.

Besides the newly identified risks, in the PSG meetings, the currently most relevant risks will be

discussed and reassessed. The meeting minutes will include this aspect and the Coordinator shall

transfer the update to the Risk Register. The Coordinator is responsible for keeping the Risk Register

updated and accessible to all SMOOTH members through the platform Redmine.

Tolerance margins: It is responsibility of the WPL and the Coordinator to establish the threshold

which is unacceptable to the objectives of the project. The tolerance levels are set by answering

the following question “how far wide of the plan should we allow things to deviate before we take

action?” These margins will establish for example the accepted delay in the issue of deliverables

and reports, the accomplishment of milestones, etc.

The following chart shows the process and the corresponding responsibilities of the different

project members and governing bodies:



of 20

Figure 1. Risk registration process chart

3.1.- Risk register

SMOOTH Risk Register will be completed adopting the very practical approach of PRINCE2 on risk

management, which assesses any negative or positive risk by its cause, likelihood, impact, timing,

and the choice of response. While the overall register is kept by the Coordinator, updates can be

constantly made by any project member.

In the Annex, the risk register which takes the format of a spreadsheet is shown. Once a new risk is

identified, entries are made on the register. For each entry, the following fields should be recorded:

IDENTIFICATION

Risk identifier: Provides a unique reference for every risk entered into the register. It will typically be a numeric or alpha-numeric value.

Date of register: The date the risk was identified.

Reported by: The person who raised the risk.

Date of revision: The date the risk was reviewed.

Author of revision: The person who reviewed the risk.

RISK DESCRIPTION

Status: It refers to whether the risk is active or closed. If it is closed, it should be indicated if the risk ceased to be material or if their effect was reduced or mitigated.



of 20

Risk category: Risk management strategy establishes the following categories to handle the risks that may arise; within those two categories, risks may be classified a further step by subcategories (performance, schedule, quality, legal, resources, ethical, IPR, etc.). Project Management risks (MNG): conflicts of interest, confidentiality, decision making procedures or simply different working habits. Technical risks (TECH): risks which arise in the integration of critical technologies, and/or sub-systems dependent on them. Also from an underpinning technology not maturing in the required timeframe.

Risk description: In terms of the cause, event (threat or opportunity) and effect (description in words of the impact).

Work Package: The work package affected by the risk.

Risk owner: The person responsible to manage the risk (there can only be one responsible for each risk).

RISK ASSESSMENT

Probability: The scales for estimating probability in SMOOTH project are: “high”, “medium” and “low”. High: Imminent event that may cause the risk. There are no external or internal conditions that can avoid the event. Medium: There are conditions that reduce the probability of the event happening but they are not enough to avoid term. Low: There are conditions that make unlikely the event to take place.

Proximity: States how close to the present time the risk event is anticipated to happen (e.g. imminent, within stage, within the project, after the project).

Impact: The scales for estimating impact in SMOOTH project are: “high”, “medium” and “low”. High: High impact risks significantly impede the correct implementation of the project. They may result in not achieving the objectives of the project and may require more efforts and a change of methodology. It may also require the intervention of the Project Board. Medium: Medium impact risks impede the correct implementation of the project. They may complicate the achievement of the objectives of the project or require extra efforts to be overcome. Low: Low impact risks slightly impede the correct implementation of the project and they may require slight adaptations in the work plan.

Description of impact: Optional description of the consequences deriving from the risk if no measures are taken in order to avoid or mitigate the risk.

RESPONSE TO RISK

Category of response: Depending on the risk (its proximity, probability and impact) different responses may be adopted. Avoid: It normally implies changing any aspect of the project so the impact of the risk cannot occur or affect the implementation of the project. Reduce: Measures are taken in order to reduce the probability of the event taking place and the impact of the event in case it finally occurs. Alternative strategy: In order to reduce the impact of the event if it finally takes place, an alternative strategy is proposed for the implementation of the project. Accept: The consequences of the risk are accepted and no action is taken. The risk must be monitored to assure it is tolerable.

Description of response: Measures to cope with the risk. Each risk has a Contingency plan described in the Risk Register.

Risk executor: The persons that will execute the actions described in the response to the risk. There is no need to be the same person as the risk owner.

Risk register information

4.- SMOOTH’s key performance indicators

A set of Key Performance Indicators has been created with the aim of assuring SMOOTH’s

objectives.



of 20

The KPIs tables below have to be used for project internal management and monitoring. Periodic

activity reports will assess these indicators to evaluate the effective implementation of the project

and whether corrective actions are needed or not:

Description Means of verification Objective RP01 Objective RP02 Objective RP03

Timely

submission of

deliverables

Deliverable log; exceptions

for delays requested to the

EC

< 3 out of 18

deliverables (of this

period)

< 3 out of 17

deliverables (of this

period)

< 3 out of 21

deliverables (of

this period)

Date accomplishment Key Performance Indicators

Description Means of verification Objective RP01 Objective RP02 Objective RP03

Approval of

deliverables by

the Project’s

internal

revision

Deliverable log and

compliance of the quality

assurance procedure of

deliverables; number of

deliverables accomplishing

this objective.

Maximum 1 further

iteration upon

revision/request for

changes per

deliverable.

Maximum 1

further iteration

upon

revision/request

for changes per

deliverable.

Maximum 1

further iteration

upon

revision/request

for changes per

deliverable.

Quality Key Performance Indicators

Indic

ator

No

Activity area Indicator description

Expected progress

(cumulative)

M1-

M12

M13-

M24

M25-

M30

1

Management

Number of follow-up meetings 24 24 12

2 Max % of deviation from original resources

assignment 30 20 10

3 Max number of [cumulate] days of justified

delay in submitting deliverables 4 45 30

4

Dissemination

Number of papers published in indexed

journals 1 3 3

5 Number of conferences attended (as

presenters) 2 3 3

6 Number of workshops showing SMOOTH

outcomes N.A. 1 1

7 Communication Total online impacts (web visitors, social

media activity) 5000 10000 50000



of 20

Indic

ator

No

Activity area Indicator description

Expected progress

(cumulative)

M1-

M12

M13-

M24

M25-

M30

8 Exploitation Number of new potential business

opportunities raised - 1 2

Dissemination Key Performance Indicators

5.- Conflict resolution

Most typical conflicts in cooperative projects are different perceptions or understandings of the

work to be done, priorities, urgencies and time limits and sufficiency of quality of work. This conflict

potential affects all project partners as they share and work for the same common goal, hence with

different perceptions, background and resources.

The coordinator has a critical role in sensing and early detecting such conflict potential, to address

the issue and seek consensus among the partners in time. The frequent progress meetings are a

key instrument to address any perception of conflict, misunderstanding and controversial opinions.

As described in detail in the Consortium Agreement, incompliance of the contractual obligation of

the work plan or the Consortium Agreement is an act of BREACH. Depending on the severity of the

breach and its impact on the project, corrective actions reach from the Coordinator setting a time

limit for remedy up to a PSG decision about the conditions of continuity of the failing partner.

In the PSG, each partner has the right to vote and veto a decision only in justified cases; especially,

if the business interests or IPR of one of the partners would be adversely affected. The partners

commit to resolve the issue amicably and undertake any appropriate action of reasonable effort to

solve the issue that raised the veto. The vetoing partner shall not uphold his opposition of such

action.

In worse case and severe dispute which, notwithstanding all effort and benevolence cannot be

resolved inside the Consortium, an external arbitrary institution shall be selected.

6.- Dissemination, communication and collaboration activities

As by the rules of H2020, all documentation of the project and in particular publications or public

material that report on or include material from activities carried out within the project must

expressly acknowledge the financial contribution made by the European. In any communications of

the consortium or in representation of the consortium, the project logo and the EU emblem have

to be visibly included.



of 20

Figure 2. Project logo

Figure 3. EU emblem

Unless the Agency requests or agrees otherwise or unless it is actually impossible, any

dissemination of results (in any form, including electronic) must display the EU emblem and include

the following text:

“This project has received funding from the European Union’s Horizon 2020 research and

innovation programme under grant agreement Nº 786741”

For all publications, the following acknowledgement phrase is compulsory:

The research leading to these results has received funding from the European Union’s Horizon 2020 innovation action programme under grant agreement No 786741 –SMOOTH project.

Any publicity made by the beneficiaries in respect of the project, in whatever form and on or by

whatever medium, must specify that it reflects only the author’s views and that the European Union

is not liable for any use that may be made of the information contained therein.

This [presentation/publication/etc] reflects only the author's views and the European Community is not liable for any use that may be made of the information contained herein.

The templates explained beforehand already respect this obligation and are therefore the best

source and reference. Shall a partner have any doubt about the use of the logos and the footnote,

please contact the Coordinator or the WP Leader for Dissemination, ESBA.

Any dissemination, communication or collaboration activity planned by partners should be in line

with the dissemination and communication strategies defined.

6.1.- Dissemination

A spreadsheet for announcing and reporting on scientific dissemination activities is available in the

project repository (under WP8 / Conferences and Events folder), where the following information

details should be provided:

- Year;

- Title;

- Dates;

- Location;

- Type of participation;



of 20

- Deadline;

- Relation to SMOOTH;

- Links, URLs;

- Participants;

- Participation details (Title of Paper, Article in Journal, etc., link to abstract/paper).

The first 8 fields are mandatory for any dissemination opportunity, even if there is no planned

submission or participation yet. This can be used to announce to other partners the opportunity.

If the publication is accepted, the last 2 fields in the spreadsheet must be filled in.

A spreadsheet for announcing and reporting on other dissemination and exploitation activities

(both planned and already executed, such as presentations at conferences, publications, website

presence, newsletter articles, etc.) is also available in the project repository under WP8 /

Conferences and Events folder, where the following information will be provided:

- Year;

- Venue (and link);

- Dates;

- Location;

- Type of participation;

- Deadline;

- Relation to SMOOTH;

- Type of audience;

- Size of audience;

- Already attending? (who);

- Want to attend? (who);

- Comments.

The first 9 fields are mandatory for any communication opportunity, even if there is no planned

participation yet.

This can be used to announce to other partners the opportunity.

All partners must keep these spreadsheets up to date with their own activities.

6.2.- Communication activities

Each partner wishing to undertake any formal project-relevant communication activities and

initiative related to the project should inform both the Coordinator and WP8 Leader, for approval

of the content, overall message and visual identity of the project (logo, communication style, etc.).



of 20

All communication activities should be reported at latest at the time of the periodic report.

Publications

During the project and for a period of 4 years after the end of the project, the dissemination of

results by one or several partners including but not restricted to publications (excluding patent

applications(s) and other registrations of IPRs) are governed by Art. 29.1 of the GA and Art. 8.4.1 of

the CA.

The authors must send a notice of the final version of any planned publication to the other partners

by email, in accordance with the CA art 8.4.1 (i.e., at least 30 days before the planned publication

submission date). Submit as much information as is available, but at least:

- Planned authors;

- Title;

- Abstract;

- Planned dissemination venue.

In accordance with the SMOOTH CA (art. 8.4.2), any objection to the planned publication shall be

made in writing to all partners within 30 days after receipt of the written notice. If no objection is

made, the publication is permitted.

The Coordinator tracks the progress of each such dissemination request.

The main author is responsible to keep this issue updated as the dissemination is worked on, for

example by updating the information in the issue, by uploading draft versions for the Project Board

to review, etc.

Rules for publications

Depending on the nature of the publication (scientific vs non-scientific), a few important rules have

to be followed.

- Non-scientific Use SMOOTH Logo;

- Use EU acknowledgement;

- Use EU disclaimer;

- Use EU Logo.

- Scientific Mention the following sentence in the acknowledgement section:

“SMOOTH project (G.A. no 786741) is funded by the European Union (EU) under the

Digital Security Focus Area of the Horizon 2020 (H2020) Innovation Action

programme.”

Rules for dissemination

Acknowledgement to the EC for its funding must be clearly indicated on every publication,

document and presentation for which project funding will be claimed.

It is also mandatory to use the EU logo. This rule does not apply to scientific publications, which

typically do not allow the inclusion of such logos. Both EU and SMOOTH logos are available in the



of 20

project repository in the WP8 folder (i.e. Templates sub-folder). The EU logo should be given

appropriate prominence when displayed with the project logo or any other logos.

The following sentences may be used:

Promotional material and publicity:

“This project has received funding from the European Union’s Horizon 2020 Innovation Action

programme under grant agreement No 786741”.

Patents:

“The work leading to this invention has received funding from the European Union’s Horizon

2020 Innovation Action programme under grant agreement No 786741”.

Publications:

“The work described in this <PUBLICATION_TYPE> has been conducted within the project SMOOTH.

This project has received funding from the European Union’s Horizon 2020 Innovation Action

programme under the Grant Agreement No 786741”.

Disclaimer

Any dissemination of results must indicate that it reflects only the author's view and that the EC is

not responsible for any use that may be made of the information it contains by including the

following disclaimer: “This <paper/presentation/article/publication> and the content in it reflects

only the author’s view and the European Commission is not responsible for any use that may be

made of the information it contains.”

1.1.2 Social media

The project uses the following social media:

LinkedIn

https://www.linkedin.com/groups/12122549/profile

Twitter

https://twitter.com/GdprSmooth

Partners are encouraged to engage themselves and other project stakeholders in social media use.

Before sharing any formal project communication using social media, the WP8 Leader and

Coordinator should be consulted.

6.3.- Collaboration with other similar projects and initiatives

An important focus for dissemination will be to other projects similar EU-funded projects and

initiatives. Along this objective SMOOTH will establish connections with relevant projects, for

bilateral exchange of information on relevant events (e.g. invitations) and creation of opportunities

matching mutual agendas (organising joint workshops and networking sessions).

https://twitter.com/GdprSmooth



of 20

7.- Annex: Templates

7.1.- Deliverable template

7.2.- Presentation template



of 20

7.3.- Risk register template

7.4.- IPR inventory register template

Partner who

brings in the

IPR

Description of the

input, material,

deliverable,

background…

WPs or

tasks

where it

shall be

used

Ownership

/access

right

situation


and/or

conditions for

implementation

(Art. 25.2 GA)


and/or

conditions for

exploitation

(Art. 25.3 GA)

7.5.- IPR log template

Authors,

owners,

collaborator

s

Description of the

output, including

format and version,

document reference

etc.

associated

WP/task

purpose for

project

implementati

on

purpose for

exploitatio

n

objectives

further

potential

application