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

LinkedIn:

• Alan Pringle


• Christine Cuellar

Transcript:

Disclaimer: This is a machine-generated transcript with edits.

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 th