In developing our new Technical author basic/induction training course modules, one thing that struck us was it is easy to talk about a technical writing process that is often not followed in reality.
For example, most books on technical writing describe how the writing project begins with a planning stage, an activity where the project is carefully mapped out in detail. The reality is often quite different, and planning is often considered far less than a trainee Technical Author might imagine.
Many Technical Authors believe they already know their audience and the appropriate purpose of the document, so in a project with tight timescales, the planning stage can end up being minimised. The reality is that writing projects are often a recursive and iterative process. For example, the purpose of a document might revisited at the review stage. This decision may not be right, but it’s one that often happens.
Today, Technical Authors can be expected to describe a product in permanent beta, developed in using Agile methodologies,(EDIT) or using a single-sourcing tool. Times have changed, and the way Technical Authors carry out their work, to an extent, has done as well.
We’ve decided it’s wrong to pretend certain things don’t exist, and mention them in the course. Hopefully, it will help new Technical Authors identify where there are potential failings in a project and be able to make a justifiable case for certain activities.
Do you think this is the correct choice to make?