penta-eureka.eu€¦ · Web viewerated sections and thus cause the merge process to fail....

AENEAS Office EURIPIDES² Office44 rue Cambronne 44 rue Cambronne75015 Paris, FRANCE 75015 Paris, Francewww.penta-eureka.eu [email protected] [email protected]. +33 1 40 64 45 80 Tel: +33 1 40 64 45 73

FPP Annex template☐ PENTA Call 5☐ EURIPIDES² Call 13☐ PENTA-EURIPIDES² colabel☐ EURIPIDES²-PENTA colabel

This template must be used equally for PENTA proposals, EURIPIDES² proposals or co-labelled proposals.

2

<PROJECT ACRONYM>FPP Annex

Foreword

Do not remove or modify in any way the sections having these notations ,

All guidelines in the template appear in this “boxed” format. These instructions, as well as the preceding title page (“FPP Annex template”) and this foreword, should never be removed manually from the submitted files: they are automatically removed by the merging function of the EURIPIDES 2 PENTA Project Zone. Potential layout issues appearing when removing the instructions (e.g. a large image leaving half a page blank) will be adjusted by the AENEAS-EURIPIDES2 Offices, between the proposal submission and the transfer of the generated PO/FPP to the reviewers.

NB: all texts between “<” and “>” symbols (incl. on the front page and in the headers) should be replaced or removed.

It is highly recommended that you carefully read all the instructions provided: they indicate for each chapter and subchapter what is expected, and must be carefully taken into account.

It is crucial that proposal writers comply with the pre-defined formatting and styling rules: breaking these rules may create errors when inserting the auto-generated sections and thus cause the merge process to fail. Complying with formatting rules can be achieved by adhering to the following guidelines:

do not remove any predefined title and do not add headers, incl. annexes, that are not supposed to be defined according to this template, at any level of the hierarchy (e.g. do not add a §5 after § 4 Rationale for public funding); in particular, for references or publications, as additional annexes are forbidden, please rely on footnotes; you are, however, free to add subsections when there is no subsection yet defined (e.g. you can define a subsection §2.2.1.1 within §2.2.1 Market analysis);

do not modify the predefined styles, except for standard “emphasis” effects (i.e. underlined or bold text) – we recommend using the underlined and bold formatting in a consistent and prudent way throughout the document, and on body text exclusively;

only use the pre-defined styles that start with “PENTA_”: the most relevant ones are “PENTA EURIPIDES2_BodyText” for standard paragraphs (Arial 10 with a line spacing factor of 1.2 pt), “PENTA_BodyBullets” for bullet points within standard paragraphs and “PENTA EURIPIDES2_Figure”; for captions, you can use the standard “Insert Caption” function from Word, as it will automatically use the “PENTA EURIPIDES2_Caption” styling; these styles are accessible in the “Quick Styles Gallery” of the “Home” tab;

do not remove the instructions (both green and orange ones), and do not remove the auto-generated sections, incl. the annexes;

do not overload the document with uncompressed / excessively large images; a proposal should ideally fit in less than 10 MB.

It is in the interest of consortia to ensure that a merged document (i.e. including auto-generated sections) can be generated and downloaded before the submission deadline so that all the relevant information is provided in the project proposal document.

of 23 PENTA and EURIPIDES2 FPP Template (January 2020)

3


Items that need to be filled in exclusively via the EURIPIDES2-PENTA Project Zone will have the following notation:

Auto-generated section: input to be provided only on the Project Zone website.

Do not remove or modify in any way the sections having these notations throughout the whole Annex template since they are needed to automatically merge the information provided via the EURIPIDES 2-PENTA Project Zone with your uploaded Annex document.

Unless otherwise specified, section length recommendations (in pages) are provided as suggestions to help

the editing. However, the overall length of the final merged document up to section §4 excluded must not exceed 35 pages for a PO and 65 pages for an FPP , which roughly corresponds to an uploaded file of 45 pages for a PO, and of 75 pages for an FPP (all sections included, i.e. including comments and empty auto-generated sections).

You should be aware that if you exceed the recommended length, this will adversely affect the evaluation by the reviewers


4


Full Project Proposal Annex<ACRONYM> or <PROJECT NAME><FULL PROJECT NAME>

