Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, has been the CEO for Watermark Learning as well as a consultant and advisor for Educate 360. She has over 35 years of experience in project management and business analysis. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as the several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, and spending time with her 6 grandsons and 1 granddaughter.

Avoiding Conflict between the PM and BA. Part 1

At a recent conference I sat next to a project manager who observed, “My organization hired a new consulting company to do business analysis work. They’ve completely taken over. Now they do a lot of the work that I used to do, such as meeting with the sponsor to uncover the business problems, determining what we’re going to do on the project…I can’t believe it! I feel like I’m being treated like a second-class citizen!”

While this complaint pointed out some organizational issues, it also got me thinking about the role of the PM and the BA in the early stages of a project. The two bodies of knowledge, the BABOK® Guide 2.0 and PMBOK® Guide – Fourth Edition, each allude to work being done at the beginning of the project , so it is not surprising that conflict between these two roles can arise.

It’s easy for me to say that spelling out roles and responsibilities helps avoid this conflict. Using a responsibility assignment matrix, such as a RACI, is helpful, but it may not be enough. Looking back it seems to me that as both a BA and a PM, I never spent a lot of time dwelling on this issue. When I was a BA I didn’t have a project manager, so in a sense I was able to avoid conflict. When I became a PM, I was extremely fortunate to work with strong BAs who took the initiative to define their own roles. Below I have listed what worked for us and why. Next month I’ll delve more into the pitfalls and some examples of less successful projects.

We worked on a project which had both business and technical complexity. We were introducing many new business processes as well as new technology. The project affected many business units within the organization, and the risk was high. Below are a few of the factors that I believe contributed to a smooth relationship between the BA and me (PM), and ultimately to a very successful project:

  • We each worked with our strengths. As a PM, mine was focusing on delivering the product (new software) when we had promised it, within the approved budget, and with frequent communication with the sponsor. As a BA, hers was an incredible ability to understand the real business need-why the project was being undertaken, what was happening currently, and what we needed to recommend to the sponsor, which was different from what the sponsor had requested. Without her, I would have accepted the solution originally requested by the sponsor, a solution which would not have solved their business problem.
  • We kept the good of the organization in front of us at all times. There simply was no grab for territory, because it wasn’t about us. It was about delivering a product that worked–on time and within budget. One of the team members observed that she felt like we were giving birth. The good news was, though, that we didn’t have to suffer through teenage years!
  • I was focused on the date and budget, so my natural tendency was to want to do the project quickly rather than correctly. Fortunately I had the good sense to listen to the BA and slow down when I needed to, which was usually at her insistence. Was this easy for me? Not at all! Am I glad I did? You betcha!
  • I completely trusted the BA. But the whole topic of trust is the topic for different blog on another day.

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part II

Now that we have looked at the framework for requirements management, let’s delve deeper into requirements planning.

The Requirements Management Plan 

Planning the business analysis work effort is part of the overall effort to plan the project, and the resulting Requirements Management Plan becomes part of the project management plan. Below is a table with some of the key planning activities, the sub-processes associated with each, and the final deliverables that are produced. As stated earlier, these deliverables are rolled into the requirements management plan, which in turn, is a subsidiary plan within the overall project management plan.

Because of the interrelationship of the project and the product, of the project manager and the business analyst, most of the activities below, while focusing on the product or activities to produce the product, are part of the larger project. The effective project manager, in planning for the whole project, seeks input from a variety of team members to create scope, schedule, and cost baselines. One of these team members is the business analyst, who provides input on the business analysis phase or phases. In other words, the business analyst plans which activities will be needed to define the product requirements completely and correctly. The information from business analysis feeds into the overall project.

Below is a table which expands on the activities in the knowledge area of business analysis planning and monitoring, the processes within the broader tasks, and the key deliverables that are output from these processes.

idonthave1.png

 

Exhibit 3 – Requirements Planning Activities and Deliverables

It is helpful to remember that each of these activities and sub-processes should be considered and performed, although not with the same amount of formality. For example, identifying project roles can take place in a formal, facilitated session with cross-functional representation, or it can occur when the project professional informally touches base with a limited number of stakeholders. Likewise, the deliverables may be permanent and stored in a repository or they can be temporary, a by-product of an informal conversation. In the latter example, the deliverable may be produced on a whiteboard and erased at the end of the discussion, kept in notes until the end of the project, or archived indefinitely. What is important is that these decisions be made purposefully and before the execution of business analysis has occurred.

Clarifying Roles

