Should every Management System include Design?

[howste]

Requirements are defined needs. I am referring to undefined needs.

Undefined needs are not yet requirements.

So you're saying we should define the undefined needs that the customer didn't tell us they needed. These would then become requirements. I agree that this makes sense. How would this be phrased in a management system requirements document? Here's some wording that I would suggest for this: "The organization shall determine requirements not stated by the customer but necessary for specified or intended use." Oh wait! That's already in there in 7.2.1!

Customer needs and customer requirements are essential design inputs (hence 7.3.2).

The design process turns customer needs in product requirements.

You're saying that requirements are both inputs to, and outputs from, the design process. I'd say that requirements are inputs to 7.3 and, as Jim mentions, the outputs are specifications. At least that's what ISO 9000 says:

design and development
set of processes that transforms requirements into specified characteristics or into the specification of a product, process or system

If things are generated within a process they're generally called outputs. Inputs to a process generally come from other processes, whether they be internal processes or external processes (such as a customer's purchasing process). If the customer's process didn't define the requirements for us, then one of our other internal processes must have defined them. A way to describe what that process is doing is determining requirements related to the product. How convenient it is that that's almost exactly the name of clause 7.2.1 in the standard.

Hence 7.3 (which handles customer needs) precedes 7.2.1 and 7.2.1 (which handle customer requirements which may include the requirement for design but unlikely if the customer supplies the design).

Hence, 7.3 doesn't determine the requirements, it turns them into specifications. 7.2 determines the requirements and comes first. For some reason it seems you're trying to mix the two things in clause 7.3. We can't design something until we determine/define what the requirement is.

 

[Sidney Vianna]

Differentiating between needs and requirements is essential otherwise company's just do what is in the contract whether it is right or worng.

I think it is critical to remind oneself of the ISO 9000:2005 definition of the term requirement.

According to the normative definition a need IS a requirement.

 

[John Broomfield]

All,

I strongly recommend that you study the ISO 9000:2005 definition of a requirement again:

3.1.2

requirement:

need or expectation that is stated, generally implied or obigatory.

I have stressed that is because this seems to be at the crux of your misunderstanding. A need is not a requirement until it is stated, generally implied or obigatory.

If the need is not stated, generally implied or obligatory it remains a hidden need.

Designers expose these hidden customer needs for all to understand as essential characteristics of the product (otherwise known as product specifications).

Many customers find it very difficult to fully articulate their requirements. That is why we all need designers to translate the customer's needs into product requirements. That is for the whole product not just the part that happens to be specified in the RFP documents.

BTW, the ISO 9000 definition of design very nearly is illogical but just about works when we consider the fact that the designer elicits from the customer an understanding of his or her requirements.

Respectfully,
John

PS: I am grateful to howste for reminding me that 7.2.1b) requires the organization to determine requirements not stated by the customer but necessary for the intended use. "Necessary for the intended use" helps a lot but is too utilitarian to satisfy the customer's needs. One example, the enjoyment we receive from our iPhones - way beyond "necessary for intended use".

 

[howste]

requirement:

need or expectation that is stated, generally implied or obigatory.

I have stressed that is because this seems to be at the crux of your misunderstanding. A need is not a requirement until it is stated, generally implied or obigatory.

If the need is not stated, generally implied or obligatory it remains a hidden need.

It's a good thing then, that clause 7.2.1b requires that we identify what you call "hidden needs" and state them so that they are requirements that can be used as inputs to the design process.

Designers expose these hidden customer needs for all to understand...

Why? You keep insisting that this is a function only designers can do for some reason. Are designers the only humans capable of ascertaining customer needs? Are you really suggesting that others in the organization working in sales, marketing, customer service, leadership or other functions are somehow incompetent to do this?

Just for the sake of argument, lets say that a "designer" in an organization is responsible to determine customer needs and "expose these hidden customer needs for all to understand." If that's the case, what is being done by this "designer" is still defined in clause 7.2.1.

BTW, the ISO 9000 definition of design very nearly is illogical but just about works when we consider the fact that the designer elicits from the customer an understanding of his or her requirements.

Please elaborate. It's not ambiguous or in conflict with anything I see in the ISO 9000 series of standards. The definition seems logical enough to me. Please state your evidence.

 

[Sidney Vianna]

I have stressed that is because this seems to be at the crux of your misunderstanding.

 

[Jim Wynne]

All,

I strongly recommend that you study the ISO 9000:2005 definition of a requirement again:

3.1.2

requirement:

need or expectation that is stated, generally implied or obigatory.

I have stressed that is because this seems to be at the crux of your misunderstanding. A need is not a requirement until it is stated, generally implied or obigatory.

If the need is not stated, generally implied or obligatory it remains a hidden need.

Designers expose these hidden customer needs for all to understand as essential characteristics of the product (otherwise known as product specifications).