Strategic Challenges Areas addressed (please refer to the Electronic Components and Systems Strategic Research Agenda (ECS SRA)https://aeneas-office.org/2019/02/21/ecs-sra-2019-executive-summary/

Edited by: <name>Date: <date>

Apart from the State-of-the-Art-dedicated text (§2.3.1) which is handled by the AENEAS-EURIPIDES2 Offices as public information, unless otherwise specified by the consortium, this document will be treated as strictly confidential.


5


Project key data

Auto-generated section: input to be provided only on the Project Zone website. Do not edit or remove this box and do not provide any text within this annex in this chapter, but provide the requested information directly on the EURIPIDES2-PENTA Project Zone.

The inserted key data will contain (among others) the acronym, full title, time frame, the respective countries and partners per country, the coordinator, as well as a short description, which should include the project idea, the main expected market impact and the main technological objective.


6


Table of Contents

PROJECT KEY DATA............................................................................................................................. 5

TABLE OF CONTENTS........................................................................................................................... 6

PROJECT ACRONYMS........................................................................................................................... 7

1. PROJECT ONE-PAGE DESCRIPTION............................................................................................8

2. PROJECT OVERVIEW.................................................................................................................. 9

2.1. Rationale of the project..........................................................................................................92.2. Targeted impact.................................................................................................................... 102.3. Technology........................................................................................................................... 122.4. Consortium overview............................................................................................................15

3. WORK DESCRIPTION................................................................................................................17

3.1. Project structure................................................................................................................... 173.2. Main milestones.................................................................................................................... 173.3. Work package descriptions..................................................................................................18

4. RATIONALE FOR PUBLIC FUNDING............................................................................................21

ANNEX A: SUMMARY OF COSTS & EFFORT BREAKDOWN...............................................................22

ANNEX B: CONSORTIUM FEEDBACK ON THE PO EVALUATION........................................................23


7


Project acronyms


8


1. Project one-page description

(Mandatory length: 1 page)

Provide, within one page maximum, a strategic description of your proposed project addressing:

the context and goals of the proposal; the business relevance and the targeted market impact; the innovative aspects and the major expected technical outcomes; the consortium relevance.

<Text to be inserted here>


9


2. Project overview

2.1. Rationale of the project

2.1.1. Problem statement and market value chain

(Maximum length: 1-2 pages)

Introduce here the problem the project aims to solve. Explain the current issues, limitations or bottlenecks of what currently exists, explain the needs you plan to satisfy or to create.

Describe the societal, economic and/or technological challenges addressed by the proposed project.

Also introduce the market value chain(s). The market value chain is a representation of the various processes involved in producing products or services and delivering them to the market. It indicates where and how value is considered and created, and how the market actors in their respective markets can be profitable. It also describes the actors’ strategies and relative positioning: it must show all the actors involved in designing, producing, distributing the products and/or services and the relationships among them. All the peripheral actors who can influence the market(s), through regulations, recommendations, indirect suggestions, etc., must also be included. Describe clearly the interfaces between these actors and define the customer – provider relationship(s) wherever relevant.

This subsection describes the context and background relevant to the project, in terms of technological and market status, not the project itself. It should convince evaluators that the project partners have a good understanding of the context in which they will be evolving, both technology- and business-wise.


2.1.2. Project innovations and technology value chain

(Maximum length: 1-2 pages)

Present here a brief view of the project innovations you are introducing: focus the description on novelty in terms of the state-of-the-art. Innovation can include both technological, process, usage and business model innovations. Explain what the project brings to the table, how it differs from existing results and previous or current projects, products and services, how partners will be able to differentiate themselves from existing market actors and become competitive (or how they can create or re-imagine a market). Remain concise in this section (cf. §2.2 and §2.3).

Describe in a few words what the project aims to achieve and how it backs the broader goals of the main partners.

Introduce also the technological value chain(s): it is a kind of modular architecture comprising the main functions and building blocks required to create the solution, as well as their interactions.

This subsection should convince evaluators of the novelty of the project proposal.


10



2.2. Targeted impact

2.2.1. Market analysis

(Maximum length: 2 pages)

Present here a detailed market analysis that is focused on the actual markets targeted by the project partners. Present market trends (e.g. graphics and figures), main products, describe the landscape in terms of competing or alternative solutions (companies, products…), the situation in Europe vs. US and Asia, etc.; provide figures whenever possible. Use up-to-date data or comment on outdated information (e.g. forecasts of several years ago). Do not rely solely on current market situations but consider also predictions and estimates of future growth from the latest studies.

Describe the existing or announced industrial products or services in the project domain. Explain which competitive advantages the market leaders have and how differentiation could be achieved towards them. Detail why smaller actors are restricted to low market share (e.g. targeting niche markets or competitiveness issue) and how volatile the market currently is (are there more and more actors or is it the opposite? In the latter case, does it derive from market consolidation or from competitors dying out?).

Present existing and potential and/or forecasted competitors (e.g. Google in the car industry or satellites). Do not hesitate to introduce Porter’s five forces model of competition to describe (on top of the current industry competitors) not only suppliers and buyers, but also potential new entrants as well as threat of substitutes.

This subsection should convince evaluators that the project partners have a clear and detailed understanding of the market they are targeting, including not only the current situation but also the current trends, forecasted evolutions and potential threats.


2.2.2. Consortium market access

(Length: up to 4 pages)

Describe how the introduced innovation will help achieve competitive advantage. Explain the expected business impact of the project with respect to the competition (see §2.2.1). Each of the partners (except for the academics and research centres) should clearly identify its accessible markets, opportunities and how it intends to profit from them.

PENTA/EURIPIDES2 projects are designed to enable organisations to achieve leadership positions in the value chains addressed as part of the programme. As such, information should be provided in relation to potential IP, opportunities for company development (especially SMEs), along with an analysis of the market State-of-the-Art and competitor positions in the market leading to an understanding of how the outcome of the programme will enable leadership in the applications or systems served.


11


Detail how the partners will exploit the actual project results after the project end. When possible, briefly discuss a timeline for commercialising the project outcome (keeping in mind that funded projects may not directly develop products or services): indicate the most relevant technology deployment time range, i.e. short-term (less than two years after project closure), mid-term (two to four years) or long-term (five years or more) that can be expected.

NB: while ambition is at the core of competitiveness, it is also important to remain realistic and credible with regards to the partner targets and capabilities.

Detail also in this section the global strategy deployed towards achieving the exploitation goals, for instance (and when relevant) through:

Standardisation:

Standardisation should be seen as a way to enable exploitation plans, e.g. by enabling a market to take off, by helping integrators to embrace the proposed technology, by counterbalancing proprietary solutions of leading competitors, etc.

Dissemination:

Dissemination and exploitation measures should address the full range of potential users and uses including research, commercial, investment, social, environmental, policy making, setting standards, skills and educational training

Consider here dissemination towards customers, communities (industrial, scientific, etc.), incl. communications, seminars, workshops, conferences, papers, courses, etc. Dissemination must be seen as a tool to make potential customers or partners aware of the project achievements and results, within and outside the organisations participating in the project.

Define and justify a dissemination strategy actually supporting and having impact on the project, i.e. justify the choices made (e.g. why selecting given workshops rather than others). Indicate how the project results will be disseminated in the course and at the end of the project, i.e. by means of (e.g.) which presentations in workshops and conferences, publications, etc.

If fast exploitation is expected, explain what exactly is targeted, and how the consortium intends to achieve these goals.

This subsection should convince evaluators that the consortium is credible, legitimate and relevant to address the market and to exploit the project results (if successful) to generate business (i.e. that it can have an impact on the market). This subsection should be market oriented and should only focus on the long-term goals of the project (i.e. what is expected to be achieved thanks to the project outcomes, i.e. after the project closure).


2.2.3. Impact of the Project on the Overall Goals of PENTA and EURIPIDES2

(Length: up to 1 page)

PENTA-EURIPIDES2 projects have at their core the following goals:


12


To reinforce and enhance existing strengths in Europe by focusing on areas where Europe has strong leadership

To close gaps across the European value chain for micro- and nanoelectronics based components and systems from technology providers to end users - thereby stimulating the European Electronics market as a whole.

To identify and develop new market leadership opportunities for Europe’s micro- and nanoelectronics industry and associated industry sectors thereby providing the ability to support future European champions through disruptive business or market approaches.

The consortia should identify how the successful conclusion of the project will contribute towards some or all of these overall PENTA-EURIPIDES2 goals


2.3. Technology

2.3.1. State-of-the-Art (SotA) analysis


Describe the current technological situation in the project domain with a detailed technical state-of-the-art, with regard to current products, prototypes and research results and trends, both on the industrial and academic sides.

For the research state-of-the-art (SotA), also document how your proposed project relates to, and/or builds on results of, and differentiates from, other (past or running) cooperative (e.g. IST, PENTA,CATRENE, EURIPIDES, ECSEL and ARTEMIS or National) projects: we recommend filling in, for each of such projects a short description thereof in the suggested table below, focusing on the aspects related to the proposed project and a short description of how the proposed project relates to, and/or builds on and differentiates from it. Please note that in this table below, the last column, “Relationship”, should explain:

which input modules will be reused from the mentioned project; and/or what will be transferred from this proposal to the mentioned project; or the reasons why the consortium does not intend to reuse/transfer results from/to the mentioned

project (i.e. why the results already achieved are not useful for this proposal).

NB: For each past or running PENTA-EURIPIDES2 project, a summary description will be available on the PENTA and EURIPIDES2 public websites.

The state-of-the-art described in the project proposal will have to be updated / extended in the course of the project and integrated in a public deliverable. Except for specific cases, the state-of-the-art dedicated text of section 2.3.1 (excluding Table 1 , related collaborative research projects) of the project proposals will be considered by the AENEAS and EURIPIDES 2 Offices as a public document .


13


This subsection should convince evaluators that the project partners have detailed knowledge of the technological background (and evolution) in the targeted field. PENTA and EURIPIDES 2 consider the State-of-the-Art analysis as a key tool to clearly understand and steer innovation all along the project lifespan.

- Beginning of public section -


- End of public section -

Link to previous and/or current collaborative research projects:

Project Name Cooperative Programme

Time period (approx.)

Technical Focus Relationship

<ACRONYM> <e.g. PENTA>

<2016-2019>



<ACRONYM> <e.g. EURIPIDES>

<2013-2019>



<ACRONYM> <H2020> <2014 – 2020>



<ACRONYM> ECSEL <2014 – 2020>



Table 1: Related collaborative research projects.

2.3.2. Proposed technological innovation and novelty in relation to the SotA


Clearly explain the progress and technological innovation proposed by your project, with reference to the current technology state-of-the-art. Explain what differentiates the project from other R&D efforts, how it builds on the SotA and which novelty it brings from a technological standpoint.

This subsection should convince evaluators that the consortium has sufficient insight into the technological challenges and proposes significant breakthroughs to bring technological innovation and novelty.



14


2.3.3. Expected project outputs

(Length: 1 page)

Detail the concrete final results of the project: give a clear description of what will be its actual set of outputs (new markets, new products, new applications, prototypes, demonstrators, IP positions etc.)The description should be detailed enough to give a clear picture of what will be generated, including the core functionalities and levels of maturity.

At the end of the project, the results will be confronted with the content of this subsection (potentially updated through Change Requests). A poor description will be considered as a lack of expected results, or as significant uncertainty about what will be delivered: clarity is therefore highly recommended here.

The requested description must focus on tangible , realistic and credible outputs that will be developed within the project (if the project extends existing solutions, then clearly clarify the specific contributions of the project) and available at project closure, i.e. demonstrated at the final project review. Post-closure results, like exploitation plans and prospects, have to be indicated in §2.2.2.

This subsection should convince evaluators that the project will deliver tangible results of interest that will support the business goals of the project partners.


2.3.4. Quantified objectives and quantification criteria


Consider the expected project results (cf. §2.3.3), and for each one of them define appropriate quantification criteria (Key Performance Indicators - KPIs) that will be used to measure the objective achievements, i.e. what will enable the consortium and evaluators to measure during the course of the project the progress achieved towards the goals. The KPIs should not cover the steering & management of the project, but cover actual exploitation oriented project results.

Example 1: For nanoelectronics technology development of a pilot line the number of wafers processed, the processing time and the production yield.

Example 2: For the nanoelectronics application development in power electronics to develop 20% more energy efficient automotive power semiconductors and to realise 10% EMC emission reduction through development of EMC filters.

Example 3: For the development of an embedded framework to enhance the security and privacy protection of future platforms, to reduce by 40% the leakage of uncontrolled data to remote servers versus currently available platforms.

Example 4: For electronic systems development, the number of demonstrators delivered at the end of the project


15


Example 5: For systems integration, the number of devices which will become available

This subsection should convince reviewers that the clear analysis and quantification of project progress will be possible during the project lifetime.


2.4. Consortium overview

2.4.1. Cooperation added value: business level


Position the consortium partners in the market value chains as described in §2.1.1. Explain the business rationale behind the consortium composition, providing convincing elements regarding the consortium legitimacy in terms of the business:

describe the core idea motivating the partners to collaborate and explain how this consortium helps them achieve their business goals;

describe how the cooperation is adding value; explain why the international collaboration (and in particular the PENTA/EURIPIDES 2 programmes) is a

good way to reach the targets; in the event that the consortium does not cover the whole value chain for the respective markets,

explain why this is not an issue for the project, and how the consortium intends to overcome this missing link.

In any case, it is strongly recommended to involve (directly or indirectly) end-users and potential future costumers in the project, and to set up (whenever possible with these end-users) strong business cases which will derive in business-oriented demonstrations.

This subsection should convince the evaluators that the consortium has enough business power to have an impact on the market.


2.4.2. Cooperation added value: technology level


Describe who among the partners will achieve the technological innovations and detail the technological added value of the consortium collaboration. Focus on unique selling propositions that generate value.

Explain the interactions between the key technology-oriented players. Refer to the targeted technological architecture (cf. §2.1.2), and position the partners in that architecture while underlying their specific role, added value and relevance here.

Explain the technological rationale behind the consortium composition:


16


describe the core idea motivating the partners to collaborate and explain how this consortium helps them achieve their technological goals;

describe what the key partners bring in, how their expertise is complementary, i.e. what makes them relevant partners.

This subsection should convince the evaluators that there is enough R&D competence in the consortium, that the consortium is appropriate and that value will be created from a technological point of view.

Both business and technological sleeping partners must be avoided.



17


3. Work description

3.1. Project structure


Provide a global overview of the technical work to be performed and of the Work Breakdown Structure (work packages) envisaged towards it. Use diagrams where possible and do not hesitate to separate the hierarchical view (organisation of WPs and tasks in a tree) from the process view (e.g. interdependency between WPs, yearly processes, etc.).

Explain the interfaces and interactions between work packages, and between consortium members.

Justify how the project structure supports the project objectives.

This section should convince the reviewers that the project structure helps the consortium achieve its goals.


3.2. Main milestones

Present the project milestones in the following table. Milestones are control points in the project that help to chart progress. Milestones may correspond to the completion of a key deliverable, allowing the next phase of the work to begin. They may also be needed at intermediary points so that, if problems have arisen, corrective measures can be taken. A milestone may be a critical decision point in the project where, for example, the consortium must decide which of several technologies to adopt for further development. Major demonstrators should also be considered as project milestones.

It is recommended to consider no more than 6 milestones in a project (i.e. on average not more than a milestone every 6 months).

Milestone titles (descriptions) should be self-explanatory. For each milestone, indicate the Key Performance Indicator (KPI) that will be used to state its achievement, as well as its completion date.

This subsection should give a good overview of the different phases of the project.

<If relevant and needed, text to be inserted here>


18


Exhaustive list of project milestones:

ID Description KPI Completion month

<MS1>

<e.g. implementation of prototype v1>

<e.g. demonstration module implementing 95% of the specifications integrated and running in the common framework>

<e.g. M24>

<MS2>

<e.g. targeted use-case performance needs achieved>

<e.g. 99% success rate in detecting intrusions and less than 1 false alarm per hour>

<e.g. M18>

3.3. Work package descriptions


For each Work Package (WP), describe:

the timeline; the starting point, objectives and expected results; the WP tasks; the detailed contributions of the partners involved in the WP; the type, content, confidentiality and planned delivery date of deliverables.

Deliverables can be:

either textual deliverables, i.e. documents (pdf, docx, etc.) (cf. “Doc.” in the second column of the deliverable tables);

or demonstrators, pilots, prototypes, designs, silicon chips, software, etc...

Make sure deliverable titles (descriptions) are self-explanatory.

Refrain from planning too many deliverables and look for quality and relevance rather than for quantity: avoid duplicating the textual deliverables with different versions and report in this proposal only deliverables that are relevant at the overall project level. It is thus recommended to avoid defining more than 20 textual deliverables (except when it is highly pertinent and properly justified) and to focus on a reasonable and limited set of deliverables.


19


It is highly recommended to provide during or at the end of the project a public deliverable consisting of an update/extension of the State-of-the-Art described in the project proposal.

This section should convince the reviewers that the planned work is precisely known and that the roles and contributions of each and every partner are clearly defined.

3.3.1. WP 1: <work package title>

Describe here the leadership, timeframe, as well as the overall WP objectives and expected results.

Detail also in the appropriate tables the task descriptions, the contributions per partner (every partner that indicates costs and effort on a given WP should have a proper description of its contribution in the related table) as well as the WP deliverables.

Please add lines to each table by selecting an existing line and by using the built- in Word functionality “insert new lines”: it will guarantee that the formatting of the table follows the predefined rules (e.g. with the automatic switching between light grey and white background for odd and even lines). You should never have to adjust the table formatting yourself.

Leadership <Company name>: <contact name>

Timeframe Start: M<X> End: M<Y>

Objectives and expected results


Task descriptions

Task Description

<T1.1> <FPP only>


20


Contributions per partner

Partner Contribution

<FPP only> <FPP only>

<FPP only>

<FPP only>

Deliverables

ID Type Description Access Due month

<D1.1> <SW, Doc.>

<FPP only> <Public,

Confidential>

M<X>

<FPP only>

<FPP only>

3.3.2. WP 2: <work package title>

Instructions are the same as for WP1. Copy the template content of WP1 as many times as you have Work Packages in your project

3.3.3. Etc.

<…>


21


4. Rationale for public funding


On the website you must fill in one section per country represented in the consortium. This section will indicate the national coordinator and detail the national rationale for funding. At the end of the national rationale for funding, the national coordinator has to indicate the national ICT clusters the project has contacted and intends to join (a clear status with regards to the cluster has to be indicated).

The national rationale for funding has four components:

national gain: you have to explain the benefits for the participating countries (e.g. support to national strategies, standardisation, open source, knowledge dissemination, wellbeing improvement, impact on national productivity, etc.), how the country benefits from collaboration with other countries and the risk level of the investment (i.e. why is a public incentive preferred for such investments),

return on investment (RoI): you have to explain how the money invested by both Public Authorities and companies is expected to generate value, revenue, jobs and/or economic growth, etc.,

value creation of the national sub-consortium: how cross-fertilisation between the various participants is achieved;

adequate balance between the national partners (e.g. ratio of effort as a percentage for academics, SMEs, etc.).

For each partner, in addition to contact details and a generic description (incl. type and size of the entity), two specific descriptions are requested:

relevance of the partner within the project by describing its main role in the project and the main added value to the international consortium and vice versa;

market access, i.e. how the partner intends to exploit the project results and how the market(s) will be accessed (exploitation prospects and capability); current main markets and main customers, as well as planned exploitation plans and strategies are welcome whenever doable.

It is crucial that all national coordinators get in touch with their national Public Authorities (PAs) to present them the project (idea, partnership, budget, etc.), checking funding opportunities and ensuring that the national consortium is eligible, even in countries that are not part of the PPA (PENTA Public Authorities Committee) nor the EURIPIDAC (EURIPIDES Public Authorities Committee). Beware of eligibility issues at national level.

For PPA/EURIPIDAC countries, information on the contact persons is available on the PENTA-EURIPIDES 2 public website (in section “Funding and Countries”). For the EUREKA countries that are not member of the PPA nor EURIPIDAC, the contact persons are National Project Coordinators (NPCs); http://www.eurekanetwork.org/eureka-countries).


22


Annex A: Summary of costs & effort breakdown


This annex will contain a comprehensive summary of the costs and effort, by providing 1) costs & effort per country per WP (with totals), and 2) costs & effort per partner type. This data is automatically computed based on the detailed figures of costs & effort provided online by each partner on the Community website: it is therefore crucial that all partners provide relevant input for both costs & effort, and do not leave blank fields, which would generate erroneous breakdowns.

Detailed costs & effort per partner are provided in the related country perspective section of § 4.


23


Annex B: Consortium feedback on the PO evaluation

Auto-generated section: input to be provided only on the Project Zone website.

This annex will be filled in only at FPP stage, and will remain empty at PO stage.

The Management Committee and Public Authorities PO evaluation will be provided after the PO submission. It is highly recommended to take into account the comments and recommendations of reviewers, and to adapt accordingly your proposal. Your feedback should be described concisely in this section: inputs are to be provided on a special page of the PENTA-EURIPIDES 2 Project Zone website, which will be provided together with the PO evaluation itself.


penta-eureka.eu€¦ · Web viewerated sections and thus cause the merge process to fail....

Documents

Transcript of penta-eureka.eu€¦ · Web viewerated sections and thus cause the merge process to fail....