In episode 129 of The Content Strategy Experts podcast, Sarah O’Keefe and Bill Swallow discuss the prerequisites for efficient content operations and the pitfalls from not following them.

Mayhem, chaos, cost overruns, work, rework, delays. I mean, these things, they’re expensive. And they’re not just expensive, they’re soul sucking for everybody involved in the project. And it doesn’t have to be that way if this thing is planned and executed at the right level.

—Sarah O’Keefe

Related links:

• Even a digital content factory is not built in a day
  
• Getting buy-in from content ops stakeholders
  
• Do you have efficient content ops?
  

Twitter handles:

• @sarahokeefe
  
• @billswallow
  

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 talk about the prerequisites for efficient content operations. Hey, everybody, I’m Bill Swallow.

Sarah O’Keefe:

And I’m Sarah O’Keefe.

Bill:

And I think, before we jump in, we should probably explain to everybody what we mean when we talk about content operations.

Sarah:

Content operations is the people, the processes, and the technology that allow you to make content happen. And some people will say that content operations only counts if you’re actually working efficiently. So it’s like a best practice. But I would argue that content operations is all the things. So, in a world where you’re writing things in Notepad and converting them into WordStar, and from there, through WordPerfect into some ancient version of PostScript for print, that is in fact content operations. It sounds like pain, but it is content operations. So what we’re looking to do in general in all of our projects is produce better, good, efficient content operations.

Bill:

So within content operations, you generally have four areas that we tend to look at to see how best we can optimize those things. One would be requirements. One would be having a roadmap. Another one is actually planning based on the roadmap and the people involved.

Sarah:

Right. And it gets very tricky very quickly because content ops sits in between the publishing content production world and IT. And so, the temptation is to say that, “Well, content is just a weird type of data,” which, well, that’s a whole other conversation. It’s a whole other podcast. So we’ll just set that aside for the moment. But the major point here is that, when you start looking at content ops, when you’re looking at content at scale, huge volumes of content in lots of different languages, globalization requirements, you have to think about delivery platforms. You have to think about video streaming, audio issues, transcripts, accessibility. And the volume of content that passes through a content ops environment can be, I think, surprising to a traditional IT group. If this is your first experience with content and content ops, the amount and the complexity of information that we’re dealing with tends to come as a surprise to people that are not specialized in the space already.

Bill:

Right. There’s so many different facets to content in so many different ways that those facets can get leveraged and need to be leveraged. It’s not just a raw data store, even though many would argue that XML is just a raw data store.

Sarah:

When you start looking at content operations, what you’re going to find is that there are a number of components to your content ops that are unique to a content ops environment. Yes, you’re familiar with content management systems, but in particular, are you familiar with component content management systems, headless CMSs? Are you familiar with localization issues, what it looks like to do Unicode across 40 or 50 different languages? When you look at XML, XML for content and XML for data are in fact not at all the same thing. So you need people that understand this tech stack from a content perspective. And since 80 or 90% of the work that we’re doing is actually DITA, the Darwin Information Typing Architecture, keep that in mind. A lot of tech people struggle with understanding DITA. And I mean, to be fair, a lot of content people struggle with DITA initially. So there’s a lot there, and it’s complicated.

Bill:

There’s usually an assumption that is made that, “Oh, well, DITA is just XKL. XML is just data. So we know how to handle data, so we know how to handle DITA. And the two just couldn’t be more different

Sarah:

Yeah. And requirements. When we start talking about requirements, what are we talking about here? Not so much the tech stack, right? I mean, there’s a tech stack requirement, but what’s the baseline that you start from when you start building requirements?

Bill:

Right. And that baseline really does come down to the business drivers for why you are doing the things that you’re doing. And fundamentally, if all of your tech requirements do not meet those business goals, you’ve just wasted a ton of money.

Sarah:

I mean, I’ve told this story before, but a long time ago, I was working on a project and we were busy trying to justify the build, the system, which was going to be pretty expensive. We were trying to justify it because we were going to have more efficient formatting. We were going to save money on formatting, formatting automation, get away from a very manual at the time in design and I think unstructured frame maker process, both of which were time consuming. And I’ve never forgotten. I went into a meeting with this VP and we were explaining some of the cost savings, which were really very much efficiency-driven. And he stopped us and he said, “Look, we’re a company. We’re doing,” whatever it was, “$10 billion in revenue per year.” And of that 10 billion, at least half is international revenue. So $5 billion a year in international revenue.

And he said, “Right now, we have a six month delay on localization in getting any… And so, we can’t get any international money.” You can’t get international revenue when you can’t ship your product with content in German, or French, or Italian, or Spanish, or Thai or whatever it was they needed. He said, “Can you promise me that you can chop one month off of our six month delay in localization? Because if you can, we can easily justify this whole thing and you don’t need to talk to me about this other complex stuff.”

Now, we knew that it’s actually pretty easy to get from six months down to, say, two months without really trying very hard. Now, getting from two months to two days, that’s hard. But all he wanted from us was-

Bill:

Very hard.

Sarah:

Six months to five months, which we said, “Well, yeah, I mean, that’s easy. We can do that.” And he said, “Great. Where do I sign?” So, ultimately, the requirement in that particular case, because all of their growth was coming from international revenue, non-US, non-English customers, so they wanted to focus on that. They wanted to deliver better and more efficiently and faster so that they could get that revenue more quickly. And my misunderstanding of the business case could have gotten us in real trouble had it not been for this person in a meeting who said, “Let me stop you right there because you’re focused on the wrong thing. Tell me about this thing,” which was easy.

Bill:

Actually, that was a good example of having the right people making the right decisions, and talking to the right people in order to inform the right decision.

Sarah:

Right.

Bill:

Yeah. From your perspective, you were doing the right thing because you needed to build efficiency and all this other fun stuff. Meanwhile, you talked to another person who’s looking at the right thing as, “We need to expedite our sales in a foreign market. How can you help us do that?”

Sarah:

Right. And we were able to do that, but we had to get refocused on that correct baseline fundamental requirement for what they were trying to do. So I guess then the question becomes, what happens when you don’t have the right people asking the right questions?

Bill:

Right. Because that really is one of the linchpins here. First of all, you have a huge learning curve for anyone who is not the right person doing the right type of work. They’re starting from ground zero, and they need to basically escalate their knowledge and build their proficiency in the work that they need to perform out of the gate. And generally, you don’t have that kind of a runway when you’re doing any kind of an implementation project of any kind.

Sarah:

I mean, it’s common to come into these projects where there’s not… And for us. We’re consultants. We get brought in when that knowledge internally is missing. So it’s really, really common for us to come in and have to build out a knowledge base and a set inside the organization so that the stakeholders inside the organization can make good decisions and can carry this thing forward. Related to that, once we’ve done that, once we’ve built a group within the organization that has this knowledge and these competencies, we want to hang onto them. There are very, very few things worse than losing the people that have that knowledge because they move on to something bigger and better and more exciting. And we have to start over with a new group. And again, build all that foundational knowledge to make sure that they know what they need to know in order to make good decisions because when you come into a new area of practice, whatever it may be, you don’t know what you don’t know, and so, you make bad assumptions. And if you make bad assumptions, you make bad decisions. And bad decisions are expensive and time-consuming.

Bill:

Very much.

Sarah:

So I think if I’m a director or a VP looking at launching one of these content ops digital transformation kinds of efforts, look around your organization. Do you have the right people in place with the right skillsets? If not, do you have people that can learn this stuff, that you can, I don’t know, not dedicate to, but assign to the project for the long term, couple of years, to build that community of practice, that knowledge inside your organization? That’s something that we spend a lot of time on, we spend a lot of time focusing on, but there will have to be that core group eventually. Unless you’re playing to black box outsource this stuff, which is very, very rare, you need a group internally that keeps track of this stuff and manages it for the long haul.

Bill:

Building that into your team, it really is critical. Like you said, whether you bring someone in initially to get the team up and running and have them learn, or you have people with those core competencies already in house, if you’re missing those people, that your project is going to very likely run over budget, run over time, and generally just be absolute chaos.

