Getting mileage from a tech comm mission statement

If you have a mission statement for technical communications, you can use it to anchor several strategic and tactical decisions. I’ve suggested a few general reasons Why you need a tech comm mission statement in my previous post. The valuable discussion that ensued led me to think we can get some mileage from a mission statement in some high-level tasks further downstream.

Consider a mission statement that says: “Our product help provides users with relevant product information at the right time in the right format.”

Defining audiences and deliverables

You can keep your audience in focus with a mission statement. Do you write for end users? Maybe there are different types, such as professionals vs. amateur hobbyists? Do you also address colleagues who expect to find internal information in the documentation? The mission statement above doesn’t specify it – and hence can be expected to address everyone who uses the product.

You can also derive your deliverables from a mission statement. Do you publish to several formats or only to one? What is your priority of formats? Web help first, PDF second seems a standing favorite that’s recently been disrupted by the emergence of mobile output. The mission statement above merely mentions the right format – so you need to figure out what format is right for your audience types. You can use personas to determine how your users work with the product – or better yet: Observe or survey them!

Defining information model and processes

You can derive your information model, the structural standard of your documentation, from your mission statement. This model should help you to reach the goal described in your mission and serve your audience. For example, topic-based architectures have long been popular. If you need to retrieve small chunks of information, for example to share steps in a task or exception handling advice, consider a more granular standard such as DITA.

Your processes should outline a repeatable, efficient and effective way to create your deliverables so they address your audience and, once again, help you to achieve your mission goal.

Your information model can suggest which topics or elements to create need to be created and updated for a given product or enhancement. Together with your processes, this makes it easier to plan and estimate documentation efforts – in theory at least…

– But with some management support and some persistence, a mission statement and some strategic decisions piggy-backed on to it can help you get out of the proverbial hamster wheel.

What do you think? Can this be helpful? Or is it too far removed from real life? Do you have any experience with a larger documentation strategy based on a mission statement? If so, did it work?

Advertisements

Why you need a tech comm mission statement

A mission statement for technical communication can help everyone in your company (or you and your customers) to stay on track in pursuit of a common goal of what your documentation can and should achieve.

Just like a corporate mission statement, a tech comm mission gives all parties who are involved with documentation direction and a common goal. It describes the purpose and benefit of the documentation and how it is achieved. It helps to define processes for creating the documentation as well as metrics whether the documentation is successful. If the mission is well-conceived, it guides documentation strategy without prescribing it.

For example, if you want to focus on usability and speed, a mission for your documentation could be: “Our product help answers any user question about product use in no more than three mouse-clicks.” Your strategy would then aim for a well-structured, easily navigable context-sensitive online help – with printed user manuals and closely tied in training materials taking a backseat.

A more comprehensive mission could be: “Our product help provides users with relevant product information at the right time in the right format.” This would set you on a quest to find out who your user types are, which product information is relevant for them and which formats it can be provided efficiently.

A mission statement in itself cannot be right or wrong. But it must be useful in several respects. Specifically, it must help:

  • Your customers and users by guiding you to provide useful documentation.
  • Your company externally to provide documentation which improves the perceived product quality.
  • Your company internally to anchor the importance and function of documentation.
  • You as technical communicators to make appropriate strategic decisions about documentation, for example, which users to address, which deliverables and processes to define, which methods and tools to apply.

What do you think? Is a mission statement for tech comm necessary? Or merely helpful? Or a vain attempt at putting on corporate airs when the writers should just buckle down and get the job done?

(Edit: The discussion continues in “Getting mileage from a tech comm mission statement“…)

Is it about the manual – really?

How can tech comm regain agency in times of change? Imagine management decides to completely change the tech comm deliverables of your company because – it makes sense to them somehow. For example, to replace printed user manuals by iPads, as American Airlines recently got FAA approval to do. And the sense it made to them wasn’t necessarily about usability: One of the reasons given was to save $1.2 million – in fuel for flying around heavier manuals rather than lighter iPads. – Or insert your own hypothetical change of processes, tools and deliverables…

The meaning of change

What does such a change in deliverables mean for tech comm?

  • “Oh, no, another reorganization project…”
  • “Is this another shot at doing more with less?”
  • “Management has no clue how the documentation adds value to the product!”

All these reactions are legitimate, important and understandable. But they might not help us to change management’s mind, because broadly speaking we and they focus on different things:

  • We tech comm’ers focus on executing our processes and churning out good deliverables efficiently, as we should.
  • Management focuses on optimizing revenue and cash flow by changing corporate products and services, as they should.

