How to Set a Defensible Baseline in the Measure Phase

A Green Belt presents the Measure tollgate. First-pass yield sits at 84.2 percent, the target is 95, and the slide says so in a large font. The sponsor asks one question: "84.2 over what period?" The answer is three weeks in July, pulled from a supervisor's spreadsheet, during a month when the second shift was down for training. The number is not wrong. It is undefendable, and every improvement claim the project makes later will be measured against it.

A baseline is defensible when it survives four questions without a story attached. Which period? Which source? Can the gauge see the change the project intends to make? When was the number frozen? Answer them in the charter, with the raw data filed behind the figure, and the baseline stops being a negotiation.

What finance and the sponsor will challenge

The sponsor tests representativeness. Was the process running normally? Did the sample include the bad shift, the peak month, the product family that generates most of the complaints? A baseline drawn from a convenient week overstates or understates the problem, and either way the Goal Statement built on it is wrong.

Finance tests traceability. A baseline that will later support a savings claim has to be reproducible from a system finance already trusts. If the number came from a hand-kept tally, the controller cannot reconcile it to anything, and the savings that hang off it become soft by default. Hard Savings vs Soft Savings: Getting Finance to Sign Off shows what happens to a claim whose baseline is undocumented: the controller strikes it.

Fix the sample period first

Choose the period before pulling a single row, and write down the reasoning.

1. Cover at least one full operating cycle. If the process has a monthly close, a weekly schedule rotation, or a seasonal demand swing, the baseline must contain the whole cycle. Lean 6 Sigma Hub's guide to Measure phase timing puts the typical collection window at two to four weeks inside a three-to-six-week Measure phase, with the caveat that the window has to be mapped against process cycles rather than the calendar.
2. Exclude known abnormal events and say so. A line shutdown, a system migration, a one-off recall. Remove them from the sample and record the exclusion with dates. An undocumented exclusion looks like cherry-picking; a documented one looks like judgment.
3. Get enough points to see variation. For continuous data, 30 observations is the usual floor. For attribute data such as defect counts, the sample has to be large enough that the rate is not dominated by a handful of events. If a month yields four defects, the baseline is a guess, and the Goal Statement should say so.

State the period in the charter as dates, not a description. "1 March to 31 May 2026, 13 weeks, all three shifts, product families A and B" can be checked. "Q1 and part of Q2" cannot.

Name the data source and its owner

The source determines how far the number can be trusted. The transactional system of record (ERP, MES, ticketing, billing) is the strongest source because finance already reconciles to it. A departmental database or BI extract is next: reproducible, but check who maintains the query and whether its definitions match what the charter means. A manual log or spreadsheet is the weakest. Use it only when nothing else measures the metric, and then treat the log itself as something to be validated.

Whatever the source, record three facts alongside the number: the system or file it came from, the exact query or filter used, and the person who pulled it. If a controller wants to re-run the extract six months from now, those three facts are what makes it possible.

Run a measurement system sanity check

Before the number is frozen, confirm the measurement system can distinguish the change the project intends to make.

For a physical gauge, run a Gage R&R. The AIAG MSA manual's criteria treat gauge error under 10 percent of total variation as acceptable, 10 to 30 percent as conditionally acceptable, and over 30 percent as unacceptable. The manual itself warns against using those thresholds as the only test, a caveat SPC for Excel's review of the criteria quotes from page 78. The practical question is simpler than the percentages: if the goal is to move yield from 84 to 95 percent, can the gauge see an 11-point move, or is that inside its own noise?

For transactional and service metrics, the measurement system is a definition plus the people applying it. Run an attribute agreement check. Give two or three people the same 30 records and have them classify each one (defect or not, on-time or late). Disagreement above about 10 percent means the operational definition is doing the measuring, not the process, and the baseline will drift the moment someone new starts classifying.

Then write the operational definition into the charter next to the metric. "On-time" means received by the customer before 17:00 local on the promised date, measured from the carrier scan. That sentence is the measurement system for most CI projects, and it is the one thing the Control phase inherits unchanged.

Date the baseline and freeze it

A baseline has a date of record, and after that date it does not move. Two dates matter: the end of the sample period and the day the number was entered into the charter as final. Both go in the charter.

Freezing is what makes the later comparison honest. Improvement is measured as post-improvement actuals against the frozen figure, over a comparable period, using the same source and the same definition. When the baseline was set from three months of ERP data, the improvement claim uses three months of ERP data.

If the baseline later proves wrong (a definition error surfaces in Analyze, or a source turns out to double-count), revise it once, record why, and re-date it. A documented revision is evidence of rigor. Silent drift is evidence of the opposite.

Why skipping Measure is the most expensive mistake

A weak Define phase produces a vague charter, which Measure usually repairs. A weak Analyze phase produces the wrong root cause, which the Improve pilot usually exposes. A shortcut Measure phase produces a baseline nobody can defend, and nothing downstream repairs it, because every later phase consumes the baseline as an input.

The costs arrive in order. Analyze starts from data that may not represent the process. Improve delivers a change and the team cannot prove it worked, because the before and after numbers were collected differently. Close arrives, the savings claim reaches finance, and the controller cannot reconcile the baseline to any system.

Rebuilding the baseline at that point is not possible in the strict sense. The pre-improvement process no longer exists. The team is left estimating what it used to be, and an estimated baseline is exactly the story finance will not accept. Against the cost of two or three extra weeks in Measure, this is the largest avoidable loss in a DMAIC project.

Where the baseline lives in SixGrid

In SixGrid, the Charter tab holds the Primary Metric with three values: baseline, current, and target, with a progress bar between them. The baseline field is the number this post has been about. The current field is what moves during Improve, and the target comes from the Goal Statement. The Six Sigma Project Charter, Field by Field walks through the fields that sit around it.

The number alone is not the evidence. The Notes journal below the charter is where the sample period, the source, the query, the exclusions, and the measurement system check get recorded as dated entries, so the reasoning lives on the project rather than in someone's inbox. The raw extract, the Gage R&R output, and the attribute agreement sheet go on the Files tab, which collects every attachment on the project in one place. When the sponsor asks "84.2 over what period," the answer is a dated note and a file, not a memory.

Charter Status handles the freeze. A SixGrid charter is Draft or Final, independent of the project's own status. Keep it in Draft while the baseline is being collected and the definition argued. Set it to Final the day the baseline is dated and agreed with the sponsor and the Financial Rep, and the Activity Log records who did it and when. From that point the baseline is the project's fixed reference, and the same figure is what a benefit on the Financials tab is later claimed against. Six Sigma Financial Tracking That Finance Will Sign Off On covers how that claim is classified and validated, and the Continuous Improvement hub holds the rest of the program discipline these posts belong to.