In the first article in our “Getting Back to Basics” series, Cathy discussed how asking the right questions ensures that we build the right solution for the business problem. In our next article, “Requirement Techniques”, Charlene wrote about three basic elicitation techniques used to obtain the requirements for the system being designed.
In our third and final article, we discuss the benefits of using an appropriate template as the vehicle for delivering requirements. We also cover how a review and approval process tailored to stakeholders can help create the alignment needed to move a project forward.
The Requirements Template
Once requirements elicitation is complete, the Business Analyst has a combination of presentations, meeting notes, diagrams, and other artifacts collected and created throughout the process. The next step is to find the best way to package those requirements into a format that allows you to confirm the results of your elicitation and gain approval from your stakeholders. This is where a requirements template can help.
Most organizations use some form of template for documenting requirements, as it provides a number of benefits, including:
- A good template helps guide the BA on how to present information in a format many stakeholders are familiar with (since most will recognize it from other projects).
- Templates commonly express information beginning with the more abstract business requirements followed by detailed specifications describing implementation details. This enables readers to see both the big picture and related details.
- Items that are deemed “Assumptions” or “Out of Scope” are labeled clearly and always in the same place from project to project.
- The template should include a Table of Contents for ease of navigation as well as a version number to support the inevitable additions or changes encountered during the review and approval process. (It may also make sense to create a change log to document the history of all your changes.)
- Templates serve as a default check list, reminding the BA to look at the requirements from all angles. For example, a section on “Constraints” can identify existing processes or systems that must remain in place with a successful solution. Seeing the “Constraints” section in the template reminds less experienced BAs to consider the impact to existing systems and processes as they determine whether their requirements are complete and ready for review.
Even with the structure they provide, templates may be customized to suit the need of a project. If a section is not needed, it can be omitted, or marked “n/a” depending upon organizational standards. At Geneca, we created a requirements template with common (always needed sections) but left the requirements detail to be dependent on the project. Following the concept of “Design Patterns” that developers use, we created “Requirements Patterns” that could be dropped in and used as needed in the detail section of the requirements template.
Stakeholders and Requirements Approval
BAs understand the importance of knowing their stakeholders. And, if they have done their job up to this point, they are well acquainted with them. They know who is playing the role of the project’s Executive Sponsor, the subject matter experts on the business side, and who the key technical stakeholders are. They also know which of these stakeholders needs to approve their requirements. Nothing is more frustrating than a surprise at review and approval time with a late addition to the stakeholder list.
Getting stakeholders to approve a requirements document can be a challenge. Each approver brings a different point of view. For example, business stakeholders may be primarily concerned with the ensuring the correct solution is in place for the business problem we are trying to solve. On the other hand, developers and testers are focused on whether the requirements are complete, with all the edge cases addressed.
The approval process is also colored by the world of office politics, where it may be difficult to ascertain what is truly important to a stakeholder. BAs who represent themselves as unfailing advocates for their projects are often best able to work through those issues preventing approval that do not represent gaps in the requirements.
The Art and Science of Communicating With Stakeholders
Effectively communicating requirements and earning stakeholder approval require a combination of technical and the soft skills.
Communication Plan: Creating and sharing a communication plan early in the project helps set the stage when it’s time to gather approvals. Elements within the plan should include how to best communicate with each stakeholder while acknowledging that there can be differences in the best way to reach out to different groups. For example, if one or more key stakeholders are in Europe while others are in North America, the location difference can make it a challenge to get everyone together for a requirements review. Conducting a review where some team members are present in a room and others are six time zones away on a conference line always poses a challenge for the BA striving for alignment.
Divide and Conquer: One technique that can be effective with a distributed team is the “Divide and “Conquer” approach. While there is no actual conquering involved, the Business Analyst builds consensus among approving stakeholders individually prior to requesting formal approval. This approach is often helpful when addressing issues critical to one group but less important to another. For example, while your technical stakeholders may be sensitive to making sure that any solution fits neatly into an existing architecture, business stakeholders may consider this a secondary concern. Taking time to align with each stakeholder individually can facilitate a smooth approval process. Alternatively, it can also highlight the short list of challenges that must be resolved with all stakeholders.
Always Be Closing: Another technique can be borrowed from the sales world: Always Be Closing (ABC). Business Analysts and sales people both work to build rapport with their clients in order to ultimately achieve consensus. During the sales process, incremental agreements that a product or service is meeting the needs of potential clients represents a step toward making a sale. Likewise, each time a stakeholder acknowledges that pieces of a requirements artifact represent a common understanding with the project goals, the BA is moving towards approval.
Always remind your stakeholders that you will eventually be asking for their approval and will regularly seek their feedback in order to uncover issues that need work prior to earning their signature.
Conclusion
With our “Back to Basics” series, Cathy, Charlene and I, attempted to step back from the all the processes, tools and advice available to the Business Analyst and take a fresh look at those tasks common to every project we face. Whatever the assignment, BAs always need to ask good questions, find the most effective way to elicit requirements, get those requirements on paper, and earn the approval of their stakeholders. Mastering these basic skills help you be successful no matter what challenges you have before you.
Author: Greg Kulander is a Senior Business Systems Analyst at Geneca, and is the Vice-President of Membership for the Chicagoland Chapter of the International Institute of Business Analysis. He has been working primarily as a Business Analyst on software projects since 1999 for such companies as JP Morgan Chase, U.S. Bank and NAVTEQ (now Nokia Location Services). He has helped lead successful projects in government, healthcare and private sector e-commerce, and was a founding member of the U.S. Bank Business Analysis Center of Excellence. He has a Master’s degree in Management Information Systems from Benedictine University, and Bachelor’s degree in Marketing. Greg thoroughly enjoys seeing a project go live and watching an organization reap the benefits of well-made software.