Process Improvement Plan: 12-Week Template With DMAIC Steps

8 min read ยท 2026-10-25

A process improvement plan describes how you will make one business process faster, cheaper or more reliable: which process, the problem in numbers, the target, the steps to find and fix root causes, who owns each step and how you will keep the gains. It turns a complaint like "invoices take forever" into a project with a baseline, a deadline and an owner.

The template below follows DMAIC (define, measure, analyze, improve, control), a structure widely used in Lean Six Sigma, over 12 weeks. It works for finance, operations, HR, IT or customer-facing processes. It includes a filled-in example, who owns what, the tools to use at each step and how to present results to leadership.

The roadmap at a glance

Goal: The target process meets its agreed cycle time and error targets for four weeks in a row, with a named process owner and a control plan in place. Duration: 12 weeks

  1. Define (Weeks 1-2)

    Agree which process, what problem and what result the project must deliver.

    • Write a one-page project charter: process name, start and end points, problem statement, target, scope and team.
    • State the problem in numbers, such as the time from invoice receipt to approval, not as an opinion.
    • Name the sponsor, the process owner and the core team, including people who do the work every day.
    • Draw a SIPOC (suppliers, inputs, process, outputs, customers) to agree the boundaries.
    • List what is out of scope, such as replacing the ERP system.

    Milestone: Charter signed by the sponsor and the process owner, with a measurable target and a date.

  2. Measure (Weeks 2-4)

    Map how the process really works and set a reliable baseline.

    • Map the current process step by step with the people who do it, including rework loops and waiting time.
    • Pull data from your systems for at least the last few months: volume, cycle time, errors and rework.
    • Check that the data is reliable by tracing a sample of cases by hand.
    • Measure the time each step takes and the time work waits between steps.
    • Record the baseline for each target metric in a simple dashboard.

    Milestone: A current-state process map and a baseline for cycle time, errors and volume, agreed by the team.

  3. Analyze (Weeks 4-6)

    Find the root causes behind the biggest delays and errors.

    • Mark the steps with the longest waits, most handoffs and most rework on the process map.
    • Run a fishbone diagram or five whys session on the top problems with the people who do the work.
    • Use a Pareto chart to see which few causes drive most of the delays or errors.
    • Check each suspected cause against data before you accept it.
    • Rank root causes by impact and by how hard they are to fix.

    Milestone: A ranked list of three to five root causes, each backed by data, reviewed with the sponsor.

  4. Improve (Weeks 6-10)

    Design, test and roll out changes that remove the root causes.

    • Brainstorm fixes for each root cause, then choose with an impact and effort grid.
    • Draw the future-state process map and write the new standard work.
    • Pilot the changes with one team, region or product line for two to three weeks.
    • Compare pilot results with the baseline and adjust what did not work.
    • Roll out to the full process with training, updated documents and system changes.

    Milestone: Changes live across the whole process, with pilot results showing progress toward the target.

  5. Control (Weeks 10-12)

    Make sure the gains stay after the project team moves on.

    • Write a control plan: each metric, its target, who checks it, how often and what to do if it slips.
    • Hand the dashboard and the standard work to the process owner.
    • Add the new steps to onboarding material and system configuration so they stick.
    • Hold a closing review with the sponsor and record lessons learned.

    Milestone: Target met for four weeks in a row and the process formally handed over to its owner.

Example: a filled-in plan for invoice approval

Picture a mid-size distributor where suppliers complain about late payments. Invoices sit in email inboxes waiting for approval, and the accounts payable team spends hours chasing managers. The finance director sponsors the project, the accounts payable manager owns the process and a business analyst leads the work.

The fixes here are simple: clear rules, routing and a reminder. Most process improvements are. The hard part is proving which few causes matter, so the team does not waste weeks on the rest.

  • Weeks 1-2, owner business analyst: charter defines the process from invoice receipt to approval, with the target of cutting median approval time in half. Milestone: charter signed by the finance director.
  • Weeks 2-4, owner accounts payable manager: process mapped with three clerks, baseline pulled from the ERP. Milestone: baseline shows most of the time is waiting for manager approval.
  • Weeks 4-6, owner business analyst: Pareto chart shows invoices without a purchase order number and unclear approvers cause most delays. Milestone: root causes approved.
  • Weeks 6-10, owner accounts payable manager: suppliers asked to include purchase order numbers, approval routing by cost center, automatic reminder after three days. Piloted with one division, then rolled out. Milestone: median approval time down in the pilot.
  • Weeks 10-12, owner accounts payable manager: control plan with a weekly approval time chart and an escalation rule. Milestone: target met four weeks in a row.

