The true cost of quick fixes (podcast, part 1)

Gretyl Kinsey / Podcast, Podcast transcriptLeave a Comment

In episode 78 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow talk about the true cost of quick fixes in your content strategy.

“Even if a quick fix might save you some time or a little bit of upfront cost or upfront effort on planning, it’s almost always going to add costs in the long run.”

—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 this episode, we’ll be talking about the true cost of quick fixes and common issues that might lead an organization to taking this kind of bandaid approach to content strategy. This is part one of a two-part podcast.

GK:     Hello and welcome everybody. I’m Gretyl Kinsey.

Bill Swallow:     Hi, I’m Bill Swallow.

GK:     And we’re going to be talking about quick fixes in your content strategy today, and how that can lead to all kinds of issues down the road. So I think the place to start is just talking about what we mean by quick fixes.

BS:     And that can be pretty much anything that doesn’t fit the greater plan. Doing things that kind of make things fit or responding to an immediate need with an ad-hoc approach to getting something done.

GK:     Yeah, absolutely. And I think we’ve both seen plenty of examples of this happen. Even if you’ve gotten a really solid plan together for your content strategy, there are oftentimes things that just pop up that do go outside of that plan. And so then it’s often really tempting to sort of apply this quick fix to get you through it. So what are some examples that you’ve seen of these kinds of quick fixes?

BS:     One that jumps right out is formatting abuse. So whether you’re working in structured content or not, ignoring any styles or any elements or whatever you’re using, and just kind of using whatever feels right to you in order to make things look or behave a certain way rather than following what the styles should be.

GK:     Right. And I’ve seen this, like you said, both in structured and unstructured content. And so from the structured side of things, that’s usually going to be a situation where you’ve got some sort of separation between your content itself and your formatting. But if you are used to working where you’ve got that control over the formatting, and then you suddenly don’t have that anymore when you go to structure, I’ve seen people do this tag abuse thing where they will use a tag in a way that is technically legal within the structure, but it is trying to control formatting. And then that can have all kinds of unintended consequences across your actual transformation processes that produce your output. But that’s just a very common thing that people will say, “Oh, I need a page break here, or I need a table to look like this here.” And they do something that’s just a tag abuse thing to get it out the door.

GK:     And from the unstructured point of view too, I’ve seen people do what I would call template abuse. And so that would be things like, for example, in InDesign, instead of all of the predetermined styles, maybe applying one but then making a little tweak to it, like making the text italic or something, or making it a slightly different size, or not connecting text frames together when they should be connected together just because you’re trying to get something to lay out and look right on a page, but you’re actually making the whole document break. And same thing in FrameMaker as well, similar to what you might do in an InDesign template. If you’re an unstructured FrameMaker, I’ve seen people do that same thing where they’re ignoring the formatting that was built into that template and overriding it with lots of little formatting tweaks here and there just to get one page perfect. But then later, if somebody makes an update and it blows away all of these little formatting tweaks, then that person would have to go back and make them again. And so that’s when a quick fix doesn’t become so quick.

BS:     Oh yeah. And there’s nothing quite like opening up a Word document and seeing everything being tagged with normal asterisk. Especially when you’re trying to do a quick rebranding job and you realize that your four page document is going to take you about eight hours to change. Especially if you’re changing fonts and sizes, colors, that type of thing. Once you start introducing a lot of these ad-hoc quick fixes, the more work you’re creating for yourself down the road.

GK:     Yeah, absolutely. Another thing that this is kind of more specific to structured content, and I think particularly to DITA, is something that we at Scriptorium call spaghetti reuse. And that is basically when instead of coming up with a reuse plan and putting all of your reusable content into warehouse topics and putting them all in one place where people know where to get them, instead what people will do is maybe conref in a piece of information ad-hoc from another topic. And then you suddenly get this tangled web of reuse that’s impossible to track. And that’s done as a quick fix because if you know that you should be reusing content, but you haven’t made a plan for it, and suddenly you need to get this content out, that might be a tempting thing to do, but then it’s, just like with the tag and template abuse, it’s just going to create a lot more problems later when somebody comes in and needs to fix it.

BS:     Oh yeah. If you’re working, especially creating new maps for new deliverables and you’re bringing topics in to build your map out and to build your document or your help system or whatever you’re producing out of DITA, once you start pulling those maps in, you’re going to find that you have all of these missing links all throughout your content to other topics that you didn’t want to include in your map file. And now you’re stuck either having to stop what you’re doing and create these warehouse topics so that you can do it correctly, or what I’ve also seen is that people just grab the topic that they need, dump it in the map and set it to resource only, just so they can resolve that conflict in a hurry. And that creates another issue down the road with more spaghetti reuse.

