The scope of the business analysis work comes from the business analysis deliverables and becomes part of the overall project scope. The business analyst, in defining the business analysis scope or work, works closely with the project manager to ensure that the approved business analysis work is included in the overall project scope.
An important tool in both defining the scope of work as well as in developing estimates is the work breakdown structure (WBS). There are different ways to break work down. One is to break down the project into iterations, releases, or phases. Another is to break deliverables into work packages. Another is to break activities into tasks. Both the breakdown of deliverables and activities requires use of the technique of decomposition, where larger pieces or work are broken into subsequently smaller and smaller pieces, creating a hierarchy of work.
The BA, to be in alignment with the project management plan, can use these same tools and techniques not only in defining the business analysis scope, but also in estimating business analysis activities.
Some considerations when developing both the scope of work and activities include:
The requirements approach
Each of the requirements approaches will define the requirements process in different ways and will have very significant impacts on the business analyst’s planning efforts. Each will offer descriptions of the project phases, deliverables, and tasks that should be included in the project and will greatly impact the requirements plan.
For example, the traditional waterfall method advocates gathering all requirements in the beginning of the project; while in the Iterative/Agile approaches requirements may be defined throughout the lifecycle. These differences will lead to different deliverables and tasks being identified as well as different sequences and dependencies of tasks.
Examples of common requirements approaches include:
- Waterfall
- Incremental
- Agile
Specific stakeholder preferences
Typically some stakeholders will exhibit individual behaviors and preferences and that must be met in order to have a successful project. 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.
If these can be identified and factored into the business analysis planning process, the project has a better chance of success.
Location: The Business Analyst must also consider the location of the 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.
Collocated: All key stakeholders are located in the same local geographic area. There are no special location-related planning considerations for the BA 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 analysis to identify and account for these differences.
An example of the impact of this type of situation might be the necessity to have more tele- or video conferences rather than face to face meetings, due to the various locations and the difficulty in scheduling. Or the organization’s desire to have at least one face-to- face and the complexity of arranging such a meeting could result in additional tasks and schedule lags (delays).
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, more frequent review sessions or more detailed documentation.
The type of project or project phase to which the Business Analyst is assigned may have a significant impact on the estimating process. For example, in a project to purchase a new software package, the tasks will be different from an effort to develop a new package. Different projects with different deliverable and tasks might include some combination of the following:
- Feasibility study
- Process improvement
- Organizational change
- New software development (in-house)
- Outsourced new software development
- Software maintenance
- Software package selection
The differences in the business analysis planning activities in these different types of projects will be significant; since the purpose of, objectives and tasks involved in the business analysis work will be quite different.
