Validation (Was Artfully is dragging)

[rjl -at- BOSTECH -dot- COM]

Jane Bergen asked:

>Does anyone else have some ideas how
>to solve the problem of getting someone to proofread drafts?

Most of us have run into this problem at one time or another, and it's
frustrating. It's bad enough when the SME's plead "busy," it's even worse
when you get the occasional one or two that intentionally make it a game:
"I'm not gonna review your document, and you can't catch me." I've got one
of those here.

I've proposed to my manager a new system for checking documents, linked to
our ISO 9000 certification. It's being seen as a radical idea (little do they
know...), and it has its pros and cons. The -biggest- con is that its
going to require extra staffing.

It's called "Validation." (Some of you already know what follows.)

One reason why the SME's are reluctant to review documentation is because
they don't see it as part of their jobs. They became programmers in order
to write code, not to review tech manuals. Okay, so the answer is to hire
people and tell them "Your job is to review tech manuals and correct the
technical data as needed." Nothing else. No other writing, no programming,
no janitorial tasks. Just check manuals for technical accuracy. These
people are called "Validators."

And this is -not- an editor's job, you keep a separate editor for all the
traditional editorial functions. Validators are not looking for style and
format, spelling, and grammar. They're checking for technical errors only.

The validator will do a line-by-line check of the all new or changed portions
in the manuscript, checking -everything- as needed. The validator will, from
time to time, have to chase down the SME's to get clarification on material,
but in these cases the validators have narrowed the scope of the questions
down from the entire manuscript to a series of specific questions in the
manuscript. This should be a relief to the SME's.

So, how do you get an engineer to sign up for a job as a Validator? You
don't. Crazy as it sounds, the ideal Validator is a technical communicator,
not an engineer. A tech communicator is able to look at the data with the
right amount of distance, is able to view the document in the larger scope
of all other documentation, and....well, I'm likely preaching the choir
when I address the idea to this group.

Document review flow is something like this:

1) Writer prepares manuscript.
2) Writer submits manuscript to validator.
3) Validator reviews manuscript.
4) Validator writes up comments as needed, returns manuscript to writer.
5) Writer incorporates validation comments as needed.
6) Writer submits manuscript to edit.

Having the edit come last allows the editor to check the style and format
of the validation changes.

What's the impact on staffing? I think it's gonna work out to be something
like one validator for every ten writers, I'd be interested in feedback
or estimates from those of you out there that are also working with the
validation/verification concept. (Yes, I realize that makes it a little
tough for someone like Jane, who is the only writer. Perhaps in cases like
this, the validation function could be turned over to someone in the QA
department? Or use a contractor?)

(BTW, my first tech writing job actually wasn't writing, I was a validator.
I did it for five years. I know the concept works, from experience.)

Opinions?

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