Write a DMAIC Project Charter for a Repeated Factory Loss

Start with a loss that the team can describe

A cutting planner receives an order pack with two different size totals. The team resolves the conflict, changes the record and gets work moving. A week later, another pack has the same problem. Each incident seems small until people count the repeated calls, checks and corrections.

A DMAIC project charter gives that recurring problem a clear scope. It states the problem, the people affected, the evidence needed and the decisions the team can make. It also gives the sponsor a way to judge progress before approving a permanent change.

DMAIC stands for Define, Measure, Analyze, Improve and Control. ASQ describes the method as a structured way to improve an existing process whose performance falls short. A charter belongs near the start, but it should remain open to justified changes as the team learns more.

This guide follows a fictional apparel factory that wants fewer errors in released production order packs. All figures are illustrative. The case follows the factory's internal release process. It starts with a prepared record and follows its use by cutting and production planning. It does not prescribe a buyer's document format or replace the factory's rules for product approval.

Decide whether a project is needed

Not every wrong entry needs a DMAIC team. If a field contains an obvious typing error, the authorised person can correct it through the normal process. A project may help when the same error keeps returning. The cause may be unclear or may cross several departments.

Consider three different situations. A missing page may call for an immediate resend. Repeated missing pages may reveal a weak release check. A new product that needs an entirely new record system may require a wider design effort. These are different tasks, even when people use the same phrase, “fix the paperwork.”

The sponsor should ask what remains unknown. Does the factory lack a clear definition of a correct pack? Does it know when an error entered the record? Can it distinguish a legitimate later change from a mistake present at release? A team that cannot answer those questions needs to establish facts before choosing software or training.

Immediate containment can continue during the project. Production still needs valid instructions. Affected work must follow the factory's existing hold and release rules. The charter should name the person responsible for that daily response. A ten-week improvement timetable is not permission to leave a known wrong instruction in use.

Write a problem statement without naming a culprit

“Staff need more training” is a proposed cause and remedy. It tells the team very little about the loss. A useful statement says what went wrong and where. It names the period reviewed and explains the effect on the next user.

For the fictional factory, the starting statement is:

During the four weeks before this project, 40 of 400 production order packs contained at least one defined error at first release. Cutting and planning staff had to resolve the errors before using the affected information. The project will confirm this baseline and investigate how such errors enter or pass through the release process.

That wording does not blame the person who typed the final record. A wrong value might have come from an old source file, an unclear instruction or a later change applied to only one page. These are possibilities to test, not conclusions to include in the charter.

The statement also avoids claiming that every error delayed shipment. Some may have been caught before work was due to start. Others may have caused a real interruption. If the business case includes delivery loss, link each claimed event to the error. Support its time or cost with a clear record.

Fix the boundary before the target

For this project, an order pack means the approved set of internal production instructions. Each pack has one unique release ID. The study begins when the pack enters the release check and ends when it is first issued for use. Later findings may reveal errors that were present at first release. The team therefore keeps a review trail after that event.

Included records cover one factory's specified garment lines and their normal release route. Buyer negotiations and initial product design sit outside this project. So do supplier delivery performance and unrelated machine losses. An issue outside that boundary goes to its proper owner rather than silently expanding this project.

The boundary still needs a route for changes. Suppose the team finds that most conflicts arrive in an upstream file it cannot edit. The sponsor may extend the scope, involve that file's owner or narrow the goal. Any decision should have a date and reason. Leaving the original target unchanged while removing the difficult cases would hide the problem.

The CMS project-charter worksheet sets out goals and boundaries. It also covers people, resources and approval. It was developed for healthcare improvement. Those planning prompts can also help a factory, but the worksheet is not an apparel compliance requirement.

Establish what counts as an error

In this case, a pack has an error if its released information fails an agreed requirement that was valid at the release time. A size total might not match the sum of its quantities. Other errors include an obsolete approved revision or a required field missing from the record.

A newly approved buyer change after release is not automatically an original error. The team compares the released pack with the requirement that applied at that moment. It can track later change handling separately without rewriting the first-release result.

One pack may have several errors. A wrong revision and a missing quantity can be two error instances in one affected pack. The charter therefore separates the number of packs with errors from the total number of errors found. Neither number should be labelled simply “defects” on a chart with no further definition.

Repeated correction visits do not create new packs. If the same release returns twice, it still has one release ID in the first-release count. Additional work and new mistakes during correction can be recorded in separate fields. This lets the team study repeat handling without inflating its denominator.

Before accepting the baseline, two reviewers each classify a small set of actual records. Include disputed cases in that set. They compare their reasons, resolve unclear rules and repeat the exercise where needed. Agreement on easy examples alone says little about the cases that cause conflict. The project should retain examples of both included errors and legitimate changes.

Build a baseline with a clear denominator

