In several threads we have discussed the merits of meeting (and some cases, exceeding) our Customers requirements and expectations. Occasionally, we have used the words "requirement" and "expectation" interchangeably. But some of us, also feel that there is a difference. These discussions are, however, located in a multitude of threads.

I commence a new round of Internal Auditor training next week. Not only will I be bringing my existing Auditors up to speed on the new standard (as part of our transition process, I only had time to update a handful), but I will also be introducing some fresh eyes into the pool.

A few keeners have already read the Standard and have asked, "What is the difference between an 'expectation' and a 'requirement'?"

I replied that a requirement is a "must"...there is a corresponding "shall" somewhere in the Standard for it. An expectation is like icing on the cake.

One person countered with "But isn't a Customer expectation a requirement? We want to keep them happy, so what they expect, we should do?"

Interesting...and valid...point.

So, these two situations - conversations in multiple threads and a soon-to-be Internal Auditior - have prompted me to start this thread.

Let the word games begin! :agree1:

Here is some fuel for the fire:

:D

Requirement:

 Something that is required; a necessity.

 Something obligatory; a prerequisite.


 That which is required; an imperative or authoritative command; an essential condition; something needed or necessary; a need.


Expectation:

 Something expected

 That which is expected or looked for

 The prospect of the future; grounds upon which something excellent is expected to happen; prospect of anything good to come, esp. of property or rank.

 The value of any chance (as the prospect of prize or property) which depends upon some contingent event. Expectations are computed for or against the occurrence of the event.

 belief about (or mental picture of) the future

 wishing with confidence of fulfillment

 the feeling that something is about to happen

Oh boy, here we go!

I feel there is a difference between them, but what do I know?

ISO 9000 says a requirement is a "need or expectation that is stated, generally implied, or obligatory". Then they add 4 notes.

Seems your auditor was correct -- in the ISO world.

I am not going to say that requirement and expectation mean the exact same thing, but when it comes to what a customer expects from me, it pretty much becomes a requirement.

If you are my customer, and you order something to some certain set of ASTM standards, with a certain size, and color and due at your plant on a certain date, you have spelled out the requirements I need to meet. Now, as a customer, you expect me to meet those requirement, and I as the supplier must meet them. You may also have expectations that I send you correct invoices, bills of lading, certificates of compliance, etc. I must do those things as per our industry standard practice and if I don't I risk losing you as a customer.

All right, I've rambled on and on, and you are all saying, "what's your point, Steel?" As near as I can tell the difference between a requirement and an expectation is that an expectation is kind of a "soft" requirement. Maybe not stated in so many words, but seen as a requirement in the eyes of the customer no matter what you choose to call it.:bigwave:

In spite of ISO (I know, I know) to me there certainly is a difference.

A requirement is something that is spelled out, as in a spec sheet or purchase order.

An expectation is not necessarily spelled out, but is still "expected" to happen.

For example, many companies have a 100% on-time delivery requirement spelled out somewhere in the purchasing documents. They may not, however, state that the pallets of goods must be upright when they arrive. From the few times we have had Evil Kenevil (sp?), pretending to be a trucker, hauling our loads, I would say that our customers expect upright pallets, even to the point of issuing a SCAR when the pallets are not upright.

So, even if I think there is a difference, the end result is that it doesn't matter, even if there is a difference, and even if ISO was to say otherwise. They both are treated pretty much the same.

IMO, of course.

Craig

:agree:

If the customer orders a product, the requirements are spelled out in the product specificaton or on the purchase order. The expectations may be unspoken. They expect it to arrive on time, they expect the containers to be in good condition, they expect all of the documentation to be accurate, they expect the supplier to be available as needed, they expect issues to be resolved in a timely manner.

The list goes on and on. The definition of the two may be different but if you are going to truly meet the requirements of the customer, I think that you have to treat everything as a requirement.

Not to mention that it is just good business practice.

:agree1:

Expectations become requirements that are to be met,

Requirements are expected to be met,

2 + 2 = 4,

1 + 3 = 4.

The net result is the same.

The only gray area to me is when a requirement that is not met is generally easy to find and address because the requirement is defined; whereas the expectation that does not get met is in most cases harder to "fix" because it is a perceived requirement rather than a documented requirement.

In that line of thought a missed expectation in most cases can be more detrimental to the customer / supplier relationship compared to a documented requirement that was missed. The missed requirement can (hopefully) be fixed, while the missed expectation may change the perception longer term.

I hope that makes sense. JMO.

