Content strategy pitfalls: planning (podcast, part 1)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 61 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow return to our content strategy pitfalls series with a discussion about planning.
“Another thing that is really helpful is doing a pilot project or proof of concept, because that can help you look at a small but essential piece of your strategy and see how that works, and what goes wrong or what goes in an unexpected direction during that pilot.”
— Gretyl Kinsey
Related links:
Twitter handles:
Transcript:
Gretyl Kinsey: 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 61, we return to our content strategy pitfalls series with a discussion around planning.
GK: Hello and welcome. I’m Gretyl Kinsey.
Bill Swallow: And I’m Bill Swallow.
GK: Today, we’re going to talk about what happens if you don’t plan a content strategy and you don’t plan for implementing new systems. I think both of us have seen this happen quite a bit, so I think let’s just go ahead and start off with the question of what happens when you don’t plan properly?
BS: All the bad things happen.
GK: Yes.
BS: Yeah. One of the things that I’ve seen and I’ve heard pain points for talking to other people is when they look at a content strategy and they plan it without considering all of the pieces that need to come together in order to reach the end goal, so they look at where they are and they look at where they need to be, and they put that end result as the highest priority. But they don’t consider all the little pieces in between.
GK: Yeah, I’ve definitely seen that happen, as well. I’ve also seen it happen where the end result that they had in mind had nothing to do with their business goals and just had everything to do with, “Oh, we saw this really awesome tool that we think would be a good change.” Or, “We may be have this one goal that we’re focusing on,” but it’s not really taking into account how that is going to help save time and save costs, and it’s not really an overall picture. It’s just sort of something, one little piece that they’re focusing on, and that affects the entire planning process or lack thereof.
BS: Right. Because it then shuts out a lot of other opportunities and it shuts out a lot of other places that need to be addressed.
GK: Yes. I think one really common case I’ve seen of this is where content strategy kind of just encompasses one department or one type of content and doesn’t really look at the organization’s content as a whole, and doesn’t kind of look at the future end goal of getting all of that content aligned and making sure that the company’s branding is a major part of that and that everyone is kind of consistent across their messaging. I think that that’s one big planning gap that I’ve seen happen a lot of times. A lot of it boils down to just different groups kind of working in silos and not collaborating with each other. And so when that happens, then of course they don’t plan together and make sure that they’re coming up with one kind of overarching strategy.
BS: Right. You did mention also focusing around a particular tool, and that’s a fairly myopic view in general, but when you start targeting a tool, either by relying on its own capabilities, you tend to forget to look at all of the other pieces that need to come together to support that or other places where that content needs to be used. Or if you’re looking at a particular goal of getting everything into a new CCMS, or a new CMS for that matter, that ends up being strictly an implementation problem, and not necessarily a strategic look at how the content needs to come together in order to do that.
BS: So, a lot of the strategies are a lot of the tasks that fall out of the strategy that you’re putting together generally focus on that one single goal in disregard a lot of tangential pieces, that other people might be relying on your content that they no longer will be getting it in the format that they expect, or it might limit the sharing of content, or it might lead to oversharing of content. In which case, you then might have the same problem for example, of duplicate content or redundant content being produced by other groups just by leveraging your content without actually following some kind of systematic reuse.
GK: Absolutely. Like I said, that’s something that I have seen happen so many times. Sometimes we’ve been brought into a situation as consultants where that was what happened and then they have had to bring in an outsider like us to fix it. That’s definitely something I think to really consider in the planning phase so that you can avoid that and avoid getting stuck in that hole and then having to kind of crawl your way back out.
BS: That’s a good analogy.
GK: What are some other examples that you’ve seen of what happens when you don’t plan or when you kind of fail to do so correctly?
BS: Well speaking of crawling, you end up having portions of projects that ended up just being in this bit of a churn cycle, so to speak, where a lot of efforts being made to do a particular piece of the overall strategy, but nothing else is coming together. Then when things do come together, then a lot of rework needs to happen on that same piece. I guess in one way, you can boil it down to not hardening any particular portion of your strategic approach until you know all the pieces are going to fall together. Because if a change does happen somewhere down the line, you have to back up and then start redoing a lot of the same work over and over again. Likewise, if you don’t get buy-in from particular groups or with using particular technologies in a certain way, you might have to then revisit how you’ve approached your entire content model, which is no small feat, and it’s not easy to do when 85% of your implementation is complete and then you have to start and basically redo a huge portion of that.
GK: Yes. A couple of examples where I’ve seen this happen. There is one case where metadata was something that got caught in a churn, because prior to kind of moving things over into a structure environment, there was a situation where nobody had really thought about metadata and how it would be used with structured content. And so, that almost became so much of a focus, and it was a new focus that had not been considered before. People got caught up in the churn of constantly going back and forth and saying, “What metadata do we need? How are we going to use it?” It basically just drew all of their focus away from the other pieces of the project so that nothing was really moving forward. I think that’s a good example of this kind of churn cycle that can happen.
GK: I’ve also seen it happen with conversion processes sometimes or with the development of output transforms. Basically like you said, any one piece, if it kind of gets all of the focus or most of the focus and you’re really working so hard on making it super perfect, then oftentimes what happens is other considerations happen, other things come into play. Then what you thought was so perfect is actually not perfect after all, but maybe you’ve already used all of your resources. Maybe you had budgeted a certain amount of time or money to work on that piece and you’ve already blown through all of that before you had a chance to see how it fit into your larger strategy. Then you’re kind of in a really bad place at that point because what you had developed to perfection is no longer perfect, but then maybe you’re stuck without the means of taking it where it needs to be.
BS: Right. And you know, that speaks a lot too also being able to keep your eyes on the prize, so to speak, and it’s nice to have that end goal in in view. But you can’t necessarily ignore it once you start working on a particular piece of your implementation or a particular piece of your strategic drill down into figuring out what the tasks are to complete something and start working on some of the ground level bits of your implementation. If you keep your eyes or if you keep a focus away from the end goal and all the pieces that need to come together to make that happen, a lot can change. Other departments and so forth can have their own projects going on, which could impact some of the infrastructure you planned on interfacing with or using directly, and that can have a huge impact on all the work that you’re doing. Which might be good work, but it would have to be reworked in order to work with whatever new approach or new systems these other groups have decided to implement while waiting for you.
GK: Yes, absolutely. What other examples have you encountered of this?
BS: Another, I guess a good basic one, is the problem of stagnation, where you have a charter to go ahead and implement something, to develop a strategy to get teams aligned and so forth. Then for whatever reason, things come to a crawl. So maybe executive leadership has a different high priority that they’re chasing, and suddenly your group’s needs or your project’s needs suddenly don’t get the focus that it needs to move forward.
BS: It’s really difficult to kind of get out of that stuck mentality of not being able to move forward, because you’re not getting the budget that you need, because you’re not getting access to the people that you need to talk to. It can almost be frustrating. So, it’s important to be able to make sure that you have a means of communicating up to someone who can make an executive decision to say, “We know that we have a focus on these three other things, but this is still a priority project, so let’s make sure we have some time and resources allocated to keeping this moving forward.” Your content strategy might not be the be all end all project that the company is worried about, but then you can at least make sure that you have some ability to keep it moving forward and not letting it stagnate.
GK: Absolutely, and I think that what you’ve said about allocating resources is one of the biggest issues that can lead to the stagnation, and can also lead to another example, which is something that we’ve called hurry up and wait mode. A lot of projects sort of end up in that cycle of stagnation and churn as well. I think a lot of it boils down to the allocation of resources, like you said. If you don’t plan for that up front and you just kind of make a project, something that people work on as they can rather than setting aside a certain amount of time that people are going to work on it, then what often happens is it just never gets done.
GK: Something else always comes up that’s more important or more pressing. And if you haven’t thought about what resources do we want to put toward this, then it’s never going to happen. I think that’s also true if you don’t really have hard deadlines or a schedule in your plan that you’re working toward. Those two things, not having a set schedule and not having resources allocated, often can just stop a project in its tracks and delay it months, if not years at the time.
BS: Mm-hmm. I guess what would you say to a situation where you’re doing everything right as far as you know, and you know you’re doing everything that you’re supposed to be doing to move your strategy along, but things just aren’t going to plan?
GK: Well, I think the first thing I would say to that is that this is almost guaranteed to happen, so it’s really important to have backup plans when you make your initial plan. You know, there’s always going to be that ideal of how you think your strategy should go, but there are always external factors that come up that you will not be able to anticipate. But you can at least kind of think about if this sort of thing happens, here is how we would handle it on the front end. Then that way when those things do come up, you’re not just completely taken off track and you kind of have a bit of a game plan in mind for how you’re going to handle those things and it doesn’t just completely derail everything
BS: Right. Yeah, having those backup plans is essential, and also being able to look at projects and be able to say, “Okay, what, what can we isolate?” You know, “What is something that isn’t tied specifically to a dependency down the road?” It might be initial conversion of your content. It might be doing a content audit to at least get your arms around, “Okay, well what do we have to do to deal with? Even if we don’t have the resources to do anything with it, what are we looking at here? What’s the total scope? What are the types of things that need to be changed? What types of files need to be massaged a bit so that it makes conversion easier?” Something small on that scale can still keep the project going as you wait for other pieces to start moving.
GK: Yeah, I agree. One thing that I’ve seen really help companies, especially where the resources or the budget might be very stretched, is to kind of reduce that risk and plan things, and like you said, in those smaller chunks or in kind of more reasonable pieces and phases. I know that there’s one project that I worked on where they decided to do their implementation in these kind of small phases where they said, “We know that we can do each piece at a time and not feel like we’re biting off more than we can chew.”
GK: Whereas if they had tried to just go ahead and implement every single part of our strategy at once, they know that they would have gotten caught up in that sort of churn that can happen whenever things go off the rails and don’t go according to plan. By sort of taking that into account and knowing how things typically worked, they thought that the smarter thing to do would be to just kind of take it in reasonable, approachable pieces, and sort of do one thing at a time that they knew they could kind of get their arms around and keep their arms around as they were going through it.
GK: Another thing that I think is really helpful along those lines is the idea of doing a pilot project or proof of concept, because that can really help you look at sort of a small but essential piece of your strategy and see how that works, and then look at what does go wrong or what goes kind of in an unexpected direction during that pilot. Then use that to kind of help plan out your larger implementation more thoroughly, but without having invested everything up front. You can kind of see if something is going to go not quite according to plan, what kinds of things those might be by doing a pilot, and then you can say, “Oh, okay. Here’s how we need to course correct before we go forward to the rest of this and sort of expand it further.”
BS: Yeah, those small proofs of concept can come in really handy, too, when you’re, for lack of a better approach, if you have particular groups that you’re waiting to work with, but for whatever reason they’re stalling their engagement, those little proofs of concepts, it can be that little spark that keeps the project going or the spark that kindles some action on their side. It’s a lot easier to show someone this is what I’m thinking and this is how it works, and you can play with it and try to break it or do whatever you need to to kind of see where we’re going with this. Sometimes that approach is a lot easier than trying to get people in a room to talk theoretically about how something will be implemented. If they have something that they can play with, and use, and provide feedback on, it can sometimes move that project forward quicker.
GK: Absolutely. One case where I saw this actually work quite well was in a situation where there had been a really large merger and sort of series of mergers, where this company had kind of grown from having just the one content department to suddenly they had brought in these other companies that had their own documentation teams. They decided when they were doing this rebranding effort to kind of bring everything together, to just start with the one documentation team that was sort of pushing the project and that was the most motivated. They said, “We’re just going to convert this department’s manuals into XML, prove that this works, and then we can use that to convince all of these other groups that have their own sets of documentation, you know, this actually does work, and it’s safe for you to do this, and there’s not the huge risk that you think there is.”
GK: Whereas I think if they had tried to just go ahead and convert everything all at once up front, it would have been chaos. Because they had all of these groups that they had just basically been bought out and they already had a lot of stress they were under as a result of that, and they were kind of learning all of the new things that they had to learn by now having been acquired by this larger company. And so focusing on a major content overhaul at the same time I think would have been too much. But because they had this one group that wanted to go ahead and do it and just start small, that proof of concept was enough to start getting the other groups on board and having them one by one come through and say, “Okay, now we can do this piece of the content and go ahead and convert that.” Then that way, they were able to sort of tackle a rebranding piece by piece in a way that was not overwhelming.
BS: Another piece that goes along with that is just having regular, or sometimes even frequent, either meetings or at least communications going out to other groups that say, “Here is where we are. Here’s where things stand. Here are the next steps.” A lot of times, that really helps to one, keep people interested in what you’re doing, and also reminds them that they’re on the hook to share something at some point along the way.
GK: Yes, absolutely, and I think that if you don’t have those open lines of communication, then that’s another way that things can really go off the rails and destroy whatever original plan that you had for your strategy. I think that’s extremely important. It kind of depends on your company culture, but whether it is face-to-face meetings that are more effective or if you’re a distributed team, whether it’s having web meetings or even if there is a forum that you all post on. Whatever system works best for your company, I think it’s really important to have that in place and have some sort of regularity to it so that you are all kept accountable.
BS: Exactly.
GK: We’re going to wrap things up here, but look out for our next podcast episode where we continue our discussion of content strategy pitfalls around planning, this time talking about some best practices of how you should do your planning. Thank you, Bill.
BS: Thank you.
GK: And thank you all 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.
About the author