The fictional baseline covers every first-released pack in the selected scope over four complete weeks. The reviewers checked all 400 packs against the same definition. This is a census of that period, rather than a sample drawn only from complaints.

The first-release error-pack rate is:

40 ÷ 400 × 100 = 10%.

The separate count of error instances per 100 released packs is:

55 ÷ 400 × 100 = 13.75 errors per 100 packs.

The second figure is not a 13.75% rate of packs with errors. Several errors can belong to the same pack. Changing between those measures would make a trend look better or worse without any change in the process.

These four weeks describe what happened in the defined period. They do not establish a universal factory rate or prove that the process was stable. The team should keep the daily or weekly sequence, release volume, product mix and relevant route changes. A pooled percentage can hide a problem concentrated in one type of order.

Where a source record is missing, mark the case as unresolved and investigate it. Do not count a pack as correct merely because nobody filed a complaint. If the team later corrects the baseline, the charter should preserve the old value, the new value and the reason.

Make each observation traceable

The measurement plan needs more than a column for yes or no. For each release, record its unique ID, first-release time, applicable source revision and review status. An error record should name the rule that was not met and when the issue was found. It should also point to the evidence. The reviewer should be able to return to that evidence without relying on memory.

Discovery time and release time serve different purposes. An error found on Friday may belong to a pack first released on Monday. Counting only Friday's releases beneath Friday's discoveries would mix different groups. For the baseline, assign the error to its original release group and keep the discovery date as a separate field.

Agree a review cut-off so that comparison periods have a similar chance of revealing errors. In this example, complete review of every released pack is part of the measurement method. If later evidence changes a closed period, revise it transparently. Do not compare a fully checked baseline with a recent period that has barely been reviewed.

Access also matters. The working sheet can refer to a controlled source record rather than circulate complete customer files. People need enough detail to trace the fault. Access to records and the time they are kept follow the factory's existing rules. Removing unnecessary personal names can also keep the discussion focused on the process.

Finally, separate severity from frequency. A rare wrong instruction with serious consequences should receive the response required by its risk. It must not disappear behind a long list of minor missing fields simply because those fields dominate the count.

Set an outcome and protect the surrounding process

The proposed goal is to reduce the first-release error-pack rate from the confirmed 10% baseline to no more than 4% by the end of project week 10. The result will cover all eligible first releases in weeks 7–10, using the same error definition and complete review method.

The change from 10% to 4% is 6 percentage points. Relative to the baseline rate, it is a 60% reduction, calculated as (10 − 4) ÷ 10. Both descriptions are valid, but they answer different questions.

The target is an illustrative project goal, not an industry benchmark. It does not authorise acceptance of a critical error. The factory's existing escalation and release controls still apply to every affected order. Meeting the monthly target does not change those rules.

The Institute for Healthcare Improvement distinguishes outcome, process and balancing measures. Applied to this factory case, the outcome is the error-pack rate. A process measure could show whether a tested release step was completed. A balancing measure would reveal harm elsewhere, such as extra release delay.

The exact process measure should follow the selected remedy. The number of training sessions shows whether a course ran. It does not show whether released packs became more accurate. The team can record training without making it the main success measure.

Release time and extra checking effort deserve attention from the start. A new check that catches errors but adds a long queue may simply move the loss. Urgent orders also need review. People may bypass a slow process when time is short and the risk is high.

Put the working charter on one controlled record

The charter can fit on a short form with supporting definitions attached. It should be brief enough for the team to use, yet precise enough that another person could reconstruct what the project promised.

The form needs real names in use. “Management” cannot approve a change when two departments disagree over who has authority. The sponsor needs enough authority to settle those conflicts. The project lead needs access to the people and records involved.

A version number prevents an old goal or definition from resurfacing in a later report. Keep the error rules and baseline data in the supporting files. Include open questions and a log of decisions. The form can link to those records without copying every transaction into the charter.

Give each phase an evidence gate

ASQ's DMAIC outline starts with a clear problem and sound measures. The later phases examine causes, test changes and keep the gains in place. For this case, phase approval depends on evidence rather than a presentation saying that the calendar date has arrived.

During weeks 1–2, the team confirms the scope and reviews the earlier four-week baseline. It also settles disputes about how to classify errors. The sponsor can approve the next phase when the denominator and error rules are usable. If the baseline cannot be trusted, the plan must allow new data collection.

Weeks 3–4 focus on possible causes. The team traces selected errors from the released pack back through the source and approval history. It also examines correct packs made under similar conditions. Suppose the team suspects an old template. The records should show that template, the wrong field and a plausible route into release. This supports the claim more than a general complaint about old files.

Weeks 5–6 allow a limited trial of the chosen change. The trial plan defines which releases use the new method, who checks results and what would stop the trial. The four-week follow-up in weeks 7–10 then tests whether the approved approach holds under normal work.