Sarah:

Mayhem, chaos, cost overruns, work, rework, delays. I mean, these things, they’re expensive. And they’re not just expensive, they’re soul sucking for everybody involved in the project. And it doesn’t have to be that way if this thing is planned and executed at the right level. And I will say that, typically, the people who get blamed for this are the people on the ground who are doing their best to try and do this stuff. But ultimately, folks, I blame you, the senior leadership. It’s your job to plan this thing, to give people what they need to make sure that they have the right skill sets. And if they don’t have them, that you support them in acquiring those skill sets, that you support them with outside experts who come in and can deliver on those skill sets, contribute to your project, and do all of the things. The lack of planning, magical thinking is the thing that kills these projects. And then, the people on the ground get blamed for it. “Oh, why didn’t my tech writers do this better?” Well, because you put them in an impossible to succeed position.

Bill:

Right. And to say that it’s senior leadership’s job to plan everything, that’s a little misleading, I think. But it’s their job to make sure that the right people are involved at the right points in the project to make the decisions and help plan the effort because they are the ones who have the leverage to bring the right people in and make things happen.

Sarah:

Yeah. It’s enablement. And we don’t enabling as a verb because it sounds terrible, but that’s really a leadership job, is to make it possible.

Bill:

Clear the runway, get the right people in.

Sarah:

Yeah. Apparently, I have some feelings about process and wrong processes. The most common thing that happens here from our experience is that people pick the software, the technology stack first or too early, and then let that drive all the other decisions. Now, there are legitimate reasons why the tech stack might be a constraint in the sense of we’re in group B over here and groups A, C, D, E, and F are all using the same tech stack and we need to fit into that. That I get. But what’s actually a lot more common is, “Ooh, I like this. I used it in a previous job, so let’s just go with it.” And that’s really not a good reason to pick anything specific. So what happens?

Bill:

Congratulations, you pick the box that you can’t work outside of. And not every box contains every single solution to every single business need. So if your business drivers require very specific things and the box doesn’t have it, you’re never going to get there.

Sarah:

Yeah. Okay. Hopefully, you picked the correct box, or actually you did your requirements properly, and then you said, “Hey, this looks like the right kind of system for what we’re trying to do.” What are other things in the process as you move along in one of these builds that cause problems?

Bill:

A lot of it comes down to pretty much the same type of focus. Whether it’s a big box or a little box, you’re still picking the wrong one. For example, if you are combining content sets from multiple different groups into a brand new system and you spent a very long time choosing the right system that meets the right business needs, but you don’t do any upfront content modeling to see how all of these different groups content will fit together in this bright, shiny, perfect box, you’re going to find a lot of missing pieces along the way. You’re going to find a lot of edge cases. You’re going to have to do a ton of rework just to get this content to all interact.

Sarah:

Did you just tell our audience that they have to think inside the box?

Bill:

If they have a box, they should think inside it. Yes. If you don’t have a box, then think outside of it until you find the box that fits wherever you ended up going.

Sarah:

Yeah, the content model, I mean, it’s such a point of contention because if it’s too strict, it won’t work and people will do weird work arounds. And if it’s too loose, it doesn’t really help you because it doesn’t constrain things in any useful way. And if you build it out and then later you find edge cases that you weren’t thinking about, you have to stick a bolt on the side of the box, and it’s just bad. So there’s the content model, then you convert your content into the new content model, at which point you find all the things you missed.

Bill:

Exactly. That is really the aha moment. When you start converting content, you go, “Oh, wait a minute. We didn’t account for this thing that this group is doing over here. And they say it’s really important.”

Sarah:

Yeah. I mean, that’s a tough balance because you want to build out a content model, start doing some prototype proof of concept conversion, refine it as you go, do the rework that’s necessary. I mean, no matter how much upfront planning and analysis you do, you will find edge cases. The problem is, the later you find them, the more expensive it is to either rework the content model or, my particular favorite, to just hack around them.

Bill:

Yeah. The number of times I’ve seen output class used as a means to an end, it’s [inaudible 00:17:49].

Sarah:

