The most common and natural way to deal with weakness seems to trying to strengthen the weakness. But did you ever consider smartly exploiting the weakness as a direction to deal with the weakness?
Showing posts with label TOC. Show all posts
Showing posts with label TOC. Show all posts
Friday, April 8, 2011
Thursday, March 24, 2011
Biotexing and Decision Making
Labels:
biotexing,
Caluwe,
decision making,
project,
success,
Theory of Constraints,
TOC
Friday, April 30, 2010
Finding the cause for the majority of the issues
Wouldn't it be wonderful by following some simple steps it is possible to find the root of what is causing the majority of the issues?
One has to remember, often, if not the root, the solution lies outside the periphery we tend to look for solutions. Therefore out-of-the-box thinking is required to address the root of the majority of the issues.
The Cloud is a tool that finds its origin in ToC (Theory of Constraints). It is excellent for finding root causes of the majority of the issues.
Basically it is a very compact description of a dilemma. When examining several dilemmas it is usually possible to extract a few, or even one, generic dilemma: a description of a reoccuring dilemma. There are many uses for this: explanation of what happens in the past and now, prediction for the future ...and a good guide to effectively deal with the reoccuring dilemma.

There are several techiques and instructions around to construct a cloud and a generic cloud. Here I present the technique I developed over the years. The technique is very reliable and others are quite successful in using it as well. Best of all, same input usually generates very similar conclusion ...this can't be said of some other techniques.
The following is a real case where I'm the coach of a programme manager who feels he needs to improve himself. You might recognise yourself or a generic issue. Fine, but the scope of this blog is the specific case for this programme manager. For home work I asked him to following:
We practised together two:
Two interventions are not enough, but after little more than one week I got a list with 15 interventions. This is more like it, following some rules it structured the data in such a way that all what was required to see if there was a commonality between one or more dilemmas.
One has to remember, often, if not the root, the solution lies outside the periphery we tend to look for solutions. Therefore out-of-the-box thinking is required to address the root of the majority of the issues.
The Cloud is a tool that finds its origin in ToC (Theory of Constraints). It is excellent for finding root causes of the majority of the issues.
Basically it is a very compact description of a dilemma. When examining several dilemmas it is usually possible to extract a few, or even one, generic dilemma: a description of a reoccuring dilemma. There are many uses for this: explanation of what happens in the past and now, prediction for the future ...and a good guide to effectively deal with the reoccuring dilemma.
There are several techiques and instructions around to construct a cloud and a generic cloud. Here I present the technique I developed over the years. The technique is very reliable and others are quite successful in using it as well. Best of all, same input usually generates very similar conclusion ...this can't be said of some other techniques.
The following is a real case where I'm the coach of a programme manager who feels he needs to improve himself. You might recognise yourself or a generic issue. Fine, but the scope of this blog is the specific case for this programme manager. For home work I asked him to following:
- List all the interventions you took or wanted to take in the past 3-6 months
- For each intervention:
- List why it was / would be good to take that intervention
- List why it was / would be good NOT to take that intervention
- What goal did you aim for that required both above
We practised together two:
| Intervention | Why good to | Why good not to | Goal/Aim |
| Call resource manager | - personal contact - keep a project member | - maintain relation - steering committe takes their role | maintain relationship |
| Escalate to senior supplier | - project member will return - senior supplier takes his role | - maintain relation - respect the decision | to force a solution |
Two interventions are not enough, but after little more than one week I got a list with 15 interventions. This is more like it, following some rules it structured the data in such a way that all what was required to see if there was a commonality between one or more dilemmas.
In this case there was, to be precisely everything seem to fit into one generic dilemma:
Two question had to be answered:
- Do you ever let something go wrong?Answer: seldom
- Does the formulated objective (green box) match what you feel is what you are trying to achieve and seems so hard to achieve?Answer: yes
Then we discussed the validity of the generic description of his core dilemma. It matched.
So how to read the cloud:
- You demand people (steering committe members, resource managers, etc) to live up to their roles and responsibilities in order to improve the probability for succes in your project.
- However, you feel you should not demand people to live up to their roles and responsibilities because you must respect their positions and this makes you look powerful.
- If you demand people to live up to their roles / responsibilities, you do not respect them (you know better and act like a boss rather than a subordinate or equal) and you look weak because you can't manage.
- On the other hand, if you do not demand people to live up to their roles and responsibilities it is very hard or impossible to improve the success of your project
- And, you need both to improve the probability for success of your project and to respect people's positition and to look strong in order to fulfill your objective: make steps forward in the project and that people associate you with delivering good results.
We explored his generic dilemma using his home work and other situations. It was a very good respresentation for his situation.
The theory of the cloud says: as long as you are captured in the dilemma, you will not achieve your objectives. You might do a bit of both, make some trade-offs, you will never achieve what you want because you need BOTH necessary conditions. Any solution MUST positively contribute to both necessary conditions (the blue boxes) at the same time.
With this we have the focus, we have very clear criteria for any solution or idea to improve his situation.
He is going to talk to some senior programme managers he knew who are quite successful and try to learn how they deal with the dilemma. What do they do to ensure that stakeholders take-up their responsibility and that respect is paid to the position of the stakeholders? He knows how to value any suggestion or proposed idea.
So, with a couple of simple questions and following some rules to construct the generic cloud, the dilemma that caused so many issues latetly for this programme manager became very explicit. And, at the same time we have focused his attention on the characteristics the solution must have in order to work for him. This is very helpful to think-out-of-the-box.
Labels:
continuous improvement,
creativity,
out-of-the-box thinking,
Theory of Constraints,
Thinking Processes,
TOC
Wednesday, February 10, 2010
Problem Solving vs Goal Realizing
During my education I wrote an application letter for an internship pointing out my problem solving skills. The reply was short: "we don't have problems". At that time my mindset was such that I only could laugh; who doesn't have problems to solve?
Later when working for the A. Goldratt Institute in The Hague I became interested in how NLP would fit in the ideas of the Theory of Constraints (TOC) and in particular the Thinking Processes and MSW.
Problem solving vs goal realizing, two sides of the same coin? Semantics?

Because if you solve all your problems, you achieve your goal. Or, what blocks you from your goal are problems that must be solved.
Well, for some time I thought this as well. However, then I came in a stage of life thinking of a serious relationship and having a family. Slowly it started to dawn on me. The best way to solve problems is by preventing them. The amount and depth of problems I would encounter with having a serious relationship would go up. They would sky rocket by having a family. So, the problem-solving strategy would be not to start a relatinship and have a family. Yet, this would create a situation that would seriously limit, block would be a better word, the achievement of my goal.
Of course the above example is my own personal one. Other people have different goals and different requirements. However, I feel most can relate to the above personal example and possibly see a similar situation for themselves. It is quite possible, sometimes necessary, to create additional problems in order to achieve your goals. Equally, it is quite possible, very often I presume now, that you can solve most if not all of your problems and still be far away from achieving your goal.
So far most, if not all, the tools, methods, approaches or whatever that is usually associated with problem-solving that I learned and practised can be used for goal realizing. The key difference between problem-solving and goal realizing is not the skills and tools, it is the attitude and mindset. And, it makes all the difference. Both for myself and my customers.
Goal-realizing means stepping outside the seemingly obvious. Finding out what is really being pursued and ensuring that this is being realized. It also means that the rapport you create with the customer is based on what the customer finds important. And, if you are your own 'customer', this is even more important.
Intended or not, that short reply I got "we don't have problems" triggered a very nice understanding many years later.
Later when working for the A. Goldratt Institute in The Hague I became interested in how NLP would fit in the ideas of the Theory of Constraints (TOC) and in particular the Thinking Processes and MSW.
When I confronted the TOC-community with the question whether TOC is problem-solving or goal-realizing, all chose problems-solving. Interesting to note, the break-through of TOC was the book called The Goal. One of the first steps in the Thinking Processes is to define the goal and how to measure it. This is very similar to Lean or Six Sigma.One of the NLP things that struck me was that if you focus on something you will create a perpetual situation. Let me explain. In relation to problem solving it would mean that you will create an ongoing situation where problems must be solved; e.g. self-fulfilling profecy of ongoing problem solving. NLP therefore tends to focus on what one wants to achieve, rather than what one doesn't want. So rather saying that you're good in problem solving (which is a 'negative' thing), you would say that you're good in goal realizing (which is a 'good' thing).
Problem solving vs goal realizing, two sides of the same coin? Semantics?
Because if you solve all your problems, you achieve your goal. Or, what blocks you from your goal are problems that must be solved.
Well, for some time I thought this as well. However, then I came in a stage of life thinking of a serious relationship and having a family. Slowly it started to dawn on me. The best way to solve problems is by preventing them. The amount and depth of problems I would encounter with having a serious relationship would go up. They would sky rocket by having a family. So, the problem-solving strategy would be not to start a relatinship and have a family. Yet, this would create a situation that would seriously limit, block would be a better word, the achievement of my goal.
Of course the above example is my own personal one. Other people have different goals and different requirements. However, I feel most can relate to the above personal example and possibly see a similar situation for themselves. It is quite possible, sometimes necessary, to create additional problems in order to achieve your goals. Equally, it is quite possible, very often I presume now, that you can solve most if not all of your problems and still be far away from achieving your goal.
So far most, if not all, the tools, methods, approaches or whatever that is usually associated with problem-solving that I learned and practised can be used for goal realizing. The key difference between problem-solving and goal realizing is not the skills and tools, it is the attitude and mindset. And, it makes all the difference. Both for myself and my customers.
Goal-realizing means stepping outside the seemingly obvious. Finding out what is really being pursued and ensuring that this is being realized. It also means that the rapport you create with the customer is based on what the customer finds important. And, if you are your own 'customer', this is even more important.
Intended or not, that short reply I got "we don't have problems" triggered a very nice understanding many years later.
Labels:
Lean,
MSW,
Six Sigma,
Theory of Constraints,
Thinking Processes,
TOC
Friday, February 5, 2010
Dealing with Half-Backed Ideas
Plenty of situations where you, or others, might have an idea. The idea sounds okay or even great, but ...there is a but. The idea is not 'perfect'. The idea has some serious negatives as well. Result: some people try to chop the idea down, some are resisting the chopping.

