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