Deliverables

Development costs are relative. You can spend 90% of the time designing and 10% coding, or you can take three additional weeks writing test cases and avoid three months of debugging and re-factoring later on, but you'll never know for sure beforehand. Each team on each institute or company has its own associated costs. Some teams have more senior software engineers than juniors, others have more developers in general, but senior developer generally code better and faster than junior developers so even being more expensive, the time taken to achieve a particular task is smaller.

With all those variables and constraints, how to measure the associated costs of a particular team? How to assure that, in the long run, all objectives will be achieved? Can you can spend twice as much time now with software quality to save time at the end? Will you actually save time at the end?

Normally those consortia won't gather more frequent than a few years to define everything that every group has to do in the next period of time. But a few years is so much time that it's impossible to know how many things you can do in such period, you don't know how many people will be working in the team, who and at which pace.

Because you can't gather the whole consortium every month you need to define something very high-level for the next years anyway but once you're with your team you need to get down to Earth and map what you're really going to do and when. The best way to do it is by defining milestones.

A milestone is a fixed point in your schedule with some achievement, be it an idea that needs to be tested, documentation or diagrams that need to be written and also code, tests and deployment. Because at the end you need something concrete to establish the milestone (tests for ideas, documents, code, binaries, happy user) it's also called deliverables.

Every document or set of features in the code is a deliverable, every group inside the team will work towards one deliverable at a time and will have a backlog of deliverables that can change in time. If you have a homogeneous team you can also share a pool of deliverables in a first-come-first-served basis.

In essence you can't predict how long it'll take to produce the whole product but you can predict the next few steps. Once you have the iterative process and you know the amount of deliverables you have still to produce you can estimate, in a much more precise way, how long the whole project will take.

Having deliverables also means that you can release more often, users will see the partial results earlier, will be happier and will interact sooner for a better product way before it actually goes into production, so the feedback phase happens before the launch.