The NBr is part of what is known as the MSW (Management Skills Workshop). A subset of the Thinking Processes of the Theory of Constraints.
The NBr is a process in two phases that is simple, organic and very effective. The two phases are:
- Construction of the NBr
- Trimming the NBr
The best way is to use post-its.
A short video on how to read an NBr
The basic steps for phase 1, the construction of the NBr, are:
Note: Some of the items put aside will be used in a 'because'. Some of them will not be used for different reasons.
That's all and now you have a pretty good NBr on the idea that is not only verbalizing clearly why some oppose the idea, it is also easy to communicate.
The next phase is finding where the best place is to trim the NBr; the place to look for some additional ideas to prevent the negatives from coming into place.
The basic steps for phase 2, finding a pivot point in the NBr, are:
Why the NBr works so well
The NBr isn't a guarantee a solution will be found. What the NBr as a process does is to ensure a proper and shared understanding is created. Further more, it moved the focus of the discussion towards were the energy is needed. The point were a solution must be found for the idea to work without the negatives.
A very smart way of slowly but steadily changing the perception of both the idea generator and the one(s) who see negative ramifications on the idea. A very novel way to help people think out-of-the-box.
Labels:
NBr,
Negative Branch,
Theory of Constraints,
TOC
Subscribe to:
Posts (Atom)
