Annex 1. Instructions for completing Part B of the Proposal
This Annex provides the instructions and the template to help you to structure Part B of your proposal aimed at providing information on the rationale, objectives and work plan of the proposal, as well as implementation details and contribution to the FI-WARE Impact.
The instructions are inserted along the template itself, explaining the expected content in each section. Tips are inserted inside proposed sections and WP description forms using text in italic. You may drop it from the final version of the Part B document you generate. Text to be replaced by you is marked in yellow.
Beyond the template for drafting part B provided in the following pages, a “stand alone” electronic version of this template can be obtained in http://www.fi-ware.eu/open-call/ web page.
The template will help you present important aspects of your planned work in a way that will enable the experts to make an effective assessment against the defined evaluation criteria. Please keep the evaluation criteria always in mind and follow the instructions per section and subsection carefully when preparing part B of the proposal.
It is in your interest to keep your text concise since over-long proposals are rarely viewed in a positive light by the evaluating experts.
When you complete budget information in part B, please make sure that:
· Numbers are always rounded to the nearest whole number.
· All costs are given in Euros (not thousands of Euros), and must exclude value added tax.
NOTE 1: Each page of Part B must be numbered and should be headed with the short name of the applicant and the date. The completed proposal Part B MUST be submitted in PDF format.
NOTE 2: Your project should plan to start beginning of September 2012 and be no longer than 20 months.
Project Title: / FI-WARE: Future Internet Core PlatformProject Acronym: / FI-WARE
Type of instrument: / Large-scale Integrated Project (IP)
Grant Agreement number: / 285248
Response to the First FI-WARE Open Call for selection of additional beneficiaries
Call Identifier: FI-WARE: Open Call 2 for additional beneficiaries
[Proposal full title]
[Proposal acronym]
PROPOSAL PART B
Version: <major-digit>.<minor-digit
1
FI-WARE: Open Call 2 for additional beneficiaries – [project acronym] –YYYY/MM/DD
Proposal Abstract
This section should provide a maximum 2000 character summary of the Part B, describing in particular:
· the relevant features of the proposal
· the strengths of the proposal, and its contribution to FI-WARE overall goals
· the strengths of the applicant(s)
· the complementarity of the participation in the FI-WARE Consortium with the applicant’s core business
TABLE OF CONTENTS
B0. Cost and funding breakdown
Complete the table below (one table for each organisation involved in the proposal).
Please show figures in euros (not thousands of euros).
Organisation Name: (enter organisation name)
RTD / Other / Management / Total1. Personnel costs
2. Other direct costs
3. Total direct costs (Sum of row 1 and 2)
4. Indirect costs
5. Total costs
(Sum of row 3 and 4)
6. Requested EC contribution
In row 1, insert your personnel costs for the work involved, differentiating between:
RTD activities: Activities directly aimed at addressing a topic of the call. Each topic will deal with a set of functionalities to be supported by the FI-WARE Platform. Proposals should address the definition of open and royalty-free specifications, as well as the development of a reference implementation, of new components in the FI-WARE Platform that will cover these functionalities.
Other activities: any specific activities not covered by the above mentioned types of activity such as training, coordination, networking and dissemination (including publications). These activities should be specified later in the proposal.
Management activities include the maintenance of the consortium agreement, if it is obligatory, the overall legal, ethical, financial and administrative management including for each of the participants obtaining the certificates on the financial statements or on the methodology, the implementation of competitive calls by the consortium for the participation of new participants and, any other management activities foreseen in the proposal except coordination of research and technological development activities
In row 2, insert any other direct costs, for example equipment or travel costs.
In row 3, calculate the sum of your personnel and other direct costs
In row 4, insert your indirect (overhead) costs.
Indirect costs are all those eligible costs which cannot be identified by the participant as being directly attributed to the project but which can be identified and justified by its accounting system as being incurred in direct relationship with the eligible direct costs attributed to the project
You may use your actual overhead costs if this is possible within your organisation's accounting system. If not, you may use a calculated figure of 20% of the sum in row 3. If you are a non-profit public body, a research organisation, a secondary or higher education establishment or a small or medium enterprise, you may use a calculated figure of 60% of the sum in row 3.
In row 5, calculate the sum of your direct and indirect costs.
In row 6, insert your requested EC contribution
RTD activities: you may request up to 50%of the total cost figure. If you are a non-profit public body, a research organisation, a secondary or higher education establishment or a small or medium enterprise, you may request up to 75% funding.
Other, Management: you may request up to 100% funding
In case of more organizations in your proposal, please fill in the following table with total costs for the whole consortium.
Costs for the whole consortium:
RTD / Other / Management / Total1. Personnel costs
2. Other direct costs
3. Total direct costs (Sum of row 1 and 2)
4. Indirect costs
5. Total costs
(Sum of row 3 and 4)
6. Requested EC contribution
Note: If you are successful in the evaluation, your final costs and funding estimates agreed with the ICT PSP project will also be subject to legal and financial verification by the Commission services
B1. Scientific and/or technical quality, relevant to the topics addressed by the call
B1.1. Concept and objectives
Describe in detail how you propose to address the S&T objectives (i.e., Epics) of the targeted topic of the FI-WARE Open Call. If you plan to rely your work on an existing technology/product, please specify so.
B1.2. Progress beyond the state of the art
Describe how the technologies you propose to develop compare with, and represent a step beyond, the state of the art.
B1.3. S/T methodology and associated work plan
A detailed work plan should be presented, broken down into work packages[1] (WPs). This work plan should be adaptable to the Agile methodology adopted in FI-WARE.
Please present your plans as follows:
i) Describe the overall strategy of the work plan
ii) Describe how it can adapt to the Agile methodology adopted in FI-WARE.
iii) Provide a detailed work description broken down into WPs:
· WP list (please use table 1.2a);
· Description of each RTD WP (please use form 1.2b). Note that the number and nature of deliverables have been already established, in order to align with those defined in RTD WPs already defined in FI-WARE. Therefore, you simply need to copy this part as provided in the template. Note that it is assumed that efforts declared for each task of these RTD WPs include the necessary PMs needed for the integration of results (developed components) in the FI-WARE Testbed, as well as the participation in global technical coordination activities.
· Description of Communication, Collaboration and Dissemination WP (please use form 1.2c). It should contain a description about how participants intend to contribute to Communication, Collaboration and Dissemination activities in FI-WARE. An extract of the corresponding WP in FI-WARE will be made available on the Open Call web page (http://www.fi-ware.eu/open-call/).
· Description of the Exploitation and Standardization WP (please use form 1.2d). It should contain a description about how participants intend to contribute to Exploitation activities in FI-WARE. An extract of the corresponding WP in FI-WARE will be made available on the Open Call web page (http://www.fi-ware.eu/open-call/).
· Description of a Management WP describing how you plan to carry out overall management of activities. Note that technical coordination activities are not considered as Management.
iv) Provide a graphical presentation of the Work Packages showing their interdependencies (Pert diagram or similar)
Note: The number of work packages used must be appropriate to the complexity of the work, a small proposal addressing a very specific set of Epics could consist of one work package only. The planning should be sufficiently detailed to justify the proposed effort and allow progress monitoring by the FI-WARE project coordinator.
Very important note: Your project should plan to start beginning of February 2013 and be no longer than 15 months.
Table 1.2a: Template - Work package list
Work package list
Work packageNo[2] / Work package title / Type of activity[3] / Person-months[4] / Start
month[5] / End
month8
TOTAL
Table 1.2b: Template – RTD Work package description
Work package number: / WP<x> / Start date or starting event: / M<x> / End: / M<y>Work package title: / <WP name>
Activity type: / RTD
Participant Number: / 1 / 2 / 3 / n
Participant Short Name: / <partner-1> / <partner-2> / <partner-3> / … / <partner-n>
Objectives:
Each RTD Work Package should address a number of Epics linked to the topic you target in your submission. The Work Package should be structured into Tasks, each Task corresponding to an Epic. In the description of a Task you should elaborate on how you plan to support the defined functionality described in the corresponding Epic.
Description of Work:
Task <x>.1: <title of task>
Task <x>.2: <title of task>
…
Task <x>.n: <title of task>
Deliverables:
You should plan at least two major releases and five minor releases (one every three months) of the deliverables listed below. Major releases will be the deliverables that will be officially submitted to the EC and considered at official reviews of the project. However, you should take into account that adoption of Agile practices in FI-WARE lead to continuous integration of updates in the FI-WARE Testbed after each Sprint (duration of a Sprint in FI-WARE = 1 month) or minor release (duration of a minor release = 3 Sprints). Keep in mind that duration of your project should no go longer than 15 months.
Following there is a list of deliverables and delivery dates for this WP. Deliverables follow numbering D.<i>.<j>.<n> where <i> designates the WP, <j> designates the deliverable within that WP and <n> identifies the release of the deliverable. Documents are tagged as (R) while software for experimentation is tagged as (P). Deliverables will have also internal delivery dates.
Deliverable Number / Deliverable Title / Description / Nature / Dissem.
Level / Delivery Month
D.3.1.{1,2} / FI-WARE GE Open Specifications. (*)
This deliverable describes the open specifications linked to GEs (and their corresponding components) being developed in this WP. A draft of this deliverable will be published three months ahead of the actual delivery of a complete and integrated FI-WARE SW release so that Use Case projects may have early access to them for the development of their proof-of-concept prototypes.
Strong emphasis will be given to the adoption of specifications defined by standardisation bodies and initiatives, as well as to defining particularly innovative and relevant specifications that the WP will propose for adoption by those bodies. / R / PU / x, y
D.3.2.{1,2} / SW Release (version of components delivered for integration in testbed).
This deliverable is the software implementation of FI-WARE components that have been developed in each release of FI-WARE. The software linked to a component will be accompanied with a document (release notes) describing the features of the corresponding backlog that have been covered in the release. Components targeted in the first release of FI-WARE will be initially identified in the first release of the FI-WARE Architecture. The FI-WARE Architecture and Roadmap documents will be updated with each FI-WARE release to keep consistency. The second and third release of FI-WARE will include the adoptions originated by the feedback by the Usage Areas, as well as the fixing of bugs emerged through testing of components. / P / PU/PP[6] / x, y
D.3.3.{1,2} / Installation and Administration Guide.
This document comes along with the SW implementation of components, each release of the document referring to the corresponding SW release to facilitate the users/adopters in the installation (if any) and administration of components (including configuration, if any). / R / PU/PP[7] / x, y
D.3.4.{1,2} / User and Programmers Guide.
This document comes along with the SW implementation of components, each release of the document being referred to the corresponding SW release, to document to the users/adopters the features offered by the components and interfaces and the way they can be exploited in their developments. / R / PU / x, y
D.3.5.{1,2} / Unit Testing Plan and Report.
This deliverable provides the description of the test plans and the report on the unit test and validation activities performed for the components defined and implemented in this WP. / R / PP / x, y
(*) – GE Open Specifications will contain all the information required in order to build compliant products which can work as alternative implementations of GEs developed in FI-WARE and therefore may replace a GE implementation developed in FI-WARE within a particular FI-WARE Instance. GE Open Specifications will typically include, but not necessarily will be limited to, information such as:
· Description of the scope, behaviour and intended use of the GE
· Terminology, definitions and abbreviations to clarify the meanings of the specification
· Signature and behaviour of operations linked to APIs (Application Programming Interfaces) that the GE should export. Signature may be specified in a particular language binding or through a RESTful interface.
· Description of protocols that support interoperability with other GE or third party products
· Description of non-functional features.
Detailed allocation of effort (person months) -