GK:     Absolutely. So that again, points to this idea that it’s always better to go ahead and build in that time up front to make that plan, instead of just going the quick fix route, because it’s not quick later when you have to go back and clean up the mess you’ve made. Something else that can also cause a problem like this, and this is more for if you’re working in an unstructured environment, but heavy use of copy and paste, and then if you do get into structure and you do have reuse capability, but you are in the habit of heavy use and copy and paste, still going ahead and doing that can be a real problem. That’s even worse than the spaghetti reuse if you’re in a structured content environment, like DITA, but you’re still copying and pasting everywhere and you’re not making use of that reuse potential that you now have.

BS:     Yep. And copying and pasting really creates two really fundamental and horrible problems. One is if you need to update that content, god knows how many places you’re going to have to go looking to fix that content. Even though it’s exactly the same in all places, you’re going to have to make the fix in all places. Likewise, on a localization angle, you’re just throwing money out the window if you constantly have stuff copied and pasted all around, especially if people are then modifying what’s been copied and pasted because they don’t particularly like the wording in this certain instance or they forgot to update it in one place. Then you start getting all of these fuzzy matches going into your localization workflow, and you’re throwing money at a problem that shouldn’t be there in the first place.

GK:     Absolutely. Another example of a quick fix is having multiple variants of the same output type to satisfy immediate needs. So for example, if you are generating PDF output, let’s say, from a collection of DITA topic files, maybe you realize, “Oh, I need a PDF with this particular cover variant and I need another PDF over here with this one for different audiences.” There are ways in your PDF transform to build things in where there’s a switch based on your audience or based on the product that that content goes with or what have you. But instead, maybe you decide that the quicker fix is to just basically copy over that transform and make that one little adjustment when you could have just had it all working in one single transform. And we’ve definitely seen that come up as an issue as well, and the problem there is that you are just kind of creating this ballooning effect of your outputs. So instead of having one output transformation that can do a variety of things, you’ve got multiple transforms for all these different variants when you didn’t really need it.

BS:     Oh yeah. And the same goes for on the unstructured side, especially with an InDesign and FrameMaker and other applications that allow you to use … Well, I’m going to use a FrameMaker term, but to use master pages for your layout.

GK:     Yes.

BS:     A lot of times I’ve seen people create multiple templates just to satisfy either different page sizes or different cover pages, as you mentioned Gretyl, and they ended up having to apply these templates over and over again to their files just to generate new output when they could go in and just select a different master page and allow the document to reflow into whatever that new layout needs to be.

GK:     Yeah. And again, this is just one of those things where a little bit of planning upfront could have gone a long way and saved you all of that trouble, and all of that ballooning effect of having all these different ways to produce your output when you could have gone with something much more efficient. And if you realized that that’s a problem and you need to clean it up, it’s kind of like all of these other quick fix examples, that you’ve made a mess that could have been avoidable, and now someone has to put in the time and the effort to go back in and clean that up.

BS:     Well now that we talked about some of these quick fixes that are out there, what are some common issues that might lead a company to implement a quick fix rather than do it the right way?

GK:     So one of the most common, and I think most obvious issues that we run into, is just pressure from deadlines and release schedules and things like that. You’ve got a product that has to go out the door by a certain date, or you’ve got an update to your product that has to go out by a certain date, you’ve got content that has to go out with that product. If you are localizing, you’ve got those deadlines too. So that is a big source of why people cave to the pressure of these quick fixes. Because if you are looking at a limited window of time where you’ve got a choice between, “Do I do things the right way or do I do things in a way that works, maybe not ideally, but still gets my product out the door on time?” Then that’s the one they’re going to pick. So it’s a tough situation. And again, it gets back to this idea of planning more up front, but sometimes there are scenarios where you just don’t have the time to do that properly. And so what generally will happen is a company will say, “Okay, well, it’s going to be just strictly from a cost benefit analysis perspective, better to do what we have to do to get it out the door and then go back and fix it later when we’re not under that deadline pressure.”

BS:     And you always have that extra time after a project to go back and rework and do it the right way, right?

GK:     Oh yeah, of course. No you don’t. That’s one of the pitfalls of this is that you think, once we get over this one hurdle of this deadline, then we can go back and fix it, but there are usually other deadlines coming up, and even if you’ve got long cycles between your releases, if you’re not on that typical two week sprint schedule that a lot of companies have, you still may have something unexpected that pops up. You may have somebody in a different department say, “Hey, we’re going to introduce a new project over here. And guess what all that time you thought you had to fix your mistake, your quick fix, that’s all gone. And so, this is really a tough problem that there’s not always a great solution to, but I think if you’ve got the time to plan up front, that that’s really the best way to get around this, because once you kind of get in that quick fix mindset, it becomes a perpetuating cycle that’s very hard to break out of.