Many customers find it very difficult to fully articulate their requirements. That is why we all need designers to translate the customer's needs into product requirements. That is for the whole product not just the part that happens to be specified in the RFP documents.

I'm lost, and perhaps you can help me find my way. Are you saying that a "designer" is not necessarily a person who designs things for a living (i.e., a person with the word "design" or "designer" in her job title), but anyone who designs anything? If that's the case, you'll need to explain why we need the productdesign requirements of the standard to guide and control those activities, which you haven't done yet.

Perhaps you could help me further by giving an actual example--preferably not a hypothetical--of an instance where a customer found it difficult to express his "hidden" needs, and a "designer" uncovered them and translated them into specifications, and lastly, how the design requirements of the standard made a difference in the whole process.

 

[howste]

PS: I am grateful to howste for reminding me that 7.2.1b) requires the organization to determine requirements not stated by the customer but necessary for the intended use. "Necessary for the intended use" helps a lot but is too utilitarian to satisfy the customer's needs. One example, the enjoyment we receive from our iPhones - way beyond "necessary for intended use".

I think that for consumer goods, user expectations frequently go beyond the simple utility of the item. That's why many organizations collect marketing information, have focus groups, etc. to determine these expectations. Notice that "expectation" is a term used in the definition of requirement that you quoted. They do these activities and define the requirements before they start to design the product, otherwise the cost to design the product is much higher and the time to market is much longer. I'm pretty sure that a user of an iPhone expects the "eye candy" that they pay for and that enjoyment is part of their intended use of the product.

 

[John Broomfield]

I'm lost, and perhaps you can help me find my way. Are you saying that a "designer" is not necessarily a person who designs things for a living (i.e., a person with the word "design" or "designer" in her job title), but anyone who designs anything? If that's the case, you'll need to explain why we need the productdesign requirements of the standard to guide and control those activities, which you haven't done yet.

Perhaps you could help me further by giving an actual example--preferably not a hypothetical--of an instance where a customer found it difficult to express his "hidden" needs, and a "designer" uncovered them and translated them into specifications, and lastly, how the design requirements of the standard made a difference in the whole process.

Jim,

My iPhone example was not substantial enough to make the point. Let us look at more substantial example instead:

Take the MAXXI building in Rome. For this building the owner gave the architect some of the requirements. The remaining requirements had to be elicited by the design process translating the client's needs first into requirements that could be priced and agreed and then into specifications and drawings for realizing this wonderful new building.

Now I am in danger of suggesting that all designers are engineers or architects so let me show how lowly the job of designer can be.

You are leading an expedition to the North Pole. You take the Bean catalog and select the clothing you think will the suitable from the catalog. You are the designer. You have translated the needs of your team and yourself into clothing you determine will keep you alive.

However, the more cautious expedition leader decides to call Bean and ask for advice on clothing suitable for the North Pole. The Bean employee is now the designer who may refer to design tables to make a recommendation or may simply say "our clothing is unsuitable".

Until the needs or expectations are stated, implied or obligated they remain hidden. It is the job of the person making the design decisions to elicit these needs and expectations from the client (and wider interested parties perhaps) so they gradually become requirements that can be discussed, value engineered and agreed upon as the design passes from the conceptual to detailed phases into verfication and validation through design change control to the realization of the product that fulfills the needs of the customer.

These days contractors and manufacturers are included in the design process so they can provide their inputs. Many customers and some designers realize they are not the experts in the services provided by contractors and manufacturers.

If the contractor or manufacturer is excluded from the design process they often provide value engineering as part of their proposal or as part of the contract negotiations. This is an example of the contractor or manufacturer's design service (responsibility for validation may be left with the customer or the customer's designer).

RFPs with specifications often are missing a requirement or two and this is where contractors and manufacturers have an opportunity to add value, through design, beyond simply pricing the fulfillment of the stated, implied and obligatory needs and expections.

Or the bidder may choose to ask a question for all bidders to receive information on the same missing requirement. Here the opportunity to win the job with a differentiated bid may be lost.

Let us not leave parts of our product undesigned by anyone.

John

 

[Mikelangelo]

Let us examine this


An engineer of an organization (ISO 9001:2008 terminology) is asked to design a fire suppression system for the protection of a computer room. The equipment and parts necessary for the assembly of the system already exist.
No new product is designed.

The engineer will have to make all the necessary calculations and draw the system.


Does this fall into the requirements of 7.3 ?

 

[somashekar]

Let us examine this


An engineer of an organization (ISO 9001:2008 terminology) is asked to design a fire suppression system for the protection of a computer room. The equipment and parts necessary for the assembly of the system already exist.
No new product is designed.

The engineer will have to make all the necessary calculations and draw the system.


Does this fall into the requirements of 7.3 ?

Yes it does ...