ISO 9000 says a requirement is a "need or expectation that is stated, generally implied, or obligatory".

I would interpret this in the following fashion:

I have the responsibility for gleaning from my customer defined "requirements". Those requirements may be based upon a perceived need (specific and obligatory "hard" requirement), or an expectation ("softer" negotiable requirement).

As an example: My customer may require an electric motor capable of a minimum of 1/2 hp (the need), and would like to have the ability to generate 3/4 hp (the expectation). It is now my responsibility to at a minimum meet their defined need, and if possible I will strive to meet their expressed expectation. But I know that (as an example) if the state of the art is such that 3/4 hp is beyond known capabilities for the size of motor they are asking for, then I am free to provide them with a product that meets their needs and as much beyond as possible.

But that is just my interpretation.
;)

I am not going to say that requirement and expectation mean the exact same thing, but when it comes to what a customer expects from me, it pretty much becomes a requirement.:

I guess their "EXPECTATIONS" are that we meet their "REQUIREMENTS"! :lol:

I interpret it (ISO9000) to mean that it is our responsibility to clearly understand what the customer wants above and beyond written requirements as per 7.2.1 and meet them. "Generally implied" and "expected" is kinda vague and a smart customer will try to minimize problems by clearly stating (i.e. in writing) anything that is important. I would hope that most of this stuff relates to common things like the customer expecting the same type of packing or shipping containers as were used in the past, consistent paperwork, cleanliness, etc.

I interpret it (ISO9000) to mean that it is our responsibility to clearly understand what the customer wants above and beyond written requirements as per 7.2.1 and meet them. "Generally implied" and "expected" is kinda vague and a smart customer will try to minimize problems by clearly stating (i.e. in writing) anything that is important. I would hope that most of this stuff relates to common things like the customer expecting the same type of packing or shipping containers as were used in the past, consistent paperwork, cleanliness, etc.

So what is measured for Customer Satisfaction? ISO 9001:2000 states "measurements...relating to customer perception as to whether the organization has met the customer requirements."

What do we do when requirements are met but the Customer is not "satisfied" because expectations were not met? Should expectations then become requirements? Should Customer Complaints be issued because of a failure to meet an expectation?

You're right, Mike, that a smart Customer (and, IMO, a smart Organization) would have everything in writing...requirements and expectations. It's good business sense and a :ca: .

I've used this example during training.

I asked my son, who was 13 at the time, to take out the trash and place a new bag in the can. When I checked to see if he had completed his task I didn't notice a new bag in the can. When I opened the lid a new bag was in the can, just not opened up.
Now he met my requirements, but he didn't meet my expectations.

I've used this example during training.

I asked my son, who was 13 at the time, to take out the trash and place a new bag in the can. When I checked to see if he had completed his task I didn't notice a new bag in the can. When I opened the lid a new bag was in the can, just not opened up.
Now he met my requirements, but he didn't meet my expectations.

Did you complain?
Did he review the situation and a new bag put in as per your expectations?
Has what was an expectation now become a requirement?

I've used this example during training.

I asked my son, who was 13 at the time, to take out the trash and place a new bag in the can. When I checked to see if he had completed his task I didn't notice a new bag in the can. When I opened the lid a new bag was in the can, just not opened up.
Now he met my requirements, but he didn't meet my expectations.

This is a very good example of how this all ties to customer satisfaction and the perception that a customer has of its suppliers. Great example. :applause:

I've used this example during training.

I asked my son, who was 13 at the time, to take out the trash and place a new bag in the can. When I checked to see if he had completed his task I didn't notice a new bag in the can. When I opened the lid a new bag was in the can, just not opened up.
Now he met my requirements, but he didn't meet my expectations.


Right on the money!!!! :applause:

... a smart customer will try to minimize problems by clearly stating (i.e. in writing) anything that is important.

Just a note - just to play devil's advocate here - I don't know if I totally agree with this in every respect. When I go to Tim Horton's <offside: what a beautiful thing!>, I expect my coffee to be hot. It's overkill for each customer to have to ask for that. There are certain *very important* characteristics of certain products that, as a customer, I wouldn't expect to have to state. JMO, though...I might be off the beaten path here. :tunnel:

I think the point being made by the standard is that we need to determine the customer's expectations and satisfy them as well as the requirements. If we know as the "experts" that customers in the past have wanted a garbage bag opened in the bin, it is our responsibility to bring this to the attention of the customer and clarify their expectation.