Who owns what

Process improvement fails when the project team fixes a process it does not own. The process owner must be in the room from the charter to the handover, because they will run the new process after the project closes.

Include people who do the work every day. They know where the real delays are, and they are the ones who have to change how they work.

  • Sponsor (director or VP): approves the charter, clears blockers between departments and accepts the results.
  • Process owner: owns the process before and after the project, approves changes and runs the control plan.
  • Project lead (business analyst, continuous improvement lead or project manager): plan, workshops, data and reporting.
  • Process participants: mapping sessions, root cause workshops, pilot and feedback.
  • IT or system owner: system changes, data extracts and automation.
  • Finance partner: checks any cost or savings figures before they go to leadership.

Tools to use at each step

You do not need special software. A whiteboard or a shared diagram tool, a spreadsheet and your existing systems are enough for most projects. Excel, Visio, Lucidchart or Miro all work for process maps and charts.

Pick the simplest tool that answers the question at each step. A complex statistical analysis is not needed if a Pareto chart already shows two causes behind most of the delays.

  • Define: project charter, SIPOC diagram.
  • Measure: swimlane process map, data extract from your systems, baseline dashboard.
  • Analyze: fishbone diagram, five whys, Pareto chart.
  • Improve: impact and effort grid, future-state map, pilot plan.
  • Control: control plan, run chart or control chart, standard work document.

Process improvement plan in project management

In project management, the term can also mean something else. Some editions of PMI's PMBOK Guide list a process improvement plan as part of the project management plan. In that sense, it describes how the project team will analyze its own project processes, such as how it handles changes or reviews, and improve them during the project.

If you were asked to write that kind of plan, keep the same logic: define the processes in scope, the metrics, the targets and when you will review them. Confirm the expected format with your PMO or with the edition of the guide your organization uses.

How to present it to leadership

Use one slide with four parts: the problem in numbers, the target, the root causes you found and the results so far. A before and after chart of the main metric does most of the work.

Leave out the workshop notes, detailed maps and every idea you considered. Keep them in an appendix for anyone who wants to check them. If you show savings, let your finance partner check the method first.

At the close, show the control plan and name the process owner. Leadership needs to know who will keep the gains, not only that the project ended.

Metrics to track

Pick one main metric that matches the problem statement and two or three supporting ones. Measure them the same way before, during and after the project.

Plot each metric weekly on a simple run chart. It shows whether a change is a real trend or just a good week.

  • Cycle time: time from the start to the end of the process, as a median, from system timestamps.
  • First pass yield: share of cases that go through without rework or correction.
  • Error or defect rate: errors found per batch of cases, by type.
  • Waiting time: time cases sit between steps, the biggest source of delay in most office processes.
  • Volume handled per person: to check that the process can absorb growth.

Common mistakes to avoid

  • Starting without a baseline means you cannot prove any gain, so measure the current process before you change anything.
  • Jumping to solutions in the first meeting fixes symptoms, so finish root cause analysis before choosing fixes.
  • Mapping the process from the policy document instead of reality hides the real delays, so map it with the people who do the work.
  • Rolling out changes everywhere at once makes failures expensive, so pilot with one team and compare with the baseline.
  • Closing the project without a control plan lets old habits return, so hand over a dashboard, targets and an escalation rule to the process owner.
  • Picking a process that is too big leads to a project that never ends, so set clear start and end points in the charter.

Frequently asked questions

What are the steps of a process improvement plan?

A common structure is DMAIC: define the problem and scope, measure the current process, analyze root causes, improve the process with tested changes and control it so gains last. Each step should end with a milestone the sponsor can check.

What should a process improvement plan include?

It should include the process and its boundaries, the problem in numbers, the target, the team and owners, the timeline, the methods for analysis, the pilot plan and a control plan. A one-page charter usually holds the first half.

How long does a process improvement project take?

It depends on the size of the process and how easy data is to get. A focused project on one office process is often planned over two to four months. Larger, cross-department processes may need to be split into several projects.

What is the difference between Lean and Six Sigma?

Lean focuses on removing waste, such as waiting, rework and unnecessary steps, to make a process faster. Six Sigma focuses on reducing variation and defects using data. Many teams combine them as Lean Six Sigma and use DMAIC as the project structure.

Generate this roadmap with AI