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.
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:
Stakeholder needs and constraints relevant to communication include:
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.
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.
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:
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:
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.
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.
Business Analysis Communication Plan: Describes how, when and why the business analyst will work directly with stakeholders.Components can include:
Business Analyst Related Interview Questions
|Business Analyst Interview Questions||Business Letter Format Interview Questions|
|Business Communications Interview Questions||Business Environment Interview Questions|
|Business Management for Financial Advisers Interview Questions||Business Development Interview Questions|
|Business Management Interview Questions||Executive Business Analyst Interview Questions|
|Business Objectives Interview Questions||Business Development Manager Interview Questions|
Business Analyst Tutorial
Business Analysis Planning & Monitoring
Requirements Management & Communication
Solution Assessment & Validation
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.