Paul Perrotta on change management at tekom/tcworld

Content management/strategy and the business of tech comm were my two focus areas during the tekom/tcworld conference in Wiesbaden, Germany, last week, and I will summarise some of the sessions I attended in several blog posts.

(For a general overview of what tekom is like, refer back to How German is tekom and tcworld? UK tech comm consultant Ellis Pratt and I have been commissioned to sum up this year’s event for an upcoming issue of ISTC’s Communicator magazine.)

Paul Perrotta on change management

Paul Perrotta from Juniper Networks offered two sessions on change management in tech comm. He reported on his unit’s journey from siloed, bickering, intransparent groups to a more efficient Information Experience (iX) organization.

Part of the problem is that we in tech comm are often pretty bad at saying what we do and what value we provide to the company and to customers. Instead, “docs happen” frequently in a black box. If you measure how well-regarded each unit is by their budget increases, a black box is not a good place to be in, because it won’t get you better funding. Executives don’t know (and don’t need to know) how tech comm works. But they need to know whether it’s successful and how it helps them be successful. And whether 8 dollars spent on it will increase their bottom line by 10.

So make tech comm more business-like and make managers’ worries your own: How can we increase customer satisfaction? How can we contribute to increase market share? Address these challenges to show the value tech comm contributes and how you can help the business to deflect some of the threats, such as:

• Doing more (work) with less (resources).
• Deferring costs to a less certain future.
• Offshoring tech comm.

Here’s what you can do specifically:

• Define a vision and mission for tech comm to clarify what they do – and what they don’t do. (See also “Why you need a tech comm mission statement“.)
• Make improvements manageable by chunking them up into strategic initiatives.
• Dissolve the documentation siloes by architecting and governing all content as a whole.
• Improve content to make it complete, searchable and findable.
• Connecting tech comm with marketing, sales and support to contribute to and benefit from the same content.
• Rebrand tech comm as information experience to emphasize its contribution to the customers’ experience.
• Focus on users and engage with them, for example, via user satisfaction surveys, feedback, social media.
• Install an iX customer advisory board which meets regularly.
• Seek out managers with the power and money to help you and map out your allies throughout the organization.
• Make tech comm measurable and operationally efficient:
  • Link tech comm to development metrics where possible.
  • With proven competence, you can aim for 5% of R&D spend which is industry best practice in IT.
  • Ask how much of the product price tags the documentation is worth.
  • Show what (else) you could do with X more money.

Some of the results that Paul found:

• Many customers are happy to offer feedback if they find they get heard, and tech comm improves as a result.
• An ongoing discussion with users builds trust and customer loyalty.
• Commonly governed content becomes more reliable and more easily findable for employees and customers alike.
• Managers will support you because your success is their success of you demonstrate competence and that it’s easy for them to help you.
• If you map your projects to executives’ objectives, you can clarify what you can and cannot do with available resources.
• Achievements require focus to reap their full benefits – and then advertisements to make sure executives realize that you can work like a business…
• To measure their achievements, tech comm quality metrics are not enough; you need customer engagement/experience metrics as well.
• As a side effect, you will have to abandon an implicit ethos that treats tech comm as special, as an art that creates books.

Advertisement

STC13: Alyson Riley about effective IA

In her session “Building Effective IA Teams in Resource-Challenged Times”, Alyson Riley from IBM offered her take on the recent theme that tech comm needs to “speak business” to prove its worth. (This is part of my coverage of the STC Summit 2013 in Atlanta.)

Alyson argued that “nice to have” initiatives are no longer compelling enough to get tech comm a budget or a mandate. To play a mission-critical role in a corporation, tech comm must plug into the corporate strategy. However, that strategy and its stakeholders usually isn’t waiting for us to put in our two cents. So we tech comm’ers must:

1. Focus on corporate strategy as opposed to tactics.
2. Play to the motivations behind the strategy, so we can come up with ways to support it with our unique skills and contributions.

The following moves can help with that second step:

• Address the “buyer evaluates” and “buy” stages of the product. Usually, we speak to the “customer uses” stage of our product where there’s often more cost than income. The challenge is to make it compelling for buyers and sales to also use our content to their benefit in the more profitable stages. A good start is to ask sales: “What is the hardest part of your job?” and see if we can help them with the information we provide.
• Influence social content to help leads along the marketing funnel from awareness to loyalty and advocacy. That doesn’t mean to “sell out” completely to marketing. It’s often as easy and sensible as including customer benefits in our content. Simply add the “why” to the “how” and give clients a chance to understand and promote your product.

Both moves boil down to the same principle: Don’t educate stakeholders in sales, marketing, product management, etc. about the product. Instead, imagine what the success of these respective stakeholders looks like and address that:

1. Analyze opportunities your product can address in the terms of sales and marketing.
2. Craft an effective story that centers on your content and how it can drive revenue, sales, customer satisfaction and loyalty.
3. Prove it with metrics that speak to the stakeholders.

When it comes to metrics, page views of documentation usually don’t impress managers much. Instead, Alyson suggested “time-to-value” (TTV) which measures the customer’s time from buying or paying for the product to the moment they reap value from it. This is similar to “return-on-investment”, but TTV can be clearer to measure when investment consists of one-time payments plus maintenance fees. Also, it’s easier for tech comm to favorably influence TTV… 🙂

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?

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“…)

Top 6 tech comm trends for 2013

Flexibility in several dimensions is my tech comm mega-trend of the year, after mashing up the top 6 trends presented by Sarah O’Keefe and Bill Swallow in Scriptorium’s annual tech comm trends session. Head on over to Scriptorium’s site to watch a recording of the webcast and to read Sarah’s take on the trends she presented.

1. Velocity

Velocity is Sarah’s first trend which simply means that we tech comm’ers are expected to create, deliver and update content faster than before. Also gone are the days – or months – when localized documentation could be several weeks late.

If we are serious about this, we need to revamp our documentation processes. I agree with Sarah: A recent restructuring of documentation processes has sped up my throughput and made my estimations more predictable. So it has improved my productivity as a whole.

It’s also made me more flexible because my smaller task packages take less time before I finish with a deliverable. It used to take me 4 to 6 weeks to update a user manual, so interrupting this task for something more urgent was expensive because it further delayed the manual and also clogged up my pipeline. Now I take about 2 weeks for the same task which allows me greater flexibility in sequencing my tasks because I still have a chance to finish the manual by the end of the month, even if we decide that I first spend a week on something else. I could not have achieved this  flexibility without revamped processes to analyse and specify documentation and without a topic-based approach.

2. PDF is here to stay

Bill’s doesn’t see PDF go away any time soon, if only because it’s durable, controllable, reliable and downward compatible to that other durable format called print-on-paper. Google Docs might be a potential competitor, but Bill doesn’t see it making great advances on PDF in 2013.

As comments from the audience showed, there seems to be a lot of passion about the issue and some people can’t seem to wait to lay the last PDF to rest, finally. As a tech writer in semi-regulated industries, I know that I’ll be creating PDFs for my users for a looong time. It might not be a trend per se, but I agree with Bill that we haven’t seen the end of PDFs just yet.

3. Mobile requirements change technical communication

Mobile will be the big game-changer for tech comm this year, predicts Sarah. Requirements for mobile documentation mean that PDF will be one format of many – and maybe not the primary one in many cases. Other essential deliverable formats include HTML5 (for an online audience) and apps (for native or offline use).

The limited real estate of mobile devices requires more flexibility in how we structure and present documentation. Progressive disclosure can help us to integrate essential user assistance in labels or pop-ups. Beyond that, we need a strategy of what to disclose where and how to create a seamless and consistent user experience.

4. Mobile drives change

Similar to Sarah’s trend, Bill underscored the influence of mobile documentation. He emphasized the need for concise, no-frills content. Rather than jump on the progressive disclosure, Bill presented an alternative scenario: An “executive” device with the main product hooks up with a second, mobile device which presents the corresponding documentation. (I didn’t quite understand this point, I think Bill mentioned a second screen embedded in the primary device, but I’m not sure.)

5. Localization requirements increase

Bill sees the scope of localization expand as the need for translation no longer stops with external documentation. Increasingly, internal documents also need translations because corporations need to keep international teams afloat and cannot afford to lose traction due to vague or misunderstood communication.

This is also the reason why, economic advantages notwithstanding, machine translation hasn’t taken off yet. But a hybrid process seems promising in some areas where machine translations become useful and reliable after human editing. Enter flexibility as our audience now might also include far-flung colleagues – and our tasks might include editing text that’s been translated by robots.

6. Rethink content delivery

As we face diverse requirements for working at different speeds in more formats and for more diverse audiences, we need to be flexible and rethink what we deliver and how. With demands like these, pages of static contents are frequently not sufficient. Instead, users need more dynamic content and filters to customize the documentation to what they need at the moment.

Someone in the audience summed it up very well: “Think of content as a service, not a product.” To me that makes a lot of sense, because it emphasizes the recipient of that service and their situation over the static dead-on-arrival quality that comes with a tome of printed pages.

My summary

I think flexibility is a key ingredient in many of the trends Sarah and Bill discussed with the audience. The recent opportunity to reorganize how I create documentation has given me two kinds of confidence: I have a suitable process in place for now. And I can change processes and methods when I need to.

