Whether you’re surviving a content operations project or a journey through treacherous caverns, it’s crucial to plan your way out before you begin. In episode 176 of the Content Strategy Experts podcast, Alan Pringle and Christine Cuellar unpack the parallels between navigating horror-filled caves and building a content ops exit strategy.

Alan Pringle: When you’re choosing tools, if you end up something that is super proprietary, has its own file formats, and so on, that means it’s probably gonna be harder to extract your content from that system. A good example of this is those of you with Samsung Android phones. You have got this proprietary layer where it may even insert things into your source code that is very particular to that product line. So look at how proprietary your tool or toolchain is and how hard it’s going to be to export. That should be an early question you ask during even the RFP process. How do people get out of your system? I realize that sounds absolutely bat-you-know-what to be telling people to be thinking about something like that when you’re just getting rolling–

Christine Cuellar: Appropriate for a cave analogy, right?

Alan Pringle: Yes, true. But you should be, you absolutely should be.

Related links:

• 
  
• Nightmare on ContentOps Street (podcast)
  
• Enterprise content operations in action at NetApp (podcast)
  
• Content creature feature
  
• Hear Alan Pringle speak about the Horrors of modernizing content operations at LavaCon 2024!
  

LinkedIn:

• 
  
• Alan Pringle
  
• Christine Cuellar
  

Transcript:

Christine Cuellar: 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 episode, we’re talking about setting your ContentOps project up for success by starting with the end in mind, or in other words, planning your exit strategy at the beginning of your project. So I’m Christine Cuellar, with me today is Alan Pringle. Hey, Alan. 

Alan Pringle: Hey there.

CC: And I know it can probably sound a bit defeatist to start a project by thinking about the end of the project and getting out of a new process that maybe you’re building from the beginning. So let’s talk a little bit more about that. Why are we talking about exit strategy today?

AP: Because everything comes to an end. Every technology, every tool, and we as human beings, we all come to an end. And at some point, you are going to have tools, you’re gonna have technology and process that no longer supports your needs. So if you think about that ahead of time, and you’re ready for that inevitable thing, which will happen, you’re gonna be much better off.

CC: Yeah. So this conversation started around the news of the DocBook Technical Committee closing, and that’s kind of a big deal for a lot of people, and it kind of sparked this internal conversation about like, you know, what if that happened to you? How can people avoid getting caught by surprise? And of course, as Alan just mentioned, the answer to that is really to begin with the end in mind, to have an exit strategy because everything does end at some point. So this got me thinking about, you know, I don’t know, Alan, you’ve seen the horror movie The Descent, right? You’ve seen that movie? Yes, because it’s amazing and it’s a horror movie and it’s awesome. So it me kind of think of that because, you know, this group, and I’m not going to spoil it, no spoilers for people who haven’t seen it yet, but, if you haven’t, go watch it. The first one’s my favorite. I haven’t seen the second one, so I’m biased. Anyways, that’s not the point. This group plans to go along one path, you know, down these caves which are definitely in North Carolina, right Alan? That’s definitely where they take place.

AP: Well, they say it is in North Carolina, but it is quite clearly not filmed in North Carolina. As someone who is familiar with Western North Carolina, I had to laugh at this movie trying to pass off somewhere in the UK as like the Appalachian Mountains, but that’s just a quibble. So go ahead with your story.

CC: Anyways, yeah, they got a mountain in there, right? And then there’s a path into the mountain. Of course, they’re going to explore this deep, dark cave. So they’re descending as the name implies. And so they’re planning to go along one path. think someone maybe tricked someone else along the way. I can’t remember. But they’re planning on going down one path. And there’s a lot of things that begin to happen that they didn’t plan on. And one scene in particular, there’s a cave that collapses and of course that means they have to pivot, right.

AP: Yeah.

CC: So when you’re thinking about building an exit strategy and trying to plan for things that you can’t anticipate, how do you anticipate things you can’t anticipate?

AP: Well, first of all, let’s be clear. All the things that happened in that movie happened in a period of like two hours or an hour and a half. And part of the issue with any kind of process and operations is things can slowly start to go badly and you just kind of keep on trucking and really don’t pay attention to it. But…

CC: Yes.

AP: It’s not just about fine tuning your operations. That’s a whole other conversation. You your process is going to require updating every once in a while. There going to be new requirements and you need to address them in your content ops by changing your process, updating your tools, maybe adding something new. What we’re talking about here is when those tools and that process, they’re coming to an end, for example, because a particular piece of software is being defecated. It is end of life. What are you going to do?

CC: Mm-hmm.

AP:  What if there is a merger? You have a merger and there are two systems doing the same thing. One of those systems is going to lose and go away. Why are you going to maintain two of the same systems? So you’re going to have to figure out how to pivot to get to that.

