International Institute of Business Analysis

Purpose:
- Specify how the business analysis tasks will be performed - Identify the deliverables to be produced

Chapter 2 Business Analysis

- Describe how changes will be controlled & managed

Value:
- Specifies tools, resources and contributors & ensures availability - Allows for monitoring & addressing of requirements challenges - Coordinates with other project work

Planning and Monitoring

Business Analysis Planning and Monitoring

Greater Memphis Chapter

Business Analysis Planning and Monitoring IIBA Operational Vision Inputs and Outputs

Greater Memphis Chapter

2.1 Plan Business Analysis Approach

2.1.1 Purpose: 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. 2.2.2 Description: 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.

Greater Memphis Chapter

2.1 Plan the Business Analysis Approach

2.2.3 Inputs

Greater Memphis Chapter

2.1 Plan the Business Analysis Approach

2.1.4 Elements
Timing of BA Work Formality and Level of Detail of BA Deliverables Requirements Prioritization Change Management BA Planning Process Communication With Stakeholders Requirements Analysis and Management Tools Project Complexity

Greater Memphis Chapter

2.1 Plan the Business Analysis Approach

2.1.5 Techniques
Decision Analysis Process Modeling Structured Walkthrough

Greater Memphis Chapter

2.1 Plan the Business Analysis Approach

2.1.6 - Stakeholders
Customer, Domain SME, End User or Supplier Implementation SME Project Manager Tester Regulator Sponsor

2.1.7 - Output
Business Analysis Approach

Greater Memphis Chapter

2.2 Conduct Stakeholder Analysis

2.2.1 Purpose: This task covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. 2.2.2 Description: Stakeholder analysis is performed as soon as a business need is identified and will usually be an ongoing activity as long as business analysis continues. Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. Stakeholders may be grouped into categories that reflect their involvement or interest in the initiative.

Greater Memphis Chapter

2.2 Conduct Stakeholder Analysis

2.2 Inputs

Greater Memphis Chapter

10

2.2 Conduct Stakeholder Analysis

2.2.4 Elements
Identification Complexity of Stakeholder Group Attitude and Influence Authority Levels for Business Analysis Work

Greater Memphis Chapter

11

2.2 Conduct Stakeholder Analysis

2.2.5 Techniques
General Techniques
Acceptance and Evaluation Criteria Definition (9.1) Brainstorming (9.3) Interviews (9.14) Organizational Modeling (9.19) Process Modeling (9.21) Requirements Workshop (9.23) Risk Analysis (9.24) Scenarios and Use Cases (9.26), User Stories (9.33) Scope Modeling (9.27) Survey/Questionnaire (9.31)

RACI Matrix Stakeholder Map

Greater Memphis Chapter

12

2.2 Conduct Stakeholder Analysis

2.2.5 Example Stakeholder Matrix

Greater Memphis Chapter

13

2.2 Conduct Stakeholder Analysis

2.2.5 Example Stakeholder Diagram

Greater Memphis Chapter

14

2.2 Conduct Stakeholder Analysis

2.2.6 Stakeholders
Domain SME Implementation SME Project Manager Tester Regulator Sponsor

Greater Memphis Chapter

15

2.2 Conduct Stakeholder Analysis

2.2.7 Output
List of required roles Names and titles of stakeholders Category of stakeholder Location of stakeholders Special needs Number of individuals in this stakeholder role Description of stakeholder influence and interest Documentation of stakeholder authority levels

Greater Memphis Chapter

16

2.3 Plan Business Analysis Activities

2.3.1 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. 2.3.2 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.

Greater Memphis Chapter

17

2.3 Plan Business Analysis Activities

2.3 Inputs

Greater Memphis Chapter

18

2.3 Plan Business Analysis Activities

2.3.4 Elements
Geographic Distribution of Stakeholders
Collocated vs Dispersed

Type of Project or Initiative

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

Business Analysis Deliverables Determine Business Analysis Activities

Greater Memphis Chapter

19

2.3 Plan Business Analysis Activities

2.3.5 Techniques
Estimation (9.10) Functional Decomposition (9.12) Risk Analysis (9.24)

Greater Memphis Chapter

20

2.3 Plan Business Analysis Activities

2.3.6 Stakeholders
Customer, Domain SME, End User, and Supplier Implementation SME Operational Support Project Manager Tester Sponsor

2.3.7 Output
Business Analysis Plans

Greater Memphis Chapter

21

2.4 Plan Business Analysis Communication

2.4.1 Purpose: 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. 2.4.2 Description: 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.

Greater Memphis Chapter

22

2.4 Plan Business Analysis Communication

2.4.2 Continued
Considerations for a Business Analysis Communication Plan:
what needs to be communicated what is the appropriate delivery method who is the appropriate audience and when the communication should occur. Time and resource availability constraints. Physical location/time zone of the stakeholders. Communication approach for the stakeholder. What types of communications will be required (e.g. status, anomalies, issues and their resolution, risks, meeting results, action items, etc.) What types of requirements will be elicited (business, stakeholder, solution, or transition; high level vs. detailed) and how best to elicit them (see the Elicitation KA for options) How best to communicate requirements conclusions/packages, including authority level (signoff authority, veto authority, or review only).

Greater Memphis Chapter

23

2.4 Plan Business Analysis Communication

