In episode 120 of The Content Strategy Experts podcast, Gretyl Kinsey and Sarah O’Keefe discuss content ops stakeholders in risk management.

“Your regulatory environment for a single product could actually be different depending on where you’re selling it. You have to do things a certain way in Europe. You have to do things a certain way in the US.”

– Sarah O’Keefe

Related links:

• Content ops stakeholders: Localization (podcast)
  
• Content ops stakeholders: Tech stack managers (podcast)
  
• Content ops stakeholders: Executives (podcast, part 2)
  
• Content ops stakeholders: Executives (podcast, part 1)
  
• Content ops stakeholders: IT (podcast)
  
• Content ops stakeholders: Tech support (podcast)
  

Twitter handles:

• @sarahokeefe
  
• @gretylkinsey
  

Transcript:

Gretyl Kinsey:                   Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we continue our series on content stakeholders. This time focusing on risk management. Hello, and welcome everyone. I’m Gretyl Kinsey.

Sarah O’Keefe:                   And I’m Sarah O’Keefe. Hi.

GK:                   And we’re going to be talking about risk management as part of the content stakeholder group. So my first question to you is what is risk management and what role does it play at an organization?

SO:                   Well, I hate to say risk management is responsible for managing risk, but the risk management group typically is a legal adjacent group of some sort, and their responsibility is to figure out how to enable the company to avoid, let’s say unnecessary problems. When we’re talking about risk and risk management, usually we’re talking about products that are inherently dangerous if they are used incorrectly. So a medical device is a really good example, right? You can save a lot of lives using a medical device correctly, but if you use it incorrectly, some really bad stuff can happen. There are machines that have pinch points, or that you don’t want to stick your hand in certain places, or they use certain kinds of chemicals that are potentially dangerous. So what we’re typically talking about here is working on products that have health and safety implications, and because they have health and safety implications, there’s potentially product liability, or there are regulatory concerns, which is sort of a different aspect of the same thing.

SO:                   So if I don’t document my medical device properly, the regulatory authorities may come along and tell me I’m no longer allowed to sell that medical device, which from my point of view, as the maker is very, very bad. And or if I don’t provide the right information about the device or even design it properly, there could be people that get hurt. So there’s that risk, which obviously we don’t want people to get hurt. And additionally, from the company’s point of view, there are potentially financial implications if somebody gets hurt and then sues the company for not providing the right instructions or providing a poorly designed product.

GK:                   Yeah. So clearly risk management is one of the most, if not the most important stakeholders at your organization. And that’s why I wanted to talk about that. Because I do think that gets swept under the rug or forgotten about when it comes to content. So I wanted to talk a little bit more about how risk management relates specifically to the content. And I think you already started to go there a little bit by talking about how there are sometimes legal and regulatory requirements around what information has to be included in your product documentation, especially when it is a product that carries high risk.

SO:                   Right. So most of the people I think listening to this podcast, if you have risk management as a stakeholder, you probably know about it. It’s pretty unlikely that you’re operating in a company somewhere that has safety concerns and you’re not aware of it. If you make software, particularly if you make things like video games, then probably you have fewer concerns in risk management, but even there, if you think about video games, very often, there’s a notice at the very beginning that talks about flashing lights and the risk of seizure for people that are photosensitive. Or you might get, there’s apparently an infamous warning of some sort having to do with video controllers and people mashing it in certain ways and getting terrible blisters on their hands. So your risk is of course more limited if you’re doing software because you don’t have probably scary chemicals or you’re not dealing with medical devices that get maybe implanted in people’s bodies.

SO:                   However, so if you have a risk management concern because of your product, you probably know about it. And then it comes down to an interesting question of perhaps regulatory. So again, I’m saying medical devices a lot. Medical devices, pharmaceuticals, drugs are regulated. You have to meet certain standards for them. Those standards are different from one country or one region to the other. So that’s a concern.

SO:                   When we talk about machinery, it gets very interesting because in the US machinery for the most part is not really regulated. It’s more, you better do this properly or somebody’s going to get hurt, and then they will sue you. So the concern is legal exposure due to a product liability suit of some sort. In Europe, generally, or in the European Union, we have things like the machinery directive, which require you to do certain things with your documentation. Your regulatory environment for a single product could actually be different depending on where you’re selling it. You have to do things a certain way in Europe. You have to do things a certain way in the US. And interestingly, when you start thinking about global content strategy, very often, one of the things you want to do is try and find a way to put all of that together in a way that meets all of your regulatory requirements.

