Chapter 4: Tapping into the Network

Nancee Moster

Introduction

This chapter focuses on:

• Types of technical communication work I know (from personal experience) to be available to consultants and independent contractors
• Strategies for proving to your clients that you're the right person to deliver that work
• The skills you possess as a technical communicator that are readily transferable to designing and creating non-traditional deliverables

Your goal

It's your job to convince your clients and prospective clients that you're an indispensable and irreplaceable asset who:

• Understands their business problems, products, customers, and niche markets.
• Can save them time and money.
• Can help them compete in today's marketplace.

It is also your job to:

• Make money.
• Stay challenged.
• Feel creative.

The trick is to perform both jobs successfully and simultaneously.

Your strategy

Just how do you pull of this miracle?

• First off, make sure your clients and prospective clients understand the difference between a technical communicator and a techno-junkie.
• Trust me on this: Anyone can master an HTML editor to produce a web page. Even you! But not everyone can produce a usable, interesting, well-organized, well-formatted (I know that is an oxymoron in HTML land) web page that surfers return to again and again because it offers easy-to-find answers to their questions.
• You're selling your technical communication expertise - not your ability to make some development tool do cartwheels. If you don't already understand and accept this important distinction yourself, you'll forever compete against hackers who gladly accept pennies for the opportunity to play!
• Analyze your clients' needs - whether they want you to or not!
• If you can't get your clients to buy into a full-blown, formal, analysis effort, just start talking to people. Wander over to the marketing department. Chat with the human resources director or a sales person over coffee. Take the president's secretary out to lunch.
• Look for ways to save your clients time and money.
• No, this does not slit your own throat. Everything that goes around comes around. Seek opportunities to design and create technical documentation that can do double or triple duty. Try to shorten the publication cycle. Pursue strategies to shorten the product release cycle.
• Find related audiences in your clients' organization who can benefit from your product knowledge and technical communication expertise so that you can cross over to more work.

Traditional technical communication work

I usually group traditional technical communication work into the following categories:

• Pure writing focus - Deliverables designed for authors
• Systems focus - Deliverables designed client organization personnel
• User focus - Deliverables designed for end users
• Training focus - Deliverables designed for students who must learn to use a product, and teachers who must make that objective a reality

By the way, this chapter focuses on deliverables, not delivery platforms. For example: An operations document is a deliverable; it is generally called a user guide when you deliver it on a print platform, and online help when you deliver it on an electronic platform. So this chapter discusses operations documents, not user guides or online help.

Pure writing focus

The most common forms of traditional, pure-writing-focused technical communication deliverables include style guides and editorial review.

Most technical publication departments today are understaffed. So when a technical publication manager must choose between churning out product documentation or developing a style guide to standardize product documentation, the choice is painfully obvious.

Perhaps more distressing, many technical publication departments don't use the style guide they painstakingly produced - mostly because it's difficult to reference, but sometimes because department individuals never bought into its recommendations in the first place.

As for editorial review, even though technical publication managers understand its worth, they rarely have the time, money, or resources to create, let alone implement, a consistent editorial process.

Prove your worth as a professional technical communicator by shortening the publication cycle:

• You have an amazing amount of credibility as an outside consultant; use it to achieve intra-departmental consensus on acceptable standards.
• Improve style guide referenceability by delivering it online, complete with keyword and/or full-text search capability.
• Design and create document templates and boilerplate text that actually reflect the recommendations of the style guide.
• Implement an editorial process that complements work flow instead of impedes it - even if that means cutting corners. Some editorial review is better than none at all!

Systems focus

There are all kinds of - and names for - system-focused technical communication deliverables. My personal favorites include:

