Analysis in Action 21 September 2021
0 likes194 views
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.
Analysis in Action 21 September 2021
- 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
- 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!