GK:                   Yeah. And one area that I’ve seen in terms of software, where there can sometimes be differences from one region or one country to another is with data security. And that’s one area that it maybe doesn’t have the same level of risk of injury or harm that you might see with medical devices or heavy equipment or chemicals. But it’s something that a lot of people have concerns about. So if you’re a software company and you are collecting people’s data as part of the way they use your software, if it may be part of the way that you’re delivering it to them, if you are delivering a lot of personalized content and they have a profile that you are managing their data, then there can be regulations around how that data has to be kept secure, how you’re allowed to use it, how you’re allowed to share it or not share it.

GK:                   And those requirements can be different depending on region as well. So if you’re a global company and you work in software, that might be one of the areas that you have to think about. Maybe it’s not so much about how you’re documenting that safety information, but it’s how you’re handling the way that people are accessing your content if there is a data security concern.

SO:                   Yeah. That’s a really good point. And so there’s that sort of internal issue of what are we capturing about our software users and what are the legal implications of that, especially in again, Europe and California, which sort of begs the question of how do you know whether somebody’s in Europe or California in the first place. And then additionally, the type of product that you’re making, if you make a software product that collects your customers, customers data, right? So then you’re going to have to provide some information about how to manage these issues, the data security issues downstream. So if I’m a software vendor and I make a CRM, a customer relationship management system, then by definition, I’m collecting lots of data about people. And you need to make sure as the product designer and the content creator that your best practices can form, or at least you tell your end users, right, the people typing into the CRM, these are the implications of all this data you’re collecting.

GK:                   Absolutely. And I want to use that to segue into something that I have seen both with software and other types of companies, which is that your risk management group may actually create their own content around those exact types of things. So I wanted to get into some examples of the types of information that they may produce alongside of just the regular product documentation. So I’ve typically seen a lot of internal facing content come out of risk management departments. You might see things like guidelines, frequently asked questions, things like that around your safety information, your legal documentation requirements, so that people who are writing your content and documenting your products know what’s required, what has to go in there and how to make sure it’s consistent.

GK:                   You might see things like instructions or training materials for the risk management team, so that as they onboard new people, everybody is aware of all of the requirements. I’ve also seen some risk management departments be the ones in charge of creating the contracts that the company uses. And if there are again security concerns there, making sure that that’s included in those contracts. So all of that internal facing content is something that might be under the responsibility of your risk management department.

SO:                   Yeah. And I think additional to that, you see risk management very much involved again with products that are possibly hazardous, they will be involved with safety messages, those messages that say things like this content is under pressure so do these kinds of things, or always make sure that the second thing is set before you undo the first thing. Or make sure that the power is turned off so that nobody gets electrocuted when they go in and do whatever it is they’re trying to do. Another thing I’ve seen in addition to all the scenarios you’re describing, it’s not common, but the risk management team sometimes will be responsible for actually reading and reviewing the external facing content to make sure that there’s nothing in there that is potentially problematic. So they’re reviewing maybe from a compliance point of view, maybe from a legal exposure point of view, they want to make sure that the product documentation doesn’t over promise.

GK:                   Yeah. And I’ve definitely seen risk management departments catch things as part of that review that should not have necessarily been customer facing. So I think that’s a really important piece to include. If you are an organization that has a review process, make sure that your risk management group is a part of that so that nothing like that falls through the cracks.

SO:                   Right. And so then if we turn our attention to the content creation process and thinking about safety and legal information, which then results in risk management or risk reduction, what are some of the things that you see there? What kinds of content, techniques do we have that can help us with this?

GK:                   Well, one thing that I think it’s really important to ensure is that all of this safety information, legal information, anything that has to be there for compliance is consistent across the entire enterprise. And I think it’s really important to put some systems and tools in place that can make sure that happens, because if you have duplicated safety warnings and you have this information not being maintained in the same place, and then it gets out of date and you’ve got inaccurate and inconsistent pieces of information floating around, you’ve got some conflicting safety warnings floating around, that can lead to some real harm for the people who are using your products. And then that can get your company into legal trouble as we talked about earlier. So one thing that we always like to encourage people to do is have a single source of truth for your safety information.

GK:                   Typically, when people talk about content reuse, talk about content single-sourcing, safety information, legal information, regulatory requirements is the starting point for most people because that’s the information that it is the most important to have consistent. And one thing that can really help with that is getting into a structured content ecosystem. Something that can facilitate that type of reuse that can allow you to write an important safety warning one time, and then have it be reused across all of the documents where it needs to appear, have it update automatically any time that safety warning needs to change, because we’ve seen some situations where a company would have hundreds of separate copies of the same safety warning, and how do you keep up with all of that and make sure it’s accurate. You really can’t. So single-sourcing and reusing your safety information is a really big and important way to make sure that it’s accurate every time it gets published and distributed to your end users.

