SD Bronze

Online Collaborative Evaluation

Our newest addition to the Smart Decisions range in Bronze. This is for simple evaluations (up to 6 options and 6 criteria) where participants are geographically distant. Create options and criteria and score remotely. Full discussions can be done online and the results displayed instantly. Download to Gold or Platinum to carry out more sophisticated analysis of results.

For more information go to our website page

Smart Decisions

Promax is now "Smart Decisions".

We feel the name more accurately reflects its capabilities in supporting problem solving. We've now moved this blog to our main website (http://www.cogentus.co.uk/news/) and so updates to this one will be discontinued.

If you want to read more on the latest updates to the software please go to the main website (http://www.cogentus.co.uk/).

More Ideas, Better Ideas

In order to come up with innovative solutions you need ideas. If you only have a few ideas, the chance of identifying a good solution is unlikely. In general, if you have more ideas you will improve the chance that you will hit upon a good solution. However, you want not just more ideas, but better ideas. This chapter describes a range of techniques that will enable groups and individuals to improve the quality of their idea generation enormously.

For many years the typical approach to generating ideas has been “Brainstorming”. This is a technique from the 1950’s where ideas are generated within a group setting. The rules are that the group should be multi-disciplinary and that all ideas should be expressed freely without discussion, debate or ridicule. The ideas are then posted to a flip chart or wall. However, there is substantial evidence that this technique, however popular, is not very good at generating ideas. Research has shown, repeatedly, that it is much less effective than individuals working on their own. The reason why it continues to be popular lies in the belief that the “sum is greater than its parts” – that it must be better to pool the knowledge of a group and rely on one or two individuals. Unfortunately this is not the case. Groups are not very good at coming up with ideas unless the rules of traditional brainstorming are changed.

There are three main reasons why traditional brainstorming is not effective:

1. Trial and Error. Generating ideas randomly is by its very nature a trial and error process. This is both inefficient and ineffective.
2. Psychological Inertia. These are the barriers we all have in coming up with ideas. Our background, culture, previous experiences and education all constrain our thought patterns. We only know what we know.
3. Assertive Participants. It is a fact that the most powerful, assertive and confident people in the group propose the most ideas. The rest of the group tacitly accept them with very few additional ideas generated; it is extremely difficult for quiet and introverted people to make a difference even if they might have the best ideas!

These shortcomings, however, can be addressed to significantly improve brainstorming sessions (which are probably better referred to as Group Working). Trial and Error can be replaced with structured thinking processes. Psychological Inertia can be addressed with tools that encourage “out of the box” thinking and improved group working processes will ensure that all participants can contribute effectively.

Techniques for generating ideas vary between those that are suitable for a broad focus (where you need a lot of ideas) to those that require a narrow focus (where you need better ideas). The focus area is established during Framing/Problem Definition stage and it cannot be stressed enough that you need to have an adequate definition before attempting to generate ideas – otherwise different people will have different views and the ideas that are generated won’t have much relevance.

There is one technique, called Brain Writing, that is less associated with generating ideas per se but is more about how to improve working within a group. It will resolve the issue of assertive participants.

Techniques for generating ideas for a broad focus (lots of ideas) come from “creativity”. These tools break down the psychological inertia that prevent individuals from generating ideas. There are a huge number of creativity tools and there’s no reason to know them all. The ones described in this chapter provide a good range to suit most groups and problems:

• Themes 
• Questioning
• Random Connections 
• Superheroes
• Analogy

Techniques for generating ideas for a narrow focus (better quality ideas) come exclusively from “Triz”. These tools are based on the principle that somewhere, someone has already solved a problem similar to yours. Therefore, if you can access this prior information you can find a solution. It requires a good problem definition but is guaranteed to generate a range of high quality solutions in a very short period of time. Again, there are many different tools available and the selection below provides coverage for most:

• Inventive Principles
• Technical Contradictions
• Physical Contradictions
• Standard Solutions
• Trimming

When generating ideas, these are best placed into an “Ideas Bank”. This is simply a repository that holds all the ideas in one place. Once ideas have been generated the final step is to refine the ideas in order to develop the options that will provide the best solution.

Future blogs will examine these techniques in more detail. Promax is specialist software for problem solving, innovation and decision support. It includes all the tools mentioned above for generating ideas. It has prompts for creativity tools and over 2,000 examples for Triz tools.

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!