Early stage risk/cost/time estimaties when working with unstable/beta software integration

Question

What is the usual way to estimate costs in the first weeks of this kind of high risk projects where there is no specialist knowledge of the technologies you need to use in a development team?

In my case I need to estimate the time it would take to integrate several GIS features and map providers with a GIS GUI software and an optimizer engine, and it has proven to be very hard to estimate any reasonable time frame for completion (other than basing on previous estimated completion times). In any case, it has made me think about the difficulties of this problem and I would like to know what are the parameters of time and resources used in this cases. I haven't found a consistent methodology to account for this. All i can see is pure risk, even though I understand what could or could not happen and the amount of time if this or that happens. It varies from 'completely unfeasible' to 'solved in a week'. Any advice will be appreciated.

Answer 1

You can accurately estimate this. This is not the first time projects have used new technologies or embarking on something that has never been done before.

Use all available techniques. Use a multidisciplinary team to provide the analysis and input. Do NOT use single-point estimates. Rather, have your team provide probabilistic values and assume a triangular distribution, i.e., optimistic, most likely, pessimistic.

Work top down, break your work down and go up, use Delphi technique, examine the extremes and eliminate, use historical values where you can, use parametrics where you can, and most of all iterate your work several times as you approach CONSENSUS.

When you break the work down, you will likely find much of the scope familiar and rather easy to estimate.

Once you have sequenced your work, simulate your schedule based on your probabilistic estimates and evaluate the results. Because this is new work, I would set my targets--the single point value that gets priced and baselined--on the heavy side of the curve; that is, I would target somewhere in the 80th to 90th percentile versus the more competitive 50th to 60th. By doing so, you are building in both schedule and cost contingencies in your targets.

You did not mention the type of contract under which you will perform this work. It is not appropriate for a firm fixed price vehicle. If you did that, you would add another contingency value and it would be huge for this type of risk, e.g., three to five times your price. It just does not make sense.

This is a T&M or cost plus type contract. You need to advise your client to build both management reserve--funds available to you to fund in scope but unplanned work--and contingency reserves for your client's use to fund anything else that bites him. The contingency reserves need to be rather healthy for work like this.

This is doable because you can rule out the extremes rather quickly. For example, from a top down perspective, will it take you ten years to do this project? Five? Three? Two? Do the same thing from the optimistic side. Will it take you a week? A month? Six month? Year? You can see how ten years and a week are laughable. When your team stops laughing, you have begun to establish either side of the probabilistic estimate.

Answer 2

You can't accurately estimate things you never done before. Unless you try to use the technology to solve real problem it is a pure guessing.

If the risk is clearly unavoidable try to minimize its impact. Intstead of providing some estimate or commit to a whole project start with some prototype or feasibility study with your engineers.

Sometimes customers do not mind to pay for the research phase and even if they don't it is better to start with something small to see how many issues arise from using new technology.

Try to convince your customer to work with small iteration instead of commiting to fixed requirements/deadline. Having shallow requirements or complicated technology might be an advantage - you can implement a lot of simpler stuff (which is usually 80% of the project) which will give you a way to negotiate on more complicated features. E.g. if you are close to deadline and 80% of the project is completed and shining then it would be easier for customer to simplify remaining features rather than going behind the deadline/budget. Of course it depends on customer, importance of the features, etc.