SO:                   Right. And then adding to that, you want all those safety warnings to be consistent when you translate, which,

GK:                   Yes.

SO:                   You’re going to take that one that you refactor, that’s the contents under pressure warning, and you’re going to translate it one time. So that then in your localized content, that warning will appear consistently as well. We’ve had some infamous cases where our customers looked at translations and were upset because the translations weren’t consistent, why’d they use three different words here. And then you go back and look at the English, the source, and it was inconsistent in the English. So it’s not too surprising that the translated version wasn’t consistent. So if you can get that source content refactored and cleaned up and aligned, then you can turn your attention to the localization and that downstream process to make sure that stuff gets cleaned up.

GK:                   Definitely. So if your organization has limited resources for content development, how can they ensure that the risk management requirements for the content are met?

SO:                   Well, I would say that this is not the most interesting content necessarily, but it’s really important, right? Because again, if you don’t get this right, your company could face some crushing legal liabilities, or even be blocked from selling a particular product. So that is a high priority kind of item. Do this or we are out of business. So from that point of view, it tends to be a pretty easy sell into the organization. And there’s a huge payoff, because as you said, when you have hundreds of copies of a single warning, which should be consistent and mostly it is, but not quite, there’s just a huge payoff to getting that thing reviewed, approved, made consistent one time. So the risk management team goes over it and says, okay, this is the language we want you to use. Great. Now we stash it in our content warehouse and we use it everywhere.

SO:                   And I, as a content creator, don’t have to worry too much. I just have to make sure that I use that approved set of warnings and cautions in my content consistently. And I don’t have to think about it anymore. I can go think more carefully about how I’m going to write that procedure or how I’m going to write that contextual information. And the safety warnings become essentially an asset that I have available to me, right?

GK:                   Yeah, exactly. And if that doesn’t convince your executives, if you show them, here’s how much cost and time we’re going to save on people writing and maintaining these multiple copies, translating these multiple copies. If we get it down to one, we’re going to save this much time and cost. If that’s not enough to convince your management to prioritize all of this risk management type of content, then another thing that might help is just providing some data around these safety related lawsuits. Here’s how much you stand to lose if this information gets us in trouble because it’s not reusable and not consistent.

SO:                   Yeah. I mean, you visualize a warning that says, stay back two meters and then you have the same warning, except it says, stay back three meters from whatever the thing is. Now, should it be two meters or three meters? I don’t know. But the main point is that you don’t want to give them two different numbers, right, for,

GK:                   Exactly.

SO:                   The same warning. You have to be consistent because otherwise somebody’s going to stand at two meters, get injured and sue, or they’ll be too far away. And so you have to get it right. I will say within that, as you said, the structured content gives you some opportunities to automate a lot of this stuff. So that from a content creation point of view, we can just do what we need to and move on. There’s a lot of value associated with getting the risk management, getting the safety content right. But it’s, and it’s bad to get it wrong, but it’s dreary. It’s just so not interesting. So what we want to do, I think is automate it as much as possible because then it’s going to be more correct, which is helpful. And also I’m going to spend less time on it as a writer, which is helpful because I don’t want to rewrite the warnings about high pressure and things getting under your skin and chemical exposure and whatever else it may be. I just want to know that they’re right.

GK:                   Exactly. So, is there any other advice that you would offer around risk management content for companies who are thinking about this for the first time, or maybe have a new regulatory requirement that they’re up against?

SO:                   Yeah, I think I would start with the question of what is your exposure, right? If you make heavy machinery, your exposure is significant. If you make video games, right, your exposure is probably less significant with the exception of some of these photosensitive issues. If you make mobile games that go on your phone, that seems pretty minimal except for don’t play while you’re driving.

SO:                   So you want to kind of look at your product and your product’s profile in terms of what the risks are, what the safety issues are. And then you want to look at where you’re selling your product because the regulatory compliance and legal issues are different in every region. So that’s something to worry about. And I think you probably have a risk management team or legal counsel somewhere in your organization, and it’s probably worth talking to them about this because they’re the experts and they’re again, a stakeholder in your content. And we want to make sure that this particular aspect is taken care of because the implications of getting it wrong can be really, really significant both to your customers in terms of them getting hurt or injured or worse and to the company.

GK:                   Well, thank you so much, Sarah, for this fantastic discussion.

SO:                   Thank you.

GK:                   And thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post Content ops stakeholders: Risk management (podcast) appeared first on Scriptorium.