(^8) 97 Things Every Project Manager Should Know
Make Project Sponsors Write Their Own Requirements
Miyoko Takeya, PMP
Tokyo, Japan
PRojECT FAIlURE IS noT jUST A PRoBlEM with American corporations.
According to a survey conducted several years ago by one of Japan’s leading
information technology magazines, more than 75% of the projects that are
undertaken by Japanese corporations are considered a failure when measured
against the metrics of quality, cost, and delivery.
In Japan, as in most other nations, the top reason for failure in each metric is
almost always the same: poor requirements definition. The companies that are
most at risk are those with poor business analysis capabilities. When specifically
reporting on technology projects, such as software development, success is cat-
egorized, euphemistically, as “improbable.” This result shows how difficult it is to
find, identify, and define true requirements for a software project.
Since it is so hard to do, many project owners—such as customers, project
sponsors, or company executives—expect the project manager to define and
refine the requirements for the software on her own. They do not provide
much in the way of guidance or a clear definition of what they need. Since it is
a software project, and they may not understand software development them-
selves, they assume that they don’t have to define what they expect.
The software project manager usually does not have the authority or the time
to find, select, and prioritize the project requirements on her own—especially
since there may be several interest groups involved in the project that prob-
ably have conflicting ideas about what they envision the software will do upon
completion.