CC: Mm-hmm.

AP: So there are all of these things that can happen that mean you have got to exit whatever you were doing and move into something new, something different. And the reasons are many, like I just mentioned, but the end result is, are you ready for when that happens? In a lot of cases, frankly, people aren’t.

CC: Yeah. So if you could give listeners three pieces of advice on how to be less dependent on a particular system, if you had to narrow it down to three, what would you suggest to help them not be just dependent on one particular system or maybe a set of systems?

AP: One thing is when you’re choosing tools, if you end up something that is super proprietary, has its own file formats, et cetera, that means it’s probably gonna be harder to extract your content from that system because it is proprietary. Even if your content is in a standard, and in a lot of cases, of course, I’m talking about DITA, the Darwin Information Typing Architecture and XML standard. Even with DITA, even though it’s open source and a standard, some of the systems that can manage DITA content put their own proprietary layer on top. A good example of this is, for example, those of you with Samsung Android phones. I’ve had one in the past.

CC: Yeah, that’s me.

AP: Samsung puts their own proprietary layer on top of the Android operating system and a lot of that stuff frankly I hate, but that’s not the point of this conversation, but it’s the same issue. You have got this proprietary layer where it may even insert things into your source code that is very particular to that product line. So look at how proprietary your tool is or your toolchain is and how hard is it going to be to export? That should be an early question you ask during even the RFP process. How do people get out of your system? And I realize that sounds absolutely bat, you know what, to be telling people to be thinking about something like that when you’re just getting rolling–

CC: Appropriate for a cave analogy, right?

AP: Yes, true. But you should be, you absolutely should be.

CC: And how do you know you are going to get onto the other two things to think about in just a second, but question there, how do, what are some maybe green flags for how that question should be received or how you want that question to be received if it’s going to maybe be the right fit?

AP: I would hope some variation of the answer would be you can export to this standard, although that often is probably not the answer that you’re going to get.

CC: Okay, as standard. What are some other things people need to keep in mind in order to not be system-dependent?

AP: I don’t know if it’s so much system-dependent, but you need to think culturally about what this means. People become very attached to their tools because they become very adept. They become experts in how to manipulate and do whatever with a certain tool set. And they feel like, you know, I am in total control here. I know what I’m doing. Things are running well. 

CC: Yeah.

AP: And when it turns out that tool is going to have to go away, their entire process and their focus on being an expert, it’s blown. It’s just blown away. And that can be very hard to deal with from a person level, a people level, having to tell people, yeah, this is a shock to your system. You’ve been using this tool forever. You’re really good at it. Unfortunately, that tool is being discontinued. We’re gonna have to move to something else. That can be very hard for people to swallow and it’s understandable.

CC: Mm-hmm.

AP: It’s completely understandable. One other thing that I will mention is if you can get your source content, not the actual delivery points I’m talking about here, but wherever you’re storing your source in some kind of format neutral, file format and again, talking mostly about XML content, extensible markup language, because when you create that content, you are not building in the formatting. You were creating it as a markup language. And the minute your content is in a markup language, it becomes easy to easier. I shouldn’t say easy because nothing here is easier. There is a better path to moving that content, possibly to another standard, for example, because you can set up a transformation process that’s very programmatic.

CC: Mm. Yeah.

AP: This particular element in this model becomes this. And when you hit this particular element in this model, you start a new file. If you see this particular attribute, it needs to be moved over here to this attribute.

CC: Hmm.

AP: So it’s a matching process that you have to do so it can be programmatic. So anytime you get into something that’s XML and what does that X stands for? And what does that X stand for? It stands for extensible. That gives you a little more control because it gives you more flexibility. And that’s weird to think more flexibility gives you more control. That almost seems kind of diametrically opposed, but that’s true.

CC: Yeah.

AP: Because you can move something out more easily because it is something that can be sliced, diced, transformed. So there’s that angle.

CC: Yeah. Yeah. So, okay. So as a non-technical person myself, I’m gonna see if I can summarize this and you tell me whether or not this is accurate. So from a very high level view of this, it’s almost like, you know, rather than keeping all of your content in one particular content management system or something like that, you’re keeping it in a, it’s all stored in a separate box or a separate repository. And then whatever system you’re going to use is your delivery output. It’s almost like a, is that accurate to say? Okay.

AP: Because when you are in a format that is not, doesn’t have the, if you’re in a file format that does not have the formatting of your content built in, that means you can deliver to a bunch of different presentation layers. You can automatically apply it. 

CC: Okay.

AP: And that’s really, I was kind of headed that way. You can even see your new system as almost a delivery target, I need to figure out how to transform my source content in a way that a new tool, a new system can understand. And so basically you’re saying, okay, let’s export it, let’s clean it up, maybe do some automated transformations and programming on it to make it more ingestible by the other system.

