To get managers behind a migration to topic-based authoring (TBA), focus on benefits and savings. This is the last post in a two-part series. Find the beginning and background in part 1.
I present the speaker notes and explanations instead of the actual slides which only contain the phrases in bold below.
Benefits and challenges for writers
Make documentation efficient. For technical writers, the structure within topics and across all topics makes writing topics more efficient because you spend less time stressing over what goes where and over layout.
Make documentation transparent. The structure of the topics collection as a whole makes content more transparent: It’s easier to spot a missing topic, if each setup procedure (how to set up stuff) is accompanied by an operating procedure (how to use what you’ve just set up) and by a concept topic (what is that stuff you’ll set up and operate). Thanks to their structure and smaller units, documentation efforts also become easier to estimate – though maybe more tedious to report on in their details.
Collaborate more easily. The structure also makes it easier and faster for writers to collaborate on writing, reviewing and editing each other’s topics, again, because it’s quickly obvious what belongs (or is still missing) where.
Assume new tasks and responsibilities. Challenges for writers are learning a whole new range of tasks and responsibilities, from “chunking” subjects into topics and making sure there is one (main) topic for each subject to interfacing nicely with the topics of colleagues to peer-editing other people’s topics. On the other hand, most writers no longer have to double as layouters and publishers, since that role is usually in the hands of a few people.
Migrating legacy content. Another challenge is, of course, to migrate all existing contents into topics. However, this is a one-time effort, while the benefits of clearly structured topics keep paying off.
Benefits and challenges for companies
Of course, the benefits and challenges for writers affect the company as a whole. But there are additional effects to the company owning topic-based documentation.
Leverage corporate content. Cleanly structured (and tagged) content in topics is much easier to leverage as part of a corporate content strategy. (Did I mention this was a presentation for managers? Hence the verb “to leverage”…) After all, there are other teams who may well hold stakes in some documentation topics or parts of them:
- Product management or even Marketing may want to reuse parts of concept topics, such as use cases.
- Training could reuse procedural topics.
- Quickly searchable documentation can improve customer services – or any type of performance support your company may offer.
Make recruitment more efficient. Clearly structured, topic-based documentation will make it easier on a company to find and hire professional, qualified technical writers – and help new writers get up to speed faster.
Savings from topic-based authoring
Your mileage will vary, depending on your current deliverables, processes and tools. However, from the case studies I’ve seen around the web and at conferences, our numbers are not unusual. Savings are in hours for writers who apply topic-based authoring compared to their earlier efforts without TBA.
- Writing Release Notes as usual – saving 0%
- Writing Online Help, largely reusing Release Notes topics – saving 45-60%
- Writing new User Manuals, by reusing some topics from Release Notes or Online Help – savings unknown
- Updating existing User Manuals, by reusing Release Notes topics – saving 60-75%
Complementary information
To read more about measuring efforts and costs, see my previous posts about:
About topic-based authoring, I recommend these two books:
- Kurt Ament, Single Sourcing: Building Modular Documentation
- Gretchen Hargis, et al., Developing Quality Technical Information, chapter 8 “Organization”, pp. 215-244.
Your turn
Would these arguments convince your managers to support you in moving to topic-based authoring? What other arguments might it take? Should such an initiative to restructure documentation come from writers or managers? Please leave a comment.
Filed under: change management, content management, managing, metrics, single sourcing, topic-based authoring |
Kai's Tech Writing Blog 
I am currently in the process of getting funding for a TBA project, and my struggle has been to simplify the concept of XML/DITA/TBA enough for managers to understand it. For people who are not at all connected with producing documentation, it is hard to talk about it in general terms that a manager can understand, without them quickly losing interest. We have tried presenting the benefits (time savings, translation cost savings, single sourcing), but my manager still feels that we are presenting too many details. He is concerned about the audience (our CTO) losing interest. Do you have any suggestions?
Hi, Samia, you hit on a very important issue! I have felt like you for the longest time – and I must say: Your manager is probably right…! 🙂
What you describe sounds tricky though, because in my own experience, C-level managers DO care about saving time or money or generally “doing more with less” – more documentation with fewer writers, as it were… So could it be that you’re esentially headed in the right direction, but maybe the level of detail isn’t a good fit yet?
If that doesn’t help, try to find and address the pain points of your audience. What do they really care about because it makes or breaks their personal success? And can you speak to that somehow?
Maybe cost isn’t the top priority? Maybe quality and reliability are? (That’s not uncommon in regulated industries.) Will single sourcing help with quality control and consistency of your documentation?
In general, anything that you can do to ward off your CTO’s fears or to help her or him to be successful will recommend you and your project as your CTO’s ally.
Another thing to consider is the sheer amount of time and/or money that you’re asking for. We tech comm’ers don’t always have the best sense of what counts as a big figure. I’ve seen tech comm projects get shelved really quickly because they were asking for waaay too much money. And I’ve seen others vetted scrupulously by writers – only to be waved through because they were essentially asking for peanuts.
What’s an appropriate size to ask for is tricky and can change really quickly, but it’s often a decisive parameter that can make or break your project. So if your numbers aren’t palatable, can you roughly sketch out a meaningful project for approximately half – or twice the amount?
Hope this helps! 🙂
Thanks Kai! Yes, your comments are really helpful. I think we just need a few minor tweaks to our presentation, and it really isn’t very expensive from a corporate perspective. I think it will be an easy sell once we can get the message right. It is really easy to show how much money we will save on translation costs (take out DTP and exact match), and we have some good examples of time savings and greater efficiency. We have just been stuck in preliminary stages for (what feels like) a long time, and I am anxious to get us moving. I think we’re nearly there!