2005.09.22
Optimising planning
by Karel Thönissen

In the Joel On Software forum Astarte wrote:
[...] Because many of our managers are ex-developers, they are often able to make a fairly accurate 'gut-feel' estimate of how long coding something 'should' take. Estimating how much testing time we need to allocate seems harder - development managers want to minimize this time (so they can ship earlier or with more features) and, as the QA manager, my team of testers want to maximize this time to reduce the risk of shipping garbage. [...]
You can plan on Time, Quality and/or Costs. Pick any two.
If minimising time to market is the objective, then making an estimate is ungrateful, but not difficult: anything you say will be reduced anyway. Anything you say is unimportant. Marketing has taken over development. Marketoids claim that they are better at software planning then the software department itself. From what you write, I predict that you are heading for politically difficult times. Run as hard as you can?
If management 'optimises' planning, then they become responsible for creep, slipping schedules, etc.
If management needs estimates to plan market development, training people, capacity planning, budgetting, etc., fair enough.
The request for an estimate is justified for reasons stated above. However, in this case, I would say that the first objective should be to get hard data. You do not know the dev:test ratio. Not knowing process indicators like this, all planning is glorified guessing. Management should provide budget for collecting this data, even if this extends development time.
|