Andy/Khaled
Sorry for the time it's taken to reply (Don't worry, I've issued myself a CAPR).
A most interesting discussion this (for me at any rate).
Khaled, your last response raises an interesting distinction vis a vis, the difference between measuring whether an activity has been performed or not (which is relatively easy), and whether or not it has been performed WELL (which is important for 9001:2000 continual improvement imperatives). Your solution - identifying potential non-conformities in the planning phase and working to avoid them during realisation - is innovative. My company is working to implement exactly that sort of practice, but more to satisfy the 'preventive action' requirement than the monitoring one. Now that I think about it, I suppose such provisions can be applied to WHAT is monitored. As to the HOW, we leave that to the experts - the people who use the system (In our new as-yet-to-be-implemented QMS, there is a requirement to 'establish criteria for assessment' in the planning phase of a project). I am hoping (!) that so long as this assessment criteria is documented, it will satisfy third parties (sound of beads of sweat forming on furrowed brow...).
(Interestingly enough, it occurs to me that the number of 'unexpected' non-conformances that crop up during a project can be tallied up as a method of monitoring the effectiveness of the planning process!!)
Andy, in response to your request for examples of processes...
My company is in the design business. A brief is established, scope and specifications determined from the client, and off we go. The actual 'realisation' of our 'product' involves a lot of to-ing and fro-ing back to the client for verification purposes. Most non-conformances arise out of co-ordination and communication errors (ie. "You showed the client design x? But design y is the current one!" That kind of thing). With vast quantities of designs coming in and going out, it is difficult to keep up without imposing cumbsersome checklists, release forms and the like, which actually tend to make things worse as they take up lots of peoples time (our 'new' QMS will attempt to soften the blow somewhat by simplifying the way the documentation system is set up, and by reinfocing the need to ensure the currency of customer requirements during the lifecycle of the project).
'Product(ie. service)realisation' is for us an ongoing, iterative, concern, rather than a matter of working to requirements with final product release as a defined endpoint. We have a constant stream of little 'releases' rather than one big one at the end of a project. Traditional approaches to monitoring (so far as I have seen)tend to focus on the latter rather than the former situations. I am relatively new to this field, so I'm learning all the time. Any insights will be readily gobbled up.
Thank you both for an intersting thread.
------------------
JasE