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

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.

Illustration: Daniel Guidera

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 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.