Structuring content – ASTC 2017

I’m attending the Technical Communicators Conference 2017, the annual conference of the Australian Society for Technical Communication (ASTC). This post is a live blog of a session at the conference. In other words, I’m writing as the presenter speaks. Any mistakes are mine, and all credit goes to the presenter.

Margaret Hassall presented a session called Structuring content – why, what, when, how, where. Margaret’s talk was a case study of the challenges her team has faced, and the techniques they’ve ysed, in putting structure around technical documentation.

Margaret talked about:

  • the tech writing team,
  • the development teams,
  • document and content types,
  • problems,
  • challenges and tools,
  • waterfall and agile, and
  • organisational restructures.

The teams

Margaret works for a large company, with about 15,000 employees around the world. It’s a tech-heavy company, using software to manage the business and provide services and products to customers. The tech writers create the user guides and reference docs for the apps. Five years ago, things were relatively simple. They had a team of five writers, and each writer would manage a particular release.

Then everything changed: delivery to far more channels, agile processes, changes to team reporting structures. The result was that developers needed to know a lot more, and the content held in people’s heads was lost. There were many more releases.

The tech writering team had to find new ways of doing things.

To measure the sophistication of their processes, the  team used the methodology recommended by Joanne Hackos: the information process maturity model. You assess your processes using the following scale, which moves from rudimentary through to sophisticated:

  1. initial
  2. managed
  3. defined
  4. quantitively managed
  5. optimising

Margaret discussed how the team placed themselves in the above scale initially (somewhere between levels 1 and 2), and worked to move themselves up the scale.

The problems

Challenges included:

  • Where to store documents, given the move to greater globalisation resulting from the company restructure.
  • How to help people find the information that had been created.
  • How to manage and communicate the team’s priorities, given the organisational change.

The team conducted a survey of the users and content – find out who uses what, and audit your information to find out where it’s created. Margaret recommends this as a very important thing to do. For example, you may find that too much information is stored in email, which makes it hard to find for people outside the immediate team (such as the tech writers). You may also find that people need help with versioning documents. Different groups owned the various documents. Different teams preferred different tools, though Margaret says this is one of the minor problems. You can create macros, for example, to convert convert from one tool to another.

People often don’t realise that their content is valuable to other teams. For example, if you’re a research and development company, you need to create a specific type of content, to qualify for an R&D tax concession. Sometimes people don’t think their processes are important, whereas the content may be invaluable for the R&D claim.

Tackling the problems

Margaret’s team started work putting structure around the content. She discussed the following aspects of the changes and processes they’re putting in place:

  • Using and promoting templates – their importance, and how to be flexible but not too flexible.
  • Helping other teams organise content, particularly in tools such as SharePoint.
  • Getting access to the tools that other teams use, such as task-management tools (like TFS) to get the information stored in those tools.
  • Moving from a content creation role to a content curator role.
  • Also moving towards documenting processes rather than applications.
  • And doing more technical work, such as automating the publishing process.
  • Creating new content types, like videos and webinars.
  • Merging into the same team as the trainers.

New directions the team is taking:

  • Consider changing the name of the role from “technical writer” to something else. They haven’t yet come up with a new name.
  • Manage the sharing of knowledge.
  • Talk to developers at the water coolers.
  • Create guidelines and templates for developers to use. These also include glossaries and guidelines on document types, tagging and metadata.
  • Act as content editors.
  • Automate where possible.

In summary, Margaret said that the technical writers need to be more “technical” than before. She listed the new competencies the writers need, and a focus on automation and single source.

Thanks to Margaret for a great narration of your ongoing journey towards content structure.

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 10 November 2017, in ASTC, technical writing and tagged , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: