Identifying Contradictions and Conflicts

Introduction
Resolving conflicts and contradictions is the single most important aspect in solving a problem. Without a thorough understanding of those issues obtaining a good solution to the problem is likely to be impossible.


The technique discussed here is an excellent process to elicit those conflicts and contradictions.

Earlier, a system model was developed that described the components of the problem and what functions are being carried out. A Conflict Resolution Diagram (CRD) takes this system model one step further with the aim of identifying any conflicts in the system. Whilst you can use the system model and embellish, it is often better to produce a separate diagram of the conflicts in order to simplify what will, undoubtedly, be a complicated diagram.

The process is as follows:
Step 1: Identify the Objective
Step 2: Determine the Requirements.
Step 3: Determine the Pre-Requisites
Step 4: Identify the Conflicts
Step 4: Identify Focus Areas

Note, steps 1 through to 4 can be carried out in any order. Sometimes, the conflicts are clear but other aspects aren’t. Sometimes it might not be clear what is the objective. You shouldn’t be too rigid, only to be sure that all the steps have been done.

Objective
The objective clarifies the main purpose: what is it that you are trying to achieve? Place a box to the left hand side and articulate the objective.

Requirements
Requirements are the necessary conditions in order to satisfy the objective. Although the example only shows two boxes; this is for simplicity and most objectives will have many requirements. Please note that requirements are “essential” (Needs) and not just “nice-to-haves” (Wants). Place each requirement in a box to the right of the objective.

Draw an arrow from the Requirement box to the Objective box. It is good practice to write each relationship in the form of: “In order to have (OBJECTIVE) we must have (REQUIREMENT). You don’t need to display the text but it helps to clarify to everyone the thinking behind the requirements.

Pre-Requisites
Pre-requisites are the necessary conditions to satisfy the Requirement. This is usually described as an action (verb) and is the place where conflicts occur. Place these in boxes to the right of the Requirements.

Draw an arrow from the Pre-Requisite box to the Requirements box. Here, there are two things worth adding to the line. The first is to write down the relationship in words using the form: “In order to have (REQUIREMENT) we must have (PRE-REQUISITE). Again writing the words clarifies the diagram. Secondly, you should list all the assumptions being made in determining that this particular pre-requisite is needed for the requirements. Assumptions are the “why something is needed”. If you wish, once you’ve listed all the assumptions, you can extend the words used to describe the line thus: “In order to have (REQUIREMENT) we must have (PRE-REQUISITE) because (ASSUMPTIONS)”.

 Listing assumptions is a tricky part and you need to be very careful to make sure they are, in fact, valid. Assumptions are particularly vulnerable to bias, prejudice and misunderstanding. They vary considerably depending on people’s value systems, which has been derived from the previous experiences and culture.

Conflicts
On the diagram, identify any pre-requisites that are competing against one another. These are usually called “Conflicts” or “Contradictions” There are two different ways they could compete. One is that you can’t have both pre-requisites at the same time; a sort of “A or B but not both”. The second is that as you improve one pre-requisite the other one gets worse; a sort of trade off situation.

For each pre-requisite that is competing, draw a line between the boxes. In Promax there are line shapes for the two different types In summary:

• Technical Contradictions: used for trade offs where as one pre-requisite improves the other gets worse
• Physical Contradiction: use where you can have A or B but not both. 

