Deliverables and milestones are enforced to have “lead beneficiaries” by the EC. The logic is that any milestone or deliverable must have someone answerable for it. The side effect, unfortunately, is that I found myself looking only at the deliverables that listed Edgeryders as the lead beneficiaries. This returns an unrealistic view on the work needed, and is a step towards a breakdown of within-consortium collaboration.
So, I propose to @melancon that we – between here and January – prepare a version of the GANTT chart that tells each partners not just which deliverables and milestones they are lead beneficiaries of, but also the ones they are supposed to collaborate to. This should give us all a high-level description of the project’s “heartbeat”.
Thanks Alberto for this extremely crucial aspect if not organic dimension of OpenCare.
If you recall, work packages descriptions were accompanied by diagrams that would draw how each WP contributed to the project as a whole, through different aspects. These diagrams were left out in the final documents (part A and part B) since the WP description was dismantled into various informations uploaded into different ECAS forms. This is a pity.
I second Alberto’s suggestiion and would promote the development of a network, organic view of tasks deliverables and milestones. Assuming the network is well designed, WPs should naturally appear as densier network zones.
And I would even suggest to turn this into a collective fun exercise: publish and update views of the network as comments go on how deliverables, tasks etc. are perceived and describe.
P.S. And yes, deliverables and milestones are requested to have a lead beneficiary, so we had to indeed assign one for each. We hadn’t thought of the side effect, that partners would “naturally” focus on those where they appear as leaders …
A network view of the workflow is a novel idea. Well done, Guy! We’ll definitely implement it.
In general, I would like to take a fresh approach to operations, and run the project as no project has been run before. I am seeing enormous scope for improvement in management. Again, this has to do with running projects as network of peers rather than as hierarchies, focusing on enabling rather than controlling. As soon as the admin work is done, we’ll get down to it.
