PDCA Cycle: Plan Do Check Act, Steps, History and Examples

Train teams faster and more effectively with AI

Start Free

A team changes the way it does something, rolls the change out to every site at once and moves on. Three months later someone asks whether it worked. Nobody wrote down the starting figure, nobody said what result to expect, and the people who ran the change have no way to tell an improvement from a good month. The PDCA cycle exists to stop that happening.

I'm an instructional designer at Coursebox, where we make an AI tool for building employee training, so I'll mention our product where I tested it. PDCA comes from quality management, and most of what follows applies to any process: a production line, a ward, a support desk or a course. I explain each step, where the cycle really came from, why Deming preferred "Study" to "Check", and what the research says about how teams use it. Then I run one hypothetical hotel through a full cycle, show five real cases and share a free cycle log you can reuse.

What is the PDCA cycle?

The PDCA cycle (Plan, Do, Check, Act) is a repeating four-step method for improving a process: plan a change and what it should achieve, try it out, check the results against the plan, then standardise, adjust or drop the change.

View the full-size diagram

It is also called the Deming cycle, the Deming wheel and the Shewhart cycle, and a close relative, PDSA, swaps Check for Study. Nobody has claimed authorship of the four-step version, so the clearest definitions come from the people who used it. In the Japanese version reproduced by Moen and Norman in Quality Progress in 2010, Plan means "Define a problem and hypothesize possible causes and solutions", and Act means "Return to the plan step if the results are unsatisfactory, or standardize the solution if the results are satisfactory." ISO's committee for quality management, in its guidance on the process approach in ISO 9001:2015, describes PDCA as "a tool that can be used to manage processes and systems".

Here are the four steps at a glance, with the question each one asks.

The cycle is meant to repeat. Each turn starts from what the last one taught you, and a change that holds becomes the new standard that the next cycle tries to improve. It works on anything you can change and measure: a machine setting, a hospital ward routine, a sales process or a course.

The first case shows what a small, well-aimed test looks like, on a training problem most organisations will recognise: people not finishing their e-learning.

Case study: Nurses finishing their e-learning in New Delhi

A government eye hospital in New Delhi asked its ophthalmic nurses to complete two online infection-control modules. After 8 weeks of tracking, only 12 nurses (5%) had finished the first module and 2 (0.8%) the second.

• What they did: A small team found the barriers: no protected time on busy shifts, no free computers, a server that "kept lagging and crashing" and a mistaken belief that the modules had to be done with the informatics team present. They tested change ideas through several PDSA cycles in one ward of 9 nurses: 2 hours of protected time on the roster, a reserved computer in each ward, a fixed server with round-the-clock support, and coaching in computer skills.
• Evidence and result: Dolma and colleagues reported in the Indian Journal of Ophthalmology in 2022 that the pilot ward reached 90% completion of both modules within 2 weeks, so the changes were scaled to all nurses. At 24 weeks, 227 of 232 nurses (98%) had finished the first module and 222 (96%) the second.
• Limitation: Completion is not knowledge or infection-control practice. An administrative order to finish the modules was issued at week 19, so the final figures are not the cycles' work alone. There was no comparison group, the report is a one-page letter and it does not give the number of cycles.
• Lesson: When people do not finish a course, test the barriers to access on one small group for two weeks, track completion weekly on one chart, then scale. If you add a mandate, report it as a separate lever.

Who invented the PDCA cycle?

Nobody invented PDCA in one go. The cycle grew from Walter Shewhart's work in 1939, Deming's teaching in Japan from 1950 and Japanese managers who recast Deming's ideas as Plan, Do, Check, Action. Deming himself never adopted the PDCA wording. Here is the history in order.

Shewhart's circle (1939)

The idea starts with Walter Shewhart's 1939 book, Statistical Method from the Viewpoint of Quality Control, based on lectures he gave in March 1938 and edited by Deming. Shewhart described three steps in quality control: specification, production and inspection. He wrote that "these three steps must go in a circle instead of in a straight line", and that they "correspond respectively to making a hypothesis, carrying out an experiment, and testing the hypothesis" (pp. 44 to 45). His figure shows the straight line, labelled old, beside the circle, labelled new, and he suggested that a spiral would be an even better picture. Shewhart's 1920s work was the control chart, so the cycle itself dates from the late 1930s.

Deming's wheel (1950)

