Business Analysis: Developing a Communications Strategy

Business Analysis: Developing a Communications
Strategy

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.

Designing the Communication Strategy

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.

The BA will develop a framework to document the timing, method, and stakeholders involved with the requirements. He should consider the following issues when designing a communications plan:

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

Interested in learning more? Why not take an online Business Analysis course?

Starting a Project A requirements communication plan indicates the BA's intentions regarding the delivery of information to stakeholders. It is a document that establishes:

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

Requirements Communication Plan Process

Figure 12-1. Requirements Communication Plan Process

Manage Requirements ConflictsIf project requirements affect more than one stakeholder, there may be a need to resolve conflicts between both the stakeholder expectations regarding needs and the requirements themselves. Within the communication plan, the BA must choose the method that will most effectively resolve the conflict. Sometimes that may mean bringing the stakeholders together in a face-to-face meeting, or it could require the BA to conduct additional research then share his findings with the conflicted parties.

The BA will first record the conflict in a requirements issues log where each party's issues are represented. Then the appropriate communication tool is used to convey the fundamental conflict points to all interested parties. From there, the BA will continue to facilitate a dialogue between the conflicted parties until the matter can be resolved. Throughout the process, the BA should document each step that is taken and continually audit the process to uncover communication inefficiencies or problems and determine corrective actions.

Choosing an Appropriate Communications Format

The BA is responsible for determining what format will be the most effective and efficient and conveying requirements information. Project requirements are usually presented to more than one stakeholder, so the method(s) chosen must 1) meet the needs of the interested stakeholders and, 2) clearly, concisely, and accurately express the requirement information. In some cases, the requirements may have to be conveyed using multiple formats.

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.

Figure 12-2. Formats for Communications

Preparing a Requirements Package

Combining the requirements deliverables into a comprehensive presentation is necessary to present a complete picture to stakeholders. The requirements package is a key component to success downstream (in future processes) as it should incorporate all facets, conditions, constraints, and methodologies of the requirements; any gaps, inconsistencies, or misinformation should be removed prior to presenting the package. This phase can be done iteratively, combining subsets of information as requirements are fulfilled. The goal of the package is to present enough detail to gain sign-off by stakeholders.

The process for creating a requirements package involves four primary steps:

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

Conduct a Requirements Presentation

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.

The presentation will usually focus on areas such as business requirements, data and behavior models, functionality, and process flow. The IIBA Book of Knowledge indicates that "the presentation has a structure consisting of:

· 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)."

The output of the presentation may include team action items, requirements amendments, requirements approval, or a list of unresolved issues.

Requirements Review

At any time during the requirements phase of the project, the BA may conduct a requirements review to verify accuracy and completeness, to clarify information quality, or to obtain a sign-off. This is typically an iterative process that develops into a comprehensive requirements package. The BA will host a working session where relevant stakeholders will review documentation and discuss issues, opportunities, challenges, outcomes, and other facets of the requirements.

There are several roles that are played within the requirements review:

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

The participants are usually required to review documents prior to the session, and are to comment only on the material and not on the author. The deliverables from a review session can include a list of amendments or issues, a set of action items, or materials that have received a sign-off.