Software development, like all research, is impossible to plan from start to finish. Successful project management must reconcile the desires of software users with the constraints of software development.
Re-engineering books suggest that all companies have "core competencies." Organizations excel at certain skills for historical or accidental reasons. Projects that rely on these competencies give the organization an advantage that others cannot easily match. (Unfortunately, the idea became an excuse for eliminating skills.)
Software development is optimum when a single individual can master all necessary business and development skills. Much innovative software gets written this way, often secretly. The motto is "understand the issues and do the right thing." Communication is not an obstacle.
Sometimes two individuals split roles. One advocates features for customers and the other advocates simplifications in the software, perhaps changing the way customers work. The two argue constantly, but the result is very satisfying. The dialectic creates a product superior to what either could have designed alone.
Project management becomes necessary when a larger team must distribute skills. Too often project management prevents the necessary dialog.
A top-down management will specify features desired by customers, estimate resources required for each feature, then distribute tasks to developers within an overall schedule. This arrangement is suboptimum. Developers are not involved, or they are involved and committed to a specification before they understand the implementation. Lower-priority features remain, even if they prove to be more difficult than acceptable alternatives. Developers with special expertise lose opportunities for simplifications or innovations.
Development schedules with time lines and critical paths help manage foreseeable scenarios. When used well, development schedules distribute the load between developers. Schedules can help manage resources and expectations, but with limitations. Schedules omit uncertainties of research and design. A schedule assumes that the implementation is well understood. Even if time estimates include probabilistic errors, these estimates allow only for foreseeable scenarios.
A development schedule is useful only for the immediate future. Software components will be built in a certain order, with increasing uncertainty. The first component to be built, in the first month of the project, may be understood with ninety percent certainty by developers. The actual construction of that component will expose the ten-percent ambiguity in the specification. This uncertainty propagates to the next set of components to be written, with a proportionally weaker understanding of the design. Six months later, the original development plan may be entirely inappropriate. Early designs appear naive, and new opportunities appear.
All development plans thus become "spirals," whether acknowledged or not. If plans prevent adjustments between user features and software components, then the project becomes more inefficient than necessary.
Feature lists must not be confused with a design. Only constant discussion within the team can produce a design. Project plans invariably list features in their order of importance to users. Feature lists attempt to balance the complexity of the product with the available resources and schedule -- but they cannot.
Too much of the underlying infrastructure of software is invisible to users, and to project managers. A developer creates software components in order to implement desired features. Development times can be estimated and adjusted for components but not for features. A schedule is accelerated by simplifying or discarding components, not features. Only constant renegotiation can simplify development and remove the fewest important features. Lost features can be compensated with unforeseen improvements. Only when the product is finished can the design be complete.
Bill Harlan, Oct. 1998
Return to parent directory.