Scriptorium

In episode 111 of The Content Strategy Experts podcast, Sarah O’Keefe and Rahel Bailie of Content, Seriously discuss the rise of content ops.

“If you want a better user experience and more customer loyalty, you need accurate content.”

– Rahel Bailie

Related posts:

Twitter handles:

Transcript:

Sarah O’Keefe:                   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. My name is Sarah O’Keefe. And I’m your host today. In this episode, we discussed the rise of ContentOps with Rahel Bailie of Content, Seriously. Rahel, welcome. I’m so happy to have you here on the podcast.

Rahel Bailie:                   Well, I’m delighted to be here on the podcast too. I thought you’d never ask.

SO:                   And here we are, finally. So yeah. I mean, I know who you are, but for our listeners, tell us a little bit about yourself and about Content, Seriously, and what you’re doing here.

RB:                   I wish I had done such a professional job as you did on introducing. So I’ve been doing ContentOps since probably 15 years ago. I’ve found references in my old slide decks to content operations, except nobody knew what it was. And that kind of went in one ear and out the other. So for many years, I’ve been under the rubric of content strategy, have been advocating for content operations to do things more efficiently. I was a consultant from 2002 until shortly after I came to the UK. And now that I’ve got my citizenship, I went back to consulting. It seems to suit me the best. And I worked in all areas, from technical writing and very technical writing to guidance writing, to marketing writing over the years. And once I went into consulting, then I turned my talents to diagnosing in client situations and finding more efficient ways for them to produce their content.

SO:                   So how do you define ContentOps? I mean, it’s been out there as you said for a while, but I think you’ve got one of the sort of cleaner definitions of what this is. So what’s your definition of ContentOps?

RB:                   So I’ve been refining it and refining it. And right now, it’s refined to the statement that ContentOps is a set of principles. And I think that’s important. It’s principles that we use to optimize content production and to leverage content as business assets to meet business objectives. It’s all about efficiency.

SO:                   And so what are some of the basic things that would drive an organization towards ContentOps?

RB:                   So I have a theory that there are six kind of meta business drivers and everything else is a subset of that. So if you want to reach one of these business goals, you’re going to need some sort of operating model that is slick and clean and efficient to be able to do that. So out of those six, there’s the one like reduced time to market, while reducing time to market means producing content in a better, faster way, expanding your reach. So as soon as you go into other countries, now you have localization issues. And if you don’t want to break the bank with your translation, your language service provider on translation costs, you need to get your source content in order, risk management. So compliance, regulatory, all those things.

RB:                   If you don’t want to get sued or shut down or whatever is the case in your industry, you want to have that all together, you need a good operating model. The next one would be a better user experience. And if you want better user experience and more customer loyalty and so on, you need accurate content. So you need content that comes from the same place. So you’re not duplicating it. And then having to maintain all those duplicate copies, which comes under content operations. And there’s a couple others, but you get the idea that anything that you do that involves having a content component, you want to manage your content really well because otherwise you’re going to be lost.

SO:                   So it’s almost like maturity, right? It’s a mature content development process as opposed to this, just throw some stuff up against the wall and then copy and paste it over here and then copy and paste it again. And did I mention copy and paste?

RB:                   Anything that says copy and paste, or I track it in a spreadsheet. Exactly, right? So I’ve seen places that had over 50 spreadsheets and the guy who was supposed to be the manager and all he did was manage spreadsheets. There was another company that was doing a retail product and online so that they’re a retail chain and they’re out of business now, not surprisingly. 99 spreadsheets to manage their content. It was ridiculous. So this idea of being able to do things more efficiently. So can you imagine on the code side having, I don’t know, a hundred developers sitting around, they’re all writing their own spaghetti code and they’re in their copying and pasting it all over again and forgetting to change the version number and all those things that happen.

RB:                   Well, that’s what’s still happening in content in a lot of places. And I get told by people, oh, can you go and see what cool Company A is doing for content? And I’ll say, well, I just happened to speak to someone from there last week or last month or whatever, and they’re coming to me because it’s a show. So even though they’re out there, we have our book and we have our method and we have our whatever. It doesn’t apply to content.

SO:                   Yeah. People come to me a lot and say things like, what CMS should I buy? Or what CMS has the biggest market share? Who should we pick? And what they want me to tell them is, oh, this one is doing really well in the market. And depending on my mood of the day, my default answer when they say what CMS has the biggest market share, my default answer is actually Excel.

RB:                   Yes. Because as Jeff Eaton said in a discussion I had with him recently, technically, that’s a headless CMS because it’s a different rendering engine. If you put it into PowerPoint, PowerPoint is the CMS.

SO:                   We don’t use bad words like PowerPoint on this show.

RB:                   No. You told about all the four letter words I could not use, but PowerPoint has more than four letters.

SO:                   I’m sorry. I thought PowerPoint was implied. The session you’re talking about was a webcast on headless CMS that you did with Jeff Eaton. And we will add that to the show notes so that people can find it. I wanted to ask you why now? And because you’re absolutely right, you’ve been talking about ContentOps for a while, and now it seems as though this concept or this buzzword or whatever is gaining traction. So why? What changed in the market? Why is the market ready now to talk about ContentOps?

RB:                   Okay. I’m going to answer this in two parts and the first part is very brief. And if you go back to the early 2000s, who had content problems? So I remember the Cisco had a guy go in and they said they had over a million pages and it was complete mess because everything was just pages done individually and thrown up onto the web. And then they had this million pages and they had to have someone come in and organize them and put together a taxonomy and whatever. So unless you were a huge SAP, Cisco, whatever, you didn’t have a content operations problem, really, because you had a 10 page website, maybe. Now, there’s a company called Gather Content, who said that when they were first getting into this business, they were creating this piece of software where people could kind of perk their content until the website was built.

RB:                   And they built their software to handle, 20 to 200 pages. And next thing, within a few years, they’re being asked to support 20,000 pages and people aren’t using it as a temporary stopgap anymore. So they had to redo their whole code base to make this more robust. So when you look at that kind of, oh, we went from 20 pages to 200 to 20,000 and 200,000, you can see how that complexity, well, the scale is increased greatly. The complexity, because you’ve got, take the iPhone, well, just because there’s an iPhone, what’s the latest one? 14 or something? That doesn’t mean you can ditch all the support material for a 13, 12, 11, 10, nine, eight. You have to still have it out there. So how do you do all this multichannel publishing and omnichannel, and now we’ve got conversation design content and all sorts of content genres that didn’t exist.

RB:                   And they all have to work together. And one of the things I do with my students at the university is, we have a course called content and complex environments. And I create eight teams, three people each, eight teams, 24 students, great. They all go and produce a little piece of content towards a fictional product. And then I bring them back together and they have to coordinate everything. And they say it’s so hard. And it’s not the creating the content. It’s the coordinating with seven other teams. So if you take this and you multiply that out into any content environment, you get complexity and you get the need to have a tight operating model. You can’t take the operating model for software development and apply it to content. It’s not the same thing. You can’t take data ops and apply it to ContentOps. So you have to come up with your own efficient way of working.

RB:                   And that’s why it’s now because we’ve reached that, is that peak dirt, they used to say? We’ve hit that pinnacle of like, oh my gosh, my stuff is everywhere. We are breaking all the rules and whatever those rules may be in your particular industry, regulatory rules, or we racked up content debt. We don’t have the quality. We are not checking accuracy. We don’t have time. We don’t have time. We don’t have time. And now they’re saying, okay, well, we have to get more efficient than this. This copy and paste stuff has got to go.

SO:                   So looking back on this, when you look at where we are right now with ContentOps versus some of the stuff that you were looking at a while back, 10 or 15 years ago, when you look back, has anything changed? I mean, I know your definition has changed a little in that you’ve refined it or tightened it or whatever, but has ContentOps itself changed over the past 10, 15 years?

RB:                   Yes. In a couple of ways. So one is around tooling. If you look back 15 years ago, we barely had any tooling, production grade tooling. So right now, even today, there are lots of companies that they throw Microsoft Word or Google Docs at, and then expect them to go and do content production the way you would keep pace with the agile team. But here are some basic tools that are really meant for casual business use and do your best with them. And we know that, that doesn’t work anymore, but now we have some tools where we can say, actually, you have this, or you have this, you’ve got a Gather Content. You have a CCMS, you’ve got a PIM. You’ve got all these different things that are out there that are starting to come up, that you could use for a better operating model.

RB:                   And we have workflow modules that you could apply to things so that you’re not tracking things in a spreadsheet. So that’s changed. But also I think the locus of control has changed because now we have product owners and product managers and they often have the budget. And so how do you have to go about implementing is different because you have to keep up with what they’re doing and you have to convince them that content deserves its own operating model. And that’s a hard sell. It’s a really hard sell right now.

SO:                   So what’s next? When you look forward at the next, well, I’m not going to ask for 15 years because that’s ludicrous, but how about three to five? If you look into the future in the short-term, medium-term, whatever that is, what do you think is next? What’s coming down the pipe in ContentOps that’ll be interesting and fun and exciting to work on?

RB:                   Well, that’s a loaded question. When they show those curves where they show the early adopters and it’s starting to kind of, it’s at the bottom of the curve on the left and then there’s this line up and then at the other end going down, it’s the late adopters. So I think we’re so far at the beginning that for most organizations, nothing will change. There’s still going to be limping along. But I think what’s going to start happening soon is that there will be things that happen and when I say things that happen, it could be that somebody got sued. Somebody missed a deadline and got fired, those kinds of things that, somebody lost their funding because something didn’t happen on time. So there will be something that tips them over into the edge where they go, ugh, we should have listened.

RB:                   And then as they move around the industry, they will take their experience with them and start implementing things differently. And I say this because I had a former product manager where I used to work and he’s off doing his own thing now. And he called me and said, “I want a guy like Chris.” Chris was the content strategist who worked for me. And he said, I want him because our product is content and we need to manage it in a different way. We have to be really good about how we manage our content, it has to be done really well. And there are lots of moving parts and what would I call that person and where would I find one of them? Right. So here’s somebody who lived through this non successful experience with me.

RB:                   But when he went into his own business, decided he wasn’t going to make that happen again, right? He was going to do it right. So he’s looking for the right kind of person, the right shape of person to come in and do their content operations. And I just spoke with another fellow who runs… He’s one of co-founders of career.pm. So it’s for product managers. He got so excited and said, oh my gosh, product managers need to know about this. And so we’re trying to put together this deck on what the benefit will be for product managers if they will pay attention to ContentOps and we came to certain conclusions, some kind of sad conclusions, which was that, for them, content is like somebody showing up with a baby and the baby’s ready to be put into the product.

RB:                   And you say, well, it takes all this time to make a baby. And it’s like, well, that’s none of our business. Once you have a baby, then we care. And so you’ve got that piece as well where they say, well, that’s nothing to do with us in the product, that has to do whoever’s responsible for the content team. And when you start going up the chain, there’s one of those weird matrix responsibility things, and nobody’s responsible for content. It might go up to head of marketing or head of communications. They don’t know about ContentOps. They might know about ContentOps from a marketing perspective, which is a very different rhythm and a very different beast than product content. They don’t even know that some of these processes and tools and tensions exist. They think it’s a three step process, you write, you copy and paste, put it in CMS and QA it, done.

RB:                   And so when you start going into these things and I spent a long time within a government department and I did a kind of almost a time in motions study, but I used the concept of lean services and the seven types of waste. And we just mapped out the way they’re doing it now and the way they could do it. And we came up with a 75% savings. It was quite remarkable. And that was using conservative estimates. If it hadn’t been me, if it had been anyone else, they probably wouldn’t have gone in and gotten that same result because the other folks that they would bring in, know about the editorial side. So they would say things like, well, run everything through Hemingway before you write it. And then we know that it’s going to confirm to the style guide.

RB:                   And that’s about the extent of what they know and that’s about it. But when you say, well, we should hook up an authoring system to a taxonomy management tool. And then yeah. We’ll need to have some sort of digital asset management, but maybe the CMS has it. They don’t even think about those things or the implications of what happens when you have multimedia content and you need to have transcripts and captions and in multiple languages. And they just like, okay, too much, too much, go talk to the techies. And the techies don’t know because they’re not content people, they don’t know this stuff. That becomes the ping pong ball. And I think that some of these things will start to get understood, especially when there’s a, I hate the term, but the burning platform. When they find themselves in a burning platform, then they’re going to be looking for that vehicle to take them off the burning platform. And that may be some sort of vehicle connected to an operating model for content.

SO:                   Okay. Well, I mean, that seems like an almost hopeful note. So I think we should leave it there on the hopeful note of your software, your platform may be burning, but you will get off of it successfully.

RB:                   Well, I think I will say that there are people like you, like me, there’s a couple of handfuls of people that I can think of, not a lot of us, but go out and get the expertise, bring in somebody, hire in that expertise to help you and then listen to them.

SO:                   I really have nothing to add to that other than you should listen to Rahel. So Rahel, thank you. I’m going to wrap it there. Thank you so much for being here-

RB:                   My pleasure.

SO:                   And for participating on this and with that, 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 The rise of content ops (podcast) appeared first on Scriptorium.

In episode 110 of The Content Strategy Experts podcast, Alan Pringle and Sarah O’Keefe continue their discussion about executives as important stakeholders in your content operations.

“You need to understand how decisions in your organization are made and where the real power is.”

– Sarah O’Keefe

Related posts:

Twitter handles:

Transcript:

Alan Pringle:                   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. This is part two of a two-part podcast.

AP:                   I’m Alan Pringle. In this episode, Sarah O’Keefe and I continue our discussion about executives as important stakeholders in your content operations. In the previous episode we talked about the importance of business needs. In this episode, we talk about how to effectively communicate with executives. Now, we’ve talked about these business needs, business requirements and how they really affect- basically, I don’t want to put thoughts in the heads of executives but what we talked about is kind of how they think in general, basically from my experience.

