Page 199 -

170 PART TWO MANAGING SOFTWARE PROJECTS

Defined outcomes. Every task that is scheduled should have a defined out-
come. For software projects, the outcome is normally a work product (e.g.,
the design of a module) or a part of a work product. Work products are often
combined in deliverables.
Defined milestones. Every task or group of tasks should be associated with
a project milestone. A milestone is accomplished when one or more work
products has been reviewed for quality (Chapter 8) and has been approved.
Each of these principles is applied as the project schedule evolves.

7.2 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT

In a small software development project a single person can analyze requirements,
perform design, generate code, and conduct tests. As the size of a project increases,
more people must become involved. (We can rarely afford the luxury of approach-
ing a ten person-year effort with one person working for ten years!)
There is a common myth (discussed in Chapter 1) that is still believed by many
managers who are responsible for software development effort: "If we fall behind
schedule, we can always add more programmers and catch up later in the project."
If you must add people Unfortunately, adding people late in a project often has a disruptive effect on the proj-
to a late project, be ect, causing schedules to slip even further. The people who are added must learn the
certain that you’ve system, and the people who teach them are the same people who were doing the
assigned them work work. While teaching, no work is done, and the project falls further behind.
that is highly
compartmentalized. In addition to the time it takes to learn the system, more people increase the num-
ber of communication paths and the complexity of communication throughout a proj-
ect. Although communication is absolutely essential to successful software
development, every new communication path requires additional effort and there-
fore additional time.

7.2.1 An Example
Consider four software engineers, each capable of producing 5000 LOC/year when
working on an individual project. When these four engineers are placed on a team
project, six potential communication paths are possible. Each communication path
requires time that could otherwise be spent developing software. We shall assume
that team productivity (when measured in LOC) will be reduced by 250 LOC/year for
each communication path, due to the overhead associated with communication.
Therefore, team productivity is 20,000 (250 x 6) = 18,500 LOC/year—7.5 percent
less than what we might expect. 6

6 It is possible to pose a counterargument: Communication, if it is effective, can enhance the qual-
ity of the work being performed, thereby reducing the amount of rework and increasing the indi-
vidual productivity of team members. The jury is still out!