conflict resolution | Coepd

1
Conflict Resolution techniques
(Professional Business Analyst Training
organisation)
2
.

• Conflicts are part of daily work. We have seen
  situations where people with different goals and
  needs have clashed. If we resolve it in an
  effective way, we can also eliminate many of the
  hidden problems.

3

• Steps for Conflict Resolution.
• Understand the scenarios -
• Promote the good relationships through respect
  and good behavior is most important. Separate the
  problem from the person and identifies the real
  issues. Listen carefully each persons interests.

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.
   
4
Steps for Conflict Resolution. 2. Collect the
Information An conflict resolution tool,  is the
ability to go in depth  than the surface to get
an understanding of an individuals needs and
concerns. We should be objective not personal
and try to view our actions from the standpoint
of the other person.

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.
   
5

• Below are few ways to effectively gather
  information
• Identify the issues We should be clear and
  concise never try to solve all problems at once.
• Listen carefully Put our self in the other
  persons shoes and try to understand how the
  problem is affecting him or her.

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.
   
6

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.
   

• Below are few ways to effectively gather
  information
• No assumptions For instance, dont assume that a
  supervisor is angry with a staff person when he
  actually feels frustrated about their conflicting
  communication styles.

7
Steps for Conflict Resolution. 3. Identify the
true Problem- Conflict resolution skills can
only come into play when the true problem is
identified. We make  sure everyone agrees on what
the problem is before moving forward. Remember
that different roles, interests and conflict
resolution styles. Keeping aside individual goals
to come to a mutually agreeable and beneficial
solution is an important step in conflict
resolution.  
8
Steps for Conflict Resolution. 4. Brainstorm on
the Possible Solutions Gathering the involved
parties together for a brainstorming session not
only helps to resolve the problem in quick
manner, but it makes everyone feel like they are
part of the solution.  
9
Steps for Conflict Resolution. 5. Do Not
Postpone Conflict Resolution Act on the
conflict immediately. Otherwise, the situation
could affect the performance.  Address the
situation with careful consideration the decision
will directly impact on the demeanor and
performance of the staff.  
10
(No Transcript)