Deming took the idea to Japan in 1950. His version was a management cycle for products. Describing it to a US government roundtable in 1980, he said: "It is a plan for management: 4 steps: design it, make it, sell it, then test it in service. Repeat the 4 steps, over and over". In Out of the Crisis (1986) he credited Shewhart: "I called it in Japan in 1950 and onward the Shewhart cycle. It went into immediate use in Japan under the name of the Deming cycle" (p. 88).

The Japanese PDCA (early 1950s onwards)

Masaaki Imai wrote in Kaizen (1986) that "Japanese executives thus recast the Deming wheel and called it the PDCA wheel, to be applied in all phases and situations" (p. 60). He gives no year and names no one. Moen and Norman date the change to 1951 and note that "No one has ever claimed ownership of this revision". The Japanese version put weight on standardising a result that worked, so the same fault would not recur. Kaoru Ishikawa later described it as a rephrasing of F. W. Taylor's "plan, do, see", and divided it into six categories, one of which reads "Engage in education and training" (1985, p. 59). So one of the best-known Japanese accounts of PDCA puts training inside the cycle.

Deming's PDSA (1986 to 1993)

Deming kept working on his own version. In 1986 his figure already asked teams to carry out a change "preferably on a small scale" and then "Study the results. What did we learn? What can we predict?" (p. 88). In The New Economics (1993) he printed "The PDSA Cycle", which he called "a flow diagram for learning, and for improvement of a product or of a process" (p. 134). Moen and Norman quote a 1990 letter in which he wrote, "Be sure to call it PDSA, not the corruption PDCA."

Which PDCA sources to read

• Moen and Norman, "Circling back" (Quality Progress, 2010). Read this one first. It is short, traces the cycle from Shewhart to the Model for Improvement and explains how PDCA and PDSA differ. The authors work for the firm that developed the Model for Improvement, so they write from the PDSA side.
• Langley and colleagues, The Improvement Guide. Read it for running cycles in practice: aims, predictions, small tests and linked cycles. The second edition (2009) is the one the Institute for Healthcare Improvement cites.
• Deming, The New Economics (1993). Read pages 134 to 136 of the first edition for PDSA in Deming's own words, including his three options for the Act step.

The four steps of PDCA, worked through one example

Here is the example I'll use for every step. It is hypothetical, and every figure in it is illustrative. A hotel group runs six city hotels of about 150 rooms each. At one pilot hotel, the executive housekeeper owns a problem: rooms cleaned by new room attendants, in their first 30 days, fail the floor supervisor's first inspection too often. Over the last 4 weeks, the supervisors' existing inspection log shows that new attendants' rooms passed first time 64 times out of 100. Experienced attendants passed 91 out of 100. The bathroom causes most fails (hair on surfaces and water marks on glass), followed by bed making and restocking amenities. A departure room takes 32 minutes on average, and every failed room means a re-clean and a later check-in.

New attendants currently get a 2-hour slide induction on day 1 and two shifts shadowing an experienced attendant. Many have cleaned rooms elsewhere, but nobody should assume they know this hotel's standard. The people involved are the executive housekeeper, two floor supervisors who inspect rooms and coach, and the group's training coordinator, who owns the induction. The intended outcome is new attendants whose rooms pass first inspection at least 80% of the time by their third week.

I chose this example because it shows PDCA clearly. The data already exists, because supervisors inspect every room and log pass or fail. Results come back within days. And the change being tested is a training change, judged by a workplace result rather than a quiz score.

1. Plan

Plan is where you decide what to change, how you will know whether it worked and how small the first test can be. Deming put it plainly: "Planning requires prediction" (1986, p. 88). The Institute for Healthcare Improvement's Model for Improvement frames the planning around three questions, which "can be addressed in any order": "What are we trying to accomplish?", "How will we know that a change is an improvement?" and "What change can we make that will result in improvement?"

• What it asks: an aim as a number and a date, one change or one small package of changes to test, a written prediction of its result, the measures you will use and the size of the test.
• In the hotel example: the aim was 80% first-time passes for new attendants by their third week. The change was that a floor supervisor cleaned each new attendant's first 5 rooms side by side, using a one-page, bathroom-first checklist of 12 points with photos of the pass standard, and the attendant self-checked against it before calling for inspection. The slide induction was cut to 45 minutes. This is a package of related changes, so a good result would not say which part did the work. The prediction, written before the test: first-time passes would rise from 64% to at least 80% within 3 weeks, and cleaning time would rise by no more than 3 minutes a room. The outcome measure (the result we wanted) was the first-time pass rate, the process measure (whether the change was actually done) was the share of rooms where the self-check was done, and the balancing measure (a check that nothing else got worse) was minutes per departure room. The test ran at the pilot hotel only, with the next 3 new attendants, for 3 weeks.
• Watch for: a plan that says "improve quality" with no number, no date and no prediction. Without them, Check has nothing to compare against.

