communication for the real world

Tools that work

This article is adapted from a presentation (PDF, 772KB) delivered to the Society for Technical Communication TransAlpine chapter annual conference in Ljubljana, Slovenia on Friday, 18 April 2008. This presentation cannot be printed, distributed, or otherwise used without the written permission of the author. All rights reserved.

Textured wall, Ljublana, Slovenia

Are expectations of your work constantly changing, or ill-defined? Do your projects suffer from scope creep with no sense of the original agreement, and no understanding of the time needed to meet delivery schedules? Are you juggling multiple projects, multiple timelines, and trying to muddle through scoop creep?

Learn project management skills for technical communicators

You have to be able to explain your expertise and the parameters of your work. You have to be able to suggest, with confidence, the direction documentation should take. You have to be able to create reasonable project metrics and service level agreements, and use e-mail and telephone communication templates to even out your project communication and make things run smoothly. In short, you have to be able to fully exercise ownership of every process and every product of your working day.

What’s in it for you?

  • Efficiency
  • Project knowledge
  • Professional consistency
  • Confidence

In addition, as you get better at applying project management skills to your projects, you will find that you get:

  • More income, if you are a contractor and find that you can handle more projects
  • More respect in your workplace

In addition, use of these tools provides a means of protection from bad clients, or from projects using faulty processes. When a project manager does not deliver what you need for the project, or consistently misses deadlines, you can track it, substantiate it, and take action if needed.

Here are the tools

  • Your professional knowledge and core skills
  • A project management workflow containing the following elements:
    • Project metrics process
    • Service level agreement process
    • Communication process
    • Review process
    • Publishing process
    • Delivery process
    • Post-delivery de-briefing process
    • Project tracking process

Know the value of your core skills

Your core skills as a specialized communicator (writing, editing, research, and information design) are what make you valuable. Keep up to date with your field, and your specialization. Join groups and forums and read background material. Know your profession. Stay relevant.
Use your research skills so that you never make a professional decision because it sounds good, or it sounds right, or you think it might be correct. Always back up your decisions with research. If you are rigorous in your approach and verify your sources, Web research can be perfectly useable.
Follow templates, reference guides, style guides, and language direction whether supplied by your employer or from your own collection. Develop a project style guide if your employer does not have one. Do not insist on a template, a reference, a style, or a language direction because you like it. Instead, always choose what is right for your employer, and be able to meet their requirements with grace. Being able to make informed choices and to provide breadth as well as depth of service to your employer are powerful additional skills for writers. Add in project management, and you have skills that really set you apart from the rest.

Take time now to save time later

Here are the things you’ll have to know and own:

  • Your product
  • Your ability
  • The project
  • Your project management processes

Know your product

Create a documentation matrix that fits your work situation. Use it when you talk to the project manager about the direction documentation should take in the project. It’s a useful tool because the project manager probably does not know all the kinds of documentation you can produce, or the situations in which a type of documentation should be used.
Here is a sample documentation matrix:

This documentation option: Serves this purpose: And is created by:
User guide A guide for non-technical end users. Documentation services
Administration guide A guide for administrators and technical end users Documentation services
RunBook An administration guide which contains procedures to start, stop, and supervise a system. Documentation services
Frequently asked questions (FAQs) A list of frequently asked questions HMTL coded and posted on the product Web page for easy access and usability. Documentation services
Product brief Information briefs for technical or non-technical targets. These are used for marketing purposes. Corporate communication services
Self-paced, interactive learning module Interactive, self-paced tutorials for technical or non-technical end users, as required. Training services
Technical standards A technical specifications document for a project. Technical development manager

Know your ability

Create a list of questions to define your work and use them every time you approach a project. This builds up a frame of reference for you to know your own ability in every situation. Here are some possible questions:

  • How long do I need for the research segment?
  • How long do I need to learn the product or tool?
  • How long do I need for the draft segment?
  • Do I need to create one draft or two before I send it for review?
  • How many reviews do I need?
  • Do I need another pair of eyes to edit the document?

Know the project

Ask yourself how involved you are with the projects for which you produce documentation. Get involved early in the process, if you can. A good thing to take on is user testing. With user testing, you get a hands-on learning opportunity with the product, and project managers understand the benefit.
Have regular meetings with your project team, your documentation colleagues, and your manager. This keeps you thinking about the projects you manage, and on top of your schedule.
Create a list of questions to define the project. Use them every time. Here are some possible questions:

  • What is the target audience for the documentation?
  • What kind of documentation does this project need?
  • What is the estimated page count according to the project manager or the subject matter expert?
  • How well is the project planned?
  • Is the subject matter expertise a team effort?
  • Does the subject matter expert need a walkthrough?
  • How long does the subject matter expert need for review?
  • Can the subject matter expert learn the one-review system?

Understand project metrics and learn to apply them
For a senior specialized technical communicator, here is a basic documentation project metric:

Keeping in mind that things change:
Three finished pages per six-hour day + contingency

The three-page count includes research, product learning, writing, editing, illustrating, reviewing, finalizing, publishing, and delivery.
Three pages means three pages start to finish.

Contingency = 5–10% of total estimate, depending on risk.

Using this metric as a base, develop your own project metric. Learn what works best for you through experience. Use a metric every time, and consolidate the results in your post-project de-briefing. Be adaptable when you plan so that you can take anything unusual about the project into account.