One of the first tasks in requirements planning is completing stakeholder analysis, during which time it is important to clarify the project professional’s role and associated responsibilities. Because of the interrelationship of the project and product, the roles of project manager and business analyst tend to blur in some organizations and on some projects. Here are several considerations to help clarify these two roles:

  • The difference between the function of managing the project and that of managing both the requirements and the business analysis phase(s). Although the same person can certainly manage both functions, they are different and the associated roles are also different. Skills required and characteristics of effective performance differ for each role, so giving thought to each during stakeholder analysis is important. For example, it is even more important for the project manager than the business analyst to have human resource management skills, and it is even more important for the latter to be an expert facilitator.
  • The consultative nature of the project professional’s role. In establishing roles and responsibilities it is important to view the project professional as a consultant who makes recommendations, rather than either as an owner or as an order-taker. One of the required skills is the ability to influence without authority. A responsibilities assignment matrix, such as a RACI, can help with this clarification. 
  • The importance of distinguishing between requirements management and product ownership is also critical. We need to remember that managing requirements does not mean owning them. When clients are not available, it is rarely in the best interest of the project to continue without executive and business client support. Since it is the sponsor who has a business problem needing a solution, the sponsor needs to assign people who can define what they want in a timely manner. The project professional can have input and can certainly make recommendations, but the final decisions and acceptance of the requirements need to rest with sponsors. Therefore it is necessary to clarify the sponsor’s role as the ultimate owner, even if they have chosen to designate a day-to-day project owner. 
  • Finally, project professionals need to keep asking why the stated business problem is worth solving and to explain why it’s in the sponsor’s best interest to provide available resources who can define the requirements that will solve the business problem.

The next article in the series explores the consultative nature of the project professional and provides tips for negotiating to ensure there is enough project time for requirements management.


Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com.

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

Part 3: Recommending Solutions that Address Expectations

As discussed in the first two parts of this article, project professionals realize that projects fail when customer requirements are not clearly defined and customer expectations are not met. The consultative questioning presented in the earlier parts is essential to understanding the business problem and its limitations. The project manager or business analyst can then analyze root causes of the problem or opportunity, and will be able to recommend a solution to solve the business problem at hand. If the recommendation is accepted, we can then recommend the most effective implementation approach. The major steps involved in the consultative approach are:

  1. Asking questions to uncover problems and synthesizing the responses
  2. Analyzing those problems
  3. Advising clients by recommending solutions.

This article focuses on analysis and recommendations.

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.

Tip: Modeling provides the structure to ask the right questions at the right time during the project, and provides a basis for solid recommendations.

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.

The following chart shows a table for requirements models used in software development

Model Benefit of use Main Use Can be Used for Non-Software Components
Business process Change management. How will use of the product cause business processes to change. Document the current “as-is” and future “to-be” business processes, identify gaps. Determine ways to get to “to-be.” Use as a basis for other models to assess impacts. Yes
Data model Provides structure for getting information requirements. Gather the information required to support the proposed process. Requires understanding the business rules enforced by data, and planning how to convert from the current to the future state. No
Use case model Defines how the new product (system) will work. Documents interactions between the end-user and the system. Shows the interactions of other systems and time triggers to the system. Yes
Prototype Can be used to document navigation, design, usability, errors and messages, look and feel of the end product without investing the time and resources needed for full product development. Prototypes are mockups that can be “paper and pencil” or mockups using technology, but without full functionality.
Prototypes provide the ability to see and use a model of the product before full implementation.
Yes

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. It’s important that the tone 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 will give the recommendation 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 added 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 in every venue. 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

Tip: Be courageous. While we want to keep the audience in mind, we need to present what we think is the right thing for the organization, even if we perceive that our audience is not receptive. By doing our homework, analyzing impacts and alternatives, we can present with confidence.

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 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 and business analysts do not need to make the decision to accept the recommendation. That’s for the sponsor and executives. However, project professionals 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.

Summary

In this series, we explored how to uncover client expectations and why this is so important to delivering the right product. Uncovering expectations takes time and requires the art of consultative questioning. It demands patience with clients who have difficulty articulating their requirements. Uncovering expectations takes a commitment to defining requirements in sufficient detail to understand what those expectations truly are. It requires a process for eliciting the requirements, and also for analyzing, documenting, and validating them. Finally, the consultative approach we presented acknowledges that the expectations we uncover may require recommendations for shifting the business to adopt and embrace them.

(For parts 1 and 2 of this series, return to the Home Page, click on Articles and then on September 2007 and October 2007)

 


Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Each has presented numerous workshops, seminars, and training classes to thousands of participants on three different continents. They regularly speak on business analysis and project management topics at Business Analyst World conferences and Project Management Institute (PMI) Global Congresses. Elizabeth and Richard are frequent contributors of articles to international trade publications such as CIO; ComputerWorld; BA Times; PMI PM-Network Magazine; the University of Houston book, IT Project Management Readings; Certification Magazine, ICFAI Professional Reference Book – Project Management-Emerging Perspectives; and many others. Elizabeth and Richard are also contributing to the Fourth Edition of the PMBOK in a section on collecting requirements.

 

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

Part 2: Using Consulting Skills to Uncover Expectations

As presented in Part 1 of this article, project professionals realize that projects fail when customer requirements are not clearly defined and customer expectations are not met. Project managers and business analysts face a number of challenges in developing the kind of usable products that customers expect.

In Part 1, we mentioned five pitfalls to uncovering expectations: 1) the Time Trap, 2) Stated Requirements Don’t Meet Expectations, 3) Ineffective Questioning, 4) Using the Wrong Techniques and 5) Accepting Solutions Presented by the Business. This article continues the discussion by addressing how these common pitfalls can be addressed by using a consulting approach and focuses on consultative questioning.