Improvement teams often use three kinds of measure: an outcome measure (the result you want), a process measure (whether the change was actually done) and a balancing measure (a check that nothing else got worse).

2. Do

Do means carrying out the change as planned and recording what actually happens. Deming's 1986 figure says to "Carry out the change or test decided upon, preferably on a small scale" (p. 88). Ishikawa placed training in this step, a reminder that people need to know what the change asks of them before the test starts.

• What it asks: run the test as planned, collect the measures as you go and write down anything that departs from the plan, with the date.
• In the hotel example: the supervisors ran the side-by-side cleans and logged every inspection. One supervisor was on leave in week 2, so the other covered both floors. One attendant skipped the self-check on busy days. Both went into the log, because both affect what the results can show.
• Watch for: dropping awkward results or changing the test halfway without noting it. A deviation you record is information; one you hide makes the Check step misleading.

3. Check (or Study)

Check means comparing the results with the starting point and with the prediction you wrote in Plan. The Institute for Healthcare Improvement's guide to testing changes puts it as "Compare the data and result to your predictions." Deming called this step Study and asked: "Do they correspond with hopes and expectations? If not, what went wrong?" (1993, p. 136).

• What it asks: the result for each measure, set against the baseline and the prediction, and an honest statement of what the data can and cannot show.
• In the hotel example: the results are below. Bathroom items were still the most common fail. Cleaning time averaged 35 minutes, 3 more than before, exactly at the limit set in the plan. The process measure fell short: one attendant skipped the self-check on busy days.
• Watch for: reading a good number as proof. Three attendants over three weeks, with no comparison group and a supervisor away for a week, can show a promising direction but cannot rule out other causes, such as a quieter fortnight.

The pass rate moved in the predicted direction and stayed above the 80% aim from week 2. When the change is training, choose the measure carefully. A first-inspection pass rate shows whether people clean rooms to standard, so it sits closer to the behaviour and results levels of the Kirkpatrick model than a quiz score or a satisfaction survey would.

4. Act

Act means deciding what to do with what you learned. Deming gave three options: "Adopt the change, or Abandon it, or Run through the cycle again, possibly under different environmental conditions, different materials, different people, different rules" (1993, p. 136). The Japanese PDCA put the weight on standardising: Imai wrote that once an experiment succeeds, "methodological standardization is taken to ensure that the new methods introduced will be practiced continuously" (1986, p. 61).

• What it asks: a decision to adopt, adjust or abandon, a reason for it, and either the next test or the steps that make the change the new standard.
• In the hotel example: the housekeeper decided to adjust and run a second cycle at the same hotel, adding a 3-minute bathroom demonstration on the first shift and keeping the checklist. If the pass rate held at 80% or more for the next 4 new starters, the change would become standard at the pilot hotel: the training coordinator would update the induction, the checklist and the supervisor guide. Only then would a second hotel test it. Had the first cycle failed, the hotel would have dropped the change, gone back to the old induction and kept what it learned.
• Watch for: rolling one good cycle out to all six hotels. One cycle at one hotel is a single test, and standardising too early spreads a change before anyone knows it holds.

A result also needs holding after the improvement work stops, as the Ugandan case below shows.

Case study: Health workers fixing patient records in Uganda

Five rural public health facilities in Kayunga District, Uganda, kept patient registers and monthly malaria reports that were often incomplete. New national registers in July 2015 doubled the number of fields to fill in, and at baseline only 15.0% of register entries had every field complete.

• What they did: Staff at each facility had a 3 to 4 hour training session on recording and reporting. Facility teams then attended learning sessions about every 3 months, each followed by an "action period" in which they ran plan-do-study-act cycles to test their own change ideas, kept monthly run charts and had visits from a coach. The programme ran from November 2015 to August 2016.
• Evidence and result: Westercamp and colleagues reported in Malaria Journal in 2021 on 156,707 register and report entries from July 2014 to December 2016, counted by an independent team. Compared with the baseline trend, the estimated change in the share of entries with every field complete was 60.1 percentage points at the midpoint, and the share with the clinically relevant fields complete rose by 61.6 points. Accuracy improved for one reporting measure but not another. After support ended, all-field completeness began to decline, driven mostly by one facility.
• Limitation: Training, the cycles, coaching, learning sessions and new forms ran together, and the study was not designed to separate their effects. It covered one district with no concurrent comparison group, and the teams' own counts agreed only moderately with the independent ones.
• Lesson: In this design, a short training session was one part of a bundle that also included learning sessions, coaching and months of local cycles. Together they changed record-keeping enough for an outside count to see it. Plan for the fade: standardise what works, keep measuring after the support stops and check a team's own figures against an independent count.

