Q. 105  Operational definition” is a prerequisite before any data collection activity. Best defined, it is a clear, succinct and non-ambiguous statement that provides a harmonized understanding of the metric for all involved before data collection. What constitutes an operational definition? 

Prima facie, though it may appear to be a simple and straight forward process, what are the examples from your experience which indicate otherwise?
 

 

Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.

• All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/
• Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening as per Indian Standard Time.  
• The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.

Operational Definition: It helps in providing a clear-cut detailed definition of a metric. It provides a systematic way of transforming a conceptual definition to a kind of measurable one.

When can Operational Definition be defined ?
Before you collect your data ? Why ? Otherwise in reality, you may not be able to ascertain whether the collected data is right or wrong and therefore you cannot take a decision.

 

What will happen if there is no Operational Definition ? Why is it important ?
If there is no Operational definition for a metric or a characteristic which you need to know, you may not know how it should be used/addressed. In that case, an organisation can get erroneous or indifferent results. There would be no standardization of its usage/addressing.

Benefits of Using an Operational Definition(for a metric/characteristic):
1. There will be a standardized way of usage across the organisation.
2. It will be easy to explain about the metric/characteristic, to new joinees as it is standardized.
3. Since, how to do and what to do part is known, making errors or doing incorrect ways of things will be avoided.
4. A Qualitative product will be achieved because of #3.   

Let us see quite a few examples on Operational Definition.

Before we go on with some serious example, let me try to make with a simpler and easy example. Let us take the sport of Cricket(Please bear with me if you are not a keen follower of cricket). Now our matter of interest is "No-Ball" which is not a legal delivery, in Cricket. So you want to know the Operational definition of a 'No Ball'. That will tell when can a ball delivered be declared as No Ball and under what circumstances. Two teams were playing cricket in a popular, local tournament, played with international cricketing rules . Team A was batting and Team B was bowling. Team A was chasing a stiff target. The Umpires were checking consistently for 'Overstepping the bowling crease' no ball and 'waist-high' no balls. But the Umpires were not focussing on the number of fielders to be placed inside the 30-yard circle during the 'powerplay' period, when there is a 'fielder' restriction. This cost the Team A dearly and it lost the match very closely. This could not have been the case, had the batting team(Team A), knew the Operational definition of a 'No Ball'[effectively which will say how 'No Ball' can happen, which is actually not a legal delivery(an error case)]. So the 3rd way of a 'No-Ball' happening was missed out as the team did not have a clue about. Here for 'Overstepping', 'Waist-high' and 'Fielder Restriction Missing on powerplay period' can be seen by naked eye as a measurement way. Where there is an element of doubt, ball tracking mechanism can be used for the first 2 and 3rd Umpire replay can be used for the 3rd One. What is the decision to be taken for if each one of these is happening. For 'Overstepping' case, there would be an extra run and a 'Freehit' given. Similarly, for 'Fielder Restriction Missing' No-Ball case also a similar approach would be used. Because this was not known to the team, Team A suffered. Extend this approach to the Industries, we can really see how important this Operational definition is .

 

Let us move to a real world example.
In an IT maintenance project (support project which went to production),  a team was trying to measure the backlog management index(BMI).A BMI is nothing but the percentage of, dividing the  total no. of tickets (read issues/incidents) that got closed in a given month, by the total no.of tickets(issues) that had arrived in that given month.

 

i.e BMI= (Total no. of closed issues in a given month/Total no. of issues arrived in that given month) * 100.

 

The measuring characteristic here was the status of the incident ('Incident Status'). The tool where this was measured was 'Remedy'. There are many such Project related issue management tool(s) . Here the data was taken between the start date and end date of the given month(used every month of a year). All issues that were marked as closed in the tool, as of any date in the given month was considered for this measurement. All issues which had arrived in that given month, was taken for calculation for this measurement. The measurement unit was a dimensionless number.

