Plan Business Analysis Activities - Business Analyst

Purpose

Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables.

Description

The business analyst determines which activities are required for a given initiative, how those activities will be carried out, the work effort involved, and an estimate of how long the activities will take. This task includes activities to:

• Identify business analysis deliverables
• Determine the scope of work for the business analysis activities
• Determine which activities the business analyst will perform and when
• Develop estimates for business analysis work.

Business Analysis activities Plan Example

The activities that are executed and how they are executed will determine the quality and timeliness of the business analysis deliverables and ultimately of the solution. The business analysis plan(s) identify and schedule the activities and resources required to produce a clear, concise set of requirements that support development of the solution.

This planning activity will typically occur more than once on a given initiative or project, as plans frequently must be updated to address changing business conditions, issues encountered by the business analyst or other team members, lessons learned through the performance of business analysis activities, or other changing circumstances.

One way of accommodating change on a larger initiative is to plan on an incremental or rolling-wave basis. This approach to planning creates a high-level plan for the long term and detailed plans to address near-term activities, with the understanding that the long-term plans will change as more information becomes available. An alternative, used in change-driven methodologies, is to follow a well-defined, time-limited process for developing requirements and limit each iteration to the work that can be completed in the time allotted. A long-term roadmap may be used to set expectations, but the contents of the roadmap are constantly revisited as priorities change.

Input

Business Analysis Approach: Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan-driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible. These differences will lead to different deliverables and tasks being identified as well as different sequences and dependencies of tasks. The approach will also determine how the planning process is performed.

Business Analysis Performance Assessment: The business analyst must use prior experiences on this initiative or on others to determine the effort involved in performing business analysis work.

Organizational Process Assets: The organizational standards and process assets in place may mandate certain deliverables. Lessons learned from previous initiatives, as well as from currently ongoing business analysis activities, may be used in the development of business analysis plans.

Stakeholder List, Roles, and Responsibilities: Stakeholders will exhibit individual behaviors and preferences that may need to be met. For example, one key stakeholder may prefer the use of process maps, which could influence the planning of business analysis tasks related to this stakeholder. Another stakeholder may have some experience using a particular technology and be in favor of its choice for the current project, which might also influence the business analysis deliverables, tasks, and estimates. Understanding their roles and responsibilities on the project will help to determine how much those preferences will shape the plan. In addition, time will have to be set aside to work with stakeholders to elicit and analyze requirements and for those stakeholders with decision-making authority to approve requirements. The role of each stakeholder must be understood so that the appropriate activities can be scheduled and the necessary

Elements

1. Geographic Distribution of Stakeholders

The business analyst must consider the physical location of key stakeholders on the project. Some projects will have the stakeholders located in a single location while others will have some of their key stakeholders dispersed over a wide area. These latter projects may well involve increased complexity, which will have an impact on the estimate of some activities and tasks in the project. Stakeholders may be collocated or dispersed.

Collocated: All key stakeholders are located in the same local geographic area. There are no special location-related planning considerations for the business analyst involved in these projects.

Dispersed: These more complex projects have some key stakeholders located in different geographic regions or countries. The factors of distance, possible time differences and cultural and language differences increase the complexity for business analysis and will require effort to identify and account for these differences and how they will affect requirements planning and solution development / selection, testing and implementation. If stakeholders are dispersed, it may be necessary to have more teleconferences or videoconferences rather than face to face meetings.

Another common situation involves an outsourced development project where the development team is physically located many time zones away. This type of situation, for example, will be accounted for during business analysis planning and might be better served with more detailed requirements documentation and acceptance criteria or more frequent review sessions.

2. Type of Project or Initiative

The type of project or initiative to which the business analyst is assigned may have a significant impact on the activities that need to be performed. For example, in a project to purchase a new software package, the work will be different from an effort to develop a new business process. Different kinds of business analysis initiatives include, but are not limited to:

• Feasibility studies
• Process improvement
• Organizational change
• New software development (in-house)
• Outsourced new software development
• Software maintenance or enhancement
• Software package selection

3. Business Analysis Deliverables

A list of deliverables is useful as a basis for activity identification. Methods for identifying deliverables include, but are not limited to:

• Interviews or facilitated sessions with key stakeholders.
• Review project documentation
• Review organizational process assets, such as methodologies and templates, which may dictate which deliverables are required,

An organization may have a standard set of deliverables, or multiple sets that are used to support different approved methodologies. The breakdown of deliverables may also be dependent on the techniques selected by the business analyst, and may include deliverables such as interview questions, meeting minutes, use case diagrams and descriptions, and as-is / to be business process models. The business analysis approach frequently mandates the use of certain techniques. Most agile methods assume that user stories will be used to document stakeholder requirements, and a Business Process Management initiative will require process modeling.

