Capturing

Project
Requirements
and
Knowledge
by Gregory D. Githens, PMP

Projects dont fail at the end;

they fail at the beginning.
Thinking strategically and
leveraging requirements
help you begin as well as
you hope to end.

of requirements are
significant causes of angry customers, massive cost
overruns, rework, missed opportunities, embarrassment,
and other project frustrations.
OOR CAPTURE AND MANAGEMENT

Many projects are handed requirements in forms that include verbal instructions, sketches on a napkin, or contract specifications: Get to work! Its
a simple solution, and you can do it. We dont have much time! The customer
doesnt know what he needs, but hell buy this solution. Scope creep. Recovery from inadequate project requirements is painful.
Good requirements management is hard work, but worth it. This article
gives you some insights on the basic elements of project requirements knowledge management and encourages you to think strategically and invest some
energy in the fuzzy front end of projects.

What is a Requirement?
Simply, a requirement is defined as capacity or capability that is needed for
describing the projects product, thus satisfying a set of customer purposes. A
specification is a formal notation of a requirement. In practice, I find that the
definition of a requirement is not common, nor easily agreed to. People struggle with the purposes and content of the needed information and ultimately
find their own practical and personal definition.
Greg Githens, PMP, of Catalyst Management Consulting, finds that project success or failure
is determined in the fuzzy front end of projects. Additional information on requirements
and knowledge management can be found at www.CatalystPM.com.
February 2000 PM Network 49

Three Examples of a Knowledge Tree

Problem elements affecting enterprise PM

system capabilities and capacities

Examples of deficiencies in
current performance

Stakeholders view of the organizational issues

related to enterprise project performance

Locations where work is performed

Repeated schedule slips

Project office desire for centralized

reporting and coordination

Systems

Idle resources not matched

with project opportunity

Executive view of enterprise

financial performance

Peoples knowledge

Budget overruns

Customer dissatisfaction with

communications

Human resource departments need

for forecast of skill needs for projects

Timetable for acquisitions

Exhibit 1. The three examples show the relationships among enterprise project management problem entities. One purpose of project requirements
management is developing and specifying a complete and valid model. This model becomes the input to product scope management processes.

Requirements Knowledge Structures

The purpose of project requirements management is to build a valid knowledge
structure that communicates the essential
characteristics of the problem as input to
project design and implementation. A
knowledge structure is a logically organized

arrangement of facts, principles, and other

pertinent information. Valid means it is a
correct representation of the situation. Essential characteristics means that the most
important aspects of the problem are recognized, prioritized, and communicated.
The characteristics valid and essential

mean that the knowledge structure is both

accurate and complete.
I will illustrate a requirements knowledge structure (or tree, in this case) with an
example from enterprise project management, which are decision-support software
products intended to integrate project management procedures in the organization.
Capturing decision-support systems requirements is difficult because the technical solution will affect many other systems,
and structures, as well as the organizations
culture.
Exhibit 1 presents three truncated requirements knowledge trees describing an
enterprise project management system. The
first tree describes the parts or elements of
a problem; the second provides examples
of problems and functionality that an enterprise project management system might
be expected to include; and the third lists
perspectives of the stakeholders who would
have needs in operating an enterprise project management system or consuming its
output information.

Factors to Consider in
Capturing Requirements

Reader Service Number 029

50 PM Network February 2000

Requirements capture is both a personal

and an organizational discipline. Three important factors that characterize good

Four Concurrent Project Management Processes

Requirements
Elicitation

Current
Knowledge

Domain
Understanding
Requirements
Validation

Valid
Requirements
Specification

Agreement

Yes
Requirements
Specification

The processes repeat

To other project-oriented
and product-oriented
processes

Exhibit 2. The four requirements management processes are concurrent. Requirements are progressively elaborated and produce a succession of models
that describe the problem. The processes repeat themselves and are inputs to project- and product-scope processes.
requirements-capture work are (1) the practices of defining key terms, (2) orienting on
customer value, and (3) striving for technology independence.
Key Terms. Requirements specifications
are a form of language we use to describe
customer constraints and preferences. Abstract concepts are common, so always
clarify key terms and strive for common
language.
Semantics is the study of meaning in languagemore specifically, how peoples
thoughts are translated into utterances. Understanding word meanings is the single
most important part of requirements work;
thus semantics is relevant and practical.
Meaning in words derives from content (the
dictionary definition of the word) and context (application of the word in a particular
situation).
For example, the word acquisitions in Exhibit 1 can mean new investment in technology, people, capital, or organizational
mergers and takeovers. Thus, acquisitions is
ambiguous in this context and suggests the
need to modify the knowledge tree by making the statement more definitive.
Another semantical concern for capturing requirements is that they operate at multiple levels of abstraction. A requirement for
decision-support systems for a CEO is dif-

