PDSA

No, not a typo. There is definitely an "S" in PDSA rather than a "C". Most likely the "C"-version is best known because of the same behavior Deming tried to correct on so many occasions.

The well-known PDCA and SPC were invented by Walter A. Shewart   The impression he made on W. Edwards Deming was such, that Deming became a great advocate of Shewart's methods. It lay out the foundation of how Demming helped Japan after being defeated in WOII to become one of the biggest industrial players in the world.

"I called it Japan in 1950 and onward the Shewhart cycle. It went into immediate use in Japan under the name of the Deming cycle, and so it has been called there ever since" Out of the Crisis by W. Edwards Deming

Still, some of the credits have to go to Deming as well. In the words of Deming "Shewhart has the uncanny ability to make things difficult". So Deming spent a great deal on figuring out Shewhart's ideas, and devise ways to present them with his own twist. In this way the simple concept of PDCA came into existence.

The idea of PDCA was to act as a guide for all projects, not just quality projects.

PLAN	Objective Questions and predictions Plan to anwer the questions(who, what, where, when)
DO	Carry out the plan Collect the data Begin analysis of the data
STUDY	Complete the analysis of the data Compare data to predictions Summarize what was learned
ACT	What changes are to be made? Next cycle

When looking at the last bullet under Study, summarize what was learned, it is not hard to imagine why Deming changed the "C" into an "S". A check will only look whether something did or didn't meet the expectations. A study will look as well into why the deviations occured; both in a positive and negative sense.

In orde to do the Study correctly, the Plan must minimally contain the predictions (second bullet under Plan). And, ideally the Plan should contain the fundamental assumptions on which the predictions are based.

If you want to read a bit more about the background, there is a nice paper called Evolution of the PDSA Cycle.. It step-by-step shows how Shewhart's original ideas evolved into what we now know as PDSA.

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.

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.

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.

Oded Cohen of the Goldratt Institute in the UK developed years ago a very practical approach to deal with these kind of situations. This approach is now known as the NBr or Negative Branch.
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:

1. Construction of the NBr
2. 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.