PDCA Shouldn't Always Lead to Improvement

 PDCA (Plan, Do, Check, Act), and its alternative PDSA (Plan, Do, Study, Act), are popular quality improvement frameworks. The truth is, they shouldn't always lead to improvement. If every single PDCA cycle you implement leads to improvement, I'd suggest you take a deeper look. Maybe you're not doing PDCA properly.

Briefly, PDCA is about the following 4 steps:

• P - Plan an improvement experiment. Plan how to test if this proposed improvement really brings about an improvement.
• D - Do the experiment.
• C - Check / Study the results of the experiment.
• A - Act on the results of the study. Implement the change or perform another cycle. 

The 3rd step in PDCA, Check, requires you to check the results of what you did in the 'Do' step. The output of performing Check can result in one of the following conclusions:

•  The proposed improvement works, let's implement it.
• The proposed improvement actually makes things worse, let's not implement it.
• The proposed improvement is not an improvement, or not enough of an improvement, let's not implement it.

The point of C (or S) is to serve as a control gate so we don't implement changes that are not worthwhile improvements.

Problem Solving

So many different techniques being peddled on how to solve problems.

How did we get so prolific at creating problems without any training at all?

Often, people don't go about creating problems for others, but merely solving their own problems. Their solution inadvertently creates problems for others (and sometimes for the person who came up with the solution as well).

So, if a persons has the problem of failing business revenues and solves that problem by coming up with new products, then the other businesses may experience loss of revenue and all the problems that bring.

Mind the Gap

 Mind the Gaps. Or, why systems fail to deliver.

The sponsor and the stakeholders describe the problem situation to the professionals whose job is to solve the problem. Their description does not describe the problem properly.  They may present relatively minor problems as serious ones, they may forget some aspects, they may disguise some problems, they may have solutions in mind and describe problems in terms of the solutions. They may even be innocently unaware of the real problems. 

The actual problem is different from the one they described.  The first gap: The real problem state P, and the described problem state P'

The system developers conceptualise solutions for P'. The chosen conceptual solution S may seem to address P' but conceptual incongruencies remain hidden,  That is,  S may solve some aspects of P' but not as much as thought.  The second gap.  S vs S'.

The builders build T, the implementation of S.  T is never perfect and falls short of the expectations of S.  What is delivered is T'.  The 3rd gap.

T' is operated not as ideally as it should.  It becomes T''.  The 4th gap.

In the end, we have solution T" being used to solve problem P, whilst also delivering its own new set of problems p(T''), producing a new problem situation P(T'').

Risk-Managed Men

Manage your risks or your risks will manage you.

Do risk management or be risk-managed men. 

(Get it? "risk-managed men", rhymes with "risk management". No?)

Bruce Lee is a Lean Guru

"Absorb what is useful, reject what is useless, add what is essentially your own" - Bruce Lee

"Useful" = value

"Useless" = waste

"Your own" = don't just copy the TPS.

No Stupid Questions, Stupid

 Playing with the order of the words:

No stupid questions.

No questions, stupid.

Stupid! No questions!

Stupid questions,  no.

Questions, stupid? No?

Questions? No? Stupid.

Training

The essence of training is acquiring or improving skills.  If you undergo training, and no change occurs in how you do the things you were trained at, then the training did not matter.

If you had a certain way of planning projects, and underwent training on how to plan projects more correctly, then you went back to your way (which was not as good), then the training did not matter. Sometimes the reason you went back to the old way was not due to yourself. Perhaps the organisation you work in prefers the old way, and resists the new way (a very common situation), then you face incongruity. You know what you're doing is not as effective as the new way, but you 'have no choice'. It takes a lot of effort to try and change an organisations. If you tried, you may end up alienating people, or making enemies. There is also the risk that your execution of the new way won't be as effective as the old way. This is a real risk, because after all, you are just a beginner in the new way.