An operational definition sets out exactly what you measure and how, so that everyone who measures reaches the same outcome. Without one, one person measures from the incoming email and another from registration, and you compare apples with oranges. In Lean Six Sigma this is also called operationalising the Y: making the outcome you want to improve unambiguously and reliably measurable.
Why an operational definition?
Words like fast, correct or on time seem clear, but mean something different to everyone. What is fast to one person is slow to another. W. Edwards Deming pointed out that a measurement only means something once you have agreed how to measure: a term like “clean” or “on time” only gets meaning with a method of measurement and a criterion attached.
In an improvement project this is no detail. Your baseline measurement determines how big the problem appears, and after the improvement you want to repeat the same measurement to show that it is better. Measure differently and you prove nothing.
Step 1: Define the Y
The Y is the outcome you want to improve. You derive it from what the customer values, often with a CTQ tree. A customer applying for a mortgage wants a quote within a certain time. The Y is then the lead time of the application.
A Y is usually about one of three things:
- Time: how long does it take? Lead time, waiting time, delivery time.
- Quality: how good is the result? Accuracy, completeness, dimensions.
- Cost: how many resources does it take? Hours, material, rework.
Step 2: Write the operational definition
Next, you record how you measure. A complete operational definition answers these questions:
- Unit: what do you count or measure? An application, an order, a product.
- Measurement method: where does the measurement start and end, in what unit, and from which data source?
- Defect: when is a unit wrong?
- Specification limits: what does the customer accept? An upper limit (USL), a lower limit (LSL), or both.
- Opportunity: how often can it go wrong per unit? For lead time once per application, for a form perhaps at every field.
- Dataset: which period and which units do you include?
The image at the top of this article shows how the vague “the quote must be fast” becomes a measurement everyone does the same way.
Step 3: An example
The customer expects a quote on their mortgage application within two working days.
| Element | Definition |
|---|---|
| Unit | A mortgage application |
| Measurement method | Lead time in working days, from the moment the application is registered in the system to the moment the quote is sent, both according to the system timestamps. Weekends and public holidays don’t count. |
| Defect | The quote is sent later than 2 working days after registration. |
| Specification limit | USL: 2 working days. There is no lower limit: faster is always fine. |
| Opportunity | One per application |
| Dataset | All applications over the past three months |
How much the start and end points matter is shown below. The same application yields three different measurements, depending on who measures.
Step 4: Common pitfalls
- Unclear start or end point. Does the quote count as sent at 17:05, or only when the customer opens it? Record which moment counts.
- A vague measurement method. “We take it from the system” is not enough. Which system, which field, which timestamp?
- No specification limit. “As short as possible” is not a standard. Record what the customer still accepts.
- Exceptions not covered. What do you do with applications that are withdrawn or waiting for the customer? Agree whether they count.
Test the definition
A good test: have two people independently measure the same ten units. If they reach the same outcome, the definition is clear enough. If not, there is still room for interpretation. For measurements with an instrument or a human judgement, you examine this systematically with a Gage R&R.
Conclusion
An operational definition is a small effort with a big effect. It prevents arguments about the figures, makes measurements repeatable, and ensures that after an improvement you can show it really is better. That is why it belongs in the Measure phase of every DMAIC project.
Want to learn how to measure reliably and improve with data? Take a look at the Green Belt course.