BS:     Yeah. And it snowballs to a point where once you do have to do something different with your content, whether it’s a rebranding effort, whether you’re switching tools, whether you’re doing whatever. If there’s something large scale that you need to change in your content, the more quick fixes that you have in there the tougher it’s going to be to work around them to get anything done on that larger effort.

GK:     Yeah. The tougher and the more expensive, because if you’re doing something like converting your content from one format to another, or rebranding or making some sort of large scale terminology update, anything like that that affects basically all of your content set, then the more consistent your content is, and the less full of these kinds of little quick fix tweaks that it has, then it’s going to be a lot more of a smooth process to convert it or change it, update it, whatever. If you are faced with deadline pressure and it’s absolutely imperative that you have to change the content or convert it or whatever, then you’re looking at a pretty big price tag because you’re not only making a lot of major updates and kind of getting all of those consequences of your quick fixes out of there. But you’re also having to do that under a tight deadline, which is probably what got you in the quick fix boat in the first place. So that’s something to keep in mind is that there is going to be … Doing anything on a quick deadline, that usually means there’s going to be a bigger cost for that turnaround.

BS:     Absolutely. And speaking of cost and cost comes down to two things, time and money. Either you don’t have the time personnel wise to get something done right the first time, or you just don’t have the funding to either go back and revisit, or you don’t have the funding to pick up, let’s say you’re doing something ad-hoc in a tool that is not really well designed for your needs, and you don’t have the funding to actually buy the tool that you do need that would satisfy all this rework that you’re doing constantly. It can be difficult to be able to either get that budget or be able to secure that time to do things in a more efficient manner.

GK:     Yeah, absolutely. So if you do have that limited funding or limited resources to really build out the ideal solution that you want, it makes it kind of hard to think about your planning. And I think this is an issue that I’ve seen with a few clients, or maybe more than a few, where one of the challenges they ran into was just a lack of longterm planning or the ability to do longterm planning.

GK:     Whenever we’ve come in to help companies develop a strategy. One of the things we do is to encourage them to not just focus on the present, but also the future and think about what are your goals for right now versus what are your goals for two, three, five, 10 years down the line? But if they are working with really limited budget, really limited resources and even kind of an unpredictability factor in how much budget they’re going to get from year to year, that can make it really difficult to ask and answer that question of where might you be five years down the road, and what are your ultimate business goals?

GK:     So I think it’s important to be flexible in that area and still plan for it as best you can so that you can avoid falling into this rabbit hole of making quick fixes and just having that become your only strategy. But it does kind of become understandable when you look at this problem of limited funding and limited resources, why so many companies end up taking that quick fix route.

BS:     Another area we can get a lot of quick fixes creeping in are if your writers aren’t properly trained to use the tools that they need to use to get the job done, or if they are not well trained in the types of publishing that need to happen from those tools.

GK:     Yeah, absolutely. And I think, in some cases, it’s not always just a lack of training, but it can sometimes be an active avoidance of a steep learning curve, and that’s where I think it’s really important. And we’ve talked about this in some of our other podcasts and blog posts, but it is so important to customize your training to what your writers and other content creators need to make sure that nobody is getting left behind, to make sure that people are not feeling resentful about the changes that are now in their kind of day-to-day working life, because that is a really big concern, and when you’ve got this whole different way of creating content, it can be very difficult to learn.

GK:     So if you want to avoid people coming up with quick fixes with work arounds, with some sort of way of doing things that they find easy but that isn’t necessarily correct, then it’s really important to make sure that they get not just a one size fits all training, but custom training, maybe ongoing training or support to make sure that they can do their jobs correctly.

BS:     And in addition to that, if you find that either after training or if there are enough writers that refuse to do it the right way for whatever reason, or that cannot do it the right way for whatever reason, you probably picked the wrong tools. In which case, then you’re going to have to go back. That also speaks to the longterm planning. You chose a tool based on its capabilities and not necessarily the wants or needs of your staff.

GK:     Yeah. And that’s something as well that I’ve seen, that even the tool selection itself can sometimes have a quick fix approach that gets you in trouble later, and that has a lot of consequences down the road. So that’s where it is really important, kind of like we talked about previously without that longterm planning, whatever limitations that you may have with budget resources, it is still really important to think about your future needs and to make sure that your tools and your strategy are going to truly serve your company’s business goals and make the actual work that your writers and content creators are doing more efficient.

