Plan Business Analysis Communication - Business Analyst

Purpose

Business Analysis Communication Plan Template

A business analysis communications plan describes the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications.

Description

Planning business analysis communications includes determining how best to receive, distribute , access, update, and escalate information from project stakeholders, and determining how best to communicate with each stakeholder.

Requirements can be presented in various formats. This task describes the work required to decide which format(s) are appropriate for a particular initiative and its stakeholders. Requirements should be presented in formats that are understandable for the reviewer; they must be clear, concise, accurate, and at the appropriate level of detail.

Considerations for the business analysis communications plan include:

• what needs to be communicated;
• what is the appropriate delivery method;
• who is the appropriate audience;
• and when the communication should occur.

Stakeholder needs and constraints relevant to communication include:

• Physical location/time zone of the stakeholders.
• Communication approach for the stakeholder.
• What types of communications will be required (e.g. status, anomalies, issues and their resolution, risks, meeting results, action items, etc.)
• What types of requirements will be elicited (business, stakeholder, solution, or transition; high level vs.detailed) and how best to elicit them (see the Elicitation KA for options).
• How best to communicate requirements conclusions / packages, including authority level (signoff authority, veto authority, or review only).
• Time and resource availability constraints.

Input

Business Analysis Approach: May include standards and templates used for communication , and expectations regarding when and how communication should occur.

Business Analysis Plan(s): Determines when work will be performed and the deliverables that will be produced, and which need to be communicated.

Organizational Process Assets:May include a defined set of templates for use in business analysis communication, including presentation formats, requirements documentation templates, and others.

Stakeholder List, Roles, and Responsibilities: Used to identify the stakeholders who will require information regarding business analysis work, determine when information needs to be provided, and how a stakeholder is expected to use that information.

Elements

1. Geography

The communications needed for a team that is collocated will be different from communications required for a project with geographically dispersed stakeholders. For example, it is more difficult to have short, daily team meetings when the participants live in vastly different time zones, when technology is not readily accessible, and where multiple, complex deliverables with complex interfaces are being developed simultaneously in different locations.

2. Culture

Cultural diversity should also be taken into account when planning communications. Cultural considerations are important regardless of where the team members are located.

In addition to the obvious language barriers, there may be more subtle differences that should be considered in the plan, including:

• Relationship to time.Some cultures view deadlines as firm commitments, while others may view deadlines as a goal to be balanced against other concerns and interests.


• Relationship to task completion. Some cultures complete tasks because they have committed to the planned activities. Others complete tasks primarily when trust and the human relationship have been built.


• Relationship to contracts. Some cultures believe in the letter of the law, others in the spirit of the contract. This difference might surface when creating Requests for Proposal, for example.


• Relationship to formal and informal authority.Some cultures prefer a centralized power structure where decisions are made by a small group, while others prefer to involve all affected stakeholders in approving decisions.

The use of models following a standardized notation can help overcome language barriers by eliminating the need for many textual descriptions.

3. Project Type

Different projects will necessitate different deliverables, and the extent of documentation that is needed in a requirements package will vary depending on the project. Some examples are:

A new,customized in-house software development project.In this scenario, all requirements may need to be included.

Upgrading the technology or infrastructure of a current system.In this scenario, only the technical requirements may need to be included in the package.

Change in a business process or new data for an existing application. In this scenario, the process and data requirements, business rules, functional and technical requirements will be needed.

Purchase of a software package. This type of project will likely require a Request For Proposal, and the package will need to include the business requirements, technical requirements, limited functional requirements and other vendor specifications.

Short,focused,agile style iterations of software development.These projects may not specify any or very little formal requirements documentation. Whiteboards, flip charts, and user stories may suffice. Agile focuses on creating the minimum necessary of documentation to deliver the requirements, and many agile teams will prefer to document the solution after it has been delivered.

4. Communication Frequency

Investigates the frequency required by various stakeholders for each type of communication. Note the frequency of reporting can vary from stakeholder to stakeholder. For example, the frequency of reporting business analysis status can be biweekly for the sponsor, weekly for the Domain Subject Matter Experts and biweekly for the technical partners.

5. Communications Formality

Planning communications requires taking into consideration the level of formality that is needed.This could vary from stakeholder to stakeholder, project phase to project phase,work within a project phase,and requirements presentation.

Communication tends to be more formal under the following circumstances:

• The project is unusually large (by organizational standards) and will be delivered in phases. The level of communications formality tends to increase as the scale of a project increases. This is because more stakeholders are typically involved and more communication is required.
• The domain involved is very complex. Note that the domain affected by the project may span departmental and divisional boundaries within the organization. For example, the domain of engineering employee recruitment could involve the engineering, human resources, payroll, marketing and benefits administration departments. These groups will all be key stakeholders for the project and its deliverables.
• The technology employed, if any, will be new, or new to the organization.
• The project is considered to be mission critical, in that it is tied directly to strategic objectives.
• The executive sponsor and / or key stakeholders require formality.
• The requirements are likely to be subject to regulatory review.
• The requirements will be presented to suppliers in an RFQ/RFI/RFP.

Techniques

See Prepare Requirements Package and Communicate Requirements for additional information. Communication techniques are described in Communication Skills.

Structured Walkthrough : One of the most common approaches to requirements communication. Time to conduct each walkthrough and address the issues raised during the walkthrough must be included in the plan.

Stakeholders

Customer and Supplier: Major customers of an organization or suppliers to that organization (particularly institutional customers) may need to be informed of planned changes well in advance of implementation.

Domain SME: May be involved in review and approval. Likely to focus on matters of particular interest or on the areas on which they are an SME. Domain SMEs often have influence over the approvers, even if their approval is not formally required.

End User: May be involved in review and approval. May also have considerable influence over approvers even if their approval is not formally required.

Implementation SME: May be involved in review and approval.

Operational Support: May be involved in review and approval. Will primarily focus on the requirements to support the solution.

Project Manager: In a project, the business analysis communication plan will generally be integrated into the overall project communications plan. On small projects the plan may be very brief and may not be formally documented. On large and complex projects and projects with many stakeholders, it may be included as part of the project initiation documentation and is essential as part of the overall project communications plan.

Tester: Will primarily be involved in verification and validation of the requirements.

Regulator: Regulators may require that requirements, decisions, and other information regarding the execution of business analysis processes or the definition of the solution be retained and made available to them for review.

Sponsor: Communication needs for the sponsor are likely to focus on business requirements and high-level stakeholder and solution requirements.

Output

Business Analysis Communication Plan: Describes how, when and why the business analyst will work directly with stakeholders.Components can include:

• The stakeholder communications requirements for business analysis activities.
• Format,content,medium,level of detail.
• Responsibility for collecting, distributing, accessing, and updating information.