Software Project Estimation Part 1: Introduction

This post is part of my series on Software Project Estimation:

One of the biggest challenges I have run into in the course of my career is coming up with good estimates for completing software projects. So many times I am overly optimistic when coming up with an estimate, or I completely forget about certain pieces or steps, and the resulting estimate is insufficient.

When the estimate for a project is too small, one or more of the following will always happen:

  1. Requirements will be either intentionally or unintentially left out of the finished product.
  2. The team will rush through the construction of the project. This rushing will cause the quality of what is being developed to suffer.
  3. Time will be stole from later phases of the project to allow more time during construction. Most of the time this time will be taken from the Testing phase.
  4. The project  will be completed, but it will be delivered late.

In all of these cases, the project should be considered a failure. The customer will not be happy with the product they have received.

An estimate for a project that is too large can also be a problem.  The customer may reject the project because they don’t think they can afford it, or too much budget may get allocated to this project causing other projects to not be funded.  Another danger is that Parkinson’s Law may come into play.  This law states that the amount of time required to complete a task will always expand to fill the amount of time available for it’s completion. So people begin working slower on this project when they could be completing it and beginning to work on other things.

All of this can be avoided by establishing good estimates early on in the project.  But how can you come up with a good estimate to execute the project? There are a wide variety of methodologies for doing this, some of which are more accurate than others, and some can be applied earlier in the project than others.

This series of posts will address different aspects of project estimation and dive into several techniques.

The following posts will deal exclusively with the software development projects.  That’s where my experience lies.  But, I’m sure there are concepts and principles here that apply to the completion of any type of project.


6 thoughts on “Software Project Estimation Part 1: Introduction

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s