Project Management

Use this process to estimate a project's effort hours

Once you understand the effort that's required for a project, you can assign resources to determine how long the project will take and estimate labor and non-labor costs. Here's a process you can use to estimate the total effort required for your project.
Editor's note: This article was originally published December 11, 2006.

There are three early estimates that are needed for a project: effort, duration, and cost. Of the three, you must estimate effort hours first. Once you understand the effort that's required, you can assign resources to determine how long the project will take (duration), and then you can estimate labor and non-labor costs.

Use the following process to estimate the total effort required for your project:

  1. Determine how accurate your estimate needs to be. Typically, the more accurate the estimate, the more detail is needed, and the more time that is needed. If you are asked for a rough order of magnitude (ROM) estimate (-25% - +75%), you might be able to complete the work quickly, at a high-level, and with a minimum amount of detail. On the other hand, if you must provide an accurate estimate within 10%, you might need to spend quite a bit more time and understand the work at a low level of detail.
  2. Create the initial estimate of effort hours for each activity and for the entire project. There are many techniques you can use to estimate effort including task decomposition (Work Breakdown Structure), expert opinion, analogy, Pert, etc.
  3. Add specialist resource hours. Make sure you include hours for part-time and specialty resources. For instance, this could include freelance people, training specialists, procurement, legal, administrative, etc.
  4. Consider rework (optional). In a perfect world, all project deliverables would be correct the first time. On real projects, that usually is not the case. Workplans that do not consider rework can easily end up underestimating the total effort involved with completing deliverables.
  5. Add project management time. This is the effort required to successfully and proactively manage a project. In general, add 15% of the effort hours for project management. For instance, if a project estimate is 12,000 hours (7 - 8 people), a full-time project manager (1,800 hours) is needed. If the project estimate is 1,000 hours, the project management time would be 150 hours.
  6. Add contingency hours. Contingency is used to reflect the uncertainty or risk associated with the estimate. If you're asked to estimate work that is not well defined, you may add 50%, 75%, or more to reflect the uncertainty. If you have done this project many times before, perhaps your contingency would be very small -- perhaps 5%.
  7. Calculate the total effort by adding up all the detailed work components.
  8. Review and adjust as necessary. Sometimes when you add up all the components, the estimate seems obviously high or low. If your estimate doesn't look right, go back and make adjustments to your estimating assumptions to better reflect reality. I call this being able to take some initial pushback from your manager and sponsor. If your sponsor thinks the estimate is too high, and you don't feel comfortable to defend it, you have more work to do on the estimate. Make sure it seems reasonable to you and that you are prepared to defend it.
  9. Document all assumptions. You will never know all the details of a project for certain. Therefore, it is important to document all the assumptions you are making along with the estimate.

This type of disciplined approach to estimating will help you to create as accurate an estimate as possible given the time and resources available to you.

-------------------------------------------------------------------------------------------------------------------

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
18 comments
pamoli01
pamoli01

Is there a method to estimate non it projects like process transition projects, or projects involving M&A etc?

animeshmehra
animeshmehra

Nice article. eConcinnity.com is currently looking for estimation experts. If you are interested, please submit your credentials to them at http://www.econcinnity.com. You can join and work online in part time mode. Thanks

reisen55
reisen55

As an independent consultant, and I assume many post here, how many of us have experienced Project Hell where our best work estimate falls to pieces because of unexpected point failures along the way? Those projects that just grow because of unknown failures and things that go bump in the night? I do not enjoy, and sometimes take a considerable hit, from these hellish events. Those projects that you estimate should take 4 hours but really take 14 hours because of (oh, for example) power supply that dies along the way, system issues, software issues, bad motherboard affecting some other issue, etc. My BEST effort, then, is to accept these little wars as unwinnable - and bill for the four lousy hours or whatever my initial estimate was, swallow the rest and have a stiff drink at the end of the day.

tprensa
tprensa

I found these suggestions very insightful and I used this process regularly to estimate projects. It works.

Marty R. Milette
Marty R. Milette

When bidding on a project, I usually take what I consider to be a 'reasonable' estimate and then double it. I've never come in at under the actual time, but haven't gone much over either -- enough to eat anyway. The real problem is to get management to BUY a fair and reasonable proposal. Ever hear something like, "You want 120 man-days for this project? We only budgeted for 40! Can you do it in that?"

ps2goat
ps2goat