Using Consulting Skills to Overcome Requirements Pitfalls

Overcoming the many pitfalls described in Part 1 requires a consultative approach. Why is that? Being a consultant to the business helps ensure that expectations are met. The background of a situation is assessed by understanding the business problem, analyzing the current state, understanding the limitations, and gathering supporting statistics that detail the exact impact of the current situation. The project professional is then in an excellent position to recommend a solution that will solve the business problem at hand. Effective consultants have learned that the key to success includes:

  1. Asking questions to uncover problems and synthesizing the responses
  2. Analyzing those problems
  3. Advising clients by recommending solutions.

This article explores Step 1 and focuses on consultative questioning.

Asking the Right Questions

Asking the right requirements questions can be challenging, because we need the right context for asking good questions. Being a consultant requires asking questions to obtain the right perspective, before trying to understand the details of the end product. Once we have the context, we can then move on to questions related to our product.

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:

  1. What business problems are being solved with the project?
  2. What opportunities is the organization taking advantage of?
  3. What are the external threats that this project addresses?
  4. How does the project take advantage of the organization’s strengths or compensate for its weaknesses?
  5. What is the product description and project vision?
  6. How does this project link to the organization’s strategic direction?
  7. How will this product be perceived in this organization?

A few good questions for understanding the project context can include such things as:

  1. How much are you willing to spend on this project?
  2. What is the priority of this project in relation to the other projects in this portfolio/program/organization/division?
  3. What are your time constraints and what causes them?
  4. What risks do you see with this project?
  5. Who/who else should we talk to?
  6. Who are the subject matter experts and what experience do they have?
  7. If you had to choose among time and cost, scope, and quality which is the most important to you? Least?

Some good questions for learning high-level product requirements includes such things as:

  1. To what extent will this new product cause business processes to change? Which ones will change and in what way?

    Tip: avoid questions related to detailed features and functions until the business, project, and product context are clearly understood and documented.

  2. What do people need to know in order to use this product?
  3. How will internal and external customers use the product
  4. How will the product be sold? Maintained? Supported?
  5. What impacts to other areas are you aware of?
  6. How stable are the product requirements?
  7. Tell me about the best/worst product feature you’ve encountered? Easiest/hardest product to use that you’ve had to use?

Synthesizing Responses

Synthesizing responses uses active listening skills to take a great deal of disparate information and organize it in a way that is useful to the appropriate stakeholders. It starts with active listening, which involves ensuring that what is said by the speaker is actually heard correctly and completely by the listener. The listener needs to ask clarifying questions and paraphrase what is thought to be heard. Asking good and relevant questions builds confidence in the speaker that there are no assumptions or misconceptions on the part of the listener.

To effectively synthesize information, critical thinking skills are needed along with 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.
  • Organize, discriminate, and discern disparate pieces of information, putting them together in concise and useful ways.
  • Distinguish between what’s important from what is not, and discard the unimportant. Experience is invaluable in making this determination. Analysis tools can also be 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. , a globally recognized business analysis and project management training company. Each has presented numerous workshops, seminars, and training classes to thousands of participants on 3 different continents. They regularly speak on business analysis and project management topics at Business Analyst World conferences and Project Management Institute (PMI) Global Congresses. Elizabeth and Richard are frequent contributors of articles to international trade publications such as CIO; ComputerWorld; BA Times; PMI PM-Network Magazine; the University of Houston book, IT Project Management Readings; Certification Magazine, ICFAI Professional Reference Book – Project Management-Emerging Perspectives; and many others. Elizabeth and Richard are also contributing to the Fourth Edition of the PMBOK in a section on collecting requirements.

Tip: Use traceability to help ensure that each requirement is linked with project deliverables, project objectives, business problems, and business objectives, preventing rogue requirements from sneaking into the project.

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.

Summary

Uncovering expectations takes time and requires the art of consultative questioning. In this article, we focused on tips for effective questioning. We presented several ideas and examples of asking the right questions, regardless of the product or service of the project. We stressed the importance of synthesizing the information obtained to make it relevant. We also showed how a traceability matrix can be a useful tool for synthesizing sizable amounts of information like requirements. Part 3 will conclude the series with the remaining steps of the consulting process, and will focus on analysis and recommendations.

 


Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Each has presented numerous workshops, seminars, and training classes to thousands of participants on 3 different continents. They regularly speak on business analysis and project management topics at Business Analyst World conferences and Project Management Institute (PMI) Global Congresses. Elizabeth and Richard are frequent contributors of articles to international trade publications such as CIO; ComputerWorld; BA Times; PMI PM-Network Magazine; the University of Houston book, IT Project Management Readings; Certification Magazine, ICFAI Professional Reference Book – Project Management-Emerging Perspectives; and many others. Elizabeth and Richard are also contributing to the Fourth Edition of the PMBOK in a section on collecting requirements.

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

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

“Project professionals need to master the art of asking questions to ensure expectations are discovered.”

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,

“People are attracted to features, but will not be happy without usability.”

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.