ferent from a requirement for a software

programmer. However, both are relevant for
problem solving and delivering a useful
project solution.
I often hear project participants say,
Customers dont know what they need.
Here is a commonsense rule: Customers
buy what they want, not always what they
need. The process of educating your customers is a process of getting them to want
what they need. When there is agreement
between the customer and the project on
the need, you have a requirement. Your objective is to satisfy agreed-upon requirements, which reflect wants and needs. It is
the secret to managing expectations creep.
Orient to Customer Value. Requirements
originate with customer wants and needs
and evolve into a product vision, and, eventually, into a delivered outcome or capability for the owner. A baseline of requirements helps the project define and measure
product success or failure.
Customer value is a component of prioritizing requirements. For example, most
organizations have numerous performance metrics, and usually at least one financial criterion as a hurdle. Your job in
managing requirements should include
knowing the long-term and short-term performance implications of the project.

Reader Service Number 101

February 2000 PM Network 53

Capturing and Specifying Project Requirements and Avoiding Scope Creep

I define scope creep as adding features and functionality to the
product that were not part of the original project contract, without commensurate increases in time or cost. The best way to
avoid scope creep is by using good requirements management.
There is an old saying, Any fool can add; it takes a genius to
subtract. You can banish scope creep by understanding knowledge structures, applying the four requirements management
processes, and using the following techniques.
Prepare. In preparing, construct a two-column table to identify
what you know and dont know. Use your experience in other relevant areas (past analyses and history) to help the customer understand the nature of the problem and the range of potential solutions.
Basic activities include preparing a list of meeting outcomes
and clarifying participants objectives, time duration, and other
expectations before doing the work of elicitation.
Use a Written Problem Statement as a Touchstone. The question, When does a project start? is not trivial. We need to keep
a focus on outcomes. So, develop a concise problem statement,
and apply these simple techniques to assure validity: restate the
problem with different words, turn it 180 degrees, and ask
Why? repeatedly to get to the root of the problem.
Recognize and Manage Bias. All communications are biased,
so understand the biases inherent in each projects requirements. Examples of bias include social pressure from the interviewer (people tell the analyst what they think the analyst wants
to hear), groupthink, impression management, wishful thinking,
anchoring, availability of data, and overconfidence.
Use Blitzing Tactics to Capture Project Requirements. The
cross-functional perspectives of the project team are important
in identifying the correct, complete, and valued requirements.
Workshops like joint requirements planning are good techniques but need to be facilitated well. If you cannot get what
you need in a few intense days of work, you probably will only
wear out the project team and build resistance. In todays hectic
environment, people tire of one more round of planning.
Requirements capture is a communication process best practiced with dialogue and discovery of emergent and latent needs,
not extraction via interrogation. An interview is not a contest.
Entry and Contracting. A relationship of mutual openness,
trust, and honesty is a prerequisite to discussing organizational
problems and opportunities. In the entry process, the development team members lay the groundwork for trust, get to know
(For more on this topic, see Financial
Models, Right Questions, Good Decisions,
PM Network, July 1998.)
A good example of value-oriented requirements is the project team for a datawarehousing project in a telecommunications company. The team spent nearly a
year developing and communicating the
value proposition and business case. The
project faced many political threats, but the

