A recent work request reminded me of production life cycles. I got an email regarding a user guide for an application that I had written earlier this year. She said she was looking for something similar. She asked me how long it would take. I told her that I would need to look at the application, but I also said there were a number of things to consider, including how much access I could have to the application so I could test and document it, who would be available to answer any questions I had, who would be able to test and review the document, the document format, and so on. (On hindsight, I also realized that I’d forgotten to ask a very important question: who is the audience?)
The conversation reminded me about the importance of the document development life cycle. In an earlier article, I talked about a number of issues that frustrate people who understand technical communication and documentation. This is another frustration that is poorly understood and widely ignored.
I’ve had the privilege of having worked in both software development and professional document development environments. Many people fail to understand that there is no difference in the production process between the two environments. To put it another way, the development life cycle between the two is no different!!! The software development life cycle (SDLC) is widely known and an industry-standard term. But if you’re not a technical writer or communicator, when was the last time you heard any mention of a document development life cycle? For that matter, are you even aware that such a thing exists?
It seems to me that most people aren’t. How many of you have been frustrated when you’re given a documentation project, whether it’s an application, a process, or a product, and been told that it needs to be finished in a couple of days (or even a couple of hours)? This is completely disrespectful to technical writers, and it upsets me to no end.
Like software, producing good documentation follows a life cycle. Here’s a sampling of what takes place when developing a document. Document requirements must be defined: what is being documented, what is the scope, and so on. And let’s also not forget what may very well be the most important requirement: who is the target audience? The document must be designed and written. This involves organization, layout, and design. Writing it is no small task; I’ve written before about how hard it is to interpret ideas that come from a subject matter expert (SME). Once a document draft is written, it needs to be reviewed (“tested”) by an SME for accuracy; are the ideas conveyed in the document correct? Adjustments to the document will likely need to be made, and it will need to go back to the technical writer for editing and updates. Document format needs to be considered; will it be deployed as a PDF document, or will it be stored and maintained in an online format, such as a Wiki, Sharepoint, or Confluence? Speaking of maintenance, bear in mind that if the application or process is changed, the document will likely need to be changed as well.
Documentation is a critical, yet overlooked and disrespected, profession in technology. A technical writer cannot be expected to produce a quality document in mere hours. As with all quality products, documentation also follows a life cycle. Whenever the document life cycle is properly followed, the result is a quality document, which, in turn, results in satisfied customers and a positive reputation for your organization.