Re: Quality/validation

[rjl -at- BOSTECH -dot- COM]

This is a response to the anonymous posting concerning QA/validation
problems.

I think that three parts of your problem are

* Busy developers who don't want to review the manuals
* QA's confusion on the actual tasks involved
* Personality problems

Busy developers is a problem that's tough to overcome. Some of these people
just don't -want- to do it. They see their jobs as developers, not reviewers.
(I don't have any direct observations to prove this, but I'm sure when they
were preparing for their careers they didn't sit in the dorm at night and
say "Oh boy, I can't -wait- to review docs....") Really, the only solution is
to move the brunt of the QA/validation away from the developers. Sure, include
them in the loop. Sure, give them copies, and sure, pay attention to what
comments they make. But the developers should be your -second- line of
defense. When they fail to come through, you'll shrug it off. Who needs em?
You've already gotten usable comments from the QA/Validation folks. (I
realize this is a radical idea, but it actually works very, very well.)

But that leads us to the second problem. You're not -getting- usable comments
from the QA group.  The QA confusion shows up in the fact that you're
getting typo correction and word-choice selections. The QA folks should
be looking for technical errors, not playing "comma cop." My guess is that
someone was given the task of reviewing the documents, but not clearly
told -what- to look for. When that happens, reviewers (including SMEs)
often default to a spelling/grammar check. Not too difficult for them to
do, and the reviewer can check off the little block that says "Done."
The answer? The QA folks should have the doc review tasks clearly defined,
as a job assignment. How clear a definition? In an extreme case, you should
be able to go to the QA person's manager and say "This isn't a usable review,
and it doesn't meet the requirements set down by our rules and agreements."
(This becomes easier if you've built the QA/Validation process into ISO 9000
plans....but that's another process.) The QA people should know that if they
are not looking for technical problems, they are not doing their jobs.

The third problem is personalities. That's tougher. The fact that you've got
to go back with "written proof" suggests that it's an attitude. I once worked
with a validator who essentially behaved as if the fact that there was one
validator for every ten writers proved that he was ten times smarter than the
writers. (I just assumed the writers jobs must be ten times harder....) I
did that QA/Validation task for a few years, and I made my share of mistakes.
I wrote up some correction comments that were flat-out wrong. Normally,
the writers were able to come to me and with a quick explanation, show me
where I'd made a mistake. Sometimes, I'd ask to see the source data, but as
often as not it was in the context of "Help me learn this better, so that
I'll avoid this mistake next time." The QA folks might say "Well, we need the
documentation for the records." Only if they've built their own rule to
require it, and rules can be changed.

You've got the basis for a good system, but it still needs to have some of
the bugs ironed out. Once you've done that, though, you should find that
the confidence in the documentation quality will go up.

I hope this was of some help.

Rick Lippincott
Boston Technology
Wakefield, MA
rjl -at- bostech -dot- com