The Shewhart cycle, and the various models it gave rise to, is central to understanding project and programme life cycles. It is also the origin of some product development approaches used in projects – notably Scrum.
The cycle emerges from the principles of the ‘Scientific Method’, which is commonly said to originate with Galileo but arguably has its roots in the teachings of Aristotle. It is a method for developing ideas based on observation, then testing them through experiment and finally refining, changing or eliminating the ideas.
Dr. Walter Shewhart adapted the scientific method for industry and presented it as a linear flow of ‘specification’, ‘production’ and ‘inspection’. In 19391 he changed this linear sequence to a cycle to show how refinement and change lead to an iterative approach to product development.
The Shewhart cycle was further developed by W. Edwards Deming2 in what became known as the ‘Deming Wheel’.
In 1950 Deming presented his ideas to the Japanese Union of Scientists and Engineers (JUSE), this became popularised as the Plan, Do, Check, Act cycle or PDCA.
Deming never liked the word ‘check’ and preferred ‘study’ – hence Deming’s PDSA cycle, which he always referred to as the ‘Shewhart cycle for Learning and Improvement’.
Shewhart and Deming focused on the development of consumer products that were created and sold in a ‘business to consumer’ market but the PDCA cycle is an important principle in contemporary project management, particularly when comparing predictive and agile types of project.
By its very nature, the PDCA is iterative, i.e. it is repeated multiple times until the desired result is achieved. The iterations can be represented as shown below:
The PDCA cycle is found throughout projects and programme life cycles. For example, the life cycle for a simple low complexity, low uncertainty (predictive) project typically comprises four phases. The PDCA cycle will be evident in each phase.
In the identification and definition phases, requirements management captures the wants and needs of customers and, through solutions development, refines these into a specification. This is not a linear process. In the case of a building for example, the customer will articulate what they want and an Architect will translate that into a conceptual design (Plan), which will be used to create a computer model of the building (Do). The customer will comment on the model (Check) and, if accepted the Architect will revise the drawings or issue them to a builder or, if the customer has lots of comments, repeat the cycle is until the customer is happy (Act).
For a more detailed explanation of the history and evolution of the Shewhart/PDCA/PDSA cycles, click here. In the delivery phase, detailed scheduling of the work that achieves the specification will occur (Plan), the work will be performed (Do), the products of the work will be subject to test and approval (Check) and will be either accepted or rejected (Act). Plans will be reviewed in the light of progress and change requests before the next cycle. Once everything is accepted the project can be closed.
The simple building project can be contrasted with the more complex project to develop the software that was used to design the building. Let’s say that the mandate for the software development project is to “Develop an innovative building design software package for small to medium architectural practices using the latest technology.”
Sounds good, but what does it mean? What exactly does ‘innovative’ mean, ‘what type of buildings are these architects involved in’ and ‘what does the customer mean by “latest technology”’? Very often, even the customer won’t know exactly what they want until they see some examples and can say “Yes, that’s it” or “No, that’s not what I meant”.
This is not the sort of project where doing all the design work up front and then moving to delivery is appropriate. There are high levels of uncertainty about the scope of the work and how to achieve that scope. The approach here will be to reduce the identification and definition phases and bring specification, production and inspection together in short cycles during the delivery phase.
In a less complex project, the PDCA cycle is used for design in the early phases and for product development in the delivery phase. In a more complex project or programme the PDCA cycle brings design and delivery together into a combined iterative approach focused on the delivery phase.
- Shewhart, W. A. 1939. Statistical Method from the Viewpoint of Quality Control. Department of Agriculture. Dover, 1986, page 45.
- Deming, W.E., 1950. Elementary Principles of the Statistical Control of Quality, JUSE.