Did Walter Shewhart Invent Project Retrospectives?
The Project Retrospective has come of age. We have books, articles, seminars and many teams adapting the technique for their project. So what are the roots of this approach which, at its core, is about tapping into the wisdom of team members to drive continuous, incremental improvement? A few key innovators of the 1930's, 1940's and 1950's recognized the need for driving product quality. Perhaps unknowingly, we've applied their theories in our project post mortems, project lessons learned meetings, and project retrospectives. The project retrospective is this decade's implementation of continuous improvement.
Introducing A Series of Articles on the Perfect Retrospective
This is the first article in a series about project retrospectives. The series includes:
- Examining Project Performance and Learning From the Project Experience - that's this article. A short recap of quality management and continuous improvement, starting with Shewhart and Deming, leading to retrospectives.
- Project Retrospectives: Perhaps Your Best Source of Valuable Improvement Ideas builds a compelling case for adopting retrospectives as a primary method for improving project performance.
- Foundations for the Perfect Retrospective gives pointers to some great information on retrospectives and gives almost a dozen tips on successfully establishing retrospectives in your organization.
- The Perfect Project Retrospective outlines your activities (pre-, during, and post-retrospective) for a constructive and effective retrospective.
- Walter Shewhart introducing of monitoring quality in a factory setting
- W. Edwards Deming introducing the notion of introducing change and validating its impact
- Japan's business leaders simplifying Deming's approach into four steps: plan, do, check, act
- Post Mortem reviews led by an investigator/facilitator to understand the reasons for a project's failure
- Lessons Learned methods driven by a project manager to understanding opinions of project performance
- Project Retrospectives involving all project team members to collectively understand project performance and identify improvement actions
The Beginning of Critical Thinking on Continuous Improvement - Shewhart
While it may be hard to believe, there was a time in the USA before the money-back guarantee was commonly offered by retailers; we couldn't have a confidence that a purchased product would be satisfactory. With some exceptions (Montgomery Ward - 1874) the quality of products was not assured. Even today manufacturers are still introducing satisfaction guarantees as though they are ground-breaking (see aircraft manufacturer Bombadier's 2011 new "Groundbreaking Parts Satisfaction Guarantee"). Such guarantees are only possible when manufacturers and retailers have effective quality control mechanisms in place.
Imagine what a quality initiative would have looked like in the 1930's. Without an understood and proven approach towards product quality, a manufacturer was pretty much in uncharted territory when it came to implementing a quality assurance program. We have Walter Shewhart to thank for his original and groundbr
In the 1930’s Shewhart first described a method for monitoring the quality of a work product in a factory setting. (I've not found anything that predates the work of Shewhart and his work is the first that I learned, so let's use his work as the starting point.) Shewhart described a three step process of Specification, Production and Inspection. He introduced the innovation of using statistical analysis of product inspection results to continually revise product specifications and the production process.eaking work on quality control - this is the genesis of thought on continuous improvement.
Page 45 of Shewhart's lecture notes on statistical process control (compiled and edited in 1939 by W. Edwards Deming as Statistical Method from the Viewpoint of Quality Control) describes these three steps in a circular diagram as an ever repeating cycle.
Shewhart essentially gives us a framework for understanding the quality of a produced item and using that information to revise product specifications. At first glance, this almost seems too obvious. Perhaps, but disappointingly, not universally applied. Consider your own experience on software teams: just how frequently have you seen the quality of your software system measured, with those results then being used to revise the software process?
Shewhart's model became the foundation for the next innovation brought to us about a decade later by W. Edwards Deming.
Principles for Improving Quality - Deming
Deming further developed Shewhart's concepts into a four step process that describe introducing an improvement and then evaluating the effectiveness of that change. (This version of his diagram is from Dr. Deming's book 1982 Out of the Crisis, P. 88).
Deming's innovation was to methodically plan improvements. After selecting an improvement action and bringing it into implementation, study the results - looking for the impact of the change and learning from these results. This cycle was called the "Shewhart Cycle" by Deming himself.
A Simplified Model for Improving Quality - Deming along with Japan's Business Leaders
Deming's four step "Shewhart Cycle" while logical, was not sufficiently memorable. Fortunately a major extrapolation and simplification has become very well known over the past sixty years.
Deming visited Japan in 1950 and presented his quality models to a large assembly of engineers and managers during a one week JUSE seminar. During this visit to Japan, he also met with the presidents of Japan's largest companies (Described in Deming: The Way We Knew Him, Page 138) at the Mt. Hakone Conference center - during these meetings Deming described a continuous cycle of Design-Manufacture-Sale-Investigative Survey, and he represented this as "The Deming Wheel."
Shortly afterwards, the concise Plan-Do-Check-Act concepts were conceived, probably by Japanese business leaders, as a simplification to Deming's concepts. In What Is Total Quality Control?: The Japanese Way, quality expert Kaoru Ishikawa (inventor of the fishbone diagram) presents this version of the Plan-Do-Check-Act wheel in the context of Deming's 1950 visit to Japan:
Plan-Do-Check-Act (PDCA) has become a well-known approach to quality improvement. It is universally known as the both the Deming Cycle and the Shewhart Cycle.
(In The Deming Seminar, which I attended in 1986, Deming distanced himself from PDCA, having come to the perspective that check was a significant understatement of the actual activity. He recast the wheel as Plan, Do, Study, Act (PDSA), with the change of emphasis to studying the impact of the change vs. merely checking on the change. While PDSA is a more accurate description of the method, it never received the same attention, thus it has not been as widely recognized as PDCA. Moen and Clifford have a fascinating paper on the creation and modification of PDCA through the years).
PDCA was a notion decades before computers and the disappointing performance of so many complex software and technology projects, yet the fundamental concepts are very relevant today for anyone involved in software projects.
Evaluating and Improving Project Performance - the Journey to Retrospectives
Innovators of previous decades provided us with a terrific foundation for quality control and continuous improvement. As well, we have an excellent current generation of thought leaders of who have brought us the concepts and methods of retrospectives. They have introduced new concepts aimed at improving performance - in essence, giving us practical implementations of the Shewhart Cycle and PDCA. Here's what I've experienced on the 30 year journey to Project Retrospectives.
The Formal Project Post Mortem - Why did this project fail?
Our initial attempt at understanding project performance is a method, probably still in use, called post mortems. It's an unfortunate term, with many negative connotations and openings for dark humor; it's even confusing to spell (one word? two? two with a hyphen?). A post mortem is generally conducted at the conclusion of a large project that experienced notable problems - project problems so significant that a company executive really wanted to know what went wrong. Quite frequently, it is led by an outsider, a person not connected with the project. I've seen that the focus is largely on the triple constraint areas (cost, scope and schedule).
Using just about any definition or description you could find of a formal project post mortem, you would logically conclude that the goals are reasonable and the methods appear to be sound. It is hard to argue against the value of assembling project data, interviewing people and validating opinions, performing an extensive root cause analysis, identifying fixes and issuing a final report. The difficulty is this: the project post mortem has a tarnished reputation that serves to diminish any enthusiasm that participants might have for the activity. Try this experiment: ask a handful of your colleagues to tell you the first thing that comes to mind when you mention the term "project post mortem" and see if any of these are mentioned:
- The only reason for conducting a post mortem is because a project has failed.
- The primary purpose of a project post mortem is to satisfy upper management's need for a report on the project failure, not to drive improvement
- Few people expect the results to actually contribute to advancing the project maturity of the organization.
- More likely than not, the post mortem will identify a guilty party, pointing blame to an individual or group.
I first participated in project post mortems in the early 1980's, and conducted my final project post mortem in 2003. Most were at the conclusion of a troubled or failed project. Through this period, I observed a declining interest by participants because they had little confidence that that goals of a post mortem would actually be achieved; it seems that my observations are in line with the experience of others. Nevertheless, the project post mortem was a very good first step aimed at learning from a project experience and using that information to help other projects.
Project Lessons Learned - How did you feel about the project?
The emergence of "Lessons Learned" appears to me to be a direct response to some of the criticisms of project post mortems. The new name is clearly a step in the right direction - most people resonate with the positive implication of "learning and improving."
Lessons learned sessions tend to use less hard data, instead relying upon opinions of team members. Here the focus is on the team's view of how well they followed their process and performed together. A typical Lessons Learned Questionnaire is peppered with "how effective . . ." "how well did . . . " and "how did you feel about . . ." questions. Lots of opinion, a bit light on data (e.g., performance relative to the triple constraint or on delivered business value).
The lessons learned activities that I've led or in which I participated were very different from project post mortems; much more upbeat, conducted for all projects (not only troubled or failed projects), and the team itself was the primary consumer of the results. They were timely, fast, inexpensive to conduct, led/facilitated by a project manager, focused more on opinion and less on project data, and was driven by questionnaire responses that were completed by project participants. If a lessons learned meeting was conducted, then the team had an opportunity to discuss their responses to the questionnaire and collaborate on identifying improvement actions. If this meeting was not part of the process, then the burden almost always fell to the project manager to interpret the questionnaire responses and determine the path forward.
Overall, I've found lessons learned activities fairly effective in getting participation by most team members, but no more effective than post mortems in driving lasting and sustained improvement.
Project Retrospectives - What wisdom did we gain and how can we best apply it going forward?
The latest incarnation of learning from experience is the project retrospective. The name has a connotation of deep thought and introspection, perhaps sprinkled with a smidgen of reminiscing. It sets a tone of constructively congregating and jointly examining the project. Retrospectives are about the shared project experience and the collective learning and wisdom gained by the team members. Of course, all of this intellectual activity is accompanied by focused action that results in improvement. The project retrospective's deep examination of the project differentiates this from the Lessons Learned approach.
The project retrospective can be effectively conducted by the project team itself (some inexperienced teams may elect to have an outside facilitator) - this is an important innovation. This improvement mechanism is not driven by an outside consultant or management; rather it is an instance of the team taking responsibility for improvement. This distributes responsibility and accountability throughout the organization, not just limiting that task to management or a project manager.
Integrating the two concepts of agile projects and project retrospectives creates the perfect petri dish for continuous improvement. Short, frequently executed project cycles with a built-in examination of project performance at the conclusion of each iteration creates a situation in which a project team can continuously observe, plan improvement actions, complete those actions, verify the impact of the improvement, and respond appropriately - this sounds remarkably like PDCA! Shewhart, Deming and Ishikawa surely would have high words of praise for any team that adopts this approach.
As with project post mortems and lessons learned, there are many varieties of retrospectives and techniques (more about these in the next article). The best project retrospectives make use of quantitative project data as well as team member observation & opinion. The team does need to develop a discipline in selecting improvement actions to maximize impact.
Project retrospectives scale very well as a primary means of continuous improvement - with responsibility distributed to project teams, there's no single constraint that limits the potential for improvement. With everyone on the project team participating, the opportunity for identifying the best improvement actions is maximized. Of course, project retrospectives have many other benefits and advantages.
There's always opportunity for a bit of improvement, the trick is tapping into facts, observations, opinions and insights of team members to understand that opportunity. Across decades we've used project post mortems, lessons learned and retrospectives - of these, the project retrospective seems particularly effective, particularly for smaller teams.
It turns out that Walter Shewhart didn't invent the project retrospective, but he certainly started us in that direction with his ground-breaking work on using statistic analysis of manufacturing to understand factory production performance; Deming and several of Japan's influential thought leaders took us further down the continuous improvement road with the innovation of Plan-Do-Check-Act. The Project Retrospective is a very powerful and practical application of PDCA.
The next article in this series, Project Retrospectives: Perhaps Your Best Source of Valuable Improvement Ideas, explains the most significant reasons for adopting project retrospectives.