Continual Improvement Requirements - No expected completion date listed - 8.5.1

[Bigfoot]

Hello Covers

During our last external audit a Non compliance was written against cl 8.5.1 with the finding of "More than 50% of Continual Improvement projects do not have the expected completion date listed" - - All of the CI projects checked during the audit have completion / or expected completion dates for the steps as the owner works through it. On further review I can't find where this is an actual requirement. I asked tha auditor for a specific reference and the response offered reference to 7.3 c, 4.1 d, e, & f, 5.4.2 which refers back to 4.1, ISO 9004 Annex "B", & Appedix "B" of Vocabulary (ISO 9000:2000 QMS - Fundamentals & vocabulary) - I have reviewed the areas suggested and find no requirement for the completion date of a project be identified. Do any of you have any ideas or thoughts on this?

Also was wondering is ISO 9000:2000 Quality Management Systems - Fundamentals & vocabulary an auditable document or like ISO 9004 is it a guidance document?

 

[Jen Kirley]

While not specifically a requirement, I am not sure but the auditor may have got the sense the projects were stalled, not active or not well enough defined to be called projects, which infers there is structure that one might expect to include a projected timetable in the planning stages.

 

[Bigfoot]

While not specifically a requirement, I am not sure but the auditor may have got the sense the projects were stalled, not active or not well enough defined to be called projects, which infers there is structure that one might expect to include a projected timetable in the planning stages.

Jennifer - Thanks for the feedback. In Q4 2005 we had 31 open CI projects - Q1 2006 there are 53 open & 13 closed CI projects. I would find it tough to believe it is stalled, but as with nearly everything there is always room to improve & project definition is likely one of those areas. However that isn't what he identified as the noncmpliance.

 

[pldey42]

You could contest the finding I suppose, because 8.5.1 has no mention of dates. Auditors should pick one clause to write a finding against, not a random selection of several in the hope that one will stick.

That said, if you _want_ to use the finding to mandate completion dates in your projects, you could look to 8.5.1 or 8.5.2 which both require action to be "appropriate" to the effects of n/cs or problems: timeliness is one aspect of "appropriate" because if a process problem is causing money to be wasted, who wants to waste it longer than necessary?

Section 2 of ISO 9001:2000 refers to ISO 9000:2000. You can't audit to ISO 9000 because it has no formal requirements; but its concepts and vocabulary do apply in an ISO 9001:2000 audit and make the audit process itself (something of) a consistently repeatable process (amongst auditors and across organisations) by removing the room for interpretation that would otherwise exist for words like "quality".

Hope this helps,
Patrick

 

[Jen Kirley]

Seems to me the next step is to ask the auditor exactly what was referred to in the nonconformance, and discuss the interpretation of the standard used to arrive at these conclusions.

 

[apestate]

There's the bit at the end of internal audit

... The management responsible for the area being audited shall ensure that actions are taken without undue delay to eliminate detected nonconformities and their causes ... (see 8.5.2)

 

[Bigfoot]

You could contest the finding I suppose, because 8.5.1 has no mention of dates. Auditors should pick one clause to write a finding against, not a random selection of several in the hope that one will stick. Even in the list of potential clauses & references there is no actual requirement for this. Dates are used to drive the timely completion of the project steps and keep it from getting bogged down.

That said, if you _want_ to use the finding to mandate completion dates in your projects, you could look to 8.5.1 or 8.5.2 which both require action to be "appropriate" to the effects of n/cs or problems: timeliness is one aspect of "appropriate" because if a process problem is causing money to be wasted, who wants to waste it longer than necessary?

Section 2 of ISO 9001:2000 refers to ISO 9000:2000. You can't audit to ISO 9000 because it has no formal requirements; but its concepts and vocabulary do apply in an ISO 9001:2000 audit and make the audit process itself (something of) a consistently repeatable process (amongst auditors and across organisations) by removing the room for interpretation that would otherwise exist for words like "quality". As I thought.

Hope this helps,
Patrick

Patrick - Thank you for your response. It does help. I made some added comments above. This was a New Lead Auditor to our site (mandated change by TS) and this was our TS Renewal Audit. IMHO this is not a non-compliance as it is clear that the project owners are using dates to drive completion of the project steps. The only issue stems from the abscence of the expected completion date for the entire project. Acquiessing (sp) to accept this is similar to painting a bulls eye on our chests and walking through a firing range - add the dates as requested and then miss one we'd be noncompliant for failing to meet our expected completion dates.

 

[Bigfoot]

Seems to me the next step is to ask the auditor exactly what was referred to in the nonconformance, and discuss the interpretation of the standard used to arrive at these conclusions.

I have and the response was the list of clauses that I put into the initial post, (7.3 c, 4.1 d, e, & f, 5.4.2 reference to 4.1 etc.). None of which list this as a requirement.

 

[pldey42]

Understood.

As a software engineering consultant (in my last career) I dealt with this as follows: rather than give a customer an end date for a complex system I had to build, without really knowing how deep the sh*t was, I'd define up front a planning phase and promise them a date at the end of that first phase. That way, everyone avoided open-ended commitments.

You might try that with the CI projects: give them a date (a reasonable one) by which they have to have a plan. Now, if that includes some pilot trials and plans past that are vague, ok: set a date nearer the time for completion of the next phase. (But I think you know that.)

As for the auditor: how about having a little chat with him about his prospects for returning to your site? (Decent contracts with registrars allow you to negotiate with them the "quality" of your auditor.)

Hope this helps,
Patrick

 

[Cari Spears]

As a software engineering consultant (in my last career) I dealt with this as follows: rather than give a customer an end date for a complex system I had to build, without really knowing how deep the sh*t was, I'd define up front a planning phase and promise them a date at the end of that first phase. That way, everyone avoided open-ended commitments.

You might try that with the CI projects: give them a date (a reasonable one) by which they have to have a plan. Now, if that includes some pilot trials and plans past that are vague, ok: set a date nearer the time for completion of the next phase.

Good example ... good suggestion.