How to Map Out a Process for a Successful Technical Communication Department

© Ugur Akinci
How do you run a technical communication department?
How do you make sure your team works on a documentation project as it’s supposed to and pulls the oars in the same direction effectively?
One way to do this is to draw (mentally or literally) a Process Map.
Here is one offered by Chris Brogan, one of my favorite “process gurus”, together with my annotation:

(1) Process Name

“Maps should all be named, so that everyone’s referring to the same process.”
Fair enough. Call it something appropriate like “Motocom X354-B User Guide” where B refers to the version.

(2) Goal

“Spell out the most important goal/goals of the process at the VERY TOP.”
Should include a clear definition of the DELIVERABLE with a DEADLINE.
For example: “Deliver a PDF guide, plus a single-sourced HTML help file, on October 23, 2011.”

(3) Success

“It’s great when you can spell out what success looks like. Use words and measurements (if you can).”
Be as specific as you can.
For example: “To receive a grade of at least 80% in the 2012 Motorola End User Satisfaction Annual Survey.”

(4) Requirements

“What does one need to accomplish this task? What previous knowledge? Tools? PEOPLE? Etc.
Be as specific as you can.
For example: “This project requires 2 full-time and one contract technical writers, Adobe Technical Communication Suite 2.5, total 450 labor hours, 4-color printing, and the services of localization company with at least B+ AAHTS rating.

(5) Background

““Write a paragraph or two explaining what makes this process important.”
Share the importance and significance of the project with your team members upfront and welcome their inquiry and feedback.
For example: “We are tasked [excuse a little techie lingo there! — Ugur] to write the user guide for Motocom’s 4th-generation advanced transponder X354 which is used to save miners in mine accidents and those stranded in avalanches, storms, and similar natural calamities. Thus this mission-critical product demands a  top-notch user guide that would be accurate yet very easy to read and understand, with plenty visuals and a highly accessible navigation structure. Future rescues in part will depend on our success to turn out the best documentation we can.”

(6) Story/Flow

“Before you bark out a set of instructions, tell the “story” of the process. Make sure people understand the flow. This helps people NOT cut corners and not interpret parts differently than intended, because in context (which the flow provides), they understand what’s what and how it relates to the rest.”

(7) Actions

“This is the checklisty part. Make it so. Make it simple, repeatable. Make it on a different physical page to the backstory. They have to read and learn all the above stuff. They have to FOLLOW the actions list.”
For example: ” a) Write your section. b) Incorporate graphics. c) Submit to CMS. d) Ask for Peer Review and do the edits. e) Ask for SME review and do the edits. f) Push it to the our Localization Partner. g) Do post-mortem analysis and submit report orally at the Final Evaluation Meeting.”

(8) Measurements

“Show how to measure success. Whatever it is, show that there’s a success checkoff.”
For example: “The average Customer Satisfaction score for all our past documents was 79%. “Motocom X354-B User Guide” pulled in a rating of 93.4%. Congratulations to the whole team!  Well done!”
(Public domain photo courtesy of Wikipedia Commons)