Problem Detection & Resolution

1. 8/19/21
1
DOMAIN VI
Problem Detection and
Resolution
(version 2.2)
MSc. PMP. Nguyen Thanh Phuoc
phuocnt@gmail.com
Key Topics
• Control limits
• Cost of change
• Cycle time
• Defect rate
• Escaped defects
• Expected monetary value
• Failure and success modes
• Lead time
• Problem solving
– As continuous improvement
– Team-based
2
• Risk Adjusted backlog
• Risk burndown graphs
• Risk severity
• Technical debt
• Throughput/productivity
• Trend analysis
– Lagging metrics
– Leading metrics
• Variance analysis
– Common cause
– Special cause

2. 8/19/21
2
Tasks TO DO
1. Create a safe and open environment to surface
problems
2. Engage team in resolving threats and issues
3. Resolve issues or reset expectations
4. Maintain a visible list of threads and issues
5. Maintain a threat list and add thread remediation
efforts to the backlog
3
Understanding Problems

3. 8/19/21
3
Understanding Problems
• How Problems Impact a Project
5
Understanding Problems (cont.)
• How Problems Impact a Project (cont.)
6

4. 8/19/21
4
Understanding Problems (cont.)
• How Problems Impact a Project (cont.)
– Our original approach was appropriate for the project ??? NOT
è Need to backtrack and try a new approach
– Ex: Let’s assume it takes two hours to undo the bad work and
that this takes us two steps backward in the completed scope on
the project. Including the hour we spent diagnosing the problem,
the total time we’ve lost is now 1+2+2 = 5 hours
7
Understanding Problems (cont.)
• How Problems Impact a Project (cont.)
– The secret to minimizing the impact of problems
• Identify them as soon as possible è early detection reduces
the potential for rework.
• Need to diagnose and solve it as quickly as possible so we
don’t consume any more unplanned time than necessary
8

5. 8/19/21
5
Understanding Problems (cont.)
• Cost of Change
– The more stakeholders will be
impacted by the defect, making it
that much more expensive to fix
– Agile methods emphasize frequent
verification and validation through
software development practices
(such as pair programming,
continuous integration, and test-
driven development)
9
Impacts of defects

6. 8/19/21
6
Understanding Problems > Technical Debt
– Is the backlog of work that is caused
by not doing regular cleanup,
maintenance, and standardization
while the product is being built
– Is a backlog of things that should be
done to make work easier in the
future, but aren’t done because of a
push to deliver features
– Ex: Refactoring code, Fix technical
issues in future
11
Understanding Problems > Space Environment
• Create a safe and open environment
– We want people to feel comfortable not just to experiment,
but also to admit their problems, failures, and mistakes and ask
for help so that the project can recover as quickly as possible
– So creating a safe and open environment is as much about
avoiding catastrophic (thảm khốc) delays as it is about protecting
people’s feelings
– This can be a coaching opportunity to remind people to share
issues early
12

7. 8/19/21
7
Understanding Problems > Failure modes
• Understanding the human factors that contribute to problems can
help us minimize problems and handle them more effectively
– There are five failure modes that Cockburn describes in his book Agile
Software Development: The Cooperative Game.
1. We make mistakes => don’t surprise that people make mistakes
2. We prefer to fail conservatively (bảo thủ) è When faced with
uncertainty, people tend to revert back to what they know, even if they are
aware that it might not be the optimal approach
3. We prefer to invent rather than research è it is also usually more
costly, time-consuming, and error-prone
4. We are creatures of habit è we don’t want to change our
ways
5. We are inconsistent è apply the new approach consistently
è Do Cockbum’s failure modes mean that we are doomed (cam chịu)
to fail? NO. Let’s review them to understand the issues involved
13
Understanding Problems > Success Modes
– Be helpful to share the following success modes with our team
members, and try to leverage (đòn bẩy) them for the good of the
project:
1. We are good at looking around
2. We are able to learn
3. We are malleable (dễ uốn): Despite the common resistance to
change, we do have the ability to change and accept new
ideas and approaches.
4. We take pride (tự hào) in our work: step outside of our job
descriptions to repair or report an issue, because it is the
right thing to do for the project
14

8. 8/19/21
8
HOW TO SOLVE PROBLEM
Success Strategies
– Cockburn has come up with ten strategies for overcoming the
failure modes.
1. Balance discipline with tolerance
2. Start with some thing concrete and tangible
– Solve a problem in our mind first, and then turn the solution into reality
3. Copy and Alter
– Easier to modify a working design of it our needs than to create something from
nothing
4. Watch and Listen
– We learn by watching others and listening to them
5. Support both concentration and communication
– Communication and conversation are also essential for knowledge work and
should be encouraged, since they help surface gaps in understanding and
provide solutions to questions
15
HOW TO SOLVE PROBLEM
• Success Strategies (cont.)
– Cockburn has come up with ten strategies for overcoming the
failure modes.
6. Match work assignments with the person
– Should try to match work assignments to personality types and look for
mismatches
7. Retain the best talent
– Need to recognize the huge difference that talent makes and find ways to attract
and retain the best talent
8. Use rewards that preserve joy
– Reward structures are tricky to setup, because once people start to expect a
reward
9. Combine rewards
10. Get feedback
– A little bit of feedback can replace a lot of analytical work
16

