Re: measuring productivity and QUALITY

["Peter Ring, PRC" <prc -at- ISA -dot- DKNET -dot- DK>]

A very interesting discussion!

About quality:
--------------

I have worked a lot on measuring quality of technical documentation.
The results so far are my book "The PQM system - How to write better
instruction manuals, and control their quality yourself!", the PC
programme PQM 2.3 which can assist you in measuring the quality of a
manual, my internal and external courses, - and a lot of manuals with
a good user response.

When I in the following refer to "manual" it includes all kind of
instructional material on paper or on-line.

Basically there are two dimensions:

The first dimension is the phase of the manual "production":

1. Planning and writing phase. Is the manual goint to fulfil the
   goals set, incl. fulfilling the needs of its target group(s)?
   Measure: PQM points (see my book). After the measurement, any
   fundamental problems and little details will normally be solved.

2. Usability test phase. Does the users like it? Does it work? How
   many errors? Measure: Problems encountered during the test
   (number, course, and severity). After the measurement, the
   problems found will normally be solved.

3. The users' use of the manual. Does it temp them to use it? Does
   it fulfil their needs? Measure: Number of support/service
   calls. Problems identified should be solved, but most often
   it's only the small problems which is solved, fundamental
   problems like "written on a too high level" are rarely solved.

The second dimension has to do with the functionality of the manual:

The functionality can be divided in four groups:

- Paedagogical quality: Is the manual written for the "typical weak
  user" in its target group? Does it follow the more or less well
  known rules for how to write a good manual? Does it contain what
  it should contain?

- Technical quality: Is the information in the manual correct? Is
  any important info missing?

- Linguistic quality: Number per e.g. 100 pages of spelling errors,
  grammatical errors, terminology errors? Ambiguity - nice and clear
  language or complicated language? (Mechanically measured
  "readability" is a part of the paedagogical quality measurement).

- Graphical quality: Follows graphical line? Decent lay-out? Paper
  and printing quality (if printed)?

Each of these four points contains a number of weighted parameters.

The funny thing is, that to my experience it doesn't take much more
time to write a good manual than a bad one. Often even less if you
are used to write in a user friendly way and know what's important
here!

About productivity:
-------------------

First of all the quality should be OK. But if you are a documentation
manager, you know which people in your department are solving the
problems of producing a decent manual within a reasonable time, and
who are not. But it will be a sort of "felt average" over many
projects. For a single specific project it is very difficult: too
many factors like the quality of the information you base it on,
product changes during the documentation, availability of the technical
experts, just to mention a few.

I could go on for days but I'll stop here.

Greetings from Denmark

Peter Ring
PRC (Peter Ring Consultants)
- specialists in user friendly manuals and audits on manuals.
prc -at- isa -dot- dknet -dot- dk
- the "User Friendly Manuals" website with links, bibliography, list
  of prof. associations, and tips for technical writers:
  http://isa.dknet.dk/~prc/
- text cleaning software, e.g. for reading difficult e-mails:
  http://isa.dknet.dk/~prc/software/index.html