Management Deviations or Exceptions to the QMS

[The Specialist]

It would seem, Harry, that we agree on this issue.

 

[harry]

Yes, especially in the context of a QMS.

 

[samsung]

I agree with both Jane B. and The Specialist, under the given circumstances, it should be taken as a process change and should be dealt as per the change management procedure or protocol. As Jane said, flexibility or agility is a positive attribute of an organization and should therefore be a 'designed in' feature of the QMS provided the changes/ proposed changes add some value to the organization or to its customers.

 

[JustADude]

Thanks.

I will add some more scenarios which may need a deviation like the one mentioned for purchase, and which is the basis of my query.

To set the context, we are a software development company. Like many other software companies, in addition to ISO 9001, our QMS is also aligned with the CMMI framework from SEI. This brings in another consideration. CMMI brings with it the concept of Tailoring which means that we can tailor the organizational processes for the particular delivery team's processes to address their specific customer scenario. This may mean not just a changed process, but an entirely new process. This variant may not be absorbed into the organizational QMS till it has been piloted for some time. This is generally documented in the Quality Plan of the team. The organization will need to live with the associated risk till the pilot period for the process is over. Now would this need a deviation in ISO or can it be considered as part of process change management?

Some other cases for deviations:

1. Customer's acceptance criteria for a software product to be shipped is that all features mentioned in the requirements document have to be completed. They are planning to demo the product at a particular industry expo and the deadline had been set on that basis. The deadline is now over. Out of 10 features to be completed, only 8 have been addressed. The product is functional even without these two features (which of course would have made it a better product). The concerned development team wants to release the product to the customer since the deadline is over. They want the CEO to approve a deviation from the QMS for this delivery.

2. A team is following the new Agile software development methodology called SCRUM, which consists of one month sprints to deliver a product. There is an organizational objective that Rework effort should not be more than 10% of the actual effort. This is not relevant to the team because for them rework itself is a separate sprint. They want to set an objective which is more in line with the methodology they follow and want a deviation from management.

3. Timesheets are to be filled in the internal tool developed for the purpose by all staff mandatorily as per the organization's QMS. One of the delivery teams has a requirement from the customer that they need to fill their Timesheets in the customer supplied tool (for ease of billing for the customer). Filling two Timesheets is an unnecessary overhead and there is no bridge between the two systems. Since the team can pull out most of the information about their activities from the customer's tool, they want the top management to give them a deviation for not using the organizational tool.

4. This could be trivial, but as part of fire safety requirements, the QMS has banned inflammable stuff within the premises inluding match boxes. One of the delivery teams is planning an event within the organization premises which includes lighting candles. They want management to approve a deviation for this. They guarantee that this will be closely monitored.

These are interesting scenarios, but each is different. Item #1 is seems to be a case of the customer changing their requirements. If the customer is willing to accept the software with only 8 of 10 features working the customer should put that in writing. After that is done there should be no need for a change in your QMS, because you will be satisfying the customer's requiremtents. If the customer will not accept the software or won't put it in writing, you shouldn't ship it till all 10 functions are working.

Item #2 looks like a case of a poor procedure on your end. Management needs to decide if all teams have to follow the same rules or not. If it is OK for one team to have a different set of rules, that should be stated in your QMS documentation and all the rules explained. If management does NOT want on team to do it differently, they should not allow it by signing a deviation or exception.

Item #3 looks like it started as a problem in quoting the work. You have a system where your overhead is already figured with your people doing the time sheets with the standard method. When a customer asks for time sheets done in their system, that could have been quoted as a separate cost and if approved, you would be getting paid to do it in both systems. As of now, there would be no real harm in your management allowing an exception to YOUR system and letting the team do the time sheets in the customer's method since the actual ISO standard does not specify how that is done. You would only me making an exception to HOW you satisfy ISO and not an exception to ISO itself.

Item #4 is much like #3. ISO does not say "no matches in the workplace". You and your management decided to make that part of your internal safety rules in order to satisfy the ISO section 6.3.a. Your management can make an exception to its own rules as long as it does not violate the requirements that ISO specifically states.

 

[JaneB]

Thanks Deepu, more examples is helpful.

I'm familiar with CMMI framework, software development and iterative development (eg, example given).

What I am wondering is if your existing QMS is too prescriptive (as Harry picked up) and /or too heavily based on a strict 'manufacturing physical product' model, and hence some of the problems you are having?

A decent QMS must enable the business to do its business, not strap it into a straitjacket. Your business ain't the same as a manufacturer.
When you mention 'tailoring' and creating an entirely new process (or perhaps a once-off process), your system must and should cater for that. And yes, it's entirely reasonable to have that in some kind of 'R&D' status for a while. Covering it in the Quality Plan is fine. Process change? Maybe, if it's changing an existing process.
Whichever, I'd be looking to specify the minimum inputs and outputs you must have though, in order to keep some kind of control over such, and ensure it doesn't become a backdoor kind of 'we don't have to follow our system'.

#1: IF your customer modifies their acceptance criteria, you can 'release' it. IF they don't, then you have not met their criteria. You might give them a demo version only (eg, for an expo), but you cannot release as 'final' because you have not yet fulfilled their stipulated requirements.

#2: I agree with the team. They aren't reworking, but iteratively developing. If your QMS is too rigid as to permit that, or requires a 'deviation/exemption', so be it. Though I'd want to make it more flexible, myself.

#3. Let common sense apply! Again, sounds as though your QMS is too rigid here. What is the result you're trying to achieve? If you can get the data on hours from customer's system, and your management is OK with it, fine. Otherwise, you're duplicate data entering, which seems pointless.

#4. Who is 'the QMS' which has banned inflammable stuff? Again, surely common sense should apply!! Regardless, whether such stuff is banned/not banned has nothing to do with any mandatory requirement of ISO 9001. Sounds almost as though someone is using 'ISO 9001' as a big stick rather than an intelligent and useful management system.

 

[JaneB]

I disagree that the term 'deviation' is as strong as you say.

I offered some extra information in case of the possibility of a language issue. For many people in the forum, English is not their first language and confusion may arise.

Re. 'deviation' I did not say it had that meaning (denotation) but deliberately used the term connotation.

If unfamiliar with the difference, an example may help clarify. “Determined” and “pig-headed” both denote stubbornness; but the first connotes a wise adherence to purpose and the second connotes foolish rigidity.

And as one delightful gentleman said:

I often write “insufficiently complex” at the bottom of student papers instead of “simple-minded.” Although they denote essentially the same quality, the connotations of the first are less insulting.

 

[The Specialist]

I offered some extra information in case of the possibility of a language issue. For many people in the forum, English is not their first language and confusion may arise.

Re. 'deviation' I did not say it had that meaning (denotation) but deliberately used the term connotation.

If unfamiliar with the difference, an example may help clarify. “Determined” and “pig-headed” both denote stubbornness; but the first connotes a wise adherence to purpose and the second connotes foolish rigidity.

And as one delightful gentleman said:

JaneB.

Please do not be offended!

My intention was mearely to point out that the term 'deviation' is an acceptable and indeed industry-recognised term and that the OP should not be affraid to use it. This is just my opinion, of course, and does not undermine your assertion.

Incidentally, the term "pig-headed" is a colloquialism (of old) and deliberately offensive term. As such, it is a rather strong example to use by comparison!!

 

[JaneB]

the term 'deviation' is an acceptable and indeed industry-recognised term

What industry or industries are you referencing? Or is this rather akin to saying 'everyone knows that'...

PS, Appreciate the concern, but one can hold a different opinion without being offended. The Cove'd be a sad place (and probably much emptier) if not