TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I attempted to send this yesterday, but it never seemed to show up. If this
turns into a duplicate posting, I apologize.
Marc Santacroce asked:
>What is the difference between verification and validation?
Essentially, the type of clothing worn by the person doing the task. (Well,
not -exactly-, but darn close.) I was involved in both for several years, in
fact at one point my job title was actually "Aircraft Manuals Validation
Engineer." (which was just another fancy title meaning that I was a tech
writer)
Validation and Verification are terms used in defense & government contract
work, and refer to specific steps in the tech manual QA process. The details
are spelled out in a couple of documents, I'm thinking the USAF definitions
are in T.O 00-25-1. (It's been a while since I've referenced the document,
I'm not positive about the number. It is a "00" series T.O., that's for
certain.)
Both words refer to the actual process of checking tech manuals for technical
accuracy. There are three degrees of Val/Ver:
1) Comparison (AKA "Desktop") You compare the tech manual to the engineering
documents & blueprints, without going near hardware. ("The print shows these
attachment lines and those mounting bolts, just as the tech manual says. The
procedure should work as written.")
2) Simulation. You walk out to the airplane, look at the engine, and compare
the manuscript to the hardware, without actually performing the procedure.
("Yes, I can see that if you disconnect these lines and remove those bolts, the
engine will come out just as the tech manual says. It should work as written.")
3) Demonstration. You walk out to the airplane, and physically remove the jet
engine following the tech manual steps exactly as written. (CLUNK. "Ahh,
somebody help me put this engine back in the airplane, please.")
You only need do one method in order to validate or verify, but you must record
whether the method was comparison, simulation, or demonstration. In each case,
of course, any required changes are recorded for inclusion into the manuscript.
Now for the difference. When Marc Santacroce, TRW employee, is doing these
things to check the manual, it is "Validation." When the exact same thing is
done by a military or government representatives, it is "Verification." (Hence
the "clothing" remark. If you're wearing civvies, you're validating, if
you're wearing a uniform, you're verifying.) Under normal circumstances,
tech manuals -must- be validated by the contractor prior to delivery. Most
verification is done by the military -after- the manuals are delivered. Your
validation comments/changes -must- be incorporated into the manual prior
to deliver, most verification changes will go into a future change.
So, to clarify what I said a moment ago, the procedures will probably be
performed twice: Your validation, their verification.
Although the DOD promotes the idea of "simultaneous validation/verification"
(i.e., you & Tech Sgt. Smith work side-by-side and agree on comments and
changes), in practice they very rarely get around to doing it this way.
Unfortunately, this lack of planning causes extra work, and increases costs
at the taxpayer's expense. (Oops, started grinding an axe there for a
minute...)
In terms of manpower estimates, it's a big deal. I'd guess that for every
ten tech writers, you need one additional full-time person simply to do
validations. (That was the approximate ratio when I worked at Lockheed,
back in the 80's.)
And for those of you who "never have and never will" done writing for the
defense industry or government, I'd still suggest that you re-read the above
paragraphs. I firmly believe that ISO 9000 will, within a few years, drive
private industry into requirements very much like what I have just described.
(Ooops, there goes that grinder again....)
I hope this helped, and if you need additional details just let me know.
Rick Lippincott
I can send, but not receive at work. Address personal comments to:
rjlippincott -at- delphi -dot- com