AP:                   I think it’s also worth discussing how to communicate with them. For example, let’s go back to tools for a minute. We’ve already said, don’t talk about all the bells and whistles and the features of the tools, they don’t care about that. I do think one thing they would care about is that you were following the correct company process to select your tools. You are working with your procurement department, you were working with your IT group, you were working with information security folks. Those are also other stakeholders in any kind of project, and a content ops project is no exception. So you need to be sure that you are following the protocols that your company has established for assessing tools, and that you communicate that you are doing that with the executive champion of your project.

Sarah O’Keefe:                   Yeah. And that’s an interesting one because as an executive, what they are truly paid to do is to assess risk. What is the risk of taking this action? What is the risk of not taking this action? Should I spend this money? What are the implications if I don’t? And what you’re talking about in terms of the tools assessment, and I will say quite frankly, when I hear from a client, we have to go to the enterprise architecture board, that never makes me happy. Because their job, and this is legit, is to minimize the number of tools in the company.

AP:                   Exactly.

SO:                   Right? Because the more you have, the more systems you have, the more complicated everything gets and the more expensive it gets. And so the EAB is responsible for saying, “Well, we have these 17 tools already. Why are you telling us you need a specialized tool?”

SO:                   You need a super special CMS, but we already have three of them. Why can’t you use SharePoint? And then we cry. By the way, crying doesn’t work. Don’t cry. No, never cry. But the executive’s job is to test your argument that no, we are super special and we need a super special set of tools and here’s why. And then they have to make the decision that that argument that you’re making will get better content ops, which will give you all these cool business things, is worth the risk and the cost of introducing another tool or another set of tools or whatever it is that you’re asking for. So it’s not personal. They don’t hate you. They don’t hate your favorite tool, but they don’t like bringing in more complexity and nearly always, that’s what we’re arguing for. We need more stuff. We need another stack because we can’t do this in the generic business tools that you have right now.

AP:                   Yeah. And those conversations usually are not a one and done sort of thing. It usually takes a lot of time and I hate to use the word education, but I do think there is some of that going on when you’re having these discussions, because you have to explain, like you said, why this particular tool, which may seem like a match to something that already exists, why it is critical for your content ops to have this particular tool.

SO:                   I have found over the years, that it can be helpful to make the analogy to software developers or product developers if it’s hardware, especially with an engineering, whether software or hardware, manufacturing kind of executive. Essentially your software developers have a bunch of specialized tools to manage code. We are asking for the equivalent for content, right? So it’s not that we’re special and esoteric or anything like that. It’s just that there’s a certain set of tools that help us and that make us more efficient and in which we can do better work just as you have in your software development or in manufacturing, you have CAD systems and you have product lifecycle management, PLM systems, those kinds of things. So I think it’s helpful to just align this with other professional level things that are needed in order to do these jobs well. And of course we swore we wouldn’t talk about tools and here we are. As always.

AP:                   Yeah, well, let’s shift focus a little bit because politics are always part of a project. That is pretty much the rule of corporate life. At least that’s what I’ve seen in my now, whatever 25 years now, shudder, at Scriptorium. Politics are inevitable. And I think that is especially true when you have executives involved and you have to be very sensitive to them. Let’s wrap up this discussion talking about the importance of politics and why you need to pay attention to those optics.

SO:                   So two things. We talk about requirements and constraints, right? A requirement is like the system has to do X and a constraint is something like, and also it has to connect to this system, or it must not do this, or it has to run on Linux or something. But a constraint, sometimes there are personal preferences and I really wish I was making this up. We had a project where we went in. They were like, “Oh, and don’t use purple.” Okay. Well sure. But why? “Well, senior exec so and so really hates purple. If you show them anything with purple in it, they will reject the project.” Okay. Well guess what? That’s a constraint.

AP:                   Yeah.

SO:                   Absolutely ridiculous, but a constraint. So pay attention to your personal preferences slash constraints of the people that are approving stuff. If they hate PowerPoint and only want a video presentation, or they only want PowerPoint and they don’t want to hear from you, or they only want a white paper making the argument. Okay. Well deliver that, right? So that’s not really politics. That’s more like, how do you pitch to your decision maker? On the political side, there’s so many aspects to this, but basically you need to understand in your organization how decisions are made and where the real power is. So for example, if you have a CEO who’s your nominal decision maker, but on technical questions, they always defer to the CTO. They’re going to let the CTO decide. Then the CTO is your actual decision maker. And that’s who you need to pitch to. That’s who you need to tailor your solution to, to make sure that you’re giving them the information that they need in order to make the decision in the format that they want, et cetera.

SO:                   So that’s one issue, who’s the actual decision maker and that may be different from who’s on the org chart or you’ve been told, “Oh, so and so is making the decision.” And then you find out that your director of XYZ has a senior technical something who they lean on. And if you can’t convince that person, you’re done.

AP:                   Yeah. You’re sunk.

SO:                   Yeah. But they were sitting in the back of the room not talking and you didn’t notice them. And you used blue, which they hate and you didn’t know about because you didn’t pay any attention to them. So that part of it’s really important. And I’m using trivial, ridiculous examples but I will tell you, I have seen these at least once.

AP:                   Oh yeah. Absolutely.

SO:                   Usually it’s something more serious than color preferences, but maybe you built a pitch and the person you’re pitching to is color blind and you didn’t think about it. And now you’ve got an ineffective presentation because, well first of all, never do that, but you weren’t paying attention.

AP:                   You really have to be sure you’re attuned to what is going on. And that really takes some, frankly, detective work and really good observational skills on your part.

SO:                   Yeah. And it’s one of the hardest challenges that we have as consultants, right? Because we don’t have all that history with the organization. So we tend to lean on the people inside the organization that we’re working with and say, “Well, what do you know about this person?”

AP:                   Exactly.

SO:                   And ask those questions. Politically, very often these projects cross organizational boundaries. So for example, if we’re trying to integrate marketing, learning, learning, training, and technical content, then we almost certainly are dealing with two or three C-level executives, right? The marketing executive, the chief marketing officer, maybe there’s a chief learning officer, or maybe that falls under the CIO, or maybe that’s under the chief people person or HR and technical content usually but not always, under some sort of engineering function. Well who makes the decision, right? Those three executives get in a room to talk about this project.

SO:                   Are they going to do it? Are they going to push back because they don’t like each other? Who pays for it? Who owns the project? Who gets the glory? If those three execs work together well and are a team at the C-level, then things will be great. But what’s far more common is that they all have their own area of responsibility. I’m not saying fiefdom.

AP:                   I was thinking it though.

SO:                   Yeah, sorry. So they each have their little fiefdoms, which they rule with an iron fist and a project where you are trying to introduce some sort of enterprise strategy, right? Across those three organizations or more, I mean easily more, but we’ll start with those three. It threatens them because they are giving up control. Oh, we want to introduce an enterprise level taxonomy, an enterprise level terminology. Well, are you telling me that somebody else is going to tell my people how to write? Well, actually, yes because you see, we need all three of those organizations to use the same terminology and the same metadata so that when this content goes to your website or out for delivery, the people consuming it can use it in a consistent way, right? They don’t care about your empire.

AP:                   So here we are thinking that content silos are the major problem. I think it’s more the fortified castles of each one of these groups. That’s the bigger problem.

SO:                   Okay. I swear I’m not going to reference Genghis Khan.

AP:                   We might want to wrap up now. I think we’ve worn this analogy out. Yes.

