Estimate Guesstimate

There has been plenty written and said about estimation of software development times and a number of methods that have come and gone just like fashion. The schools of thought range from those (J. P Lewis) that state there is no way to estimate software development time to those who believe estimates can be made at best on a varying scale of accuracy (CMM).

From experience, personally, I side with Lewis, in that one cannot from a set of artefacts using a standardised mechanical method arrive at an estimate, which is better, then 50% correct 50% of the time, some would think my numbers are too high but I am trying to be generous.

Added into the mix that current development practices advocate the use of such things as code reuse, frameworks and varying architectural approaches to meet various requirements, all of which adds another layer of complexity to what is already an extremely difficult task.

So the solution, or should I say the way that I prefer to attack the problem which I class as both a technical and commercial problem is to develop a series of costing points.

Let me explain it this way, we are about to head off on a journey, we can envisage our destination and from those thoughts we can arrive, using indirect methods at an agreement as to what that destination is worth to us if we arrived at it.
At the risk of over simplification lets take an example of building a new application, the feasibility studies should that over the life of the application (5 years) it will deliver productivity savings of $3,000,000 (in case of a commercial product for resell we use different methods but still arrive at a single number).

This $3,000,000 results in a Net Present Value terms would be around $2,500,000 and given a benchmark return on investment of about 35%, it is easy to see that the project would become unviable if the project cost got around about $1.8 million dollars, this becomes our no go point for our project.

So we now start to work out our project cost, and this is where human skill and experience comes into play. The first cost checking exercise is based upon the feasibility study, the conceptual design and a development preparedness study. The factors that we are looking for is as follows:

In the feasibility study:
1. How well has the functionality or functional area of the application been defined, we are trying to understand if the functionality envisaged is adequate to achieve the benefits contemplated?
2. How much confusion or ‘not known’ is contained within the proposed solution?

In the conceptual design:
1. How well can the borders of the sub components be defined and how many sub components are there?
2. What is the ratio between clearly complex components verses relatively simple components?

In the development preparedness study:
1. Is there a history of successful delivery of this type of project?
2. Are resources currently available to progress the project?

Taking the six factors above in consideration one need to construct two coherent arguments, the first one being:
1. Is it likely that given the six factors above that the project can be delivered at a cost under the stated $1.8 million dollars and within any time constraints that may exist?
2. What actions can be taken and at what cost to arrive at a hard dollar estimate of the total construction cost plus or minus 25%
So let us say the answer to the above is something like:
1. It would appear possible to deliver the project for under $1.8 million dollars. (This could be with or without conditions, clearly the more conditions the more risk associated)
2. To generate an initial estimate, which is above or below cost by 25% would require that we investigate or prototype item A and design item B. The cost of doing this is $35,000 (This would be a relatively simple task to price)
We now have another decision gate to pass and one that is relatively simple; at the worst case scenario the further investigations will prove the first assumption incorrect and therefore we would face a cost of $35,000, against $2,500,000 upside which is about 1.5%. In the likely case scenario the $35,000 investment will get us 25% improvement in resolution on which we know could be bring at least $450,000 closer to project cost, in anyone’s terms this is a good return and would justify a move forward.

At this stage, we need to start working towards certainty and we do this my completing the stated works. Upon completion, we review what we have learnt versus and what we have created against the estimated cost and expected outcome. The variance of which is factored into the next gateway.

The objective of the next pass is to bring the coatings and estimates from a 25% margin down to a 15% margin, then a 10% margin and finally a 5% margin. At which point we should be able to say with the work completed to date and another X of dollars and Y months we will deliver the system for a total of Z plus or minus 5%.
Now this clearly does not work for those that like a fixed upfront cost and it can cause contracting problems, yet it does deliver lower cost and more correctly priced projects, it a matter of managing the process and complexities that arise form software development.

In the case that a fixed price needs to be locked for external client, the above method can and so be used as the internal management method, it alerts the team very quickly of problems and affords them the opportunity to manage around them.
Getting back to the fixed price a model needs to be worked up based upon historical performance of the development team and greater emphasise needs to loaded into the development preparedness study, truth be know this fix price would be a Guessetimate and that is when skill and experience comes into play and few provision for the unknown.