Getting Everyone on Board: How to Win Buy-In for Single-Source Publishing

Show don't tell!

I've found that projects like single sourcing can be difficult to sell internally. There are misconceptions about what it takes to get great documentation and while the cost isn't significant in comparison to other major internal system projects, it's still a cost.

In my experience the major cost isn't a financial one. The ship is sailing so to speak, it's got half the crew with their fingers in holes blocking a leaks, but it's still afloat. Implementing a new CRM, moving from Microsoft Dynamics to Oracle for example is an easy sell in comparison.

In the hypothetical Navy I've just created, a CRM swap out is like convincing the Admiralty to fund a new Aircraft carrier. "This one is faster Ma'am, it's got more planes, bigger guns and it'll be cheaper to run". A project like single sourcing is harder. This is more akin to saying. "I can make your entire fleet faster but you'll need to go without fuel for a few months." I won't call it tech debt here but if your key stakeholder is the CTO, it'll be a good start.

Even the most dedicated technical writer has to admit that discussing the finer points of the most efficient way to handle SKU's changing in the product range isn't the most invigorating of subjects. In this example I'd start with a question. How much time does the service desk spend answering field service calls about part numbers? What do we spend in logistics costs on incorrect parts being shipped. I guarantee the leadership in the Operations and Logistics team will know the answer. They may not know how single sourcing can help.

I summarised the top line in my previous post From Chaos to Clarity: How Single-Source Multi-Channel Publishing can set you up for success. but I wanted to go into more detail about getting stakeholders onboard in this post.

Investigate

The chances are you already know what can be done with a project like this, hence reading this blog, but it's really important to gather feedback and pain points from others. Before pitching, gather specifics.

Volume of Content: Where does information live? Product information is a pretty vague term on the surface and can cover anything from the service support telephone number to wiring guides for hardware. Cover it all. Put yourself in the mind of colleagues and customers. Ask yourself a question then go and find the answer. You'll need to know what existing tools you're dealing with for the implementation stage but assessing what is where and how much of it there is is step one.

Duplication Rate: How often is the same content repeated in multiple places? This is closely link to the step above. When you asks the questions about the available information don't stop when you get one answer. See you if can find it in another place. Even better if you can find a contradiction. Record the questions, the answers and the source. You'll need them later. This is a good time to extend that search outside of what you might consider writing tools or even places that information is usually stored.

In every team, department or business there is always an oracle. Depending on the size there might even be a few. That person that's been around for years and just knows the answer. They'll usually be able to dig up an email or run a script that tells exactly what you need to know. Check your questions with them. Ask them what they got asked in the last 6 months. You'll meet the odd knowledge hoarder but in most cases these people will be very busy so saying "I want to know what you get asked all the time so that it's the last time you have to answer that question" will be music to their ears.

Error Impact: What’s the cost of incorrect documentation? This is the hardest and easiest piece to give guidance on. It's the hardest because the impact of erroneous documentation on different sectors is impossible to compare. Quantifying and showing that to the stakeholder in a project is down to you. It's the easiest because it's the most obvious. When you're looking to get buy in though, don't stop at what you know to be the impact. As I said earlier, speak to team and department leaders about pain points. They'll tell you what incorrect information costs their team. Compliance is a core part of all business activity and even more so in regulated industries. When looking at impact, ask yourself what could happen "if" we got this wrong. Compliance is a great place to go looking for numbers. Regulators and governing bodies will have a lot of details on the fines if you are to fall foul of the required standards.

Update Frequency: How often do product changes require documentation updates? How often is a good question. A better question is how quickly do we have to turn it around. What's the deadline. If you work with a cloud platform, how long have you got between getting a finished version to look at and it going live. Hardware raises a similar question. What's the lead time for a new part with a new part number and config requirements hitting the build line. The answer is not much. It's always not much. If a component. driver or plug in changes, can you get that out to everyone who needs it in a way they can use fast enough without single sourcing.

Channels: Where does content need to go? PDFs, web, internal portals, AI assistants? If you are not already using single sourcing then it probably means for every destination there's another person. Another person will need time to do their bit, impacting on update timelines. If you've got tech writers creating PDF's to send to one place and word docs so marketing can post on the website take note. Ok, it might only be an extra email or a link to share the finished content but a key thing to consider at this point is how that gets updated. PDF's and links float around like bad smells. You can't guarantee an update that's been created is the one being used.

Presenting your findings

Here's some bullet points to help collate the investigation stage.

• Explain that the goal isn’t just to “fix documentation” it’s to solve real business problems.

• Where does product information live?

• Highlight the complexity of existing process.

• Show examples of duplicated or contradictory content.

• Explain why duplication means risk (errors, wasted time, compliance issues).

• Highlight the "Oracle" Every team has experts who “just know” the answers.

  • Position the project as a way to stop them answering the same thing forever.

• What does incorrect documentation cost?

• Show urgency in line with changes and updates

• Show risk in :

  • PDFs and links floating around. Updates aren’t guaranteed to reach everyone.

  • Delayed knowledge transfer. Every channel is another person, another delay.

• Position the solution:

  • Update once, publish everywhere.

  • Reduce duplication and errors.

  • Improve speed and compliance.