Scope changes during specification process

As a project manager I am in charge of creating technical specifications for projects and generating estimates based on these specifications. 

There are generally 2 stages in this process.  The 1st stage is defining the spec with enough detail that one can generate a ballpark estimate.  This estimate is then used to bid for a job.  It is rare that we can accurately detail the functionality before bidding on the job, mostly due to time constraints.  A ballpark is all you can do.

If we are awarded the job, the next step is to actually create a functional specification which will be used for 2 purposes: to have a final specification for development and to generate an accurate cost for the job. 

In the 3 years I've been doing this, I noticed there is almost always a scope increase between the ballpark estimate and the final number.  Controlling the increase during the 2 stages is a crucial component of my job.  However, it is almost always going to happen.

Does anyone here have any objective numbers on a reasonable percentage of increase to expect?

This question does not deal with controlling costs after the development has started.  That is another issue. 
 

Frogmoses
Friday, April 23, 2004

Nobody can answer that without knowing how you're determining your "ballpark" estimates. Are you counting things like feature or function points, or just winging it?

Ron
Friday, April 23, 2004

You might find some useful information in Rapid Development, by Steve McConnell.

Pakter
Friday, April 23, 2004

>Does anyone here have any objective numbers on a >
> reasonable percentage of increase to expect

What have been your numbers in the past? Perhaps
that's a good measure in the future.

Then do analysis and see why the numbers are off.
See if you can do better in the future. But as you
say you will always be wrong, but being less wrong
is nice.

son of parnas
Saturday, April 24, 2004

I use historical analysis to do my ballpark so in general they are pretty accurate for what they are intended to be.

I allow for change in scope while developing the functional spec, and because of that I can refine the costs when it happens. 

There is a point at which I will say, no-more changes.  If the customer then requires changes after that point, its handled thru change control with the costing done as additional cost.

If you are not gathering historical metrics on how long it takes to develop stuff and how much it costs you should be. Its the only real way you will get near accurate ballparks without resorting to some level of guessing.

Andy Watson
Monday, April 26, 2004

Thanks for the comments.  This is one of those cases where I "knew" the answer but wanted to hear someone else say it.  It is all about refining the estimation accuracy based on historical data.  I guess part of why I asked the question is that we haven't built too many of these large systems and so the historical data is not present.

This whole issue was brought into focus this last week because we are building 2 systems for 2 different clients and my bosses are very anxious about the costs.  I told them the ballpark estimates are not "final" because there is always a bit of creep.    They didn't really want to hear that.  Another part of my question was also to affirm the reality that scope creeps and is to be expected up to a point.  Knowing this will allow me to manage expectations on my end. 

What I would like to eventually be able to do is to have a realistic idea of how much a project typically creeps and present that number to my bosses without ever mentioning the lower figure.

Again, thanks for the comments.

Frogmoses
Monday, April 26, 2004

  Recent Topics

  Fog Creek Home