PROJECT

In order to manage a successful software project, we must understand what can go
wrong (so that problems can be avoided) and how to do it right. In an excellent paper
on software projects, John Reel defines ten signs that indicate that an information
systems project is in jeopardy:
1. Software people don’t understand their customer’s needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.

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 particularly
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 . 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 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  and giving the team
the autonomy, authority, and technology needed to do the job.
2. Maintain momentum. Many projects get off to a good start and then
slowly disintegrate. To maintain momentum, the project manager must provide
incentives to keep turnover of personnel to an absolute minimum, the
team should emphasize quality in every task it performs, and senior management
should do everything possible to stay out of the team’s way.
3. Track progress. For a software project, progress is tracked as work products
(e.g., specifications, source code, sets of test cases) are produced and
approved (using formal technical reviews) as part of a quality assurance
activity. In addition, software process and project measures 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 components,
decide to avoid custom interfaces when standard approaches are available, decide to identify and then avoid obvious risks, and decide to allocate
more time than you think is needed to complex or risky tasks (you’ll
need every minute).
5. Conduct a postmortem analysis. Establish a consistent mechanism for
extracting lessons learned for each project. Evaluate the planned and actual
schedules, collect and analyze software project metrics, get feedback from
team members and customers, and record findings in written form.