BA Activities Plan

Comments (Include when, how and with No. of

Requirements Activity In/Out Start date End date Est. hours
whom) Sessions
BA PLANNING
Create Business Analysis Plan
Plan BA Approach
Plan Stakeholder Engagement
Plan BA Governance
Plan BA Information Management
Identify BA Performance Improvements
STRATEGY ANALYSIS
Analyze current state
Analyze future state
Assess risks/challenges in moving to future
Define change strategy (gap analysis, provide
recommendations, etc.)
ELICITATION
Interviews
Requirements workshop
Focus Group
Survey
Observation
Document analysis
Interface analysis
Prototyping
Research
Brainstorming / Mind mapping
REQ. ANALYSIS & DESIGN DEFINITION
Analyze & document req.
Business models
- Business architecture
- Organizational models
- Geographical models
- Value Stream maps
- Value chain/cross-functional models
- Context diagrams
- Functional decomposition diagrams
Data Models
- Class models
Process models
- SIPOC charts
- Process maps
- Swimlanes
- Data flow diagrams (DFD)
- Use case model
- Activity diagrams
Others
- CRUD matrix
- Prototypes/mock-ups
- State transition diagrams
- Sequence diagrams
- Storyboards
- User stories
Verify & validate requirements
Define req. architecture
Define design options
Analyze potential value & recommend solution
REQ. LIFECYCLE MANAGEMENT
Communicate requirements
Trace requirements
Prioritize requirements
Conduct reviews & obtain approvals
Analyze change requests
Manage documentation
BA PERFORMANCE EVALUATION
Measure & analyze BA performance measures
SOLUTION EVALUATION (Pre/Post Project)
Measure solution performance
define performance measures and use the data
collected to evaluate the effectiveness of a solution
in relation to the value it brings
Analyze performance measures
provide insights into the performance of a solution
in relation to the value it brings
Assess solution limitations
determine the factors internal to the solution that
restrict the full realization of value
Assess organizational limitations
determine how factors external to the solution are
restricting value realization
Recommend actions to increase solution
value
Increase Solution Value is to understand the factors
that create differences between potential value and
actual value, and to recommend a course of action
to align them
REQUIREMENTS TRACEABILITY MATRIX REQUIREMENTS TRACEABILITY MATRIX Instructions For Completing This Document
Project Name: <optional> Project Name: <optional> 1.) Complete the Project Name, C/I/O, Project Manager Name, and Project Description fields
Project Manager Name: <required> Project Manager Name: <required> 2.) For each issue identified, complete the following:
Project Description: <required> Project Description: <required> ID: A unique ID number used to identify the traceability item in the requirements traceability matrix.
Technical Associated ID(s): This column should contain the ID of any associated utilities used for requirements tracking
Assumption(s) such as a repository, pipeline document, etc.
and/or
Assoc Customer Functional System Software Test Case Implemented Additional
ID ID Need(s) Requirement Status Component(s) Module(s) Number Tested In In Verification Comments
Technical Assumption(s) or Customer Need(s): This column should be populated with a description of the
technical assumption or customer need linked to the functional requirement.
001 1.1.1 Module 1
Functional Requirement: This column should be populated with a description of the functional requirement.
002 2.2.2
Status: This column should be populated with the current status of the functional requirement.
003 3.3.3
Architectural/Design Document: This column should be populated with a description of the
architectural/design document linked to the functional requirement.
004 4.4.4
Technical Specification: This column should be populated with a description of the technical specification
linked to the functional requirement.
005 5.5.5
System Component(s): This column should be populated with a description of the system component(s) linked
to the functional requirement.
006
Software Module(s): This column should be populated with a description of the software module(s) linked to the
functional requirement.
007
Test Case Number: This column should be populated with the test case number linked to the functional
requirement.
008
Tested In: This column should be populated with the module that the functional requirement has been tested in.
009
Implemented In: This column should be populated with the module that the functional requirement has been
implemented in.
010
Verification: This column should be populated with a description of the verification document linked to the
functional requirement.
011
Additional Comments: This column should be populated with any additional comments
012

013

014

015

016

017

018

019

020

021

022

023

024

025

026

027

028

029

030

031

032

033

034
 Planning inputs

Inputs Reviewed Y/N Comments / Observations / Notes

Business Information
Business Case
Organization Chart
Organizational processes & templates for BA work
Project Information
Existing project documents:
Project charter
Scope statement
Preliminary Project Plan
Preliminary Stakeholder List
Additional Documents
Existing Training Materials
Existing Models
Existing User Documentation
Others??
 Plan Business Analysis Approach

Level of Effort
Task Name Resource Start date End date Note Approach options BA approach Project approach Impacts to BA planning and work effort
(hours)
Waterfall
Agile
Iterative
Lean/Six Figma
 Plan Stakeholder Engagement Section B: Stakeholder Engagement Plan
RASCI Matrix
R = Responsibility (Who does the work?) C = Consults with (Who do we need to consult and get input from?)
A = Accountable (Who approves, makes the decision, signs off?)I = Inform (Who do we need to inform after the work is done?)
S = Support (Who supports the business analyst in doing the work)
Task Name Resource Start date End date
Level of Effort
Note
Authority
(hours) R A S C I
Responsible Accountable/ Approve Support Consult With Inform
Role

Stakeholder Register

Expectations Influence
Stakeholder Project Impact Commitment
/Concerns (if any) Rating Remarks
Group Role(s) Rating Level

Project owner Project owner

Supplies Section
IT Staff IT project team
Section Heads User representatives
Section users User representatives

Stakeholder Collaboration Plan Stakeholder Contact List

Capture the key collaboration events for your stakeholders. Include their preferences for collaboration, events, frequency, location,
Categories Y/N
tools and mediums. A collaboration event may be conducted for an individual or a group of stakeholders. Name Group Representing Phone Email Category
Stakeholder Tools (wikis, Medium (in-
Stakeholder(s)
Name or Event Frequency Location blogs, online person or
Preferences
Group communities) virtual) Geographical locations
Primary / secondary source of
requirements
Number of user represented
Number of processes
represented
Number of systems impacted
Technology skill level
Level of influence
Level of acceptance
Authority levels
Group represented
Departments / Entities
Internal / External
Language
Stakeholder communication plan Time Zones
Capture the key communication events for your stakeholders. Include meetings, requirements sessions, requirements reviews, prioritization
sessions, requirement activity status, etc. Experienced User
Communication Event Audience Objective Media/Format Frequency
 Requirement Risk Categories

Risk Score (P
# Risk Category Risk Event / Consequence Prob. Impact Risk Rank Risk Response Risk Response Strategy Risk Owner Category Examples
* I)
Planning & - Little or no requirements planning done Requirements plan does not sync up
RR1 Monitoring - Stakeholders not identified with project plan
- Unclear scope
Scope Not clear on what is in and out of scope
- Scope not well documented
- Inadequate user involvement
Elicitation Time pressure – not enough time
- Requirements are not complete
- Different interpretations
Documentatio - Includes design elements
- Ambiguous terminology
n - Missing requirements
- Not enough detail
- Customers disagree on prioritization
- Conflicting requirements
- Level of difficulty implementing the req.
Analysis - Degree of requirements stability
- New technology, software, etc.
- Little or no modeling done
- No as-is models to leverage
- Untestable requirements
- Requirements not signed off Requirement not linked/traced to
Validation - Un-reviewed requirements business problem, project objective or
- Requirements are not verified (not complete business objective
enough to allow design to begin)
- Scope creep
- Requirements are not traced
- Expanding product (requirements) scope
Management throughout the project
- Change process not created or used
- Requirements were not baselined
- Expanding project scope
 BA Governance Plan
Determine how decisions will be made, work and requirements prioritized, change process, & approval process

Process Exists?
Activity (Y/N/Needs Action Plan
Modification)
Prioritization process (with
criteria and technique used)
Change management process
(include who will authorize
changes)
Decision making process
(include participants, review
and approve)
Escalation plan for decision
making
Requirements review and
approval process
Issues management process
 BA Information Management Plan
Determine how you are going to manage the business analysis information. The formality of this management plan will depend on the project approach selected (predictive vs adaptive or somewhere in between).

Activity Due Date Action Plan

General BA Information Management
Determine organization of BA information
Identify storage and access needs to
documentation (repository, version
control, audit logs, etc.)
Define formality and level of detail
needed by stakeholders
Requirements Management
Define requirement attributes and
elements
Develop a traceability matrix
Identify requirements reuse opportunities
 BA Peformance Evaluation Plan

Who will
Measure / Acceptance Unacceptable Recipient (s) of metric Measurement
Metric Source of data capture the
Techniques Criteria Criteria information Frequency
info
Actual vs. Planned Business % deviation Time Sheets & BA
Analysis Hours from plan 0-5% > 5% Plan BA PM Weekly
 Solution Performance Evaluation Plan

Unaccept Who will Recipient (s) of

Acceptance
Metric Measure / Techniques able Source of data capture the metric Measurement Frequency
Criteria info information
Criteria
Number of errors found in Number of errors logged Error reporting by First 3 months after
production by the help desk 0-5 >5 the Help Desk BA Solution Owner implementation
 Issue Log
Capture any outstanding issues that need to be addressed before this plan is complete.

Item / Issue Assigned To: Date Raised Date Resolved Action Taken
 Issue Log
Capture the assumptions that went into your plan & determine the impact on any decisions, requirements, or plans that were made based on that assumption

Assumption Impact on decisions, requirements or plans

Y High <Notes:
N Medium 1. Stakeholder Group: an individual or a group of individuals who is/are either
Needs modification
Low involved in or affected by the project, e.g. the Project Owner, User Group, etc.
2. Project Role: the role that a stakeholder group plays in the project, e.g. the Project
Owner, Users, etc.
3. Expectations: describes the needs of the stakeholder group.
4. Concerns: describes the concerns or objections expected from the stakeholder
group.
In 5. Influence Rating: rates the degree of influence that the stakeholder group has on
Out the direction of the project and it is categorised as High, Medium or Low.
6. Impact Rating: rates the degree of the project’s impact to the stakeholder group
and it is categorised as High, Medium or Low.
7. Commitment Level: rates the level of involvement (commitment) of the stakeholder
group at different project phases. The commitment level is suggested to be
classified individually in the 3 major phases of the SDLC (i.e. Fund Request, SA&D
& Implementation) instead of the entire project life cycle.
8. Aware: stakeholders are aware of the scope and objectives of the project.
9. Understand: stakeholders understand the impacts (e.g. anticipated benefits,
project schedule and the changes in the future state) to the organisation and their
functional areas.
10. Adoption: stakeholders are participating in project activities (e.g. providing
general inputs to user representatives) and are acquiring the skills necessary for
the change.
11. Buy-in: stakeholders are willing to work with and implement changes brought by
the project and are ready to acquire the skills to adapt to those changes. They may
have the responsibility to provide part of the requirements and testing in the project
because they should be the one who will use the output of the project intensively.
12. Ownership: stakeholders make the decision and change their own. They have
high influence to ensure the project is successful and the high impact from the
project. In general, Project Owner and PSC are highly committed to the project.
13. Remarks: provides additional information useful in handling communications
needs of the stakeholder group.>