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: 

• Scriptorium’s Content Ops Manifesto
  
• Content operations (content ops)
  

Twitter handles:

• @alanpringle 
  
• @sarahokeefe
  

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.