Improve Your Estimation of Software-Development

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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

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

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.

Lessons learned in scheduling software-development projects

	Debugging, documentation, and performance tuning are going to take at least as long as the programming. If it takes six months to design and build an application, it will take another six months to get it ready for prime time.
	Integrating an application into a larger software system will take twice as long as creating the application itself (including debugging, documenting, and fine-tuning the application) because of the complexity of the interfaces.
	If the software system your company is creating is highly similar to a system it has created before, you can be confident of your development schedule.
	If the software system your company is creating is an entirely new breed of animal, it’s virtually impossible to estimate how long development is going to take. Create a generous schedule that allows for unknowns.
	Be realistic when you’re trying to determine which of the above two situations applies.

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 Inc., which helps organizations turn around troubled software projects. He has done consulting work for numerous organizations, including IBM, Lotus, and Standard & Poor’s. He can be reached by e-mail at connell@chc-3.com or on the Web at http://www.chc-3.com.