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.
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.
Managers can help by keeping system definitions constant. The system a team of engineers is creating shouldn't be a moving target. Management should use a good planning process that accurately defines the feature set for the software, and then resist making big changes once development begins.
Step 2: Make sure engineers are invested in the overall success of the organization.
The idea is to tie programmers' careers to the success of the organization so they will be motivated to complete software as quickly as possible while maintaining high quality. Profit-sharing, stock options, cash bonuses, extra vacation time, and other incentives can be used to encourage engineers to set the shortest-possible realistic schedules when new systems are in the planning stages.
Step 3: Give experienced engineers significant input in the creation of development schedules.
It's like planning the construction of a house. You wouldn't try to estimate the completion date without talking to people experienced in pouring foundations, framing walls, and installing heating systems.
Significant input means experienced engineers who have worked on similar projects are involved in decision-making from the very beginning of the planning process (including discussion of the proposed system's features list). By contrast, if a manager says, "We have decided this project can be finished in four months, and we'll all work nights and weekends to get it done, and you agree — right?" engineers might nod, but they'll soon create their own "real" schedule.
In extreme circumstances, significant input should even include veto power over the schedule. But engineers shouldn't use that power lightly: Software developers must recognize the validity of input from other departments, such as marketing, and must keep in mind the needs of the organization as a whole.
Engineering groups should be encouraged to think of themselves as mini-managers, weighing the need for speed against the need for quality, and helping the company to compete.
Managers are always trying to balance the need for a calm, productive working environment against the need to beat the competition. Software developers should become adept at that balancing act, too.
Charles Connell is president of CHC-3 Consulting and writes frequently on computer topics.
DATAMATION Copyright © 1995-1999. All rights reserved. For information on reprints or electronic licensing of this story, call EarthWeb at 212-725-6550.