Operational Definitions: How to Make Two People Measure the Same Thing the Same Way

The Operational Definitions tool does one job. It defines exactly what is measured, where its boundaries sit, and how two independent people must reach the same result. That is the whole promise.

You reach for it in the Measure phase of RDMAICS, before you collect a single row of data. If your team cannot agree on what a term means, every chart you build afterwards is argument fuel rather than evidence. A definition written down first removes that argument.

Use it when a measure has a name that everyone recognises but nobody has pinned down. Delivery time. Downtime. First pass yield. Complaint. These words feel obvious until two people calculate them and produce different numbers. The tool forces you to write the start point, the end point, the method, the source and the edge cases in one place, with an owner and an approver attached.

Everything below is built on one case. It is fictional. It is the sample data that loads with the tool, and it stays consistent through the whole article so you can see one definition built end to end.

The measure is delivery time, carrying the definition identifier OD-001. The measure type is time and duration. The purpose is stated as measuring the end-to-end customer wait and determining compliance with the 30-minute promise. That single sentence does more work than it looks. It tells you the measure exists to answer a question, and the question has a threshold in it.

The population is every completed standard delivery order. Not every order. Not every attempt. Completed, standard, delivery. Three words that quietly remove a large slice of the data before anyone starts counting.

Start with the observable definition. In this case it reads as elapsed clock minutes from the ordering system's confirmed event to the driver's customer-handoff event for the same order ID. Notice that every noun in that sentence points to something a person can see in a system. There is no judgement word in it.

Next come the boundaries. The start point is the order status changing to Confirmed in the production ordering system. The end point is the driver recording Customer handoff in the delivery application. The measurement method is to subtract the confirmed timestamp from the handoff timestamp after matching the same order ID. The unit is minutes. The data source is the ordering and delivery event logs.

Then you fill the rules that stop drift. The source fields are named directly: order_id, confirmed_at, handoff_at, order_type and status. The recording rule stores one record per eligible order using the first valid confirmation and the first completed handoff. The precision rule rounds elapsed seconds to one decimal minute, and only after calculation, not before.

Scope comes last in the setup but matters first in practice. The include list covers kitchen preparation, dispatch waiting, travel and handoff time for completed standard deliveries. The exclude list covers cancelled orders, test orders and customer-requested scheduled deliveries.

Once the fields are complete, the tool presents the definition as a single assembled record. You read it top to bottom as one instruction set rather than as scattered notes in a project folder.

Three parts of the output carry most of the weight. The positive example shows order PZ-1842 confirmed at 18:04:12 and handed off at 18:33:06, giving 28.9 minutes. The non-example states that kitchen-ready to driver-departure time is not delivery time. The boundary case states that a 30.00-minute delivery is on time and a value greater than 30.00 is late.

That boundary line is the quiet hero of the record. Thresholds break down at the exact value, not in the middle of the range. By writing that 30.00 sits on the compliant side, the definition removes a dispute that would otherwise surface in a review meeting months later.

The record also carries governance. The definition owner is the Delivery Data Analyst. The reviewer and approver is the Process Owner. The version is 2.0, dated 2026-02-01, with a status of Approved. The validation evidence records that thirty orders were independently recalculated with 30 out of 30 timestamp matches and 100 per cent agreement. A note sets the timezone rule: use the local store timezone including daylight-saving rules. The tool also offers an AI review that explains the result if you want a second read of the completed record.

A good operational definition is not paperwork. It unlocks specific decisions that were previously unsafe to make.

With OD-001 in place, you can state compliance against the 30-minute promise without caveats. You can compare one store against another, because both are applying the same start point, end point and rounding rule. You can compare this month against last month, because the version number and date tell you whether the rule changed underneath the trend.

It also changes how you treat gaps. The missing or exception rule says to flag either missing timestamp as a data-quality defect, not to impute a value, and to report the excluded count. That turns missing data into a visible measure of its own rather than a silent distortion of the average.

Finally, it supports handover. When the Delivery Data Analyst moves on, the next person inherits a definition with an approver, a version and validation evidence attached. The measure survives the person who built it.

The most frequent failure is writing a definition that sounds precise but contains a judgement word. Terms like prompt, complete or acceptable cannot be observed. The delivery time definition avoids this entirely by pointing at two recorded system events.

The second failure is rounding too early. The precision rule in this case rounds elapsed seconds to one decimal minute only after calculation. Round the inputs first and you shift results in ways nobody can trace later.

The third failure is leaving the scope implicit. Cancelled orders, test orders and customer-requested scheduled deliveries are all excluded here. If that list lived only in someone's head, two analysts would produce two different compliance figures from the same log file.

A few more worth watching for:

A definition is a claim until you test it. The test is simple. Give the written definition and the raw source to a second person who was not involved in writing it. Ask them to calculate a set of records independently. Then compare.

In this case the validation evidence records thirty orders independently recalculated, with 30 out of 30 timestamp matches and 100 per cent agreement. That is the evidence that the definition does what it claims, not an opinion that it reads well.

If agreement falls short, the fix is almost always a boundary or an exception, not the core method. Look at the records where the two people differed, then write the rule that would have prevented the difference. Increase the version number and record the new date and status.

The tool will not tell you whether delivery time is the right measure for your problem. It records the purpose you type in. If you are measuring the wrong thing precisely, the definition will make that error consistent rather than visible.

It will not collect data, calculate performance or produce a compliance figure. OD-001 states that a 30.00-minute delivery is on time and anything above is late, but the tool does not report how many orders fall on each side. That work sits in your analysis tools.

It will not validate itself. The evidence of 30 out of 30 matches and 100 per cent agreement came from people doing an independent recalculation. The tool stores that evidence. It does not generate it, and it cannot tell you whether the sample was representative.

It will not fix a broken source system. If the confirmed timestamp fires at the wrong moment, or drivers record handoff after they leave the customer, the definition will describe that flawed behaviour faithfully. The missing timestamp rule catches absent data, not inaccurate data.

It will not enforce itself across an organisation. Approval by a Process Owner is a record, not a control. People can still build a report that ignores the definition. Sustaining the measure means linking the definition to the reports and queries that use it, and reviewing the version when the process changes.

Used with those limits in mind, the tool does the one thing well that it promises. It makes the measure explicit enough that two independent people reach the same result.