(Fair Lawn, NJ - April 15, 2018) - This is the 7th in a series of blogs posted in the first 4 months of 2018 with excerpts from an upcoming book: Project Management for Performance Improvement Teams (PM4PITs) co-authored by our COO, Bill Ruggles and H. James Harrington (pictured below) which is scheduled to come out on May 7th!
The 4th blog back on January 22nd provided an excerpt from Chapter 1 which addressed the 'traditional' approach to continual (or continuous) improvement: the P-D-C-A or P-D-S-A iterative model invented by Dr. Walter Shewhart over 75 years ago, and revised by his protege, Dr. W. Edwards Deming, in the 1950's and their 4 key shortcomings.
'PDCA' or 'PDSA' is a four-step, cyclical, and iterative model based on the 'scientific method' originally created for problem-solving or carrying out change which is often an 'improvement' over something on a continual or continuing basis. While solving a problem is NOT continual improvement, solving a series of problems continually and using those outcomes to improve performance standards and reduce performance variance IS continual improvement.
Here’s how each of the four steps of the PDCA Cycle is supposed to work:
- Plan: Identify or recognize an opportunity and plan for a potential change, including the preparation of a proposal or hypothesis. (Note: There is a lot and often TOO MUCH included in this step which often overwhelms the user and the CI Team.)
- Do: Implement or test the proposed change or hypothesis either by carrying out a small-scale experiment or study, or by conducting a 'proof of concept' pilot.
- Check: Review the test/pilot, analyze the results, and use the data to analyze and identify what you’ve learned from it. Did you validate the hypothesis or not? Did your implemented solution actually work or not? (Note: This is probably the most frequently skipped step.)
- Act: Take action based on what you learned in the Check phase: If the change did not work as expected, go through the cycle again with a different plan. If it was successful, incorporate what you learned from the test into other changes or on a wider scale. Use what you learned to plan new improvements or solve new problems. Then, either suspend the CI Initiative or begin the PDCA cycle all over again by returning to “Plan”. (Note: This step only allows for the user to Re-Plan if the outcome of the test/pilot was different than expected.)
What’s WRONG With the Traditional Framework for Continual Improvement?
In spite of its widespread use, much like the 'traditional' Project Management Framework described in our last Blog, we have encountered four serious shortcomings trying to apply this 'traditional' Continual Improvement Framework that serves as the 'engine' for Performance Improvement. It, too, falls short of providing Senior Management, the PMO, the Project Manager, the Kaizen Leader, the Black Belt, the Green Belt and his/her Project Team with the latest in conceptual and theoretical underpinnings to address the unique challenges and opportunities of 21st century projects and programs, particularly those focused on performance improvement.
These four (4) shortcomings are the following:
- The Overloaded “Plan” Step at the Front-End of the Cycle;
- The Overlooked “Check” (or “Study”) Step (3rd one) of the Cycle;
- The Inadequate “Act” Step at the Back-End of the Cycle; and
- Prevention is Missing – There is inadequate focus on new product design and performance reliability.
What’s RIGHT With the Contemporary Framework for Continual Improvement?
We address and correct ALL four of these shortcomings in Chapter 2 of our book by making the following three (3) changes to it:
(1) Add a new Step (Align) at the front end before Plan;
(2) Combine the “Check” and “Act” Steps in the middle; and
(3) Add a new “Confirm” Step at the back-end after the newly-merged step.
In addition to the above three (3) changes, we leave the “Plan” Step label as-is but refocus what it must achieve; we also leave the “Do” step and its focus, as is. In so doing, we’ve created a five (5) Step “APDCC” iterative process: “Align”, “Plan”, “Do”, “Check/Act” and “Confirm”.
In addition, we believe the interactions among these 5 Steps should not be circular; they should be iterative in the same way as the contemporary project management interactions we exhibited in our prior Blog on that topic, as illustrated in the Figure below:
We see the conditional interactions among these 5 Steps – especially between Plan, Do, and Check/Act -- in the center of the figure are more consistent with the dynamic “if-then-else” iteration of 21st century projects.
Here are brief summaries of each Step of our Contemporary Continual Improvement Model:
- Align: Identify the “opportunity for improvement” (OFI), “goal”, “pain-point” or “problem” and ensure its strategic alignment with the performing organization's Mission, Vision, and/or Core Values or a Strategic Priority with its Goals and Objectives. This can usually be done via a Business Case.
- Plan: If approved by the Executive or Steering Committee, prepare a plan or "road-map" to exploit the "OFI", “goal”, “pain-point” or “problem”, including the preparation of a proposal or hypothesis for achieving it. (Note: Now, with the "Align" step preceding this "Plan" step, there isn't as much included to overwhelm the user and the CI Team.
- Do: If the Plan or "road-map" is approved, Implement it and perform the test of the proposed hypothesis or OFI either by carrying out a small-scale experiment or study, or by conducting a 'proof of concept' pilot.
Check/Act-On: (Check) Review the test/pilot performed, analyze the results, and use the data to analyze and identify what you’ve learned from it. Did you validate the hypothesis or not? Did your implemented solution actually work or not? Then, as per the Figure above, depending on the results for that periodic interval, take one of the following three (3) actions (Act-On):
- If the actual performance-to-date, including the value of the work performed, was consistent with the planned performance and no changes are needed, then, iterate back to Do to perform the work scheduled for the next periodic interval; else
- If the actual performance-to-date, including the value of the work performed, was not consistent with the planned performance and one or more changes are needed, then, a Change Request needs to be created and submitted to the Change Control Board. If the Change Request is approved, iterate back to Plan to revise the work scheduled for the next periodic interval (and other future periodic intervals, if applicable). Then, after Re-Planning, return to Do to perform the revised work scheduled for the next periodic interval; else
- If the actual performance-to-date, including the value of the work performed, was consistent with the planned performance, there are no changes are needed, and there is no more work scheduled for the current Stage of the Life Cycle, or if the Initiative needs to be terminated prematurely before all of the work has been Done, then, proceed to Confirm to perform its activities.
- Confirm: Verify that the benefits promised in the Business Case have been delivered, the "OFI" has been exploited, its goal has been reached, or the original problem has been solved; OR, if its goal has NOT been achieved, recommend what step(s) should be taken at this time; Finalize all remaining work activities to formally close the initiative or the current Stage of the initiative. If there are remaining work activities for another Stage, Iterate back to Align and resume your CI work.
For more details regarding our Contemporary Framework for Continual Improvement, be sure to pre-order your copy of our book by going to: https://www.amazon.com/Project-Management-Performance-Improvement-Little/dp/1466572558/ref=mt_paperback?_encoding=UTF8&me=
In the meantime, please let us know if you have any questions or comments about 'contemporary' continual or continuous improvement by contacting us either at firstname.lastname@example.org or simply leaving us a comment below.