Conducting a tech documentation audit: The first 30 days onsite as a technical writer
A typical interview question I’ve gotten in the past is what do I do when I come in as a new technical writer that is the first one inside of an organization. Some of my technical writer roles in the past have been working directly on technical teams (and have been the first technical writer more than once), so I do have a process I’ve come up with over the years but had yet to write down. The key for a successful document audit is to couch everything in business terms especially if the technical writer position is to either start a new group or be a part of a technical team.
Here is a basic overview of my documentation audit process:
Get access to existing documentation
I like to read all of the existing technical documentation before speaking to anybody. At this phase, I want to look at the documentation based on my own experience tempered against any preliminary discussions about the current state of the organization’s technical documentation as discussed during the interview stage and any preliminary talks that have taken place. I usually keep a running list of observations of what I see in the documents at this stage.
Get access to existing systems (if feasible)
An optional step is to get access to existing systems to compare the existing documentation against orders for a document freshness test. However, I realize this isn’t always feasible or even necessary, but I’ve gotten a lot of insight doing this when the project involves reverse engineering requirements documents, software requirements specification, or functional specifications.
Discuss organizational priorities for technical documentation
I don’t admit to having all the answers about the direction of the documentation plan, so I always try to get the organization’s priorities for technical documentation early in my documentation audit. Technical documentation needs to align itself with the business early in the process.
Interview internal customers about the documentation
I’ve long been a believer of aligning technical documentation to the business, so I am a big proponent of talking to the internal customers for the documentation and getting a handle on their likes, dislikes, and requirements.
Interview stakeholders and managers about the documentation
After speaking with the internal customers about the documentation then it is time to talk with the manager and higher level stakeholders of the documentation.
Develop and present a list of findings
Based on my discussions with staff members, I write up my list of outcomes and introduce them to management and/or stakeholders either through a written report or a presentation.
Develop an action plan
Based on the discussions during the internal customers and stakeholders and the presentation of the list of finding then it is action plan time. My action plans typically include:
- Document priorities
- Proposed document overviews
- Create Project schedule/dates for document development
- Execute on the action plan
I like to align my action plan with the projects that the documentation supports and set 60 and 90-day goals for new technical documentation efforts especially if technical writing is a new addition to the organization.
What sort of upfront analysis do you do as a technical writer starting on a new contractor in a new full-time position?
Hey there! My name is Will Kelly. I’m a technical writer and content development manager living and working in the Washington, DC area. After spending years focusing on technical and SDLC documentation, much of my work now focuses on thought leadership content and marketing collateral. My articles have been published by DevOps Agenda, Mobile Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.