What did this BMI imply ? If BMI was greater than 100, then backlog was reduced (issues on production got reduced) , else if BMI was less than 100, then backlog was increased. This is a proven operational definition existing for a long time, in the industry. But this was not used in that portfolio as this was the first time that the team ran into a maintenance project. In the initial period, there was a confusion about how this would be defined or interpreted. It was misinterpreted by people who newly joined the team. Why ?Because there was no operational definition for BMI (because it is an industry standard and the need for a portfolio-level definition was therefore missed out). The confusion was due to the fact that new joinees thought that they should take the 'closed' status of incidents/issues only for the incidents(issues) that got opened in the given month. Ideally all incidents that got 'closed' on a given month should have been taken. So without a formal operational definition, put in place, the data collected were skewed. This portrayed a BMI which was showing lot of backlog ,when actually it was not the case. Then when the root cause was identified, then the team put a proper operational definition and ensured that the data collected was correct and the results were there to see and customers saw more than 100% BMI, for most of the months in that calendar year.  

 

In one of my friends' hotel where i had dined, i found the hotel staffs collecting Customer Satisfaction Index (CSI). One of the staffs asked me about how the food was ? I told food was tastier but the quality needs bit of improvement. He was bit perplexed as he could not fathom out what i mean by this. I explained that the quality of the food that i took was not upto the mark and that some of the curries and the corresponding ingredients were not baked propery.  But in general, food was tastier to the mouth!! When i found what could be the reason for him not understanding these things, i found that a proper documentation/practice of CSI is not followed and customer satisfaction has become a kind of a routine question and has been asked based on the experience of the staff. A Clear-cut operational definition of CSI was mising. Per owner of the hotel, the CSI tried to capture by that hotel was on 5 aspects - Ambience, Quality of the Food, Taste of the Food, Cost Effectiveness, Customer Care. For each of these aspects, there were certain ways of doing and measuring them. But that was not documented. All of these aspects/attributes can be meassured as Bad/Average/Good/Very Good/Excellent or a range from 1-5 (with 5 being the highest and 1 as lowest rating). They can be measured using a software app using Mobile or hand-held device or manually (depending on that hotel's capability) or any other way. Therefore with a proper operational definition, staffs can be at ease to take CSI across their customers in a consistent way.

 

Conclusion:
Having an Operational definition is very critical to the way how we see a metric or a characeteristic which we want to make use of. Without knowing how it will work, if we start collecting data, then the result can be unexpected or throw errors, that you do not want. We had seen the importance of 'Operational Definition'. Just to portray the importance of this , am correlating an important aspect in Agile Scrum called 'Definition of Done'. This talks about when a user story or a requirement is said to be 'completed' or 'Done'. The 'Definition of Done' ensures that a requirement is completed and that it can be pushed to production(ready for moving to production). 

The definition for this 'Definition of Done' is left to the discretion of the project team which is working on that requirement. Along with the product owner, the development team would define this. A typical 'Definition of Done' for an IT project which is Agile Scrum based could be : a User story should have - Code Completion, Unit Testing completion, Integration Testing completion, System Testing completion, No Severity 1 and Severity2 errors . Now the point here is that this 'Definition of Done' says about what constitutes a requirement's completion. But it does not necessarily tell how these things to be done. This is where 'Operational Definition' differs. It tells the 'how' part as well. Imagine what benefits would a team get if the 'Operational Definition' is defined for the metric(s) that it uses. This is why 'Operational Definition' is so important.

 

Operation Definition , it is clear, concise and unambiguous statement that provides a unified understanding of the data for all involved before the data is collected or the metric is developed. For any data collection activity, OD should be established for each data element that will be collected.Operational Definition constitutes following:

1. Who collects the data?
2. How are the data collected?
3. What data are collected?
4. Where are the sources of the data?
5. When are the data collected.

OD also provides the metric and tell who is the responsible or answerable to its results or in other words we can say that it provides an interpretation of the metric.

 

for example in some organizations, might be possible that a highly accurate required because of regulatory or reporting requirements.So accurate data are required and necessary to drive and sustain real improvement. in aerospace industries we need very high accurate data. and there are some organizations which have processes that deliver data to the other organizations.

 

for example a payroll data regularly reported to the internal revenue service. the consequences associated with poor data accuracy can be quite trouble some an dhave a strong negative impact on the individual who is depending on the data.

The best answer to the question is that of R Rajesh. Rajesh has also provided three examples and they are all well scripted. 

 

Writing an Operational Definition may seem to be simple but it becomes very complex while dealing with abstracts. Example - emotional stability of a child can manifest itself in many ways. It would need to be broken down into multiple elements and defined. But again, that is the very purpose of writing an Operational Definition for a CTQ.