To avoid difficulty, do not share the project metric you use, and always treat it as a flexible rule. Every project is different. Your results may vary.

Develop a Service Level Agreement (SLA)

Create an SLA process that you follow each time you approach a piece of work. Here is a simple one that works well:

  1. Know the project and, using a project metric, build up a reasonable estimated SLA for the work to be done.
  2. Call the project manager on the phone, or walk over, to discuss it before putting it in writing.
  3. Write up a brief estimate which includes:
    • The documentation product
    • The estimated delivery date
    • What they have to provide so that the work can be done and the deadline for that
    • What to expect next
  4. Send the estimate to the project manager via e-mail.

Effectively, the SLA is the shell of your schedule for the project. For the project manager, it does not need to break down into dates for drafts, edits, or review, but the project manager knows what to do and what to expect. For you, the SLA helps you to organize your effort, to recognize and quantify scope creep, and to know when to escalate if a significant problem develops.

Follow up relentlessly

Communication is the key to a smooth project:

  • First, always discuss things in person or over the phone. Keep it short and to the point.
  • Second, always recap the important conversation points in an e-mail. Again, keep it brief.

Build a communication library to contain bare-bones templates for the following:

  • An initial project reply and high-level estimate, if needed
  • A service level agreement (SLA)
  • An adjusted SLA, for when things change
  • A message containing a draft for review, including a brief description of the review process, if needed
  • A publication announcement

Prepare the documentation

This is what you do best. Create a production process that outlines your core activities:

  • Research and learn
  • Write
  • Illustrate
  • Edit
  • Prepare the draft for review

Conduct the documentation review with the subject matter expert

Create a review process that works for you. This is one of your processes, so be confident to:

  • Drive the subject matter expert review turnaround time.
  • Drive the review meeting.

Explain the review process to the subject matter expert up front:

  1. The subject matter expert conducts a technical review of the document.
  2. There is ideally only one review meeting to gather and implement changes. This is most effective if you make document updates in real time during the review meeting. To make document updates in real time during the review meeting, use WebEx, MS NetMeeting, or another product that allows you to look at the same document with your subject matter expert and let them see exactly what changes you make.
  3. The document is published.

Here are guidelines for the subject matter expert’s review process:

This number of pages in one document: Allow the SME this amount of time to review:
Up to 50 pages Two working days
50–100 pages Three working days
100+ pages Four to five working days

Here are some guidelines you can give to the subject matter expert to use while they review:

  • Concentrate on content only. For example:
    • Product or technical definitions
    • Steps
    • Processes and procedures
    • Technical specifications
  • Do not correct anything other than content. For example:
    • Grammar
    • Style
    • Language
    • Template
    • Layout
    • Colours
    • Document definitions and instructions
    • Front matter

You can offer to go through the material with the SME so that they know what they should focus on, and what they should ignore. You only have to do this once with a subject matter expert. It teaches them a valuable skill that makes the process faster and more effective for them, and more reliable for you.

Finalize and publish the document

Create a finalize-and-publish process that works for you. Use it every time you finalize and publish a document.
Here are timing guidelines for the finalize-and-publish process:

This number of pages in one document: Requires this amount of time to finalize and publish:
Up to 50 pages One eight-hour day
50–150 pages Two eight-hour days
150–250 pages Three eight-hour days
250–350 pages Four eight-hour days

Publish the document in the way that works best for your employer.

Deliver the document to the project manager

Create a delivery process that works for you and refine it over time, or when delivering to a new project manager. Here are guidelines for document delivery:

  • Do not widely release drafts of a document prior to delivery.
  • Own the documentation process right up to publication.
  • Deliver succinctly, and with authority.

Within one week: Do a project de-briefing

Create a de-briefing process that covers every angle of the documentation side of the project. Be sure to contribute lessons learned from the project to the:

  • Project manager
  • Documentation process
  • Project process
  • Any other related process, as needed.

As always, discuss your de-briefing with the project manager, the subject matter expert, your documentation colleagues, and your manager first. Then, follow up via e-mail.

Track your projects

Track your activity across all projects.
Create a tracking process that works for you. Update your tracking once a day and consider following these guidelines:

  • Track the real time that you use.
  • Use any gaps that you find in the schedule to be productive.
  • Communicate changes in your schedule promptly to the project managers and subject matter experts that are affected by them.
  • When you find conflicts, defend your schedule in quantifiable terms such as lost revenue, lost opportunity, duplicated or wasted effort, and so on.

Here are some examples of project tracking tools:

  • MS Project (
  • A presentation slide that you update daily, one slide per project
  • A spreadsheet application such as MS Excel
  • Google Calendar (
  • MS Outlook (
  • Magnets on a whiteboard
  • XPlanner (

Learn more

Don’t stop with the basics. Learn more to make you better at handling projects.

Further reading Description Link
The Project Management Institute (PMI) PMI publishes standards related to project management and manages project management certification. PMI
The Deadline by Tom DeMarco A novel about project management. The Deadline
Society for Technical Communication (STC) Follow trends and learn from dedicated professionals in STC. STC
Other associations Follow trends and learn from dedicated professionals in other associations. Google your country.
Google your area of specialization.
Online forums and MVP sites for tools and techniques Places where like-minded professionals share knowledge. Google your tool or technique.