In my organization, technical writers are shared resources. We provide a little bit of baseline support and a whole lot of surge support to several different projects. It’s a dance of shifting priorities and erratic pace, but most days I wouldn’t trade the challenge for any other environment.
I do have one persistent complaint, though. My bosses (meaning the individual project managers) don’t understand me. It’s not the angst-ridden cliche. It’s that they don’t understand what I do. To varying degrees, they have an impaired vision of how a technical writer adds value to a project. One PM recently told me that in her previous companies, she always thought she wanted a technical writer, but she had no idea how to make the case for such a luxury.
With some encouragement from my direct supervisor and a whole lot of help from my closest colleague, I decided to create a marketing document to present all of our capabilities and offerings – targeted not at clients or end users, but at our internal customers. I want our PMs to have a thorough understanding of what we can offer. I also want to give them enough information to make judgments on things like LOE vs. ROI, so I included an assessment table for each offering. The table tells them who the audience is (and what immediate training need it solves), the additional resources involved (SME, developer), the software licenses and expertise, the output format, the overall difficulty rating, and how many hours it takes (minimal, moderate, major).
I published the document as a PDF with functional prototypes, and I borrowed heavily from a Madcap brief (by Mike Hamilton) to explain the hazards of CBT development without proper planning. I’ve put the outline below – I think most of you will need no explanation for what type of content fits under each heading:
I’d like to hear how you all have addressed this issue in your organizations, and also any ideas you have on how a three-person team armed with only Adobe TCS2 + SnagIT + good practices can expand what I’ve outlined here.