the customer and each other, and establish the desire for a collaborative working relationship.
It is always safer to start the interactions with basic introductions and purposes for collecting and using the information. Always discuss the issues of confidentiality, no matter how well
you know the interviewee.
In my experience, the best requirements emerge by acknowledging the two-way nature of communication and the notion
that a requirement is an agreement. It builds buy-in and avoids a
passive attitude.
Use Open and Closed Probes. Use open-ended questions that
begin with the words how, what, why, when, where, or who, although tell me about can also get you the same information.
Record this information. You will frequently run into information
that might seem irrelevant. Dont discard it; capture it in an
idea parking lot.
Develop skill in asking questions. Technical professionals
can learn from their sales and marketing colleagues.
As the discussion proceeds, ask clarifying questions to be
sure that you understand the extent and bounds of the problem.
Use close-ended questions (yes or no) to confirm your understanding.
Avoid the Checklist Mentality. It is natural to want some structure for elicitation and appropriate to use checklists in gathering
requirements. However, beware of the checklist mentality, which
I define as a thoughtless reliance on checklists, where ticking off
a box becomes more important than critical thinking.
Use Prose, Diagrams, and Physical Prototypes. The output of
requirements elicitation is a model of the problem and solution.
There are many ways to specify requirements. Using different
formats can help eliminate ambiguity.
Watch out for pitfalls such as vague and ambiguous language. When using prose, try to structure each requirement
specification into a short statement using the word shall.
Prioritize and Establish Boundaries. You should analyze each
requirement for desirability, which is the difference between
must have and nice to have. Prioritize requirements by ranking each need from most important to least important. `

team was able to maintain support because

the team assured that the projects value
proposition was understood and remembered by executives.
What can happen when the value is not
recognized? Consider the project team that
developed an attractive requirements document, which described the existing system,
but not the new capacity that the organization needed to compete in a turbulent in-

dustry. After substantial expenditures, the

project was canceled, to the regret and relief
of the project team.
Requirements capture and management
requires the same developmental and communication skills as business strategy. Both
requirements and strategy have elements of
sensing and responding to threats and opportunities, depend upon specialized language and processes, and are measurable

February 2000 PM Network 55

Five Elements of a Project Requirements Knowledge System

Process
Four recognized requirements processes
Common lexicon
Consistently applied for repeatable outcomes

Framework for Enterprise

Strategic Management
Functional strategies
Project strategies
Integration
Balance of customer
and technology

Culture and Leadership

Patience with learning
Urgency for action

Information Technology Infrastructure

Building blocks and tools
IT investments in data repositories

People
People discipline, including abstract reasoning and
critical thinking skills
Competency
Skilled in using and improving the system
Interpersonal skills

Exhibit 3. Process alone will not assure capability for project requirements knowledge management. Effective knowledge management leverages the
elements of people, process culture, leadership, and IT infrastructure.
in terms of success and failure. As analytical techniques, both strategy and requirements are processes that discover opportunities to add value.
Strive for Technology-Independent Statements. A good project will avoid prematurely constraining designs. Of course, premature is a judgment call, but most of us
can think of instances when a project deployed a solution before the problem was
understood. You want to allow designers
freedom to select the appropriate technologies and optimize a solution for the
customer.
A common pitfall in requirements specifications is to initially describe the problem
in terms of features or technologies. When
problem statements are technology constrained, they presume that the customer
understands the root cause of the problem,
has surveyed alternative modes, and has developed an optimal solution. Often, people
satisfice, defined as picking the first acceptable solution to a perceived need, instead
of the optimal solution. (Economist Herbert
Simon coined the word by merging the
words satisfy and suffice.) Projects often

need to rework or continuously improve

upon these satisficed solutions.
Enterprise project management (EPM)
software has been the subject of much satisficing. I have spoken with a number of
EPM software vendors who are frustrated by
customers inability to articulate requirements. Because of this, vendors resort to
selling the advantages of the features of one
product over the features of another product. Buyers become overwhelmed by cool
features and soon forget about the needs of
the business. You can avoid this type of confusion in any requirements management
work by striving to keep your requirements
specifications technology independent, especially in the early stages of the project.

Requirements are Like Butterflies

There is a saying: Requirements are like
butterflies; once you pin them down,
theyre no longer real, theyre dead! In striving to represent real-world problems in our
requirements specifications, we try to capture all the relevant detail and organize it,
but find it difficult to describe intangible
characteristics.

Exhibit 1 is fairly simple, but its not complete. Simple models are best at communicating, but they lack the detail needed for a
realistic assessment of the problem. The tree
can branch to the level of detail that you desire. The goal is to develop a knowledge
structure that is complete and accurate, but
not so overwhelmingly detailed and trivial as
to intimidate and confuse. With experience,
you will develop the judgment to determine
when to stop analysis and proceed to design.
Simplicity versus realism is a dilemma,
and I always recall H.L. Menckens thought:
For every complex problem, there is an answer that is short, simple, and wrong. Simple
requirements specifications make communication easy, but are often imprecise and incomplete. Complex requirements are more
realistic, but often contain overwhelming detail and errors that are difficult to detect.

Project Requirements Management

Processes
Well-managed projects develop knowledge
structures and models through four processes
of project requirements management: problem understanding, requirements elicitation,

February 2000 PM Network 57

requirements specification, and requirements

validation. Problem understanding is primarily an intellectual process, and the other three
are communications processes. Exhibit 2
illustrates that the processes are concurrent
and iterative.
The problem-understanding process
models the customers problem and desired
future state. Most organizational problems

are tangled, and the project must make

judgments on which problems to solve and
which to exclude. Take care not to define
the boundaries of the problem either too
narrowly or too broadly.
Heres an example of a too-narrow focus
in the problem statement: The IS department of a manufacturer defined the problem as collecting data to charge back user

Reader Service Number 043

58 PM Network February 2000

departments for IS services. The departments practice was to accept any reasonable project request, because the IS department was measured on utilization of
resources. Unfortunately, the department
maximized utilization by accepting numerous small projects. The result was a clogged
development pipeline, with the attendant
symptoms of burned-out staff and dissatisfied customers. The root problem in this
case included (at least) a lack of strategy for
project portfolio management, which was
perceived as too abstract and grandiose a
mission for the IS department.
Requirements elicitation is a process of
gaining customer and developer knowledge
relevant to the problem and the solution
space. Requirements elicitation produces a
succession of individual and team mental
models of the problem domain. These models become clearer as knowledge increases.
Requirements models help the development team understand the needed capacity
of the customer. A good practice is early
and continuing involvement of the customer in the planning process.
Scope creep is a common and often
painful project problem. The sidebar describes some techniques of requirements
elicitation that can help banish scope creep
from your project.
The purpose of the requirements specification process is to produce a formal notation of the requirements. Developers can
use the specification input for design. Requirements specifications documents serve
as agreements between the team and the
customer on what constitutes the problem.
Project specifications documents should
include an adjective, such as requirements
specification or design specification, to describe clearly what is being defined. This
will help avoid the confusion that many
people have when they believe that
specifications are some type of technical
language understood only by the
technocrat.
The purpose of the requirements validation process is to assure that the requirements model is consistent with customers
and users intentions; thus, it is an accurate
representation of the situation. For requirements specifications, there are five important parameters:
` UnambiguousThere is only one interpretation of the requirements specification.