SO:                   Yeah. But it is a point, I mean in all seriousness as a chief marketing officer, my job is marketing, right? And all the responsibilities that go with that. So improving engagement among customers and potential customers, outreach, getting new leads, new customers, new this, new that, right? If I’m techcomm, my job is to enable use of the product. So at up at the C-level, we do in fact have different sets of priorities and trying to bring those people into a project that must cross over is really, really difficult because they reasonably are prioritizing what their people need, not always what the overall organization needs. And now I’m going to pick on the CEO, because it’s the job of the CEO to say to these C-level people, “I want you to make this work, work together, make it happen, prioritize the cross department or cross-functional content ops, content strategy and not your individual responsibilities and priorities.”`

AP:                   That’s a really good point. And I think we can end on that somewhat hopeful note. So thank you very much, Sarah.

SO:                   Thank you.

AP:                   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: Executives (podcast, part 2) appeared first on Scriptorium.

In episode 109 of The Content Strategy Experts podcast, Alan Pringle and Sarah O’Keefe return to the occasional series about stakeholders and content operations projects. In this episode, they talk about executives as important stakeholders in your content operations.

“An executive wants to know how a tool is going to solve business problems and support company goals. They don’t care about the widgets and what they do. They want to know about business problems being solved.”

– Alan Pringle

Related posts:

Twitter handles: 

Transcript:

Alan Pringle:                   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 talk about executives as an important stakeholder in your content operations. This is part one of a two-part podcast.

AP:                   Hey, I am Alan Pringle.

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

AP:                   This podcast is part of a series about stakeholders in content operations, content ops projects. In the previous episode, we talked about the IT department being a key stakeholder. Today, we are going to shift our focus and talk about the role, or roles, really, I should probably say, that executives play in content operations.

SO:                   So execs probably don’t play a day-to-day role in content ops, with a notable exception of, if your organization is a company that produces content as a product, right? But most of the companies and clients that we work with, content is a component of the product but not the primary product. And in that case, the executives probably are not going to reach all the way down into the day-to-day content ops issues, but they have huge influence.

AP:                   Right. They are participating. It’s like an umbrella kind of over everything you’re doing that you may not notice all the time, but it’s most definitely there.

SO:                   Yeah. And first and most tremendously, obviously, executives in a business are where you get funding, right? So even if they’re not involved in the day-to-day, your probably C-level, your CIO, CTO, maybe the CMO, the chief marketing officer, that’s the person who’s going to sign off and get you funding to build out content ops, refine content ops, do what you need to do to get the investment that you need in your systems.

AP:                   Right. And it’s not just about funding. I mean, that’s a huge part of it, don’t get me wrong, because they are really the ones that are going to open up those purse strings. They also usually have a really good, big-picture view of how this slice, this content ops slice, this effort, is going to support the company’s goals. They have usually a much better handle on those short, mid, and long-term goals for the entire company, and can make sure that your efforts are going to fall in line and help with those things.

SO:                   Yeah, and that’s a really good point. And we’ve said this before. If you’re not sure how you’re going to get funding for your effort, one of the smartest things you can do is figure out what priorities or what goals does your particular funding executive have. Have they been told to grow the business? Have they been told to cut costs? Have they been told to expand into new markets? What’s on their horizon, and how can you align what you’re doing in content ops with what they are prioritizing for the year or the next couple of years?

AP:                   Exactly. You kind of need to talk their talk, more or less, or at least speak in terms that they, that’s part of what their job is, whether it’s the growth that you talked about or whatever else.

SO:                   Right. And that is, of course, highly unlikely, unfortunately for me, to be technology, right? They don’t want to talk, they don’t want to hear about tools. They don’t want to hear about shiny tools. That is not going to cut it. I am happy to talk with you, Alan, or anybody else in the world for hours, and hours, and hours about shiny tools, but that’s not how you get your executives to give you money.

AP:                   It’s the worst thing you can do, based on my experience, at least what I’ve observed.

SO:                   Yeah. It’ll work if you have a C-level exec who is also a geek, a nerd, and really wants to talk tools, maybe.

AP:                   Yeah.

SO:                   But those are actually pretty few and far between because that’s not how you get to the C-level.

AP:                   Yeah. It’s more of a situation where, yeah, we know that tools are your wheelhouse, good on you, and there’s a place for that. But that may not be the place for these particular discussions, because really, based on what we’ve seen, an executive wants to know how a tool’s going to solve business problems, support company goals and whatever else. They don’t care about the widgets and what they do. They want to know about business problems being solved, and how it’s going to fix whatever kinds of goals. And I know there’s tons of goals. We should probably kind of lay those out right now, that an executive would be particularly interested in hearing about.

SO:                   Right. So having said “not the tools,” I lean really heavily on a hierarchy of business needs. I got this from Constellation Research, but there’s numerous versions of this out there. So if you think of a pyramid, and you sort of start at the bottom, the infamous Maslow pyramid with food and shelter at the bottom and self-actualization at the top, in business, the food and water layer, right, is compliance.

AP:                   Yeah.

SO:                   If you have regulatory compliance, legal requirements, that is the bottom of your pyramid, because if you don’t do that, you will be out of business. So that’s-

AP:                   You don’t exist.

SO:                   Then you don’t exist, right? So that’s the foundation. And then in order, going up, so you have compliance, cost avoidance, revenue growth, which is kind of the flip side of cost avoidance, competitive advantage, and then branding.

AP:                   Yep. And really, you don’t do one without the one that preceded it.

SO:                   Yeah.

AP:                   So yeah, that makes a great deal of sense to me. But I do want to kind of throw in here, I’m going to back up and talk about cost avoidance. It can be very easy to fall into this trap, talking about how a tool or process is going to improve efficiency. We’re going to gain 20% on this or whatever. You’ve got to be really careful, if you are spinning efficiency as the primary argument for a content ops, or really any kind of project, because are you setting yourself up for a situation where executives are going to kind of expect those kinds of efficiency gains year after year? Because at some point, you’re going to hit a plateau where there are no more efficiency gains, really, to be had. So you got to be really careful, even if it is true you’re going to have efficiency gains, you may not want to spin it as the primary reason to do a project.

SO:                   Yeah. It’s almost like, I mean, if you think about compliance, the bottom, you need to do compliance, but you don’t need to, once you get to the point where you are compliant or compliant enough, which sounds really bad, right? But if you’re in compliance with the regulations, you don’t then say, “Oh, we need to be super compliant, or double compliant, or keep… “. No.

SO:                   And so with cost avoidance, it’s kind of the same thing. We want to get to a point where we are operating efficiently, and we have our costs managed, and we understand what those costs are. And so for example, localization, as you globalize and add more languages, can very easily be a runaway cost problem if you don’t have an efficient content operation.

AP:                   Right.

SO:                   So if your content ops are terrible, every time you localize, all that inefficiency gets just multiplied across every language. So what we want to say is, “Look, if we do it this way, it will be efficient and scalable, and we’ll be able to do what we need to do. And then we can move forward, and do some more interesting and exciting things like the next step, which is revenue growth,” right? How can content and content ops contribute to revenue growth? And maybe the answer to that is, well, we can add more languages for less money because we’re efficient. And so therefore, you, the CTO, you, the CMO, you, the organization, can go into more markets, because more markets become feasible from an investment point of view, because we don’t have to put millions and millions of dollars into localizing, because our source or our starting point is terrible. Right?

AP:                   Right. I mean, when you have a repeatable process that you can adapt for new languages, it cuts how long it takes to get into a market. And we have even had C-level folks on some of our past projects say, “I don’t care about all these bells and whistles and whatever, what I care about is getting into X country and getting this done in a very short window of time, not a three month, not a six month lag. I want to get in there simultaneously, or just a few weeks after the primary language content was released, to get that product into these different markets as quickly as possible.”

SO:                   Right. And I mean, that’s, canonically, that’s a revenue growth argument. Because what you’re saying is, when we go to market in country one, let’s say in the US with English only, if it takes us six months to localize, well, then we can’t go into any other markets for six months, or non-English speaking markets for six months. If we can get all the localization done in a few, in two months instead of six, or a few weeks, or a few days, well, then you start to get revenue from those other markets, which means you are going to get your money sooner, which is a very compelling argument and leads into competitive advantage, right?

AP:                   Right.

SO:                   Because if my product, when I release my product on day one, and on day 15 I release in non-English markets, and you release your product also on day one, but your non-English markets don’t happen until day 60-

AP:                   Right.

SO:                   Well, that’s an advantage to me, right? I’m more nimble, more flexible. I’m in Germany with German language content, which says something to my customers in Germany about how much I care about, well, it’s perceived as, “You care about us.”

AP:                   Right.

SO:                   On the inside, it may very well be, “Well, we just can’t do it. And we care very much about our German customers, but we can’t get to German language because, again, bad content ops.”

AP:                   But, and this goes to the final step in this pyramid, and that is branding. All that perception that you just mentioned goes directly into the branding angle, because if I were at a company and we were getting stuff out weeks after it went to the primary country where the content was originally released, and we were getting that product out in a few weeks thereafter, I would be crowing about that and making sure that my branding reflected the fact that, yeah, we’re getting out there giving you what you need as soon as possible. That’s a big deal, and marketing should probably reflect that.

SO:                   Yeah. I mean, we’re both focusing a lot on localization and on global markets, which I think is probably the most common justification for better content ops, right?

AP:                   Right.

SO:                   Because you can see how easy it is for every one of these steps in the pyramid to talk about what that means in a global company. But it’s also worth looking at this just from a single language point of view. Obviously, you have to do compliance. I mean, if you’re in the US, the number of industries where compliance is required is fairly limited, but you’ve got to do it. You don’t want to spend money that you don’t have to spend. That’s the cost avoidance piece. If your content is better, if your content is well-designed, and if it is easy to search and accessible on your website, those are all factors that contribute to people understanding how to use your product and using it successfully, which means they’re not going to return it, or they will be less likely to return it. Some enormous percentage of product returns are basically not “The product is defective or broken,” but actually, “I can’t figure out how to use it.”

AP:                   And in addition to returns, you’re going to have fewer people pinging your various support channels. And that, in turn, is going to help you with your bottom line and competitive advantage.

SO:                   Right, because support is stupidly expensive.

AP:                   Exactly.

SO:                   So you can see how you can tie the general business operations and the general business needs into, “If I do content ops well, and if I do these things with my content, then these are the business results you’re going to see. If our content looks better, sounds better, feels better than the content that our competitors are producing, then we will gain an advantage there,” right? You gain a competitive advantage, you gain a branding advantage, and all of these kinds of things. So if you’re looking at content ops and you’re trying to get investment for content ops, my advice is to take this five-step, or five-layer, hierarchy of needs. Think about where you are, right?

AP:                   Yep.

SO:                   “We’re not in compliance, and the FDA is threatening to shut us down” is a really good reason to invest in content ops.

AP:                   That’s a really good point, and I think we can end on that. So thank you very much, Sarah.

AP:                   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: Executives (podcast, part 1) appeared first on Scriptorium.

In episode 108 of The Content Strategy Experts podcast, Alan Pringle and Gretyl Kinsey kick off an occasional series about stakeholders and content operations projects. In this episode, they talk about IT groups as an important stakeholder in your content operations.

“The IT department can be such a great ally on a content ops project. IT folks are generally very good at spotting redundancies and inefficiencies. They’re going to be the ones to help whittle that redundancy down.”

– Alan Pringle

Related posts:

Twitter handles: 

Featured image: nanastudio © 123RF.com

Transcript:

Alan Pringle:                   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 talk about IT groups as an important stakeholder in your content operations. Hi, I’m Alan Pringle.

Gretyl Kinsey:                   And I’m Gretyl Kinsey.

AP:                   In this episode, we’re going to kick off an occasional series about stakeholders and content operations projects. And yes, even though content is the primary umbrella, primary objective on a content operations project, there’s still many stakeholders from all across an organization that are going to be involved, so it’s not just about the content creators and the people authoring content. What are some of the other ways that stakeholders come into play, Gretyl, on a project?

GK:                   Well, a lot of times there will be the most important stakeholder, which is your executive champion, who is in charge of the money and the resources to actually get your project approved and get it started, so that’s always someone that we make very definite sure to talk to when we get involved in content operations. You might also have developers or engineers who are working on the product itself. And of course, as we’re going to be talking about today, you might have IT, information technology, a department that’s in charge of managing your tools and your processes. So all of these other groups, even if they don’t directly create content themselves, they definitely have an important stake in it, and they need to be part of the decision making processes.

AP:                   I agree. It essentially takes a village to get one of these projects done, so it’s really good to have an understanding of other people’s responsibilities in the organization and to get their viewpoints and feedback to be sure that your content ops project is going to be successful.

GK:                   Absolutely. So as Alan said, we want to start this series by focusing on information technology or IT departments. And that’s because they are significant stakeholders in content projects. We’ve had a lot of times in the past with projects that Scriptorium has been involved in where it was actually the IT department who came to us first and who initiated the entire content strategy overhaul.

AP:                   Absolutely. And that’s an important thing to note. A lot of people may assume, just because it’s a content project, that we’re going to be contacted by the people authoring that content. And in multiple cases, that has not been the case at all. We have had people contact us who were much more into the tools and tool management and information technology side of a company who didn’t create content at all, yet it was still part of their responsibility because they’re the ones overseeing the tool chains and some of the processes for those groups, content creating groups.

AP:                   And speaking of those content creating groups, I think it is fair to say in our years of doing this, Gretyl, that we have seen a lot of content folks who had some gripes about IT groups. And then the IT people had their own stories about the content creating people. So there’s a lot of that going on, and we could spend how many podcasts on that topic, but I don’t think it’s that interesting. What we want to focus on instead is really how the IT department can be such a great ally on a content ops project. And they really have some skills and viewpoints and access that are absolutely necessary to get things running and to work well.

AP:                   And one of the first things that I can think of in regard to that general skillset is that IT folks are generally very good at spotting redundancies and inefficiencies. And that kind of makes sense because if they are managing the infrastructure of tools, they’re going to be very sensitive about, for example, if you have multiple tools doing the same exact thing within an organization, especially after say a merger, where you’ve got two different companies coming together, and you’re going to have all these layers of tools doing the same thing. They’re going to be the ones to help whittle that repetition, that redundancy down.

GK:                   Yeah, of course. I know one of the earliest projects that I was involved in that had IT coming to us as the primary stakeholder who was interested had actually spotted not only kind of these redundancies or inefficiencies in what tools they had, but also in how people were using them. So they kind of had a little bit more insight into how content creators were kind of doing a lot of manual processes with these tools that they had in place that could’ve been something more automated, how they were spending a lot of time on these things that really they knew of much more efficient ways to handle them just by nature of being in IT and seeing other departments kind of handle those processes more efficiently. So that’s definitely a good thing that they kind of have this broader view of what tools should be in place, what the kind of overlaps are, if there are any, and how they can get those out so that you could have a much more efficient way of using the tools that you have in place.

GK:                   And I think that kind of leads into another strength of IT departments, which is that they tend to have a sort of more broad, or company wide, or enterprise level view of the organization. And that’s just because of the way that they manage tools across departments. They can really kind of have that bigger picture of how they’re being used.

AP:                   Absolutely. And that perspective is sort of like when you bring in a consultant like us. We bring in a third party view because we’re not so close to it. We can give objective advice on how things are set up, how they’re running. And the IT group can do something very similar. They’re not in there day to day using the tools, authoring, or whatever. They’re a step back, so they’ve got more of a bird’s eye view, and that can be very, very helpful, like you mentioned, in spotting these redundancies.

AP:                   I think another thing worth pointing out is these folks usually have programming chops. And they have the skillsets to customize things, and they’re not scared to do so. A lot of times, to get maximum use out of your content strategy plan to be sure it’s working the best, it may require some very particular configuration, connections between tools, et cetera. And when you’ve got an IT group that’s savvy at those things, that is a huge, huge benefit to you and your content project.

GK:                   Absolutely. I really can’t think of a case that I’ve ever seen where one single tool did everything that an organization needed out of the box. And I think that’s true the more tools that you get in your tool chain, you are going to need some sort of custom configuration most of the time. And so when you’ve got an IT department who is really involved in the overall content strategy, they can help you see what exactly are the customizations that you’re going to need. They can be a really valuable asset to your content department in making sure that those customizations are done. And so again, that’s why it’s just really important to involve them from the outset before you really even get into the process of choosing what those tools are going to be. They can help you make the decisions about what customization might be involved based on what you choose.

AP:                   And I think it’s worth acknowledging that making those customizations does cost money. And when you’re doing your content strategy planing for how you want your content ops to go, looking at return on investment is going to be a big part of that assessment, so getting that feedback and input for what it’s going to cost to stand up these customizations, these configurations, is very important because you need that information to figure out essentially how long it’s going to take you with improved efficiency or whatever, to basically recoup those costs. So yes, customization is a great thing, but you need to have the clear understanding fairly early on about the kind of cost projections to get that work done and how you’re going to get that money back and then make more gains beyond that to make it worth everyone’s while to do that customization.

GK:                   Absolutely.

AP:                   We’ve kind of already touched on this, but let’s take a little time to talk about the kind of functions that an IT group is going to handle, contribute to, in content operations projects, or even the content strategy planning that precedes it. What are some of the things that come to your mind, Gretyl?

GK:                   So one of the first ones that comes to mind right off the bat based on what we just talked about is enterprise architecture. And that’s because like we said before, IT has that kind of big picture, bird’s eye view of all of the tool chains across the organization. So when it comes to developing your information architecture for content, particularly at the enterprise level, thinking about not just one type of content and one department, but all of your content across an organization, IT can really be helpful in figuring out what your strategy is going to be for that enterprise level information architecture.

AP:                   And speaking of enterprise, the more organizations move into the content as a service model, where basically it’s less about delivering a PDF, or a help set, or a marketing slick, or whatever, it’s more about giving the end user whatever kind of content they want in the specific format they want it, when they want it. That really requires a lot of connectivity. It requires a lot of understanding of the entire tool chain and how everything is connected within the enterprise. And the more we move to that content as a service CaaS model, the more critical I think IT is going to become in these sorts of projects.

GK:                   I agree. I think we’re seeing a lot more demand for Content as a Service for custom, personalized delivery for on-demand content. So I agree absolutely that IT is going to be playing I think an even bigger role as more of these kinds of projects are undertaken.

AP:                   Something else that I think that really falls into their wheelhouse is to help with evaluating new tools that you’re going to need to develop, manage, and distribute your content. If you’re doing, for example, a new content management system, you’re probably going to set up some proofs of concept with a vendor or two and get that set up and running. And it would behoove you to get some input from IT about how those tools are set up and how efficient and how well they work, also to do security checks. I think a lot of tools now are more in the cloud. Less and less, we’re seeing companies deploy tools on premise on their own servers. Instead, they use cloud based tools. Even so, security is still a concern. And that is something that they need to be part of. How you stand those tools up, how good the security is, all those kinds of things that you want to look at in a proof of concept, that definitely needs the input from your IT people.

GK:                   Yes, absolutely. And as consultants, we’ve been involved in that process of the demonstrations and the kind of questioning of the vendors with regard to choosing what tools you want. And there have been some of those times where IT was heavily involved. They helped come up with a lot of the information, a lot of the feedback, a lot of the things that were asked of those vendors during that demonstration and kind of testing process. And then we have had other projects where sometimes tools were chosen, and then later the company came back and said, “We should’ve had IT involved and we didn’t, and that was a mistake because we’re seeing that we might’ve made a wrong choice here. We didn’t evaluate this one particular aspect that was really important.” So definitely when you are looking at tool options, especially if you’re choosing more than one tool, so if you’re looking at maybe a CCMS and an LMS, that you would really want to have IT involved to help make those decisions and make sure that everything is going to work together as you intended to.

AP:                   Right. And once again, I go back to the whole enterprise level viewpoint, the connectivity among these systems. You cannot have blinders on and pick a tool that suits just your purpose. It has to fit in the bigger ecosystem you have for tools. Otherwise, everybody’s going to have their own little tool communities, and that’s just a mess that you don’t want, and frankly, an IT department probably is not going to tolerate very well.

GK:                   Yeah, exactly. And that’s a really great point because it leads us to the next kind of thing on our list of how IT can help with a content project, which is that they are really good at making those connections among disparate departmental content and data sources. So if you have a situation where you’ve got, let’s say, technical content, training content, marketing content, and all that needs to be connected and you don’t really have the infrastructure for that, IT is going to be your number one resource to make sure that can happen.

AP:                   Right. And I think one other thing that kind of puts a bow around all this is content governance. And I know you’ve talked a lot about that, so I’m going to kind of let you take that on because that’s been a topic I know that you’ve written about and talked about on the podcast previously.

GK:                   Yeah, sure. So content governance is what happens when you need to have someone in charge of overseeing all of your content processes and the changes to those processes over time, the evolution of those processes. And again, this is a place where it’s very important to have IT involved. A lot of times when we have had companies that we’ve worked with putting a governance strategy in place, it’s either been driven by IT or they’ve made sure to have someone from IT be part of whatever team of resources is in charge of content governance. And it all cuts back to what we’ve been saying, it’s because they have that viewpoint from the enterprise level. They’re the ones who are going to really know and understand how all of the parts of your content tool chain work with the content lifecycle. So when it comes to maintaining and governing and improving your processes, it’s imperative to have IT involved.

AP:                   Absolutely. And I think one of the last topics that I want to touch on before we wrap up are some final thoughts in regard to content ops projects, considerations that really feed into IT and having their participation. And the first one that I think really comes up is authoring tools. One thing that I have really learned over the past few years is when it comes to authoring content, it is very much not a one size fits all situation for the tools used to create content. There are absolutely legitimate reasons to have different types of tools for authoring content, even if they feed into the same repository or management system for the content.

AP:                   And a good example of that is sometimes you have part-time contributors on content projects, such as product engineers. Once in a while, they’ll go in and add some feedback, put in just a little bit of information. They do not want to deal with the overhead of a super duper professional strength authoring tool. They want to get in and get out very quickly with minimal overhead, minimal time spent on learning a tool. Whereas the people who are day-to-day creating content and that’s their full-time job, they’re going to want a lot more control, a lot more features, a lot more bells and whistles to get the content done and do the things they need to do that are a little more complex, for example, in regard to reuse, and get that done correctly, whereas the people who are part-time contributors probably don’t care as much about that because it’s being handled by the full-time content creators. So there is absolutely a valid reason to have different authoring tools. And it’s probably better not to force people’s hand to use just one tool because of some kind of perceived redundancy there.

GK:                   Yeah. And one thing I’ve seen IT help do with this in particular also is even if you do have the same authoring tool, there may be features that you can turn on or off for certain kinds of users. And so you could have different levels or different user roles, and IT is kind of in charge of managing which people are your power users, your ones who need all of the bells and whistles and all of the controls, which ones are maybe only in a review capacity, but not a content creation capacity, so they might need some different controls, which ones are just those kind of part-time occasional subject matter expert contributors. And that’s where it can again really be helpful to have IT involved to make sure that, whether they are using different tools altogether, or kind of different variations or access levels of the same tool, that everybody can do what they need and kind of not be forced into a bunch of features and things that they don’t need.

AP:                   Absolutely. And surprise, surprise, I think the last point we’re going to make is that a lot of times, very niche, very particular content tools may be required to get the best return on an investment for your project, like we talked about a little bit earlier. But you still have to balance the cost of those niche tools and configuring them and making any customizations against the overall cost of even just implementing and then maintaining those very specific tools down the road. So there’s got to be some ROI calculations done, and this is where IT I think will be very, very helpful in figuring out that return on investment.

GK:                   Yeah. Before you ever decide what your tools are going to be, IT can help you say, “Yes, this is going to get you everything you want, but it’s going to involve X many dollars or X much time for maintaining these customizations that are going to be involved for training people on how to use them,” really helping you think of all the different aspects that are going to be involved in using that tool. And they might be able to recommend something that gets you, let’s say only 90% of the way there instead of 100%, but you’re going to save so much cost for things like customizations and maintenance that maybe it balances that out. So it’s really helpful to have that perspective before you make your tool decisions.

AP:                   And that’s great advice and observation there, Gretyl. And I think we’re going to wrap up, so thank you very much.

GK:                   Thank you.

AP:                   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: IT (podcast) appeared first on Scriptorium.

In episode 107 of The Content Strategy Experts podcast, Bill Swallow and Gretyl Kinsey are back for another episode in our Content strategy pitfalls series. They talk about what can have happen when you lack a unified content strategy.

“One way to get funding in place is to start the conversation among different groups. Get these groups together and start talking about what their ultimate goals are with their content strategy and their content operations. That way you can have multiple voices coming together and asking for a larger pool of money that can be shared.”

– Bill Swallow

Related posts:

Twitter handles: 

Featured image: chrischips © 123RF.com

Transcript:

Bill Swallow:                   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 look at another content strategy pitfall, what can have happen when you lack a unified content strategy? Hi, everybody. I’m Bill Swallow.

Gretyl Kinsey:                   And I’m Gretyl Kinsey.

BS:                   So, before we jump into talking about what can happen when you lack a unified content strategy, we should probably start with explaining exactly what a unified content strategy is.

GK:                   Yeah. So, if you’ve listened to any of our podcasts before, looked at any information on Scriptorium’s blog, you might have also seen us refer to this as enterprise content strategy. So, what we mean by enterprise or unified content strategy is a plan for managing all of your content processes across the organization. And a lot of times that involves bringing all of your different content producing groups into alignment with each other.

BS:                   And as you can imagine, if everyone is working against a different strategy and doing different things, a lot of bad things can happen. One thing that we see right out of the gate when an organization does not have a unified content strategy, is that there are a lot of inconsistencies throughout the entire content chain, from authoring the content all the way through to the customer experience on the final destination of that content.

GK:                   Yeah, absolutely. A lot of times this happens, because not everybody in the organization places the same amount of value on content. I know one example that I’ve seen of this might be something like, an executive sees a lot of value from something like the marketing content, because that’s directly making sales. But they don’t realize maybe the importance or the value that other kinds of content like your technical documentation, your training modules, maybe your legal materials might have. So, those groups maybe don’t get as much funding, as many resources, as much invested into them. And then you end up with this inconsistency, with this lack of cohesion among the different content producing groups, just because there wasn’t really value placed on content as a whole.

BS:                   And we also can see this within even what we consider a traditional content group. So, for technical documentation, a lot of times you will have user focused guides and user focused content, and you will also have deep technical content, perhaps API references and so forth. And oftentimes, we even see several different strategies being used for these various sub-components of what we would refer to as the umbrella of technical documentation. And even in those cases, you can start seeing a lot of dissonance between how the content is being authored, how it’s being produced, and how it’s being received.

GK:                   Yeah, no matter whether you have these subgroups that you’re talking about or your larger content producing departments. Another issue that we see is that these different groups may come up with different content strategies separately. When you’ve got all of these different ideas and these different ways of work trying to come together for the first time, you can have a lot of issues like change resistance. You can have egos coming in and you can have a lot of debate over what approach is the best approach. And so, that’s why, whenever we talk about a unified content strategy, it’s oftentimes easier to work on it from that perspective from the start, rather than trying to bring together a whole bunch of separate content strategies from different groups.

BS:                   And a lot of these inconsistencies and a lot of these mismatches that you might see as you try to combine two different strategies into one, could range from how people work when they author, it could be what tools they’re using and whether they’re even compatible together with other groups. It could be the tone and voice of the content that’s coming through and that there’s a stark difference between the two, and there’s no way to easily glue them together without it sounding completely bizarre to someone who’s reading it.

GK:                   Yeah, absolutely. And I think that’s an important point, because when you start having those inconsistencies, you reflect outward in the content to where they’re going to be affecting the way that somebody might use that content. If whether you are a customer who is trying to decide whether to buy a product or you’ve already bought your product, you’re trying to figure out how to use it. If the content is not consistent, if some of these issues from the way it’s been created are spilling over into the user experience, then that’s going to have a negative impact on your company. And so, that’s why I think what we said up front about the value of content is so important and you have to really think about that from all different angles.

BS:                   Right. And a lot of times any of these changes are going to come really with a significant cost. And a lot of times we look at the dollar signs or the price tag on the tools involved in being able to swap tools and migrate content over into a new system. But sometimes that’s not even the largest cost we’re talking about. If there are workflow changes that need to happen within a company, that usually means not only changing what that process looks like, but training everybody up on using it correctly. It probably involves a completely different way of authoring into some fashion. So, whether they are using different tools to author, there are different ways of going about producing that content.

BS:                   If the tone and voice needs to come to alignment, a lot of stuff needs to be rewritten. If there’s localization involved, then anything that has been translated previously is no longer a leveragable asset, in which case you’re starting from scratch with retranslating everything. So, it’s really important when you are defining your content strategies, that you take a look around and make sure that you’re not operating in a silo and potentially magnifying the cost of unification later.

GK:                   Yeah, absolutely. And one thing that you mentioned that got me thinking about another pitfall when it comes to that cost was you mentioned tools and process changes. And I think one pitfall that I’ve seen a lot of companies fall into is they make decisions about their tools or their process changes and purchase new tools without consulting everyone who might be affected by that decision. So, for example, let’s say that you have got an LMS at your company and you need to upgrade, and you only consult people in training and e-learning who use the LMS. And you don’t talk to other content groups who may share content, who may need to use some of the training materials as part of technical documentation, as part of marketing content, for example. And then when you purchase your new LMS, it affects those other groups and there’s that spillover.

GK:                   And we see this happen all the time. We see it happen with component content management systems. We see it happen with localization, where these kinds of tool decisions are made without really taking into account the unified content strategy and the effects. And I think when we’ve got those kinds of content silos, that’s where it’s more likely to happen because you don’t really think outside of your particular group.

BS:                   To that point, if one of the key factors in moving toward a unified content strategy is to be able to intelligently reuse content rather than copying and pasting, or what have you, the tools are really going to make or break that particular aspect of your content strategy. Because if one group is authoring in one particular tool that has a very specific file format or some kind of binary format, it is going to be near impossible to be able to get that content out and reusable as a single chunk of content. A lot of times it will either need to be copy and pasted or re-keyed or something to get it into another system to be able to use it. And that completely defeats the purpose of reuse.

GK:                   Yeah, absolutely. And I think this really speaks to why whenever, at Scriptorium, we come in and help companies with their content strategy is we often say tools should be the last thing you do. You need to come up with all of your goals, all of your specifications, all of the reasons why you’re buying that tool in the first place before you start looking at options. Because what happens when you make those decisions in the early part of that process is you don’t think of all the different factors. And then you end up either in a situation where you’re locked into using a tool that doesn’t really work for you or to get out of it. It’s going to be like Bill said, really expensive. There’s a lot of costs involved with these kinds of tools. So, rather than making an expensive mistake, it’s always better to take more time upfront, to work on the strategy itself and really understand what it is you’re looking to get out of those tools before you buy them.

BS:                   And with every strategy comes one particular item that is often overlooked when putting a content strategy together, and that’s content governance.

GK:                   Absolutely.

BS:                   And if everyone is doing different things with different tools and different ways and using different processes and different quality control checks, it is going to be very difficult to get any kind of overarching governance in place to be able to make sure that everyone is working as they should be throughout this process. The governance is going to be rather wide in scope. And the more differences you have between different teams working together, the more difficult it’s going to be, to be able to govern all the aspects of content creation across the enterprise.

GK:                   Yeah. I thought it was really interesting that you mentioned how governance is something that people don’t consider enough. I also have seen it be treated as an afterthought, when really it should be one of the most important parts of your content strategy. And I think when we have a situation where there’s a unified content strategy and that’s the goal, then people tend to consider governance as a greater part of it. But you’re right, Bill, that when we’ve got a situation where there are all of these different silos, all of these different tools and they don’t fit together into one streamlined content set of processes, then governance is just going to be herding cats. It’s going to be wrangling all of this mess that you’ve got, instead of truly moving your strategy in a better direction for the whole enterprise.

BS:                   Right. I mean, the governance angle really is speaking to a lot of the other pitfalls that we talked about. If there are multiple different tools in place, it’s very difficult to govern how those tools should work and at what point in the process that tool should have a handoff and what that quality check should look like. If you have many, many, many different strategies in place, regardless of whether you’re using the same tool or not, it’s very difficult to get those quality checks and get those points defined as to where you do certain reviews, where you do certain checks and balances. It will just exacerbate the problem of not being able to produce content that looks like it came from one organization with one voice, with one intent to its audience.

GK:                   Definitely. So, I want to close out by talking about one issue that’s at the root of all of these pitfalls, which is that oftentimes when we see this lack of unified content strategy, it tends to come down to a lack of funding or resources, or maybe unequal funding across different departments. And a lot of times that’s outside of their control. So, I want to talk about what companies can do to account for that limitation and how you can avoid some of those pitfalls, even if you’re dealing with a lack of funding or resources.

BS:                   So, one way to get this funding in place is to start that conversation among different groups, to talk to different groups that may have a different content strategy that is underway or that they’re using, or that they’re thinking about. Getting these groups to come together and start talking about what their ultimate goals are with their content strategy, with their content operations. And start pulling together those ideas, and being able to look at the tools that they’re using, for example, or that they plan to use in their new content operations and start pulling that together and making sure they’re compatible, if not identical. And that way you can have multiple voices coming together and asking for a larger pool of money that can be shared, rather than individual groups getting their own little pocket of cash to work with.

GK:                   Yeah, I think that’s absolutely critical, to make sure that you have that communication across departments. Another idea that I’ll suggest that might help, if you know that you’re going to be limited on funding, you know that you’re going to be limited on budget. At least one thing that you can do for now is once you’ve done what Bill has suggested, you’ve maybe gone to some other departments, you’ve talked about your content needs, start seeking out an executive champion. So, even if you can’t get the money immediately, even if you know it’s going to take time, the sooner that you can start planting that idea in someone’s head about why content is valuable, why it’s going to help to eventually get that funding in place, what it’s going to do for the organization, then the better your chances are of actually securing that.

GK:                   And one really, really solid way to do that is by gathering some metrics. So, what information can you actually provide to the executives about how much money that you are losing right now with inefficient or inconsistent content processes and how much you’ll save by fixing those? One thing that you might even consider doing is taking what limited funding you do have and conducting some sort of a pilot project or a study to just show here is what we’re thinking with regard to content strategy. We’ve talked it over with other groups, they want to buy into this too. And here is just a little bit of proof that we think it’s going to work. And if you can show some of that evidence, then I think that really helps to prove that value of content and maybe start to have the folks at the top who have the cash take it more seriously.

BS:                   Yeah. Showing that return on investment is critical, especially to gain an executive sponsor. Another thing to look at is not necessarily the cost savings that you have by working together and doing these things in unison, but it’s also looking at opening marketing or opening market opportunities for your organization. So, if you have been hindered by the way you work from entering into new business markets, or being able to broaden an offering to an existing business market, and your thoughts of having a unified content strategy can get you there, that return on investment will be much greater than the savings you’ll get from streamlining existing processes.

GK:                   Absolutely. And don’t forget to account for time as part of your savings as well, whether that is things like time to market, whether it’s time saved in your actual content workflow. Just remember to take into account all the other factors that can go toward the idea of return on investment aside from just strictly the cost savings.

BS:                   And I think that’s a good place to close it.

GK:                   Yeah. So, thank you so much.

BS:                   Yes, thank you all. 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 strategy pitfalls: lacking a unified content strategy (podcast) appeared first on Scriptorium.

In episode 106 of The Content Strategy Experts podcast, Gretyl Kinsey and Bob Johnson of Intuitive talk about accessibility and the Darwin Information Typing Architecture

“If you’re doing it right, accessibility doesn’t look any different than what you’re doing day to day. You’re just adding accessibility considerations when you author your content.”

– Bob Johnson

Related posts: 

Twitter handles: 

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 talk about accessibility and the Darwin Information Typing Architecture with special guest Bob Johnson of Intuitive. Hello and welcome everyone. I’m Gretyl Kinsey.

Bob Johnson:                    And I’m Bob Johnson.

GK:                   And I am so happy that you are a guest on our podcast today. So, would you just start off by telling us a little bit about yourself and your experience with DITA and accessibility?

BJ:                    Sure. I actually have routes in component content management that go back before DITA. I worked for a web CMS vendor that published a web CMS that was component based. And we implemented Author-it, which is a component based CMS and authoring tool primarily for technical content. We eventually moved to a DITA publish, which solved some problems for us. And since then, I’ve worked with a number of companies, both on the authoring side and the publishing side. I’ve managed CCMS acquisitions, I’ve managed DITA transitions for companies in the medical device sphere, in software, and in medical reference conThe web CMS vendor is also where I got my experience with accessibility. We wanted to sell to government customers and so we needed to be able to make section 508 compliance statements. And so, I had to study up. Later on, I worked for a company that had been acquired by Oracle. Oracle takes a rather different approach to accessibility than a lot of companies. Where other companies centralize their accessibility practice, Oracle makes each business unit responsible. And so, I took the responsibility for helping this acquisition implement accessibility in its content. When I went looking for documentation about accessibility and DITA , I didn’t find anything.

BJ:                    So, I sat down with the web content accessibility guidelines and developed a matrix to indicate which guidelines applied to techcomm, which one applied to authoring, which one supplied to publishing. And they built a mitigation strategy based on that. I later shared my experience at DITA North America and have been working since then to share that experience with technical communicators across various markets. You mentioned at one point in our emails, what is accessibility? And that’s a really good question. I’ve never found a legal definition, but what I usually use as a definition is accessibility is the characteristics of a product and its content that allow users with disabilities to access the content or use that product.

GK:                   That’s great. And from your perspective, based on all of that experience you just described, what does accessibility look like when you are authoring DITA content?

BJ:                    In all honesty, if you’re doing it right, accessibility doesn’t look any different than what you’re doing day to day. You’re just adding accessibility considerations when you author your content. So, for example, when you add a graphic, you make sure that you add an alt text so that users, for example, on a screen reader can get a description of that graphic. You make sure that your table designs are simple and easily navigated. Designs that look easy to the human eye can be very tricky to navigate on a keyboard, which is what most users on a screen reader will be doing. It also looks like authoring content that’s well structured and very focused so users, for example, with cognitive disabilities, don’t encounter problems or distractions that might make it harder for them to follow the thread of the content and understand it so they can fulfill their tasks.

GK:                   Yeah. And I know it’s really interesting what you said about images and tables in particular, because I think for a lot of our clients at Scriptorium, that’s one of the areas that when they’re authoring content in DITA, and they become concerned about accessibility or maybe they start to have new regulatory requirements for accessibility, with their content, that tends to be one of the biggest areas they have to start with. And a lot of times when they have legacy content, one of the areas where they haven’t really been addressing accessibility in the past. So, I think that’s a really good starting point that you mentioned.

GK:                   I want to talk about one other concern that we tend to see a lot, which is when we have something like DITA or structured authoring in general, where your content and your formatting exists separately, then that means there’re going to have to be two maybe different groups thinking about the way accessibility works. So, how can we be proactive in designing accessible content when you’ve got that separation between your content and your formatting?

BJ:                    The place to start is remembering that there’s more than just visual disabilities when it comes to accessibility. One of the responses I frequently hear when I talk to people about accessibility is, why do we need to do this for a small portion of our audience? And if all you think about is users that are blind, that is a relatively small portion of the audience. But visual disabilities itself is actually larger than just blindness. Visual disabilities also encompasses color blindness. About 8% of North European males and about 5% of North American males are red-green color blind. That’s a substantial portion of any audience. And you have to consider that, particularly when you’re implementing your interface, to make sure that color is not the only signal that something is changing or something has meaning.

BJ:                    You need to be sure that the form of whatever it is also changes so it indicates that there’s something you need to pay attention to. Similarly, when you’re designing an interface, you need to be concerned with neurological disabilities, and certain rates of flashing are known to induce seizures and you don’t want to flash at those rates. When you’re thinking about authoring, again, you want to think about not just visual disabilities, but physical and cognitive disabilities. People with physical disabilities may be navigating by keyboard similar to users on a screen reader. If they have, for example, carpal tunnel or epicondylitis, which is an inflammation of the epicondyle tendon in the elbow and makes it difficult to navigate by mouse, you may need to use the keyboard in that situation.

BJ:                    And you want to make sure as the author that you make a table, for example, that’s well defined to navigate. You want to make sure that your text content minimizes distractions for users with cognitive disabilities, like ADD or dyslexia. You want to make sure that it’s well organized, that there are a lot of bullets, that you keep your paragraphs short and tight, you keep your topics short and tight. And you really want to avoid using inline links, because those are distracting for both users on screen readers and users with cognitive disabilities.

GK:                   That’s a really interesting point about the inline links, because we’ve also seen that pose issues for reuse in DITA as well. But I don’t know that we’ve ever really seen it come up as an accessibility issue, but that is a really great point. And I know we’ve been encouraging a lot of companies that do heavy reuse to get their inline links into something more like a related links list at the end of a topic, rather than sprinkled all throughout. But that’s a really good point too, that it can also really have benefits on the accessibility side to do that.

BJ:                    Definitely. I have some personal experience with this. I have two children that both have cognitive disabilities, ADD and similar related disabilities. And watching them during the COVID pandemic and having to do their school work remotely and seeing text content that they’ve had to use that has links embedded in the text. They’ve found it easy to get distracted and lose the thread of what they’re working on. And that’s equally important for someone that is using content for a business application, or if they’re a consumer trying to, for example, place an order for a product or a service. You don’t want them to lose that thread and go off and do something else.

GK:                   Absolutely. I thought it was also really interesting what you said about making sure that your topics are short and focused because that’s another area where a lot of companies have come to us and said “we have legacy content that was written more in kind of a book like format, and we want to get it more modular.” And a lot of times, accessibility is a driving force behind that, especially as they’re going into more online forms of delivery, like Webhelp or HTML or a dynamic portal. So, that is a really interesting point too, of how they can author their topics in a different way that’s better for accessibility. So, that’s all covering the authoring side, but what about on the output transform development side, what can be done with the design and the way that you deliver that content to make it more accessible?

BJ:                    You need as the publishing designer to make sure that you implement whatever accessibility affordances that your authors design into their content. You also want to make sure you consider some of the color issues that I mentioned earlier, to make sure that those users have the correct signals for content changes, not just around color, but around form as well. You also, if you’ve got any kind of streaming content, streaming audio, streaming video, similar to this podcast, that you also make either a transcript or closed captions available so that users with auditory disabilities can follow along or even access the content. Because obviously, a user with an auditory disability is going to find it very difficult, if not impossible, to listen to this podcast and the transcript is going to make that available to them.

GK:                   Absolutely. One other question following on from that I wanted to ask is that one thing that we’ve seen sometimes with clients who are trying to take things from their legacy formats into something a little bit more modular is that they tend to have lots and lots of hierarchical nesting. And I wanted to get your perspective on any issues that might cause for accessibility. Because one thing we’ve seen is when you have many, many levels of headings, it can only go so deep in a visual representation before it gets really convoluted and confusing. And I think from an accessibility point of view, a lot of times our advice tends to be to try not to have your nesting and your hierarchy, whether it’s for headings or even list items to go too many levels deep. And I wanted to get your perspective on that as well.

BJ:                    Now, that’s a good point and both for users with visual disabilities and users with cognitive disabilities. Excessively, deep nesting is really problematic. So, for example, a user on a screen reader, deeply nested content can be very challenging to navigate, especially when you’re navigating by keyboard. So, making a shallow structure is going to be much easier for that user on the screen reader to navigate. A user with ADD or executive function disorder is going to have similar problems navigating an excessively complex structure. It’s difficult for them to keep focus or to focus on their navigation of a very complicated structure.

BJ:                    So, to make it easier for the users with those disabilities, you really want to focus on making your structure relatively shallow. Three levels deep is about the deepest recommendation for any form of navigation that I have seen by accessibility experts. And by the way, I consider myself an advocate, not an expert. I advocate for implementing accessibility and technical communication content, but I’m not necessarily an expert on accessibility.

GK:                   Any other final advice or words of wisdom that you have to help people who may be starting to introduce accessible content or address accessibility for the first time?

BJ:                    One thing is to realize that you don’t necessarily have to do everything at once. Very often, when people look at accessibility, they feel overwhelmed. I usually recommend a three pronged approach to implementing accessibility if you haven’t done it before. Anything that new, anything you doing new starting now, make sure you implement accessibility and follow your accessibility practices. Anything that you touch going forward, whether it’s to implement a new feature or to mitigate a defect, plan for implementing accessibility mitigations as well, as part of that work.

BJ:                    And then for each period of work, whether it’s a sprint or some other form of work, plan implementation of accessibility mitigations in a section of your content to make that whole section accessible or to implement accessibility in that whole section. Also, work with your leadership to determine what aspects of accessibility you need to implement. It turns out that some accessibility mitigations you implement for certain disabilities might not be good for users with other disabilities. And it’s up to your leadership, your accessibility experts, and your legal team to determine which accessibility mitigations are most important for your organization.

GK:                   Thank you so much for all of that fantastic information and for joining us on the podcast today.

BJ:                    Thank you for having me. Glad to join 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 DITA and accessibility (podcast) appeared first on Scriptorium.

In episode 105 of The Content Strategy Experts podcast, Alan Pringle and Sarah O’Keefe talk about an exit strategy as part of your content operations planning.

“You need to be thinking about the what-ifs 5 or 10 years down the road while you’re picking the tool. Are we going to have flexibility with this tool? Is it going to be able to help us support things we may not even be thinking about or may not even exist right now?”

– Alan Pringle

Related posts: 

Twitter handles:

Transcript:

Alan Pringle:                   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 talk about an exit strategy as part of your content operations planning. Hi, everyone. I’m Alan Pringle.

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

AP:                   And today, Sarah and I are going to talk about something that probably doesn’t get enough attention, and that is an exit strategy for your content operations.

SO:                   Yeah, and it seems vaguely impolite to talk about the process of leaving a vendor when you’re planning and thinking about which tools to buy and which systems to build and how to build up your content operations. But I think it beats the alternative, which is not to think about leaving a vendor and then 5 or 10 years down the road, you have to exit and you are truly, truly in trouble.

AP:                   Yeah, and I can understand, I will admit, I have caught glimpses of side eye from client stakeholders more than once when exit strategies came up during content strategy assessments. We’re talking about getting out of a tool before it’s even selected, and I can kind of understand the thought process. Why are we talking about that now? Well, as you pointed out, you really need to talk about it during the planning phase. Otherwise, you’re going to be left with a lot of muck when something happens and you’re forced to leave a tool for some reason.

SO:                   Yeah. The side eye from the vendors is even better when we start asking awkward questions. But the alternative, we’ve got projects right now where we are looking at, how do we exit a particular component content management system, move a customer to a new system because it’s time, and they need to move for good and valid reasons. And what we’re running into is that because the inbound 5 or 10 or 15 years ago didn’t really take into account the inevitable exit, we have huge migration costs. We’ve got relicensing costs. We’ve got rebuilding, recustomization, reintegration. It’s almost as bad as the original project of going from unstructured to structured content. It is super expensive if you don’t have a good path to exit.

AP:                   Sure, and let’s kind of take two steps back. The bottom line here is that planning to get away while you’re choosing your tools is a risk mitigation strategy. It’s a way to keep things from completely blowing up 3, 5, 10 years down the road. So it’s a way to lower your risk. As part of that mitigation of risk, let’s talk about some of the odds and ends that you really need to be thinking about as a way to develop your exit strategy.

SO:                   You know, we talk a lot about standards and I think everybody listening to this knows that we do a lot of work with XML and a lot of work with DITA-based content. But with that said, you kind of want to start with this question of, am I going use a standards-based tool… now we’re talking about something like a DITA CCMS or an XML CCMS… or should I use a commercial tool, which maybe isn’t standard space per se, but has a really good setup that meets my needs? If you can find something that meets your needs out of the box, doesn’t really require customization, that should work for you. But I would argue that the more customization you’re planning, the more complex your setup is going to be, the more important it is to fundamentally have a standard underlying what you’re doing, because otherwise you’re going to be again in big trouble when you try and get out.

AP:                   So basically, the more you tinker, the bigger your problem may be when you do need to leave this tool set or tool ecosystem.

SO:                   Right, exactly, because whatever configuration customization thing you do will not transfer over to the next system, whatever that may be. So you sort of look at it and say, well, it’s a one off. I’m going to do this, and as long as we’re in Tool X, this will work, but as soon as we exit Tool X, all that work that I just did has basically zero value.

AP:                   Yeah, and it also sort of… It may force your hand where you are locked in with a system until you can do something about all those customizations, and in some cases you may not be able to do anything about those customizations.

SO:                   Yeah. I mean, we worry a lot about lock-in, getting to a point where you have built a system, a process, a technology stack, a tool set that is so specific and unique to that particular underlying layer that you have that it becomes impossible to get out. The more customization you do inside a tool, the more custom connectivity, the more integrations you build to other tools, the more locked in you’ll be, because, again, if you switch tools, you’re probably going to have to rebuild all of that, and it was daunting to do it once and it’s going to be more daunting to do it again.

SO:                   So the more you integrate and customize, the higher your exit cost is going to be. You have to balance that against the fact that obviously you’re doing the integration because you get productivity, you get value from it. How high is that value, and can you recoup that over, again, three to five years before you are potentially faced with having to switch tools for some external reason that you have no control over?

AP:                   Yeah, and this is where you really have to look at your business case, your investment. Are you going to recoup that money? And if you do, that’s great, but if you don’t and you keep basically investing in these customizations layer upon layer upon layer, it’s going to be very hard to unwind all that stuff, and more importantly, it is going to be hideously expensive, both from a money point of view and a person-hours point of view, to get that stuff recreated.

SO:                   Right. So to take a very concrete example here, if you have a DITA-based CCMS and you build style sheets, DITA Open Toolkit style sheets, to do all of your output, then those style sheets should transfer from one DITA-based system to another, with let’s say minimal-

AP:                   Yeah.

SO:                   … rework. Certainly some CCMSs do have some proprietary stuff going on that you have to either put in or strip out, but overall, something like 90% or 95% of your style sheet should just work if you move it out of one DITA-based system into another one. If, however, you build out your output using, let’s say, a proprietary publishing layer in a particular tool and then you switch tools, you have to start over. So that’s a concrete example of where vendor lock-in would cost money down the road.

AP:                   And I think it’s important to point out here that it’s this exit strategy or these problems with not having an exit strategy are not just related to tools. There are some things that have to do with finances, contracts, so on, that also have a big part in these kinds of problems. So let’s step back from the tools a little bit and talk about the bigger-picture implications of finances and contracts and that sort of thing.

SO:                   Right. So if I’m… This is a case where the interests of the vendors selling commercial tools, software, and the interests of the customer, the organization buying commercial tools or software, do tend to diverge, right? Because if I’m the vendor, I want the longest-term contract possible. I want you to stay with me. I want you to pay me every year, as we all do, because that allows me then to reinvest in my tool and make it better and keep you as a long-term customer. It also reduces my risk as a software vendor, right? A five-year contract is better than a three-year contract is better than a one-year contract, and especially in a Software as a Service, in a SaaS world.

SO:                   So, okay. Well, that’s fine. But if I’m the customer, then you’re looking at an ROI of maybe two years or three years, and I don’t want to be locked into five years. Concrete examples of things that can happen. The software that I rely on gets bought by somebody else and they discontinue it. They take it over and they discontinue it. I have to exit. The organization that I work for gets merged with another organization, and then another organization, and suddenly we have not two systems, but, like, five different authoring workflows.

AP:                   And we’ve seen that. We have seen that.

SO:                   Yeah, I’m not actually making that one up.

AP:                   No, you’re not.

SO:                   So we have to consolidate because we’re supposed to actually deliver a unified customer experience, which is pretty hard to do with two or three or five CCMSs.

AP:                   Right, and also, most IT organizations are not going to stand for having three versions of a tool that essentially do the same thing when you do merge together. So from a financial point of view, it does make sense, and from a support point of view, to jettison two and stick with one.

SO:                   So two years ago, I picked a system. It’s a good system, but we got merged. Now we have a much bigger group. My sort of facts on the ground have changed. Or, we picked a system, it was fine, but now we’re doing more languages, or, oh, we need to integrate with this new chatbot thing that we’re doing over here in the corner and I don’t have any way of doing that out of the system that I’m currently in. And I didn’t account for that on day one, because it was 10 years ago and chatbots weren’t a thing, right?

SO:                   So those are the kinds of issues that you run into, where change or having to change, having to exit, is basically inevitable. At some point, a new requirement comes along, or your company changes, or you grow, or you shrink, or you change markets, you add localization, you add more localization and more languages. Something happens, and the thing that was a good fit for you is no longer a good fit for you. So what does it look like at that point to exit your business relationship with your existing vendors and your existing set of vendors? If you’re locked in for a really long time, you’re in trouble because you can’t do what you need to do.

AP:                   That lock-in can make things very difficult for you if you need more flexibility and you need to pivot and be nimble and really kind of change course a little bit if you are so locked down in something that doesn’t give you the ability to address those things. So basically you need to be thinking about the what-ifs 5 or 10 years down the road while you’re picking the tool. Are we going to have that flexibility with this tool? Is it going to be able to make some changes and help us support things we may not even be thinking about or may not even exist right now? Some delivery format that we don’t know about. Is this flexible enough to help address a concern we don’t even know about? I mean, that’s the kind of thing you have to be asking yourself.

SO:                   You know, to take a concrete today analogy, this is exactly like the office space problem, right? Suddenly everybody’s working remote. There’s all this office space. Are we going to use it again? Are we going to come back to our office? The facts on the ground have changed, and maybe the thing that was selected is not the right thing anymore, but here we are with a 5-year or 10-year or 15-year lease, right? It’s exactly the same problem, that you get locked in and then things change. Maybe everybody’s working remotely and your particular system isn’t really set up for a distributed workforce.

SO:                   And now back to the CCMS, right?

AP:                   Right.

SO:                   Most of them now, most of the clients we see, are in fact SaaS and not on premises, but you think about those kinds of issues. Well, what if you need everybody in the same building to use the system, and being in the same building is not in fact an option?

AP:                   Yeah. You have zero flexibility in a case like that, so it is definitely a problem.

SO:                   Yeah. It’s not that you made a bad choice. It’s just that there’s new information.

AP:                   Yeah. So let’s talk about dealing with, like you just said, that new information when you didn’t do that upfront planning. What are the ramifications of not thinking about the exit strategy when you’re essentially entering a tool?

SO:                   It just means that, at the inevitable point when you do have to leave the tool for whatever reason, you are then going to have to figure out, what are my options? How can I get out? How bad is the migration going to be? How do I dismantle or rebuild or recreate these integrations that I have? How do I think about the features that I have?

SO:                   One thing I would say is that I would caution people against trying to move from Tool A to Tool B and completely recreating or reproducing the old authoring experience. If you switch tools, and particularly if you switch authoring tools, authoring tools have different strengths and weaknesses, and what you want to do is take a tool and take advantage of its strengths. You don’t want to ignore its strengths because you never did it that way before, and you don’t want to rely heavily on its weaknesses, again, because that’s how we’ve always done it, right? So there’s some change that has to happen there. The authors will probably need some training and some help to shift over, but you really want to think about, well, what’s in here and what’s the state of the art and what are the new things that I can do?

SO:                   But largely, if you have to migrate or if you have to change tools, what you have is, at that point, a tactical problem, right? You just have to do it, and you have to look at the facts as they are, the features that you have available to you, the options that you have, and figure out what to do. But I think I would argue that exit strategy and risk mitigation is something that you should be thinking about or should have been thinking about before the tools and the technology stack and the processes were originally set up. And of course, if that’s not the case or it was your predecessor, then that’s just how it is.

AP:                   Bottom line, an exit strategy should be part of your content strategy. So while you’re doing the assessment, you need to be thinking about this and not dealing with the ramifications of not considering it 5 or 10 years later.

SO:                   It’s a lot cheaper to do it before you build. Yeah.

AP:                   Exactly. And on that note, I think we will wrap up. Thank you, Sarah, very much.

SO:                   Thank you.

AP:                   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 Exit strategy for your content operations (podcast) appeared first on Scriptorium.

In episode 104 of The Content Strategy Experts podcast, Elizabeth Patterson and Sarah O’Keefe discuss the Scriptorium Content Ops Manifesto.

“The bigger your system is and the more content you have, the more expensive friction is, and the more you can and should invest in getting rid of it.”

– Sarah O’Keefe

Related links:

Twitter handles:

Transcript: 

Elizabeth Patterson:                   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 talk about content ops and Scriptorium’s Content Ops Manifesto. Hi, I’m Elizabeth Patterson.

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

EP:                   And so we’re just going to go ahead and dive right in. Sarah, let’s start off with a definition. What is content ops?

SO:                   There are lots of great definitions out there written by people smarter than me, but the one that I really like is pretty informal. Content ops is the engine that drives your content life cycle or your information life cycle. So that means the people, the processes and the technologies that make up your content world. How do you create, author, edit, review, approve, deliver, govern, archive, delete your content? That’s content ops.

EP:                   So Scriptorium recently published a Content Ops Manifesto. And in this manifesto, you describe the four basic principles of content ops. So what I want to do is just go through those one by one, and I will of course link the manifesto in the show notes. So the first one you have in the manifesto is, semantic content is the foundation. What exactly does that mean?

SO:                   I wanted in this manifesto to take a small step back from hands-on implementation advice, and the things that we tell people to do, you need to go through and build out your systems, and here’s how you make them efficient and focus instead on the principles of what that looks like without getting too much into the details. And so with that in mind, each of these principles is intended as a guidepost that would apply for any content operation that you’re trying to build out. Semantic content is information that is essentially knowledgeable and about itself, or self-describing. Now this could be as simple as a word processor file, where you have some paragraph tags that say, “Hello, I’m a heading one,” and “Hello, I’m a heading two,” and “Hello. I am a body tag,” that kind of thing. So you need to have tags, labels of some sort that describe for each, whether it’s a block or a little chunk or a string of text.

SO:                   What that text is. Is it a heading? Is it body text? Is it a list or part of a list? That kind of thing. So that’s tags. Now, there are lots and lots of ways to do tags across every tool that you could imagine, but you need some sort of semantic labeling. Second, we need metadata. So we need information about the information itself. Usually this is classification tags. So things like, “I am a beginner level task,” or even, “I am a task. I was last updated on this date. I belong to this product or this product family.” So metadata provides you some additional context about the information and describes it further, but it doesn’t really describe the information itself, but rather where the information belongs or who should be using it. Metadata is broadly… If you’re struggling with metadata, take a step back and think about, if I were searching for this information, what kind of labels or tags would I want to use to find what I’m looking for?

SO:                   And then we have hierarchy and sequencing. So hierarchy means that you’re looking at the structure of the content from the point of view of which things are subordinate to which. So let’s say that you have an installation procedure and there are six things you have to do in a specific order and each one of them is a task or a process of some sort. Well, you need to be able to say these six things are in a group. There’s the installation process, which consists of these six things, that’s hierarchy. And then sequencing is… And they have to be done in this order, right? You have to do one, then two, then three, then four. You can’t start with four and then do one or your installation won’t work. So there’s this process or this idea that you’re collecting up information. And when you do these bigger collections above and beyond a tiny little string, you need hierarchy and you need sequencing.

EP:                   So the second principle that you touch on in the manifesto is that friction is expensive. And when we’re talking about friction, in this sense, we’re referring to the process that you’re slowing down productivity. So what are some common points of friction and what are some things you can do to eliminate them?

SO:                   Yeah, so friction is any time you have really human intervention, right? Because computers are very, very fast at what they do and humans, well, we have other skills, but-

EP:                   We make mistakes.

SO:                  We do make mistakes, but we’re good at certain kinds of creative things. We’re good at saying these things go in this logical sequence, but what we’re not good at is applying the same formatting consistently over and over and over again. Right? So friction is any place in your process where there’s human intervention. So I’m going in and I’m hand formatting things, or I’m downloading a collection of files, zipping them up, sending them to somebody else who’s then uploading them into a different system and expanding them and reinstalling them there. Anytime you see a process that is driven manually and/or driven by paper, you probably have friction in your process.

SO:                   And we think these things have gone away, but there are a non-zero percentage of people out there who are doing reviews by the process of, “Let me print this thing out and go give it to you and have you write on the paper and then give me the paper back.” That introduces friction. The problem with friction is if it’s just you and me and we’re working on two or three pages of stuff, and we’re in the same location, not that big a deal. But as you scale, as you have more people and more documents and more languages and more variants, that manual process that used to be okay when we had 10 or 15 or 50 pages of content, becomes unworkable, right? Because it slows you down. So when we talk about friction in a content ops context, what we’re usually talking about is where are these points of manual inefficient intervention and how do we get rid of them?

SO:                   And when you start talking about eliminating friction, we fall back on things that you’ve heard previously in a non-content ops context, automated formatting, automated rendering across all the different formats that you’re looking for, reuse content instead of copying and pasting, connect systems together so that you can share content efficiently, review workflows that are not human dependent and not paper dependent, but rather roles. I need somebody with the role of approver to look at this thing. I don’t need it to be you personally, Elizabeth, and as it happens, you’re on vacation this week, right? So I don’t want to send it to you. And I certainly don’t want to send it to your email specifically. What I want is for the system to say, “Hey, this thing is due for a review and here are the three people that are authorized to do it.”

EP:                   So friction, I mean, it’s going to take time and effort to eliminate that friction, but it’s definitely worth it in the long run.

SO:                   The bigger your system is and the more content you have, the more expensive friction is, and the more you can and should invest in getting rid of it. Yeah.

EP:                   Definitely. So the third principle outlined in the Content Ops Manifesto is to emphasize availability. What exactly does that look like?

SO:                   So is content available? What that means is if I am your content consumer, and I need a particular piece of content, can I even access it or have you locked it behind a log-in that I don’t know about or that I don’t have credentials for. So literally, not available to me. The information exists, but I can’t get to it. So that’s question one is, have you made it available and in many cases, availability in that aspect of it is actually synonymous with, “If I Google, will I find it,” right? Because I don’t necessarily know where you’ve stashed it, but if I can find it, then it’s available to me. Now, there are outlier cases where you do need to put things behind log-ins for good and valid reasons and that’s fine provided that your end audience knows, “Oh right. I have these credentials. I’ve signed up for the subscription. That’s where I’m going to go look for the information.”

SO:                   That’s fine. So where do you put it? What are the rights to get to it, right? Do the right people have the right access and do they know about it to get to it? Now, the second factor with availability is actually accessibility. And here, I mean, in the technical sense of, can I consume this content successfully? So there are a bunch of aspects of accessibility which usually have to do with physical limitations. So we’re talking about things like, I’m colorblind. Did you design the content in a way that I can still use it, even if I have some vision limitations? Is the content consumable by screen readers so that if I have a vision impairment, I can use it? If we’re doing a podcast, is there a transcript so that somebody with a hearing impairment or somebody who’s deaf can read the transcript instead of needing to use hearing?

SO:                   So you get into this question of, have you provided ways for people to access the information that allows for the possibility that they have some a physical limitation? There’re some others around keyboard navigation, right? Can I tab through the buttons instead of having to click on them? Have you allowed for people that have tremor or issues with fine motor control so that asking them to specifically click on a tiny little button on a screen somewhere is maybe not an option. Is there a mobile option as opposed to a desktop? Maybe I’m accessing all your content from a mobile device and if you haven’t thought about that, then I’m going to have problems trying to read the teeny, teeny tiny print on my not so big phone screen, right.

EP:                   And we’ve probably all experienced that and it is frustrating.

SO:                   It’s so annoying. So when we talk about availability, we’re talking about literal availability, like where did you publish it? And do I have access? Talking about accessibility and all the various facets of accessibility, there are lots of useful guidelines on that out there that are more detailed. And then we also need to think about languages and localization. If I’m a non-native English speaker and my comprehension of your text is going to be much, much better in French, which by the way, I can assure you, is not the case for me, you have an obligation to provide that content in French, if you want to market to your primary French speaking audience, right?

EP:                   Absolutely.

SO:                   So you need to think about languages. Localization also ties into the question of, well, if I’m writing content for a particular locale, a particular location, you need to think a little bit about what that looks like.

SO:                   So to take a really basic example, if you’re marketing to somebody in Florida, you probably don’t need to sell them snow pants in October, right?

EP:                   Probably not.

SO:                   They are not buying snow pants in October. So that’s like a really basic localization principle that… You want to think about your market and how your market differs by geography or by locale. That gets tied in with language. But they’re not really the same thing, right? You’ve got geographic stuff, you’ve got regional things and you’ve got different regulatory schemes. So for example, to take the infamous example, any legal advice that you’re giving somebody always ends with “comma except in Louisiana.” So, oh, also don’t give anybody legal advice because we’re not qualified, right. But you have to think about those kinds of locales and the different regulatory schemes to make sure that you’re covered and you’re not giving people bad advice based on making the assumption that we all live in the same spot.

EP:                   Right. So the last principle in the Content Ops Manifesto is to plan for change, which is something that we touch on in a lot of the posts that we publish and the podcasts that we publish. So how do you plan for change?

SO:                   We really are annoying about change managment.

EP:                   It’s so important.

SO:                   It’s our favorite word, our favorite phrase, or actually it’s our second favorite phrase because our first favorite phrase is, “it depends.” But let’s say it this way. When you start thinking about content ops and building up these processes and these technologies and these systems that you’re going to use to drive your content engine, the number one thing that I would advise you to do when you do this is to think about your exit strategy. So in other words, I am buying product X and I’m going to put all my content into it, or I am implementing system Y and I’m going to put all my stuff into it and that’s going to drive what we’re doing. I want you on day one, when you’re going into this really cool system that you’ve decided is going to be the be all end all for at least the next couple of years, to be thinking about what if I’m wrong or what if things change?

SO:                   What if that company gets bought by a competitor and they discontinue the product? What if the system that you put in place doesn’t work or a new requirement comes along and your system can’t accommodate it. You need to be thinking on day one about, “Okay, well, I’m going to go in, but if I have to get out, do I have a way of getting out? What’s my exit strategy? What is the cost of exiting this particular system or process? What is the cost of changing tools and technologies?” Because I’m not saying you should have a foot out the door. It’s more that we know that change is going to happen.

SO:                   Change is totally inevitable and somebody is going to come along with a new requirement that we’ve never thought about before, and we’re going to have to meet the moment. And so we need to know A, what things am I picking and are they extensible? Can I add on, can I accommodate these new requirements inside the system I’ve built or selected? And if not, how expensive is it going to be to get out? Now, if the answer is, it’s going to be super expensive to get out, but this thing meets 100% of our requirements right now, it’s extensible in these 15 ways and I don’t see a reason that we would need to get out, that’s okay. That’s a decision that you’re making, but you need to do a strategic assessment of, what is my exit strategy and what are the implications of needing to exit from whatever it is that I’m about to pick?

EP:                   Right. And I think exit strategy is a good place to wrap things up. So thank you, Sarah.

SO:                   Thank you.

EP:                   And if you would like to read the Content Ops Manifesto that will be linked in our show notes. So 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 The Scriptorium Content Ops Manifesto (podcast) appeared first on Scriptorium.

In episode 103 of The Content Strategy Experts podcast, Alan Pringle and Bill Swallow share some considerations for transitioning into a new component content management system or CCMS.

“You need to look at the requirements you have now. Are they being supported or not supported? Do you see this system helping you move forward with your content goals in three to five years?”

– Alan Pringle

Related links:

Twitter handles:

Transcript: 

Bill Swallow:                   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 share some considerations for transitioning into a new component content management system or CCMS. Hi everyone. I’m Bill Swallow, and today I’m here with Alan Pringle.

Alan Pringle:                   Hello everyone.

BS:                   And we’re going to jump into a discussion about when we should be switching our component content management systems. So I think Alan, I’ll probably start off with a question to you. How do you know it’s time to move on with your existing CCMS?

AP:                   Well, everybody’s situation is going to be a little different, but in general, there’s some things that you can look out for as warning signs you may need to reconsider your CCMS. One of them being, sure things worked great when you stood the system up, but now a few years later, you’re finding that it is not scaling to meet your needs. You’ve got a whole lot more content in it. You have some feature sets that may not be there, that would be very helpful to you. So it’s a matter of, is that system keeping up with your growth and your changes? Is it keeping pace?

AP:                   In regard to the feature sets that I just talked about, if you discover that you’re spending a lot of time doing customizations to make things work for you, that may be a warning sign that you need to take a look at what some other systems offer as out of the box features because you do not want to be in this loop where you are spending a lot of time and money and investing in a system by basically doing patchwork add-ons to it. That’s not sustainable in the long run. If there is a system that has the feature that you’re looking for automatically, it may be worth considering that system, instead of doing this patchwork add-on to your existing setup.

AP:                   We’ve also seen cases where we had a client that was involved in a merger. And because of that, there were multiple component content management systems in the mix from the different, mostly technical publications departments that merged together from the different companies. So when you find yourself in a situation where you have acquired another company or you’re being acquired, you may have a situation where you’ve got overlap in your tool ecosystem, and in general, a company is not going to want to support two tools that do the same thing.

AP:                   So you have to take a look kind of from a bigger business point of view, at what the overarching goals and efficiencies that the company wants to make. And some of those efficiencies may be, we’re not going to have two CCMS’s here, we need to migrate everything to one. And I think it’s worth mentioning in that case, just because you’ve got two systems in house, you may want to look at a third option, so that way, you are really not picking winners and losers because everyone has to move. I am not saying that is the perfect solution for everybody, but it’s absolutely something you should consider, if you do participate in a merger and have some overlapping systems.

BS:                   So everyone shares the pain pretty much. Okay, so let’s say we made the decision that we have outgrown our existing CCMS. How do we start to evaluate new options?

AP:                   Well, you need to gather information and you can do it internally, kind of be your own consultant, or you can hire someone to come in to help you do this. Basically, you need to take a look at the requirements that you have now, how well they’re being supported or not supported, as the case may be. And kind of break out your crystal ball. Where do you see things three to five years? Do you think this system is going to support you and some new things you may need down the road? So, that’s the kind of thinking you have to do. How well are you being supported in the present, and do you see this system helping you move forward in three to five years with your content goals?

BS:                   And I think once you start putting all this information together, at that point, you may want to consider doing a request for proposals from multiple different vendors. And in that case, definitely include your existing vendor because there may be something that you may not currently have in your existing configuration that they may be able to offer as well. Plus you’ll be able to use them as a baseline against your other options.

AP:                   Yeah, it’s not necessarily that you have to immediately assume that your current vendor is no longer going to be part of the picture. There may be a chance that they have new offerings, new features like you mentioned, and you can use the RFP process to kind of uncover some of that too. And from a business procurement point of view, I am sure your procurement department is not going to be disappointed to get a chance to renegotiate a contract. That’s just gross. And I know it sounds very matter of fact, but it’s the truth. It’s a matter of renegotiating and looking at a tool and seeing if it’s supporting things and what kind of funding is going to be required with any update that you have with that tool, if you choose to stick with it.

BS:                   Okay. So we’ve identified issues with our existing CCMS. We’ve gone through and identified a new option, whether it’s to stay with the existing one with some changes or to move to a new system. What are some of the common issues or roadblocks that you might encounter as you start to switch systems?

AP:                   This is true of anytime you switch technology, even if you, for example, were on an Android phone and you changed to iOS on an iPhone. There are going to be some features in one operating system that are not going to be exactly equivalent on the other side, you’re going to lose some features and you may gain some features. So you may have something set up that is very specific and tailored to the particular tool, the particular CCMS you’re using now. Is there anything in that, that is not going to translate well or come over to the new system? And there’s several components here in regard to this. Are there features you were using that are specific to that particular CCMS, that are not supported because it’s a proprietary feature, in whatever you’re moving to? That’s one consideration. And then another side of that is, do you have any connectivity, any connections to other kinds of systems?

AP:                   And this can include a learning management system, a digital asset management system, a translation management system. Are those connections that you have, can you get the equivalent setup in the new CCMS? Are there automatic API connectors from your new system to these things? Are you going to have to rebuild or completely recreate your existing connectors when you move to a new system? So you’ve got to look at anything that is very particular to the CCMS that you’re currently in and how well that will transition over. And then you have to think about your bigger tool ecosystem and how those things are connected and how you’re going to basically reconnect everything together when you switch to a new CCMS.

BS:                   So I’d also expect in this case, if in your existing CCMS, you’ve been making a lot of customizations on your own and hacks and whatever else to get things to work properly, you’re probably going to have to find either a resolution for those or unwind them, even in your content, perhaps, as you start migrating to a new system.

AP:                   Exactly. And this goes back to what we were talking about earlier, where if you have done a ton of customization to your CCMS, at what point do you say, “Is enough, is enough. I can’t keep adding and adding these custom hacks to this tool because it’s becoming inefficient.” That very much ties into what you’re talking about here.

BS:                   Okay. So we’ve talked about problems in the existing, evaluating new options and problems when you’re probably migrating. So what can you do to make this transition a success?

AP:                   Well, this is a tiresome piece of advice, but its solid advice, and that is, you need to make a transition plan. This is not something you can just jump into. You need to take a look at your “real work schedules,” because you do not want to be making this transition, when you have deadlines, deliverables, anything going on at your company where you’ve got a new product release coming out. That is not the time to do this. So you need to step back, look at what’s coming schedule wise, in the next few months, figure out when would be a good time to do this, and then start giving some thought about, “Okay, what might be the first thing that we can try and move over?” You may want to try to do a pilot to move over just some of your content to be sure that everything has stood up correctly, instead of going whole hog and doing everything at once. Those are two things that immediately pop into my mind.

BS:                   And probably keep both stood up and keep using the old one as your production system until everything is verified as complete on the new one.

AP:                   Absolutely. I think you also need to basically take a very deep breath and realize things are going to go wrong and be flexible and be ready to deal with things that are going to go sideways because they will. And there are going to be some things you may have an inkling, this may be a little challenge, but there may be other aspects you haven’t even considered that cause you problems. So you can’t go in with this super rigid idea, we must hit this exactly right, because in general, technology is going to wag its finger in your face and say, “I do not think so. I’m going to cause you a problem here.” But some planning can minimize those things, but I don’t know about you, I’ve yet to see any transition from one tool to another, CCMS or otherwise, that was perfectly smooth, and there were no hiccups. I have yet to see that ever happen, period.

BS:                   No, there’s no golden system. Going back to your phone analogy between Android and iPhone, there are excellent things about each one of them, but they also both have their problems.

AP:                   Exactly. And then finally, too, because you are moving to a new tool, you’ve got to realize skills people had in the old tool set, are not going to be quite as useful. So you’re going to have to provide training and support to be sure people can basically remap the skills they had from the old tool to the new tool. And that may be a little rough, especially if people have really invested a lot of time and thinking into workarounds to get things to work in the old system. And those things are no longer available. That’s a lot of muscle memory you’re going to have to undo with some training and best practice information, so people don’t keep doing those workarounds because they’re no longer needed.

BS:                   All sound advice. And I think we could probably wrap up here. Thank you, Alan.

AP:                   Sure.

BS:                   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 Transitioning to a new CCMS (podcast) appeared first on Scriptorium.

In episode 102 of The Content Strategy Experts podcast, Sarah O’Keefe and Sharon Burton of Expel talk about the importance of terminology management.

“If we don’t give customers the information to understand what we’re telling them, they won’t be successful and we have failed.”

– Sharon Burton

Related links:

Twitter handles:

Featured image: bbbrrn © 123RF.com

Transcript: 

Sharon Burton:                   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. My name is Sharon Burton, and I’m your guest today.

Sarah O’Keefe:                   And my name is Sarah O’Keefe, and I’m hosting. I delegated reading our bumper to Sharon because, well, there were some attempts and it didn’t go well. But, hopefully the rest of this episode will be more professional because we’ve got Sharon in charge.

SO:                   In this episode, I want to talk to Sharon about terminology management. Sharon Burton is a longtime friend of mine and also a senior content strategist at Expel. Sharon, welcome and thank you for taking on guest hosting.

SB:                   You’re welcome. I’m very happy to contribute to the overall mirth levels.

SO:                   This is going to be trouble.

SO:                   Tell us a little about yourself and your job at Expel, and what Expel does.

SB:                   The honest to goodness truth is I’ve done pretty much everything there is to do in this field. At least, it certainly feels like that.

SB:                   What I’m doing at Expel, I’m salaried at Expel, which is also new. I’ve not had a lot of salaried jobs. We work in the cybersecurity space. This is a new space for me, which is exciting. One of the things I love about our field is you always get to learn new things. I’m learning about cybersecurity. What we do is we are your offsite security management staff. There are groups of people in mid to larger companies called a security operations center.

SB:                   A medium to large company will have a group of people staffed called SOC, S-O-C, security operations center. Those kinds of people will monitor all of your hardware, and your software, and make sure that the people logging into the networks are the right people and all of that. The problem with that, and there is a big problem with that in the cybersecurity industry, is multi-fold.

SB:                   Number one, there aren’t enough people out there who are trained to do this, flat out aren’t. There’s a huge deficit of people. Number two, the people in the security business, because there aren’t a lot of them, they job hop a lot. Because as soon as they get bored, they can go get another job doing something interesting elsewhere, so you have a lot of staff turnover. And number three, sitting there and watching the logs of all of this stuff, all day long, is mind-numbingly boring. So you have staff shortage, mind-numbing boring and people job hop.

SB:                   What Expel does is we are your, if you will, offsite stock. But, we’ve got a whole bunch of tools and technologies, and all kinds of fun things that we’ve developed, so that we don’t bore our people. We’ve got all kinds of bots that do exciting and fun things. And, we’re a young company, we’re only five years old. When I started, they knew I was the first content anybody and they hired me because they knew that to move the product forward in any way, shape or form, was going to require content strategy. Not just content, lots of people are creating content here, but an actual strategy.

SB:                   When I first started here, I met with the CEO, and the COO, and a couple of other people and I said, “Okay, you hired me. Let’s talk about why you hired me. What problems do you see as we need to solve?” Both the CEO and the COO, two of the three founders, said, “We’re a content company that happens to make some products, and the products happen to be in the cybersecurity space. But, if we don’t provide content to our customers to understand what a threat is, things that we’ve handed to them and said this is a threat, you should go fix this. Or, you’ve got an intrusion, you should go fix this. If we don’t give them the information to understand what we’re telling them, they won’t be successful and we have failed.”

SB:                   I went, “So, you mean that we’re a content company that happens to make software?” And they said, “Yes.” I went, “I think I’m in love, perhaps more than HR is comfortable with.”

SO:                   Awesome. I wanted to talk to you about terminology management, because you’ve … Well, as you’ve said, you’ve done a lot of things but we had to pick a topic, so we came up with this one because I think it’s near and dear to your heart, and it’s also maybe not well understood.

SO:                   Can you tell everybody just what is it? What is terminology management and why does it matter?

SB:                   There are certainly people, much smarter people than I am, who could talk about this. But, I’m going to talk about it because it’s something that I’m currently involved in, part of the foundation I’m building here at Expel.

SB:                   We all know that there are a lot of words. I have been accused of having them all and using them all, all the time. Go ahead and laugh, Sarah, I know. But, there are a lot of words. Technical writers know that we should call something the same thing all the time. Unlike when we were taught to write in school when we were told, “Oh no, our reader will get bored if you always call it a field. You should call it other things.” The reality is the technical writing, techcomm community, we know once you decide to call that thing a field, by God, that thing needs to be called a field every time because otherwise, you’re going to confuse your users. That’s terminology and that’s making your terminology consistent.

SB:                   But, companies are starting to figure out it isn’t just the user guide or the online help where this matters. It matters when the salespeople are talking to customers or potential customers. It matters when marketing is talking to potential customers or to customers. It matters on the blog, it matters in the post-sales content, which is my happy place. But, it also matters in the customer support database, it matters in the UI. Because if we don’t figure out what stuff is called and then use those words, we look like we’re all self-employed, or something. There’s that customer experience.

SB:                   There’s also the translation. If you don’t have your terminology managed and somebody walks in your office and says, “Oh, we just closed a deal and all we have to do is deliver in German, in six weeks.” If you’re laughing thinking, “Oh, that never happens,” Sarah and I are here to tell you we don’t have enough numbers to count the number of clients we’ve dealt with who have that exact situation happen. “What do you mean we can’t deliver in German? Well, we’re just going to translate the content.”

SB:                   Well, if every time we say click okay, everybody says it a different way … I worked with a client once, where I did a quick analysis on just a subset of the docs, and they said click okay in over 50 different ways. 50. “Click the okay button, click okay button, click okay, select the okay button.” Well, if we had translated that, then that’s 25 cents a word, per language. We would have to pay that, because it’s $50 million in German in six weeks, we don’t have time to go fix that, so we’ll translate that right now. We’ll fix that after we translate it, which means your translation memory is now no good, or at least a limited value, it gets so expensive.

SB:                   Now at Expel, we are not currently localizing and I don’t know that we ever will, because the international language of cybersecurity is English. But, we have to act as if that guy, that person, that woman is going to walk in your space and go, “German, $50 million in six weeks.” If you’ve done your terminology management, if you’ve gotten your language groomed so that it’s all consistent, you can go, “Well, that’s not optimal. I think we’ll be okay,” instead of putting your head down on the desk and bursting into tears, which is usually the reaction.

SB:                   That’s why terminology management matters, because it’s customer experience and it’s literal dollars and cents.

SO:                   I think even setting aside localization, the point of the thing should always be called the same thing. It’s not a baby seat, a car seat and an infant seat, and a safety seat.

SB:                   And, a booster seat.

SO:                   It’s one of those. And a booster. Yeah, it’s one of those. Now frankly, I’m not in that particular business and I don’t particularly care which one you pick, but I care a lot about you picking one of them.

SB:                   Yeah.

SO:                   Even if you’re only operating in one language, there’s that consistency issue of, as you said, using the same term for the same thing so that people don’t get distracted wondering, “Wait, why did they change? Why is it different in this document, or in this chapter, or over here? Or, why is the marketing content different from the techcomm support content? This is weird.”

SO:                   How do you do this? We have convinced you, the gentle listener, we hope, that you should consider terminology management. But, what do you do? What’s your first step?

SB:                   Well, I’m in a really fortunate spot because my company got it, they literally hired me to do this stuff. I’m in an absolute sweet spot. I just said, “Well, it’s time for us to now take on the phase of the project plan where we start doing terminology management.” They went, “Oh good, I was wondering when we were going to get there.”

SB:                   But, I have also worked with places that needed to be convinced this was a thing. One of the ways to do it is to get a subset, a representative subset of docs. I don’t mean go look for the worst examples, I mean are you using Flare? Good, then grab the big Flare project. Flare is a great way to do this, because you probably have Analyzer. If you have Flare and you have Analyzer, and there are other ways to do this, but this is a great way to do it if you’ve got that tool, take a look for phrases that are almost but not quite the same. Analyzer will let you run that report. That’s how I got the click okay, all the different ways to click okay. You start getting your arms around phrases that are used all the time.

SB:                   I’ve spent much of my career in software, so things like click okay, accessing menus, the basics of the style guide, but the style guide is like an honor system. There are better ways to do this.

SO:                   For those of us who don’t work at Expel, what kinds of challenges might you have come up against in the past, when working at other less enlightened places? What kinds of pushback, or problems or issues do you run into when you tell people, “We are going to manage terminology?”

SB:                   I am formulating a hypothesis about the tech industry. I’ve been working on this hypothesis for about five years. That most software companies, for sure, don’t realize that they are in the content business. They think they’re in the software business, they think what they’re selling is a software product. But in fact, they’re in the content business. Now Expel, as I said, I’m incredibly fortunate, I know how fortunate I am.

SB:                   As I’m looking at where thinking is changing around content, and the value of content pre and post sales, I’m thinking that companies are more in the business of content and they just happen to create a product that they sell. But it’s got to have a large content ecosystem, otherwise it’s not going to be able to be used. I think about that, but I’m realizing that an awful lot of companies don’t know they’re in that business. It can be very difficult to get a company to recognize they need to control their terminology because they don’t see a value in the content, or they see a limited value in the content.

SB:                   One of the ways I’ve tried with other customers, other clients, a lot of places you can convince them to have a style review for content before it gets released. That means that a human being has to read it, read the content, they have to have the style guide memorized, and then they have to make sure that that content meets the style guide requirements. For terms, for how we talk about stuff, all of that stuff. That’s time consuming, labor intensive and fraught with errors because humans are full of errors. We want to be perfect but the reality is we are not, we are wonderfully imperfect.

SB:                   So you take the number of people who are doing that, the percentage of their time they are doing that, and then you figure out what that costs the company, fully loaded, it’s a straight business case. And then, you look at terminology management products. There are a couple of them out there. And then you start looking at what is it going to cost to do this programmatically, versus having people do it onesie, onesie. That is a way to go about it, but a company has to know it hurts before it’s willing to stop the bleeding.

SO:                   So there’s some pushback, just on the grounds of content is not important, which is pretty problematic.

SB:                   It is pretty problematic. The good news is, over the course of my career, we’ve gone from tech writers are secretaries to content strategy, bringing people in as senior content strategists, because they recognize how important content is. Now, that’s the arc of my career and it’s a beautiful thing. But, that level of enlightenment is not, perhaps, pervasive throughout the land. There are still kingdoms who don’t feel that content is as important. We’ll get them, eventually. Eventually, they will figure it out. It’s just it can be frustrating and hard.

SB:                   Because I think I am of the belief that what we do matters, in the content world. It matters because it lets people have content that will let them do the important things that they’re trying to do. Because of that, they deserve the very best that we, as an industry, and we as individuals, can give them. I really believe this.

SO:                   That was something I wanted to ask you about. We see terminology and terminology management introduced very often in the context of, “We need to mature our processes, we’re going to put in place some sort of content management, content management system. Then, we’re going to formalize our style guide and embed it using terminology management software,” those kinds of things.

SO:                   But, I feel like is there a best practice here? Which one should you do first? Do you do the terminology work and then the content management? Or, do you do content management first? Or, do you do them simultaneously? What do you think?

SB:                   At Expel, because we’re young, because we don’t have a full-time tech writer, we’ve got a contractor who we love, we’ve not built up that side of the house. Again, we’re young, we’re still in startup mode, we’re still in, “Take that hill! Okay, let’s take that hill.” We are not ready for content management, in the bigger picture. We’re building up a knowledge base. There was no knowledge base when I started here 10 months ago, there is now a knowledge base. I’m very proud of that. Is it where I want it to be? No. But, it’s only been on its feet for, what, April, so five months, six months. Toddling along now, it stopped the zombie walk.

SB:                   I wanted to get the style guide and the terminology management done early, early, early because I think this is the foundation that we can build the house on. I have been where we had the content management stuff in place, but we had no terminology management. That meant that somebody, part time at least, had to go through the content management system on a fairly regular basis and align the content. That’s labor intensive, but if you have an intern or a very young person, that can be fun for them for a while, until they get bored with it. But, it still has to be done.

SB:                   It depends on where you are on the spectrum. If you’re an established company with a lot of content, I’d go for the content management system first. I think the payoffs are going to happen faster there. Unless maybe you’re delivering in five languages, then maybe I’d go for the terminology management first. What’s bleeding?

SO:                   In short, it’s the mantra of the consultant.

SB:                   It depends.

SO:                   It depends.

SB:                   No, I would ask, “Where’s your pain point?” If you’re spending too much on localization, then I’d look at why are you spending that much. Is it because you have no terminology management? You’re not using a style guide, you’re not applying style? Can we solve it there, or do we need to go all the way back to your copying and pasting from document to document?

SB:                   And by the way, everybody knows, every time you copy and paste, a kitten gets hurt so don’t copy paste.

SO:                   Yeah, don’t hurt the kittens is probably as good a place as any to wrap this thing up. Thank you, Sharon. This was very interesting, and I think helpful. I hope that all goes well at Expel and wherever you may be.

SB:                   You are welcome and thank you so much.

SO:                   Thank you. 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 The importance of terminology management (podcast) appeared first on Scriptorium.