POOR CAPTURE AND MANAGEMENT of requirements are significant causes of angry customers, massive cost overruns, rework, missed opportunities, embarrassment, and other project frustrations.
Many projects are handed requirements in forms that include verbal instructions, sketches on a napkin, or contract specifications: “Get to work! It's a simple solution, and you can do it. We don't have much time! The customer doesn't know what he needs, but he'll 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 project's 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.
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 organization's 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
Requirements capture is both a personal and an organizational discipline. Three important factors that characterize good requirements-capture work are (1) the practices of defining key terms, (2) orienting on customer value, and (3) striving for technology independence.
Reader Service Number 029
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.
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 language—more specifically, how people's 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 different 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 don't 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. (For more on this topic, see “Financial Models, Right Questions, Good Decisions,” PM Network, July 1998.)
Reader Service Number 101
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 don't 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 project's 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 today's 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 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. Don't 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. ■
A good example of value-oriented requirements is the project team for a data-warehousing 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 team was able to maintain support because the team assured that the project's 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 industry. 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 in terms of success and failure. As analytical techniques, both strategy and requirements are processes that discover opportunities to add value.
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.
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, they're no longer real, they're 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 it's 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. Mencken's 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, 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 customer's 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.
Here's 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 departments for IS services. The department's 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:
■ Unambiguous—There is only one interpretation of the requirements specification.
■ Complete—The requirements specification covers all relevant aspects of the problem.
Reader Service Number 043
■ Not complex—For a person familiar with this type of problem, the requirements specification is simple and relatively easy to understand.
■ Stable—The requirements specification is not likely to change.
■ Traceable—The 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 designer's 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.
Reusing Requirements: Project Knowledge Management Capability
Knowledge is a resource, and a requirement is a form of organizational knowledge that projects can capture, reuse, and leverage. Effective project managers are resourceful and look for intelligent ways to reuse what can be reused.
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 elements 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
