Estimating

I was working today with a client on estimating how many man-hours their project was going to take. It was a pretty straightforward exercise; estimate the number and complexity of all the components of the project and apply benchmark data we’ve collected and add it all up to come up with a total. At this early stage in the project, there is some margin of error in what we refer to as a budgetary estimate. It’s more refined than a level of effort but not a detailed estimate.

The resulting answer was pretty big and the client thought it was much bigger than the project would actually be, and he might be right. Under ideal conditions, the project may take much less time. However, having done projects before, I know this perfect state for project execution is rare. Things often come up. There’s some requirement that didn’t get identified but is a must-have. Problems creep up. People get pulled of the project for something else, or quite or get married. Some features take longer than the benchmark would indicate.

For now we’ll keep an eye on this estimate while we start our first iteration. After we complete that, we’ll see if our estimates for those features match reality. Then we can adjust the overall estimate as necessary.