How To Estimate Time For A Project

clockWhether you bill clients hourly or on a per project basis, a necessary step of all projects is estimating the time it will take. Not only does the client want to have an idea of how much money they will be spending, but they also need to plan around an estimated timeline. And you need to be able to ensure you have the time and resources necessary to complete the project.

Depending on a number of factors, including how much experience you have with the type of work you’re doing, if you are using subcontractors, and the information you have from the client, estimating the time for a project can be difficult. Here is the process I use when scoping the time commitment for a new project.

Identify Deliverables

The first step is to identify the main project (i.e. Website Redesign), and then pinpoint the specific deliverables associated with the project. For example, upon completion of the redesign, you will be providing the client with a newly designed website by FTPing the site files and sending the client a CD or USB drive with the working files.

Break It Down

Next, I take the project and break it down into simple tasks separated by component – the more specific the better – that will get us to the deliverables. Here is an example of what the tasks may look like:

Project Planning

  • Initial meeting with client to gauge scope of project
  • Provide client with project information sheet to get more information about what they like/don’t like about their existing site
  • Review/analyze existing site and client form
  • Develop list of areas site changes to be made
  • Get approval from client

Design

  • Design site mockup
  • Get approval from client
  • Code pages
  • Create new navigation
  • Reorganize content into new pages
  • Optimize for SEs

Testing

  • Cross-browser testing
  • Validate code
  • Check links
  • Test forms

Add It Up

The next step is to estimate time for each task, rounding up. If you are using subcontractors, you will need to get their time estimates first and work them into your time. Then take the total time for all of the tasks and add in a buffer. The buffer can be anything, although I usually stick with a 10-25% addition. This allows for any unexpected situations or challenges that arise.

Things to Keep in Mind

The more time estimates you do, the more accurate you will be. As you create your own formula, some other factors you may want to consider include:

  • Project management time
  • Time to review work of subcontractors
  • Holidays or days off that occur during the project
  • Client turnaround time
  • Debugging

How do you ensure your time estimates are as accurate as possible?

