Posted on | May 1, 2010 | 21 Comments
Let’s be frank, estimating is not an easy task. Guessing is.
Estimating is not just the tangible act of figuring out how long a task is going to take. There are many intangibles that are rarely taken into consideration and these are the ones that will make or break your project.
As organizations feel an ever increasing pressure to produce results faster, the need for accurate estimation has risen in importance to the point that most have developed estimating standards based on pre-established deliverables. For example, a construction company has an already pre-determined estimate of what it takes to build 12 Ft. wide by 33 Ft. long room, an office furniture company knows what it takes them to build a model Deluxe Executive chair, etc., etc. These companies do this all the time using the same tools and materials, all of which are very tangible.
PERT is one of the most simple and widely used models to estimate effort by determining the best estimate of the time required (called expected time or Te) to complete a task, assuming everything proceeds as normal, the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time (sounds familiar, right, the construction company and the office furniture company above):
• Optimistic time (O) – the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected
• Pesimistic time (P) – the maximum possible time required to accomplish a task, assuming everything goes wrong, but excluding major catastrophes
• Most likely time (M) – the best estimate of the time required to accomplish a task, assuming everything proceeds as normal
The formula to calculate PERT is:
Te = (O + 4M + P) / 6
I use PERT all the time, it is very accurate and has proven very valuable in many situations.
A custom software development company with many intangibles based on the client’s requirements implemented a method to estimate based on eight categories in order to qualify a project’s complexity as high, medium or low. A number of points are added up as each category is answered: 1 point for low, 2 points for medium and 3 points for high. The total score of the project determines its complexity factor that is then utilized in providing the initial estimate. If the total score is between 8 and 12 points then it is a low complexity project, if it is between 13 and 18 it is a medium complexity project, and if it is between 19 and 24 it is a high complexity project. Note that not all software development organization can follow this model although it may be used as a start. For example:
As you can see, estimating is an art. Don’t you think so…? Well, I do.
Email This Article