[Fiware-pcc] [Fiware-wpl] Fwd: Full Open Call details

Alex Glikson GLIKSON at il.ibm.com
Mon Jan 30 13:42:12 CET 2012


My question seems more relevant to the pcc, so sending it to the 
corresponding list..

Dear Juanjo,

Can you, please, elaborate on the considerations that led to the funding 
estimation? 
The scope of the first open call was very limited, and we have two more 
open calls, so it would be good to understand what drives our funding 
decisions/assessments.

Thanks,
Alex



From:   Juanjo Hierro <jhierro at tid.es>
To:     "fiware-wpl at lists.fi-ware.eu" <fiware-wpl at lists.fi-ware.eu>, 
"fiware-wpa at lists.fi-ware.eu" <fiware-wpa at lists.fi-ware.eu>
Date:   30/01/2012 11:49 AM
Subject:        [Fiware-wpl] Fwd: Full Open Call details
Sent by:        fiware-wpl-bounces at lists.fi-ware.eu




  FYI.   To be commented during our joint WPL/WPA follow-up confcall.

  Cheers,

-- Juanjo
-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es
email: jhierro at tid.es
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Chief Architect

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932



-------- Original Message -------- 
Subject: 
Full Open Call details
Date: 
Mon, 30 Jan 2012 08:31:26 +0100
From: 
Juanjo Hierro <jhierro at tid.es>
To: 
Arian.ZWEGERS at ec.europa.eu <Arian.ZWEGERS at ec.europa.eu>
CC: 
INFSO-ICT-285248 at ec.europa.eu <INFSO-ICT-285248 at ec.europa.eu>, JOSE 
JIMENEZ DELGADO <jimenez at tid.es>, MIGUEL CARRILLO PACHECO <mcp at tid.es>, 
subsidies at tid.es <subsidies at tid.es>, Annalisa.Bogliolo at ec.europa.eu 
<Annalisa.Bogliolo at ec.europa.eu>, jhierro >> "Juan J. Hierro" 
<jhierro at tid.es>


Hi Arian,

  Following are the Open Call Details which would be made available on the 
Open Call web page at the FI-WARE website.   Please take a look at them 
and confirm whether you are Ok:
A Guide for applicants which provides guidelines on how proposals should 
be formulated and describes the evaluation and negotiation process. Please 
take a close review of this document, because it contains the details on 
how we would like to approach the call.   Particularly, sections 2-5.
Detailed list of Epics (tasks) to be considered by submitters when 
targeting each topic (still under revision, but will be finalized by EOB 
tomorrow): 
for the middleware topic: 
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Common_base_technologies#FI-WARE_Advanced_Middleware
for the business modeling topic: 
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Materializing_Applications/Services_Ecosystem_and_Delivery_Framework_in_FI-WARE#Business_Elements_.26_Business_Models
We will establish that the upper limit of funding for the two topics will 
be 2 Million Euros, of which at least 1 Million Euro will be devoted to 
the middleware topic and 500 K? will be devoted to the business modelling 
topic.
  The Consortium and the Collaboration Agreements will be made accessible 
to proposers.   They will be able to download a excerpt of them from the 
Open Call web page, excluding sensitive information, provided the click on 
acceptance of a NDA that will be displayed to them prior to downloading.

  As described in the guide for applicants, the restrictions on the types 
of organisations that may submit a proposal will be the same as in FP7 ICT 
ordinary calls.   However, submissions involving just one organization 
will be allowed and indeed submissions involving large consortiums are 
discouraged.

  Rest of details (deadline, email addresses to submit proposals or asking 
for help, etc) will be published on the Open Call web page as well as the 
public announcement, despite you will find them also in the Guide for 
applicants. 

  Best regards,

-- Juanjo

 
-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es
email: jhierro at tid.es
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Chief Architect

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932


On 27/01/12 18:27, Arian.ZWEGERS at ec.europa.eu wrote: 
Hi,
 
I will only answer the last question. For the rest, I await the Call 
Details.
 
You may select one proposal if the call asks for just one proposal, if 
there is no more funding for a second proposal, if there are insufficient 
above-threshold proposals for funding, etc.
The Guidance Notes talk about "no selection" cases, but IMHO the same 
applies to left-over budgets. Then, you may re-open the call or 
redistribute the funding to the existing partners. All to be approved by 
the PO and subject to an amendment.
At any time in a project you may decide that you need additional expertise 
and you can ask somebody to join the consortium. However, the budget of 
the newcomer has to come from the existing consortium.
 
Of course you can't misuse this mechanism and artificially inflate the 
budgets of the open call.....
 
Best regards,
Arian.

