I have been assigned the job of creating the Quality Manual for my company. We are a service provider, so our product is our service. Which my background has been with companies that actually produce a product, so I did have to go through a learning curve accepting that my service is indeed the product. I hope that makes sense. I also have only been with them for 6 months, and am still learning their business. Currently there is a total of 6 employees to give you a relationship of size. The services that are provided all deal with safety which include training, creating procedural manuals and auditing to a regulatory standard. The company from its onset has always used procedures of some form to provide the services. So this move to a Quality Management System is really the next step for them.

I wanted to give some background information that may be helpful in responding to my question. Prior to learning about this forum I was not seeing the need for 7.3 in our manual. But after review of serveal posts I now believe that I cannot exclude it. Since the size of our company is small and when we need to create something for the client the project is assigned to one of us. Then your work is reviewed by the manager/supervisor (owner) and any corrections noted, then this process is repeated until it is in a form that is going to meet the requirements of the client.

If I write this out in the manual or a seperate procedure and create a form to capture what is happening would that suffice what 7.3 is requiring?

If I am totally on the wrong track don't hesitate to say so, I see the light at the end of the tunnel and unfortuantely it might be a train.

Thanks in advance :thanx:

Sharpedge, welcome to the Cove :bigwave: your explanation makes perfect sense.

You are quite right in your assumption that 7.3 can apply equally to a service as a product and that given the small number of employees, it is best to keep it simple. However you do need to address all 7 elements of clause 7.3.

I think the idea of using a 'smart form' is a good one for your situation. You can put the control mechanism in the manual or in a procedure or not have a documented procedure - it is not mandatory for this process but I usually create one.

The form would typically need to include:

the plan for the design - what you intend to do, when and by whom
the inputs - perhaps customer requirements for the project
the outputs - what you design e.g. a specification or training course
review - could be a meeting where you review the proposed output for suitability (may include the customer)
verification - method of determining that the output will satisfy requirements
validation - may only be possible when using the material e.g. a training course - perhaps use course feedback
changes - control of any changes made to the course and their impact on previous presentations of the material

Thanks

Great I was on the right track.

If my thought process was right, and you have confirmed, then yes I understand I will have address the seven elements under 7.3.

From my Quality experience, my approach has been to let the Quality Manual be my policies and then Quality Procedures describe how to meet those policies. I try to work from say what we do, do what we say, and document what we did.

In some examples of manuals I have reviewed I have seen several that seem to restate the elements. Something like, "The company name shall plan and control the design and development of the services to be provided."

I know this is a little off topic from my original question, but is this acceptable. I was a Quality Mgr. for a company that met Mil-I-45208 and it seemed we had to give a more detailed response to a requirement then restating it.

Thanks again

You can repeat the words of the standard in the QM if you wish but I personally think that is a complete waste of time and paper. If you want to do that, just a 1 liner which says "we the organisation will meet all requirements of this standard".

I prefer to put each clause into context for the organisation so that it helps the reader of the QM to understand what is important to them. So for example, you may state that clause 7.3 relates to the design of training courses and that there is a documented procedure (or not). If you choose not to have a documented procedure you may put a bit more in the manual by way of explanation.

Your method makes more sense to me too.

I had the same thoughts as well for a waste of time and paper.

Thank you very much again:applause:, I really needed that input, wow, I have been on target much more than I was giving myself credit.

I have been stating what we do and support that where needed with a procedure, but then seeing so many using this restatement method I was concerned that maybe my approach was off.

Thanks:thanks:

Since the size of our company is small and when we need to create something for the client the project is assigned to one of us. Then your work is reviewed by the manager/supervisor (owner) and any corrections noted, then this process is repeated until it is in a form that is going to meet the requirements of the client.

If I write this out in the manual or a seperate procedure and create a form to capture what is happening would that suffice what 7.3 is requiring?



Good background briefing on your issue - very helpful.

Your idea sounds fine, only I'd advise against making anything too complicated, particularly given a small company.

For a start, be sure you need any new form before you create one. If you decide you do, keep such a form as short and as flexible as you can - services are often much more tailored for individual customers are than product widgets. And you definitely do not want to get to a point where it almost takes longer to fill in the form than to do the work. Don't laugh - I've seen them, alas.

Look at what's already being created in the business - eg, do you give a proposal to the client (eg, to do training)? It can stand as the design or part thereof.

In most service firms, the inputs required will already have been specified (or should have been) in something like a customer proposal or tender, as well as the deliverable outputs - e.g. a specification or training course. Yes? (If not, = business risk)

If it's a generic kind of 'design' process, then I'd cover that as into the process flow/procedure, and maybe use some kind of form to capture, say, signoffs at key points in the procedure - these would then serve as the records of review of the plan/proposed solution during development, etc.

Iterative design is also common (keep tweaking until it works). DOn't try and capture every single iteration - just focus on the key ones.

Thank you for your input.

I am taking your suggestion and having my supervisor(owner) review the process from two angles. One from a standpoint where the client initiates a design because of what they require. Then from a position of where he see's an opportunity and decides to design a service based on this opportunity.

I will see how this turns out before putting anything more together. From what I have been involved in I think we do most of what is in 7.3. Some may be a difference on what it is called or how it is recorded.

I did get a chuckle too, been down that road before too.

Thanks again

You can repeat the words of the standard in the QM if you wish but I personally think that is a complete waste of time and paper. If you want to do that, just a 1 liner which says "we the organisation will meet all requirements of this standard".

I prefer to put each clause into context for the organisation so that it helps the reader of the QM to understand what is important to them. So for example, you may state that clause 7.3 relates to the design of training courses and that there is a documented procedure (or not). If you choose not to have a documented procedure you may put a bit more in the manual by way of explanation.


I recommend writing one procedure for each process defined in the QMS. That prevents jsut restating the standard, and forces people to write all the meaningful things about each process in a single, [hopefully logical] document.