` CompleteThe requirements specification

covers all relevant aspects of the problem.
` Not complexFor a person familiar with
this type of problem, the requirements specification is simple and relatively easy to
understand.
` StableThe requirements specification
is not likely to change.
` TraceableThe requirements specification shows a feature or action link to a problem statement.
A requirement is a concept, and a specification is the formal notation of a concept.
The more valid and complete the requirements specification, the better the designers ability to develop the right product.
The project is the work, but the work is design. It is yin and yang: you cannot have a
project without a product, and vice versa.

age. Effective project managers are resourceful and look for intelligent ways to
reuse what can be reused.

Reusing Requirements: Project Knowledge

Management Capability

There is considerable potential for

creating competitive advantage in project
development by treating requirements
knowledge management as a core competency. Exhibit 3 illustrates the five ele-

Knowledge is a resource, and a requirement is a form of organizational knowledge

that projects can capture, reuse, and lever-

Your job in managing

requirements should
include knowing the longterm and short-term
performance implications of
the project.

ments of an organizational capability for

requirements knowledge management. A
number of automated tools are available
that help in capturing and tracing the specifications, but a holistic approach is fundamental to developing capability for improved performance. Harnessing all five
elements is essential to fast and effective
development.
HASTE IN EVERY BUSINESS brings failures,
wrote Greek historian Herodotus over 25
centuries ago. Herodotus words are still
relevant for project requirements. In rushing to produce tangible results, project participants often shortcut the crucial project
requirements work. There is never time to
do it right! (But always time to do it over.)
Excellent project teams develop an early
and structured focus on requirements and
emphasize customer value. Mediocre project teams avoid the messiness and ambiguity of requirements capture, ignore customer expectations, and focus on technical
activities. `

Reader Service Number 102

February 2000 PM Network 59

This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI.