Page 101 -

72 PART TWO MANAGING SOFTWARE PROJECTS

4. The chosen technology changes.
5. Business needs change [or are ill-defined].
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost [or was never properly obtained].
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners] avoid best practices and lessons learned.

Jaded industry professionals often refer to the 90–90 rule when discussing partic-
ularly difficult software projects: The first 90 percent of a system absorbs 90 percent
of the allotted effort and time. The last 10 percent takes the other 90 percent of the
allotted effort and time [ZAH94]. The seeds that lead to the 90–90 rule are contained
in the signs noted in the preceeding list.
But enough negativity! How does a manager act to avoid the problems just noted?
Reel [REE99] suggests a five-part commonsense approach to software projects:
1. Start on the right foot. This is accomplished by working hard (very hard)
to understand the problem that is to be solved and then setting realistic
objects and expectations for everyone who will be involved in the project. It
is reinforced by building the right team (Section 3.2.3) and giving the team
the autonomy, authority, and technology needed to do the job.
WebRef 2. Maintain momentum. Many projects get off to a good start and then
slowly disintegrate. To maintain momentum, the project manager must pro-
A broad array of resources
that can help both vide incentives to keep turnover of personnel to an absolute minimum, the
neophyte and experienced team should emphasize quality in every task it performs, and senior manage-
project managers can be 7
found at ment should do everything possible to stay out of the team’s way.
www.pmi.org, 3. Track progress. For a software project, progress is tracked as work prod-
www.4pm.com, and
www.projectmanage ucts (e.g., specifications, source code, sets of test cases) are produced and
ment.com approved (using formal technical reviews) as part of a quality assurance
activity. In addition, software process and project measures (Chapter 4) can
be collected and used to assess progress against averages developed for the
software development organization.
4. Make smart decisions. In essence, the decisions of the project manager
and the software team should be to “keep it simple.” Whenever possible,
decide to use commercial off-the-shelf software or existing software compo-
nents, decide to avoid custom interfaces when standard approaches are

7 The implication of this statement is that bureacracy is reduced to a minimum, extraneous meet-
ings are eliminated, and dogmatic adherence to process and project rules is eliminated. The team
should be allowed to do its thing.