The difference between an Obstacle and an UDE

20 January 2017, Jelena Fedurko

In the Facebook discussion of my recent blog post If an Injection is a solution you knew BEFORE you built the Cloud, why did you need the Cloud? I wrote a phrase that clearly stated that there is a difference between an Obstacle and an UDE. The phrase read “… are obstacles for the implementation, rather than system UDEs.” Thereafter, I was asked what is the difference between an Obstacle and an UDE.

I think that the confusion between the two may be caused by the fact that from the point of view of the global meaning, an UDE is, of course, an obstacle to achieving the desired performance level of the system.

However, when we speak about the difference between an Obstacle and an UDE as TOC Thinking Processes elements, there are four aspects to it.

Aspect 1 – the essence of each of these two TP tools

Speaking about an Obstacle and Intermediate Objective (IO) as elements of TP, they are elements of the secondary layer. An Obstacle is a derivative of the solution. We can identify an obstacle(s) to a specific solution only AFTER we have this solution. Hence, we start speaking about an obstacle, and do the logical work with it AFTER we have developed the solution to the problem. And an IO is a derivative of an Obstacle.

However, we work with an UDE as an element of TP, BEFORE WE HAVE A SOLUTION TO THE PROBLEM. An UDE is a loud signal of the problem in the system. An UDE is what everybody knows and speaks about, has taken steps to sort out, but it keeps on reappearing, and there is NO KNOWN SOLUTION (not on the surface) of how to STOP THE UDE FROM REAPPEARING.

For the reference – here are the 10 Rules for a statement to be qualified as an UDE:

1. UDE wording consists of a short, simple sentence – it cannot contain a cause-effect relationship.
2. The UDE is an ongoing problem that exists in your reality, and which does not allow your system to perform better.
3. It is a not a one-time recent action or event – its wording cannot have verbs like ‘get,’ ‘go,’ etc.; the wording should describe the state of the system.
4. It is within your area of responsibility.
5. Something can be done about it.
6. It must not be blame.
7. It must not be a speculated cause.
8. It must not be a hidden solution (wishful thinking for solving the problem).
9. It does not require clarification of its negative impact/effect.
10. It must not be subjective – it should not contain such words as ‘difficult,’ “hard,” “poor,” etc.

Aspect 2 – the wording

An Obstacle is ANYTHING that blocks an implementation of an idea. The wording of an Obstacle is usually of the nature of “don’t have”, “won’t get” or “don’t know”. The implied solution for the situation is obvious and usually has a ‘mirror reflection’ wording: “have”, “have received”, “have learnt”. I have seen in various TP material such ‘mirror reflection’ wording suggested for an Intermediate Objective. I do not agree with the value of such IO wording, but this is a whole different subject.

In short, the wording of an Obstacle implies a solution. This is what makes the clear cut difference between an Obstacle and an UDE, because an UDE must not be a hidden solution (Rule 8 of the 10 UDE Rules above).

Therefore, the statements of the type “We do not have the specifications”, “Our machines are old”, “Our server room is too small”, “We do not have enough qualified personnel”, etc. can be treated as Obstacles, but cannot be accepted as UDEs because their wording presents a pretty obvious solution, and often the one that is not that hard or long to implement:

“We do not have the specifications” –>”Get the specifications from somebody who certainly has them”

“Our machines are old” –> “Buy newer machines/Reject orders that cannot be properly produced on these old machines/Find subcontractors with the new machines and pass over these orders to them”

“Our server room is too small” –> “Move the server room to a bigger room”

“We do not have enough qualified personnel” –> “Train personnel/Hire new personnel that have all required qualifications”

Aspect 3 – the ‘destiny’ of the notion recorded in an Obstacle vs an UDE

There is another clear cut between an Obstacle and an UDE: a notion that has created an Obstacle MAY STAY, while an UDE must NOT STAY, it must be removed.

What does it mean – a notion that has created an Obstacle may stay? If we find a way to prevent it from blocking us from achieving what we want, then it stops being an Obstacle, while still being there.

In our discussion of the subject, Oded has brought up an example of a mountain that is blocking the way. Oded, thanks for helping me presenting this aspect in the clearer way!

The mountain is clearly an obstacle to achieve the desired outcome – to get to a certain point. However, to remove this blockage, one does not have to remove the mountain. The mountain may stay, and the road may go around it, or up to the tip and down on the other side, or a tunnel can be cut through, etc. These all are solutions in order to stop the mountain from preventing me from getting to the other side.

Aspect 4 – a frequent confusion between an UDE of the system and an Obstacle to the implementation of the solution to remove the system UDEs

Statements of the type “Top management do not have time to properly monitor the implementation”, “People that are supposed to be doing tasks on integrating the new system are too busy with their everyday work”, “The client is not doing its share of work”, “The budget that the client has is not enough to give them the needed service”, etc. are not UDEs of the system, but Obstacles that a consultant faces in the implementation.

Comments

Jelena Fedurko, 20 January 2017