“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.

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

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

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.