Full transcript of Content strategy stakeholders 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 41 we discuss the stakeholders for content strategy projects. Who are the stakeholders? Why and how should you talk to them?

Alan Pringle:      Hey everybody, I’m Alan Pringle, and today I’m joined by Sarah O’Keefe and Bill Swallow.

Sarah O’Keefe: Hello.

Bill Swallow:      Hey everyone.

A. Pringle:            A few weeks ago I was talking to a potential customer and I was explaining our basic process for content strategy projects, how we come in and we talk to the project stakeholders. And I was mentioning some of the groups that make up those stakeholders, and the prospect asked, “Why would you want to talk to X group?”

A. Pringle:            I explained to her why, and then she understood, and that is basically the foundation of this podcast. It was a legitimate question. Why do you want to talk to different people when you’re doing a project, a content strategy project, how can you identify these people, and how do you communicate with them?

A. Pringle:            So we’re going to have a discussion about that today. First of all, let’s talk about who and what are stakeholders.

S. O’Keefe:          What is a stakeholder?

A. Pringle:            Right.

S. O’Keefe:          Well, I don’t know if I’ve ever thought about defining the word stakeholder, but a stakeholder is somebody who cares about your project in some way. That might mean that they’re the client, the person who’s actually running the project. They might be the person who’s responsible for funding the project–they have the money. And I guess importantly, it’s somebody who is affected by the project, has input to the project, and/or has the ability to veto the project.

A. Pringle:            Right. Has the money for the project. So we have a generic definition of what a stakeholder is. Let’s kind of hone in a little further on … Specifically on a content strategy project who might these people be for the project?

B. Swallow:         The one obvious one is the content creators. Those are the people who are going to be ultimately authoring content within whatever system and workflow you end up implementing. So whether it’s the full-time people who that’s their day job, is to sit down and write content, or it’s part-time contributors, so subject matter experts or third party people coming in and adding little bits of information, or people seeding information that the writers then turn into more finished pieces of work, those types of people.

S. O’Keefe:          Well, there’s the people creating the content, there’s the people consuming the content, so now you’re taking about the people that read the end product. They buy the product and then they read the content that goes with it, or they are buying the content that you are producing or licensing the content that you’re producing to use in their own systems or something like that.

S. O’Keefe:          So your consumers could be readers in the traditional sense of you produce a product or solution which has content that goes with it of some sort, or they could be a content creator in a different company that’s receiving and consuming that information.

S. O’Keefe:          So if I produce a white label product like a washing machine or something and I produce technical product content that goes with that, and then that goes downstream to the people that actually slap a brand on the washing machine and sell it in their particular stores, then the content creators inside the operation that does the branding are stakeholders because they’re deeply affected by how that content is being developed, managed, produced, et cetera, because they are processing it downstream.

A. Pringle:            Yeah. They’re ingesting it, right.

B. Swallow:         Yeah. By the same token, you also have internal people who might be consuming the content in a different way as well.

S. O’Keefe:          Yeah. The support team is very often a stakeholder.

B. Swallow:         Yeah, training and development.

S. O’Keefe:          They’re the first stakeholder.

A. Pringle:            Uh-huh (affirmative). Right. And even now, especially with product documentation, or documentation that is for your services, people are now looking at that before they even buy.

B. Swallow:         Oh, yeah.

A. Pringle:            So it’s not just the actual person who has licensed the stuff, it’s the person who’s thinking about buying or licensing that stuff, and that’s also another important angle as far as that goes.

S. O’Keefe:          Yeah. And I think support is very often overlooked as a stakeholder. They’re kind of interesting, because good content means that support can actually get their job done, so they’re kind of like a customer, but they’re an internal customer rather than an external customer. And if you deliver bad content to support, it makes their job much harder or impossible, so they can be very valuable in terms of understanding what their needs and their requirements are.

A. Pringle:            And to extend further on that point about support, I’m always amazed when talking to people who are writing product content, a lot of times they do not actually talk to the end users, the people who are buying the product or service and looking at that content.

A. Pringle:            However, the support team is going to hear the usually gripes … Not usually praise, but usually gripes about how bad that content is, or how good, usually bad, or how it didn’t help them in this particular case. They’re a good resource to help you figure out what’s working and what’s not. So not only are they a consumer in the sense of being an internal consumer, they are the interface to your external customer. So if you can’t talk directly to them, to your customer, talk to your support and get it indirectly. That’s the closest you’re going to get possibly.

