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.

Root Cause Analysis

 Root Cause Analysis is the method by which you look for reasons as to why you have the problem in the first place.

Root cause Analysis runs through many methods from the simplest “Five Whys” to the “Ishikawa Fishbone” to the “Root Cause Analysis” method above.

The Five Whys is a technique where you are “why” five times. The rationale being that as you keep asking “why something happens” you gradually get to the point where you’ve found the root cause of the problem. Of course, you might get there in less than five or it might take more - please don’t stop just because you done the five prescribed!

The 5 Whys is included in Promax as part of the 5W’s + H method which has been covered in a separate blog. The difficulty with this method is that, in most practical examples, the cause and effects are much more complex than a simple linear flow. There may be lots of possible causes and these are awkward to capture without creating multiple 5 Why’s with links between them.

Another extremely common technique for root cause analysis is the Fishbone Diagram – named because the original style looked rather like a fishbone. Essential it is a branched diagram with headings for each branch under which you place the possible causes. Common headings are to use 6 M’s which stand for Management, Man, Machine, Measurement, Material, Method. I think that this method has many flaws and creates more problems than it solves because rather than asking as you do in the 5 Whys, “why something is happening”, teams just place potential faults under each heading – there isn’t a logical rationale. This means you end up with a very long list of “Issues” which may or may not be actual causes of the problem. You then need to sift through the myriad of issues to find the most pertinent ones, which is time-consuming and not at all systematic. We haven’t included a Fishbone Diagram in Promax for that reason. By all means categorise your causes after identifying them to make managing their resolution easier, but not before.

Probably the best technique for more complex problems is to use a diagramming technique. This gives the ability to create multiple routes for causes and is therefore more applicable to real-world problems.

The diagramming technique is widely used in accident scenarios where trained investigators analyse everything they can. To do this properly is not a trivial exercise and a proper analysis will take weeks if not months. They are highly trained individuals and will go to the nth degree on everything.

It is unlikely that you will have the luxury of taking many weeks to carry out a root cause analysis but it is obviously worth spending some quality time on it. After all the result of the exercise will point you in the direction of how to solve your problem!

Promax has a “root-cause” diagramming tool where you can list your causes and draw links between them. We have introduced two types of lines: a solid line indicates you have “Proof” that it is causing the problem and a dotted line indicates that it is an “Opinion” that it is the cause of the problem.

Obviously it’s up to you to decide upon the burden of proof but I would hazard a guess that just sitting in a room drawing up the diagram without any reference to some evidence will not provide for a very good analysis. This is particularly the case when dealing with managerial change issues where ideology and prejudice skew the analysis considerably. So it’s worth developing the diagram using dotted lines (opinion) and then spend some time trying to get some evidence for those opinions (where the lines can be turned to solid). If you can’t find any evidence they obviously stay dotted. If you have a diagram full of dotted lines then you’re unlikely to have a good basis for trying to solve the problem. You’ll just end up randomly trying some resolutions with no realistic idea whether they will work.

The process is as follows:

Step 1: Identify the problem
Step 2: Identify the main causes of the problem
Step 3: Identify causes of the causes
Step 4: Draw the Root Cause Analysis diagram
Step 5: Determine how the causes occur.
Step 6: Identify ideas that can resolve the problems 

Just what is Ideality?

Ideality = Benefits / (Costs + Harms)

Ideality is a concept from Triz that suggests that the “Ideal” solution is one that has everything you need but is virtually free and has zero harms. Taken at its extreme, the ideal solution is a system that carries out the required function but doesn’t actually exist. This isn’t as far fetched as it might appear since there are many systems that work very well yet are extremely cheap and generate few harms: lines painted on floors or roads to demarcate where you should or shouldn’t be; angled entries into public toilets (restrooms) rather than install doors or pencils for writing in spacecraft rather than sophisticated pens. These are all examples where the function – what it is supposed to do – is the overriding factor in the design of the system.

What this means in practice is that you need to thoroughly understand what function you need before attempting to devise a solution. Hence the emphasis in the earlier blogs of framing and problem definition.

Promax has Ideality embedded and has a number of prompts to be used to help define ideality:

1. What is the objective? That is what function are you looking for?
2. What do you need/want? That is what benefits are you expecting?
3. What don’t you want? This is nearly always cost (the lower the better and free even better) but also other harmful factors (maybe environmental impact, safety, security, etc).

 The information you collect is then used in a number of ways going forward. First, the clarification of the objective ensures you have focus on what you’re trying to achieve with your solutions. This is used in the Idea Generation stage to make sure everyone has a clear focus of the problem.

The second element is that the benefits, costs and harms are used as the criteria against which the ideas generated can be evaluated. Ideas that give the greatest benefit for the least cost and fewest harms are, by definition, closer to ideal. We carry out the evaluation in the prioritisation stage of the Cogentus Framework and a blog on this will follow in due course.

In summary:

Ideality = Benefits / (Costs) + Harms

You’ll recognise that this equation is the same as that used in traditional evaluations. It’s the same as Value For Money – the more you get for the least cost the better and this is the context that ideas (which can be new innovations or continuous improvements) can be evaluated.

