PMI-ACP Domain VI: Problem Detection and Resolution v1.0

9/7/19
1
DOMAIN VI
Problem Detection and
Resolution
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

9/7/19
2
Tasks
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

9/7/19
3
• How Problems Impact a Project
5
• How Problems Impact a Project (cont.)
6

9/7/19
4
– 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
– 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

9/7/19
5
• Cost of Change
– More work will need to be
undone to fix it (and then
have to be redone)
– The more stakeholders will
be impacted by the defect,
making it that much more
expensive to fix
– agile methods emphasize
frequent verification and
validation
10

9/7/19
6
• Cost of Change (cont.)
– both through active
stakeholder
participation (such as
modeling,
demonstrations, and
reviews, …)
– and through software
development practices
(such as pair
programming,
continuous integration,
and test-driven
development)
11
• 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
– It increases the cost of
development and making
changes in the future because
we’ll have to do all the
standardization and clean-up
work that has been put off.
Ex: Refactoring code
12

9/7/19
7
• 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
13
• Failure Modes: Problems often arise for reasons that can be prevented
è 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. Let’s review them to understand the issues
involved
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? 14

9/7/19
8
• 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
15
• 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
16

9/7/19
9
• 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
17
Detecting Problems

9/7/19
10
Detecting Problems
• Diagnostic tools such as
– [T&T] Lead Time and Cycle Time
– Defects
– Variance Analysis
– Trend Analysis
– Control Limits
• can point to potential problems before they occur or
help us identify problems as soon as possible after
they have occurred
19
Detecting Problems
• [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
20

9/7/19
11
Lead Time vs. Cycle Time
Ø Lead time: how long something takes to go through the entire process
Example: The time a story enters the deployed stage minus the time the
story has entered the backlog stage. Story 34 has entered the backlog in day
4, and enters the deployed stage on day 11; lead time equals 7 days (day 11-
day 4).
Ø Cycle time: how long something takes to go through part of the process
Example: (Deployed stage cycle time) The time between two stories entering
the last stage deployed stage in this case. Story 34 enters the deployed stage
on day 11, then two days after, the next story-- Story 37--enters the deployed
stage; cycle time equals 2 days (day 13 – day 11).
Detecting Problems
• [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
22

9/7/19
12
Detecting Problems
• [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.
23
Detecting Problems
• Defects
– Defect cycle time is the period
between the time the defect was
introduced and the time it was
fixed
– cycle time is also useful for finding
and fixing defects
– 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.
24

9/7/19
13
Detecting Problems
• [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
25
Escaped Defects (Leakages)
Ø An escaped defects is a defect that was not found by, or onethat
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)

9/7/19
14
Detecting Problems
• [T&T] Variance Analysis => Causes of Variation
– Quality expert W. Edwards Deming classifies variance into
common cause variation and special cause variation
• Common cause variation refers to the average day-to-day
differences of doing work,
• And special cause variation refers to the greater degrees of
variance that are caused by special or new factors.
– Deming goes onto say that there are two classic mistakes that
managers make:
• Mistake 1: Reacting to an outcome as if it came from a
special cause, when it actually came from common causes
of variation
• Mistake 2: Treating an outcome as if it came from common
causes of variation, when it actually came from a special
cause.
27
Detecting Problems
• [T&T] Variance Analysis => Accept the Variance or Take
Action
– The main point is that we should simply accept common
cause variation on our projects; we 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
28

9/7/19
15
Detecting Problems
• [T&T] Trend Analysis
– 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
• Ex: The amount of budget consumed
– Leading metrics that provide a view into the future
29
Detecting Problems
• [T&T] Trend Analysis (cont.)
– 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.
30

9/7/19
16
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.
31
Managing Threats and Issues

9/7/19
17
• 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
33
• [T&T] Risk Adjusted Backlog
– The risk response activities are added and prioritized(based on their anti-
value), It can be referred to as a “risk-adjusted backlog.”
34

9/7/19
18
– Step 1: Step 2:
• Next, we need some way to monetize the
risk avoidance and risk mitigation activities.
To get this figure, we can calculate the
expected monetary value of each risk
• Expected Monetary Value (EMV) = Risk
Impact (in dollars) x Risk Probability (as a
percentage)
• we are looking for relative amounts rather
than precise numbers
we should 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
35
– Step 2 (cont.): we can rank the project risks to produce a prioritized list of
threats and issues, ordered by expected monetary value, as shown below
36

9/7/19
19
[T&T] Risk Adjusted Backlog
(cont.)
– Step 3: Of course not all risks will have
avoidance or mitigation steps that we
can schedule into the project.
• 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, as
illustrated below
37
• [T&T] Risk Adjusted Backlog (cont.)
38

9/7/19
20
• [T&T] Risk Adjusted Backlog (cont.)
– We should think of the risk-adjusted backlog as a tool that uses
calculations only to get at what is truly important—the priority
of the work items that need to be done.
– The true benefit of this tool is that it helps the product owner
and the development team bridge the communication gap and
have meaningful discussions about schedule and scope trade-
offs. So although we assign numerical values to help level the
playing field, creating a risk-adjusted backlog is really more of a
qualitative practice than a quantitative practice
39
• 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

9/7/19
21
• Risk Severity (cont.)
– Risk Severity = Risk Probability x Risk Impact (a simple scale—such a slow(1),
medium(2), and high(3)
– Using this scale, a risk that has a high probability and a high impact will have a risk
severity of 3 x 3 = 9. On the other hand, a risk that has a high probability and a low
impact will have a risk severity of 3 x 1 = 3. You can see how this would help shift our
attention away from specific dollar amounts so that we can focus on the bigger picture
41
42
– As the project progresses, the
team can expand this table to
record how their attempts to
manage the project risks are
working. The next chart shows
the progress of the risks over the
first four months of the project

9/7/19
22
43
• [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
44

9/7/19
23
• [T&T] Risk Burndown Graphs
45
Solving Problems

9/7/19
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. This
minimizes the need for ad hoc problem solving during the
iterations
• 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
47
Solving Problems
• 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
48

9/7/19
25
Solving Problems
• Considerations and Cautions for Engaging the Team
– Despite the benefits of engaging the team in problem solving,
this is not a silver bullet or a cure-all approach. There are some
points that we need to keep in mind about using this approach,
including some cautions:
• Involve the team where it can be most helpful
• Solve real problems
• Team cohesion is necessary
• Check in after team or project changes
• Be sure to follow through
• 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.
49
Problem - Solving Techniques
Ø Establish Yourself as a Devil’s Advocate – Establish that you are
going to ask a bunch of questions, some naive, some pointed, but
that your goal is to help them reverify their assumptions, not to
promote an alternate idea or criticize theirapproach.
Ø Be Kind, Rewind – Ask lots of “why” questions and continue
pushing back towards the root problem.
Ø Don’t Let Them Linger on Meta-Problems – When a problem seems
too big to hold in your brain, it’s tempting to seek respite by focusing
on manageable meta-problems. While those problems may need
solving, they are distractions from the real issue that is blocking
progress.
Ø Ask Probing Questions – Make them talk through each decision
and ask stupid questions.

9/7/19
26
Problem-Solving Techniques
Ø Use Reflective Listening – This is a communication technique where you
repeat back a summary of what the other person just said to you to
confirm understanding. Another benefit in this situation is thathaving
the person hear their own ideas in another person’s voice/words may
make it easier for them to be objective.
Ø Avoid Injecting Your Own Ideas – At some point you may have agreat
idea for a better approach but avoid them.
Ø Lead Them to the Answer – If they simply aren’t making progress and
you know a good answer consider leading them to the answer witha
line.
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
52
• Risk-adjusted backlog
• Risk burndown graphs
• Risk severity
• Technical debt
• Throughput/productivity
• Trend analysis
– Lagging metrics
– Leading metrics
• Variance analysis
– Common cause
– Special cause

9/7/19
27
References
• PMI-ACP Exam Prep 2015 By Mike Griffiths, PMI-ACP, PMP
• Many other resources from Internet
53
Thank you for your attention!
54

9/7/19
28
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
55
• 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
56

9/7/19
29
• 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.
57
Shift-left testing
58

9/7/19
30
Steps in TDD
59
Acceptance-driven development (ATDD)
60

9/7/19
31
Continuous Integration (CI)
61
Techniques for problem solving
• 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.
62

9/7/19
32
Techniques for problem solving
• 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.
63
Problem Solving with
5W1H – 5M
- Brainstorming – ISHIKAWA - Mindmap

9/7/19
33
Áp dụng công thức 5W1H
What (Cái gì)? Vấn đề là gì? Công việc nào cần thực hiện?
Who (Ai)? Ai thực hiện công việc? Ai chịu trách nhiệm về vấn
đề?
Where (Ở đâu)? Vấn đề xảy ra ở đâu?
When (Khi nào)? Vấn đề đó xảy ra khi nào?
Why (Tại sao)? Tại sao lại xảy ra vấn đề như vậy? Tại sao là công
việc này/người này mà không phải là công việc khác/người khác?
How (Như thế nào)? Người phụ trách công việc đã thực hiện nó
như thế nào?
Áp dụng công thức 5W1H (cont.)
Xác định
vấn đề
Phân tích vấn
đề
Đưa ra giải
pháp

9/7/19
34
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
Quy Tắc 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.

9/7/19
35
Tập kích não (Brainstorming)
b. Các bước tiến hành
Bước 1: Chọn ra trưởng nhóm và thư ký
Bước 2: Xác định rõ vấn đề cần kích não
Bước 3: Thiết lập luật chơi
Bước 4: Bắt đầu kích não
Bước 5: Lược lại các ý kiến và tổng kết
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.

9/7/19
36
b. Sử dụng biểu đồ xương cá khi nào?
Khi có nhu cầu tìm hiểu một vấn đề, xác định nguyên nhân
gốc.
Khi muốn tìm ra tất cả các lý do dẫn đến phát sinh vấn đề,
tiến trình giải quyết vấn đề khó khăn, các vấn đề phát sinh
khác hoặc những thất bại.
Khi muốn tìm hiểu lý do dẫn đến tiến trình không đưa đến
kết quả mong muốn.
Đặc biệt là để tìm ra cốt lõi, nguyên nhân (chính và phụ) của
vấn đề.
c. Biểu đồ xương cá hỗ trợ như thế nào?
Một biểu đồ xương cá sẽ trình bày cho bạn những nguyên
nhân của vấn đề và những lý do tại sao bạn không cải tiến
như bạn nên làm.
Biểu đồ xương cá cho phép bạn nghiên cứu những nguyên
nhân, quyết định những nguyên nhân nào bạn có thể kiểm
soát và những cái nào bạn không thể. Dựa vào đó bạn có thể
kiểm soát, sau đó bạn có thể bắt đầu phát triển các chương
trình cải tiến với những mục tiêu cụ thể trong đầu. Nó cho
phép bạn đi tới gốc rễ của vấn đề chứ không phải triệu
chứng.

9/7/19
37
d. Các bước tạo một biểu đồ xương cá
v Xác định vấn đề
Ghi lại chính xác vấn đề một cách chi tiết (áp dụng 4W:
What, Who, When, Where). Viết vấn đề vào ô bên phải
tờ giấy. Sau đó kẻ một đường ngang, chia giấy của bạn ra
làm hai. Lúc này bạn đã có “đầu và xương sống” của con
cá trong sơ đồ xương cá.
– Xác định các nhân tố ảnh hưởng
Ứng với mỗi nhân tố, vẽ một nhánh “xương sườn”. Cố
gắng liệt kê càng nhiều nhân tố càng tốt.
Ví dụ: Hệ thống, cơ sở vật chất, máy móc, nguyên liệu,
yếu tố bên ngoài,… Nếu bạn có một nhóm để xử lý vấn đề
thì đây là lúc cần phải động não.

9/7/19
38
– Tìm ra nguyên nhân có thể có
Những nguyên nhân này thuộc về từng nhân tố (đã tìm ra
trong bước 2), ứng với mỗi nguyên nhân, lại vẽ một
“nhánh xương con”. Nếu nguyên nhân của bạn quá phức
tạp, có thể chia nhỏ nó thành nhiều cấp.
– Phân tích sơ đồ
Sơ đồ đã xây dựng là một danh sách đầy đủ các nguyên nhân
có thể xảy ra, bạn có thể kiểm tra, khảo sát, đo lường,… để
xác định đâu là các nguyên nhân chính rồi từ đó có những kế
hoạch cụ thể để sửa chữa.
Ví dụ: Phân tích các nguyên nhân của vấn đề: “Thiếu kỹ năng quản
lý". Sau khi thảo luận để tìm ra nguyên nhân, nhóm làm việc
biểu diễn bằng một sơ đồ xương cá như sau:

9/7/19
39
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.

9/7/19
40
Viết hay vẽ đề tài của đối tượng xuống giữa trang giấy và vẽ
một vòng bao bọc nó.
Đối với mỗi ý quan trọng, vẽ một đường phân nhánh (nhánh
cấp 1) xuất phát từ hình trung tâm.
Từ nhánh cấp 1, tiếp tục vẽ ra các phân nhánh (cấp 2, 3,...)
các ý phụ bổ sung cho ý đó. Từ các ý phụ này, lại mở ra các
phân nhánh chi tiết cho mỗi ý.
Tiếp tục vẽ hình phân nhánh các ý cho đến khi đạt được giản
đồ chi tiết nhất.
Hình minh họa:

9/7/19
41
Thank you for your attention!
81

PMI-ACP Domain VI: Problem Detection and Resolution v1.0

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PMI-ACP Domain VI: Problem Detection and Resolution v1.0

Similar to PMI-ACP Domain VI: Problem Detection and Resolution v1.0 (20)

More from PhuocNT (Fresher.VN)

More from PhuocNT (Fresher.VN) (20)

Recently uploaded

Recently uploaded (20)

PMI-ACP Domain VI: Problem Detection and Resolution v1.0