Some of our products have a higher temperature rating than others but more than one can be listed on the same spec as an approved material. If we find a customer is asking for a low temperature material, we should be asking what they are expecting the material to do for them. They may have no idea there is more than one material and although it wasn't actually said they expected it to work just as well under high temperatures.

IMO the standard is now placing a greater responsibility on us as "experts" to anticipate reasonable expectations for our own products and services. A follow-up to satisfying the requirements of confirming it met expectations is simply a way to better perform as the "expert".

Dave

Just a note - just to play devil's advocate here - I don't know if I totally agree with this in every respect. When I go to Tim Horton's <offside: what a beautiful thing!>, I expect my coffee to be hot. It's overkill for each customer to have to ask for that. There are certain *very important* characteristics of certain products that, as a customer, I wouldn't expect to have to state. JMO, though...I might be off the beaten path here. :tunnel:

Well you're right of course -- there are certain things you don't expect to need to say like that you want your coffee hot or salt and pepper available on the table of the diner, etc.

But my point is that as a customer I want to get the right thing the first time, and I have a duty to my company to get the right thing, and therefore a duty to make what I think is a reasonable effort to clearly state my expectations in enough detail that we will indeed get the right thing. And, yes, the supplier has a duty to make sure they know what I want. If we both make a reasonable effort at this there should be few times when my expectations were not understood by the supplier. Sometimes my PO's state some things that might make some suppliers say "well duh!", but these things probably came about because I was burned in the past or because I was just making sure. Will I still get burned someday? Probably, but not often.

Will I still get burned someday? Probably, but not often.

Especially not with a cold coffee... :biglaugh:
(ba-dum-bum...okay, sorry folks, that was lame.) :rolleyes:

I guess that this is where the customer's "perception" comes into play. . . not every customer's expectations are the same. . .and someone who likes luke warm coffe might think that the coffee served is too hot. . . while some Asbestos mouthed customer might think the same cup of coffee is too cool.

After 35+ years in the music biz. . . Ya gotta to play your audience

JMHO. . . :2cents:

As most do, I agree that requirements are clearly and specifically spelled out, whereas expectations are the 'obvious' characteristics that don't really need to be spelled. The expectations, however, maybe just as important as the requirements; e.g., the un-opened trash liner in the can is useless until it is opened up.

But be careful about 'exceeding' requirements in an attempt to meet 'perceived' expectations. A few days ago I started a thread on this subject, BTW.

A fine example of what can happen is provided by David. He said that the customer required a 1/2-hp motor, but to exceed the expectations, the vendor may provide a motor with an output of 3/4-hp. However, the 3/4-hp can present a variety of problems: It would draw more current than expected and overload the supply circuit and components, or the additional torque may override clutches and other safety mechanisms, to name a couple. Perhaps a 3/4-hp may be fine, but it definitely would be better to provide what the customer specified.

How would we meet (not exceed) expectations in this case? Well, for example, the customer may have not specified that the paint on the motor should be evenly applied and not peel off, but we know that, so we will provide a nicely painted motor with a durable finish.

Alex

Pardon me if this has already been said, but could it be that the term "requirement" implies a contractual obligation? Is it possible that it is as simple as that................?

Pardon me if this has already been said, but could it be that the term "requirement" implies a contractual obligation? Is it possible that it is as simple as that................?

What you say is generally reasonable, but in the ISO world we cannot ignore the fact that ISO 9000, section 3.1.2 defines requirement as a "need or expectation that is stated, generally implied, or obligatory". Your definition is closer to what ISO 9000 refers to as a "specified requirement" (note 3). :bonk:

Especially not with a cold coffee... :biglaugh:
(ba-dum-bum...okay, sorry folks, that was lame.) :rolleyes:

Yep, it was lame, but I would have said it as well.

I think the answer to the question comes from the standard itself.

7.2.1
a) requirements specified by the customer...(requirements)
b) requirements not stated ...but necessary...(expectations)
c) statutory and regulatory requirements... (expectations)
d) any additional requirements...

If we look at all of the examples here, from coffee to pallets remaining upright, they all fit into one of the three categories. When I order coffee, I "expect" it to be hot. That falls under b). There may be laws on how hot the coffee has to be (minimum/maximum). That would fall under c). Of course I want it with cream and sugar. That's an a) item. Tim Horton franchise rules might also specify the temperature range of coffee. That would fall under d).

Anything the customer "expects", but doesn't specifically ask for would fall under b), at least in my opinion. It all goes back to "what does the standard say". :read: