In starting LP&G Cyber Communications, I set out to get people to think about documentation for their IT projects from the beginning, instead of waiting until their projects are nearly done. But why? Don’t projects change? Why document what happens at the beginning of a project when documents might not be due until the end?
Reason 1: Memory is faulty, and you’ll forget why you made decisions. Let’s say you’re working in an Agile shop, and you are doing a pretty good job of tracking your work in Jira. What aren’t you tracking? What isn’t being recorded or documented? Did someone write down the flow chart that you sketched on a whiteboard? Or the discussions that happened after your scrum? When you get six sprints down the line, will you be able to remember why certain decisions were made, or when they were made? A technical writer can help you define which items to record and then keep them recorded for you, so that you have your information ready to show or review in the future.
Reason 2: When you are developing a suite of Life Cycle Documentation, having your writer involved from the beginning produces better documents with less input needed from the team. Your technical writer does not want to be handed a mostly completed document to “techwrite.” When we are involved from the beginning, we learn to understand the project, and we can do most of the writing ourselves, leaving only the most highly technical aspects to engineers, programmers, and other developers. When we are included from the beginning, by the time we get to the end of the life cycle, we can usually write the end-user documentation with very little input from the team, and we will already know who the audience is for any training.
Reason 3: If you are creating a system that changes every few weeks, a technical writer will help keep up with the end-user documentation. These days, applications do have updates every few weeks, and having someone who is keeping up with the changes to the end-user documentation puts you into a much better light with your customers. I was once brought in on a project that had a full year of bi-weekly updates with no changes to the end-user documentation, so the documents needed a complete overhaul. Imagine how frustrated those users must have been prior to the document update!
Reason 4: Your documentation might be required without you knowing it. Are you under contract with a government entity? Do you think you’re working under an Agile methodology? Have you actually read your contract? I have been brought in to document two years worth of Agile work with Enterprise Lifecycle (ELC) Documentation, because the government contract explicitly stated that the ELC documents were required, and the government Program Manager requested them two years into the project. Just because your PM has approved a specific development methodology doesn’t mean that the PM fully understands what that means in terms of documentation, and you need to be ready for anything.
Does all of this mean you need a full-time writer on your projects? Absolutely not. But building in your documentation from the beginning saves you time and money in the long run, while keeping your projects well-documented in case of turnover, continuity of operations, or other unforeseen circumstance as well.