As in the previous steps it is good practice to write the rationale behind the conflict in the relationship line. A suitable form could be: “On one had we must have (PRE_REQUISITE #1) but on the other hand we must have (PRE-REQUISITE #2).

In some cases, the conflicts appear easy to see and articulate. Sometimes less so. Often they are a combination of “hard” facts and “soft” opinions. Hard facts are things where the contradiction is based on an evidence-base such as a limited resource or plain and simple physics. Soft opinions are based on peoples perceptions and values that are harder to establish. It is worth spending some time separating the two and to not dismiss the soft opinions because they go against your (or your organisation's) opinion. This is the single biggest cause of failure in solving problems where people are involved; the solution might be more that simply changing a process step – it might require significant cultural change.

Identify Focus Areas
From the conflict resolution diagram, it is likely that there may be several, or even many, areas of conflict. We need to focus in on the ones we believe would make the biggest difference to solving the problem. We call these “Focus Areas”.

List all the areas that you wish to focus on for the next stage where you want to generate ideas. The Focus Areas can be broad or narrow but it does need to be clear what it is you want to focus on.

It is in the next phase (Ideas Generation) that we generate ideas that could be used to solve the conflict (called “Injections” in the Theory of Constraints). We use the Triz tools “Technical Contradictions” and “Physical Contradictions” to help identify potential solutions to the conflicts. These are extraordinary powerful techniques and are significantly better than simply brainstorming and will be discussed in later blogs.

At this stage, it is true that it is difficult to prioritise which of the Focus Areas are most important since you don’t know what the effect will be on the objective if that particular conflict is resolved. However, if you have used most of the techniques from the Framing Stage, you will certainly have an excellent understanding of the problem and will be able to have an informed opinion. However, it is also true that you may need to work through more of the Focus Areas in an iterative manner, gradually resolving all the conflicts until you reach the “Ideal Final Result”.







References
"Goldratt's Theory of Constraints", H. William Dettmer (1997) is an excellent book on TOC.

Mapping the Problem

It is almost always worth trying to draw a diagram of your problem. A visual representation can often uncover “hidden” aspects that are often missed or misunderstood. As well as providing a mechanism to get to the heart of the problem it can also be a good way to identify solutions.

There are many different ways to map the problem. Promax focuses on “Functions” because we can use systematic tools later on in the process to analyse the functions and generate ideas on how to solve the problem. Other techniques for mapping rely on trial and error for solving problems, which is less efficient.

The process is quite simple. First identify all the elements and components of the problem. The components within this “system” are then linked to reflect the interactions occurring. The function is then written alongside the link.

There is therefore always three parts to any link – the Subject, the Action being carried out and the Object. Actions are always verbs.

Different colours are often used to represent the different components of the problem. In the example, drawn in Promax, the boxes are either items (grey), inputs (black) or objectives (green). Promax has seven different line types of which the following are shown; dependency (black arrow), useful (green arrow), insufficient (dashed green arrow), wasteful (red arrow) and excessive (double green arrow).

By colour coding in this way it is easier to hone in on where the problem lies. 

There are other types of mapping commonly used including;
* Value Stream Mapping (VSM)
* Process Flow Diagrams (PFD)
* Su-Field Analysis (Su-F)
* Southbeach Notation
* Systems Dynamics (SD)
* Simulation Modelling

They all have a similar objective – to explain pictorially how the different items within the system interact with each other. Sometimes the information is used to calculate time, quantities and volumes within the system. They vary somewhat in what is represented and how they are represented and are often used by different groups of professionals depending on their background and training.

Value Stream Mapping (VSM) is used in Lean Six Sigma. It differs from functional mapping in that the function and the item are listed in the same box. Arrows are used purely to indicate the movement from one box to another.

Process Flow Diagrams (PFD), often called flowsheets, are used by chemical and process engineers. These list the main components of a systems. Product Flow Diagrams are also called PFD’s and are mostly used by Project Managers to illustrate how the different products of a project are related.

Su-Field Analysis (Su-F) is used by Triz practitioners.

Southbeach Notation is a nomenclature for most types of modelling using colours and shapes to express some of the Triz terms.

Systems Dynamics (SD) is used by social scientists and often has a calculation component included within it. Unlike spread sheets you can model "circular arguments" where things in the systems can continually increase.

Simulation Modelling is used by operational research professionals on specific problem types. It is rarely purely a visual representation but the components and relationships between them is written in computer code with the aim of carrying calculations on the whole system such as throughput.