August 17, 2004

How do you educate an ignorant customer as to how software projects should be run? How do you explain to them that to estimate a software project before it is fully defined (or even after all of the requirements are nailed down) is theoretically impossible? How do you explain to them that you really haven't done anything like the current project before?

I suppose you start by acting from false experience.

"Look, we have run many projects, and our basic methodology is simple. First, we figure out what we are going to build. Then we provide you with a very loose estimate that will be in the form of a range of time such as 3-6 months. Then we figure out how we are going to build it. Then we revise our estimate. Then we start to build it. During the construction we will keep you informed of our progress by giving you milestone releases. These milestone releases will be feature-incomplete releases of the actual software."

"Changes to the requirements are not impossible, but will affect the schedule, as will other changes. For example, if one of our estimates is too long, we can revise a number of things about the product or staff in order to get it done for a specific schedule. For example, if our second level estimate of 3-6 months is nowhere near your fixed management deadline of 2 months, then we can remove features (change what we are going to build to make it smaller) or add staff (increase the number of people working on the project)."

"As we move forward with the project, these changes become more difficult to make. For example, adding staff very late in the project usually backfires because the original staff must train the new staff, and the new staff is not normally very productive for a while. Overall you end up losing time. Also, if you try to add significant features late in the game, this can affect the overall design of the system and can lead to a longer schedule."

"For this reason, we are going to spend a good deal of time figuring out what the system should be and how we are going to build it to decrease the risk of us running into these sorts of suprises. That said, if you try to minimize the amount of change requests, we will try our best to respond to the ones that you have."

August 17, 2004 03:17 PM