• Marketing requirements document - Designed for distribution outside the development team, this very first document in a product life cycle clarifies the justification for implementing a particular solution, explores the feasibility of implementing that solution, and provides a features/functions summary that serves as the base for all other product life cycle documents.
• Functional requirements document - Also designed for distribution outside the development team, this second document in a product life cycle outlines the development team-accepted objectives for a solution.
• User interface design document - Specially designed for distribution outside the development team, this third document in a product life cycle outlines the user interface requirements and approaches for implementing the objectives accepted in the functional requirements document.
• Design document - This fifth document in a product life cycle is not designed for distribution outside the development team.
• Release document - Once again designed for distribution outside the development team, this last document in a product life cycle outlines implemented objectives, resolved problems, and outstanding issues.

The few times a client has provided systems-focused documentation for me to use as source material, it was virtually worthless because it:

• Was written in programmer-speak.
• Focused completely on activities transparent to the user.
• Was obsolete.

Prove your worth as a professional technical communicator by shortening the time required to bring a product to market:

• Design and create a system-focused document set that includes user interface and user task components - so that other departments (like product management, marketing, sales, training, etc.) can work in parallel with the development effort.
• Design and create a system-focused product document set that tracks features and functions as accepted, rejected, accepted with modifications, and deleted due to lack of resources - so that all client departments can easily and accurately determine the true contents of a product release.

User focus

I'm sure you've had opportunities to design and create all kinds of user-focused technical communication deliverables. I've personally produced the following:

• Operations documents
• Reference documents
• Maintenance documents
• Installation documents
• Getting started documents
• Quick reference documents
• Troubleshooting documents

Prove your worth as a professional technical communicator by saving your clients time and money:

Persuade your clients to deliver user-focused technical communication electronically. Not only are printed documents more costly to produce than electronic documents, they are generally obsolete before you even get them to the printshop. In my opinion, the only printed technical communication a software product requires is installation instructions for the online technical communication!

If you can't convince your clients to invest the resources in producing an electronic user-focused documentation set truly designed for screen viewing, then just slap their printed user-focused documentation set online. It's still more cost-effective than printing.