9. 8/19/21
9
Detecting Problems
Detecting Problems
• Diagnostic tools such as
– [T&T] Lead Time and Cycle Time
– Defects
– Variance Analysis
– Trend Analysis
– Control Limits
• These tools can point to potential problems before
they occur or help us identify problems as soon as
possible after they have occurred
18

10. 8/19/21
10
Detecting Problems (cont.)
• [T&T] Lead Time and Cycle Time
– Lead time: how long something takes to go through the
entire process
– Cycle time: how long something takes to go through part of
the process
19
Detecting Problems (cont.)
• [T&T] Lead Time and Cycle Time
– Project Cycle Type
• Cycle time for a work item is the elapsed time between its
start and finish
• The project cycle time = project duration
• Cycle time is also useful for finding defects
20

11. 8/19/21
11
Detecting Problems (cont.)
• [T&T] Throughput and Productivity
– Throughput is the average amount of work the team can get
done in a time period (or their average completion time)
– Productivity is the rate of efficiency at which the work is done
such as the amount of work done per team member
• From defects
– Defect cycle time is the period between the time the defect
was introduced and the time it was fixed
21
Detecting Problems (cont.)
• Defects (cont.)
– To help minimize the cost of
fixing defects, some project
teams actively track their average
defect cycle time and set goals
for the quick resolution of defects
– By tracking both their defect
cycle time and their cycle time,
agile teams can minimize both
the potential for rework and the
cost of any rework that is
required.
22

12. 8/19/21
12
Detecting Problems (cont.)
• [T&T] Defect Rates
– Escaped defects ~ Leakages: Defects that are missed by
testing are the most costly kinds of defects to fix
– Is a new type of work being undertaken? Is the team being
pushed too hard for productivity at the expense of quality?
– Defect rates and defect counts can be used to give insight
into these issues
23
Detecting Problems > Escaped Defects
• An escaped defects is a defect that was not found by, or one that escaped from,
the quality assurance team. Typically, these issues are found by end users after
release version has been made available to them.
• Escaped defects found counts number of new escaped defects found over period
of time (day, week, month).
Best presentation is a simple bar
chart, where each bar shows number
of escaped defects found per
(day/week/month/quarter/year)

13. 8/19/21
13
Detecting Problems (cont.)
• [T&T] Variance Analysis => finding causes of variation
– Quality expert W. Edwards Deming classifies variance into
• Common cause variation refers to the average day-to-day
differences of doing work
• Special cause variation refers to the greater degrees of variance
that are caused by special or new factors.
– There are two classic mistakes that managers make:
• Mistake 1: Reacting (respond) to an outcome as if it came from
a special cause, when(but) it actually came from common
causes of variation
• Mistake 2: Treating (deal with) an outcome as if it came from
common causes of variation, when(but) it actually came from a
special cause.
25
Detecting Problems (cont.)
• [T&T] Variance Analysis => accept the variance or take action
– Simply accept common cause variation and only need to
investigate or take action in the case of special cause variation
Ex: Asking our developers why they only coded four features this week
when they completed five features last week is an example of failing to
accept common cause variation
– We should look to external indicators and the daily stand-up
meetings where the team reports any issues or impediments
to their work to see if there are special issues that need to be
resolved è It will cause special variation
26

14. 8/19/21
14
Detecting Problems (cont.)
• [T&T] Trend Analysis
– Is a particularly important tool for detecting problems because it provides
insights into future issues before they have occurred
– Lagging metrics that provide a perfect view of the past; Leading metrics that
provide a view into the future
– Leading metrics: This early indication of a potential problem is more useful
than lagging metrics, since it helps the team adapt and re-plan appropriately
27
Detecting Problems > Control Limits
– Control limits have a much looser interpretation that includes
tolerance levels and warning signs
– Help us diagnose issues before they occur or provide guidelines for
us to operate within
• Kanban and task boards that limit WIP
• Prevent too much work
• Help the team control the amount of work in progress.
28