How the cycles fit together: small tests and ramps

A single cycle is one test. The method works through a series of small, linked cycles, each built on the last. The Institute for Healthcare Improvement advises teams to scale tests down ("sample the next 10" instead of "get a sample of 200") and to ask, "What change can we test by next Tuesday?" It calls a series of linked cycles that grows in scale a PDSA ramp, and it treats failed tests as normal: a team with very few of them "is probably not pushing the boundaries of innovation very far".

For the hotel, the ramp looks like this.

The Standardise row is what Imai called SDCA (Standardise, Do, Check, Action): "SDCA is used for stabilizing and standardizing the conditions and PDCA for improving them" (1986, p. 63). The ramp is slower than a group-wide launch, but each step limits how many people a failed change can affect, and the second hotel shows whether the result depends on one team.

PDCA vs PDSA: why Deming said Study

PDCA and PDSA share four steps and a shape, but they ask different questions in the third step. In the Japanese PDCA, Check means evaluating the results, and Act means standardising the solution or going back to Plan. The emphasis is on confirming that a change worked and preventing a fault from recurring. In Deming's PDSA, Study means comparing the results with a prediction and asking what was learned and what went wrong. The emphasis is on learning and on improving the prediction for next time.

Moen and Norman concluded that "PDCA and PDSA seem related only through the scientific method" (2010, p. 28). Moen also recalls Deming warning audiences that "check" in English can mean "to hold back", which is his recollection of the seminars rather than anything Deming published. The labels also seem to travel with different habits. In Taylor and colleagues' 2014 review of healthcare studies, 11 of the 25 that used the PDSA label ran linked cycles, against 3 of the 22 that used PDCA, though the review does not show that the label caused the difference.

The practical choice is smaller than the debate suggests. Whichever name you use, run the third step as a test of a written prediction, not a pass or fail inspection. That is how the hotel used it: the prediction gave the team a number to read week 1's 73% against, rather than a vague sense that things were better.

How to run a PDCA cycle, step by step

This sequence draws on the Model for Improvement and Deming's PDSA. The order is mine, and the hotel's answers follow in the cycle log below.

1. Pick one problem and get the baseline from data you already have. The hotel used 4 weeks of its inspection log.
2. Write the aim as a number and a date. "80% first-time passes by week 3" can be checked; "better rooms" cannot.
3. Choose one change, or one small package, and write your prediction. Say what will change, by how much and by when.
4. Choose three measures. An outcome measure, a process measure to show the change was done and a balancing measure to catch side effects.
5. Make the test as small as you can. One site, a few people, a few weeks. As the Institute for Healthcare Improvement puts it, buy-in is needed for implementation, not for testing.
6. Run it and log what happens. Record deviations with the date, including anything that went wrong.
7. Compare the results with the baseline and the prediction. Write down what the data shows and what it cannot show.
8. Decide: adopt, adjust or abandon. If you adopt, update the standard: the procedure, the training and the checklist.
9. Plan the next cycle. Use what you learned to size and aim the next test.

The hotel's first cycle log

PDCA applied to training and courses

A training change is a change to a process, so it can be tested like one. Reed and Card add a warning in their 2016 analysis in BMJ Quality and Safety: one of the ways improvement projects fail is "Adopting weak interventions (eg, administrative controls, such as training and policies)" without considering stronger ones. So a course change is a hypothesis, not a fix. Three habits follow from that.

• Measure a result at work, not only completion or satisfaction. The hotel judged its training change by the inspection log. An observation checklist is one way to see whether people do the job differently.
• Pilot with one group before everyone. New starters often arrive a few at a time, which gives you a natural pilot group.
• Know what standardising means for a course. It means updating the induction, the job aid, the supervisor or facilitator guide and the course version, so the next cohort gets what worked.

