“Oh No, You Gave Me What I Asked For!”

Part 1: Common Pitfalls to Uncovering Expectations

Project professionals – specifically project managers and business analysts – realize that no matter how well projects are executed, projects still fail when customer requirements are not clearly defined and customer expectations are not met.

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, uncovering expectations takes a commitment to defining requirements in sufficient detail to understand what those expectations truly are.

This two-part article discusses five common pitfalls and the associated risks of not uncovering expectations in part one and, in part two, how a consulting approach will help mitigate them.

Requirements and Expectations

According to various standards bodies such as PMI, IIBA, and IEEE, 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. 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, whether spoken and/or documented. Expectations on the other hand, while 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 business needs and produce enduring results. When we ignore expectations, even if we have been meticulous in documenting stated requirements, we are apt to develop unusable products.

Common Pitfalls

1) 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 professionals usually feel they are not given enough time to define requirements, let alone uncover expectations.

The second is that clients are not always available to define their requirements. We frequently hear from key clients that they don’t have time to attend requirements workshops, for instance. We’re then left with undesirable alternatives. We can postpone the meetings and delay the project, we can hold the workshops without the clients, or we can proceed with incomplete requirements. Each one of these alternatives has the associated risk of incomplete requirements, surprises, rework, and expense. Research shows the total percentage of project budget due to requirements defects is typically from 25 to 40 percent and costs the economy $59.5 billion annually (SEI study, 7/15/2005).

2) 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 mistakenly assume that if we get the sponsor and clients to articulate their requirements, the product will meet their expectations. Having sponsors state their requirements is only the beginning of the process. If we collect the requirements as given without a consultative approach, it is highly unlikely that the end product will meet expectations.

3) Ineffective Questioning

One reason that stated requirements may not meet customer expectations is because ineffective techniques are used to ask questions about the requirements. Project professionals need to master the art of asking questions to ensure expectations are discovered. Asking questions like “what are your requirements for this project?” is not apt to yield successful results. Yes, surprisingly, this is a frequent type of question asked!

Asking the wrong questions, even when asked with good intentions, can lead to unwanted results. The categories discussed here include:

• Open- vs. closed-ended questions 
• Solution presentation 
• Feature fallacy. 
• Questioning Style

Open- vs. closed-ended questions. 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 we fall into the trap of presenting solutions that sound like questions. Also 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, by avoiding leading questions, such as “wouldn’t it be better to…” or “have you ever thought about…” we reduce the risk of creating barriers to communication. Listen to yourself during the course of a day and count how many times you ask leading questions.

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.

In a recent article, James Surowiecki discusses the issues related to what he calls “feature creep” (Surowiecki, May 28, 2007,

p28). Citing statistics for consumer returns on defective but difficult-to-use products, Surowiecki shows how many non-defective items are returned annually. Sixty percent 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. People are attracted to features, but will not be happy without usability.

Questioning Style. 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, etc, 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. Making the assumption that everyone responds similarly to engagement signals and affirmation can lead to barriers and distrust.

4) Using The Wrong Techniques

Even experienced project professionals are guilty of using the same techniques repeatedly, even when the techniques are not appropriate for the project at hand. For example, using business process modeling for a reporting function may not uncover the true requirements. Using inappropriate techniques can result in clients answering the wrong questions, thereby providing incomplete or incorrect requirements. This can result in being surprised at the end of a project with sponsors saying, “yes, I know that’s what I said I want. But it’s not what I really need!”

5) Accepting Solutions Presented by the Business and Technical Experts

A final pitfall is accepting a business solution provided by the sponsor and other key stakeholders. Although not a good practice, it’s common for business stakeholders to try to save time by giving specific product details (e.g. fields on a database table) without providing business reasons. Accepting solutions presented by business stakeholders forces project managers into the role of order takers, which usually leads to unusable and unused products.

A related pitfall is feeling constrained by an imposed technical solution, often forcing business needs to be subjugated to technical architectures, rather than having technical architecture support the business need. Forcing business solutions without taking existing business processes or needs into account, invariably leads to customer disappointment.

Overcoming Requirements Pitfalls

Look for the conclusion to this two-part article in the next Business Analyst Times, as we explore overcoming the above pitfalls. The consultative approach described shows how being a consultant to the business helps ensure that expectations are met. Part two explores practical approaches to meeting and exceeding expectations through understanding the business problem, and recommending solutions that meet real business needs, not just stated requirements.

Elizabeth Larson, PMP, CBAP, and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management skill development company.

Over 15 years, they have used their extensive experience to develop Watermark Learning’s training into a unique approach that combines industry best practices, a practical approach, and an engaging format. Attendees immediately learn the retainable real-world skills necessary to produce enduring results.

Each has presented numerous workshops, seminars, and training classes to thousands of participants on tree different continents. Their speaking history includes regular appearances at Project Management Institute (PMI) North American, European, and Asia-Pacific Congresses and PMI chapter meetings.

Both were recognized in 2006-2007 as two of the world’s first registered CBAPs (Certified Business Analysis Professionals) by the International Institute of Business Analysis (IIBA). They also serve on the BABOK development and review team. Both are certified project management professionals (PMP) through PMI, and are contributors to the upcoming 4th edition of the Project Management Body of Knowledge (PMBOK).

References

Project Management Institute (2004). A Guide to the Project Management Body of Knowledge(PMBOK®) (2004 ed.). Newtown Square, PA: Project Management Institute.
International Institute of Business Analysis (2006). A Guide to the Business Analysis Body of Knowledge, version 1.6. http://www.theiiba.org. 
SEI updated May 12, 2005 viewed 7/15/05. System Quality Requirements Engineering (SQUARE) Project, http://www.cert.org/sse/square.html 
Surowiecki, J. (2007, May 28) Financial Page Feature Presentation, New Yorker Magazine, page 28.