The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Schdule Estimate

I am working with custom software development for several customers. During the pre-sales phase, we do effort estimates, that we have rather well under control, even if these are really rough.

How do you map effort estimates to schedules? I know the "standard" software schedule equation schedule[months] = 3 * man-months ^ 1/3.

However, that maps rather small efforts to comparably long schedules with few people allocated. For example, ten man-months end up with 6.5 schedule months times two people.

Do you rate the output from the above mentioned formula as realistic? How do you map effort to schedule?
Friday, October 21, 2005
In my opinion this standard formula is rather useless. The point is how much you can parallel. There is no rule of thumb, it's just up to developer experience to evaluate what can be paralleled and how long a single task may take. The approach should always be bottom-up.

I work with PowerPoint. A task in each box, one on top of the others in a column. If two tasks can be paralleled, I drag the two boxes side by side. Each task has a duration estimate. The total duration is given by the highest sum you can have going from top to bottom
Sevenoaks Send private email
Friday, October 21, 2005
You should only use a generic model when you have no experience data.  As your team has some experience, have everyone track their time for two weeks, in 30 minute increments.  Tell them not to put their names on it, just something like:
  Day 1:  2 hours on bug fix
          3 hours on meeting
          6 hours on new feature
  Day 2: Vacation
  Day 3...

Then summarize this against the estimate as a percentage.

If you find your team works 65% of the time on coding tasks you can use that.  If you find your team works 25% of the time on coding tasks use that.  Some  common mistakes:
  - dislike the number so use one they like (90%)
  - assuming everyone is interchangeable (all programmers cannot code network devices)
  - having an expert estimate and someone else do the work
  - assuming adding tools/people to a late project will make it come in on time
  - assuming adding new people to a team has only positive effects on the timeline (you should assume each new person is a 30% draw on an experienced team member for 90 days)

All these making it certain dates will be missed. 

If you have absolutely no idea, then the formula above is as good (or bad) as any.  Again, track everything for a few weeks to adjust the time-lines as soon as you can.

PM is moving toward science, but it still has a lot of art to it.
Thursday, October 27, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz