How to Run a Large Scale European Research Project


Download Slides

The MobileCloud Networking project started 1st of November 2012. It took us two attempts, call 5 and then call 8, but the second was successful and at the end it was worth the effort.

Indeed, given the number of attempts and successes (3 out of 10 and roughly 8 every 12 month) in that category, I am very proud (as coordinator and editor of the proposal and now technical coordinator of the project) of what I achieved with the help of the consortium.

Good proposal writing is very competitive, demanding, and linked to ambition. But the challenging part is starting now. Will we be able to live up to our ambitions? Or will we end up in a spirit that is sufficient to get over the reviews and at the same time remains cosy enough to avoid friction related to ambitions and ultimately impact? Will we be able to go the extra mile?

I am asking for a specific reason. There is lot’s of complaining all over the place, too much overhead, too much paper work, useless deliverables, too much reporting, too little impact, under performance, too large consortia, too small consortia, wrong consortia, strict leadership, wrong leadership, poor leadership, cultural issues, and and and, too this and too that … the glass is half empty. One could wonder why there are so many proposals (the number keeps rising steadily) if there are so many downsides.

My theory is that, besides all the complains, it’s still frequently enough a very cosy environment. Indeed, if you compare research projects with real (business) customer projects you’ll find that the latter are way more strict; in terms of deliverable deadlines, related expectations by customers, quality requirements and so forth.

There are justified reasons for this. Research needs liberty; it’s not a pre-production grade solution delivery function. Also, collaborative research projects are very pragmatic joint ventures where partners join mostly for individual objectives driven out of company strategies (in the industrial case) and not necessarily for the entire vision of the project. This is understandable, the entire nature of writing proposals is a huge compromise and the result always the smallest common denominator, thus never fully strategic to one or the other partner.

But given this, here is the question. How do you run such a project? Do you compromise on the vision and ambition of the proposal in order to provide maximum room to exploit the project as an ideal platform for individual objectives?

Or to put the project in the center and to push for a common vision and respective commitment and frequently compromise by each partner. Of course the right approach is to find a balance of the two.

But how to warrant quality? What is quality?

And here is the paradox. All the complains about quality and impact of collaborative projects would theoretically imply that the project is in the center (mind, in the center, but not the only perspective). But this is very rarely the case, at the end what dominates is commonly the individual interests and the project interests come second. This leads to very „pragmatic, not over-engineerd“ approaches in the project and then, ultimately, another seed all the complains listed above. It’s a home made problem that goes beyond any spirit of science – with ambition, challenge, endurance, and commitment being defining principles.

I used to say „better to have friction during the proposal and a project at the end, than a good time during proposal writing and spare time thereafter“. This is now complemented with „better to have ambition, friction and reward versus a good time plus a CD of documents and some software version 0.0001 alpha in the shelf“. In other words, ambition and challenge comes first. In case of doubt, just double-check your shelves …

This all isn’t anything new, at least I keep sharing whenever I find opportunity. When consequently thought through it comes down to motivation of involved scientists, which is a result of personal, organizational, and contextual interests. And lot’s of emphasis is nowadays paid to so-called intrinsic motivation – albeit this phenomena apply mostly beyond blue-collar domains. Volunteered contributions need to be valued; cause they are rare?

I tend to agree with this but wonder to what extent this is realistic. In this post’s context, the gross of staff deployed joins projects late, way after proposal idea definition and more over, writing. A good match of project scope and interest and expertise is thus subject to random factors and not always met. Another, related aspect is that most of us wear several hats, naturally, and thus face priority scheduling.

Both features do not impair motivation per se, but related them environmental factors. Yet genuine intrinsic motivation does not rely on external triggers but is founded on principle. What I have to do I do right. This is why I believe that challenge and ambitious goal setting is more important. Intrinsically motivated researchers will be ready to go for the extra mile and get over obstacles. One very nice example for this is the Open Source Software community and there competitive structures, there is hardly anything like praise or reward, especially not financially. It’s about true belief in the mission. Another related example is the admiration of Steve Jobs, which is well-known from his immense ambition and consequence in implementing it.

For all those now claiming that this is impractical or simply unrealistic in the context of collaborative research projects. Sorry, it’s not, it’s simply up to the people’s ambition. In belief in what you do and the willingness to go after it by principle.

During the Kick-off Meeting of the MobileCloud Networking project I did present this/my vision. Here are the slides (How to run a Large-Scale Collaborative Research Project). Comments welcome.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.