From: Juanjo Hierro [mailto:jhierro at tid.es] 
Sent: Friday, January 27, 2012 4:16 PM
To: ZWEGERS Arian (INFSO)
Cc: INFSO-ICT-285248; JOSE JIMENEZ DELGADO; MIGUEL CARRILLO PACHECO; 
subsidies at tid.es; BOGLIOLO Annalisa (INFSO); jhierro >> "Juan J. Hierro"
Subject: Re: URGENT questions regarding the FI-WARE 1st Open Call


On 27/01/12 12:27, Arian.ZWEGERS at ec.europa.eu wrote: 

 
In principle, as long as the proposers agree, you can do a lot during 
negotiation. However, in ordinary FP7 calls, we do not take a mix and 
match approach; we are not taking the best parts of two or more proposals 
and make it a single project. That is a bit what you want to do here.
 
I guess in this case, you only have one successful proposal (which could 
be a consortium of 1-n partners) per task. It does not make much sense to 
have one task (one (set of) Generic Enabler(s)) implemented by 2 consortia 
or by an arbitrarily manufactured combination of 2 consortia. There should 
be no need for such a thing as taking the best of two proposals.

  As you know, this is not like in ordinary FP7 calls.  In ordinary FP7 
calls, a project is not requested to integrate their results in a bigger 
project or together with other projects.   However, this is not the case 
here.   In addition, note that we may find that a proposal is very nice 
regarding some aspects (they cover very well 3 out of 5 Epics, for 
example) but is wrongly covering or simply not covering other two.   While 
a second proposal might be very nice regarding these two.   Why couldn't 
we go for the two, one complementing the other ?

  I believe that the notion of "task" you are thinking about would map 
better to the individual Epics we will define for each topic in the call.  
Proposers would have then to explain how they would deal with each 
task/Epic and how much resources they would need to involve per each. 
Then, one proposal may be proposing to cover 4 out of 6 Epics (tasks) but 
evaluators believe they would be good covering 3 of those 4.    Another 
one may be proposing the 6 Epics but evaluators believe they would be good 
dealing with 3 (the three that the first one didn't cover well).    Then 
we may try to negotiate with the two so that we fund both covering the 
six. 
 
 
Well, it's your call, but I would be very careful here.
The notion of "task" is from the Guidance Notes, which says:
"The call may be only be for a single activity, for which only one 
successful proposer will be selected, or may be that it is for several 
activities with one or more successful proposer in each. This must be made 
clear to the proposers in the call information which you will prepare."
and "A detailed account of the task or tasks to be carried out, in 
particular clarifying how many proposers may be successful in each task"
 
Note that the first quote talks about a successful proposer in each 
activity (i.e. task). It does not talk about a single successful proposer 
(which could be a consortium of 1-n partners) for a set (>1) of tasks. 
Just like in our calls, proposers do not submit a single proposal to Obj 
1.2 and 1.4, claiming budget from both. Perhaps it is allowed to send in a 
proposal for a set of tasks, but this needs to be clarified.
 
How would it work in practice?
 
You will have a call for (say) 12 epics. Each epic is a task in the sense 
of the Guidance Notes. Taking into account the above, a proposer bids on 
one task. Or, if it is allowed to send in a proposal for a set of tasks, 
you (arbitrarily, because it will not be clear how each part of such a 
proposal maps to a task/epic) divide it into a number of tasks. You would 
have to evaluate proposals for each of the 12 tasks, and select the best 
for each task. 
- will there be budgets per task? If so, how are they allocated? If not, 
how to allocate budgets afterwards? Based on highest evaluation score?
- how about dependencies between tasks? Does it make sense to bid for a 
single epic? If you are going to evaluate per epic, you should allow 
people to submit proposals for a single epic. A single proposal for 
multiple tasks will likely have dependencies. A coherent set of proposals 
from the same consortium for a set of tasks may introduce dependencies as 
well. It might be more efficient to bid for a set of epics, than for 
separate epics.
- If proposers can bid for one epic, you may get many proposals. That's 
perhaps not a problem now, but it might be times 5 for the next open call.

  Let me first explain a bit better how I see it would work (BTW, an 
approach that has been discussed with the AB and was welcome by the UC 
projects).   Then, at the end, I formulate you a concrete question I need 
you to answer (so, please, read this message up to its end before replying 
:-)

  Each of our topics (and we have two in this Open Call) would map to the 
concept of Objective in the FP7 Work Program (e.g., Objective 1.2.a)) 
while our Epics would be like the  "target outcomes" that you list within 
one Objective.   As an example, linked to Objective 1.2.a):
Intelligent and autonomic management of cloud resources, ensuring agile 
elastic scalability. Scalable data management strategies, addressing the 
issues of heterogeneity, consistency, availability, privacy and supporting 
security. 
Technologies for infrastructure virtualisation, cross platforms execution 
as needed for service composition across multiple, heterogeneous 
environments, autonomous management of hardware and software resources. 
Interoperability amongst different clouds, portability, protection of data 
in cloud environments, control of data distribution and latency. 
Seamless support of mobile, context-aware applications. 
Energy efficiency and sustainability for software and services on the 
cloud. 
Architectures and technologies supporting integration of computing and 
networking environments; implications of Cloud Computing paradigm on 
networks 
Open Source implementations of a software stack for Clouds 
 
  Obviously, a proposal to the FP7 Call 8 (continuing with the example 
with Objective 1.2) may be addressing several of the above points.   And 
you typically fund several of them, which overlap on the points they 
address.    The only difference here is that we will require them to work 
together among them and with the existing partners in FI-WARE, following 
established FI-WARE procedures/methods and towards a target FI-WARE 
Product Vision (both being made available to submitters so that they 
understand that part of the context).     Each Epics would map to a "task" 
(a functionality to be supported) and we would comply with the guidance 
notes because we would select a proposal per task (indeed, we may select 
one proposal for several tasks, even for all of them within a topic). But 
we would not be forced to select one proposal to deal with all the Epics 
(i.e., tasks).   We will ask the proposers to structure their proposal in 
tasks, each for each Epic and estimate each.   Reviewers would be asked to 
evaluate how each proposal address each task.    That would be helpful in 
the negotiations, in case we want to select several proposals, each taking 
part of the work.

  This is not just because we just wanted to make things be more complex.  