It’s difficult to strike up a conversation if our main concern is merely a secondary factor for the other side.

It’s even more difficult if there’s not a level playing field, because we are the “change managees”, the object of change management – which is not always a pleasant experience.

So how can we regain agency in such times of change without looking like the luddite who wants to keep fiddling with layout and page breaks?

Adding tech comm meaning to change

The first important challenge is to find the meaning that’s really meaningful to managers – and nope, page breaks aren’t it. Even manuals aren’t it, if management is willing to can them. Manuals are just one way of delivering documentation – so we tech comm’ers hang our hearts on them at our own peril.

Unless manuals are the most effective and most efficient way to satisfied, productive customers, a company shouldn’t really have them – as long as it has something else which is at least as good and cheaper.

I follow a lead by Sarah O’Keefe, Ann Rockley and others who know more about tech comm-facing managers ticks than I do: We need to talk about money, either as revenue or cost. And customer satisfaction to the extent that it is tied to money:

  • The company can lose customers (= revenue).
  • Or it may find tech support calls (= cost) go up because customers need more hand-holding to get stuff to work.
  • Or it gets sued (= cost & damaged reputation), because it fails to provide legally required documentation!

These are all good reasons to insist on good, efficient documentation which requires tech comm professionals! However, they won’t mean that manuals are necessarily the deliverables of choice.

Strategic Technical Communicator panel at tekom12

Marijana Prusina, Nicky Bleiel, Sarah O’Keefe and Dr. Tony Self pooled their experience in an interesting and versatile panel session about the more strategic aspects of our profession.

Marijana Prusina, Nicky Bleiel, Dr. Tony Self, and Sarah O'Keefe

The Strategic Tech Comm panel (photo thanks to Axel Regnet)

It was not so much a discussion as a fast-paced session of the experts sharing their thoughts on strategic issues and problems, so I’ll simply list some of the insights:

  • Domain knowledge for a certain industry (as opposed to general tech comm skills) can be a great asset that you can use to build a career on, but it’s not necessary to become an expert in any one domain.
  • To get a mandate or money from management, don’t argue in terms of quality, but rather in terms of cost: Show how improving documentation will either reduce cost or create additional revenue.
  • Freelancing can work well, but you will need some things which are less essential if you are employed:
    • Considerable project management skills – even if only for your own projects
    • A good network of satisfied customers, other people who know and like your work, and other freelancers with whom you can exchange tips and tricks – and maybe even projects if they’re better skilled to take them on or when you are busy.
    • A snappy definition of your core services, skills and profile.
  • To improve the reputation of tech comm and exert influence in your company, try these strategies:
    • Volunteer, if you can afford to, whether in a professional tech comm association or a standards committee.
    • Underpromise and overdeliver on your deliverables – and meet the deadlines you agree to.
    • Write a book – but be aware that you’ll mainly do it for marketing and influence: It’s a lot of work, and it won’t make you rich.
    • Be the advocate of users, who are satisfied, more productive and less costly to your tech support thanks to good documentation.
  • Take all the training that makes sense to you and that you can get. Don’t forget about domain skills and software-related skills, for example, for API documentation. When training, keep in mind your resumé and what value you will add to your customers or your employer by adding a certain skill.

Turning tech comm into a biz asset by Sarah O’Keefe

Turning technical communications into a business asset, according to Sarah O’Keefe, is mainly about justifying cost; it is necessary, but possible. Her session at tekom12 was part of the Content Strategy stream, presented as last year by Scott Abel.

How expensive is your documentation – really?

Much progress in a tech comm department gets stumped when we, the tech writers, say: “Ah, that’d be great – but they’ll never pay for it!” What that really means is: “‘They’ don’t see the value (or the urgency).” So to prove the value behind tech comm, we need to justify how we can either save money (by reducing effort) or how we can generate additional revenue (by producing value that exceeds our cost).

Sarah points out several way to do this:

  • Show how tech comm can address legal or regulatory issues. Avoiding lawsuits is a great way to save your employer’s money!
  • Control the real cost of tech comm, because “cheap can be very expensive”: Yes, you may get something akin to documentation from a secretary or an intern, but…
    • Is your documentation efficient to maintain?
    • Does it scale or allow publication in other formats?
    • Does it actually satisfy your customers and support your brand – or does it stab your corporate value statement in the back?

Cost containment strategies

Sarah mentioned several strategies to control documentation cost.