A secondary trend occurred to me as well: Thanks to Sarah’s spirited mc’ing by which she included the majority of audience questions and comments, this webcast felt a lot more communal than previous ones I have attended. It was almost like single-session, virtual mini-conference. And if industry leaders can bring us together outside of conference season, we can strengthen our networks and move our profession forwards – with just a little bit of flexibility.

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.

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.

Leah Guren’s Fish Tale at TCUK12

After opening remarks by conference organizer David Farbey, Leah Guren‘s keynote relevant and entertaining keynote address presented several lessons from the animal world:  A Fish Tale: Improve your Career by Watching Fish!

1. Take a leap of faith – like salmon. It simply takes some guts and a little bit of faith that tech comm is here to stay, else you won’t be able to make a long-term plan and get behind it.
2. Stay in school for better chances of survival – once you took that leap, keep honing your skills, keep developing. There are lots of ways and many don’t require the same amount of time and money as going to a conference, whether it’s e-zines, forums, user groups or webinars (some excellent ones are actually free!) Be sure to make your professional development part of your regular work schedule.
3. Invest in better PR – the difference between a carp and coi is mainly the prize tag – which is thanks to better PR for the coi. Communicate your value that you bring to the company and to its customers. We know how much words matter, so we can do better than calling ourselves technical writers. “Information architects”, “content strategists”, even “technical comunicators” can make more money.
4. Find the right stress – (sorry, I forgot how this related to fish… 😉 ) Tackle your fears, get a new challenge and pick the kind of stress where you’re still in control, feel stimulated and can grow.
5. Active swim in a larger pond – because like a carp you will grow (professionally) in relation to the size of your “pond”. Find opportunities for growth how you can be the expert in your environment.

I’m sure I forgot a couple of Leah’s lessons. Nevertheless, I want to add an additional lesson that I’ve found important: Know the secret of the birds. That means know how your enemies tick, so they don’t eat you. Or if they’re not threatening: Seek heroes outside of your immediate field. Sure, you won’t be able to fly like a bird, but you can still find birds inspiring.

James Conklin, Overcoming Change Resistance at STC12

In “Understanding and Overcoming Resistance to Change”, James Conklin focuses on change, rather than on management as most change management seems to do.

Why change fails

The problem with many change management initiatives is that they fail. Too many of the involved people perceive change as a thing that is “out there”. So instead of embracing the new, they resist this “external change thing” on several related levels:

• Fear. Change threatens to undermine the skills, power and security that people have built up.
• Reason. People argue rationally against the change because it contradicts their goals or because they simply do not understand how it will improve things.
• Personal attributes. People may resist change because it doesn’t address their age group or their learning styles or their cultural or ethnic background.
• Psychology. Change can incite strong emotions that leads to denial and, once again, to fear.

Why the explanation fails

James points out that these reactions involve a significant “attribution error”. We tend to blame other people’s resistance to change on them, their attributes, their lack of skills, their stubbornness. But we often blame our own resistance to change on our situation, lack of time or resources, etc.

What resistance is

There’s a more constructive, alternative perspective on resistance which is compatible with both sides of the attribution error: Resistance is one of the ways we make sense of life, specifically of our experiences in the workplace.

If we perceive resistance as a clash of narratives of different experiences, we can get away from an opposition of stubborn persons and towards an open-ended, negotiable inquiry – without losing sight of the goals! We can focus on fixing the situation by redistributing power and autonomy instead of blaming people and transforming their tasks.

What sounds very theoretical up to here, has been born out by studies from Canadian nursing homes where nurses and caretakers had initially resisted changing their procedures. I’m also reminded of other successful changes in the workplace, whether it’s Best Buy’s ROWE initiative or schemes that empower people to work remotely and still manage to hold them accountable for their work and results.

What this has to do with techcomm

For many in the audience (myself included), it was obvious that James speaks about change that technical communicators find themselves in. But James also points out that technical communicators play an essential part in shaping narratives of change.

We set the tone in customer-facing documentation: If we know their situation, we can join their conversation, explicitly compare their current situation to a new way of doing things. Then we take them seriously and address a change in processes constructively. We can even engage in their conversations directly, for example in forums or other user feedback.

If we recognize the importance that our users place on the purpose and value of their work, if we reflect not just the metrics of their work, but also the quality they attribute to it, we can improve the user experience and help to facilitate change with technical communications.

My webinar slides as PDF handout

If you’ve attended my webinar “Getting ahead as a lone writer”, you might be interested in the slides in PDF:

They were supposed to be made available to attendees by the STC, but apparently that hasn’t happened as I’ve just learned yesterday.

If you have any more questions about the webinar or being a lone writer, feel free to browse my previous posts or pose your questions in a comment below.