2.4.3 - Inputs

Greater Memphis Chapter

24

2.4 Plan Business Analysis Communication 2.4.4 - Elements

Geography Culture
Relationship to time. Relationship to task completion Relationship to contracts Relationship to formal and informal authority.

Project Type

A new, customized in-house software development project. (all requirements) Upgrading the technology or infrastructure of a current system. (technical requirements) Change in a business process or new data for an existing application. (process and data requirements, business rules, functional and technical requirements ) Purchase of a software package. (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 (very little formal requirements documentation)

Communication Frequency Communication Formality (more formal when)

The project is unusually large The domain involved is very complex The technology employed, if any, will be new The project is considered to be mission critical The executive sponsor and/or key stakeholders require formality The requirements are likely to be subject to regulatory review The requirements will be presented to suppliers in an RFQ/RFI/RFP.

Greater Memphis Chapter

25

2.4 Plan Business Analysis Communication 2.4.5 - Techniques

Prepare Requirements Package (4.4) Communicate Requirements (4.5) Communication Skills (8.4)
Structured Walkthrough (9.30)

Greater Memphis Chapter

26

2.4 Plan Business Analysis Communication

2.4.6 Stakeholders:
Customer and Supplier Domain SME (influence over the approvers) End User (considerable influence) Implementation SME Operational Support (requirements to support the solution) Project Manager Tester Regulator Sponsor

2.4.7 Output:
The stakeholder communications requirements for business analysis activities Format, content, medium, level of detail. Responsibility for collecting, distributing, accessing, and updating information.

Greater Memphis Chapter

27

2.5 Plan Requirements Management Process

2.5.1 Purpose: Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope. 2.5.2 Description: This task determines the appropriate requirements management process for a particular initiative. It includes determining the process for requirements change, which stakeholders need to approve change, who will be consulted or informed of changes, and by extension, who does not need to be involved. The task also includes assessing the need for requirements traceability and determining which requirements attributes will be captured.

Greater Memphis Chapter

28

2.5 Plan Requirements Management Process

2.5.3 - Input

Greater Memphis Chapter

29

2.5 Plan Requirements Management Process

2.5.4 Elements
Repository Traceability Select Requirement Attributes Absolute reference Author of the requirement Complexity Ownership Priority Risks Source of the requirement Stability Status Urgency Additionally cost, resource assignment, and revision number, traced-from and traced-to Requirement Prioritization Process Formality Establishing The Process And Technique Plan The Participation.

Greater Memphis Chapter

30

2.5 Plan Requirements Management Process

2.5.4 Elements Continued
Change Management
Determine the process for requesting changes Determine who will authorize changes Impact Analysis Plan the wording of the request
Cost and time estimates of change Benefits and risks of the change Recommended course of action for change Coordinate Prioritization Of Change. (note Change Driven Methodologies do no typically have a change control process that is separate from the requirements prioritization process.

Tailoring the Requirements Management Process

Organizational culture Stakeholder Preferences Complexity of project, project phase or product being delivered Organizational maturity Availability of Resources

Greater Memphis Chapter

31

2.5 Plan Requirements Management Process

2.5.5 Techniques:
Decision Analysis (9.8) Problem Tracking (9.20) Risk Analysis (9.24)

2.5.6 Stakeholders:
Domain SME End User Implementation SME Operational Support Project Manager Tester Sponsor

Greater Memphis Chapter

32

2.5 Plan Requirements Management Process

2.5.7 Output
Requirements Management Plan:
Approach to be taken to structure traceability Definition of requirements attributes to be used. Requirements prioritization process. Requirements change process, including how changes will be requested, analyzed, approved and implemented.

Greater Memphis Chapter

33

2.6 Manage Business Analysis Performance

2.6.1 Purpose: To manage the performance of business analysis activities to ensure that they are executed as effectively as possible. 2.6.2 Description: This task covers determining which metrics will be used to measure the work performed by the business analyst. It includes how to track, assess, and report on the quality of the work and take steps to correct any problems that may arise. This may feed into the development of future business analysis plans. The selected metrics are defined and described in the organizational process assets or the business analysis plans.

Greater Memphis Chapter

34

2.6 Manage Business Analysis Performance

2.6.3 - Input

Greater Memphis Chapter

35

2.6 Manage Business Analysis Performance 2.6.4 - Elements

Performance Measures Performance Reporting Preventative and Corrective Action

Greater Memphis Chapter

36

2.6 Manage Business Analysis Performance

2.6.5 - Techniques
General Techniques Interviews (9.14) Lessons Learned Process (9.15) Metrics and Key Performance Indicators (9.16) Problem Tracking (9.20) Process Modeling (9.21) Root Cause Analysis (9.25) Survey/Questionnaire (9.31) Variance Analysis
Greater Memphis Chapter

37

Manage Business Analysis Performance

2.6.6 Stakeholders:
Domain SME and End User (should be informed) Implementation SME, Operation Support and Tester (dependent on the effect performance of BA activities to perform the role, should be consulted) Project Manager (accountable for the success of project must be kept information) Sponsor (reports on BA performance)

2.6.7 Output:
Business Analysis Performance Assessment Business Analysis Process Assets

Greater Memphis Chapter

38

Plan Requirements Management Process

Questions?

Greater Memphis Chapter

39