B. Swallow:         Yeah.

S. O’Keefe:          So that’s kind of the two ends, right, the creation input and then the sort of output into things? And then in between that you’ve got a variety of other things, like your reviewers, who are typically not as engaged in the content because they just occasionally review it, although-

B. Swallow:         They might live in there too.

S. O’Keefe:          They might live in there, but more often reviewers are kind of a very part-time thing, and the people with the money.

B. Swallow:         Also the people in the middle, but also the localization people, because that’s also in between that supply chain, in between creation and deployment. So whether you’re using a third-party translation service or you have an internal group managing that process, they are stakeholders, whether they are part of your company or not.

A. Pringle:            Sure, and then kind of overarching all of that are the people in your IT department, because they are the ones who are controlling the infrastructure, the tools, and all of that for every single thing, including content creation and distribution in your company, so they absolutely have to be part of this conversation.

B. Swallow:         Right. I had a conversation once with a client who was trying to work with IT on basically getting their thumbs up to the executive branch to approve the money for a component content management system, and IT’s main argument was that, “Look, we’ve got SharePoint, we’ve got a web CMS, we have a tech support portal, and we’ve got all this stuff. Why can’t you use one of those? Why do you need yet another system?”

B. Swallow:         So if you can’t convince the IT group that you need a specific system and you can’t leverage what they already have, it makes it very difficult to get anywhere.

A. Pringle:            They’re doing their job.

B. Swallow:         They are doing their job.

A. Pringle:            Their job is to eliminate redundancy.

B. Swallow:         Yeah. Their job is not to be mean, I mean as much as we might think otherwise.

S. O’Keefe:          Well, and usually they’re … It’s interesting because they’re stakeholders in the sense that they are going to have to install, maintain, configure a system, provide the infrastructure, bandwidth, those kinds of things. But in other ways they’re really not a stakeholder. They’re actually more of a gate, because most large organizations have some sort of an enterprise architecture review board, which is what you’re talking about, which is where you go and say this is why I can’t use existing infrastructure, this is why I need a specialized CCMS system, this is why I need tools just for my content creators, and I can’t just use the standard sort of enterprise document office tools that are lying around, and the EAB typically has the power to say no.

S. O’Keefe:          They’re not a stakeholder exactly, right? I mean they’re not really engaged in the project necessarily, so they can shut it down.

B. Swallow:         Yeah. They have to support the system. You know, they have to spend human resources to manage that system over time. They need to deploy technical resources to store it, feed it memory, clean and purge their scratch systems every once in a while, update servers, you name it. Or you have a distributed team, they need to make sure that all of that can work seamlessly through the company network.

A. Pringle:            Right.

S. O’Keefe:          I mean I sometimes will look at this through the RACI model, R-A-C-I for the record, which basically just says–this is a pretty common concept that’s out there, it’s not ours–you look at who is responsible, as in who’s actually going to do the work? Who are the people on the ground who are going to code the thing, install the software, do the stuff? So that’s R.

S. O’Keefe:          But there’s accountable, which is presumably their management or an executive somewhere that’s accountable for the success or failure of the project. Then you have C for consulted and I for informed. So the people that are consulted are the ones that have input, that have feedback, that might have some constraints that would guide the project, and then there’s somebody that just gets informed, like this is what we’ve decided to do, just wanted to let you know. They don’t necessarily get to provide feedback in the form of I don’t want you to do it that way, but you want to keep them in the loop.

S. O’Keefe:          It can be very helpful to look at it from this point of view, or you can just simplify this down to who can veto it, who can derail it, and who are your supporters that can make it happen? Because if you have too many of the former and not enough of the latter, you’ve got a serious problem.

A. Pringle:            Right. And we’ve already touched on this a little bit, but I want to go to the question that the perspective customer would ask me is why? Why do you want to talk to all of these people? It’s a legitimate question, it really is, and it depends on the person, but I think that’s worth discussing a little bit.

S. O’Keefe:          So part of the answer is that in the real world things are not command and control. You don’t get to just say, “You people work for me and I’m going to tell you how it’s going to be,” and so therefore you just have to go along with it. There is a reason why we spend enormous amounts of time on change management and organizational development and all these other kinds of things. These projects are scary and complex, and you can’t just order people from the top down to just make it happen.

A. Pringle:            You can try.

S. O’Keefe:          Okay, you can. It’s not going to work.

A. Pringle:            Right.

