Operational Definitions, Defined
©2020, George J. Irwin. All rights reserved.

My wife and I have made a habit of playing the card game Skip-Bo, the object of which is to get rid of all of your cards before your opponent(s). When it’s just the two of us, it’s thirty cards each to start, and zero cards remaining at the finish.

A point of philosophical discussion between us is what constitutes a “bad beat” or “a big win,” depending on which end of the outcome you’re on. I think that if I have twenty cards or more left when my wife’s discarded her pile, that’s a “slaughter.” My wife is thinking that a “slaughter” is more than half the deck remaining, which would be sixteen plus cards out of thirty.

That’s the idea behind an Operational Definition. Wikipedia’s entry includes this: “An operational definition is the articulation of operationalization used in defining the terms of a process needed to determine the existence of an item or phenomenon and its properties...”

OK, so I had to read that five times.

Fortunately, this can be made simpler for purposes of Lean Six Sigma. It’s a description of something that everyone agrees on. For example, the definition of a train “arriving on time” could be that it reaches its destination no later than the hour and minute that is posted in a timetable. It’s easy to understand, it’s not controversial, and it can be consistently measured. It also can be expressed as a binary condition at times: the train is either on time or it isn’t.

Operational Definitions increase in importance as the complexity of the process in question increases. That especially includes when more than one organization is involved. Misunderstanding, confusion, and sometimes loud arguments result when there are pre-conceived notions of the definition of something important to a process. For example, is a specific familiar chocolate confection “defective” if the candy shell is cracked, or the letter printed on it is smeared, or both, or neither? How many of these confections need to be “defective” before the entire package is considered to be a throwaway? (Hypotethical, of course: I’d never waste chocolate.) There had better be agreement on this early in a project. If there isn’t, then it will be that much harder to measure progress and success.

Less obvious but perhaps more important: acronyms. If a project spans multiple organizations it’s a pretty safe bet (or PSB) that at least one Three Letter Acronym (TLA) is going to stand for different things for different people (DTFDP). Some acronyms have been around for so long that it’s simply assumed that “everyone” knows what it means. Don’t assume! You know the saying. Oops, wait, I just assumed that you know the saying, didn’t I?

Anyway, it is well worth the time to document the Operational Definitions of key items that are part of a process, either in the execution or the measurement. If they’re subject to interpretation, get that list of definitions somewhere into a presentation to gain unanimous agreement. You’ll be happier that you did. Whatever that means.