This article covers the BA's responsibilities in communicating the project requirements to stakeholders and others. We discuss the design of a communications strategy, the development of a communications plan, choosing the appropriate communications format and managing conflicts. We conclude with the requirements package, presentation, and review process.
During the requirements elicitation, planning and documentation phases, one of the BA's primary responsibilities is the ongoing communication that takes place. Requirements communication is an iterative process of conveying information to stakeholders in order to gain a common understanding of the requirements necessary to complete an initiative or solution. These activities are done concurrently with the other requirements activities.
The main focus areas for the BA's requirements communications activities are as follows:
1. Create a requirements communications plan.
2. Manage requirements conflicts.
3. Determine requirements format.
4. Create a requirements package.
5. Conduct a requirements presentation.
6. Conduct a requirements review.
7. Obtain requirements signoff.
· Information that needs to be shared and how it will be delivered.
· Who is the appropriate recipient for a knowledge set?
· When does information need to be delivered?
· Stakeholder authority level (sign off, input delivered, or review only).
· Requirements that have been elicited (high level versus detailed, business versus end.
· Communication of final deliverables.
1. The objectives the BA seeks for the communications process (for instance ensure complete stakeholder understanding of the requirements).
2. The ways in which the objectives will be accomplished (that is, defining the process).
3. The audience to whom communications will be delivered.
4. The tools and timetable for delivery of information.
5. The measurements to be used to evaluate the plan's results.
The plan will include written, oral, digital, and electronic means of communication. It defines both the one-way and two-way communications (for example, the BA distributes a memo to stakeholders who respond by email). Once the framework has been developed, the BA implements the plan (see figure 12-1).
Figure 12-1. Requirements Communication Plan Process
To ensure that requirements can be traced, the BA will use documentation that supports information exchange, even if some communications only require an oral conveyance. For example, they may use visual tools, such as diagrams and flow charts, or textual tools, such as a requirements summary, or a prototype, such as a model. As with documentation throughout the project, the method must conform to organizational standards, culture, and operational guidelines.
Figure 12-2 shows the process for determining the appropriate formats for communications.
1. Determine which components to group together. Present a cohesive set that can be reviewed by one or more stakeholders.
2. Assess the audience. Identify the communication needs of stakeholders and authorities.
3. Evaluate required documentation. Assess what information should be included and whether the package fulfills those requirements (like a software platform development model).
4. Package requirements for presentation. Construct a package that is applicable to the intended audience (for example, project sponsor or subject matter expert).
The BA will typically make at least one presentation throughout the project's life. Whether it is formal or informal, a requirements presentation is meant to accomplish objectives that may include:
· To ensure or enhance the clarity or quality of requirement.
· To review, analyze, and/or prioritize requirements.
· To communicate status and/or obtain authority sign-off.
· Introduction of parties attending presentation.
· Statement of presentation objectives.
· Project background.
· Presentation or review of deliverable.
· Agreement of actions or changes required.
· Review of deliverable status (for instance, signed off, not signed off, and more)."
· Author. Typically the BA, this is the author of the requirements documentation. He can answer questions and incorporate changes into the documents.
· Recorder. Can be the author, this is the person who documents suggestions, questions, comments, issues, and others discussed within the review.
· Moderator. The person who facilitates discussion and maintains a review focus.
· Author Peer. This person has experience writing similar documentation and can verify the author's adherence to standards
· Reviewers. A person with interest in the project who reviews the documentation and provides questions, comments, suggestions, and more.