Those dates are a planning assumption for the example. A serious unresolved measurement problem or a failed trial may require more time. The sponsor should approve the revised dates openly. Missing evidence is a poor reason to close a project just to meet its schedule.

Investigate causes before buying a remedy

The team may suspect rushed entries or unclear source files. Duplicate templates and weak access control are other possible causes. A fishbone diagram can organise such possible causes. Its branches are hypotheses, however; a popular suggestion still needs evidence.

Suppose errors appear more often on urgent orders. Urgency may contribute. Yet those orders may use a different route, contain more changes or arrive without all the needed inputs. The team should examine those differences before deciding that faster work itself caused the mistakes.

A useful trace follows one wrong value across the actual records. Was it already wrong in the source? Was a correct value copied badly? Did one department use a later revision than another? Each finding points to a different control. More final checking might catch all three, but it would not explain why they recur.

Error frequency can help select where to investigate first. Time spent resolving each type may change that priority. ApparelDiary's Pareto chart guide compares garment defect counts with rework minutes. It explains why the two rankings can differ. Neither ranking proves the underlying cause.

Test a change against its intended failure

Imagine that the records reveal a specific fault. One shared form allows release with the required revision field left blank. A trial could prevent release until that field contains a valid reference. This is a defined response to observed evidence, not a reason to automate every field.

ASQ's mistake-proofing guidance distinguishes preventing an error from making it immediately visible. For the proposed field control, checking that text exists only prevents a blank. It does not prove that the text refers to the correct approved revision.

The trial therefore needs challenge cases. Test an empty field and an obsolete reference. Also test a valid reference for the wrong style. Each should produce the intended response. A correctly completed pack should pass without unnecessary delay. The team also needs a controlled route for genuine exceptions and a record of who authorised them.

People who prepare and use the packs should take part in the trial. They can reveal faults that a demonstration misses. Messages may be hard to read, or work may move to an untracked spreadsheet. A bypass is evidence about the process, not merely a reason to repeat the instruction more forcefully.

If several changes start together, the team may only be able to judge their combined effect. It should not assign the entire gain to one feature without a suitable comparison. The record should also note changes in volume, order complexity and staffing during the trial.

Value the opportunity without promising cash

The charter may need a business case to secure staff time. ASQ's cost-of-quality framework separates prevention and checking costs from the costs of failures. In this example, extra release checking and error correction belong on different sides of the proposed change.

Assume that the baseline's 40 affected packs required 1,200 recorded labour minutes of correction in total. This is 20 labour hours, with an average of 30 minutes per affected pack. It excludes waiting time and avoids counting the same person's overlapping activity twice.

At the target rate, a comparable future volume of 400 packs would contain no more than 16 affected packs. If the mix and average correction effort stayed the same, avoiding 24 affected packs could release 24 × 30 = 720 labour minutes, or 12 hours.

Now suppose the proposed control adds one labour minute to every pack. At 400 packs, it uses 400 minutes. The estimated net capacity gain becomes 720 − 400 = 320 minutes, about 5.33 hours. Ignoring the added check would overstate the benefit.

Value the labour at an illustrative 15 currency units per hour. The avoided correction then has a time value of 180 units. Added checking is worth 100, leaving a net time value of 80. This is not automatically a cash saving when paid hours remain unchanged. Training, setup, software and other change costs would still need separate treatment.

These figures are a conditional estimate, not a result. Actual correction effort may change with the error mix. Finance should check the valuation basis and confirm any real spending reduction. Only then should the project report a financial benefit.

Hand over a response, not just a lower percentage

At the end of the trial, give the process owner the current method and approved error definitions. The owner also needs access to the continuing data. The handover should also say who responds when the control fails, an exception occurs or an error reaches a user.

A good response covers the affected pack and any recurring pattern as separate tasks. Closing one wrong record does not show that the process is fixed. Conversely, one new error does not prove that every part of the change has failed. The team needs to inspect what happened and act within the existing release rules.

Results should remain in time order with their denominators. If order volume falls, a lower raw error count may be misleading. If the work mix changes, show the relevant groups as well as the total. With suitable ongoing data, statistical process control can help separate routine variation from signals that need a closer look. Four weekly baseline points alone are not a mature control study.

The sponsor can close the project when the evidence supports the agreed outcome and the owner can maintain the process. If the target was missed, the closure record should say why and identify the remaining work. A useful charter supports that decision. It has kept the promise, the measure and the boundary visible throughout the work.

References

• ASQ: DMAIC process and project phases.

• CMS: Worksheet to Create a Performance Improvement Project Charter.

• Institute for Healthcare Improvement: Establishing Measures.

• ASQ: Fishbone Diagram.

• ASQ: Mistake Proofing.

• ASQ: Cost of Quality.