D1.2 Project quality plan - SMOOTH platform€¦ · PP Restricted to other programme participants...
Transcript of D1.2 Project quality plan - SMOOTH platform€¦ · PP Restricted to other programme participants...
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
Page 2 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
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 3 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
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 4 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.
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 5 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.
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 6 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.
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 7 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
ingestion, algorithms for personal
data identification and privacy risks,
and performance evaluation
WP4 NEC OTHER PU 15 EUT
D4.3
Final version of methods for data
ingestion, algorithms for personal
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
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 8 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:
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 9 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)
Specific limitations
and/or
conditions for
exploitation
(Art. 25.3 GA)
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 10 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:
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 11 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.
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 12 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.
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 13 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
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 14 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.
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 15 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;
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 16 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.).
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 17 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
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 18 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:
https://www.linkedin.com/groups/12122549/profile
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).
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 19 of 20
7.- Annex: Templates
7.1.- Deliverable template
7.2.- Presentation template
SMOOTH Deliverable 1.2
31/07/2018 Revision:0.2 Project Nº: 786741
Page 20 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
Specific limitations
and/or
conditions for
implementation
(Art. 25.2 GA)
Specific limitations
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