GK:     And one other area that kind of ties into this idea of training and knowledge is that we’ve seen some people, specifically in DITA workflows, apply quick fixes just because they didn’t know about a DITA feature that would have let you avoid it. There is a lot of very particular weird twisty stuff out there in DITA that is kind of considered more advanced, and a lot of times if you just have that basic level of training in DITA, you wouldn’t know about it. And in particular, I think there are some of the reuse mechanisms that are available, that a lot of times people have come up with some sort of a workaround just because they didn’t know it existed. Things like conref push for instance, and in some cases, even just the use of keys or the use of conkeyrefs. People will come up with some sort of quick fix to solve a problem that there was already a DITA mechanism in place that would have just automatically solved it. And so again, that’s where getting into not just training, but looking at what kinds of things you need to do with your content, talking those through and making sure that you haven’t overlooked some aspect of DITA that could solve that problem can help you avoid those quick fixes.

BS:     Oh yeah. I’ve seen a lot of cases where people even use tables for formatting in DITA in a specific way, which gives it a completely non-semantic markup, whereas they probably would have wanted to use maybe a definition list or maybe they’d use a glossentry or something like that that gives it a little bit more meaning as to the context of what your content is rather than just slapping it in a table and removing all borders.

GK:     Yeah. And that’s kind of a holdover, I think, from folks who have been trained in more desktop publishing oriented content development processes. Then they get into DITA, and they don’t realize that there are all of these features of structure that would let them accomplish something that previously they would have had to use maybe a table or some other kind of weird formatting to achieve, that now they don’t have to do it that way, but they may just not know. And they may be kind of … going back to things that they are familiar with if they haven’t gotten that proper training.

GK:     So I think to wrap up, we’ve already touched a little bit on this, but I want to talk about the consequences of relying on quick fixes. And I think the two major ones that we’ve touched on a few different times throughout this podcast, one is that it makes a huge mess, and eventually when there’s some sort of pressing need to have things set up the right way, then you have to go back in and clean up that mess if you have relied on quick fixes.

BS:     Oh yeah. And that can take ages depending on how much content you have.

GK:     Absolutely. And then of course, the other big consequence that we’ve mentioned as well is that it adds cost in the long run. So even if a quick fix might save you some time or might save you a little bit of upfront cost or upfront effort on planning, it’s almost always going to add costs in the long run to do a quick fix. Because even if you just start with one small, quick fix now, as that gets expanded and propagated across all of your content over time, that is going to just really blow up that one small, quick fix into an expansion of quick fixes everywhere. And so then if you have to clean that up later, that cost is going to be huge, and it’s something that could have been avoided upfront if you had not gone that quick fix route.

BS:     Absolutely. And to add one more thing in here, you could be doing everything right, you could be planning for the long term, you could have carefully chosen your tools, trained your team, everyone’s following exactly how they need to be working, and then a request comes in for a one off document or a one off deliverable that’s never going to be used again. And you decide to throw caution to the wind and just get it done quick and dirty. And then suddenly that one off document becomes something that you carry forward with you for years and years and years updating and so forth. And if you do it wrong the first time, or if you make those quick fixes and do some ad-hoc formatting or whatever else, you then have to carry that forward. And it becomes more and more difficult to get that one off document that somehow has turned into a sustained need, which they usually do. It’s harder to bring that back into the fold of the other things that you might be doing the way you need to.

GK:     Yeah, absolutely. And that problem can become even more of a headache when that one document that you have done as a one off not only has to be carried forward, but maybe they decide that that’s going to be the basis for how you want to do a whole lot of other documents. You develop new products and they go, “Oh, this document structure worked really well. Let’s take that to five, six, 10 different products.” And so now a mistake that you’ve made has just really blown up, and it’s become the standard. And so to get that mistake out is going to just really be a nightmare.

BS:     Or, “Oh, they’re just release notes. Don’t worry about it.”

GK:     So we’re going to wrap this up here. This is going to be a two-part podcast, and the next one is going to focus on the solutions to quick fixes. Because in this one, I think we’ve talked a lot about the problems, but in the next one we want to focus more on the positive side of how you can avoid these in the first place. And if you do end up doing them, how you can solve those with hopefully as little of a headache as possible. So thank you, Bill for joining me today.

BS:     Thank you.

GK:     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.

 

About the Author

Gretyl Kinsey

Twitter

Technical Consultant. Content strategy, tech comm, and LearningDITA. Musician, cosplayer, and devourer of delicious desserts.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.