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'').