cause and effect diagram

8
Cause and Effect Diagram (Professional Business Analyst Training organisation)

Upload: coepd

Post on 18-Jul-2015

58 views

Category:

Education


4 download

TRANSCRIPT

Page 1: Cause and effect diagram

Cause

and

Effect Diagram

(Professional Business Analyst Training organisation)

Page 2: Cause and effect diagram

•Cause and Effect diagram devised by Professor Kaoru

Ishikawis also known as Ishikawa diagram or Fishbone

diagram. This diagram helps to categorize all possible

causes of a specific problem, and identify the reason

for a process not working out.

Page 3: Cause and effect diagram

•This is one of the great visual tools to use during

brainstorming session to focus on the conversation and

help the group to determine important causes with more

detail. The diagram resembles the skeleton of a fish and

hence the name ‘Fishbone diagram’ is given.

Page 4: Cause and effect diagram

Why use Cause and Effect diagram?

· Easy to read format to draw out cause and effect relationships in an orderly manner.

· Recognizes areas of collecting information.

· Increase process knowledge.

· Group participation is encouraged to gather data.

Page 5: Cause and effect diagram

Traditional BA (Waterfall) Agile BA

Requirements are documented in Use

Cases,Business Requirements, Functional

requirements, UI Specifications, Business Rules.

Requirements are documented in Epics, User

Stories and optionally Business (or Essential) Use

cases.

Focuses on completeness of requirement and

spends time in ensuring the requirement is

unambiguous and has all the details.

Focuses on understanding the problem and being

the domain expert so that s/he can answer

questions from the development team swiftly and

decisively.

Focuses on getting a ‘sign off’ on the requirements.

Focuses on ensuring the requirements meet the

currentbusiness needs, even if it requires

updating them.

Often there is a wall between the BA/Business and

the Development team.

Agile BA (Often called as Product Owner) is part of

the team.

Tends to dictate solutions.

Has to remain in the problem domain, leaving the

development team ‘space’ to explore different

solutions.

Long turnaround. Quick turnaround.

Focus on what the requirements document said. In

other words, output (Artifact) is a well written

thorough requirements document.

Focus on the functionality of the developed

software. In other words, output (Artifact) is the

software that meets thebusiness needs.

Page 6: Cause and effect diagram

Steps for constructing Cause and Effect diagram

· Identify the problem to be analyzed which is the head.

· Create a problem box displaying the problem and draw spine (draw horizontal arrow pointing to the right).

· Identify the main causes contributing to the problem. These causes are displayed as arrows to the spine similar to the bones of the fish. .

Page 7: Cause and effect diagram

· Sort out other causes influencing the problem (effect).

· Analyze the diagram to determine the root cause.Hence, Cause and Effect diagram drives out all the causes of a problem using the 5 W’s (when, where, why, who, what) to provide an effective solution.

Page 8: Cause and effect diagram