Application Development: Improve your company's ability to estimate software-development cycles (Datamation, April 1999)

Improve your company's ability to estimate software - development cycles (cont.)

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.

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.

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.