This document provides an overview of root cause analysis and scope modelling techniques that can be used by business analysts. It describes root cause analysis tools like fishbone diagrams and the five whys method. It also outlines different elements of scope modelling like defining the scope of control, need, solution and change. Examples are provided and a discussion is encouraged on how these techniques are used in projects. Attendees are asked to provide feedback to help improve knowledge sharing. Volunteers are also sought to help run the local IIBA branch.

1. @UKIIBA #UKIIBA
Analysis in Action – BABOK techniques
September 2021
Welcome

2. Analysis in
Action
The aim of AiA is to build on our practical
knowledge by learning from each other
through real scenarios. They can include:
• Showcase of new analysis tools or tools borrowed from
other disciplines that could aid Business Analysts
• Showcase of known tools used in a new way, producing
better outcomes
• Peer review – open discussion/workshop to review and
improve our deliverables
It’s a chance to learn, share your knowledge
and network.

3. Agenda
Root Cause Analysis
• Overview
• Example
• Feedback
Scope Modelling
• Overview
• Example
• Feedback

4. Root Cause Analysis

5. Root Cause Analysis
description
Root cause analysis is used to identify and evaluate the underlying causes of a
problem.
Root cause analysis helps organize the information in a framework, which allows for
deeper analysis if needed. Root cause analysis can be used for:
• Reactive Analysis: identifying the root cause(s) of an occurring problem for
corrective action, or
• Proactive Analysis: identifying potential problem areas for preventive action.

6. Root Cause Analysis
elements
Problem Statement Definition:
Data Collection:
Cause Identification:
Action Identification:
• describes the issue to be addressed.
• gathers information about the nature,
magnitude, location, and timing of the
effect.
• investigates the patterns of effects to
discover the specific actions that
contribute to the problem.
• defines the corrective action that will
prevent or minimize recurrence.

7. Root Cause Analysis
– Fishbone diagram
1. Capture the issue or problem under discussion in a box at the top
of the diagram.
2. Draw a line from the box across the paper or whiteboard
(forming the spine of the fishbone).
3. Draw diagonal lines from the spine to represent categories of
potential causes of the problem. The categories may include
people, processes, tools, and policies.
4. Drawing smaller lines to represent deeper causes.
5. Brainstorm categories and potential causes of the problem and
capture them under the appropriate category.
6. Analyse the results. Further analysis is needed to validate the
actual cause, ideally with data.
7. Brainstorm potential solutions once the actual cause has been
identified.

8. Root Cause Analysis
– The Five Whys
The five whys is a question asking process to
explore the nature and cause of a problem.
The five whys approach repeatedly asks
questions in an attempt to get to the root
cause of the problem. This is one of the
simplest facilitation tools to use when
problems have a human interaction
component.
To use this technique:
1. Write the problem on a flip chart or
whiteboard.
2. Ask "Why do you think this problem
occurs?" and capture the idea below the
problem.
3. Ask "Why?" again and capture that idea
below the first idea.
Continue with step 3 until you are convinced
the actual root cause has been identified.

9. 1. Do you use root cause analysis to inform your
projects?
2. Which techniques have you used?
3. If you don’t use it, why not? Do you think this could
be useful for you?
4. What do you think are the strengths and
weaknesses of this method?
Discussion

10. Thoughts
Strengths
Helps to maintain an
objective perspective when
performing cause-and-
effect analysis.
Enables stakeholders to
specify an effective solution
at the appropriate points
for corrective action.
Limitations
Works best when the business
analyst has formal training to
ensure the root causes, not just
symptoms of the problem, are
identified.
May be difficult with complex
problems; the potential exists to
lead to a false trail and/or dead–
end conclusion.

11. Scope Modelling

12. Scope Modelling
description
Scope models
provide the
basis for
understanding
the
boundaries of:
Scope of Control: what is being analysed, roles and responsibilities,
and what is internal and external to the organization.
Scope of Need: stakeholder needs, value to be delivered,
functional areas, and organizational units to be explored.
Scope of Solution: requirements met, value delivered, and impact
of change.
Scope of Change: actions to be taken, stakeholders affected or
involved, and events to cause or prevent.

13. Scope Modelling
elements
Objectives
Scope of
Change and
Context
Level of
Detail
Relationships
Assumptions
Scope
Modelling
Results

14. Scope Modelling
elements
Objectives
Scope models are typically used to clarify the:
• span of control,
• relevance of elements, and
• where effort will be applied.
Depending on the action or stakeholder needs the model
supports, a business analyst determines the types of models
to be used and selects boundaries and elements.

15. Scope Modelling
elements
Scope of Change and Context
The business analyst often determines:
• business processes to be defined or modified,
• business functions to be added, changed, optimized, or re-assigned,
• new capabilities to be built or existing capabilities to be changed,
• external and internal events to be responded to,
• use cases and situations to be supported,
• technologies to be changed or replaced,
• informational assets to be acquired, produced, or processed,
• stakeholders and organizational roles impacted by the change,
• external and internal agents and entities impacted by the change,
• organizations and organizational units (departments, teams, groups)
impacted by the change, and
• systems, components, tools, and physical assets required for the change or
impacted by the change.

16. Scope Modelling
elements
Level of Detail
The purpose of analysis defines the appropriate level of
abstraction at which scope elements are described.
A proper level of detail provides a meaningful
reduction of uncertainty while preventing 'analysis
paralysis' at a scope definition stage.

17. Scope Modelling
elements
Relationships
Exploring relationships between potential scope elements helps to ensure
completeness and integrity of the scope model by identifying their dependencies or
by discovering other elements involved in or impacted by the change. Various
diagramming techniques are available for exploring relationships of specific types,
including:
• Parent-Child or Composition-Subset
• Function-Responsibility
• Supplier-Consumer
• Cause-Effect
• Emergent.

18. Scope Modelling
elements
Assumptions
At a time of scope modelling, the validity of the model
heavily relies on assumptions such as the definition of
needs, causality of outcomes, impact of changes,
applicability, and feasibility of the solution.
The resulting scope model should include explicit
statements of critical assumptions and their implications.

19. Scope Modelling
elements
Scope Modelling Results
Results of scope modelling can be represented as:
• textual descriptions of elements, including criteria for
making in-scope or out-of-scope decisions,
• diagrams illustrating relationships of scope elements, and
• matrices depicting dependencies between scope
elements.

20. 1. At what level do you typically define scope (control,
need, solution, change)?
2. How often do you use it?
3. When in the project do you use it? Do you review it
at the end of the project?
4. How useful is it for projects in general?
5. What are the strengths and weaknesses of this
method?
Discussion

21. Thoughts
Strengths
A scope model facilitates
agreement as a basis for:
• defining contractual obligations,
• estimating the project effort,
• justifying in-scope/out-of-scope
decisions in requirements analysis,
and
• assessing the completeness and
impact of solutions.
Limitations
An initial, high-level model can lack a sufficient
level of granularity, that is needed to ensure
clear scope identification.
Once a scope is defined, changing it may be
difficult due to political reasons and
contractual obligations.
Traditional scope models cannot address
common complex boundaries, such as a
horizon (a boundary that is completely
dependent on the position of the stakeholder).

22. We are always seeking new ways of knowledge sharing
in our community. Let me know what you thought!
Please fill in the questionnaire or email
Kasia Bochenek (kasia.bochenek@iibauk.org)
Feedback

23. We are always seeking volunteers to help run the
branch and sponsors to host or help fund our events.
If you can support us with any of these actions, please
contact us on the IIBA UK website.
Volunteer
with us!