The first bunch has to do with efficient content development:

  • Reuse as much content as possible: Write once, use many times, either in different places of the same format or in different output formats.
  • Automate formatting: Manually handcrafted formatting of deliverables can be a huge cost factor. It’s not uncommon for tech writers to spend 20% of their time (and hence a sizable chunk of money) on formatting output. Automate this, by relegating format either to templates or CSS.
  • Localization scales content efficiencies: Localizing or translating your content will be all the more inefficient, the more inefficiencies you have in your original documentation processes. This applies to content reuse, inefficient content variants and formatting.

Then there’s cost reduction outside of the tech comm team, for example, in tech support:

  • Consider whether your documentation is good enough to deflect the maximum possible number of support calls. Anything that users cannot find in the documentation, whether it’s missing or unfindable, drives up costs for your tech support staff.
  • Ensure your tech support staff has access to your documentation in formats they can work with efficiently. Downloading and then opening a document of 10 or 20 MB, is not only clumsy in its own right, it’s also likely that it doesn’t present the required information in the most efficient way…
  • Ensure your documentation content is actually useful to tech support staff: It must not only be accurate, but also up-to-date. Consider the nightmare in terms of costs and maintenance if tech support spun off their own documentation to augment the “official documentation”. Instead, invite them to contribute to the documentation you create.

Make documentation more strategic

Then there are a few strategies to make documentation more strategic, or rather, more strategically valuable:

  • Ensure your documentation is not only searchable (so it’s captured by publicly accessible search engines), but also findable (so people know where and how to get to it) and discoverable (so people link to it, from blogs or forums or twitter or the like).
  • Align tech comm to larger business goals: Find a corporate goal, preferable one that is tied to revenue to be made or cost to be avoided and show: If the tech comm team did this, it could contribute approximately that much money (in savings or additional revenue) to that larger corporate goal.

Conclusion

Sarah’s talk was geared towards the strategic angle of tech comm, but succeeded in making valuable points very clearly. Whether you can actually apply her advice in your situation may depend on how much managers with budget control feel the pain of improving tech comm.

TCUK12, day 1: Workshops & company

The first day of the ISTC conference TCUK12 offered workshops and great opportunities to meet tech comm’ers from all walks of life and many corners of the earth.

When I arrived late on Monday evening, I promptly headed for the bar and joined the advance party for a last round – which lasted so late that I’m not even sure in which timezone it was 2 am before I turned in…

Robert Hempsall: Information Design 101

Robert Hempsall offered a great and engaging hands-on Information Design 101 workshop about information design. The workshop focused on the five key areas of content and structure, language, layout, typography, and lines and spatial organization. Using a formal application to vote in English elections by mail, Robert led us through the process of designing the form to maximize clarity and usability.

Thanks to our versatile and engaged group of delegates, our work on the form was not only lively, but showed how different disciplines contribute to the solution of better information design, from tech comm (with its principles of minimalism and parallelism) via user interface design (with its emphasis on making completion of the form as easy and painless as possible) to graphic design.

In this sense, the workshop presented a good example of “design by committee” (which is usually a terrible idea): We discussed the most intuitive and user-friendly sequence of the form’s elements and how best to phrase the section headings, as questions or as imperatives. A seemingly innocuous “all of the above”  check box also caused a debate: Should it precede the individual options, to make completing the form quick, easy and painless? Should it come last, so users hopefully first read and reflect on the options? Or should it be omitted altogether, so users have to think about each option and select all that apply.

Form design is maybe not among the core tasks for many tech writers. Yet I’ve found several challenges in it that are strikingly similar to getting a topic structure just right, whether it’s a consistent, indicative heading, good, clear instructions or logical structure.

Rowan Shaw: Quality Across Borders

Rowan Shaw‘s workshop Quality Across Borders: Practical Measures to Ensure Best-Value Documentation in Global Technology Businesses focused on creating documentation both with authors and for users who have English as a second language (ESL).

As in introduction, Rowan presented us with 10 sentences each of which had some element that can create a problem for ESL readers, ranging from “10/03/12”, which could mean 3 October or March 10, to metaphors and slang.

If you need to hire ESL authors, it can be helpful to ask applicants to sit for an exam which tests skills such as procedure writing, fluency of expression, structuring, detail, consistency – but also their motivation for applying, to spot those candidates who want a foot in the door, but might not be interested in tech comm in the long term. We discussed a sample test, whether it was applicable and appropriate in all cultures.