I had a potential client who wanted an overhaul on his website, but he didn't have everything set in stone. However, he wanted a quote, and I wanted to provide it for free, as that sort of thing is usually what people look for. He couldn't understand why my price was so high, though, as I guessed at the high end of the spectrum. Better to bid high and refund some of the money than to bid low and ask for more. Initial consultations may now be free, but I won't allow myself to go into too much depth without some kind of down payment for reviewing the system. I bet I put in at least ten hours looking over the system, only to have the potential client take his business elsewhere. (I refused to work on a website and not upgrade the security risks, i.e., SQL Injection holes and the storing of credit card numbers (including CVV2 codes!) and passwords in plain text within an Access database.

Tony Hopkinson
Tony Hopkinson

1 - 7 = guess 8 if you think you guessed wrong twiddle. The big problem with this is step eight all too often becomes reduce contingency and rework in order to make the project saleable. And the assumption that your technical types will wave their wands and get, at least, you out of the mass grave you just dug is never documented. Guess , do some work, guess again, do some more work, guess again. The guesses will get more accurate as you go along. That way you don't get to 1 week from completion and get 'surprised' by another 10 weeks work. Still using Waterfall estimation concepts in what is generaly a much more agile environment.

reisen55
reisen55

I have found it wise to begin estimations well in advance of a project. Do not do it last minute. I am not writing of true emergency projects here. Take your time because there are always those projects holes and missed assumptions that can add hours to a thing. Walk around your estimate, think about it, then discard it and look at it again. If you are doing client work, try to avoid THE DEADLY PROJECT CREEP scenario. This is where a project starts out with a given beginning and end goal, and slowly has parts and segments added to it as users put in new wish lists desires and management would ALSO like to have this done too (since you are on site at 2:15 in the morning anyway and we are PAYING you enough) so that your simple or defined project becomes the equivalent of building the Empire State Building. In a snowstorm.

Tony Hopkinson
Tony Hopkinson

To come up with quote for how much. To see how you are doing. Unfortunately many seem to think that these two requirements can be served by one set of figures.

Tony Hopkinson
Tony Hopkinson

If you put in 'good' numbers, you look good. If you pick a few 'bad' ones, you end up with egg on your face. Nothing to with the process at all, is it, All that does is give you a way of managing the numbers not the project. It's not management of a project, but managment of an illusion of control.

Marty R. Milette
Marty R. Milette

The more up-front work you put into a proposal, the more likely you are to find out that the 'customer' has taken your work and 'shopped it out' to your competition for a better price.

jtheires
jtheires

This author says to estimate work by estimating the work! Although this is one obvious choice, other approaches can also be helpful. Of particular use are the estimation modeling tools that make use of valid, appropriate and contemporary historical data. SLIM-Estimate is one such tool that helps estimate software projects. Not only does SLIM estimate effort, but it also helps with duration and quality outcomes. As with all models, the quality of the output is directly related to the quality of the input. Therefore, care must be taken to gather appropriate and accurate input data, such as size (SLOC), team qualifications and management expertise. James Heires, PMP President EZ-Metrix code counting utility www.ez-metrix.com

dmacleod
dmacleod

Good article as always Tom, but please stop using the word 'accurate' in the same sentence as 'estimate'. It is not possible to be accurate as we don't know the answer; if we know the answer, we don't have to estimate. Provide a range estimate to enable decision-makers to understand the amount of uncertainty in the work package/project. Convert the range to a single 'planning value' using the standard formula. As Fred Brooks pointed out, if we don't have faith in our estimating methods, we will lack 'courteous stubborness' when defending estimates to others; in other words, it's too easy to buckle under pressure if you have only guessed the numbers. Estimates are not guesses. I spent my whole career as a project manager 'guessing' and believing that I was estimating. It's only in recent years when I have read some of the books that I understand what estimating is about.

reisen55
reisen55

During my time in corporate IT, we had a full weekend upgrade from Novell 3.12 to 4.11 and that was a process all of it's own. We did not quote per se, but we spent a full 2 hours writing down the steps, inclusive of 4 hours of ArcServe restore (which we almost left out) so that we did have a time-measurement to use against how far along we were. The upgrade went magnificently by the way.

reisen55
reisen55

During my time in corporate IT, we had a full weekend upgrade from Novell 3.12 to 4.11 and that was a process all of it's own. We did not quote per se, but we spent a full 2 hours writing down the steps, inclusive of 4 hours of ArcServe restore (which we almost left out) so that we did have a time-measurement to use against how far along we were. The upgrade went magnificently by the way.

Editor's Picks