Tool Or Trap? Find The Problem, Then The Platform Content Operations podcast

Content provided by Scriptorium - The Content Strategy Experts. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Scriptorium - The Content Strategy Experts or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.

Content Operations »
Tool or trap? Find the problem, then the platform

5d ago 13:25

MP3•Episode home

Tempted to jump straight to a new tool to solve your content problems? In this episode, Alan Pringle and Bill Swallow share real-world stories that show how premature solutioning without proper analysis can lead to costly misalignment, poor adoption, and missed opportunities for company-wide operational improvement.

Bill Swallow: On paper, it looked like a perfect solution. But everyone, including the people who greenlit the project, hated it. Absolutely hated it. Why? It was difficult to use, very slow, and very buggy. Sometimes it would crash and leave processes running, so you couldn’t relaunch it. There was no easy way to use it. So everyone bypassed using it at every opportunity.
Alan Pringle: It sounds to me like there was a bit of a fixation. This product checked all the boxes without actually doing any in-depth analysis of what was needed, much less actually thinking about what users needed and how that product could fill those needs.

Related links:

How humans drive content operations (recorded webinar & transcript)
Brewing a better content strategy through single sourcing (podcast)
The Scriptorium approach to content strategy
Get monthly insights on structured content, futureproof content operations, and more with our Illuminations newsletter

LinkedIn:

Transcript:

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky, you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and process that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Bill Swallow: Hi, I’m Bill Swallow

Alan Pringle: And I’m Alan Pringle.

BS: And in this episode we’re going to talk about the pitfalls of putting solutioning before doing proper analysis. And Alan, I’m going to kick this right off to you. Why should you not put solutioning before doing proper analysis?

AP: Well, it’s very shortsighted and oftentimes it means you’re not going to get the funding that you need to do the project to solve the problems that you have. And with that, we can wrap this podcast up because there’s not a whole lot more to talk about here, really. But no, seriously, we do need to dive into this. It is very easy to fall into the trap of taking a tool’s first point of view. You’ve got a problem, it’s really weighing on you. So it’s not unusual for a mind to go, this tool will fix this problem, but it’s really not the way to go. You need to go back many steps, shut that part of your brain off and start doing analysis. And Bill, you’ve got an example, I believe, of how taking a tool’s first point of view didn’t help back in a previous job you had.

BS: I do, and I’m not going to bury the lead here, but they didn’t do their homework upfront to see how people would use the system. So I worked for a company many, many, many years ago that decided to roll out and I will name the product. They rolled out Lotus Notes.

AP: You’re killing me. That’s also very old, but we won’t discuss that angle.

BS: But they did so because it checked every single box, every single box on the needs list, it did email, it had calendar entries, it did messaging, notes, documents, linking, sharing, robust permissions, and you even had the ability to create mini portals for different departments and projects. So on paper, it looked like a perfect solution. And everyone, including the people who greenlit the implementation of Lotus Notes, hated it. Absolutely hated it. Why did they hate it? It was difficult to use. It was very slow. It was very buggy. Sometimes it would crash and leave processes running, so you couldn’t relaunch it. There was no easy way to use it. Back at that point, we had PDAs, personal digital assistants, and very soon after that we had the birth of the smartphone. There was no easy way to use it in these mobile devices except for maybe hooking up to email. It didn’t fit how we were working at all. While it shouldn’t count, it really wasn’t very pretty to look at either. So everyone bypassed using it at every opportunity. They would set up a Wiki instead of using the Lotus Notes document or notes portal that they had. They would use other messaging services. This is back during Yahoo Messenger and ICQ. But yes, we had that going on and in the end it was discontinued after its initial three-year maintenance period ended because nobody liked it.

AP: Yeah, so sounds to me like there was a bit of a fixation. This product checks all the boxes without actually doing any in-depth analysis of what you needed, much less actually thinking about what users needed and how that product could fill those needs. And I think it’s worth noting too, think about this from an IT department point of view, because they’re often a partner on any kind of technology project, especially if new software is going to be involved because they’re going to be the ones a lot of times that say yay or nay, this tool is a duplicate of what we already have. Or no, you have some special requirements and we do need to buy a new system. So if I as an IT person, the person who vets tools hears from someone, and let’s get back into the content world, I need a way to do content management and I need to have a single source of truth and I need to be able to take the content that is my single source of truth and then publish to a bunch of different formats. This is a very common use case. I would be more interested as an IT person in hearing that than hearing I have to have a component content management system. There’s a subtle difference there. And I think, and this is possibly unfair and grouchy of me, but that is me, grouchy and unfair. If I hear someone come to me, I need this tool instead of I have these issues and I have these requirements. It sounds selfish and half-baked.

