Presented by Sharon Burton, and reviewed by Jay Martin
Plan your projects, define the way your success is measured, and heed the other friendly advice from Sharon Burton, an STC Associate Fellow and consultant.
Promote Tech Comm
Burton began with some advice she tells her clients: It is easier to sell to prior buyers. Returning customers are a better source of revenue. Documentation adds value, post-sale, when it helps customers use the product. Documentation helps branding.
Some companies need to be reminded that people read documentation, Burton said. Companies are not thinking of documentation as a place their customers are. Companies are not using technical content in their social media.
Customers discuss a product in social media, user forums, blogs, wikis, and other “ad hoc content,” as Burton calls it. Technical communicators are increasingly being asked to be responsible for user-generated content in some manner. Customers are remarkably tolerant of ad hoc content, Burton said. They understand that content created by a company is the source of accuracy for a company’s product.
Burton’s main message for us as technical communicators was to set expectations. Write the definition of success for documentation. Success can mean on time, within budget, as stated, and accurate. Success can be to reduce support costs, engage and increase return customers, and “fifty other ways to define success,” said Burton.
If a company has a metric for development or marketing projects, then apply the same metric to documentation. Refine the metric with each deliverable. Describe your measures of success to people at the company, then ask for additional measures. In the process of soliciting opinions, you will also be spreading the word.
Evangelize your definition of success, Burton said. Expose how documentation happens, which is a mystery at many companies. Use status reports, planning documents, staff meetings, and chats in the lunchroom. Announce in the corporate newsletter, “We released x documents in y languages.”
Consider levels of work in your definition of successful documentation and in your planning. Burton suggested that a first level is spell-checked only, with no examples. Second level is verified against the software, copyedited, and indexed. Third level is structured and optimized for readability, comprehension, and localization.
In your per page estimate, include time to manage, research, write, edit, illustrate, proofread, translate, prepare for publication, attend project meetings, and attend review sessions. If you lack prior examples, then start with Burton’s metrics: User guide, 2 hours per page. Training guide, 30 hours per hour of training. Context-sensitive help, 2 hours per topic. Content to multi-publish, 2 hours per topic. Editing community-generated content, 1 hour per 500 words.
A common error is to set the earliest possible date, or a little after it, as the completion date. Another error is to set a completion date because it will please management.
Evaluating complexity is our job, said Burton. External factors to evaluate include product stability, information availability, prototype availability, subject matter expert availability, and effectiveness of reviews. Internal factors include our technical experience, team cohesion, writing and document design, and audience understanding. One company that Burton helped had never evaluated its audience.
We work in product development environments that differ. A waterfall environment is iterative, with extensive planning and multiple phases. The process, stable but slow, is used by government and hardware companies. By contrast, an agile environment is managed and planned in sprints of two weeks, usually. The process, driven by customer stories, is used by software companies.
Multichannel publishing, formerly called single source, is our deliverable. Our documents appear as hard copy, PDF files, online help, offline help, e-books, smart phones and devices, tablets, HTML5, multiple languages, and device-sniffing content.
The book metaphor has become too expensive for companies and technical communicators, according to Burton. Books lock content into files no smaller than chapters. “You can’t reuse what you can’t get to,” said Burton. She tells companies to consider new tools and technologies. “Check in with your decisions every two years.”
Burton is happy that technical communication presents new problems to solve. The members at the meeting agreed with Burton’s message: Planning has changed, but we still need to plan.
Jay Martin is the technical editor at EMCOR Energy Services.