I mean, we’ve spent a really long time talking about all the terrible things that happen, but how do you do this right? How do you make it such that your content ops project is as painless as possible? What are the best practices?

Bill:

Well, we talked about getting the right people involved at the right stages in the right project, but I think that’s something that needs to happen regardless of what you’re doing. But as far as content operations is concerned, first and foremost, you need to have your requirements nailed down. And we’re not talking about your requirements like building out an agile framework or something like that to build things out and it iteratively progress, but what are the high level requirements that are driving this entire initiative?

Sarah:

So we need to go from six month delay in localization to five month delay, or less would be better, but a one month improvement. Our system… We talk about language support. We need to be able to localize into 40 or 50 or 75 languages. I’ll add to that, that one unusual requirement that will rule out a number of tech systems is multilingual authoring. So we’ve seen a few cases where the content is being created in… Most everything we see is being sourced in English. But English and also French, or German, or Chinese, or Korean. And you have to then have a system that will support authors working in those languages as they are creating content. It turns out that a number of CMS systems make the assumption that you have a single source language and many downstream target languages that you localize into. So it’s a one to many relationship. If what in fact you have is a many too many or a few too many, you need to really pay attention to that.

Bill:

Yes, absolutely. So, other things that you really should do is start looking at your publishing requirements as well. So it’s not just the authoring side, but it’s where you’re going. We’re talked about being able to publish out to 40, 50 languages, but what about seven, eight, nine, 10 different types of output? Are you able to get there easily? Is there a limitation in the tech that you chose that prevents you from developing a critical delivery point?

Sarah:

Yeah. So, multichannel publishing, integration with some sort of an omnichannel world. Incremental publishing is becoming important. I have a library of 40 or 50 or 100,000 chunks of content, but what I actually want to be able to do is update one and publish it, and not have to push the entire system or the entire document that that one chunk lives inside of. Integration with other systems is becoming increasingly important. The ability to take a chunk of content, push it to Salesforce, push it to the main website where we’re working in perhaps a TechCom world, or push it to eCommerce system so that it can be reused there.

Bill:

And not only iterative publishing, but iterative translation as well because some systems, they’re really great about you being able to gate very, very small chunks of content or very, very discreet files for localization at any point in time. This is separate workflow for each individual file. Other systems, they gate things by publication. So if you have 90% of your content hardened for a particular publication, you still can’t start the localization workflow for that content until the last 10%’s completed. And if we’re talking about getting from that two-month to the two-week point in the translation turnaround, you’re not going to get there if your system is gating by the publication level.

Sarah:

I think, overall, I’ve seen a lot of lists of requirements. What you want to do is focus on the ones that are unique. We need version control is not interesting to me. Everybody needs version control. And we want to be able to reuse content is a little bit interesting, but not really. And we need variables and we need localization support, those are all basically prerequisites to the requirements. They sound like requirements, but not really. What I’m looking for is, what are the unique requirements in your organization?

For example, we make medical devices and we need traceability because, if we don’t have that, we get in trouble with the regulators. We have a very complex content structure. There’s a reason it’s set up that way, and we need to reflect that in our operations. We need personalization. We need high velocity, really high velocity. Those are the things that you want to find that make your content unique within the landscape of generalized content operations. And once you’ve identified that keystone, that keystone requirement, that if we can point to this and make that successful, then we’re good, that’s what is going to help you drive the entire project and always look at that fundamental foundational requirement and make sure that you’re focused on it and meeting it.

Bill:

All those little bells and whistles can be added later. They can be configured later. But yeah, if you’re not meeting those high level requirements out of the gate, you’re doing the wrong thing.

Sarah:

The summary of this very lengthy podcast is you should plan. Planning is good. Planning is your friend. And if you don’t plan, some very, very bad things are going to happen.

Bill:

Very much so. And while you’re planning, make sure you have the right people doing it.

Sarah:

Plan well.

Bill:

Well, I think that will be a wrap for this one. Thank you, Sarah.

Sarah:

Thank you.

Bill:

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 Prerequisites for efficient content operations (podcast) appeared first on Scriptorium.