15. 8/19/21
15
Embedding quality principles
• Incremental delivery
– This exposes latent bugs early and avoids most of the onerous integration
and testing requirements at the end of the project
• Iterative delivery
– This is called frequent validation and verification
• Small releases
– With small timeboxed releases, it is important that the teams automate
their test regression suite
• Lean by using value stream map
– Lean has a continuous focus on quality by using a value stream map and
ruthlessly eliminating non-value added activities
• Limit WIP
– Kanban teams limit WIP and swarm to resolve problems collectively, before they
accept any new items of work
29
Embedding quality principles
• Acceptance test cases
– validate whether the implementation conforms to the requirements. These
test cases are documented at the back of story cards
• Definition of done
– Definition of done to determine when a story could be marked as completed
• Stand-up meetings
– stand-up meetings during which they openly share their progress and the
impediments
• Code reviews
– code reviews to ensure good quality of the code and prevent defects even before the
code is executed
• Coding conventions
• Pair programming, which is also a quality control measure
• Test-driven development (TDD), where the teams write test cases first
and then write enough code to pass the tests
30

16. 8/19/21
16
Embedding quality principles
• Refactor code to remove technical debt
– as well as provide indicative effort estimates to remove the violations from
code
• Maintain version control repository and perform continuous build
and integration
• Retrospectives
• Team involvement and participation in all ceremonies, events, or
checkpoints like release planning, iteration planning, prioritization,
estimation, review, risk identification, risk analysis and mitigation and
problem solving helps to get diverse and well-rounded views and greater
buy-in from the participants.
31
Shift-left testing
32

17. 8/19/21
17
Steps in TDD
33
Acceptance-driven development (ATDD)
34

18. 8/19/21
18
Continuous Integration (CI)
35
Managing Threats
and Issues

19. 8/19/21
19
Managing Threats and Issues (cont.)
• [T&T] Risk Adjusted Backlog
– Risk is essentially anti-value, managing risk is critical for value-driven delivery
– Need to balance the goals of delivering business value and reducing risk each
time they select a new batch of features or stories to work on
– The risk response activities are added and prioritized (based on their anti-value)
37
Managing Threats and Issues (cont.)
• [T&T] Risk Adjusted Backlog
– Step 1: Step 2:
• Monetize the risk avoidance and risk
mitigation activities by calculating the
expected monetary value of each risk
• Expected Monetary Value (EMV) = Risk
Impact (in dollars) x Risk Probability (as a
percentage)
• Look for relative amounts rather than precise
numbers
• Focus on coming up with general, just if I able
numbers that have consensus from the
project stakeholders to use as a basis for
prioritization
• …
38

20. 8/19/21
20
Managing Threats and Issues (cont.)
• [T&T] Risk Adjusted Backlog
– Step 2 (cont.): Rank the project risks to produce a prioritized list of threats
and issues, ordered by expected monetary value (…)
39
Managing Threats and Issues (cont.)
• Risk Severity
– Risks are generally assessed via two measures
• Risk probability (a measure of how likely a risk is to occur)
and risk impact (a measure of the consequence to the
project should the risk actually occur)
• Ex: if a risk is estimated to have a 25 percent probability of
occurring and its financial impact is estimated at $8,000, Its EMV
will be 0.25 x $8,000= $2,000 è draw back to using EMV focus
too much on the exact dollar amounts rather than the relative
value of the risks
– There is another metric we can use to rank risks and determine
risk response priorities—risk severity
[ Risk Severity = Risk Probability x Risk Impact ]
40

