Templates & DMAIC
How to Apply Process Templates to Real Project Delivery
A phase-by-phase DMAIC guide: which template to use at each stage, with real scenarios from manufacturing, healthcare and office work.
A phase-by-phase DMAIC guide: which template to use at each stage, with real scenarios from manufacturing, healthcare and office work.
You have the templates. The blank grid is open. And you are staring at it wondering where to start.
This is the most common failure point in process improvement work. Not a lack of methodology, not a lack of tools, but a lack of clarity about which template to use, when to use it, and what a completed version should look like in the context of a real project.
This guide walks through the five DMAIC phases and shows you exactly which templates to reach for at each stage, using realistic scenarios drawn from manufacturing, healthcare, and transactional office environments. The scenarios are illustrative, but the sequencing is real. Follow it on your next project and the templates stop being abstract documents and start being working tools.
The core principle: templates are not deliverables. They are thinking aids. Their job is to capture decisions, surface assumptions, and create a shared record the whole team can work from. A completed template that nobody reads is worthless. A half-completed template that drives a better conversation is doing its job.
Before getting into the phases, one thing to understand about the SimplicityHub template library: every template includes a fully completed worked example. That example is not decoration. It is the fastest way to understand what good looks like before you fill in a single cell of your own version.
Most projects fail in Define. Not because people skip it, but because they rush it. The problem statement is vague. The scope is too wide. Nobody has agreed what success looks like. Six weeks in, the team is arguing about whether customer complaints or cycle time is the real issue.
Define templates exist to prevent that. Their job is to force precision before the work starts.
The Project Charter is the foundation document. It captures the problem, the goal, the scope, the team, the timeline, and the business case in one place. Sponsors sign it. That signature matters.
Scenario (manufacturing): A production team is experiencing high scrap rates on a machined component line. The project leader fills in the charter with a problem statement that reads: "Scrap rate on Line 4 averaged 8.3% in Q1 2026, against a target of 2.0%, generating approximately £47,000 in wasted material per quarter." The goal statement commits to reducing scrap to below 3.0% by the end of Q3. The scope is limited to Line 4 only. That boundary is explicit in the charter.
Without the charter, the team would have spent three weeks debating whether to include Lines 2 and 3. The document ended that conversation before it started.
Once the charter is agreed, the SIPOC template gives the team a shared picture of the process at a high level. Suppliers, Inputs, Process steps, Outputs, Customers. Five columns. One page.
The SIPOC is not a detailed process map. It is a framing tool. Its purpose is to align the team on what the process covers before anyone starts collecting data.
Scenario (healthcare): A patient discharge team is working on delayed discharges from a ward. The SIPOC maps the process from the point a clinician makes a discharge decision to the point the bed is physically cleared. That boundary definition alone resolves a disagreement between nursing and admin about where their responsibility starts and ends.
After the charter and SIPOC, the following templates complete the Define phase:
| Template | What it does | When to use it |
|---|---|---|
| Problem Statement | Forces a factual, measurable description of the issue | Before the charter is finalised |
| Goal Statement | Translates the objective into a measurable target with a deadline | Alongside the problem statement |
| Stakeholder Analysis | Identifies who is affected, who has influence, and what they need | Before the first team meeting |
| RACI Matrix | Clarifies who is responsible, accountable, consulted, and informed | Once the team is confirmed |
| Voice of the Customer (VOC) | Captures what customers and stakeholders actually need | Before Measure begins |
| Project Risk Assessment | Surfaces delivery risks and mitigation actions | Before the sponsor sign-off |
Do not try to complete all of these in one sitting. Work through them in order. The problem statement informs the goal statement. The stakeholder analysis informs the RACI. Each template builds on the one before it.
The biggest mistake in Measure is skipping straight to data collection without first understanding how the process actually works. You end up measuring the wrong things, or measuring the right things inconsistently, and the data tells you nothing useful.
Measure templates enforce the correct sequence: map the process, define your measures, then collect the data.
The Process Map template visualises the current state, step by step, as it actually operates. Not as the procedure document says it should work. As it actually works.
This distinction matters more than most people expect. In almost every project, the team discovers during process mapping that the real process differs significantly from the documented one. Steps have been added informally. Workarounds have become standard practice. Hand-offs happen in a different order than anyone realised.
Scenario (transactional/office): A finance team is investigating why expense claims take an average of 19 days to process against a target of 5 days. The process map reveals seven approval steps, three of which were added after a compliance incident two years ago and have never been reviewed. Two of those steps are performed by the same person, sequentially, with no value added between them. That finding came from the map, not from the data.
Before collecting any data, complete the Operational Definitions template. This is the most commonly skipped template in Measure, and skipping it is the most common reason data collected by two different people is incompatible.
An operational definition specifies exactly what you are measuring, how you are measuring it, and what counts as a defect or an event. If two team members would make different decisions when looking at the same data point, your operational definition is not complete.
Scenario (manufacturing): The scrap rate project from Define now needs a baseline. The Operational Definitions template establishes that "scrap" means any machined part that fails dimensional inspection and cannot be reworked. Parts sent for rework are recorded separately as "rework." That distinction changes the baseline figure and, more importantly, changes what the team is trying to reduce.
Work through these in order:
Process Map — current state, as it actually runs
Value Stream Map — adds time data (process time, wait time, handoff delays)
Operational Definitions — agreed definitions before data collection begins
Tally Sheet — count occurrences of defects, errors, or events during observation
Process Observation Sheet — structured observation of the process in action
The Process Observation Sheet is particularly useful for transactional and office environments where the process is less visible than on a production line. It gives the observer a structured format for recording what they see without introducing bias into the observation.
Analyse is where most improvement projects either accelerate or stall. Teams that skip structured root cause analysis jump to solutions based on gut feel. They implement changes, see partial improvement, and then watch the problem return three months later because the actual cause was never addressed.
The Analyse templates exist to slow that instinct down and replace it with evidence.
The 5 Whys template guides the team through repeated questioning until the underlying cause becomes visible. The technique is simple. The discipline required to use it well is not.
The most common mistake is stopping too early. Teams reach a cause that feels satisfying and stop asking why. The result is a solution that addresses a symptom, not the root cause.
Scenario (healthcare): The discharge delay project identifies that patients are waiting an average of 4.2 hours after a discharge decision before transport is arranged. The 5 Whys reveals:
Why is transport delayed? The transport booking form is not submitted on time.
Why is the form not submitted on time? The ward clerk does not receive the discharge decision directly.
Why does the ward clerk not receive it directly? The discharge decision is recorded in the clinical notes, which the clerk does not routinely access.
Why does the clerk not access clinical notes? There is no agreed trigger or notification process.
Why is there no notification process? The discharge pathway was designed before the current ward structure was in place.
The root cause is a structural communication gap, not individual failure. That distinction changes the solution entirely.
Once the 5 Whys is complete, the Root Cause Analysis (RCA) template documents the findings formally. It captures the problem, the evidence gathered, the cause chain, and the validated root cause. This document becomes the justification for whatever improvement is proposed in the next phase.
Do not skip this documentation step. Verbal root cause analysis is forgotten. Written RCA is reviewable, challengeable, and defensible.
Analyse often surfaces problems that sit outside the project scope. The Issue Log template captures these so they are not lost, but also so they do not derail the current project.
Scenario (transactional/office): During the expense claims project, the team discovers that a significant number of late claims are being submitted by a single department, and that this correlates with a training gap rather than a process failure. That finding is logged. It is not the project's root cause, but it informs a parallel action.
Improve is the phase most teams rush toward. They have spent weeks in Define, Measure, and Analyse, and they are impatient to do something visible. That impatience is understandable. It is also the reason many improvements are implemented poorly.
The Improve templates slow the implementation down just enough to make it work properly.
Before committing to a solution, use the Improvement Prioritisation Matrix to sort potential changes by two dimensions: likely impact and delivery effort. This is not a sophisticated statistical tool. It is a structured conversation aid that forces the team to make explicit trade-offs rather than defaulting to whoever argues loudest.
High-impact, low-effort changes become your quick wins. High-impact, high-effort changes become your planned improvements. Low-impact changes, regardless of effort, are deprioritised.
Scenario (manufacturing): The scrap rate project generates eight potential improvements. The prioritisation matrix identifies that two changes, updating the machine setup checklist and adding a dimensional check at the midpoint of the machining cycle, are both high-impact and low-effort. These are implemented first. The remaining six changes are scheduled over the following quarter.
The Pilot Plan template structures the small-scale test that precedes full implementation. It defines the scope of the pilot, the success criteria, the duration, and the method for evaluating results.
Skipping the pilot is the single most expensive mistake in the Improve phase. Full-scale implementation of an untested change that turns out to be wrong costs significantly more to reverse than a contained pilot that reveals the flaw early.
Scenario (healthcare): The discharge project proposes a new notification trigger: a digital alert sent to the ward clerk the moment a discharge decision is recorded in the clinical system. The pilot plan tests this on one ward for four weeks. The success criterion is a reduction in average transport booking lag from 4.2 hours to under 1.5 hours. The pilot runs. The lag drops to 1.1 hours. The change is then rolled out across the remaining wards.
Once the pilot is validated, the Action Plan template breaks the full implementation into tasks, owners, and due dates. This is not a project management document. It is a delivery tool. Each row is a specific action, assigned to a named person, with a date.
Tasks should be small enough to complete within a week
Each task has one owner, not a team
Due dates are real commitments, not aspirations
Control is the phase that determines whether the project was worth doing. The improvement is implemented. The metrics have moved. And now the question is whether they stay moved six months after the project team disbands.
Most do not. Not because the improvement was wrong, but because nobody built the structures to sustain it. Control templates build those structures.
The Control Plan is the most important document in the entire DMAIC project. It specifies what is being monitored, how it is being monitored, who owns it, what the acceptable range is, and what happens when a result falls outside that range.
A Control Plan without a named owner and a defined response to out-of-control signals is not a control plan. It is a wish list.
Scenario (transactional/office): The expense claims project closes with a Control Plan that specifies a weekly review of claim cycle time by the Finance Manager. The acceptable range is 3 to 7 days. If the average exceeds 7 days in any two consecutive weeks, the Finance Manager triggers a review of the approval queue. That response is documented. It does not rely on anyone remembering what to do.
The Standard Operating Procedure (SOP) template documents the new way of working so the process can be carried out consistently, regardless of who is doing it. This is the document that survives staff changes, shift handovers, and the departure of the project lead.
An SOP that is accurate but unreadable will not be followed. Write it at the level of the person who will use it, not the person who designed the process.
| Template | Purpose |
|---|---|
| Control Plan | Defines what is monitored, by whom, and what triggers a response |
| Standard Operating Procedure | Documents the agreed way of working post-improvement |
| Process Flow Checklist | Confirms the new process is being followed as designed |
| Sustainment Plan | Sets out review cadence, ownership, and reinforcement activity |
| Project Closure Report | Summarises outcomes, hands off control, and formally closes the project |
The Project Closure Report is often treated as an administrative formality. It is not. It is the moment the project formally transfers ownership of the improved process to the business. Without it, the project exists in a grey zone where nobody is clearly accountable for sustaining the result.
Scenario (manufacturing): The scrap rate project closes with a Closure Report showing scrap on Line 4 reduced from 8.3% to 2.1% over 14 weeks. The Control Plan and SOP are handed to the Production Supervisor, who signs the closure document. The project lead moves on. The improvement does not.
A project that is progressing well but communicating poorly will lose sponsor support. A project that is genuinely struggling but communicating clearly will retain it. The difference is structured, regular reporting.
Two templates handle this across the life of the project.
The Project Status Report template provides a regular update on progress, risks, and next steps. It is not a narrative essay. It is a structured one-page summary that a sponsor can read in three minutes and understand exactly where the project stands.
Use it on a cadence agreed in the charter. Weekly for fast-moving projects. Fortnightly for longer ones. The cadence matters less than the consistency.
At key milestones, particularly at phase-gate reviews, the Project Summary One-Pager gives stakeholders a concise view of the project without requiring them to read the full documentation set. Problem, progress, results, next steps. One page. No jargon.
This template is particularly useful when presenting to senior stakeholders who are not involved in the day-to-day work and need context quickly.
For a complete DMAIC project, the templates follow this sequence. Not every project will use every template. But this is the full reference map.
| Phase | Template | Primary purpose |
|---|---|---|
| Define | Project Charter | Scope, goal, team, and sponsor sign-off |
| Define | SIPOC | High-level process framing and boundary setting |
| Define | Problem Statement | Factual, measurable description of the issue |
| Define | Goal Statement | Measurable target with deadline |
| Define | Stakeholder Analysis | Influence mapping and engagement planning |
| Define | RACI Matrix | Role clarity across the project team |
| Define | Voice of the Customer | Customer and stakeholder needs |
| Define | Project Risk Assessment | Delivery risks and mitigation |
| Measure | Process Map | Current state process visualisation |
| Measure | Value Stream Map | End-to-end flow with time data |
| Measure | Operational Definitions | Consistent measurement definitions |
| Measure | Tally Sheet | Defect and event counting |
| Measure | Process Observation Sheet | Structured on-the-ground observation |
| Analyse | 5 Whys | Root cause identification |
| Analyse | Root Cause Analysis | Formal documentation of cause and evidence |
| Analyse | Issue Log | Tracking of out-of-scope findings |
| Improve | Improvement Prioritisation Matrix | Impact vs effort sorting |
| Improve | Pilot Plan | Small-scale test design |
| Improve | Action Plan | Implementation tasks, owners, and dates |
| Control | Control Plan | Monitoring, ownership, and response triggers |
| Control | Standard Operating Procedure | Documented new way of working |
| Control | Process Flow Checklist | Compliance verification |
| Control | Sustainment Plan | Long-term review and reinforcement |
| Control | Project Closure Report | Formal handover and project closure |
| All phases | Project Status Report | Regular progress updates to stakeholders |
| All phases | Project Summary One-Pager | Milestone summaries for senior stakeholders |
Every template in this table is available to download free from the SimplicityHub template library, with a completed worked example included for each one.
You do not need to master all 26 templates before your next project begins. You need the right three or four for the phase you are in right now.
If you are starting a new project, open the Project Charter, the Problem Statement, and the SIPOC. Get those right before you touch anything else. A well-scoped, clearly defined project with an aligned team will always outperform a loosely defined project with sophisticated analytical tools.
If you are mid-project and stalling, check whether you have skipped a foundational template. Most mid-project stalls trace back to a Define or Measure document that was rushed or skipped entirely. Go back. Fix the foundation. The rest will move faster.
If you are closing a project, do not skip the Control Plan and the Closure Report. The improvement is not complete until the business owns it, not the project team.
The full DMAIC template library is free to access, with completed worked examples for every template. If you want a structured walkthrough of how to run a complete project from start to finish, the step-by-step DMAIC project guide covers the methodology alongside the tools.
The templates work. The question is whether you use them with enough discipline to let them do their job.
Start with the Project Charter. It defines the problem, scope, goal, team, and timeline before any analysis begins. If the charter is unclear, the rest of the project usually drifts.
Use a SIPOC in the Define phase, right after the charter. It gives the team a shared high-level view of suppliers, inputs, process steps, outputs, and customers before detailed mapping starts.
A process map shows how the work actually flows, not how the procedure says it should work. That helps you place measures correctly and avoid collecting data from the wrong steps or handoffs.
The 5 Whys template is the simplest way to push beyond symptoms and test cause chains. For anything more complex, pair it with the Root Cause Analysis template so the evidence is documented properly.
Use the Control Plan, Standard Operating Procedure, Process Flow Checklist, and Sustainment Plan. Together, they define what is monitored, who owns it, and what happens when performance slips.
80+ free templates with completed worked examples — Project Charter, SIPOC, 5 Whys, Control Plan and everything in between.