Project managers realize that no matter how well projects are managed, projects still fail when customer requirements are not clearly defined and customer expectations are not met. However, common pitfalls often prevent us from gathering complete requirements because:
- Defining requirements takes more time than we or our key stakeholders seem to have
- We often accept solutions provided by sponsors, business clients, and technical stakeholders, rather than recommending the right solution for the organization
- We accept the stated requirements, assuming that these requirements will meet expectations
- Not all project managers are skilled at asking the right questions and analyzing alternatives, which are needed in order to recommend the right solution
- Some project managers, intimidated by technical jargon, accept technical solutions, even when it is not the right thing for the business organization.
Uncovering expectations takes time and requires the art of consultative questioning. It demands patience with clients who have difficulty articulating their requirements. It requires a process for not only eliciting the requirements, but also for analyzing, documenting, and validating them. Finally, it requires understanding of and a commitment to defining requirements at a level of specificity and to a sufficient level of detail that they can be used to uncover expectations.
This paper discusses these common pitfalls and confusion, some of the associated risks, and how a consulting approach will help mitigate them.
Requirements and Expectations
According to the Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (2004, p. 111), the International Institute of Business Analysis’s Business Analysis Body of Knowledge (BABOK™) (v. 1.6, p. 9) and IEEE’s Standard 610 (1990), a requirement defines a condition or capability needed to solve a problem or achieve an objective that must be met by a system or system component to satisfy a contract, standard, or specification.
Requirements, then, state a business need and describe how the solution, or final product, will meet that need. Requirements tend to be high-level in the beginning of a project and become more detailed as the project evolves. The PMBOK® Guide describes the process of “progressively elaborating” requirements (p. 111). In other words, features and functions of the product are fleshed out as more is known. Detailed requirements describe such things as what the end user of the product needs to know or do or have, and how they need to use the product.
It is helpful to think of requirements as being stated, that is, spoken and/or documented. Expectations, on the other hand, while they are also requirements, are not usually articulated by the sponsor and client stakeholders. We need to meet both expectations and stated requirements in order to satisfy the business need. When we ignore expectations, even if we have been meticulous in documenting stated requirements, we are apt to develop unusable products.
Common Pitfalls
The Time Trap
One of the challenges cited frequently in our informal research is what we call the Time Trap. There are two parts to the time trap. The first is that project managers and business analysts do not always feel that they are given enough time to define requirements, let alone uncover expectations. Tight deadlines shorten the time for requirements elicitation, making both planning and managing requirements a formidable challenge.
The second is that clients are not always available to define their requirements. The project manager, usually under pressure to deliver quickly, hears from the key clients that they do not have time to attend requirements workshops. Project managers are left with undesirable alternatives. They can postpone the meetings and delay the project, they can hold the workshops without the clients, or they can proceed with incomplete requirements. Each one of these alternatives has the associated risk of incomplete requirements, surprises, rework, and expense.
Stated Requirements Don’t Meet Expectations
Another pitfall is assuming that the requirements stated by the sponsor and clients will produce a product that actually works and will be used. In other words, we assume that if we get the sponsor and clients to articulate their requirements, the product will meet their expectations. Effective house architects know that potential homeowners cannot always understand impacts of their stated needs, so they have learned to use consultative questioning to determine homeowners’ real requirements. Similarly, project managers and business analysts know that having sponsors state their requirements is only the beginning of the process. If they collect the requirements as given without a consultative approach, it is highly unlikely that the end product will meet expectations.
Ineffective Questioning
One reason that the stated requirements may not meet customer expectations is that ineffective techniques are used to ask questions about the requirements. Project managers and business analysts need to master the art of asking questions. Asking questions like “What are your requirements for this project?” is not apt to yield successful results.
Asking the wrong questions, even with good intentions, can lead to unwanted results. The three categories we’ll discuss are:
- Open- vs. closed-ended questions
- Solution presentation
- Feature fallacy.
Some project managers and business analysts erroneously think it best to always ask questions that allow the interviewee to expand their thoughts, avoiding what are called closed-ended questions. Asking these expansion questions exclusively can be time-consuming and can make the elicitation process longer than needed.
Solution presentation occurs when project managers fall into the trap of presenting solutions that sound like questions. Sometimes known as leading questions, these closed-ended questions often force the interviewee into a position of disagreeing with the interviewer, or worse yet, feeling foolish. Therefore, avoiding leading questions, such as “Wouldn’t it be better to …” or “Have you ever thought about …” reduces the risk of creating barriers to communication.
Feature fallacy occurs when either the interviewer or the interviewee focuses on the features and functions of the product before determining how the product fits into the context of both the business and the project. It is a pitfall that occurs across disciplines. As an example, software engineers and vendors sometimes concentrate on desirable features, rather than determining whether the software will solve real business problems or the impact of the software on the organization.
Alan Cooper addresses this concern in his book, The Inmates are Running the Asylum (1999). Cooper discusses the pitfalls of having engineers focus on product features, rather than usability or organizational viability.
Most of us know that it is not uncommon for salespeople to emphasize features when selling products to consumers. Whether we’re buying a new house, car, or dishwasher, we often hear about the features. How often do salespeople ask how we’re going to use the house or car? Assumptions are made, which can lead to customer dissatisfaction.
In a recent article, James Surowiecki discusses the issues related to what he calls “feature creep” (Surowiecki, 2007, p. 28). Citing statistics for consumer returns on defective but difficult-to-use products, Surowiecki shows how many non-defective items are returned annually. He goes on to say that the issue is not just with product designers and salespeople. He cites statistics from a recent study showing that 60% of those participating in a focus group picked products with more features. However, when asked to use the product, they became frustrated as “feature fatigue” took over.
Another pitfall is asking the right questions the wrong way, which can destroy trust and create barriers between interviewer and interviewee. If we are to elicit good requirements, we need to put the interviewee at ease. We need to build trust with our stakeholders, and asking questions in a way that does not facilitate communication, even if they are very good questions, can produce unintentional negative results. Here are three sins that can destroy trust:
- Asking “why” accusingly. Sometimes the interviewer can give the impression of being a prosecuting attorney. Asking “why” directly can put some people on the defensive and should be avoided.
- Showing lack of interest. There are many ways to show that the interviewer is not engaged. Checking cell phones is an obvious one. Less so are neutral non-verbals, such as lack of eye contact, slouching, and so forth, which, while not actively presenting communications barriers, can inhibit the conversation.
- Using inappropriate non-verbals, given the culture of the interviewer. How we show that we are engaged in the conversation differs from culture to culture. While showing engagement in some cultures seems obvious (good eye contact, nodding the head in agreement, leaning in to the conversation), it is not accepted in others. Making assumptions that everyone responds similarly to engagement signals can lead to barriers and distrust.
Using the Wrong Techniques
Even experienced project managers and business analysts are guilty of using the same techniques over and over, even when the techniques are not appropriate for the project at hand. For example, using business process modeling for a reporting function may not get at the true requirements. Using the same or inappropriate techniques can result in clients answering the wrong questions, thereby providing incomplete or incorrect requirements. Using the wrong techniques can result in the project manager being surprised when the sponsor, at the end of the project, says, “Yes, I know that’s what I said I want. But it’s not what I really need!” Business modeling, discussed below, provides structure for asking questions to get at hidden requirements.
Accepting Solutions Presented by the Business and Technical Experts
A third pitfall is accepting a business solution provided by the sponsor and other key stakeholders. Although not a good practice, it is common for these business stakeholders to try to save time by giving specific product details (for example, fields on a report or more technical features of a product) without providing the business reasons. When questioned, the sponsor emphasizes the importance of getting the project done “on time.” Accepting solutions presented by business stakeholders forces project managers into the role of order takers, which usually leads to unusable and unused products.
In conjunction with the above, project managers often feel constrained by an imposed technical solution, which can force the business needs to be subjugated to the technical architecture, rather than having the technical architecture support the business need. These types of technical constraints, when they force a business solution without taking the existing business processes or business needs into account, invariably lead to customer disappointment.
Using Consulting Skills to Overcome Requirements Pitfalls
Overcoming pitfalls described above requires a consultative approach. Being a consultant to the business helps ensure that expectations are met. By understanding the business problem, analyzing the current situation, understanding the limitations, gathering supporting statistics detailing exactly how bad the problem with the current situation is, the project manager is in an excellent position to recommend a solution that will solve the business problem at hand. If the recommendation is accepted, the project manager can recommend the most effective implementation approach, given such factors as the organization’s attitude toward change, how eager key stakeholders are for the change, how engaged the sponsor of the change is, and so forth. Effective consultants have learned that the key to success includes:
- Asking questions to uncover problems and synthesizing the responses
- Analyzing those problems
- Advising clients by recommending solutions.
Asking Question that Uncover Problems and Synthesizing the Responses
Asking the Right Questions
Regardless of the project, asking questions that are too generic is not likely to result in clarifying expectations. Untrained project managers may sit with business stakeholders and ask them what their requirements are, but these stakeholders are apt to state the obvious requirements rather than uncovering hidden expectations. However, asking the right questions can be challenging, because not all project managers and business analysts have the industry and product knowledge needed to ask pertinent questions. Without the right context, good questions will probably not surface. Being a consultant requires asking questions to obtain the right context, before trying to understand the details of the end product. Once we have the context, we can ask questions related to our product. At that point, for example, if we are building software, our questions need to relate to process and data. If we are developing a new product offering in the retail environment, for example, we need to understand the markets, pricing, merchandising, and so forth. Importantly, in both cases, we need to ask questions about how the new product will be used and its impact on the organization.
A few good consultative questions to ask, regardless of the product or service of the project, always include the business context with such questions as:
- What business problems are being solved with the project?
- What opportunities is the organization taking advantage of?
- What are the external threats that this project addresses?
- How does the project take advantage of the organization’s strengths or compensate for its weaknesses?
- What is the product description and project vision?
- How does this project link to the organization’s strategic direction?
- How will this product be perceived in this organization?
A few good questions getting at the project context can include such things as:
- How much are you willing to spend on this project?
- What is the priority of this project in relation to the other projects in this portfolio/program/organization/division?
- What are your time constraints and what causes them?
- What risks do you see with this project?
- Who/who else should we talk to?
- Who are the subject matter experts and what experience do they have?
- If you had to choose among time and cost, scope, and quality, which is the most important to you? The least?
A few good questions getting at the high-level product requirements can include such things as:
- To what extent will this new product cause business processes to change? Which ones will change and in what way?
- What do people need to know in order to use this product?
- How will internal and external customers use the product
- How will the product be sold? Maintained? Supported?
- What impacts to other areas are you aware of?
- How stable are the product requirements?
- Tell me about the best/worst product feature you’ve encountered? Easiest/hardest product to use that you’ve had to use?
Exhibit 1 shows a tip for uncovering needs.
Exhibit 1 – Question Tip
Synthesizing Responses
Synthesizing responses involves using well-honed active listening skills to take a great deal of disparate information and organize it in a way that is useful to the appropriate stakeholders. Active listening involves ensuring that what is said by the speaker is actually heard correctly and completely by the listener. The listener, to ensure that the information from the speaker has been received completely and correctly, needs to ask clarifying questions and paraphrase what is thought to be heard. The speaker has confidence, based on questions asked by the listener, that there are no assumptions or misconceptions on the part of the listener.
Active listening is difficult enough in a one-on-one setting, but even more difficult if the listener is also facilitating a requirements workshop. Having a scribe who is separate from the facilitator is usually helpful. This scribe has to be knowledgeable about the business and the task at hand, because, they, too, will need to synthesize a great deal of information. Having both the facilitator and scribe actively listen and synthesize helps ensure that hidden expectations surface, as they provide a cross-check for each other. Active listening is not easy. Although we know the “rules,” it can be difficult to put into practice. Other priorities and distractions can prevent us from being fully engaged.
To effectively synthesize information, critical thinking skills are required, which requires the ability to process large amounts of information. Similar past experience can be useful, but care should be taken to avoid making assumptions based on past project experiences. Critical thinking also requires the ability to organize, discriminate, and discern disparate pieces of information, putting them together in concise and useful ways. Finally, it requires the ability to distinguish between what’s important from what is not, and discarding the unimportant. Experience is invaluable in making this determination. In addition, the use of analysis tools can prove extremely helpful. For example, Pareto analysis is a helpful technique for determining the major factors causing a business problem. It uncovers the critical 20% of causes that lead to 80% of the results.
Traceability and Creating Structure from Chaos
A useful tool in synthesizing a large amount of information is the traceability matrix, which is a table for recording requirements. The structure of this table is hierarchical, so that high-level requirements can be documented in the beginning of the project and details can be added as more is learned. In addition, requirements attributes—such as a unique identifier, textual description, requirements source, rationale, priority, and many more—can help categorize requirements as they surface.
Although there are many techniques for creating structure from chaos, traceability provides the most effective way to organize large amounts of disparate pieces of information, ultimately helping to ensure that every requirement adds value, that what was approved is actually implemented, and that changes are controlled. It does so by providing a structure that allows requirements to be linked to business and project objectives, business problems, and deliverables. Traceability also helps ensure that the product can be built, tested and verified after implementation. Finally, logical groupings of the table help manage changes more easily.
Exhibit 2 shows a tip for creating structure from chaos.
Exhibit 2 – Traceability Tip
Analyzing Problems
Once we have asked business, project, and product context questions, we should have an understanding of the business problem we’re trying to solve, as well as an idea of the project’s product or service that will result from successfully implementing the project. Before we can recommend a solution, however, we must analyze the problem, which requires the ability to break the large problem into smaller pieces and to get to its root cause.
Using Models and Prototypes to Analyze Problems and Verify Expectations
To understand the business problem, we need to understand the current situation and the limitations of the current situation. Models present a clear way to learn about and document the situation, known as the current state or “as-is.” Once we understand what is happening today, we can analyze how to improve the situation and recommend a better approach. Modeling provides the structure to ask the right questions at the right time during the project. We call those “question points” and they are valuable because the modeling technique prompts them. By graphically displaying the issues, we can more easily see the “gaps” between what is happening today and what is needed in the future. Models, then, provide a basis for solid recommendations.
Modeling also provides the means to ask questions that might well be forgotten, since the models’ structure forces thoroughness in questioning. Modeling also provides a way for business analysts to translate their interpretation of the requirements to both the business clients and the technical team.
There are a variety of models that can be used during the capturing of requirements. Below is an example of the kinds of models used in software development. Some of these, such as business process models and prototypes, are useful in any project where the output is a tangible product, such as a new car, service, or process.
Exhibit 3 shows a table for requirements models used in software development.
Exhibit 3 – Requirements Model Usage
Advising Clients by Recommending Solutions
The Recommendation
In addition to the more obvious recommendation structure (summary, body, attachments), the recommendation should carry the right tone for the intended audience. The tone can be formal or informal, folksy or precise, direct or subtle. What is important in tone is that it will not distract its intended audience. Having the wrong tone and level of formality can distract the audience, break trust, and ultimately lead to the rejection of the recommendation and loss in credibility of the author.
In addition, the recommendation should include input from those who will be affected by its implementation, which means that the recommendation has a far greater chance of acceptance if it is reviewed by key stakeholders and if their input is included in the final draft. The more stakeholder input is sought, the more likely that supporters will defend it against saboteurs. Ideally, these stakeholder champions will also participate in presenting the recommendation, which will provide credibility to the recommendation.
Presenting the Recommendation
Presenting the recommendation can be done formally or informally, in written or verbal format. No matter which format or venue is chosen, the structure of the presentation is important. Having a summary and details, for example, works whether the recommendation is written and presented formally, or verbal and presented informally. Even the most informal setting requires giving a great deal of thought to planning the presentation approach, including such things as choosing the right venue, how much in advance of the meeting to distribute it, roles and responsibilities during the presentation, the agenda, ground rules, when to take questions, and more.
Finally, the consulting approach requires presenting a recommendation that best serves the organization, even if the recommended solution differs from what was initially presented by the stakeholders. Those listening to the recommendation do not need to be completely in support of the proposal, but they will more likely accept it if the project manager is thoroughly prepared and the recommendation crafted with care. That means ensuring that the recommendation addresses the business need that was identified and analyzed, that the recommended solution addresses that need, and that impacts of the solution to all areas in the organization have been taken into account. Remember, project managers do not need to make the decision to accept the recommendation. That’s for the sponsor and executives. However, project managers do have an obligation to be consultants to the business by having a clear understanding of the problem, and developing a thorough recommendation for a solution that’s the right thing for the organization.
In addition to your main recommendation, be prepared with alternatives and some analysis of why they were not your proposal.
Exhibit 4 shows a tip for presenting the recommendation.
Exhibit 4 – Sales Tip
