Expectations vs. Requirements - Definitions

[RCBeyette]

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!

[BadgerMan]

Here is some fuel for the fire:



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

[Mike S.]

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.

[SteelMaiden]

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.

[Craig H.]

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

[mshell]

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.

[Tom W]

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.

[David Hartman]

Originally Posted by Mike S.

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.