provided by: 
Originally published at Internet.com ITIL indicates that systematic process improvement requires a quality management system (QMS). As usual, ITIL is sketchy about the QMS, but does mention one in particular - the Plan-Do-Check-Act (PDCA) of the Deming cycle.
PDCA is a cyclic improvement/problem resolution tool documented by Bell Laboratories scientist Walter Shewhart, the statistician who also developed statistical process control, in the 1930's.
Other Articles by Hank Marquis
Fault Tree Analysis in 6 Steps
Seven Steps to Improved Incident Handling
CFIA in 4 Easy Pieces
6 Steps to Service Outage Analysis
If you want to talk about these or any other articles you see on ITSM Watch, we'd like to hear from you in our IT Management Forum. Thanks for reading.
- Allen Bernard, Managing Editor. FREE IT Management Newsletters
In the 1950's Dr. W. Edwards Deming, friend and student of Shewhart, popularized PDCA. PDCA became associated with him and became known as the Deming Wheel even though he always referred it as the Shewhart Cycle. Six Sigma derives its Define-Measure-Analyze-Improve-Control (DMAIC) cycle from PDCA.
Later in Deming's career, he modified PDCA to Plan-Do-Study-Act (PDSA) to describe more precisely his recommendations. (In this article PDCA and PDSA are used interchangeably.)
The power of PDCA lies in its simplicity. While easy to understand, it is often difficult to accomplish on an on-going basis due to complacency, distractions, loss of focus, lack of commitment, re-assigned priorities, lack of resources, etc. Most executives claim they use PDCA or one of its derivatives, such as Six Sigma DMAIC, but few actually practice on a consistentt basis.
Cycles of Improvement
Many times there truly is no quick fix for a problem but PDCA provides a method for improving any process systematically. Practitioners use PDCA as a guide to analyze processes. The goal is to identify errors or omissions that cause the output of the process to fall short of expectations. PDCA is useful anywhere the objective is improved performance:
* As a model for continuous improvement. * When starting a new improvement project. * When developing a new or improved design of a process, product or service. * When defining a repetitive work process. * When planning data collection and analysis in order to verify and prioritize problems or root causes. * When implementing any change.
Of course, adopting ITIL spans all the above areas, so it makes sense to use PDCA for ITIL adoption as well.
PDCA is a four-step model for carrying out change. The four steps of PDCA are:
Plan: Recognize an opportunity and plan a change. Establish the objectives and processes necessary to deliver results in accordance with the specifications. Use some form of brainstorming or cause and effect diagramming (i.e., Ishikawa) to determine the problem.
Do: Implement the processes, test the change; often with a small-scale study.
Check or Study: Monitor and evaluate the processes and results against objectives and specifications and report the outcome. Review the test, analyze results, and identify what you have learned.
Act: Take action based on what you learned in the Check step. Apply actions to the outcome for necessary improvement. Review all steps the (Plan-Do-Check-Act) and modify the process to improve it.
If the change did not work, go through the cycle again with a different plan. If successful, incorporate what you learned into wider changes. Use what you learned to plan new improvements, beginning the cycle again.
An example helps make this clearer. In this example, the practitioner desires to improve their incident classification via use of diagnostics scripts.
Plan: In this step, the practitioner examines and analyzes existing incident classification by examining previous incidents. Because PDCA does not specify how to analyze data, a separate data analysis process may be used.
Do: This example has two Do steps. The first Do seeks to match classification with a diagnostic script. The practitioner plans the scripts by comparing what currently occurs with the desired state.
The second Do trials the changed process. Within set parameters, staff varies the usage of the script based on each calls unique requirements.
Check or Study: The Check or Study step includes formal and informal assessments taking place continually. If assessments show the scripts are not performing as expected, the practitioner can make changes such as re-instruction, changing the script or more direct staff mentoring. Assessment data becomes the input for the next step in the cycle.
Act: The Act step has the goal of standardizing the change. When staff meets the goals, the diagnostic script design and usage are standardized. Staff shares best practices in formal and informal settings. Results from this cycle become input for the "analyze" phase of the next cycle.
FOCUS-PDCA
FOCUS is an acronym for Find, Organize, Clarify, Uncover, and Start. FOCUS sets the stage for PDCA. Combining FOCUS with PDCA can dramatically improve results. FOCUS-PDCA is a nine-step process with five FOCUS steps, and four PDCA steps. The five FOCUS steps are:
Find an opportunity for improvement. You need to select a process or activity that you want to modify. Examples might include how you handle major incidents, or trying to improve script accuracy for routing of tickets.
Answer the question, "What is wrong?" For example, regarding scripts, the questions might be, "Why do 65% of all scripts coded as 'A1' route to network instead of database?"
Organize a team. Always approach the solution to the question from a team perspective - this is the only way to really improve. The best ideas come from those doing the work, so involve them. Find those that understand the opportunity and related systems or processes. Ask yourself, "Who knows about this?" and make them part of the team.
Clarify the opportunity. Using team leadership skills, work to really understand the opportunity, have the team dissect what currently happens, and brainstorm possible new ways of working. Use Ishikawa "fishbone" diagrams and other means. Have the team seek to answer the question, "What is involved?"
Understand the causes. After clarifying the opportunity, seek to identify why, where, or how the undesired activity or result occurs. Lead the team in answering the question, "Why isn't it working?"
Start the PDCA cycle by choosing a single modification to the process. Working with the team, choose the most likely cause of the undesired result and develop a new approach to doing that work. Answer the question, "Where should the change occur?"
Try using the FOCUS method with PDCA. Use tools and techniques such as Fault Tree Analysis (FTA), Component Failure Impact Analysis (CFIA), Pareto Analysis and others to Plan to improve operations by determining what is going wrong and developing potential solutions.
Use small groups and group management techniques to solve the problems on a small or experimental scale first. This minimizes disruptions to routine work while the testing is underway.
Trend analysis, critical success factors (CSF) and key performance indicators (KPI) are critical to Check if the small scale or experimental changes are achieving the desired result or not.
Continuously check key activities (regardless of any experimentation) to assess output quality at all times in order to identify new or potential problems.
If the experiment was not successful, skip the Act stage, go back to the Plan stage to determine new ideas for solving the problem, and repeat the cycle.
Act to document and implement the changes on a larger scale if the experiment is successful. Standardize the changes and make the changes the "new normal." Involve stakeholders (staff, departments, suppliers, or customers) affected by the changes whose cooperation you need to implement on a larger scale.
Structured usage of PDCA can produce amazing results but you have to you use it, and use it properly.
Hank Marquis is a managing partner and CTO at itSM Solutions. You can contact Hank at hank.marquis@itsmsolutions.com.
Author: Hank Marquis
Read article at Internet.com site