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.
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:
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.
Copyright � 1995-1999. All rights reserved