QA and adherence to procedures

[FreddyNurk]

After a recent unexpected changing of employers in recent months, I've found myself faced with somewhat of an interesting situation. My main intention in raising the issues below is more or less to encourage discussion of such things, as I'm sure its not just my workplace that has these issues.

We have a QA policy. Its not been updated or adhered to for any longer than the first year of its inception, which is about 3 years ago. The policy is vague, and appears to be more about meeting QA certification than anything else.

However, whenever points are raised about people accidentally deleting files (we have an open filesharing system, anyone can change anything) or not being able to find out who changed which file, or effetively who did what, then the old 'If people followed QA then this wouldn't happen' mantra comes out. I've pointed out that there are easier ways to manage such things, as well as reduce the incidence of human error, but the same mantra is chanted over and over again.

My point is this, in general safety issues, training and procedures are a last resort for ensuring a safe workplace. Have I missed a fundamental concept here, or should we not also try and improve our work through the use of such utilies that prevent such issues from occurring? Clearly this will not work in every case, but I fail to see the difference between the principles used for safety and QA. Its still the same people involved, only the risk of harm has changed.

Your comments on such matters would be appreciated.

 

[MikeHalloran]

In a _real_ company, an accidentally deleted file could be recovered from last night's backup, or the SysAdmin could just go to or login to the server and undelete it.
{
R_i_g_h_t.
"We don't need no stinking backups."
"SysAdmin? He had a hissy fit about 'discipline' or something silly like that and quit. We didn't replace him; who needs the hassle?"
}
I can hear it now.

There's still a risk of harm, but it's economic harm, and the risk is perceived as modest ... until the catastrophe comes. Then, things will change ... for a while.

If you can't get THE BOSS to wear safety glasses in the shop, or observe any other rules, then no one else will observe any rules, either.

You can write memos until your fingers bleed and buy programs and systems until you run out of money, but nothing changes until The Big Guy takes it all seriously.

You probably have the QA policy in place at the request of one big customer, who is now suffering under the delusion that you actually have a QA _program_ in place, with a fairly formal tree of procedures and job descriptions right on down to the sweeper. If you haven't already lost that customer, you will, after the next audit.


;---

On a separate note, I have a misguided sense of loyalty, and/or I'm a real slow learner. I have, uh, unexpectedly changed emloyers, more than not. HR weenies will raise their eyebrows when they find out that's happened once. More than that, and they start talking about having more people to interview and escorting you to the door.

Keep looking, and don't turn down a mediocre job.







Mike Halloran
Pembroke Pines, FL, USA

 

[fcsuper]

Suggestion: Point out their are less expensive methods to preventing issues than a broad procedure and incomplete training.

Matt
CAD Engineer/ECN Analyst
Silicon Valley, CA
sw.fcsuper.com
Co-moderator of Solidworks Yahoo! Group

 

[FreddyNurk]

fcsuper, a valid point indeed, although I believe that part of the problem here is that there is no apparent means of discovering just how much the 'writing procedures, auditing procedures, disciplining the ones who deviate from the procedures' method costs. It appears to be a self perpetuating system, in that no one follows the half-arsed policy as it doesn't do anything, and then because no one has ever followed it, its supporters are always seeking that impossible to achieve target of full compliance. As well, no one can argue that it doesn't work, as no one has stuck to the policy to prove its failure.

I suppose I shouldn't care too much about it, rather concentrating on eventually working somewhere better, but it doesn't seem to be in my nature to just accept things like this. I suppose I should accept the level of inefficiency that is inherent, but theres a little voice in the back of my mind that tells me who the target will be if I perform to the standard possible with all the misguided procedures.

MikeHalloran, I suspect you're not that far off the mark in terms of why QA was implemented. Even though we're a consultancy, I'd reckon someone, somewhere will start getting excited about Six Sigma soon.

 

[kchayfie]

As I understand it, QA procedures are only about writing down what you are going to do and then doing it. So your procedure could say "the engineer is responsible for guessing the thickness of the wall. the chief engineer will take the engineer's guess and double it" and it would be really easy to comply with the QA policy. However, meeting codes and regulations and coming up with an appropriate design for the wall so that it doesn't fall down and so that you will get repeat business won't be as easy.

Document management shouldn't really form part of the QA policy. If its being mis-handled, it should have a company policy all of its own, at least until effective file management is so ingrained in the company culture that it doesn't need to be written down.

 

[SomptingGuy]

Some random QA comments from my experiences...

My department is about a dozen years down the road from the point where we made up loads of procedures and then didn't follow them. They all involved loads of forms and boxes to tick/sign - a real barrier to productive work. These days our QA systems have evolved to the point where they actually add value to our business. The biggest benefit to us is that things are traceable. If we find a bug in software we can look back to see exactly when it appeared and probably work out why. Without evolution, QA doesn't work. Our auditors seem to agree with our methods too.

On the issue of losing files: we use an industrial-strength CM tool so that all our files are versioned, backed-up and traceable (that word again). It's saved our bacon many times.

 

[gerhardl]

FreddyNurk: you have a problem! Obviously your MD does not have any idea of what a modern QA system should do (see description from SomptingGuy).

If you can manage to convince him that the issue sticks here, you have a 50/50 chance of a bright future in the company, the other half chance to become extremly unpopular and stamped as a troublemaker.

If your company description is correct, the MD would not, in all probability, appreciate your suggestions, increasing your downside.

 

[Tomfh]

They all involved loads of forms and boxes to tick/sign - a real barrier to productive work.

That's what ours is like. Complying with QA involves ticking all the boxes.

 

[SomptingGuy]

Note the past tense: "involveD". When we started out our (software) program files had a contents list. The contents list always had the list itself as the first entry. The sport of the day was to pick holes in other people's program files.

These days it's all electronic and linked. I can find what features will be going into a future release. From that list I can hop directly to the working area for any particular feature to check its status. If I see the words "reviewed" "merged" and "approved" I know it's finished.

 

[FreddyNurk]

I'd be curious to know what sort of CM systems are out there, though granted, this has nothing to do with QA, it just appears that my coworkers are operating under the delusion that QA fixes all.

I'd had experience with using CVS for revision management, worked extremely well for some parts of the company, as the software / research arm was already using it. Others didn't see the point.

Most notable in the responses, though, is the fact that a properly designed and implemented QA system delivers more than adherence to a compliance request from a client. Its also worth noting that semi-automated systems appear to make life easier, instead of having to wade through a myriad of boxes to tick and forms to fill.

Whether the status quo changes or not is yet to be seen.

Its now my firm opinion that engineering companies should probably take the same approach that they do (should) with projects, that is, establish the requirements well before implementation. Our QA seems to be developed by the office secretary, with very little understanding of engineering process.

 

[SomptingGuy]

CM tools:

One good resource is

http://www.cmcrossroads.com

We use ClearCase. It's fairly expensive, but fits our needs perfectly. I can grab any version of any file that went into any software build over the last 12 years. I like the "if in doubt, check it in" mentality that it fosters.

Can't really comment on other tools though, except that I found RCS and SCCS very painful to use in comparison.

 

[GregLamberson]

As MikeHalloran alluded to, whether it's the corner McDonalds or an engineering firm, it all comes down to management (or a manager).

If management is not commited to quality and does not define their expectations of excellence and enforce them, you can bang your head on the wall all day long and at the end of it, all you'll have is a head ache.

Greg Lamberson, BS, MBA
Consultant - Upstream Energy
Website:

http://www.oil-gas-consulting.com