IIBA Memphis Study Group - Chapter 2 BA Planning and Monitoring v3

1

International Institute of Business Analysis

Chapter 2

Business Analysis

Planning and Monitoring

Purpose:

- Specify how the business analysis tasks will be performed

- Identify the deliverables to be produced

- 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

Greater Memphis Chapter 2

Business Analysis Planning and Monitoring


IIBA Operational VisionBusiness Analysis Planning and MonitoringInputs and Outputs


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.


2.1 Plan the Business Analysis Approach

2.2.3 Inputs



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



2.1.5 Techniques Decision Analysis Process Modeling Structured Walkthrough



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


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.



2.2 Inputs



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



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



2.2.5 Example Stakeholder Matrix



2.2.5 Example Stakeholder Diagram



2.2.6 Stakeholders Domain SME Implementation SME Project Manager Tester Regulator Sponsor



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


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.



2.3 Inputs



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



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



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


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.



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).

2.4.2 Continued…



2.4.3 - Inputs



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.

2.4.4 - Elements



Prepare Requirements Package (4.4) Communicate Requirements (4.5) Communication Skills (8.4)

Structured Walkthrough (9.30)

2.4.5 - Techniques



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.


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.



2.5.3 - Input



•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.



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

2.5.4 – Elements Continued



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



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.

2.5.7 Output


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.



2.6.3 - Input



Performance Measures Performance Reporting Preventative and Corrective Action

2.6.4 - Elements



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

2.6.5 - Techniques


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


Plan Requirements Management Process

Questions?

IIBA Memphis Study Group - Chapter 2 BA Planning and Monitoring v3

Documents