Eric Wise

Sponsors

The Lounge

Blogs I Read

Fun & Games

Advertisement

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Estimating Cost and Schedule

One of the biggest challenges I've had managing the projects I've taken on over my career have been properly estimating the cost and schedule of a project.  In the majority of situations, cost and schedule seem to end up being a shot in the dark of me guessing how long something will take, then increasing the time just to be safe.

Here is a glance at how I estimate things (keep in mind I do web development and favor a basic 3 tier design):

  1. Do user interviews and get a good solid grasp of the project's goals.
  2. Make a list of objects that will be needed to meet the goals (it won't be 100% correct, but make your best effort to get it into the ballpark)
  3. From the objects, you have a pretty good start on your database tables, make a list of these and any stored procs that are going to be needed.  (Or no stored procs if you're going in-line sql for database independence)
  4. Lay out the most comprehensive list of UI pages/forms that you can.
  5. Determine from past experience, how long it generally takes you to code an object of varying complexity- low, medium, and high.  How you define low, medium, and highdepends entirely on your own experiences as a developer.  As a rule of thumb, I define low as something I can build in less than 2 hours, medium is 2-6 hours, and high is more than 6 hours and really is a judgement call.
  6. Now assign all your objects, UI, and database stuff you defined above to low, medium, or high.
  7. Do the math.
  8. Now increase this time estimate by a % you are comfortable with.  For me, the comfort level depends on the overall size and complexity of the project, the ability of the users to communicate their needs (add more time if they're wishy-washy or design your contract accordingly to prevent getting screwed by change requests), and your general level of enjoyment for the type of project (obviously something I think I'll enjoy doing I'll be more productive).  The % mark-up for me generally starts at 50% and ranges to 125%.

I'm curious to know how you other bloggers do your estimations and scheduling.  How do you measure something that doesn't exist?


Posted 08-04-2004 7:56 AM by Eric Wise

[Advertisement]

Comments

Darrell wrote re: Estimating Cost and Schedule
on 08-04-2004 4:19 AM
We don't often do "point" estimates like you do. We have to continually provide estimates to the customer for budgeting purposes, but all of our estimates are provided as ranges unless I have solid data to compare to (something similar took me 2 days to do last week, so it will probably take 2 days this week). The ranges are higher as the scope is more uncertain. Then, as scope gets nailed down and the requirements are fleshed out, the ranges become tighter, until I get down to point estimates. But I usually only estimate points out as far as 2 weeks, maybe a month if we're doing Scrum. :)

By the way, customers hate range estimates but I stick by them. And if they try to take the low end of the range, I politely but firmly stick to the original range. If they absolutely insist on a single point, I give them the high end of the range. Absolutely every client has asked me to reestimate, I think it is standard practice. :) But politely standing firm usually garners more respect in the long run, in my opinion.
Jon Choy wrote re: Estimating Cost and Schedule
on 08-04-2004 5:59 AM
That sounds like a great way to do a procedural design estimate. The OO nature of these projects seems questionable though. (Much like the OO nature of the development at our last common employer)