Making risk management work (4): The tools you need

This post is part of the Content Is The Web risk management series.

This post explains the tools and tables you’ll use to manage risks properly. It follows on from earlier posts about the framework and conversations that risk management uses.

The short version:

Each risk is documented in a separate report, and each piece of content you work on needs a register of all its risks. So long as you’re having the right conversations and following the framework, this is basic admin.
Continue reading

Making risk management work (2): Holding conversations

This post is part of the Content Is The Web risk management series.

You know the roles and definitions that risk management is based on, so now we turn to how to talk about risks with your risk reporters. After that, the next post introduces the tools you need to manage them.

(Risk reporters used to be stakeholders and points of sign-off. If that’s news to you, let me repeat the link to How risk management works (1) – Roles and definitions.)

It’s your decision to talk to risk reporters one-by-one, or all together as a group. It’s most important, especially at first, that you do actually talk. The old days of sending drafts and receiving tracked changes or free-form comments are over. Continue reading

Making risk management work (1): Roles and definitions

This post is part of the Content Is The Web risk management series.

So you already know that your sign-off process slows things down and makes it difficult to work with others. But you still need some way to hear everyone who should have a say, and to make sure that your web content is fit for purpose before you publish it.

Here’s something I picked up from an employer that could never guarantee 100% safety to everyone – the armed forces. It’s a risk management system, and it lets you gather more detailed information than you get from a typical sign-off process, while keeping you in control of your content. Continue reading

Sign-off is like road works

This post is part of the Content Is The Web risk management series.

I’ve already written about how sign-off processes make it hard to collaborate properly. Now we turn to another reason sign-off sucks: It’s slow and frustrating, like roadworks.

You might typically have 3-6 people sitting between your work and publication. They’re called things like ‘legal’ and ‘marketing’, but they’re better depicted like this:

Stop/go signs

Continue reading

One thing we all know about workflow: No-one knows enough about what’s going on

It takes a team of people with a range of skills and knowledge to create our web content. The way we work together and organise the tasks that go into creating content is, in sum, “workflow”. Approvals, stakeholder engagement, work-tracking and getting feedback on draft content are all aspects of workflow.

Problem is, there’s a standard form of workflow – the sign-off process – that makes it difficult to collaborate properly with all the people who contribute to making great web content. Continue reading

Leave minor changes out of your full content review process

Editing content? It makes sense to review major changes as thoroughly as new content, and to have a shorter, easier process for minor changes. The hard part is defining each type of change.

You might be able to publish minor content changes without any approval, and just give the content owner an FYI. But it’s more common in large organisations that the minor process will cut out everything except the content owner’s sign-off. Either way frees up time that you’d otherwise spend getting little content fixes rubber-stamped.

Keep it simple: Only have two categories of change

“Major” and “minor” changes aren’t always easy to tell apart. Strong definitions help reduce the grey area between them. Whatever you do, don’t try to “clarify” things with more categories. All that does is create more grey areas and two new problems: spending more time grading content changes than actually working on them; and the thankless work of building multiple review processes. This quickly turns into ranking your stakeholders by importance, and Pandora herself couldn’t build a box strong enough to contain that political shit-storm.

So, stick with only two processes and reduce confusion by defining each change type as best you can.

Defining major and minor changes

More than one aspect of a change can make it major. List things that would make a change major: any one of them alone is enough to send your content through the major review process.

Changing the target audience is major

Even minor-looking changes can alter who you’re writing for, which changes the content’s strategic aim. Anything that touches the strategic level is a major content change.

Every piece of content should have a clearly defined target audience. Check whether your new version of the content still fits this audience.

Example: Returning a faulty Shiny Widget
Say you have a webpage about your company’s finest product, the Shiny Widget. The H1 is “Shiny Widget” and the page is all about it, but there’s nothing saying what people should do if their Shiny Widget breaks during the warranty period. You quickly draft a sentence or two, which seems minor.

But when you check who the page is for, you see that the audience is “Potential customers who haven’t got a Shiny Widget yet”. Your new content isn’t for that audience. Either you’ve spotted a strategic gap – there’s no content for people who have already bought a Shiny Widget – which needs a larger solution, or you’ve drafted words for the wrong page.

Changes to the content’s purpose are major

As well as its audience, the purpose of every piece of content needs to be defined and documented. This is another part of the content’s strategic intent, so any change to it is major.

If you’re looking at a dedicated sales page for the Shiny Widget and trying to fit in after-sales service, this isn’t a minor change.

Adding or removing an idea or concept is major

If you’re not just re-wording existing information but changing the content’s “informational load”, it’s a major change. This isn’t about the word count – it could be as little as half a sentence – but about what the content “knows”.

Examples include:

  • altering the Shiny Widget’s description to include a new weight
  • adding or removing one of the ways you can return a faulty Shiny Widget
  • putting in a new way to order a Shiny Widget.

All of these can be very light changes in terms of words, but they’re all new concepts that you want your reviewers to see, and fact-check.

Change in word count can be major

After every other condition, this is a catch-all. List both a numerical and a percentage change. If the word count crosses either threshold in either direction, it’s a major change.

Lots of minor changes over time can equal a major change. Compare your new content’s word count with the last version that went through full approvals. Don’t let minor changes stack up unchecked.

Typo fixes are minor

Adding a missing full stop? Fixing a spelling mistake? Just do it.

Stylistic changes can be minor

If you’re just fixing copy to meet your style guide or brand tone of voice, that’s minor. Your approvers and stakeholders should already know about these things so they don’t need to be involved again.

Filling a design gap can be minor

It’s not pretty, but you might “need some words to fill a gap”. If you plug it by basically repeating something that’s already on the page, that’s a minor content change. (You probably have a problem with your page design, though.)

Make sure all your reviewers know what counts as minor

Let your reviewers help define major and minor changes. You want a category of change that they’re not worried by, so they need a say. Without their buy-in this will never work. Be clear that the major-minor split will save time without hiding things from them.

If you’re not sure, treat a change as major

When you can’t be certain that a change is minor, the best policy is to keep your reviewers in the loop and treat it as major. It can be a good idea to ask whether they’d like to be included next time a similar change goes through – they might just count themselves out.

Reduce risk

Content reviews are risk management. By favouring too much review over too little, you’re at to the “cautious” end of the risk appetite continuum. Bosses don’t often like people at the “reckless” end of the scale.

Build trust

You’re better leaning towards consulting too often – being open about the things you’re changing and why – than appearing to hide changes from people who deserve a say.

(If you have stakeholders who don’t deserve a say, or who withhold approval for unnecessary reasons, taking your work underground will only make things worse between now and when you tackle these problems properly.)

The more often you work with a stakeholder the better they get to know you and your work, and vice versa. This helps builds trust and makes it easier to work together. It’s much better than appearing to be the uncollaborative sneak who doesn’t know when to ask for help.

All the guidelines, definitions and documented processes in the world can’t beat a trusting relationship between you and your stakeholders or reviewers.

===

This post is 1,073 words long with an average reading grade of 8.3.