An overview of Business Analysis Planning and Monitoring (BAPM) Knowledge Areas from IIBA BABoK version 2.

1. A Guide to the Business Analysis Body of Knowledge (BABoK®) – Knowledge Area
Business Analysis Planning & Monitoring
By – Amjad Shaikh

2. What is Business Analysis
Planning & Monitoring all
about?

4. “The Business Analysis Planning & Monitoring
(BAP&M) knowledge area describes the tasks,
activities and techniques that are required for
successful definition and planning of business
analysis project phase to achieve controlled start”

5. “By failing
to prepare,
you are
preparing
to fail.”
― Benjamin Franklin

6. Enterprise
Analysis
Business Analysis
Planning &
Monitoring
Requirements
Elicitation
Requirements
Analysis
Solution
Assessment &
Validation
Underlying
Competency
Requirements
Management &
Communication
Techniques
Concepts
(BABoK)
BABoK®Version2Release2009

7.  Defining and determining business analysis processes
 Identifying stakeholders
 Defining roles and responsibilities of stakeholders in the
business analysis effort
 Developing estimates for business analysis tasks
 Planning how the business analyst will communicate
with stakeholders
 Planning how requirements will be approached, traced,
and prioritized
 Determining the deliverables that the business analyst
will produce
 Determining the metrics that will be used for
monitoring business analysis work

8. [2.1] Plan Business
Analysis Approach
[2.2] Conduct
Stakeholder Analysis
[2.3] Plan Business
Analysis Activities
[2.4] Plan Business
Analysis
Communication
[2.5] Plan
Requirement
Management Process
[2.6] Monitor Business
Analysis Performance
TasksInputs
Business Need
Enterprise Architect
Organizational
Process Asset
Expert Judgment
Business Analysis
Performance
Metrics
Outputs
[2.1] Business Analysis
Approach
[2.2] Stakeholder list,
roles and responsibilities
[2.3] Business Analysis
Plan
[2.4] Business Analysis
Communication Plan
[2.5] Requirement
Management Plan
[2.6] Business Analysts
Performance Assessment
[2.7] Business Analysis
Process Assets
Tasks Providing
Inputs
5.1
Tasks Using Outputs
2.3 2.5
2.3 2.4 3.1 4.1 6.1
2.4 2.5 2.6
2.6 3.2 4.1 4.2 6.1
2.3
Organizational Process Assets
4.4 4.5
Input sources are
external to BABOK V2
Overview map of Knowledge Area
Refer appendix for overview of BABOK V2 task layout to understand the numbering system

9. TASKS

11. The Purpose of the task
Identify the stakeholders
Describe the overall process for work on a given initiative
How and when tasks will be performed
The techniques used and deliverables produced

12. Layout of the task
 Business Need
 Expert Judgement
 Organisational Process Assets
Input
Plan Business Analysis Approach
Task
 Business Analysis Approach
Output
Techniques
 Decision Analysis  Structured Walkthrough  Process Modelling
Stakeholders
 Customer
 Project Manger
 Regulator
 Sponsor
 Subject Mater Expert
 Tester
 End User

13. Key Elements

14. Plan Driven
Change Driven

15. Impact of Plan Vs Change
on Business Analysis

16. When to perform business analysis?
Plan Driven
Change Driven
 Most BA Work at the
beginning Or during
one specific phase
 Initial list of high-level
requirements
(requirements
envisioning)
 Product backlog updated
throughout project
 Prioritized and
reprioritized
 Highest priority will have
detailed requirements

17. Level of details in the deliverables?
Plan Driven
Change Driven
 Significant amount of
formality and detail
 Formal document/s
 Standard template
 Relevant stakeholders
approve documents
before work starts
 Defining requirements
through team interaction
 Gathering feedback on a
working solution
 Often limited to a prioritized
requirements list
 Additional documentation is
discretionary
 Often produced after
solution is implemented

18. How change is managed?
Plan Driven
Change Driven
 Changes only occur when
they are genuinely
necessary
 Clearly justified
 Mini Project
 Impacts solution and
project scope
 Formal process
 Normally increase near end
of project
 Presume difficult to
identify all requirements
 No separate change
management process
 Changes simply prioritized
as per normal list items

19. When & How to communicate with stakeholders?
Plan Driven
Change Driven
 Rely on formal
communication methods
 In writing and pre-defined
forms
 All documentation normally
archived as project history
 Focus on frequency of
communication
 Less formal
communication takes
precedence
 Official communication in
writing
 Frequently occurs after
