Identify

What is today's biggest question?  Are you who you say you are?  We all want accurate identification.  In Technical Writing accurate identification is about How, Who, What, When, Where, Why.

To deliver the right product at the right price, we have to ask a lot of questions.  But before we do, let's make sure we are using the same terminology.

What is a technical communication product? Anything that conveys the right message to the right person at the right time to get the right result.

We won't know the right message, the right person, the right time or the right result until we have asked the right questions. The questions are the start point of the Identify procedure.

As our company or our customer sells products, we will call the technical communication product, documentation.  We won't know what the documentation is until we finish the second last step in the Identify procedure.  

The documentation could be a video or an audio recording, a promotional give away, a wall chart or an electronic or paper document.  And it could be many of any of these things or any combination of these things.  Once we identify what the documentation is, we can call it by that name.

Our company or our customer sells a physical item, an idea, a service or a pattern of behaviour.  So our first step is to start identifying our company's or our customer's product.

What is the product?

What stage of development is the product in?

Who owns the product now and later?

Who knows and understands everything about the product?

Where does the product fit into our company's or our customer's business activities?

Is this product part of any other initiatives?

Who will maintain the product?  Why?

Who will support the product?  Why?

What will the product be used for?  Why?

When will the product be used?

How will the product be used?

Who will use the product?

What knowledge does the end customer have about the product?  Why?

What knowledge does the end customer need?  Why?

What skills does the end customer need?  Why?

Who has what assumptions about what the documentation will look like and what it will achieve?  Why?

 Are you getting a feel for what we need to successfully identify the right technical communication documentation?

Sometimes we are dealing with straightforward documentation.  At other times it might be a suite of documentation for a huge project.  So the Identify procedure also looks at what media the documentation will be on, the delivery format, the advantages and disadvantages of this approach over that approach and so on.  This is when we finally choose the technical communication product.

And guess what?  Sometimes is it not what the our company or our customer is expecting.

Example: In case of combat, press Help?

One of my clients asked me to spend a year writing help text for a piece of live combat equipment.  As I had been a soldier, I knew no-one in combat is ever going to press help!  So I asked the client where I could read the requirement.  

The client said it was not in the specification but in "correspondence".  So I asked to see the correspondence.  The client could not find it after a quick search, so gave me permission to search for it, including in the archives.  

At the end of two weeks I confidently stated there was no written requirement on the project.  I suggested we sent an email to the prime contractor saying we were ready to upload their help files and could they let us know when they would be delivered.  

The was no answer and no help text was delivered over the remainder of the project.  The client saved themselves a pocketful of money for writing documentation nobody had requested.

Two other things to do

There are two other steps to do in parallel with the Identify procedure.  We need to prepare a first draft of the probable timeline for the work and make a first estimate of the degree of difficulty of the work.  

If we know the expected due date, it is easy.  If we don't know the expected due date, that is easy too -- nothing to do!

When we know the expected date, we can use our first estimate of the degree of difficulty to see if the work is likely to be finished by the expected date.

Where to next?

Does your Identify procedure bring you to this point?

It not, you might like to look at an overview of the technical documentation product life cycle or some training courses,