Two published cases show the cycle applied to the course itself. At Baylor College of Medicine in Houston, Rose and colleagues ran a one-hour teaching session six times to set a baseline, then changed one thing per cycle over three cycles, such as handing students a pre-filled antibiotic chart. Their 2021 report in BMC Medical Education covers 367 of 440 students who answered a survey after the session. Compared with the baseline, students in the third cycle rated their understanding and their enjoyment of the format higher, and constructive comments asking for changes fell from 48 at baseline to 5 in the third cycle. Ratings dipped in the second cycle, each student attended only once and the measures were self-ratings, not a knowledge test.

In Inverness, Scotland, NHS Highland's Health Improvement team used lean methods and two PDSA cycles on the administration of a training programme, including a test of one standard evaluation form for every course. Smart and colleagues reported in BMJ Open Quality in 2018 that collating training data fell from four or five days to 30 minutes, and admin time per course from about 2 hours to 1 hour. Several figures are the team's estimates, and they measure the team's admin, not the quality of the training. Still, the logistics around a course are a fair target, and one evaluation form for every course is what makes later Check steps comparable.

For course design itself, iterative models run a similar loop before launch. The successive approximation model and agile instructional design build and revise a course in short rounds, and evaluation throughout the ADDIE model supports checks during development and after launch. PDCA can also start before launch, when the question becomes whether a change to the training moves a result at work.

What course briefs leave out: the Check step

To see whether people brief courses with a check in mind, I looked at course requests typed into Coursebox in the 90 days to 7 October 2026: one per person, from English-language browsers, with no uploaded file. Of 266 prompts, 104 were course requests. Two independent AI readers each classified all 104 against written definitions, and every positive call was re-read in full by hand. Both readers found no request that used data or a baseline. One reader flagged a single request as a pilot, but on a full re-read it was a prototype week for a children's course with no plan to evaluate it.

Thirteen of the 104 requests were classified as requests that were for training people on a specific work procedure, such as a permit-to-work system or incident reporting, which is exactly the kind of training a PDCA cycle can test. None said how anyone would know the course had worked, and none named PDCA or PDSA. In PDCA terms, the briefs described Do and skipped Check. The sample is small, it covers short prompts rather than project plans, and many organisations evaluate courses after launch in ways a prompt never shows. Still, if you want a course to be tested, you have to write the baseline, the measure and the pilot group into the plan yourself.

PDCA vs DMAIC, kaizen, OODA and other methods

PDCA sits in a family of improvement and decision methods, and it is often confused with Six Sigma's DMAIC, with kaizen and with the OODA loop. It is none of them. The table is my synthesis, not a ranking, and I found no study comparing these methods head to head.

DMAIC stands for Define, Measure, Analyse, Improve and Control. Six Sigma was developed at Motorola in the 1980s and popularised by General Electric in the 1990s, and Schroeder and colleagues argued in the Journal of Operations Management in 2008 that its tools are "strikingly similar to prior approaches to quality management" while it "provides an organizational structure not previously seen". PDCA is not a step in Six Sigma, though the two share a scientific approach to testing changes.

Kaizen is the wider idea of continuous improvement, and Imai describes PDCA as one of its tools, paired with SDCA. The OODA loop (observe, orient, decide, act) is John Boyd's. Air University Press's 2018 edition of his briefings notes that Boyd never published a book, that his best-known OODA sketch dates from 1995, and that it labels the decision a hypothesis and the action a test. Its editor describes the familiar four-arrow circle as a diagram "which Boyd never created". OODA puts orientation, how you read a situation, at the centre, which suits fast-moving competition better than measuring a process change.

Limitations of the PDCA cycle

PDCA is easy to describe and hard to do well. The main reviews of how it is used come from healthcare, and their findings are sobering.

Taylor and colleagues' 2014 systematic review in BMJ Quality and Safety did not test whether the method works. It tested whether published projects used it as designed, and most did not. Only 4 of the 47 studies analysed in detail made an explicit prediction, 2 of the 73 followed all five principles of the method, and of the 33 studies with cycles that were not linked, 29 ran a single cycle. Those findings and others point to five limits.

• It is rarely done as designed. Small tests, predictions and linked cycles are the parts most often skipped, and they are the parts that make it a learning method.
• Reported success is not evidence. Knudsen and colleagues' 2019 review in BMC Health Services Research found that almost all of 120 projects (98%) reported improvement, but only 32 set a numeric aim and reached it. Only 10 of 72 analysed in detail tested on a small scale first, and 3 of 72 used all four key features. The authors concluded that "The claim that PDSA leads to improvement should be interpreted with caution."
• Teams skip the third step. Reed and Card found that teams "often get 'stuck' in the 'do' phase", and some go straight from Do to Act. They also warn against using PDSA as "a standalone method" and note that "simple does not mean easy".
• Gains can slip once support ends. In the Ugandan case, all-field completeness began to decline after support stopped, mostly at one facility.
• Small tests trade certainty for speed. A handful of people over a few weeks can point the way, but they cannot rule out other causes. That is why the method relies on several cycles. Small changes can also be too small to show on a distant outcome, as the Montana study below shows.