implementation

20. Key Techniques
Note: Only covering few technique in this presentation – Planning for complete presentation on techniques

21. Using Decision Analysis for Business Analysis Approach - Example
Business Analysis
Approach
Agile Approach
Waterfall Approach
Change in Requirements
Stable Requirements
Change in Requirements
Stable Requirements
Rework (at least 70%)
Min Rework (10%)
Min Rework (10%)
Waste Deliverables
(10%)
Min Rework (20%)
Waste Deliverables
(10%)Probability – 90%
Probability – 90%
Probability – 10%
Probability – 10%

23. Know people side of change
Identify Stakeholders
Analyze
Stakeholders
Devise Stakeholders
Management Plan
Review/Revise
Stakeholder
Management Strategies
Complete this
during Approach
Definition
Project Inception Phase Project Execution Phase

24. Layout of the task
 Business Need
 Enterprise Architecture
 Organisational Process Assets
Input
Conduct Stakeholder Analysis
Task
 Stakeholder List, Roles, and
Responsibilities
Output
Techniques
 Acceptance and Evaluation
Criteria Definition
 Brainstorming
 Interviews
 Organization Modeling
 RACI Matrix
 Stakeholder Map
 Process Modelling
 Requirements Workshops
 Risk Analysis
 Scenarios and Use Cases
 User Stories
 Scope Modeling
 Survey/Questionnaire
Stakeholders
 Customer
 Project Manger
 Subject Mater Expert
 Regulator
 End User

25. Customer
End User
Sponsor
Implementation SME
Regulator
Business Analyst
Operation Support
Project Manager
Tester
Domain SME
Supplier

26. Categorization of stakeholders
Meet their needs Key player
Least important Show consideration
PowerOfInfluence
Interest
Stakeholder
Stake in the project
Potential impact on Project
What does the Project expect the Stakeholder to provide?
Perceived attitudes and/or risks
Stakeholder Management Strategy
Responsibility
Additional Information that you might want to
capture about each stakeholder

27. Assign responsibilities and accountability – RACI Matrix
Responsible
This is the person or role responsible for creating or
developing the product or performing the task. In Figure,
for example, a business analyst is responsible for creating
the interview notes.
Accountable
This is the person or role who will ‘carry the can’ for the
quality of the product or task. The project sponsor, for
instance, must ultimately be accountable for the
business case for a project.
This is the person or role responsible for creating or
developing the product or performing the task.
In Figure, for example, a business analyst is responsible
for creating the interview notes.
Consulted
These stakeholders are informed about a product or task,
although they may not have contributed directly to it. For
example, the project sponsor has the right to be kept
informed about any of the products created during the
project
Informed

28. Key Elements

29. The points while performing stakeholder analysis
Complexity of Stakeholder Group
Attitude and Influence
Authority Levels For Business Analysis Work

31. The Purpose of the task
Scope of Business Analysis work
Deliverables required
Estimate effort to complete the work by scheduled dates
Identify management tools required to measure progress of work and
deliverables

32. Layout of the task
 Business Analysis Approach
 Stakeholder Lists, Roles and
Responsibilities
 Business Analysis Performance
Assessment
 Organizational Process Assets
Input
Plan Business Analysis Activities
Task
 Business Analysis Plans
Output
Techniques
 Estimation  Functional Decomposition  Risk Analysis
Stakeholders
 Customer
 Project Manger
 Subject Mater Expert
 Regulator
 End User
 Operation Support

33. Key Elements

34. Review following aspect while planning Business Analysis activities
Geographic Distribution of Stakeholders
Type of Project or Initiative
Business Analysis Deliverables

35. Key Techniques
Note: Only covering few technique in this presentation – Planning for complete presentation on techniques

36. Example of Functional Decomposition
Define Detail Requirements
Elicit Requirements
Conduct Workshop
Document Requirements
Business Process Maps
Create FSDDefine NFR
Prioritize Requirements
Conduct JAD Session
Define Usecase

38. The Purpose of the task
What needs to be communicated?
When the communication should occur?
Who is the appropriate audience?
How message will be delivered?

39. Layout of the task
 Business Analysis Approach
 Business Analysis Plan
 Organizational Process Assets
 Stakeholders List, Role and
Responsibilities
Input
Plan Business Analysis
Communication
Task
 Communication Plan
Output
Techniques
 Prepare Requirements Package
 Communicating Requirements
(Skill)
 Structured Walk Through
Stakeholders
 Customer
 Project Manger
 Tester
 Subject Mater Expert
 Regulator
 End User
 Operation Support

