Select Page


Continuous Improvement (#5 in the series Deming’s 14 Points in Project Management)
By Josh Nankivel

Dr. W. Edwards Deming recently re-introduced to me in my Project Performance and Quality Assurance class. I have heard of him before and touched on some of his philosophy in other classes, but focused much more in-depth this time. The majority of his philosophy around quality and organizational management resonate with me. So, I’ve decided to do a series of articles on Deming’s 14 points, and how they relate specifically to the field of project management. I may decide to not touch on all of them or I may. I am not really sure at this point.

This is one of my favorite points from Dr. Deming. I see so many mistakes that are made again and again, and lessons learned that are either completely undocumented or filed away after a project, never to be seen again.

Do all of the other project managers in the firm get exposure to lessons learned from other projects? Usually not, in my experience. Surely, individual project managers and sponsors learn from their projects, but organizational learning and continuous improvement require a formal process for the documentation, analysis, and incorporation of lessons learned into a common methodology.

Of course, I believe the only way to truly be committed to continuous improvement is to have a common, shared project management methodology in the first place. I’m not saying that project managers should be drones working within a system telling them how to eat, breathe, and sleep. The common methodology should provide a structure and guideline however, with some components on the more mandatory side while some others may be a guideline in which the project manager can work.

If a project manager has a suggestion based on personal experience as to improving the methodology, there should be a process in place to do so. Any proposed change should have a clear correlation to a problem that needs to be solved. The continuous improvement process should not be left up to volunteer suggestions, however. It should be a part of the methodology and how the business runs a project.

I can suggest a skeleton process:

  1. Establish a formal process by which lessons learned are documented regularly while executing projects, and put in a format and location where they are visible to all and can be later analyzed.
  2. After each project is finished, analyze the project in terms of performance in the triple constraints, stakeholder satisfaction, and other metrics important to your organization.
  3. For negative points identified in #2, use the 5 Why technique to document root causes. Do some statistical analysis on these root causes to determine their frequency, correlation to the negative points identified, and the estimated cost/time involved with potential solutions.
  4. Implement selected solutions on a beta test with one or a few projects, clearly defining the points at which the test process diverges from the firm’s common methodology.
  5. Analyze the results in the beta projects of these specific changes.
  6. Based on the successes or failures of the beta testing, implement changes in the common methodology.
  7. Rise and repeat.

You may notice that the skeleton process above fits within Deming’s Circle. That is:

  • Plan – 1-3
  • Do – 4
  • Study – 5
  • Act – 6

Josh Nankivel is the Vice Chair of Special Projects for the Students of Project Management SIG of PMI, and a project management student/enthusiast. His website is

Recommended PM App

Recommended PM App