Rowan suggested that, given the practicalities of global ESL authors, you might have to settle for less than perfect profiles in candidates. Then it is important to know which skills are easier to teach someone on the job, for example, grammar, structuring, capitalization, punctuation and how to use a style guide. Other skills are harder to teach, such as an eye for detail, audience orientation, logical thinking, but also more intricate language skills, such as prepositions and correct modifiers.

Again, this workshop benefitted tremendously from the diverse talents in the room and the experiences delegates brought to the topic.

The right company

I keep harping on how much I enjoy and benefit from meeting other tech comm’ers. Just on the first day:

  • I found that several other doc managers are also wary to hire subject matter experts, who are less committed to tech comm, because they might just want a foot in the door (see above).
  • I had an immensely helpful conversation with someone who’s a visiting professor and who could give me tips and ideas that I can try as I consider teaching as a future path.

So day 1 was very fruitful already, and I’m looking forward to more sessions and conversations to come.

Leah Guren’s Tales of Terror: Avoiding Project Disasters at STC12

Leah Guren presented a spunky, fast-paced session of project train wrecks that offered many lessons to managers and writers in tech comm projects. She presented disasters in five categories: Communication, people, politics, implementation and global issues.

“Failure to communicate”

When poor communication derails tech comm projects, it’s often due to missing information. Specifically, a project may have failed to ask the right questions (almost like performing due diligence) or failed to insist on getting the questions answered by the subject-matter experts or the specifications.

To prevent this problem, don’t write blind! Ensure that the project is clear not only on the product, but also on the users, their scenarios and workflows. This is a tricky issue that it afflicts even experienced tech comm’ers who may be tempted to wing it. But a checklist can help you to cover all your bases.

Of monster managers and quirky SMEs

People can jeopardize documentation projects, especially if they bring together people who don’t work together in projects very often. As a tech communicator, you might deal with an annoying monster manager breathing down your neck one minute and placate a quirky subject-matter expert the next.

Leah’s advice was straight and matter-of-fact: You can’t fix crazy, so don’t take it personally. You might even find yourself documenting irrational processes and workflows.

Of stakes and turf wars

Politics can endanger projects when agendas clash and turf wars arise between fiefdoms. This is actually the reason why so many organizations still run a balkanized business where development proceeds in distributed siloes. The resulting documentation often perfumes the pig though it can hardly help being inconsistent or disparate.

Consider carefully whether it’s worth the extra effort to try and clean up broken workflows and GUIs after the fact – or if you even have the leverage and the clout to be successful.

Of implementation constraints

Implementation can throw a wrench into a well-planned project, when you find you lack skills, resources or access to such. Sometimes you’ll see warning signs, such as “scope creep” when a project quickly becomes more complex than you thought originally. For example, Leah talked about a project which was to cover a complete product overhaul – and an SAP integration on top of it.

This is a case for a senior stakeholder or manager who needs to assess the situation and who can hopefully reschedule tasks or reassign resources.

Of intercultural complexity

A recent, often unexpected problem in tech comm is complexity due to globalization. Global business often doesn’t scale seamlessly, and tech comm (as all culturally contingent practices) even less so.

If your project involves countries, markets and languages you haven’t been involved with yet, take extra care. However, as companies find out again and again, there seems to be no fool-proof way to address this issue, other than trying to look at similar case studies.

Solutions and remedies

Leah held off suggested solutions until the end. The good news is that many projects can address many of the issues to an extent with standard project management tools and best practices.

  • Use a project check list that defines scope, deadlines and involved participants, incl. their roles, goals and expectations. Include also SMEs and other stakeholders.
  • Track project status meticulously and insist on regular reporting – from participants and to the steering committee.
  • Have a contingency plan, if at all possible, which can buy you extra time or replacements for people if you need them.

Salvaging wrecks

But the best-laid plans don’t always guarantee success, so you might find yourself with a project train wreck that needs salvaging. Leah’s advice, at least to me, wasn’t revolutionary or new, but rather an encouragement to stay honest:

  • Don’t hide from problems or difficult people. They won’t get better and they won’t disappear by themselves. Face them and address them as soon as possible. If nothing else, you’ll sleep better.
  • Cut your losses, if you have to and find the right time to cut your losses, before you throw good money after bad. If you, be clear to everyone (including yourself) what went wrong and why.

The assurance of coaching

After her presentation (which already included several case studies that I have omitted above), Leah solicited further case studies and problems from the audience. This rounded out the session quite well which felt like coaching on speed.

For me, the most important take-away was that projects can and will go wrong for all kinds of reasons that are beyond our control. But if we are alert and honest to ourselves, we can salvage most of them, wrap them up with decent success and saved face.