Plan Business Analysis Approach - Business Analyst


This task describes how to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted regarding and informed of the approach, and the rationale for using it.


Business Analysis Approach Document Example

Business analysis approaches describe the overall process that will be followed to perform business analysis work on a given initiative, how and when tasks will be performed, the techniques that will be used, and the deliverables that should be produced.

There are multiple established ways to approach business analysis work. In software development, they range from those dictated by the waterfall approach to the use of agile techniques. Similarly, there are a number of well - known business process improvement methodologies, including Lean and Six Sigma, as well as many proprietary and in - house methodologies, customs, and practices. Elements from different approaches may be combined; however only a subset of all possible combinations will be viable for the particular organizational environment in which an initiative is being performed.

In order to plan the business analysis approach, the business analyst must understand the organizational process needs and objectives that apply to the initiative. These needs and objectives may include compatibility with other organizational processes, constraints on time - to - market, compliance with regulatory and governance frameworks, the desire to evaluate new approaches to solution development, or other business objectives. If the objectives are not known, the business analyst may be required to define the requirements that the process must meet.

In many cases, organizations will have formal or informal standards in place regarding how business analysis is done and how it fits into project and other activities. If this is the case, the business analyst reviews any existing organizational standards, including standards, guidelines, and processes relating to the current initiative. These may suggest or dictate which approach to use. Even where a standard approach exists, it must be tailored to the needs of a specific initiative. Tailoring may be governed by organizational standards that define which approaches are permitted, which elements of those processes may be tailored, general guidelines for selecting a process, and so forth.

If no standards exist, the business analyst works with the appropriate stakeholders to determine how the work will be completed. The business analyst should be capable of selecting or creating an approach and working with key stakeholders, particularly the project manager and project team, to ensure that it is suitable.

The business analysis approach is often based on or related to the project approach, but in some cases they may be independently determined (for example, an organization may use a plan-driven approach to define its business processes and then use a change-driven approach to build the supporting software applications).


Business Need:The business analysis approach will be shaped by the problem or opportunity faced by the organization. It is generally necessary to consider the risks associated with it, the time frame in which the need must be addressed, and how well the need is understood. This will help determine whether a plan - driven or change - driven approach is appropriate.

Expert Judgment: Used to determine the optimal business analysis approach. Expertise may be provided from a wide range of sources including stakeholders in the initiative, organizational Centers of Competency, consultants, or associations and industry
groups.Prior experiences of the business analyst and other stakeholders should be considered when selecting or modifying an approach.

Organizational Process Assets: Include the elements of existing business analysis approaches in use by the organization. Organizational process assets that may be useful in defining the business analysis approach include methodologies for process change or software development, tools or techniques that are in use or understood by stakeholders, corporate governance standards (such as COBIT™, Sarbanes - Oxley, and Basel II), and templates for deliverables. In addition to these general standards, the organization may have guidelines in place for tailoring the process to fit a specific initiative.


Almost all methodologies fit somewhere along a spectrum between plan-driven and change-driven approaches.

Plan-drivenapproaches focus on minimizing up - front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximize control and minimize risk. These approaches tend to be preferred in situations where requirements can effectively be defined in advance of implementation, the risk of an incorrect implementation is unacceptably high, or when managing stakeholder interactions presents significant challenges. The authority to approve requirements typically rests with selected stakeholders and the project sponsor. The project sponsor will have the final authority to approve solution requirements, but it is common for sponsors to insist that other stakeholders grant their approval before the sponsor will. Waterfall methods of software development and business process re-engineering initiatives are typical examples of plan-driven approaches.

Change - drivenapproaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution. The authority to approve requirements usually rests with a single individual, who is an active participant in the team’s daily activities — others may advise or be informed but may not with hold consent, and the approval process must be completed within a strict time limit. Agile methods of software development, as well as continuous improvement projects, are typical examples of change-driven approaches.

The performance of this task is dependent on where the selected approach falls on this spectrum. The descriptions below touch on the ends of the spectrum, and hybrid approaches may combine aspects of both. Similar considerations must be taken into account whether the business analyst is selecting or tailoring the approach.

1. Timing of Business Analysis Work

Determine when the business analysis efforts should occur, when tasks need to be performed, and if the level of business analysis effort will need to vary over time. This includes determining whether enterprise analysis, requirements analysis, and solution assessment and validation activities will be performed primarily in specific project phases or iteratively over the course of the initiative.

Plan-drivenapproaches have most business analysis work occur at the beginning of the project or during one specific project phase. The exact name of the phase varies by the specific methodology, but the main focus of the phase includes such activities as eliciting, analyzing, documenting, verifying and communicating the requirements, as well as reporting on the status of the business analysis activities work for the project.

Change-drivenapproaches may have a business analysis effort conducted early to produce an initial list of high-level requirements (also referred to as requirements envisioning). This product backlog is then updated throughout the project as new requirements emerge. Throughout the project, these requirements will be prioritized and reprioritized based on the business need. The highest - priority requirements will be taken from the backlog for detailed requirements analysis as resources become available for implementation, and implementation will begin as soon as analysis is complete.

2. Formality And Level Of Detail Of Business Analysis Deliverables

Determine whether requirements will be delivered as formal documentation or through informal communication with stakeholders, and the appropriate level of detail that should be contained in those documents. The expected deliverables must be defined as part of the approach. Requirements Management and Communication for examples of business analysis deliverables.

