Full transcript of Content strategy failure podcast

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 episode 37, we talk about failure, how can you guarantee your content strategy will fail? How can you invite disaster for your content processes?

Alan Pringle:      Hey everybody, I am Alan Pringle and today I am with Sarah O’Keefe.

Sarah O’Keefe: Hello.

A. Pringle:            And we have offered a lot of tips on how to succeed in your content strategy in earlier podcasts, and we’re going to turn that on its head today, and talk about how you can pretty much ensure your strategy’s going to fail. So we thought this would be a kind of fun way to look at things and give you advice on what not to do.

A. Pringle:            So, Sarah, I’m going to kick the ball of failure over to your court, and let you, you know-

S. O’Keefe:          All right, I’ll take a huge swing and a miss.

A. Pringle:            Yeah, uh-huh.

S. O’Keefe:          So with the racket, because I picked the wrong racket, because tools. It is so tempting and so easy to start with the tools, to say, “Oh, this is the tool that we’re going to use, it’s going to be great, it’s going to be awesome,” and then move forward from there. And the problem with that is the tools are not in fact the first that you should pick. Before you make any decisions about tools and software, or really anything else, you need requirements.

S. O’Keefe:          And requirements are hard and nobody likes them. So it’s much more fun to see a demo and say, “Hey, that thing’s cool, let’s use it, and go.”

A. Pringle:            And it’s understandable, because when you are in the content business, you are likely working with a certain set of tools, and often and a lot, and you are intimately familiar with them, and they are part of your daily work life. So you can almost be forgiven for having such a strong focus on tools, and I understand that inclination. But you’re really not serving yourself, or really your entire department and company well, when you you are focused just on that tool experience.

S. O’Keefe:          What that does is it means that from the first day of your project, you’re looking at your content through the lens of what can this tool do, not what does my content need to do, but how can I can do things for my content inside this tool?

S. O’Keefe:          So it’s like you have blinders on, right?

A. Pringle:            Exactly.

S. O’Keefe:          Because you’re not going to go outside what that tool can do, even if that’s in fact what your organization requires. So picking the tools first is a great way to fail, because it means that you may very be actually solving the wrong problem.

A. Pringle:            Exactly, and an extension of the whole picking tools first thing is, and you touched on this already, is that you basically are ignoring requirements and any return on investment analysis, you are completely bypassing those very important parts of the content strategy process.

S. O’Keefe:          Yeah, I have told the story before, but I distinctly remember a project where I was told, “Whatever you do, we need you to recommend this specific tool.” And one of the managers, or actually one of the executives informed me that there were some specific requirements that I knew for a fact that that tool could not meet. Now, it’s one thing to kind of be going along with an existing tool, and get to a point of, “Oh, we have this requirement, and oh, we can’t do it with our current tool set.”

S. O’Keefe:          It’s entirely another thing when you go in and you say to your management, “This is the tool we need for the next 5 or 10 years,” and then a year later they come back to you and say, “Well, what about this requirement?” You say, “Oh, it doesn’t do that.” Knowing ahead of time that that requirement, in this case a particular language that they needed to localize into, would not be supported. I mean that’s just not an acceptable way of going about doing things.

A. Pringle:            No, and when you jump in tools or technology first, and you’re looking at maybe what some of your colleagues are doing and other companies are using, an interesting case study at a conference, and think, “We need to be doing that.”

A. Pringle:            Well, the problem with that is, have you done any actual analysis on what it will cost to do that neat thing? Would it solve the problems? And then present that to management and say, “We had this problem that we needed to solve. This is what it’s going to cost upfront, here’s how we’re going to recoup that money.” When you go tools first, that rarely happens if ever. It’s just ignored essentially.

S. O’Keefe:          Right, now the flip side of tools first, right, is you can get analysis paralysis when you spend so much time on requirements and ROI analysis, and figuring out every possible facet of what you’re trying to do, that then you never actually do anything. So I guess on the one hand, don’t dive into the tools immediately or first, but on the other hand, don’t get bogged down in requirements gathering forever. You have to do enough, which is a hard balance.

A. Pringle:            It very much is. And I think there is another angle with tools first. There’s a lot of things that come off that, it’s a waterfall of badness basically, of what not to do. And when you go tools first, you also are ignoring all of your content stakeholders: all the people who are either directly involved in the creation and distribution of content or their jobs are affected by that content.

S. O’Keefe:          Yeah, and the stakeholders, some of them are going to say things like, “Don’t change anything or else.” Some of them are going to say, “Give me this tool or else.” And you have to wade through–I kind of like waterfall of badness, although I’d kind of like to refer to it as something else. But I’m not allowed, I’ve been told-

A. Pringle:            This is a clean podcast, people.

S. O’Keefe:          Kaitlyn could bleep it.

A. Pringle:            Yeah, she could.

S. O’Keefe:          She could. So anyway, while you’re in the waterfall of [bleep] things, your stakeholders, they’re going to have a lot of requirements, and they’re going to have a lot of demands. And what you have to do is separate the real demands from the, I don’t know, princess demands or whatever you wanna call them. I won’t do this unless you allow me to continue using my favorite tool, or I won’t do this if anything changes for me, or I refuse to use a cloud-based system, or I refuse to use a non-cloud-based system.

S. O’Keefe:          Now, if the person saying that is like the CIO or the CTO, then you actually do have to pay attention, but otherwise it’s just one person’s opinion.

A. Pringle:            Right. You’re talking about personal preferences versus real requirements, but when someone is fairly high up the chain and is going to have a say in what’s going on here, unfortunately those personal preferences can sometimes kind of blend into–

S. O’Keefe:          They’re actual business requirements.

A. Pringle:            Right, they’re requirements at that point, yeah.