CC: Mm-hmm.

AP: So you could even look at this process of moving from one system to another as being really your final destination, another horror movie, your final delivery target, moving that source content into another system that you’re about to use.

CC: Yeah. Thank you also for unpacking that because that was much more clear than my example, but that was really helpful. So since people are planning with the end in mind, how far out are we thinking this exit strategy would typically be implemented? How far down the road is this?

AP: And that’s the thing, I can’t answer that question because you never know what is going to happen. you, right, mean, it’s like the cave collapse analogy like you mentioned, sometimes you have to take a detour, not of your own choice or of your own making. And again, mergers, tools being discontinued, companies that go under, all of these things can happen. And you need to have a contingency.

CC: Mm. Never know. So it’s a contingency plan, really. Yeah.

AP: And you need to have a contingency plan in place to get ready to exit. It’s just like during natural disaster season, you hear people say, do you have your emergency preparedness kit ready? It’s a very similar thing, but it’s in the corporate world. This is as much about risk reduction as it is about smooth content operations, at least from my point of view.

CC: Yeah. Yeah. And you mentioned several like big things that happen that can trigger the need to, you know, it’s time to exit and move on. Are there any scenarios where there isn’t a big thing that happens like a merger or a business closing or different things like that? Are there more quiet ways where you realize you may not realize that it’s time to exit? But it’s more the need to exit is more subtle.

AP: If your content process, your content operations cannot support new business requirements, for example, you need to connect to a new system, you need to deliver your content in another format. If your current system and tools can’t do that, that is a sign you’re probably going to have to find the exit door and find something that will support whatever it is that you cannot do.

CC: Mm-hmm.

AP: It’s usually you just hit this wall where you realize we have taken this tool and this process as far as it can go. It is time to move on. And here I am going to toot the consultant horn again. But that is when you start getting that uneasy feeling, that’s when you can talk to a consultant who can help you unpack it to see if it’s really a sign that the tool is no longer going to fit you or if there’s something you can do within your current system to make things work. That’s when a third-party point of view can be very valuable.

CC: Question for you on that third party perspective, since you’ve seen companies make these transitions many times and exit something and go into a new one, what’s one thing or pitfall that companies need to be aware of that maybe isn’t included in their exit strategy that should be? 

AP: Something that’s very common is to frame everything you want from your new system from the perspective of what your current system is doing. Even though your current system is not going to do something that you need it to do, you still are so fixated on how it is doing things and you can’t get beyond that. That can be a huge problem. Being able to step back and objectively look. This system can’t do this.

CC: Mmm.

AP: We need it to do that. And this is how we need to get there. People can get so mired in the, this is how we’re doing things. And we’re going to move over to this new system and do the same exact thing, just in new tools. That’s not a reason to move. There’s some compelling thing that’s forcing you out of that other tool. So now is the time to change things, update things, make some nips and tucks. Maybe undo some things. Don’t just wholesale move over into a new system and keep things status quo. Otherwise, why bother?

CC: Yeah, yeah. Is there anything else you can think of when you get to when it’s time to start the exiting process? Anything else that you can think of that companies need to have at the forefront of their mind?

AP: It’s the communication. And that includes the vendors and it includes with the people inside the company who are using the tools. And I would also mention it includes procurement. They need to understand the wins, the whys, why you’re having problems, all that, because there can be contractual obligations about when a license ends and another one begins. So you’ve got to keep that information flowing to all kinds of parties to make this exit, this transition work well.

CC: Yeah, you want it to end like the American version of The Descent where the hero actually gets out and drives away in the car, not like the UK version where the person is still stuck in the cave, which is the better ending for a horror movie, I will say, but not for your content ops project. Definitely.

AP: Yeah, but at least in a content ops project, you’re not going to get eaten by some humanoid blind thing living at a cave. 

CC: Hopefully, right? That’s ideal. That’s the best case scenario. 

AP: Hopefully not. Yeah.

CC: Well, Alan, is there any other parting advice you can think of before we wrap up today’s topic?

AP: Don’t go into a cave unprepared. Okay? Just don’t. How’s that?

CC: Yeah, don’t yeah that that is actually good advice. Yeah, don’t go unprepared. That’s really helpful. And like Alan mentioned earlier a third party perspective. I know it’s very biased to be saying it but a third party perspective when it’s time to either make the exit transition or plan for the exit transition. Content strategists can really help with that because we’ve seen we’ve seen a lot of things a lot of caves. Yes. Yeah.

AP: A lot. Maybe not cave dwellers, but a lot.

CC: Hopefully, hopefully no one has actually seen those. Yeah, well, thank you so much for being here, Alan. I really appreciate you talking about this with me today. 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 Survive the descent: planning your content ops exit strategy appeared first on Scriptorium.