The fundamental goal when planning the business analysis activities is to develop a brief and clear set of steps or tasks that lead to the implementation of a well-accepted solution. The Plan Business Analysis Activities task includes the following general activities:
By Identifying the BA deliverables.
By determining the scope of work for the BA effort.
By determining the activities that will be carried out by the business analyst.
By developing the estimates for the BA work.
By which activities and how they are executed will determine the business analysis deliverables quality and timeliness.
When completed, this task will produce the Business Analysis Plan which includes a detailed list of all the activities including the resources needed (a work breakdown structure is one way of presenting this list) and a description or diagram presenting the logical dependencies among the activities.
In developing Business Analysis Plans, the BA will use previously collected information from other tasks:
BA Approach – information on the SDLC, deliverables, templates, and tasks that should be included
BA Performance Assessment – information on metrics and assessment of the BA effort
Stakeholder List (including stakeholder roles and responsibilities) – information on individual stakeholders’ behaviors and preferences.
In addition, the organization or a regulatory body might mandate specific deliverables. This comes under the umbrella of Organizational Process Assets.
In planning the activities to be carried out, particular elements will influence the types of activities and how they’ll be performed:
Geographic Distribution of Stakeholders, i.e., whether stakeholders are co-located or dispersed will affect the complexity of the project and impact the estimate of activities.
Type of Project or Initiative. The type of project or initiative will influence the business analysis activities being planned (i.e., a new software development project and a process improvement project have different characteristics and will have a different set of activities).
Business Analysis Deliverables. Deliverables in the Requirements Package will vary according to the initiative in question.
Determine Business Analysis Activities. Typical activity lists are in the WBS. WBS defines scope of work to help with estimation within a hierarchy, decomposing activities and tasks to a greater detail (e.g., work packages). Create a WBS list by decomposing the project by deliverable, dividing the project into phases or iterations, or by using a previous similar project as an outline for current project.
Even though the business analyst has a list – perhaps even a very detailed list – of requirements activities, he still needs to estimate the scope of each activity, the resources needed, and the time that will be required to carry each activity out.
First, the business analyst can divide the entire requirements process into a collection of milestones, which mark significant events or accomplishments in the execution of a project. Having a project charter signed is an obvious example of a milestone. Delivering a product to the customer for acceptance testing is another.
Next, the analyst must identify individual work units, which consist of very specific tasks or activities that have a clearly identifiable “product” or end result (which usually feeds into another work unit). Some people define work units as tasks that cannot be decomposed into smaller tasks. Others define work units as activities that have a finite duration with a minimum length. (In other words, you don’t want to break down a task into such small pieces as to be ridiculous!). Obviously, judgment and experience are important.