BS: It does.

AP: And again, I am thinking about this from the receiving end of these queries, of these requests, but I also want to step back into the shoes of the person making a request. You can be so frustrated by your inefficiency and your problems, you latch onto the tools. So I completely understand why you want to do that, but you are basically punching yourself in the face when you go and make a request that is, I need this tool instead of I have these issues, these requirements, and I need to address these things. It’s subtle, but it’s different.

BS: It’s very different. And also if you do take that approach of looking at your needs, you find that there’s more to uncover than just fixing the technological problem itself.

AP: Yes.

BS: There might be a workflow problem in your company that you may acknowledge, you may not know it’s quite there. Once you start looking at the requirements and looking at the flow of how you need to work, and how you need any type of new system to work, you start seeing where the holes are in your organization. Who does what? What does a handoff look like? Is it recorded? What does the review process look like? When does it go out for formal review? What does the translation workflow look like? And you start seeing that there may be a lot of ad hoc processes in place currently that could be fixed as well.

AP: True. And I also think when you’re talking about solving problems and developing your requirements from that problem solving, you are potentially opening up the solution to more than just your department, your group. It can possibly be a wider situation there, too. And also by presenting it as a set of problems and requirements to address those problems, there may be already a tool in-house at your company that you don’t know about or there may be part of a suite of tools, and if you add another component to it will address your problem instead of just buying something completely outright. And we’ve seen this before, where it turned out there was an incumbent vendor that had some related tools already at the company, and that company also had a tool that could solve the problems that our client had or our prospect had. We’ve had both prospects and clients have this issue, so it doesn’t make sense, therefore, to go and say, I need this tool, which is essentially a competitor of what’s already in place. You’re going to have a very uphill battle trying to get that in place. It is also very easy, as someone who has already done a content ops improvement project, to understand this tool is good. It saves me at this company, but you’ve got to be careful of thinking just because it helped you over at company A. Now you’re at company B, it may not be a fit for company B culturally, there may be already something in-house. So you’ve got to let go of those preconceived notions. I am not saying that the tool you used before was bad. It may be the greatest thing ever, but there may be cultural issues, political issues, and even IT tech issues that mean you cannot pick that tool. So why are you pushing on it when you have got all of these things against you? Again, it is easy to fall into these traps. Don’t do it.

BS: Yep. On the flip side of that, we had a situation where a customer of ours years ago was looking for a particular system, a CCMS, component content management system, and they had what they perceived to be a very hard requirement of being able to connect to another very specific system.

AP: Yes, I remember this. It was about 10 or 11 years ago.

BS: And it was such a hard requirement that it basically threw out all of their options except for one. And we got the system working the way they needed it to. It needed quite a bit of customization, especially over the years as their requirements grew. But in the end, they never connected to that requirement system. The one that everyone said this would be a showstopper. They never connected to it because they just decided it wasn’t a requirement after X many years. And that just kills me because there could have been three or four other candidate systems that would’ve easily have fit the bill for them as well and probably would’ve cost them a little bit less money. But there we are.

AP: In fairness, all parties involved, including us, we’re working on the information that we had at the time. And I think this is a case where a requirement that we thought was a hard requirement turned out not to be. However, just because this happened in this case, folks out there listening to us, that does not mean that if a particular requirement points at a particular system that it could be not a real requirement because you want another system really badly. So you want to ignore that really hard, not how that works. It’s not how that should work. So I think there is a balance here that needs to be struck, and I think this is probably a good closing message. Don’t follow your knee-jerk instinct in regard to, I need this tool. Really look at the requirements, do an analysis. And because we’re humans, sometimes that analysis is not going to catch other things that it should have. Or you may end up having, like you just mentioned, a requirement that that’s not necessarily as real as you thought that it was. But I think your chance at project success and getting a tool purchased can configure and up and running are much higher when you start with those requirements than you start off with, I need tool Y.

BS: Well said. Do the homework before the test.

AP: And don’t put the cart before the horse.

BS: Well, thank you, Alan.

AP: Thank you. This was shorter, but it’s an important thing, and I think, again, this points to any kind of operational change being a human problem and dealing with people’s emotions and their instincts as much or more than an actual technological issue.

CC: Thank you for listening to Content Operations by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

Need to talk about content solutioning? Contact us!

The post Tool or trap? Find the problem, then the platform appeared first on Scriptorium.

194 episodes

#Business #Content Strategy #Scriptorium The Content Strategy Experts