If your clients still demand some form of printed user-focused technical communication deliverable (which is not unusual - even though customers don't read user guides, they still demand the warm fuzzy of printed documentation before committing to a major purchase), don't simply regurgitate (and try to maintain) information already available online - complement your online documentation set with printed material that's:

• Usable - Organized the way your clients' audience (customers and prospective customers) already thinks, and short so that it's easy to skim or digest in one sitting
• Multi-purpose - Can do triple duty as a follow-up marketing piece, a getting started guide, and a training tool
• Long-lasting - Focuses on business processes instead of a laundry list of features or procedures, so that its shelf life can cover multiple product releases

Sound impossible? On the contrary. Call me for information about how to create a SmartStartSM guide!

By the way, every time I think I don't need to say this anymore, I get an unpleasant surprise. Usable user-focused technical communication is task-based. Yes, you can still provide menu-, screen-, or component-based information, perhaps in appendices, but the primary organization of user-focused technical communication should focus on user tasks.

Training focus

I'm sure you're all familiar with traditional training-focused technical communication deliverables like leader documents, participant documents, and training job aids.

Prove your worth as a technical communicator by saving your clients time and money:

• Design and create leader documents that can be used by non-trainers - Many clients who cannot afford full-time training personnel have shifted the responsibility for training delivery to product experts who generally have no training experience or expertise.
• This is not necessarily a bad thing. In fact, it's my experience that participants believe the advantages of learning from an instructor with experience in the trenches, coupled with prepared training materials, far outweighs any disadvantages resulting from an instructor's lack of training experience.
• The key, of course, is prepared training materials - visuals, scripts, scenarios, worksheets descriptions of real-world problems, etc. - designed to help non-trainers focus their from-the-trenches expertise.
• Take advantage of existing user-focused technical communication deliverables - I'll never forget what happened the first time I pitched the idea of using existing user documentation as training materials to a sampling of client representatives who had a stake in the training program. A grizzled veteran of many irate help desk calls asked, wide-eyed, "You mean we won't get any more questions from customers who say 'but that's not what it says in the book' and it turns out that book is a three-year-old, out-of-date, student workbook we never saw before because we use standard documentation to solve customer problems?" The product manager turned to me and said "Go do it."
• An added benefit: If the information required for training isn't already in the standard user-focused documentation set, add it! That way you get viable training materials and improved user-focused documentation at the same time!
• Design and create training job aids for delivery online - Not only do online training job aids shorten the training product delivery cycle, they also facilitate continuing accessibility to critical information. It's a lot harder to lose a computer than a dozen pieces of paper!

Crossover communication work

All the skills you possess as a professional technical communicator are readily transferable to related audiences in your clients' organization, particularly your...

• Editorial expertise
• Organizational expertise
• Educational expertise

Editorial expertise

There are all kinds of audiences in your clients' organization who can benefit from your editorial skills. Try product management, sales, human resources. Try the president!

These people are not trained writers. What's more, they probably hate writing. Chances are they'll jump at any opportunity to improve their communication output without actually improving their personal communication skills.

Organization expertise

Editing the output of non-writers is hard work - not only because many of these authors cannot construct a readable sentence, but often because they cannot string thoughts together in a logical fashion to achieve a specific goal.

Editing is a lot easier on the back end if you can control document organization on the front end:

• Help authors outline their thoughts at the very beginning of a writing project, set them loose writing, and then polish up their work for final delivery.
• Design and create document templates to standardize (and improve) the look and feel of client deliverables.
• Create boilerplate text that authors can mix and match as needed for frequent client deliverable types like sales proposals.

Educational expertise

I bet you think I plan to discuss training deliverables here. Gotcha! This is the section on marketing deliverables.

And your first response is probably "Oh no - I can't write smoke and mirrors glitz."

Well, neither can I. Nevertheless, I've made quite a niche for myself designing and creating technical marketing literature. That's because I realized the following a long time ago:

• It's a technical communicator's job to educate an audience.
• It's a marketer's job to persuade an audience.
• Guess what: You can persuade an audience by educating them!

Once you understand and accept this simple fact, there's a whole host of fun and exciting deliverables to which you can apply your technical communication abilities, such as:

• Brochures
• Product bulletins
• Product descriptions
• Product demonstrations
• Prospect presentations
• RFP responses
• Scripts
• Customer newsletters
• Magazine articles

An added bonus: Once you've produced a few technical marketing deliverables and understand the mindset required to educate/persuade rather than just educate, you'll discover that you produce better training- and user-focused deliverables - because you've started to deliver communication the way your audience thinks instead of the way a product is organized.

One word of warning: There are more people in your clients' organization with a vested interest in the look, feel, and content of a marketing-focused deliverable than a system-, user, or training-focused deliverable. Don't shoot yourself in the foot:

• Thinks in terms of phased design and creation - perhaps an outline, then a basic prototype, then a full-blown prototype, then a first draft, and so on.
• Get buy-in from all interested parties for each phase - that way the president can't turn to you when the deliverable returns from the printshop and say "That's not what I wanted!" (Unfortunately, I know whereof I speak. I learned this important lesson the hard way.)

A final word before we leave the subject of educational expertise: It's also transferable to other client departments in the form of:

• Company reports
• Employee newsletters
• Employee policies and procedures
• Employee productivity tools

Break-out-of-the-box technical communication work

Help your clients compete in today's marketplace while making yourself an indispensable and irreplaceable asset: Help them improve their products, not just their technical communication.

Usability testing

Don't limit your thinking to testing the usability of your technical communication deliverables. Expand your mind - and your services - to including testing the usability of products themselves.

Chances are your clients:

• Have never heard of usability testing.
• Or have heard about it only in its full-blown glory and can't afford it.
• Or have no idea how to do it.

Be a hero. Design product usability testing that fits your clients' budgets.

Product interface design

Ever hear a programmer say "I don't care about user interface; my job is simply to make the product work."

Talk about a wonderful opportunity to:

• Help your clients compete in today's marketplace.
• Make your technical communication job easier (by making a product more intuitive).
• Become an integral and valued part of the development team.

Your technical communication skills make you the ideal candidate for designing effective user interface - as long as you insert your expertise early in the development cycle.

This is an win-win situation. Take advantage of it.