# The Art Of Estimating

**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

### Comments

21 Responses to “The Art Of Estimating”

May 1st, 2010 @ 3:06 pm

I too have successfully applied the pert model to estimating the development resouces needed to define, develop and test software.

May 1st, 2010 @ 5:02 pm

Jorge,

I also use Pert in my estimations. However, I found that a lot of people do not understand it. So, I usually do not disclose the O,P, M. I just give them the Pert estimate.

May 1st, 2010 @ 6:03 pm

Maybe there’s confusion regarding what we “estimate”. First response is usually TIME -days/weeks/months a project would last-, an answer I disagree.

Timing is, from my -and many authors- point of view, related to project scheduling rather than estimating, and PERT is a good example. The REAL estimation lies in effort involved in each task (node). A 3-scenario ETA (O, M and P) is a fairly simple method for estimating number of days (time) a task will take and we manage precedencies in order to have total number of days project will last, but how we get the O, M and P is the actual estimation and where the complexity of estimating is. Once we have the estimates and precedencies, PERT will do the rest… I don’t see a challenge there.

Each industry will provide methods for effort estimation (use case points and function points, in Software; tables in Construction are examples), existing very few common to all (expert judgment, market prices analysis, wideband delphi). Good managers will recognize and properly apply most suitable(s) in each case, and here’s where the complexity is.

Here’s a pretty useful reading for Software project managers, a must if you ask me: “Software Estimation: Demystifying the Black Art”, from Steve McConnell.

Enjoy!

May 1st, 2010 @ 6:34 pm

I agree with the last comment, estimation really relates to the effort needed to do a specific task. There is lot of methods as it was mentioned, like expert judgment, market prices analysis, parametric, top down, bottom up, etc. Depending on the industry or the type of project specialists may select one of them or a combination of techniques. But, If we are talking about project scheduling I would agree with PERT technique.

May 2nd, 2010 @ 12:10 pm

I think it is inappropriate to call PERT “Accurate”, it is just a formula that works well. Accuracy is still the skill of the estimator providing the values in the formula.

PERT results in the three part estimate which should always be provided. It is not necessary for the recipient to understand PERT but they will certainly understand being told “best case, worst case, and most likely” outcomes. That is the only honest way to provide an estimate. Providing a single number results in expectations that can hurt you and remove the natural flexibility in the three part estimate.

It is important to remember that estimating is predicting a future outcome. We can never do that “Accurately” Although with good techniques we can come close but only if the assumptions we made when estimating happen to come true.

I have been estimating software development for over twenty years and will be happy to expand on this or to answer questions. I am always delighted to see people working at improving estimating.

May 2nd, 2010 @ 1:29 pm

I couldn’t agree more with Peter. Accuracy will be given by accurate O, M and P effort estimations and selecting most likely scenario rather than just applying PERT.

Speaking about methods based on probability, Montecarlo is nowadays the evolution of the good old PERT. Given size of my project, I’ve never had the chance to apply it, though.

May 3rd, 2010 @ 1:50 am

On a lighter note….

Estimation is like you put a number and pray that you are not far off.

Contingency is a crucial component…too much in your your, you may not win a project, while too less, and you may loose your shirt…

Optimization of contingency is a key…thats where the estimators skills and experience comes into picture. Risk analysis is the key feature….Monte Carlo is a good option.

My Prof always says – you win a project not because your estimators did a good job, but other made mistakes, but the money you make depends on how you much wrong you prov your estimators.

May 3rd, 2010 @ 7:05 pm

Great article – thank you for sharing. Another concept I use estimation is communicating the level of accuracy with any estimate. The level of accuracy is based upon the understanding that the estimator has when developing the estimate. Too often I see ERP projects not estimated correctly due to the level at which they try to estimate (Order of Magnitude vs. Definitive). Too often I see that reserves (management, contingency) are used to account for estimation accuracy. Personally I feel that this approach is incorrect.

May 3rd, 2010 @ 7:21 pm

I use a similar concept to Brett’s. I refer to the “confidence” level of the estimate rather than accuracy, but the idea is the same. If you have a three part estimate you can calculate the probability of any number in that range. Statistically you have a 95% (approx) probability of being under your worst case, a 5% (approx) probability of meeting your best case and a 50% probability of being at or better than your most likely. The spread between your best and worst case is an indicator of the degree of uncertainty. less uncertainty equals higher conficdence.

May 3rd, 2010 @ 8:27 pm

Jorge,

Great article. looking at PERT as one of the estimating techniques. if you use it all the time, are you able to find all your critical paths?

May 3rd, 2010 @ 8:43 pm

Dare,