40. Key Techniques
Note: Only covering few technique in this presentation – Planning for complete presentation on techniques

41. Create packages based on the need, project type & audience
Executive/ Non-Technical End User
Developer/ Testers
 Presentation
 Prototype
 Business Process
 High-level Usecase
 Detail Usecase
 Workflows
 UML Diagrams
 Data Models
 Presentation
 Prototype
 Functional Usecase
 UAT Test cases/ Scenarios
Only an example

43. The Purpose of the task
Determine the appropriate requirements process
Determining whether and how requirements are changed
Determine what attributes to be captured for requirement
Determine tracking mechanism for requirements

44. Layout of the task
 Business Analysis Approach
 Business Analysis Plan
 Organizational Process Assets
Input
Plan Requirements Management
Process
Task
 Requirements Management Plan
Output
Techniques
 Decision Analysis  Risk Analysis  Problem Tracking
Stakeholders
 Customer
 Project Manger
 Tester
 Subject Mater Expert
 Regulator
 End User
 Operation Support

45. Key Elements

46. Elements to consider when planning requirements management
Repository of requirements
Traceability
Select requirements attributes for capturing process
Requirements prioritization methods/ process
Change management process

47. Key Considerations
Note: Only covering few technique in this presentation – Planning for complete presentation on techniques

48. Key considerations
Process for requirements change
Assess need for requirements traceability
Requirements Attributes

49. Example
Requirement
Identifier
Date Captured/ Stated
Source of Requirement
StatusDependencies
Priority
Category
Author
Updated By/Date

50. This is how requirements
looks like when in
requirements management
tool (RTM)
Requirements
repository within
RTM
Requirements
attributes

52. The Purpose of the task
Determine metrics for business analysis performance measure
Identify performance issue and plan corrective actions
Business analysis process & performance improvement

53. Layout of the task
 Business Analysis
 Performance Metrics
 Business Analysis Plan(s)
 Organizational Performance Standards
 Requirements Management Plan
Input
Business Analysis Planning &
Monitoring
Task
Business Analysis Performance
Assessment
 Business Analysis Process Assets
Output
Techniques
 Interviews
 Lessons Learned
 Metrics & Key Performance
Indicator
 Process Modelling
 Root Cause Analysis
 Survey & Questionnaire
 Problem Tracking
 Variance Analysis
Stakeholders
 Customer
 Project Manger
 Subject Mater Expert
 Regulator
 End User

54. Metrics for measuring business analysis performance

55. Knowledge area summary
• Stakeholders, Types
of requirements,
Organization’s
standards formality
Identify
• Stakeholder roles
and responsibilities
Define • Estimates to
complete required
business analysis
tasks
Develop
• Stakeholder
communication
• How requirements
will be approached,
traced and prioritized
Plan

58. BABoK®Version2Release2009
BABOK V2 - Business Analysis Knowledge Areas & Tasks Layout
[2] Business Analysis
Planning & Monitoring
[3] Elicitation
[4] Requirements
Management &
Communication
[5] Enterprise Analysis
[6] Requirement
Analysis
[7] Solution
Assessment &
Validation
[2.1] Plan Business
Analysis Approach
[3.1] Prepare for
Elicitation
[4.1] Manage Solution
Scope and Requirements
[5.1] Define Business Need
[6.1] Prioritize
Requirements
[7.1] Assess Proposed
Solution
[2.2] Conduct Stakeholder
Analysis
[3.2] Conduct Elicitation
Activity
[4.2] Manage
Requirement Traceability
[5.2] Assess Capability Gap
[6.2] Organize
Requirements
[7.2] Allocate
Requirements
[2.3] Plan Business
Analysis Activities
[3.3] Document Elicitation
Results
[4.3] Maintain
Requirement for Re
[5.3] Determine Solution
Approach
[6.3] Specify and Model
Requirements
[7.3] Assess Organization
Readiness
[2.4] Plan Business
Analysis Communication
[4.4] Prepare Requirement
Package
[5.4] Define Solution Scope
[6.4] Define Assumptions
& Constraints
[7.4] Define Transition
Requirements
[2.5] Plan Requirement
Management Process
[4.5] Communicate
Requirements
[5.5] Define Business Case [6.5] Verify Requirements [7.5] Validate Solution
[2.6] Manage Business
Analysis Performance
[6.6] Validate
Requirements
[7.6] Evaluate Solution
Performance
[3.4] Confirm Elicitation
Results