It’s worth remembering though that getting as close as possible to Ideality requires a thorough understanding of what function you are trying to achieve. Hence there’s little point in demonstrating that you have a value for money solution if you’re actually providing the wrong solution!

Use of Triz Resources

Promax has a number of tools to help with Framing and Problem Definition one of which is called Resources. 

Resources are anything within the environment of the problem that isn’t being directly used. Resources are basically free or very low cost items that are readily available. A resource can be anything and is could be easily visible, hidden or even derived from something else.

The rationale for understanding what free resources are available is that they may be useful in solving your problem. After all, why invest in something when you already have it to hand.

 

It is important to undertake a Site/Location visit to identify resources. Unless you can walk through the problem area you might not see everything and you might miss things that are taken for granted. This cannot be done from a meeting room.

There are typically four things to consider:

Materials and Objects: Are there any unused physical components in the system such as walls, floors, etc.? Are there components that are there but simply not seen such as air, water and the actual properties of substances? (“hidden”). Or are there components where the property of it could be easily changed? (derived)

Energy: Is there energy in the system such as electrical, thermal and magnetic that is not being used? Is there energy from the environment such as light that is not being used?

Space and Time. Is there space that is not being used? Is there idle time in machinery, equipment, documentation and people?

Knowledge & Information. Is there knowledge and information that is available yet not currently used?

Promax has these prompts in the Resource window and you simply create a list of things that sit under each category. These form the record from which you can use later in the ideas generation stage to see if anything can be used to help create a solution for your problem. 

Resources are a tool from Triz.

Framing using 5W’s+H

The importance of properly defining a problem before trying to generate a solution cannot be overemphasized. The most obvious outcome of poor definition is the solving of the wrong problem! It can also be that the problem might be easier solved once you understand the specifics.

There are many techniques available and Promax includes a good number that will ensure a robust identification of the real problem to be solved. 

The 5W’s and an H technique is a quick and easy way to define a problem. It is based on Rudyard Kipling’s poem:

I KEEP six honest serving-men:
(They taught me all I knew)
Their names are What and Why and When
And How and Where and Who.
I send them over land and sea,
I send them east and west;
But after they have worked for me,
I give them all a rest.

I let them rest from nine till five,
For I am busy then,
As well as breakfast, lunch, and tea,
For they are hungry men:
But different folk have different views:
I know a person small -
She keeps ten million serving-men,
Who get no rest at all!
She sends 'em abroad on her own affairs,
From the second she opens her eyes -
One million Hows, two million Wheres,
And seven million Whys!

The Elephant’s Child from the Just So Stories of Rudyard Kipling, 1902
 
The poem is used as a basis to ask a series of questions, which aims to identify all the key aspects of a problem to enable a solution to be developed that match the problem.

Process

Step 1
Ask “What is the problem?”
Step 2
Ask “Who has the problem?”
Step 3
Ask “When does the problem occur?”
Step 4
Ask “Where does the problem occur?”
Step 5
Ask “Why does the problem occur?”
Step 6
Ask “How does the cause occur?”


What is the problem?
The purpose of this question is to explain the problem in a clear manner. If the problem has a contradiction is should be stated here.

Who has the problem?
The purpose of this question is to identify the person or persons connected with the problem. They are the people who are directly impacted and will be the beneficiaries of any solution.

When does the problem occur?
The purpose of this question is to clearly identify the time related aspects of the problem.

Where does the problem occur?
The purpose of this question is to understand precisely where the problem takes place.

Why does the problem occur?
The purpose of this question is to find out what the cause of the problem is. This is accomplished by asking “why? five times

How does the cause occur?
The purpose of this question is to understand how the cause arises. From this the best solution can then be developed that will prevent the problem occurring in the future.

Example

 

Promax Screenshot

The scenario is that you manage a firm who provide security to factories and buildings. You provide staff with uniforms and equipment for their job. You’ve been receiving complaints from the staff that they need better torches (flashlights) as they’re not bright enough.

In Promax, the first tab provides a number of tools for Framing and the first button is the one for 5W’s+H. It provides the prompts and you simply fill in the boxes below each one:
What is the problem?
The torch/flashlight isn’t bright enough

Who has the problem?
The security guards at the factories

When does the problem occur?
At night when they are doing their rounds

Where does the problem occur?
Across the factories and building. Inside and outside

Why does the problem occur?
Why #1: Torch isn’t powerful enough
Why #2: Not enough battery power
Why #3: Limited to two batteries only
Why #4: The barrel can only take 2 batteries
Why #5: The barrel is sized to be comfortable to hold

How does the cause occur?
The user needs to be able to hold the torch/flashlight.

Discussion

From this, you can move on to generate ideas on how best to address the cause – in this case how best to hold the torch given the constraints of battery size.

It is worth noting, however, that the “cause and effect” analysis of the 5 Why’s is rather simplistic and is rarely, if ever, quite as simple as asking “why?” five times. Even in the extremely simple Torch/Flashlight example you can see that although we only identified one cause there could, in fact, be multiple causes possible at “Why #2”. It could be a faulty bulb, a dirty lens or poorly designed reflector. In this case you may need to use multiple lists of “5 whys” and then try to see if any are related.