Thanks for your comment.

Regarding your question: When I say I use it all the time I mean PERT is the technique I use most often. As others pointed out, you have to use the right technique for the project.

I am always able to find the critical path(s) because I, as the PM, will choose the expected time (which is the end result of calculating PERT, see the formula) to produce the time effort and eventually the schedule.

Best regards,

Jorge Dominguez, PMP

May 3rd, 2010 @ 11:42 pm

One of the best books I have read on how to improve estimates is “How to Measure Anything” by Douglas Hubbard. In a part of this book he explains that estimates are often given as single numbers by domain experts who are good at what they do but they are not good at estimating. He suggests that estimates should always be discussed as and given as a range. For example, instead of saying I will do it in 3 days, you would say I have 90% confidence that I will do it in 2 to 5 days. He goes on to describe a method to sum the estimate ranges and come up with a total estimate range for the project (25 to 45 days). He also proposes an approach to computing an expected value if you need a single number estimate. But he recommends that you explain the limitations of this single number and what it means to anyone who is asking. The wider the range the more uncertainty there is in the estimate and he suggests various techniques and analysis (if worthwhile depending on project size) to reduce that uncertainty.

We have applied these techniques in some of our software and consulting projects with very good results. The estimates given by our domain experts has improved significantly. We are working on adopting more of the techniques he recommends in our project size and complexity assessments.

May 6th, 2010 @ 7:55 am

Good approach Jorge, thought people still like to reply more on the “gut” feel to work on the WBS approach.. else if they are too meticulous, then tend to go the scientific way – the way FPs are..

But ya. PERT gives a head up for an approx estimate for work. and has worked for me a lto many times..:)

May 6th, 2010 @ 8:10 am

A decent article on one of my favorite topics estimation and PERT’s reliability.

In my experience, this “art” of estimating is based primarily on the PM’s experience and grasp of the current project at hand. Medium and larger size projects have so many moving parts (resources) that unless requirements are adequately nailed down at the onset, the project will suffer or die.

Your/PMI’s formula often works but it’s the quality of resource hires and their ability to “take over” and then “own” activities as scheduled, is often a crap shoot. (The question becomes: how much project time & money are left–when they are [finally] brought in?)

In my experience, outsourcing is the key. If your estimate is based on shallow experience or textbook learning, larger projects will invariably stumble, fall behind, and run out of money. If the lead PM’s judgment regarding estimation is strong, tested & well-reasoned understanding of thew requirements, success can follow. This said, the best laid plans … depend on the quality of task fulfillment. And, doesn’t this bring us back to budgeting, the lynchpin of estimating?

If the sponsor is looking for low-bid, guess what, he’ll wind up getting what he (DIDN’T) pay for. On the other hand, if he/they have deep pockets, your estimating can get a lot better in a hurry. Not only can internal (organic) project workers be better trained, but they can be complemented by superior

outsourcing talent who’ll make the difference.

Bottom line: if you’re new or untested, estimation is more science than art — as you follow the formulas/PMBoK very closely. When you’re battle-tested (and have the scars to prove it), you understand that estimation is really more art than science.

May 6th, 2010 @ 8:42 am

Thanks for the article – I think I’ll buy the book!

May 16th, 2010 @ 9:14 am

I think it is important to realise that many iductries do not use unit cost tables for estimating and instead do a bottom up estimate from first principles many times. Whilst still subjective, these are sometimes easier to perfrom sensitivity analysis on using specific factors.

On a lighter note, the blog linked below has a good article about the “soft” skills required by an estimator…

http://driftingandsinking.blogspot.com/2010/05/its-like-herding-cats-if-youre-mouse.html

May 16th, 2010 @ 9:15 am

industries! sorry.

May 17th, 2010 @ 8:27 pm

Jorge,

I found very useful your article, I want to comment only one thing: even you wrote in english I’d like you use the metric system, the english system must be ended long time ago, the same thing to the medieval mania to not use number 13 in the buildings floors or the airplane seats.

Regards.

June 4th, 2010 @ 12:00 pm

I like the PERT system, to. What’s not to like. I find that when I’m working with someone isn’t a project professional, they can see the value of a three point estimate. After all, even the simplest tasks in life have a range of effort – cleaning the house can take 30 min, 1 hour, or 2 hours depending on how dirty it is.

October 14th, 2011 @ 4:38 pm

Took me awhile to read all the comments, but I really enjoyed the article. It proved to be very useful to me and I am sure to all the commenters here! It’s always nice when you can not only be informed, but also engaged! I’m sure you had fun writing this article.

January 28th, 2012 @ 12:35 pm

This really answered my problem, thank you!