Requirements, or

How do I know the Project is Done?

The PMI 2014 Pulse of the Profession Study found 37% of organizations blamed
inaccurate requirements as a primary reason for project failures. The PM
Solutions 2011 study, Strategies for Project Recovery found that requirements
issues were the # 1 reason for troubled projects. Looking at these and previous
studies, the trend is clear. The systemic problem of writing requirements that
result in successful project completion has not been resolved.
According to the Project Management Book of Knowledge (PMBOK) a
requirement is,
A condition or capability that must be met or possessed by a system,
product, services, result of component to satisfy a contract, standard,
specification or other formal imposed document. Requirements include the
quantified and documented needs, wants and expectations of the sponsor,
customer and other stakeholders.
Requirements should possess each of the following traits:
Unambiguous, measurable, testable, traceable, complete, consistent and
acceptable to stakeholders.
All requirements should be documented in the following reports:

Project charter
Stakeholder register
Requirements document
Requirements management plan
Requirements trace matrix.

Regardless of how well written the requirements, the project manager still has to
face these dilemmas:
Schedule, cost, people/technology/material resources limit what can
be done
Sponsor assumes what customers want

 Customers dont know what they want/need/how to use until they

try it
Sponsor/stakeholders dont know what technology can/cant do
Integration issues not identified
Communications
There are well-known root causes for poor requirements and failed projects. A
partial list includes the following:
Multiple groups involved in requirements process: user/customer,
marketers, business analysts, project manager, project workers
(programmers, builders, etc.), sponsors, stakeholders
Interpretation of the elephant (how does customer, stakeholder,
marketer, sponsor, developer see the product/service)
Communication failures
Failing to consider integration with existing products/services or
planned products/services
Changing requirements without consideration of impacts on the
project
Funding/schedule/resource constraints
Failing to manage change/requirements
Individually and collectively, the root causes will affect cost, schedule, risk,
resources, personnel, quality, production, support, training, sub-contracting,
marketing, and configuration control. All of these either individually, or a fatal
combination, can spell disaster for any project and project manager.
Knowing how to reduce the impact of poor requirements and how to manage
requirements during the project life cycle are key project manager knowledge and
required skills. Key to the entire requirements process is developing and
implementing the requirements management plan. (Note: a template is available
at Project Management.com as well as other sites/resources). The plan defines
how to address requirements during the project life cycle. The plan should
include: how requirements are planned, tracked, and reported, configuration
management, prioritization, metrics, and traceability.

A requirements traceability matrix (see example below) should include

traceability to:

Business needs, opportunities, goals, objectives

Scope/Work Breakdown Structure
Design
Product development
Test strategy
High to low requirements

Notional Requirements Matrix

Priority
Category 1
Category 2
based on wt Y/N Y/N Y/N
Y/N Y/N Y/N Y/N Y/N Y/N
Bus
needs scope/W Design Require
measurRequirement Weight Score Weight Score
trace BS trace trace ment dev trace test trace Unambig able complete consistent

Responsi
ble
Name

Common methods for requirements definition include:

Brainstorming
Expert analysis
Delphi techniques
Interviews
Mind mapping software tools (see Google search for list of products).

In summary, requirements definition is still much of an art. There are tools and
processes to help customers/sponsors/stakeholders/project teams make the
definition process more of a science. However, each project requires unique
methods and each project manager must keep the toolbox full with the latest
information to use in creating the best requirements for the project team.