Image credit: Federico Belloli

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Rish

    Good article. Funnily enough i just went through the pleasure of redesigning our website (www.indesignlive.com). What you have outlined makes an excellent checklist to base the project on. If I could add one thing, it would be spending a bit of time improving the CMS if required.

    Of course this depends on how frequent your website is uploaded and whether a CMS is an viable option over coding raw html, but well done!

  • larrybailey

    Hi I’ve been offered to make one program for small office management, and I need to estimate approx how many man-hours it will require. I perfectly understand that thsi kind of estimation is very rough, I made my own estimation, but help from more expierenced people would be really great!

    what I want is just personal opinion of those who
    did simular things before or any hint would be helpful.

    ok, here it is:
    ———————————————
    The company give financial consulting services to clients. Three kinds clients of exist in system. There may be “one time” or “long-time” (many years)clients. Every month generate
    bills and prints them and credit clients’s pay-card. Although bills and reports may
    be generated at any time. Clients details and all reports are stored in system(?!)

    Clients’s payments prosseced by external finanicial propgram that output receipts.
    Receipts’s details are entered by human operator to system (client’s pay-card updated).

    Clients assigned to office workers. In the end of each day worker enter how much time she spend on every of her clients. System has to watch that
    all work day would be distributed between clinets, i.e. no idle time.

    Manager produce various reports from colelcted data. This is critically important
    data for defining profitability of client.

    There are about 20 users of the sytems. This is one system for all of them. As some function should be allowed for some type of users, then
    access to system defined by user status. They all may work with system at the same time.
    ————————————————–

    Customer wants this application be done in MS Access, as he understand something in it and wannt to tweak with it sometime afterwards.
    I think VB is better decision….so any opinion on this topic would be also helpful.

  • nachenko

    The best way to make an estimation is comparing to other projects. I track ALL tasks using Kimai, an Open Source little app to know how much time I spend on every task for every customer, no matter if the task is billabe or not, if I’m billing hourly or per finished task. I recommend everyone to track their time.

  • markfiend

    When you have a time estimate, double it and increase the units.

    If you think it will take one minute, say two hours. If you think it will take two hours, say four days. If you think it will take three days, say six weeks. The unexpected WILL happen and you WILL need that extra time.

    And if you come in closer to your original estimate, well, it’s always better to under-promise and over-deliver than the other way round.

  • aemciv

    / well said

  • Anonymous

    @markfiend – I would never hire someone who estimated this way to perform a job and I would fire them if they had already been hired. Why not just say it’ll take 10 years, and if it takes less I’ll be “wowed”, right? Please.. estimating by padding the crap out of everything you do is a band-aid to bad estimation technique.

    The greatest thing you can do for a project is NOT estimate when you will be finished with the entire project up front. If your client will accept this, you can provide them with an estimate of what you will accomplish this month. And then you will estimate for the next month. And so on until you can see the finish line more clearly. Not only does this give you much more focused development and the ability to break the project into manageable pieces, but it gives the client the ability to make changes rapidly and see the results.

    Here are some guidelines for better estimating, regardless of whether you develop in an “agile” or “waterfall” style…

    1) The smaller the task, the more accurate the estimate. However, breaking something into tons of tiny little tasks tends to cause people to forget things that are important. So break down one level at a time.
    2) When estimating tasks, allow 1 hour, 2 hours, 4 hours, and then multiples of 8 hours. The rationale here is that larger tasks should be more grossly estimated, where as smaller tasks will be easier to understand and accurately estimate. Small: set up and test FTP server, 2 hours. Large: implement auto-renamer function for files in the FTP directory, 24 hours.
    3) For every task, consider not just the performing of that task but also the testing and verification of that task. For a task like “implement auto-renamer function for files in the FTP directory”, add a related task for “test auto-renamer function”. In development, # of test hours = # development hours is a good place to start.
    4) The most common reason for underestimation in a task is uncertainty. If you are uncertain about a task, get more clarification on it before estimating. If you can’t get it, then you can apply the padding that mark was talking about — but reasonably. Take the worst-case scenario you can think of and use that.
    5) The highest impacting reason for underestimation is CHANGE. If you estimate A and your client adds in “something simple” here and “something simple” there, you are now looking at B, but your estimate says A. Always provide re-estimations when there is ANY change. Providing those estimates to your client will help them understand the impact to cost and timing. If you are in a fixed-bid project, change should go through a FORMAL change review process.

    Hope this is helpful…. thanks for the article, great to have people pushing for better understanding of estimations. One thing that’s really helpful to remember is that “estimation is guessing”. Too many people say that once an estimate is given, you should be held to it. This leads to insane padding and overcharging (or profit loss, depending on how badly the project goes), and is not good for the client and is not good for the vendor.

  • Dan R

    @markfiend – I would never hire someone who estimated this way to perform a job and I would fire them if they had already been hired. Why not just say it’ll take 10 years, and if it takes less I’ll be “wowed”, right? Please.. estimating by padding the crap out of everything you do is a band-aid to bad estimation technique.

    The greatest thing you can do for a project is NOT estimate when you will be finished with the entire project up front. If your client will accept this, you can provide them with an estimate of what you will accomplish this month. And then you will estimate for the next month. And so on until you can see the finish line more clearly. Not only does this give you much more focused development and the ability to break the project into manageable pieces, but it gives the client the ability to make changes rapidly and see the results.

    Here are some guidelines for better estimating, regardless of whether you develop in an “agile” or “waterfall” style…

    1) The smaller the task, the more accurate the estimate. However, breaking something into tons of tiny little tasks tends to cause people to forget things that are important. So break down one level at a time.
    2) When estimating tasks, allow 1 hour, 2 hours, 4 hours, and then multiples of 8 hours. The rationale here is that larger tasks should be more grossly estimated, where as smaller tasks will be easier to understand and accurately estimate. Small: set up and test FTP server, 2 hours. Large: implement auto-renamer function for files in the FTP directory, 24 hours.
    3) For every task, consider not just the performing of that task but also the testing and verification of that task. For a task like “implement auto-renamer function for files in the FTP directory”, add a related task for “test auto-renamer function”. In development, # of test hours = # development hours is a good place to start.
    4) The most common reason for underestimation in a task is uncertainty. If you are uncertain about a task, get more clarification on it before estimating. If you can’t get it, then you can apply the padding that mark was talking about — but reasonably. Take the worst-case scenario you can think of and use that.
    5) The highest impacting reason for underestimation is CHANGE. If you estimate A and your client adds in “something simple” here and “something simple” there, you are now looking at B, but your estimate says A. Always provide re-estimations when there is ANY change. Providing those estimates to your client will help them understand the impact to cost and timing. If you are in a fixed-bid project, change should go through a FORMAL change review process.
    Hope this is helpful…. thanks for the article, great to have people pushing for better understanding of estimations. One thing that’s really helpful to remember is that “estimation is guessing”. Too many people say that once an estimate is given, you should be held to it. This leads to insane padding and overcharging (or profit loss, depending on how badly the project goes), and is not good for the client and is not good for the vendor.

  • thesambarnes

    Breaking the project down into as granular detail as possible is always the best way as it often forces the person or team estimating to consider tasks that they may have overlooked if providing a more of a ball park figure.

    But I find a good starting point is always to reference previous similar projects, or projects that contained similar tasks. For instance, by tracking all the estimated and actuals of past projects can give you an average percentage that each phase took and you can use this average as a good guide. For example, by collecting stats like these for my past ten projects I was able to identify trends like:

    * The Site IA and functional specification usually took around 8% of the total project time to complete and get approved
    * Functional specification 5%
    * Design 30%
    * Back-end development 30%
    * Front-end development 15%

    And so on…

    Using these averages, and with a client’s maximum budget, you can begin to immediately allocate a rough amount of time to each phase and then break out each in more detail, but with the roughly allowed hours available known beforehand. With this initial capped limit in place, you can estimate not only your costs but also the most cost-efficitent solution based on the budget, rather than going in with a blind quote that may be way to small or too high.

    Of course, this is dependent on knowing the client’s budget beforehand, not always possible, but more possible than most seem to think if you just explain you want to deliver the best solution for the price.

  • Anil Gulati

    Sure it’s nice to have a starting point on this subject but that little step:
    – code pages
    explodes into a whole new world when you are scripting.

    When substantial design is involved the uncertainty on this step is sometimes impossible to resolve. Generally the client’s expectation then starts to influence the proposed timeline at this point.

    As others posted, it really helps if:
    – you’ve done the same kind of thing before
    – you can break it down further and get as much certainty as possible
    but I usually find scheduling is the last frontier for most substantial works.

  • Dave Keays

    I am relatively new to online consulting but I have years of experience on the desktop.

    The two major problem I’ve had with estimates so far are very similar to those on the desktop I experienced in my early years. There is the client who hands me a mock-up or says “I want to clone the functionality of xyz.com”.

    They generally do not appreciate my asking more questions and trying to pin the work down (“what about the next page?”, “how do you want the foobar to look?”, “how do you want it to act?”). I don’t see what is wrong with trying to get it right the first time.

    The only advise I’ve received is to do a basic job upfront and then get the client to pay to refine it. Sounds sloppy to me at best. I guess I have to just grin and bear it until I have enough history that I can go by the past.

  • thesambarnes

    Hey, this post inspired me to wite a more detailed two part article on estimating time more accurately for web projects that expands on my comments above.

    Please feel free to check them both out at:

    Estimating time for Web Projects more accurately: Part 1

    Estimating time for Web Projects more accurately: Part 2

    Thanks,

    Sam

  • 3doos

    thank you ,it is really great;because this is the first time i have to give estimate for new project ….