Plan-drivenapproaches typically call for a significant amount of formality and detail. Requirements are captured in a formal document or set of documents which follow standardized templates. This may be preceded by a number of requirements related documents, built with increasing levels of detail, including a high level vision and scope document that focuses on business requirements, and documents describing the requirements from the point of view of specific stakeholder groups. Relevant stakeholders must generally formally approve each of these documents before work begins on requirements at a lower level of detail. The specific content and format of the requirements documents can vary, depending on the organizational methodologies, processes, and templates.

Change-drivenapproaches favor defining requirements through team interaction and through gathering feedback on a working solution. Mandatory requirements documentation is often limited to a prioritized requirements list. Additional documentation may be created at the discretion of the team and generally consists of models developed to enhance the team’s understanding of a specific problem. An alternative approach is to document the requirements in the form of acceptance criteria accompanied by tests. Formal documentation is often produced after the solution is implemented to facilitate knowledge transfer.

3. Requirements Prioritization

Determine how requirements will be prioritized and how those priorities will be used to define the solution scope. Methods of prioritizing requirements are discussed in Prioritize Requirements . Also see Enterprise Analysis for information on defining the solution scope and Requirements Management and Communication for information on managing the solution scope. Prioritization methods will also be used when performing Allocate Requirements . Change-driven approaches tend to place a great deal of emphasis on effective requirements prioritization methods, due to the small scope of each iteration or release.

4.Change Management

Changes to requirements may occur at any time. Consider the expected likelihood and frequency of change and ensure that the change management process is effective for those levels of change. Effective business analysis practices can significantly reduce the amount of change required in a stable business environment but cannot eliminate it entirely.

Plan-drivenapproaches seek to ensure that changes only occur when they are genuinely necessary and can be clearly justified. Each change is often handled as a “mini project,” complete with requirements elicitation, estimates, design, etc. Changed requirements impact both the solution scope and the project scope and the change management process will be incorporated into the overall project management process.

Many organizations have a formal process which includes a request for change, a change log that tracks the changes that have been received, and an analysis of the impact of the change not only to the project, but also to other business and automated systems.In practice, the number and impact of change requests often increases towards the end of the project. This can be due to any combination of factors, including loosely scoped projects, lack of requirements ownership by project stakeholders, poorly performed business analysis, changing management priorities, business reorganization, regulatory change or changing business requirements.

Change-drivenapproaches presume that it is difficult to identify all requirements in advance of their implementation. There is generally no separate change management process distinct from the selection of requirements for a given iteration. Changes to existing solution capabilities are simply prioritized and selected for an iteration using the same criteria as new features and capabilities.

5. Business Analysis Planning Process

The business analyst must determine the process that will be followed to plan the execution of businesses analysis activities. In most cases, this process will be integrated into a larger project plan.

6. Communication With Stakeholders

Communications may be written or verbal, formal or informal. Decisions must be made at the outset of the project as to the applicability of such communications technologies such as email with regards to project decision-making and approval of deliverables.

Plan-drivenapproaches tend to rely on formal communication methods. Much of the communication of the actual requirements is in writing, and often uses pre-defined forms requiring signatory approvals. All project documentation is normally archived as part of the project history.

Change-drivenapproaches focus more on frequency of communication than on formal documentation. Official documentation is often in writing, but informal communication takes precedence over more formal written communication. Documentation frequently occurs following implementation.

7. Requirements Analysis and Management Tools

The business analyst must identify any requirements analysis or management tools that will be used. These tools may shape the selection of business analysis techniques, notations to be used,and the way that requirements will be packaged.

8. Project Complexity

The complexity of the project, the nature of the deliverables, and the overall risk to the business needs to be taken into consideration. The factors listed below,among others, increase the complexity of business analysis efforts as they increase:

  • number of stakeholders
  • number of business areas affected
  • number of business systems affected
  • amount and nature of risk
  • uniqueness of requirements
  • number of technical resources required

The level of requirements uncertainty is partly dependent on the domain of the project.

For example, new venture, marketing and research projects tend to have a higher requirements uncertainty, while accounting and finance projects tend to have a relatively lower level of requirements uncertainty.

Many organizations have a need for knowledge regarding a solution to be maintained over the long term, because responsibility for the solution may be outsourced, because of turnover within the project team, geographical distribution of participants, or because key personnel are on contract and will not remain available to the organization following implementation. Formal documentation may be required to address these risks.


Decision Analysis:May be used to rate available methodologies against the organizational needs and objectives.

Process Modeling:Process Models can be used to define and document the business analysis approach.

Structured Walkthrough:This can be used as a means of validating a created, selected, or tailored business analysis approach.


Customer, Domain SME, End User or Supplier:The approach taken may depend on their availability and involvement with the initiative.

Implementation SME:The business analysis approach taken should be compatible with the implementation lifecycle used by the implementation team.

Project Manager:The project manager must ensure that the business analysis approach is compatible with other project activities.

Tester:The business analysis approach must facilitate appropriate testing activities.

Regulator:Aspects of the approach or decisions made in the tailoring process may require approval.

Sponsor:The approach taken may depend on their availability and involvement with the initiative. The sponsor may also have needs and objectives that apply to the approach itself.


Business Analysis Approach Template

Business Analysis Approach: This is a definition of the approach that will be taken for business analysis in a given initiative. A business analysis approach may specify team roles, deliverables, analysis techniques, the timing and frequency of stakeholder interactions, and other elements of the business analysis process. A methodology is a formalized and repeatable business analysis approach. It includes a decision about which organizational process assets will be applied and any decisions made regarding tailoring of the process for a specific situation. Documentation regarding the approach may eventually be added to the organization’s repository of process assets.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Business Analyst Topics