21. 8/19/21
21
Managing Threats and Issues
• Risk Severity (cont.)
– Risk Severity = Risk Probability x Risk Impact (a simple scale—such a slow(1),
medium(2), and high(3)
41
Managing Threats and Issues (cont.)
42
• Risk Severity (cont.)

22. 8/19/21
22
Managing Threats and Issues (cont.)
[T&T] Risk Adjusted Backlog
– Step 3: Of course not all risks
will have avoidance or
mitigation
• Some risks may have to
be accepted or
transferred. But for the
risks that can be
proactively tackled,
• The next step is to
prioritize the response
actions along with the
functional features to get
the risk-adjusted backlog
44
Managing Threats and Issues (cont.)
• [T&T] Risk Adjusted Backlog (cont.)
45

23. 8/19/21
23
Managing Threats and Issues (cont.)
• [T&T] Risk Burndown Graphs
– Another key agile tool comes into the picture, reflecting the
agile emphasis on fast, visual communication
– To make the data in the above risk severity table easier to
grasp at a glance, we can convert the numbers into a risk
burndown graph
47
Solving Problems

24. 8/19/21
24
Solving Problems
• Problem Solving as Continuous Improvement
– Agile methods don’t rely on reactive approach of “fix the problem
after it arises.” è Instead, they include focused efforts to identify
potential issues during the iteration reviews and retrospectives that
are done at the end of each iteration.
• Engage the Team
– Agile problem-solving methods are team-based and inclusive; they
aren’t just relegated to the customer or managers
– Engage the team in identifying, diagnosing, and solving threats and
issues this is works of whole-team
– One of the most important is that you gain the team’s buy-in from the
start; you don’t have to sell your solution to the team
49
Solving Problems (cont.)
• The Benefits of Team Engagement
– By asking the team for a solution è we inherit consensus for the proposal
– Engaging the team accesses a broader knowledge base è team members are
closer to the details of the project, they bring additional insights to bear on problems
and their potential solutions
– Team solutions are practical è Team-sourced solutions have already been vetted
for practicality, and because they are created internally, they also include solutions for
implementation issues
– When consulted, people work hard to generate good ideas è People don’t want
to be treated as work drones
– Asking for help shows confidence, not weakness è Asking for ideas and solutions
to problems is not a sign of incompetence or an inability to manage .Just because a
leader asks for input does not mean he or she doesn’t know what to do
– Seeking others’ ideas models desired behavior è Teams that can effectively solve
problems and build support for their solutions are the real powerhouse of successful
projects
50

25. 8/19/21
25
Solving Problems (cont.)
• Some Problems Can’t Be Solved
– If there is a way to workaround those problem, then the best
approach is accept them and move on to delivering value
where we can
– We try to solve all the problems we encounter, but sometimes
the smartest thing to do is just get out of the situation and
reset our expectations for the project instead.
51
Solving problems (cont.)
• Divide and conquer – breaking down complex problems into simpler and
more manageable problems that are easier to resolve.
• Expert judgement – consulting with a subject-matter expert who has
‘been-there, done-that before’.
• Simulation – scaling down the complexity of the problem into a simpler
model that is easier to control and trying out multiple permutations and
combinations of scenarios.
• Brainstorming / war room – gathering all experts together in one place to
come up with ideas, logical reasoning, debate, discuss. and plan action
items.
• Metaphors – using analogy of the solution for a previous problem to
resolve the current problem.
54

26. 8/19/21
26
Solving problems (cont.)
• Trial and error – trying different alternatives repeatedly until the
resolution is obtained.
• Spikes – experimenting with alternate options to check out viability
and feasibility of the solution.
• Trend analysis – trying to figure out a pattern in the system
behavior.
• Probing – asking a series of questions to get to the bottom of the
problem, rather than treating it based on symptoms.
• Sandboxing – solving the problem in a smaller and controlled
environment, before applying the fix on the live system. 55
5W1H
Xác định
vấn đề
Phân tích vấn
đề
Đưa ra giải
pháp

27. 8/19/21
27
Man (Vấn đề con người)
Method (Vấn đề phương pháp)
Machine (Vấn đề máy móc)
Material (Vấn đề nguyên vật liệu)
Measuring/Monitoring (Vấn đề tiêu chuẩn đánh
giá/kiểm tra)
M
5M
Tập kích não (Brainstorming)
a. Nguồn gốc của tập kích não
Chữ tập kích não (Brainstorming) được đề cập đầu tiên bởi
Alex Osborn năm 1941.
Phương pháp này hoạt động bằng cách tập trung trên vấn
đề, và rút ra rất nhiều đáp án căn bản cho nó.
Có thể tiến hành bởi một hoặc nhiều người.

28. 8/19/21
28
Biểu đồ xương cá ISHIKAWA
a. Biểu đồ xương cá là gì?
Biểu đồ xương cá (fishbone diagram) hay biểu đồ nguyên nhân –
kết quả có tên gốc là phương pháp Ishikawa, là một phương
pháp nhằm nhận diện vấn đề và đưa ra giải pháp trong quản lý,
lãnh đạo.
Sơ đồ tư duy (Mindmap)
a. Nguồn gốc của sơ đồ tư duy
Được phát triển vào cuối thập niên 60 (của thế kỷ 20) bởi
Tony Buzan.
Là phương pháp được đưa ra như là một phương tiện để tận
dụng khả năng ghi nhận hình ảnh của bộ não.
Đây là một kỹ thuật để nâng cao cách ghi chép. Bằng cách
dùng giản đồ ý, tổng thể của vấn đề được chỉ ra dưới dạng
một hình trong đó các đối tượng thì liên hệ với nhau bằng
các đường nối.

29. 8/19/21
29
Review Key Topics
• Control limits
• Cost of change
• Cycle time
• Defect rate
• Escaped defects
• Expected monetary value
• Failure and success modes
• Lead time
• Problem solving
– As continuous improvement
– Team-based
72
• Risk-adjusted backlog
• Risk burndown graphs
• Risk severity
• Technical debt
• Throughput/productivity
• Trend analysis
– Lagging metrics
– Leading metrics
• Variance analysis
– Common cause
– Special cause
References
• PMI-ACP Exam Prep 2015 By Mike Griffiths, PMI-ACP, PMP
• Many other resources from Internet
73

30. 8/19/21
30
Thank you for your attention!
74