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.

2 Answers 2


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.

  • The problem is that you can not predict all points of failure when dealing with completely new technology. Probably it is a lack on experience on my side, but I am failing to see how statistical methods help you when you stumble upon a thing nobody on your team has heard about previously. Unless you can predict majority of show-stopping issues, it is more of guessing than accurate estimation.
    – aku
    Sep 4, 2011 at 12:12
  • Estimating is not about predicting the future. You cannot predict the future; none of us can. Estimating is about analyzing known variables, assumptions of what you believe to be true, analyzing your known unknowns, and then based on that drawing a line in the sand. Get passed that the likelihood your line in the sand will be correct is butt low! But that is not the point. The point is to establish a plan and then to measure your performance against that plan, i.e., manage to your variances. Sep 4, 2011 at 12:42
  • An estimate is NOT the accuracy of a sniper's bullet, but rather the LIKELY spread and precision of a shotgun blast. Then you pick the pellet that is either your most likely or of least risk, which ever you want, to establish your price and baseline for measurement. We get too hung up on accuracy of a sniper's bullet when we should be focusing on the precision of a shotgun blast. Two very different things. Sep 4, 2011 at 12:46
  • And, finally, being a leader means understanding that predicting ALL points of failure is not possible, but rather analyzing what you can analyze and then choosing to move forward knowing there are unknown unknowns that can and will bite you. We do not live in a world where we can control everything. In fact, we control very little. Sep 4, 2011 at 12:49
  • 1
    Well, in the real world customers ask you "when can you finish it?" and "how much money you need?" Treating estimates as a "spread of precision" is quite misaligned with business goals. If I tell them "it is a 65% probability we finish in June" they will find another provider. I believe it might work for some R&D activities but I seriously doubt it is applicable to the typical projects where budget and deadline matter. It would be very interesting if you tell some real story from your experience where statistical methods helped to save a day.
    – aku
    Sep 4, 2011 at 12:59

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.