Frequently, additional techniques may be selected on an ad-hoc basis during execution of business analysis as the business analyst encounters situations for which they are most appropriate. For example, the business analyst may decide to elicit requirements using a requirements workshop, and then determine in that workshop that a particular stakeholder has additional requirements which are best identified through an interview or observing that stakeholder on the job.

Deliverables will often take the form of a requirements package,as described in Prepare Requirements Package. The selection and format of requirements packages is likely to be mandated by the business analysis approach.

4. Determine Business Analysis Activities

An important tool in defining the scope of work and in developing estimates is the work breakdown structure (WBS). The WBS decomposes the project scope into smaller and smaller pieces, creating a hierarchy of work. A WBS may break down the project into iterations, releases, or phases; break deliverables into work packages; or break activities into smaller tasks.

Work packages include at least one and usually many activities, which can be further broken into smaller and smaller tasks. This decomposition of activities and tasks creates the Activity List.

The Activity List can be created in different ways, such as by:

• Taking each deliverable, assigning the activities required to complete the deliverable, and breaking each activity into tasks
• Dividing the project into phases, iterations, increments, or releases, identifying the deliverables for each, and adding activities and tasks accordingly
• Using a previous similar project as an outline and expanding it with detailed tasks unique for the business analysis phase of the current project

The elements identified for each activity and task may include:

• Unique Numberto uniquely identify each task.
• Activity descriptionlabeled with a verb and a noun, and describing the detailed tasks that comprise each activity. For example, an activity might be labeled “Update Requirements Document”.

In addition, it may include other information, such as:

Assumptions: For each task, there may be factors or conditions which are considered to be true. The business analyst can document these factors, and where present estimates will be developed using these assumptions.

Dependencies: Identify logical relationships, such as which activities have to be completed before subsequent tasks can begin.

Milestones: Represent significant events in the progress of a project. Milestones are used to measure the progress of the project and compare actual progress to earlier estimates. Milestones can be used as a time to celebrate the completion or delivery of a major deliverable or section of project work. An example of a major milestone is the stakeholders’ and sponsor’s formal approval of a requirements document.

Techniques

Estimation: A variety of estimation techniques can be used to produce an overall assessment of the amount of business analysis work required. In some cases, multiple techniques may be used to validate one another. Estimates are normally developed in conjunction with the project manager and other team members, and make use of the organizational methodology and templates for developing estimates.

Functional Decomposition: Decomposition of the tasks in a project (using a work breakdown structure) or product (using a solution breakdown structure) can be used to facilitate an understanding of the work at a sufficient level of detail to enable estimation of tasks.

Risk Analysis: Identify risks that might impact the business analysis plan(s).

Stakeholders

All stakeholders listed here may potentially participate in the verification and validation of business analysis deliverables.

Customer, Domain SME, End User, and Supplier: Domain SMEs will likely be a major source of requirements and their availability is critical when planning activities. Their understanding of business analysis techniques may shape the selection of techniques or require that the business analyst devote some time to assist them in understanding how the requirements are defined.Customers and suppliers may be especially difficult to schedule effectively.

Implementation SME: The Implementation SMEs may participate in business analysis activities in order to facilitate understanding of stakeholder needs. They will need to know in what form and when deliverables will be produced as inputs into their own activity planning.

Operational Support: May use business analysis deliverables as a basis for planning operational support activities or developing appropriate documentation.

Project Manager: In a project, the business analysis plan is integrated with and a component of the overall project plan. The project manager should participate in business analysis planning and is responsible for ensuring that those plans are integrated with the work performed by other project personnel.In addition, the scope of business analysis work within a project is managed as part of the overall project scope, and changes to that scope of work (for example, as new stakeholders are identified or business requirements change) may require approval of a project scope change. The project manager will also play a key role in identifying resources to perform tasks, scheduling the activities, and developing cost estimates.

Tester: Will need to know in what form and when deliverables will be produced as inputs into their own activity planning.

Sponsor: Must participate in the approval of business analysis deliverables.

Output

Business Analysis Plan(s): The business analysis plan(s) may include information such as a description of the scope of work, the deliverable Work Breakdown Structure, an Activity List, and estimates for each activity and task. It should also describe when and how the plan should be changed in response to changing conditions. The level of detail associated with the plan(s) is determined by the business analysis approach and the overall methodology.

Note: All tasks in all other knowledge areas have business analysis plans as an implicit input. The plan(s) determine when and how any task is performed.