Page 102 -

team fails to take a stakeholder’s needs into account and fails to build a needed feature
into the software. Waiting until after the software is built to discover these problems
results in an enormous amount of work to fix defects that should have been caught before
a single line of code was written.
Problems Are Found Too Late
There are many problems that can be avoided by having the team adopt vision and scope
documents, project plans, software requirements specifications, and other project docu-
ments. But what happens when the team doesn’t catch an error in one of these docu-
ments until the software is built?

One of the most common causes of project failure is that requirements contain a defect
that is not caught until much later in the project. Trying to fix that defect after the soft-
ware is built can be so costly that it can destroy the project entirely. For example, suppose
that a team member writes a use case document to describe a critical feature. The docu-
ment is emailed around to the team, and everyone reads it. However, some of the readers
are very busy, so they only skim it and see that it looks about right. Others see problems,
but don’t want to embarrass the author by bringing them up. A few think that they found
very obscure problems and don’t want to embarrass the other readers who they think
would not have come up with the problem.
Some teams try to find defects by mailing documents around to the team, with no real
expectations of what the team is supposed to do with each document. After the author
mails the document out, usually nobody responds to the email for a few days. Responses
trickle in over the course of the following week. Some of them point out serious flaws, but
most of them do little more than point out typos and minor wording changes. In the
meantime, the designers start their work to avoid sitting around doing nothing. Eventu-
ally the user interface, architecture, and software are built. The product is passed down to
the QA team, who start testing the build. They haven’t been a part of the development of
the software at all, and have only been talking to the users and stakeholders, putting
together a test plan to ensure that the software does everything that they expect it to.
Within a few days, the QA team discovers a problem: there is a feature that does not work
the way the users need it to work.

When this happens, the entire project team is brought together in a meeting, and a split
quickly forms. The QA lead and stakeholder insist that the software is broken. The
requirements analyst, design lead, and programming lead insist that there is nothing
wrong. They finally start going through the documents and find that the software does,
indeed, meet all of the requirements laid out in the relevant use case. But the use case is
wrong—it does not describe what the users need the software to do. It’s clear to everyone
present that fixing the problem will be a major endeavor, and that the project will be
delayed for a very long time. The team built software that was solid, well-built, and func-
tional—but they built the wrong software.

94 CHAPTER FIVE