Case study: Teacher improvement cycles in rural Montana schools

Four rural secondary schools in Montana, chosen because many students were not meeting state literacy standards, joined a four-year research partnership with SRI International and the state's Office of Public Instruction.

• What they did: In each school, a team of 8 to 12 administrators, instructional coaches and teachers ran two 6-week PDSA cycles a year, six cycles in all, testing classroom strategies such as exit tickets and vocabulary routines. Teams met weekly to review data on teaching practice and adjust.
• Evidence and result: Grindal and colleagues' 2020 report for the Institute of Education Sciences compared students with those in four matched schools on reading screeners, state tests and the ACT. They found no association between taking part and school-wide student outcomes. Teachers kept using the strategies after the cycles ended and said the process was helpful.
• Limitation: The authors stress that this "does not mean that the project was failure". Not every student received the changes, the schools differed despite matching, there was no student-level baseline, and only a very large gain would have been detectable. The data on teaching practice came from the teachers themselves.
• Lesson: Cycles that change how trainers or teachers work can feel useful and still show nothing on a distant outcome. Choose a near measure that each change should move, run cycles long enough to observe the intended result and do not promise a large result from a series of small changes.

Using PDCA with an AI course builder

On 8 October 2026 I briefed Coursebox to build a short course for the hotel's housekeeping team. Coursebox is our product, so weigh my account with that in mind. The brief was for a self-paced course of about 35 minutes that teaches the executive housekeeper, the two floor supervisors and the training coordinator to run one cycle at their own hotel. It gave the fixed facts: the 64% baseline, the change, the weekly counts of 33 of 45, 38 of 46 and 40 of 47, and the 35-minute cleaning time. It asked for seven sections in order (before you start, Plan, Do, Check, Act, planning the next cycle and a wrap-up last), with open-text answers in Plan, Check and Act instead of quizzes.

The structure came right after one revision. The first outline had squeezed Do, Check and Act into a single section, added a 4-question quiz to Plan and merged the wrap-up into the last section. After one message naming those changes, the reloaded outline had seven sections in the briefed order, one per step, with 12 pages and no quizzes. It estimated about an hour, longer than the 35 minutes I briefed, so it needs trimming. The Plan section asked for the aim, the prediction and the measures in open text. Do included the week 2 scenario where a supervisor is on leave, with a decision about how to handle it. Act asked learners to choose between standardising, adjusting and abandoning.

The issue was in the Check section, the step this method depends on. I read the generated pages, and "Read the weekly results" showed a table with the pass rates of 73%, 83% and 85% and the gain over the baseline already filled in, before the page that asks learners to work them out. The calculation task itself then said the correct rates were 73%, 83% and 85%. A learner could copy the answer instead of doing the comparison that tells a team whether a change worked.

I fixed it in the page editor. I removed the pass rate and baseline comparison columns from the results table, leaving the week, rooms passed, rooms checked and notes, and replaced the answer line in the task with the raw counts and the cleaning times. The correct rates stay in the task's model answer, which learners see as feedback after they submit. I checked the outline and the generated pages, not a housekeeping team using them, and a correct Check page does not show that any hotel's pass rate will improve; the inspection log over the next cycles is the real measure. What I could verify is the page itself: after a reload, the results page showed only the counts and the task showed the raw results with no answers, so learners now work out each week's rate themselves.

Before you build or change a course this way, it helps to plan the pilot first, so the course has something to be checked against.

Putting the PDCA cycle to work

The PDCA cycle answers a practical question: how do you find out whether a change works before you bet the whole operation on it? Use it when you can measure the result within weeks and test on a small group first; for a costly problem with an unclear cause, a structured DMAIC project may suit better. The four steps are easy to learn. The research shows that the hard parts are the ones teams skip: the written prediction, the small test and the second cycle.

Pick one problem you already have data for, such as a first-inspection pass rate or an error count. Use completion only when access or completion is the problem being tested. Before you change anything, write down the baseline, the aim with a date, and the result you predict, then choose the smallest group you can test the change with.