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