6 A Structured Approach to Process Improvement
“A problem well-stated is a problem half-solved.” — Charles Kettering
“By failing to prepare, you are preparing to fail.” — Benjamin Franklin
6.1 Why This Chapter Matters
Imagine your team has late deliveries, frustrated customers, and three competing opinions about the cause. Do you hire more people, buy new equipment, or redesign the workflow? This chapter introduces a very simple management tool, called the PDCA cycle, to guide our improvement work so we start with structured reasoning rather than guesswork. It also helps the team achieve a shared rhythm and report meaningfully to stakeholders.
6.2 Learning Objectives
By the end of this chapter, the student will be able to:
- Lean Six Sigma Principles and Tools Explain the PDCA cycle and how each phase connects to the next. Bloom:Understand
- Leading and Managing Projects Distinguish the work of the Plan, Do, Check, and Act phases in a simple improvement project. Bloom:Understand
- Leading and Managing Projects Write a clear, factual problem statement tied to customer impact. Bloom:Apply
- Leading and Managing Projects Formulate a practical SMART goal for an improvement cycle. Bloom:Apply
6.3 The PDCA Cycle
In the last chapter we learned a set of Lean principles: define value from the customer point of view, map the process, create flow, establish pull and pursue perfection. But how do we go about actually applying these principles to perform process improvement?
A haphazard approach—guessing what is wrong and trying random fixes—is usually not reliable.
- Which fixes should we try first?
- Why do we think those are going to work?
- How would we know if our fixes are helping or hurting?
- How would we know one fix would not interfere with another?
These are common difficulties when process improvement is unstructured.
Instead, what we need is a structured way of implementing process improvement. Later, we will learn there are multiple frameworks we can use to structure process-improvement projects. For our purposes in this chapter, we will use the simplest and most practical framework that fits this problem. This framework is called PDCA and it is a four-phase, repeatable cycle:
- Plan
- Do
- Check
- Act
Source: File:PDCA-Loop.png, Wikimedia Commons. Creator: Christoph Roser at AllAboutLean.com.
Rights: CC BY-SA 4.0. Used under license (not fair use).
Modification: No substantive modification; resized by the publication renderer.
W. Edwards Deming popularized this cycle in modern quality management practice, attributing the original to Walter Shewhart. In some books and organizations, you will also see it written as PDSA (Plan-Do-Study-Act). In this chapter, we use the PDCA label.
The cycle matters for more than orderly project management. In this book, reducing variation and eliminating waste also serve a further aim: helping an organization learn from the results of its decisions. Waste and variation give us important things to investigate, while PDCA supplies the feedback loop: make an explicit plan, test it, compare the result with what you expected, and decide what the evidence warrants next. The White Belt chapters follow that loop once from beginning to end so that each map, measure, and countermeasure becomes part of one connected argument rather than an isolated tool exercise.
PDCA is the right-sized framework for that first bounded cycle. At Yellow Belt, we will organize a more substantial improvement story with A3; later belts will use DMAIC when the problem requires deeper measurement, analysis, and project discipline. These frameworks differ in scale and emphasis, but they share the same obligation to learn from evidence before standardizing a change.
The PDCA cycle is a good tool for managing simple projects, where the problem we are investigating is confined to a single business unit with a specific, measurable problem. Our fictional Wash n’ Fold case is a good candidate. Over the next several chapters, we run this cycle using the Wash n’ Fold process as a concrete case. By working through this case together, we see the Lean principles in action and practice simple but powerful tools. Let’s begin with the Plan phase.
6.4 Wash n’ Fold Project: Plan
We need to do three things as part of the ‘Plan’ phase.
- Define the problem and set a clear goal.
- Map the current process.
- Establish baseline metrics.
By defining the problem and goal, we help narrow our scope. Mapping the current process gives us understanding of the process and its variants. The map also makes it easy to calculate a number of convenient metrics. This is useful for two reasons. First, viewing the map and its metrics can help identify potential interventions to try in the “Do” phase. Second, these metrics form the baseline to judge the effectiveness of these interventions in the “Check” phase.
For this project, we follow one customer order from drop-off until the completed order is staged and the customer is notified it is ready. Customer travel, pickup, and payment are outside our scope for this project.
6.4.1 Define the problem
The Plan phase starts with a clear, neutral problem statement. What we want is a specific, observable claim about what is happening. Not why the problem is happening or what we should do about it. At this step, we are only defining the problem, not attempting to solve it or assign blame. Do not assume a cause and do not propose a fix yet.
Try to tie the problem statement to its impact on the customer. “Customer orders are late” is a good start on a problem statement. “Employees are not working fast enough,” is a bad problem statement because it jumps to blame and an unverified cause. “We need another washer” isn’t a problem statement at all; it’s just jumping to a potential solution based on an unverified cause.
If you find yourself struggling with your problem statement, it can be helpful to write these questions on a piece of paper:
- Who is being affected?
- What is the problem affecting them?
- When is the problem happening?
- Where is the problem happening?
- How is the problem affecting the customer?
Use these five questions as a lens to think through what you’ve observed systematically. Are there specific subgroups of customers or employees being affected or is it everybody? What exactly is happening? Is there a specific time or place where it occurs more frequently than elsewhere? Is the problem confined to a specific area or location? Thinking through such questions can help you make your problem statements more specific and detailed. Avoid the temptation at this point to start speculating about the “Why?” Absolutely avoid assigning blame. Note too what newly discovered information might cause you to revisit and revise your problem statement.
I am intentionally belaboring what might seem like a simple point because, in practice, writing a good problem statement is often one of the biggest challenges process improvement beginners face. For some reason—psychological, cultural, or otherwise—our natural tendency is to jump straightaway into analyzing and solving problems.
Experienced mentors and facilitators often need to remind the project team we must proceed methodically to get a good result. You may find it helpful to remind yourself and your team to “trust the process”: gather evidence before settling on a solution. That discipline includes revising or rejecting our preferred explanation when the evidence contradicts it. We will get to solutions after we’ve gathered and analyzed data to guide our problem solving.
Go back to the Case Study and write a short problem statement (3–5 sentences).
Focus on what is happening now, who is affected, and why it matters. Do not diagnose the problem or propose solutions yet.
Your answer should look something like:
“Recent Friday evidence shows approximately 28% of same-day orders dropped off by 9:00 a.m. were not staged and ready, with the customer notified, by the 5:00 p.m. promise. (What and When) Customers relying on that same-day promise cannot consistently tell when their laundry is ready. (Who and How) This performance gap weakens the service’s promise of convenient, reliable same-day laundry. (How—Business)”
6.4.2 Set a SMART Goal
Once we have stated the problem, our next task in the Plan phase is to define what improvement should look like in this cycle. At White Belt level, a practical way to do this is a SMART goal. If you’re not familiar with the acronym, it summarizes five properties a good goal ought to have.
- Specific: states exactly what should improve.
- Measurable: uses at least one observable metric.
- Achievable: realistic for the team and timeframe.
- Relevant: tied to customer impact and business need.
- Time-bound: includes a clear deadline.
For this case, a same-day promise violation means an order dropped off by 9:00 a.m. that is not staged and ready, with the customer notified, by 5:00 p.m. “Reduce same-day promise violations from approximately 28% to 10% within the next 30 days” gives us a concrete target to shoot for. “Make stuff better” or “improve the process” doesn’t.
It’s okay if you aren’t completely clear at the outset what specific measure your project should target for improvement: we will discuss process metrics more fully in Chapter 9. In practice, it’s quite common, at the outset of a project, for the goals not to be completely clear. Often the project goals have to be refined over the course of the project in collaboration with the business owner or manager. The business leadership and the project team need to agree on the target. Without that agreement, the team cannot tell whether its result meets the owner’s requirement.
The goal statement should describe the desired future state of the process in as much specific detail as possible. Again, don’t include analysis or solutions in your goal statements. Just describe what the world should be like if you solved the problem identified in your problem statement.
Go back to the Case Study and write a short goal statement (1–2 sentences).
What does “good” look like?
With the problem defined and the goal clarified, the next step is to see the process clearly enough to act on it. That mapping work belongs to the next chapter. For now let’s work some exercises to solidify our understanding.
6.5 Conclusion
In Section 3.6, we described five deliverables you’ll need to complete the White Belt capstone.
You should now have the material you need to create the first deliverable, which is a small document with your problem statement and goal statement. I encourage you to create a small file on your computer, or write these out officially on a page of your journal for future reference. Together the two statements give us a snapshot of where we currently are, and where we want to be.
6.6 Exercises
1. Bloom:Apply A small dental practice reviewed 40 scheduled appointments from the previous month. In 18 of them, the patient waited more than 15 minutes past the scheduled appointment time before the hygienist began the cleaning.
Write a one-sentence problem statement for this practice. Then use your imagination to write a weak version of the same statement that violates the “no causes, no blame” rule — and briefly explain what makes it weak.
Strong: “Last month, 18 of 40 scheduled patients waited more than 15 minutes past their appointment time before the hygienist began the cleaning.”
Weak: “The reception staff are slow and the room-cleaning process is disorganized, causing patient delays.”
The weak version jumps to blame (reception staff) and assumes causes (disorganization) before any analysis has been done. It closes off inquiry rather than opening it.
2. Bloom:Understand A team is running a small improvement effort on late customer orders. For each activity below, identify whether it belongs primarily to Plan, Do, Check, or Act:
- Compare on-time completion before and after the test.
- Write a neutral problem statement tied to missed pickup times.
- Update the standard work and train staff on the new routine.
- Test a new folding schedule for one week.
- Check: compare on-time completion before and after the test.
- Plan: write a neutral problem statement tied to missed pickup times.
- Act: update the standard work and train staff on the new routine.
- Do: test a new folding schedule for one week.
3. Bloom:Apply Consider this goal statement: “Improve customer satisfaction soon by making operations better.”
Identify at least three SMART criteria this statement fails to meet and rewrite it as a one-sentence SMART goal. For the rewrite, use the Wash n’ Fold case’s current promise-violation rate of approximately 28%, target of 10%, and 30-day improvement period.
It fails Specific, Measurable, and Time-bound. It also gives us too little information to judge whether the goal is achievable or relevant to the business problem. A stronger version: “Reduce same-day promise violations—the percentage of orders dropped off by 9:00 a.m. that are not ready and notified by 5:00 p.m.—from approximately 28% to 10% within 30 days.”
4. Bloom:Apply A manager wants to skip the Check phase because “everyone can already tell the process feels better.” Would you accept that? Why or why not?
No. Perceived improvement is not enough; the Check phase requires before-and-after comparison using consistent baseline metrics. Skipping it risks standardizing a change that did not improve the intended measure or that created harm somewhere else in the process.
5. Bloom:Apply A university’s financial aid office processes student grant applications. Students currently wait an average of 18 business days for a decision; the office’s own service standard is 10 days. The director wants to run a PDCA cycle to close that gap.
Write a one-sentence problem statement and a one-sentence SMART goal for this cycle. Keep the problem statement factual and customer-focused; make the goal specific, measurable, and time-bound.
Problem statement: “Grant applicants are waiting an average of 18 business days for a decision, 8 days longer than the office’s stated 10-day service standard.”
SMART goal: “Reduce the average grant-application decision time from 18 to 10 business days within 60 days.”
Strong responses keep the problem statement free of causes or blame, state the customer-facing delay against the service standard, and make the goal measurable (18 → 10 days) and time-bound (60 days).
6. Bloom:Understand What is the difference between a problem statement and a SMART goal? A teammate drafts the following and labels it as the problem statement for their PDCA cycle:
“We need to reduce order lead time by 20% over the next month.”
Explain what is wrong with calling this a problem statement, and identify the current-state facts you would need before you could write a proper problem statement.
A problem statement describes the gap between current performance and what is expected or desired, without naming causes or solutions. A SMART goal describes the intended improvement: how much, by when.
The teammate’s draft is a goal, not a problem statement — it names a target (−20%) and a deadline (one month) rather than describing the current situation.
Before writing a proper problem statement, the team needs evidence about the current lead time, the relevant customer or service requirement, who is affected, and the observable consequence of the gap. The proposed reduction alone does not supply those facts, so inventing them would make the statement look precise without making it true.
7. Bloom:Apply Records show that 24% of customer issues handled last month required a callback, while the service standard allows no more than 10%. A supervisor describes the problem this way: “Our team is careless, so customer callbacks are too high.” Rewrite the supervisor’s statement as a neutral problem statement using the supplied evidence.
“Last month, 24% of customer issues required a callback, exceeding the service standard of no more than 10% by 14 percentage points.” This version states the observed gap and removes the unsupported claim that carelessness caused it.
8. Bloom:Understand In one sentence each, define Plan, Do, Check, and Act as used in this chapter.
- Plan: Define the problem and goal, map the current process, establish the baseline, and choose a bounded countermeasure to test.
- Do: Carry out the test under stated conditions and record what happens.
- Check: Compare the result with the baseline and the prediction using consistent measures.
- Act: Standardize what the evidence supports, revise or abandon what it does not, and frame the next cycle.
9. Bloom:Apply Draft one SMART goal for a process with current on-time completion of 62%, a desired level of 85%, and a 60-day improvement period.
“Increase on-time completion from 62% to at least 85% within 60 days.” The real project would also define what counts as on time and which process boundary and cohort the percentage covers.
10. Bloom:Apply A team has one proposed countermeasure but no baseline metric. Write two sentences describing what must be added before entering Do.
The team must define a measure tied to the problem and record its current value for a stated process boundary, cohort, and period. It must also state the result it expects from the countermeasure so that Check can compare the after-state result with both the baseline and the prediction.
11. Bloom:Apply Write a short Check-phase evaluation note template with three fields your team must fill in.
One useful template is:
- Baseline and prediction: What measure did we start with, and what did we expect?
- Observed result: What happened under the test conditions, using the same measure and boundary?
- Interpretation and next action: What does the comparison support, what remains uncertain, and should we adopt, revise, or abandon the countermeasure?
6.6.1 Reflection Questions
- Think of an unsuccessful project from work or daily life you’ve participated in or witnessed. Could that project’s failure trace back to having an incorrect understanding of the nature of the problem to be solved or the goal to be achieved? If so, write three or four sentences explaining what you or your team could have done differently.
- Write three or four sentences on which PDCA phase you are most likely to under-resource in real work and what guardrail you will use to prevent that.
6.7 Chapter Summary
- PDCA gives improvement work a repeatable rhythm: define the problem and goal, test countermeasures, compare results, and standardize or revise.
- Good Plan phase work is factual and disciplined: it states the problem without blame, it ties that problem to customer impact, and it sets a measurable goal for this cycle.
- The Wash n’ Fold case shows why structure matters: busy operations generate many opinions, but a shared method makes decisions easier to test and defend.