Back to CHC-3 Publications           CHC-3 Home

Improve your company's ability to estimate software-development cycles

Encourage software engineers to develop an eye for how long each project is going to take, then include them in the planning process--right from the beginning.


Illustration: Daniel Guidera

By Charles Connell


The scene is a hotel conference room near the Westford, Mass., offices of Lotus Development Corp. A team of software engineers has been called together for the kick-off meeting of the next release of Notes, Lotus' pioneering groupware product. The company has just shipped a major release of the software, and the management team tells the engineers what a great job they've done.

But the managers quickly get to the punch line: The next major release is only eight months away.

Then the managers explain why the next release has to ship so soon (so that Lotus can stay ahead of the competition) and how the engineers will meet the schedule (work hard).

In this true-life scenario the engineers might have been expected to feel a great deal of pressure as they walked out of the conference room that day. But I know otherwise, because I was one of those engineers. The schedule was so unrealistic that we felt we might as well relax.

The eight months passed. No one mentioned the deadline. We released the software more than a year later, nearly two years after the kick-off meeting.

It's just an illusion

An impossibly short development schedule for software, whether it's software for sale or for internal needs, creates an illusion that may benefit a management team in the short run (I've created unrealistic timetables myself as a manager). But in the long run it causes a lot of damage, including the following consequences:

For managers only:
Sometimes it takes a sixth sense

Just as engineers can learn to create development schedules, managers can learn to tell the realistic schedules from the unrealistic ones.

Look at the team's track record. Has the team met schedules it has given you before?

Does the schedule "smell" realistic? Does it include time for debugging, for working with the documentation team, and for beta testing?

Is the time accounted for? You can't have much confidence in an engineering team that schedules three months in which no specific tasks will be accomplished.

It hurts management's credibility.

It forces the documentation team to undo and redo its work.

In the case of software for sale, it causes chaos in the marketing team's attempts to schedule roll-out presentations and promotional tours.

The chaos spreads to sales, financial, and other departments.

The solution is to reengineer the time-honored method that is used in most companies to set software-development schedules. Instead of giving management teams full authority for scheduling, companies should encourage engineers to develop expertise in scheduling--and then tap into that expertise. Setting schedules should be a shared responsibility.

Step 1: Encourage engineers to include estimating abilities in their skillsets.

Software engineers aren't often told they need to develop the ability to estimate how long it's going to take them to write good code. As a result, time-estimating skills are relatively rare among programmers. Management should reward engineers with promotions and salary increases for their ability to meet development schedules they set for themselves.

NEXT >>

DATAMATION Copyright � 1995-1999. All rights reserved
For information on reprints or electronic licensing of this story,
call EarthWeb at 212-725-6550.