Avoiding the mission impossible technical writing project
I’ve had the great fortune in my career to work on some very tough projects — in what I like to call documentation unfriendly environments — and won some and lost others but learned so much about technology and how to work independently as a technical writer.
Before I accepted my current position, I had the opportunity to speak to an organization which has what I quickly came to ascertain what could be a “Mission Impossible” documentation project where there would be more chances for things to go wrong than there was to go right.
After speaking to the recruiter who set up the meeting for me, I began to think how had I won the mission impossible projects versus being “the previous technical writer.” Keys to success include:
Strong technical team
A strong technical team — not to write the documents mind you — but like it or not the IT industry is peppered by a lot of smart people and a lot more people who think they are smarter than they are. If you have genuinely knowledgeable and capable people in the critical technical roles, then half your battle for extracting technical information is won in my experience. If the wrong people are in critical roles, the holes and gaps that sometimes happen in technical documentation can expose the shortcomings.
Proper technical writer/developer relationships
Relationship with the technical team where you as the technical writer isn’t an unnecessary drag on personnel or other resources. Technical writers who need their hand held or can’t work independently are only going to be set up to fail when it comes to a mission impossible project.
Product management and developer collaboration
Strong product management and technical team cooperation and communications. If Product Requirements Documents (PRDs) or stories are just being thrown over the transit without much dialog between product management and the senior members of the technical team, then the hijinks can ensue.
Access to test environments
Access to test systems and the bug tracking system because reverse engineering of technical documentation does often occur especially if the document efforts begin well into the development lifecycle.
Reality vs. vaporware can also come into play on such document projects. If for some reason, you are continually denied access to the system, don’t take it personally, but be on guard that the product may in whole or part not exist except for visions in an executive’s mind.
What are your keys to success on “mission impossible” documentation projects?
My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.
