How to Manage Signal Versus Noise in Technical Documents

Table of Contents

Introduction

Signal versus noise is an interesting and important issue in technical communication.

Here is an uncomfortable fact of technical document management: as much as we’d like to base our decisions on hard evidence and numbers, we still make a number of judgment calls that rest on nothing more than a seat-of-the-pants “this feels okay,” this sounds just right to me” or “I’m not okay with this,” “this doesn’t quite feel right to me.”

Example

For example, imagine you asked your writers to submit those dreaded “time estimates” for the projects they are working on.

How can a writer justify the hours he or she says will take to finish that user guide? “Past experience,” is one of the answers frequently given.

Other typical answers: “I know I can do it by this date,” “I feel this is plenty time to get it done” etc.

“Signal” Versus “Noise” — Binary Outcome

Yet such estimates always set up a writing team for a binary outcome: either one misses the mark and “fails” or hits the mark and “succeeds.” But that success is a passive one. It more feels like “surviving” a multiple choice quiz where questions have only two answers: Fail, Not Fail.

(Here I’m not even going to address the related issue of padding the time estimates to make sure that “success” is but a certainty, which of course leads to wasting precious resources.)

When we “survive” such estimates or marketing specs, what do we do? Simple: nothing! Success in such cases is a license to not touch the process and ask no questions.

If on the other hand we “fail,” usually there are again no questions that lead to analysis but a simple promise and determination “to do better next time.” It’s all subjective.

Outcome is a Letdown

In both cases the outcome is a bit of a letdown because it tells us nothing about the objective process underlying the documentation project. Whether we succeed or fail, we never exactly know why.

Voice of the Process

We run hard after the “Voice of the Customer” (the document specs handed down to us) with little idea about the “Voice of the Process,” that is, the characteristics/components of the process with which documents are actually produced.

Signal or Noise?

I think at the heart of the issue is our failure to distinguish a “signal” from a statistical “noise” in our documentation efforts. This leads to false identifications when we think a signal is noise, and vice-versa. But first, let’s state our assumptions and define our terms:

Assumption 1

Not everything is explainable in life. Some things are inexplicable and remain so. We are not studying why that is the case. We are not trying to overcome that fact and find a solution to it by converting “things unknowable” into “things known.” We are just going to assume that this is so, as much a fact as the sun rising from the East every day.

Assumption 2

Every process will create some results that cannot be explained by the process itself. For example, every school will have dropouts, no matter how good the school is. Out of every thousand cars manufactured, some will break down within the first month, no matter how well the cars are manufactured. Some poems will never get published or read, no matter how beautiful they are.

Definition 1

We will call such inexplicable outcomes (as described in Assumption 2) “noise.”

Definition 2

Everything produced by a process and which is not a “noise,” we will call a “signal.”

If we could determine what range of variations are “acceptable” since they are the “noise” of the process, then I believe we could decide better “how we’re doing,” regardless of the “customer or marketing specs” under which we are laboring.

If on the other hand we detect a signal, that is, a variation that cannot be explained by the normal “random chatter/noise” of the system, then we would inquire what happened and when to generate such an out-of-range result.

The Question

Without such an understanding of when and why systems (including technical writing departments) sometimes step beyond the usual “noise” of daily life, and issue a “signal,” how can we expect to fix the process and improve the outcome?

This is too involved a topic to conclude here in a single blog post. I’ll just say that I’m in the process of writing an ebook and developing a workshop on this same issue.

A Quantitative Solution

There can be a quantitative solution to the problem of identifying “noise” vs. “signal”. The solution depends on the skill with which we use Shewhart Control Charts as a document management tool. That’s the key.

More on this subject later on. I welcome all your comments and suggestions.

An excellent book to read on the subject is Donald Wheeler‘s classic Understanding Variation: The Key to Managing Chaos. Highly recommended. It has changed the way I’m thinking about pretty much everything these days. It’s a true eye-opener.

Image credits Jesse Collins and Waldemar Brandt