Maintenance Releases
As long as I have been writing technical documentation, the most common question interviewers ask me is how do I go about getting information for my documentation deliverables.
For me, there really isn’t one answer or method for obtaining information. Much of my information gathering is determined by the availability of the actual product (or legacy products), the organization’s level of process maturity, the availability of reviewers, the corporate culture, and my own initiative as a researcher, questioner, and organizer.
In the list below, I describe methods I have often used to gather information for maintenance releases:
- Directly using the existing legacy product, if it is available to me.
- Reviewing the current user, administration, or installation documentation.
- Reviewing all functional requirements and technical specifications, with a focus on understanding changed or new functionality.
- Identifying where in the current documentation set I must incorporate the changed or additional functionality (for example, is it a global hit or an isolated hit?)
- Speaking with the customer directly about the completeness, accuracy, and usability of the current documentation. In absence of a direct contact with the customer, asking internal customer representatives about the quality of the current documentation (Product Management, QA, Technical Support, and Sales Engineers).
- Reviewing any bugs logged against the existing product and documentation.
- Interviewing subject matter experts (from both technical and non technical disciplines).
- Incorporating updates for the new funcionality and sending out new drafts incrementally, and in small sections, to the key reviewers, *before* a formal review process even starts. (I use the early drafts as an interviewing tool to flag any anticiptaed issues with the key reviewers and to clarify up-front the best way to work together.)
- Incorporating edits, making requested changes, and adding further content, incrementally.
- Testing my own drafts against the product. Filling out details as I take second, and even third passes, at the sequence of steps.
- Organizing myself, or with the coordination of Program Management (if Program Management exists), at least one formal review of the document.
- Incorporating any required changes, based on the formal review, and recirculating the final draft, in an e-mail, with voting buttons to accept, or accept with changes, the final document.
- Ensuring at a minimum that users have a way to contact the Documentation team with any feedback.
- Developing and distributing a more detailed user questionnairre about the documentation’s completeness, accuracy, and usability.
In general, it’s really important as a technical communicator to remain as aware as possible, about your company’s strategic vision, product development status, and industry best practices. Active participation in a professional society (like the Society for Technical Communication), attending any internal informational opportunities, such as webinars and brown bag luncheons, regulary using and reading about new technology, and frequently checking in with cross-disciplinary colleagues is the best way to seamlessly gather product information.
Are these information-gathering techniques similar to the way you track down information for maintenance releases, in your organization? How is tracking down information different (or the same), when writing about a new product? What are your biggest obstacles in tracking down information?
Photo Credit, Parksy1964