S. O’Keefe:          So you have to get buy-in. I mean that’s just a horrific cliché, but you have to get buy-in from all these people and everybody has to agree that your goal is the right goal and that your strategy, your approach, is the right answer. Or if they don’t agree, that at least you’ve looked at all the other options and they understand why you went with that one, given the constraints in this organization.

S. O’Keefe:          So, you know, why do you want to go talk to IT? Because if you don’t, they’re going to tell sorry, we’re busy with SAP and we’ll talk to you in three years. And if you don’t go and talk to the executives, they’re going to go and pull your funding for some other project that they like better because they haven’t heard about your project.

S. O’Keefe:          If you don’t go talk to training, who I would consider to be typically sort of an auxiliary or supporting stakeholder, or whatever you want to call that, you’re going to discover that they have an LMS that’s completely incompatible with what you’re trying to do, or you have a requirement to deliver e-learning content down to the training people and you have no way of doing it because you didn’t account for that when you built the system, so that’s why.

A. Pringle:            Yeah. You cannot develop a solution that is going to hit all of the requirements if you don’t get feedback so you can understand the bigger picture.

B. Swallow:         Or you don’t understand what all the requirements are.

A. Pringle:            That too.

S. O’Keefe:          Yeah. Now I mean the flip side of that is if your list gets too long and too broad you’re going to have analysis paralysis and you’ll never get anything moving, and people will find ways to sandbag your project so that it doesn’t happen because there’s some other priority that they want that money for.

S. O’Keefe:          It’s really, really, really common to have a pot of, you know, $30 million available for strategic projects and there’s people asking for $300 million in projects, so at that point it literally does become a zero sum game. You know, if I get $5 million somebody else doesn’t get $5 million because there’s limited money to go around, and that can get a little political, right, where people are going to push their pet project no matter what, because that’s the one that they think is the most important. But doing this work and this conversation and this discussion around why this particular project matters is the only way to get that traction.

A. Pringle:            And to get that “why” question answered, you need the feedback and the input from all these different people.

B. Swallow:         Uh-huh (affirmative). Yeah.

A. Pringle:            So what’s the best way to communicate with these different people, because they’ve got different angles, different perspectives, so therefore it is not one size fits all?

B. Swallow:         You kind of have to put on your marketer hat and you have to tailor your pitches to all these different purposes. Your content authors are going to have very different concerns than your … Even with the content reviewers, but certainly the executives who are either holding your budget in their hands, or they otherwise have influence into other major projects that depend on your project’s success. They’re concerned about very different things.

A. Pringle:            Yeah. Don’t go to an executive talking about all the features of X and Y tools. I don’t recommend that in general, I really don’t.

B. Swallow:         No. They don’t care about the bells and whistles. They only care about how it feeds into their overall strategic goals.

S. O’Keefe:          It helps with time to market and that kind of thing, or … I mean I’ve told this story before. I had a meeting with an executive where I asked the executive something along the general lines of what markets are you going into? What languages are you concerned about? And the executive said, “Well, we’re working on this huge project in a particular country, and if it happens we will have to translate everything into that language to support this big project.”

S. O’Keefe:          Well, the content creators either didn’t know or didn’t care about the huge possible project and were dead set on a solution that would not support the language that the CEO was telling me would be an absolute requirement if this project went through. So the content creators were saying, “Oh, we want to do it this way,” with sort of limited language support and limited possibilities to expand language support, and the CEO is saying, “Well, if X happens we’ll need this language.”

S. O’Keefe:          So I’m now in the position of going back to the content creators and saying, “Your CEO’s priorities are different from yours and we have to account for them,” and they really, really, really didn’t want to, which I feel like is as a general rule not a good strategy, you know, ignoring your CEO’s priorities.

B. Swallow:         Yeah. It’s generally not a good idea.

S. O’Keefe:          Not the best strategy.

A. Pringle:            I think that’s a very good way to wrap this up. I mean the bottom line is you’re not going to get good requirements, you’re not going to pick the right solution, if you don’t have all this input from all these different people.

B. Swallow:         Right. And you have to weigh it all accordingly.

S. O’Keefe:          And weigh it on whether it’s real or personal preference-

B. Swallow:         That’s a big one.

S. O’Keefe:          … to leave upon a negative note.

A. Pringle:            That’s not so negative. It’s realistic. So on that realistic note … Listen, I’m being positive. I’m not usually the positive one here, we’re going to wrap it up. Thank you Bill and Sarah.

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.