S. O’Keefe:          If it’s a C-level person, then it’s a requirement.

A. Pringle:            Yeah, and once again we’re very tool-centric on this episode, and it’s not much of surprise, because we have seen so many train wrecks where tools led the day, and it didn’t end well for people. And another part of the tools are the vendors who are creating those tools, and I see people ignore their stakeholders, yet they will bend over backwards to make tons of time for demos by vendors, where, let’s just say, the truth is not entirely told. And that is a huge just … It does not calculate for me and it never has.

S. O’Keefe:          I think just like anything else, you have to think about what the agenda is of the person that you’re dealing with, right? So the vendor, their job is to sell you something. So they’re going to explain to how their tool’s going to solve all your problems forever and also slice your bread.

S. O’Keefe:          Your content stakeholder, their agenda may be to avoid change, or to retire before the change happens, or try the cool news tools, so that they can have something on their résumé for when they bail from your organization.

S. O’Keefe:          And of course you have to take into account that a consultant’s job is to make this all sound hard so that you will buy services and advice from them.

S. O’Keefe:          So you have to balance all of those things and understand what people are telling you, and what viewpoint they’re coming from.

A. Pringle:            Exactly. And it’s not just vendors who are not always 100% truthful. That problem falls among all the different groups Sarah mentioned, and they can include stakeholders, and they include consultants. Now, that’s not us, but yes, it can, it can include consultants.

S. O’Keefe:          Yeah, we’re wonderful. And I wouldn’t even … I don’t think I’d even go as far as saying not truthful. It’s more like sometimes people have the wrong perspective, like–

A. Pringle:            True.

S. O’Keefe:          –I used to work at company X, and we tried to implement tool Y, and it was a train wreck, so therefore tool Y sucks.

S. O’Keefe:          Well, maybe it does, and maybe it was just wrong choice for that organization, maybe it was badly implemented, maybe the project manager was terrible, maybe a lot of things.

S. O’Keefe:          So you have to really work on getting to the truth through all of these conflicting … It’s like Rashomon, I mean everybody sees it a different way, and you have to figure out what the reality is going to be for you, for your organization.

A. Pringle:            It is easy to project your past experiences onto new things. And that’s what you have to sort through when you’re dealing with this.

A. Pringle:            Another angle … And this is not necessarily tools-related. Shocker. It is very easy to jump directly into the project without focusing on a smaller success, on a pilot, on something where you can get an easy win to show that this is viable. I’ve seen that happen too. People try to aim for something that’s possibly too ambitious.

S. O’Keefe:          Yeah, I mean we talk about boiling the ocean and all these other terrible, terrible expressions. But if you have a plan and you’ve kind of constructed your plan, and you think, “Okay, this is the direction that I wanna go in, this is how I wanna change things, this is how we’re going to do things,” it makes an awful lot of sense to pick a Goldilocks project, not too small, not too large, and work through it, and try out your new process, your new workflow, your new systems, your new all the things, so that you can figure out “Does this work at a small scale, what kind of issues do we see? What would cause problems downstream?”

S. O’Keefe:          So the content strategy failure here is not to do a pilot project, to just go straight into full-on commitment, production, whatever you wanna call that. Skipping the pilot project means that you skip an opportunity, you lose an opportunity to lower your risk to try some things out, to validate the decisions that you’ve made early on, or not validate them, right? You test what you’ve done.

S. O’Keefe:          Without a pilot project, it’s pretty high stakes kind of decision that you’ve made to turn your monster cruise ship in a particular direction. That’s a big commitment that you’re making. So pilot projects are a way of avoiding that, or deferring that really big commitment of making a smaller commitment, trying it out, seeing how that goes.

S. O’Keefe:          Without a pilot project, if you’ve made the wrong choice … If you’ve made the right choice, you might be okay. If you’ve made the wrong choice, without a pilot project, you’re liable to have a pretty big catastrophe.

A. Pringle:            You are basically eliminating your ability to test things in the real world, and to make some course corrections before things get too big for you to do that.

S. O’Keefe:          Yeah, and related to that, you should not allow your IT group to drive the project and ignore the requirements that are coming from your content creators. That is likely to result in a solution that is efficient and appropriate for IT, and slots into all the other tools that they have. And likely to result in a solution that does not actually meet the content creator’s needs.

A. Pringle:            I will be the devil’s advocate for the IT department, and kind of flip that around, and say a way to guarantee failure is to completely ignore your IT staff, and not to talk to them, and to go with it with just a content creator focus, and not pay attention to the tool sets your company may already have that could help solve your problem.

A. Pringle:            Part of IT’s job is a vital one, and that is to be sure that a company is not spending tremendous amounts of money maintaining tool sets that virtually do the same thing.

S. O’Keefe:          Right, yeah, so again, you can fail, you can do a great job of failing by allowing IT to run the project. And you can do a great job of failing by not allowing IT to run the project, and the same thing goes for the content creators, you have to strike a balance between those two things and potentially other stakeholders.

S. O’Keefe:          But typically, the big conflict that we see is between content creators and the sort of tool architecture enterprise people. And trying to make sure that you balance the requirements and the needs and the solutions that they need and want on both sides of that equation.

S. O’Keefe:          So actually getting those people in a single room to talk to each other can be one of the biggest challenges. And yet one of the most compelling things that you can do early on in the project.

A. Pringle:            Absolutely, and with that very good piece of advice, I think we’re going to wrap things up. Thank you very much Sarah. This was kind of fun.

S. O’Keefe:          Thank you. More failure to come.

A. Pringle:            Thank you for listening to the Content Strategy Experts podcast, brought to you by Scriptorium. For more information, please visit Scriptorium.com or check the show notes for relevant links.