It's because we want to achieve the most for the call.   Why can't I 
select two proposers A and B if I rather believe that both working 
together will bring the best solution ?    Should I miss the opportunity 
to bring proposer B in, when I recognize it brings the best solution for 
some of the Epics, just because they don't have the most complete solution 
?   That's the rationale.

  On the other hand, we are going to ask for a number of functions (Epics) 
that I honestly do not expect anyone will be able to cover completely 
(overall for the middleware topic).   Besides, I don't want that a 
potential proposer refuses to go to the Open Call just because they 
believe they cannot cover all the Epics.   Being able to select more than 
one proposal is a need.

  Note that the above proposal is not much difference than asking for a 
proposal by Epic.   But that would be non-sense, from my point of view, 
because all the proposals a proposer would submit will have a lot of stuff 
repeated, meaning they would have a lot of repeated stuff to be read by 
reviewers.

 
 
I would be very careful here. You should really think these things through 
and should not think too much about measures that the EC is not taking 
either. We did not select two winners in the Obj 1.7 call and merge the 
two, decrease funding enormously for half the partners in both proposals. 
It all comes down to clearly defining the call details, so to avoid highly 
subjective measures afterwards. 

  I see you concern, but I saw a way to deal with what is needed, while 
avoiding to be highly subjective.   Essentially, we will ask submitters 
(in the GfA) to structure their description of work based on the Epics 
that we will detail, defining tasks for each and estimating the costs 
associated to them.   Then we will ask evaluators to provide an evaluation 
per task of each of the proposal.     Based on the neutral evaluation of 
reviewers, we will have an objective input about how negotiations may be 
carried out. 
 
That is indeed like splitting one proposal (for a set of tasks) into 
separate proposals, one for each task/epic. You would not even want to 
allow proposers to submit one proposal for a set of tasks. You need to be 
very clear on the level for which you ask proposals, either on topic (only 
2) or on epic (10-20?), and evaluation needs to be accordingly. You can't 
call for proposals on topics and then evaluate on epics, but that seems to 
be what you want to do. That is not very transparent.
 
 
Anyway, it's your call, but I would go for two tasks (since there are two 
topics), and one winner per task. Apparently, this is also Jose's 
understanding. You ask for proposals that cover the complete task (i.e. 
all epics in that topic), and one task only. In case certain epics are not 
well covered, you might want to call for them in the next open call. The 
Guidance Notes also foresee that the budget for the "missing parts" are 
redistributed to the existing consortium, which then may decide to invite 
an additional partner (without open call). This approach is much more 
practical.

  See the answer above.   What do you see there that is fundamentally 
wrong ? 

  I will take a new look at the guidance notes to check what they say 
regarding the "missing parts".

  If I understand it correct ... would this mean that I may select one 
proposal (let's say that one that covers the best most of the Epics) and 
then invite some of the partners of other proposals (without open call) 
because we like the way they proposed to approach those parts we don't 
like how are being covered by the winning proposal ?
 
  Look forward your feedback.

  Cheers,

-- Juanjo

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx[attachment 
"FI-WARE_Open_Calls_Guide_for_applicants_v4.docx" deleted by Alex 
Glikson/Haifa/IBM] _______________________________________________
Fiware-wpl mailing list
Fiware-wpl at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-wpl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-pcc/attachments/20120130/d21cc505/attachment.html>


More information about the Fiware-pcc mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy