PMI-PBA® (PMI Professional in Business Analysis)

Course Structure
• Module 1 – Introduc/on to PMI-PBA
• Module 2 – Introduc/on to Business Analysis
• Module 3 – Defining and Aligning Process Group
• Module 4 – Ini/a/ng Process Group
• Module 5 – Planning Process Group
• Module 6 – Execu/ng Process Group
• Module 7 – Monitoring and Controlling Process Group
• Module 8 – Releasing Process Group
• Module 9 – Prac/ce Guide for Business Analysis Prac//oner

2
Module 4

Ini:a:ng Process Group

3
Business Analysis Knowledge Area and Process Groups

Process Group Defining and Ini:a:ng Planning Execu:ng Monitoring and Releasing
& Knowledge Aligning Process Process Process Controlling Process
Area Process Group Group Group Group Process Group Group
Needs
6 1 7
Assessment
Stakeholder
1 3 1 2 7
Engagement
Elicita:on 1 3 4
Analysis 1 8 9
Traceability
and 1 2 1 4
Monitoring
Solu:on
1 1 1 1 4
Evalua:on

8 1 7 15 3 1 35

4
Ini:a:ng Process Group - Knowledge Area and Processes

Knowledge Needs Stakeholder Elicita:on (0) Analysis (0) Traceability Solu:on

Area Assessment (1) Engagement and Evalua:on (0)
(0) Monitoring (0)
Ini:a:ng Support Charter
Process Group Development
(1)

5
Ini:a:ng processes in Needs Assessment

Needs Assessment

6
Support Charter Development

Inputs Tools and Techniques Outputs

Business case Document analysis Charter
Product scope Facilitated workshops Shared product informa/on
Glossary
Interviews
Root cause and opportunity
analysis

7
Charter

Development of charter should be collabora/ve effort

Informa/on that is commonly part of charter includes;
• Descrip/on and purpose
• Business goals and objec/ves
• High level product and porVolio, program or project scope
• Risks
• Summary milestone schedule
• Summary budget informa/on
• High level dependencies
• Success criteria
• Informa/on about external and internal par/es

8
Summary

Needs Assessment
• Support Charter Development

9
Module 4

Ini:a:ng Process Group

10
Module 5

Planning Process Group

11
Business Analysis Knowledge Area and Process Groups

Process Group Defining and Ini:a:ng Planning Execu:ng Monitoring and Releasing
& Knowledge Aligning Process Process Process Controlling Process
Area Process Group Group Group Group Process Group Group
Needs
6 1 7
Assessment
Stakeholder
1 3 1 2 7
Engagement
Elicita:on 1 3 4
Analysis 1 8 9
Traceability
and 1 2 1 4
Monitoring
Solu:on
1 1 1 1 4
Evalua:on

8 1 7 15 3 1 35

12
Planning Process Group - Knowledge Area and Processes

Knowledge Needs Stakeholder Elicita:on (1) Analysis (1) Traceability Solu:on

Area Assessment (0) Engagement and Evalua:on (1)
(3) Monitoring (1)
Planning Conduct Determine Determine Determine Determine
Process Group Stakeholder Elicita/on Analysis Traceability and Solu/on
(7) Analysis Approach Approach Monitoring Evalua/on
Approach Approach
Determine
Stakeholder
Engagement and
Communica/on
Approach
Conduct Business
Analysis Planning

13
Planning processes in Stakeholder Engagement

Stakeholder Engagement

14
Conduct Stakeholder Analysis

Stakeholder Analysis is o[en conducted during the planning phase so that the project team can understand
the stakeholder impacts and influences on the business analysis process as early as possible.
• A technique of systema/cally gathering and analysing informa/on to determine whose interests should
be taken into account throughout the project.
• Iden/fy all poten/al project stakeholders and relevant informa/on
• Analyse the poten/al impact or support each stakeholder could generate, and classify them so as to
define an approach strategy.
• Assess how key stakeholders are likely to react or respond in various situa/ons, in order to plan how to
influence them to enhance their support and mi/gate poten/al nega/ve impacts.

15
Conduct Stakeholder Analysis

Inputs Tools and Techniques Outputs

Elicita/on results (confirmed or Job Analysis Update Stakeholder Register
unconfirmed)
Persona Analysis
Enterprise and Business
RACI model
Architecture
Stakeholder maps
Situa/on Statement
Stakeholder Register

16
Determine stakeholder characteris:cs

• AZtude to iden/fy which stakeholders support the project and proposed solu/on and which stakeholders
do not.
• Complexity helps when quan/fying and planning the number of requirement sessions to conduct.
• Culture can impact how the business analyst proposes communica/ng with stakeholders
• Experience - Elicita/on may be completed more efficiently when stakeholders have prior experience
• Level of Influence helps evaluate the posi/ve and nega/ve factors
• Loca:on and Availability helps determine the best approach for collabora/on

17
Stakeholder Analysis

• Stakeholder Analysis
– Interest Vs Influence
• Stakeholder engagement levels:
– Unaware,
– Resistant,
– Neutral,
– Suppor/ve,
– Leading
• Stakeholder Management strategies are
developed to engage stakeholders.

• Working agreement - To promote effec/ve collabora/on and par/cipa/on of stakeholders

RACI

RACI Stands for Responsible, Accountable,

Consulted and Informed
Both project managers and business analysts have
an interest in stakeholder iden/fica/on and RACI
analysis
To beher understand who to involve in the needs
assessment phase, the business analyst develops a
RACI matrix to determine the roles and levels of
responsibility.

19
Assemble stakeholder analysis results

• Document the results of the analysis in a way that can be shared with the project manager, project team,
and sponsor.

• Could be considered sensi:ve in nature - exercise care when distribu:ng

• Stakeholder characteris/cs provide the project team with insights for determining how best to
collaborate

20
Determine Stakeholder Engagement and Communica:on Approach

Inputs Tools and Techniques Outputs

Situa/on Statement Persona Analysis Stakeholder engagement and
communica/on approach
Updated Stakeholder Register RACI model
Stakeholder maps
Elicita/on techniques
Retrospec/ve and Lessons
Learned

21
Determine Communica:on Approach

• Types of requirements and requirements-related informa/on that will be communicated

• Who requires communica/ons and what informa/on they expect
• Stakeholder preferences for receiving informa/on (e.g., summary level or detail)
• Preferred delivery methods for distribu/ng or accessing requirements and requirement related
informa/on
• Level of formality required in the communica/on
• Tools, including requirement repositories, which stakeholders will need access to.

22
Lessons Learned

• Lessons Learned shows how project events were addressed or should be addressed for the purpose of
improving future performance

23
Retrospec:ve

Retrospec:ve mee/ngs that are scheduled on a regular basis or conducted, when a body of work is
completed, such as the conclusion of an itera/on or at the end of a project phase within an adap/ve life
cycle
• Set the stage
• The context and tone for the mee/ng is established.
• Gather data
• Factual and relevant data is pulled together to support feedback.
• Generate insights
• The team looks for commonality in the feedback including cause and effect.
• Decide what to do
• The team collaborates to determine a course of ac/on for improvement.
• Close the Retrospec:ve
• The session is ended.
24
Conduct Business Analysis Planning

Inputs Tools and Techniques Outputs

Business Analysis performance Burndown charts Business Analysis Plan
assessment Decomposi/on Model
Charter Es/ma/on Techniques
Enterprise Environmental Factors Planning Techniques

Planning approaches from all

other knowledge areas
Product Risk Analysis

25
Conduct Business Analysis Planning

Inputs
• A business analysis performance assessment summarizes what has been learned about the effec/veness
of the business analysis processes and the business analysis techniques used in past efforts.
• Planning Approaches from All Other Knowledge Areas
• Stakeholder engagement and communica/on approach
• Elicita/on approach
• Analysis approach
• Traceability and monitoring approach
• Solu/on evalua/on approach
• Product Risk Analysis
• Project Charter A project charter formally authorizes the existence of a project, establishes the project
boundaries, and creates a record of project ini/a/on.

26
Conduct Business Analysis Planning

Inputs
Enterprise Environmental Factors (EEFs)
• EEFs are condi/ons, not under the immediate control of the team, that influence, constrain, or direct the
porVolio, program, or project.
• Factors that may influence the formality of business analysis efforts and how and when those
responsible for business analysis collaborate with their stakeholders.
• Example: social and cultural influences and issues, stakeholder expecta/ons and risk tolerances, legal and
contractual restric/ons, and government or industry standards.
• Factors that may influence the choice of techniques and tools in support of business analysis.
• Example Availability of tools to support business analysis, such as conferencing tools, modeling tools, and
product requirements or backlog management tools, and any security policies, procedures, and protocols
that may be associated with them.
• Other factors that may influence or constrain the results of business analysis,
• Examples: enterprise architecture, organiza/onal commitment to reuse exis/ng products, and even the
results of previous business analysis efforts.

27
Conduct Business Analysis Planning

Tools and Techniques

• Decomposi:on Model is an analysis model used to break down informa/on described at a high level into a
hierarchy of smaller, more discrete parts.
• Es:ma:on Techniques are used to provide a quan/ta/ve assessment of likely amounts or outcomes.
• Bohom Up es/ma/on
• Wide-band Delphi es/ma/on
• Rela/ve es/ma/on
• Affinity es/ma/on
• Three point es/ma/on
• Simple Average = (O + M + P) /3
• Weighted Average (PERT es/mate) = (O + 4M + P) / 6, Standard Devia/on = (P-O) /6

28
Es:ma:on Technique: 3 Point Es:mate – Beta Distribu:on

• Beta Distribu/on (from a tradi/onal PERT analysis) E= (O + 4M + P) / 6

• PERT uses a weighted average to calculate op/mal dura/ons. PERT is based on a normal distribu/on of
bell curve as depicted below. In a normal distribu/on:
– Approximately 4 of 6 results occur within a Standard Devia/on range of 1.
– Approximately 1 of 6 results occurs within a Standard Devia/on ranges 2 and 3 on each side of the
mean.

3 Sigma 2 Sigma 1 Sigma 1 Sigma 2 Sigma 3 Sigma

2 and 3 Sigma 2 and 3 Sigma

1 out of 6 1 out of 6

1 Sigma
4 out of 6

Normal Distribution Curve

29
Conduct Business Analysis Planning

Tools and Techniques

• Planning Techniques
• Product Backlog
• Story mapping
• Work Breakdown Structure (WBS)
• Rolling wave planning

30
Business Analysis Planning

Business Analysis planning consists of the ac/vi/es that are performed in order to ensure that;
• The business analysis approach is selected for the project
• Business analysis ac/vi/es and deliverables are defined and agreed to
• Processes that will be used for valida/ng, verifying, and approving requirements and solu/ons are
acceptable to key stakeholder
• The process for proposing changes to requirements is defined and understood, and
• Key stakeholders are aware of and support the ac/vi/es and /me commitments required to complete the
business anlaysis effort.

31
 Why many elicita/on techniques

• Many sources of requirements and different techniques suit

different sources

• Many types of requirements and different techniques suit

different requirement types

3-32
 Why do requirements change

• Internal factors
• Requirements not elicited from the right stakeholders
• Appropriate elicita/on techniques are not used
• External factors
• Changes to compe//ve landscape
• Changes in market condi/on
• Changes to regulatory laws
• Changes among personnel in customer organiza/on

1-33
 Types of Func/onal Requirements

– Implicit – Also known as

– Explicit • Conscious
• Unconscious
– Undreamed
• Undreamed

Example: Travel seat reservation

Conscious: The reservation scenario should capture the following information – Name, address, phone no.,
destination, date of travel, number of passengers, passenger type
Unconscious: Should also capture social security number; Should also SMS to the indicated phone number
confirming reservation status
Undreamed: Should send an SMS to the passenger 1 hr before the scheduled departure about the status of
departure, platform, mobile number of contact person (TC or Driver).
 Suitability of elicita/on techniques

Conscious Unconscious Undreamed

VOC 2 3 1
WhatIf analysis 2 3 2
Interviews 3 2 1
Brainstorming 1 2 3
Prototyping 2 3 2
Use case workshops 2 3 2
Kano model 3 3 3
Appren/ceship 1 3 2

Legend:
1 – Low suitability
2 – Average suitability
3 – High suitability

3-35
Business Analysis Planning Ra:onal

Ra:onal
• Sets expecta/ons with the sponsor, project team, and key stakeholders
• Ensures that roles are iden/fied, understood, and communicated
• Achieves buy-in
• Support es/ma/on of the BA ac/vi/es
• Creates an efficiently run BA process
Business Analysis Planning and Project Management Planning
• Business analysis planning and scheduling is not performed independent of project management
scheduling ac/vi/es

36
Create the Business Analysis Plan

• Created to document how the business analysis process will be performed

• Focused on the scope of the business analysis effort
• Includes list of ac/vi/es and business analysis deliverables to be produced
• Can be formal or informal
• Plan templates may exist
• Not all informa/on may be known at the /me – Based on assump/ons
• In some situa/ons, planning in the execu/on phase may be preferable

37
What to include in business analysis plan?

Following decisions are influenced by the selected project life cycle

1. Types of elicita/on ac/vity
2. Business Analysis deliverables
3. List of requirements state will be tracked and managed
4. Requirements analysis model
5. Roles and responsibili/es for those par/cipa/ng in business analysis ac/vi/es
6. How requirements will be verified and validated?
7. How requirements will be documented and communicated?
8. How requirements will be priori/zed, approved or maintained?
9. How the acceptance criteria will be determined?

38
Determining the proper level of details

1. Balancing between flexibility and management

2. Do not sacrifice good management prac/ces for flexibility

39
Understand the Project Context

1. There is NO single approach to the business analysis effort that works best for every project, because all
projects are unique.
2. Review business case, project goals and objec/ves in order to obtain the necessary context.
3. Analyze characteris/cs of the project
• Project type size and complexity
• Project /melines
• Project life cycle
• Time to market
• Market condi/ons
• Technology trends
• Risk level and tolerance
• Distribu/on of stakeholders
• Details and formality
• Constraints
• Business Analyst experience

40
Project Life Cycle influences on Planning Decisions

Project Life Cycle: Predic/ve or Plan Driven or Waterfall

• Minimizing uncertainty
• Scope Up Front
• Business Analysis work up-front
• Time and Cost for en/re project
• Deliverables defined at beginning
• Scope change carefully managed
• One implementa/on
• Need and solu/on don’t change

41
Project Life Cycle influences on Planning Decisions

Project Life Cycle: Itera/ve and Incremental

• Project split into phases
• Project work is performed sequen/ally
• High level scope is defined up front
• Rolling wave
• Product developed itera/vely
• Business Analysis performed up-front
• Requirements management /me-boxed
• Need and solu/on can change during the project

42
Project Life Cycle influences on Planning Decisions

Project Life Cycle: Change Driven or Adap/ve or Agile

• Business value over uncertainty
• Time and cost fixed per itera/on
• Quick (Rapid) itera/on
• Detailed scope per itera/on
• Changes are expected
• Business value itera/vely
• Business Analysis work constant
• Need and solu/on evolving

43
Project Life Cycle impact on Planning process

Project Life Cycle impact in planning process

• Business Analysis ac/vi/es that are performed
• Order in which the ac/vi/es will be completed
• Timing of ac/vi/es
• Business Analysis Deliverables
• Level of formality required for deliverables
• Approach for priori/zing requirements
• Methods for addressing requirement changes

44
Ensure the team is trained on the project life cycle

1. Project teams and key stakeholders may require training, if they have not worked previously with a
selected project life cycle
2. The business should be aware of the experience levels of the stakeholders and iden/fy areas where
coaching or training may be required to assist stakeholder through the business analysis ac/vi/es

45
Build the Business Analysis Work Plan

1. Iden/fy the Deliverables

2. Determine the Tasks and Ac/vi/es
3. Determine the Timing and Sequencing of Tasks
4. Determine the Roles and Responsibili/es
5. Iden/fying the Resources
6. Es/mate the Work

Determine Determine Determine

Identify Identify the Estimate the
tasks and timing and roles and
Deliverables Resources work
activities sequencing responsibilities

46
Iden:fy the Deliverables

• What deliverables will be produced?

• How deliverables will be used by other team members and key stakeholders?
• How changes to deliverables will be managed?
• Required formality of the deliverables?
• How deliverables will be accessed and by whom?
• Tools that are required to produce, maintain, or store deliverables?
• Whether requirements will be reused on future projects.

47
Determine the tasks and ac:vi:es

Decomposi:on model
An analysis model used to break down a high-level object into smaller more discrete parts.

48
Determine the :ming and seqencing of tasks

Factors
• Availability of resources required
• Needs of downstream recipients
• Rela/onship of project work to other organiza/onal work
• Contractual and statement of work obliga/ons
• Training dependencies
• Staffing and new hire needs
• Risk
• Complexity of tasks

49
Determine the Roles and Responsibili:es

Responsible
Accountable
Consulted
Informed

50
Iden:fying the resources and es:mate the work

• Iden:fying the Resources - The business analyst can lend their exper/se and personal insight to the project manager
as they work collabora/vely to determine the op/mal number of subject maher experts to engage on the business
analysis ac/vi/es
• Es:mate the Work – Factors to be considered into es/mates
• Project Size and Complexity
• Selected Project Life Cycles
• Amount of solu/on ambiguity
• Number of stakeholders
• Types of elicita/on techniques
• Loca/on of stakeholders
• Schedule and budget constraints
• Known assump/ons
• Number of Business Analysis Deliverables
• Formality and level of details
• Experience level of the project team
51
Assemble the Business Analysis work plan

Factors
• Complexity of the business analysis effort
• Size of the project
• Amount of business analysis work being tracked, and
• Type of project life cycle.

52
Document the Ra:onal for the Business Analysis Approach

For the project team, understanding the ra/onale behind the chosen business analysis approach provides
context and helps answer ques/ons regarding why the work is being conducted and why it is being
performed in a specific manner.

53
Review the Business Analysis plan with key stakeholders

Key stakeholders are needed for the following roles

• Responsibility for approving, priori/zing, or valida/ng requirements;
• Responsibility for a role in the change control process;
• Management responsibility for staff par/cipa/ng in the requirement ac/vi/es
• Responsibility for serving as a subject maher expert on the project.

54
Review and obtain approval of the Business Analysis Plan

• The objec/ve of review is to reduce the risk of stakeholder failing to support BA ac/vi/es.
• Discussing business analysis approach upfront helps to obtain buy-in early and minimize the risk of
stakeholder conflicts.
• Stakeholder involvement during review process ensure their needs are adequately addressed.
• Involving stakeholder also gives sense of ownership and they will be interested and remain engage during
business analysis ac/vity.
• Review process can reveals the areas / topics not covered or need clarifica/on by the stakeholders.
• Invite key stakeholders in review mee/ngs. Conduct review process in-person.
• Use collabora/on tools when stakeholders are geographically separated.
• Incorporate feedback and obtain approval.
• Approval can be formal or informal depending on the project life cycle, organiza/on needs.

55
Obtain approval of the Business Analysis Plan

Approval helps reduce the following risks

• Stakeholders do not support the business analysis process once it starts.
• Project team underes/mates the amount of /me that business analysis ac/vi/es will take.
• Funding allocated to the requirements phase of the project is inadequate.
• Key stakeholders underes/mate the level of involvement or par/cipa/on necessary for the requirement
ac/vi/es.
• Key resources are unavailable to par/cipate in requirement ac/vi/es, when required.
• Stakeholder expecta/ons with regard to how requirements are documented and communicated are
missed.

56
Planning processes in Elicita:on

Elicita:on

57
Determine Elicita:on Approach

Inputs Tools and Techniques Outputs

Product Scope Brainstorming Elicita/on approach
Situa/on Statement Interviews
Retrospec/ve and Lessons
Stakeholder engagement and
Learned
communica/on approach
Updated stakeholder register

58
Determine Elicita:on Approach

Factors to consider
• Stakeholder group characteris/cs and dynamics
• Project Life Cycle
• Characteris/cs of elicita/on techniques
• Type of project
• Time constraint
• Budget
• Number of stakeholders
• Loca/on of stakeholders
• Types of requirement deliverables
• Level of detail required
• Techniques that are familiar

59
Determine Elicita:on Approach

Strategies for sequencing elicita:on techniques

• Business value to be gained
• Greater risks
• Many project unknowns
• Technical challenges
• Dependencies
• Required third party resources
• Limited number of resources

60
Determine Elicita:on Approach

Inputs
• Product Scope is defined as the features and func/ons that characterize a solu/on.
• The product scope provides context and defines the boundaries to determine what informa/on to elicit
with the goal of further detailing the scope items.
• Situa:on statement describes the problem or opportunity that the business is interested in addressing,
providing context when determining what informa/on to elicit.
• Stakeholder Engagement and Communica:on Approach summarizes all the agreements for governing
how stakeholders will be engaged and communicated with across the porVolio, program, or project.
• Stakeholder register contains informa/on on who may impact or be impacted by the area under analysis,
along with profile informa/on about stakeholders or stakeholder groups.

61
Determine Elicita:on Approach

Outputs
• Elicita:on approach
• The elicita/on approach describes
• how elicita/on will be performed,
• what informa/on to elicit, where to find that informa/on,
• how to obtain the informa/on, and
• when to conduct the elicita/on ac/vi/es.
• It can be documented or it can be a thought process performed to prepare for the forthcoming
elicita/on effort.
• Ensure that everyone is aware of the forthcoming ac/vi/es and their role.
• The elicita/on approach may be referred to as an elicita:on plan in more formal life cycles.

62
Planning processes in Analysis

Analysis

63
Determine Analysis Approach

Inputs Tools and Techniques Outputs

Product Scope Brainstorming Analysis approach
Situa/on Statement Document analysis
Retrospec/ve and Lessons
Elicita/on approach
Learned
Traceability and Monitoring
approach

64
Determine Analysis Approach

Determine Analysis Approach

• Determine analysis approach is the process of thinking ahead about how analysis will be performed,
including
• what will be analyzed,
• what models will be most beneficial to produce, and
• how requirements and other product informa/on will be verified, validated, and priori/zed.

65
Determine Analysis Approach

Inputs
• Elicita:on approach is a star/ng point for determining some aspects of the analysis approach.
• The planned elicita/on techniques and their outputs might influence which analysis techniques are
applicable.
• Product Scope is defined as the features and func/ons that characterize a solu/on.
• The product scope provides context and defines the boundaries to determine what informa/on to elicit
with the goal of further detailing the scope items.
• Situa:on statement describes the problem or opportunity that the business is interested in addressing,
providing context when determining what informa/on to elicit.

66
Determine Analysis Approach

Inputs
• Traceability and monitoring approach defines the traceability and change management processes for the
porVolio, program, project, or product.
• One of the components of that approach is
• how the requirements, models, and other product informa/on relate to one another,
• which is an important input for selec/ng analysis techniques that support crea/ng models,
• using the models together, and iden/fying requirements from the models.

67
Determine Analysis Approach

Outputs
• Analysis approach
• The analysis approach describes
• how analysis will be performed;
• how to verify, validate, and priori/ze requirements and other product informa/on;
• how risks will be iden/fied and analyzed;
• how design op/ons will be assessed; and which techniques and templates are expected to be
used to perform any analysis.
• The analysis approach includes which requirements ahributes need to be captured and how the
requirements architecture impacts analyzing models.
• It also describes what other informa/on or models from the organiza/on might be used during
analysis.
• This output will likely be updated throughout the course of the porVolio, program, or project.

68
Define the decision making process

• Types of decisions that will be made, including how requirements will be approved
• Roles and authority levels, for example, who is involved in the discussions and who makes decisions, etc.
• Process to follow when consensus cannot be reached and requirements-related issues need to be
escalated
• Required turn-around /me for a decision to be reached
• How decisions are documented and communicated, including requirements signoff
• Special tools or techniques that may be used to help teams evaluate alterna/ves, for example, decision
analysis, decision modeling, decision trees etc.

69
Define the requirements verifica:on and valida:on process

• Requirements verifica:on
• Verifica/on is the process of reviewing requirements and models to ensure they meet quality
standards.
• Requirements valida:on
• Valida/on is the process of ensuring that all requirements accurately reflect the intent of the
stakeholder and that each requirement aligns to one or more business requirements

70
Define the requirements change process

• How requirements change will be proposed?

• How changes will be reviewed?
• How change management decision will be documented?
• How requirements changes will be communicated?
• How changes to requirements related informa/on will be completed?

Roles and Responsibilites

• Responsibility for proposing changes
• Responsibility for impact analysis
• Roles that par/cipate in change discussions
• Responsibility for approving changes

71
Define the requirements priori:za:on process

• When requirements priori/za/on will occur?

• The likelihood that priori/es will change
• Techniques that will be used for priori/za/on
• Stakeholders who will be involved in the priori/za/on process
• Criteria that will be used to priori/ze
• Stakeholders who will approve the priori/za/on decisions

Basis for priori:za:on

• Value: Addressing high-value requirements first

• Cost: Evalua/ng requirements based on financial costs or opportunity costs
• Difficulty: How difficult to fulfill the requirement
• Regulatory: Addressing regulatory or legisla/ve requirements first
• Risk: Implemen/ng high-risk requirements first

72
Planning processes in Traceability and Monitoring

Traceability and Monitoring

73
Determine Traceability and Monitoring Approach

Inputs Tools and Techniques Outputs

Product Scope Retrospec/ve and Lessons Traceability and Monitoring
Learned approach
Compliance or Regulatory
standards
Configura/on management
standards

74
Determine Traceability Approach

• Types of requirements to be traced

• Level of detail to trace to
• Rela/onships that will be established and maintained
• Requirement ahributes to be tracked
• Requirement states that drive the requirements life cycle (for example, approve, defer, reject, etc.)
• Tools used to perform the traceability
• Process decisions regarding how traceability will be established and maintained.

75
Determine Traceability and Monitoring Approach

Inputs
• Product Scope is defined as the features and func/ons that characterize a solu/on.
• The product scope provides context and defines the boundaries to determine what informa/on to elicit
with the goal of further detailing the scope items.
• Compliance or regulatory standards are a type of enterprise environmental factor imposed by external
organiza/ons commonly for reasons related to security, protec/ng personal informa/on, legal
considera/ons, or safety reasons.
• Compliance and regulatory standards o[en mandate more formal approaches to traceability and
monitoring.

76
Determine Traceability and Monitoring Approach

Inputs
• Configura:on management is a collec/on of formal documented processes, templates, and
documenta/on used to apply governance to changes to the solu/on or subcomponent under
development.
• Configura/on management ensures that the product being built conforms to its approved requirements.
• The traceability and monitoring approach should adhere to the configura/on management standards in
place within the organiza/on.

77
Determine Traceability and Monitoring Approach

Outputs
• Traceability and Monitoring Approach defines how traceability and change management ac/vi/es will be
performed throughout the porVolio, program, or project.
• The traceability components of the approach include types of objects to trace, types of rela/onships, and
the level of tracing detail required, and informa/on about where tracing informa/on will be tracked.
• The monitoring components of the approach include how changes are proposed and reviewed, how
decisions are documented and communicated, and how changes are made to exis/ng product
informa/on.
• Both approaches describe the roles and responsibili/es and how the informa/on is stored.

78
Benefits of traceability

• Ensure that product informa/on adds business value and meets customer expecta/ons
• Manage scope
• Minimize the probability of missing requirements
• Perform impact analysis
• Make release decisions

79
Planning processes in Solu:on Evalua:on

Solu:on Evalua:on

80
Recommended Mindset for Evalua:on

• Evaluate Early and O[en

• Treat Requirements Analysis, Traceability, Tes/ng, and Evalua/on as Complementary Ac/vi/es

• Evaluate with the Context of Usage and Value in Mind

• Confirm Expected Values for So[ware Solu/ons

81
Plan for Evalua:on of the solu:on

• What project or organiza/onal goal, objec/ve, or risk does this evalua/on ac/vity monitor or track or
confirm?
• Important to /e every evalua/on ac/vity and every individual metric to organiza/onal or project
priori/es
• Who will cover costs for the /me and effort needed to conduct evalua/on?
• Issues can appear long a[er the project has been closed. Remember from project to produc/on!
• Does the solu/on or its infrastructure have built-in measurement capabili/es for the evalua/on criteria?
• Is this part of your process

82
Plan for Evalua:on of the Solu:on

• Are there already ways to extract measurement data to use in the evalua/on?
• When data exists, it does not necessarily mean that it is available for evalua/on
• Is the chosen evalua:on method effec/ve and rela/vely inexpensive?

• You may use surveys and quess/onairs to evaluate solu/on from larger user base.
• Are there already exis/ng ways to report and publish the results of an evalua/on?
• Communica/on is key. Make sure you have the right plaVorm to boradcast informa/on.

83
Determine Solu:on Evalua:on Approach

Inputs Tools and Techniques Outputs

Product Scope Retrospec/ve and Lessons Learned Solu/on evalua/on approach
Situa/on Statement Elicita/on techniques
Group decision making techniques
Metrics and KPIs
Priori/za/on schemes

84
Determine Solu:on Evalua:on Approach

• Evalua/on criteria and acceptance levels

• Qualita/ve and quan/ta/ve evalua/on ac/vi/es to be performed
• How the solu/on will be evaluated?
• When and how o[en evalua/on will be performed?
• Evalua/on techniques that will be used, for example, focus groups, observa/ons, surveys, etc.
• Will any special measurement tools will be required?
• How results will be analyzed and reported.

85
Determine Solu:on Evalua:on Approach

Inputs
• Product Scope is defined as the features and func/ons that characterize a solu/on.
• The product scope provides context and defines the boundaries to determine what informa/on to elicit
with the goal of further detailing the scope items.
• Metrics and KPIs A metric is a set of quan/fiable measures used to evaluate a solu/on or business.
• In solu/on evalua/on, a metric defines how solu/on performance can be quan/fied.
• Defining a solu/on evalua/on approach involves choosing which metrics to use to evaluate a solu/on
under development as part of its acceptance criteria or a previously released solu/on as part of its
performance.
• Situa:on statement describes the problem or opportunity and its effect on the organiza/on.

86
Determine Solu:on Evalua:on Approach

Outputs
• Solu:on evalua:on approach describes
• when and how a solu/on will be evaluated,
• the types of metrics that will support evalua/on,
• the feasibility of collec/ng and communica/ng the actual performance data for these metrics, and
• who is responsible for conduc/ng the evalua/on and communica/ng results.

87
Ques:on #1

Business Analysis Planning is also known as approach?

a. True
b. False

88
Ques:on #1

Business Analysis Planning is also known as approach?

a. True
b. False

89
Ques:on #2

A stakeholder is ____________.

a. A person who is responsible for the budget

b. Your team
c. CEO
d. Anyone who is effected by the ini/a/ve

90
Ques:on #2

A stakeholder is ____________.

a. A person who is responsible for the budget

b. Your team
c. CEO
d. Anyone who is effected by the ini/a/ve

91
Ques:on #3

The brainstorming session should not ______________

a. Be under 60 minutes
b. Be planned in advance
c. Require the ideas to be judged for merit
d. Be facilitated

92
Ques:on #3

The brainstorming session should not ______________

a. Be under 60 minutes
b. Be planned in advance
c. Require the ideas to be judged for merit
d. Be facilitated

93
Ques:on #4

Which element is not an a>ribute of a metric?

a. Clear
b. Relevant
c. Economical
d. Adequate
e. Qualifiable

94
Ques:on #4

Which element is not an a>ribute of a metric?

a. Clear
b. Relevant
c. Economical
d. Adequate
e. Qualifiable

95
Ques:on #5

Which organizaAonal structure allows for Project Manager to control her own budget?

a. Func/onal
b. Weak Matrix
c. Strong Matrix
d. None of the above

96
Ques:on #6

IdenAfy the element which is not a stakeholder type

a. Leading
b. Suppor/ve
c. Nomina/ve
d. Resistant
e. Unaware

97
Ques:on #6

IdenAfy the element which is not a stakeholder type

a. Leading
b. Suppor/ve
c. Nomina/ve
d. Resistant
e. Unaware

98
Ques:on #7

When seEng up the business analysis plan, we talk about assigning roles and responsibiliAes. Which tool or
technique could help in this process?

a. Ishikawa Diagram
b. RACI Diagram
c. Affinity Diagram
d. En/ty Rela/onship Diagram

99
Ques:on #7

When seEng up the business analysis plan, we talk about assigning roles and responsibiliAes. Which tool or
technique could help in this process?

a. Ishikawa Diagram
b. RACI Diagram
c. Affinity Diagram
d. En/ty Rela/onship Diagram

100
Ques:on #8

Which element is not seen as being part of the requirements prioriAzaAon process?

a. Value
b. Consistency
c. Difficulty
d. Regulatory
e. Risk

101
Ques:on #9

In an adapAve project life cycle in comparison to a predicAve model no planning is required.

a. True
b. False

102
Ques:on #10

Which elements are considered part of an incremental project life cycle?

a. Business Analysis work performed up-front

b. Need and solu/on can change during the project
c. Deliverables defined at beginning
d. Scope change carefully managed
e. Business Analysis work constant

103
Answers

1. A
2. D
3. C
4. E
5. C
6. C
7. B
8. B
9. B
10. A & B

104
Module 5

Planning Process Group

105
 Thank You and Good Luck!

[Link] | support@[Link]

106