By Todd DeLuca | Senior Member
Introduction to the Problem
Do you know what happens to your content after you finish producing it? How confident are you that your audience receives it in a timely manner?
My guess is that there are times when technical communicators have put effort into a project or produced great content, only to discover that the people who were expected to get it either didn’t receive it or know it was available. Or maybe you still get questions asking where your content is or when you’re going to post it (even though it’s already been published and available for some time).
Our technical communication team was encountering these situations often enough that it warranted a closer look to see if there was a more effective way to make sure our audiences knew when and where to find the content that our team produced. We focus on software release documentation, so the content is both timely and critical for clients and support staff who need to understand software changes that impact their environments.
What was the problem?
During this inspection to learn more, we discovered that there were unexpected gaps between when content was completed and when the intended audience finally received or learned about it. We had assumed there was a clear hand off of documentation, but found out that the messaging for content availability varied, depending on who was leading a particular project or release. As a result, we received questions from people in the company who didn’t know when or where to find content, even though the material was consistently posted and available in the same location. It turns out we weren’t getting the word out quickly enough for stakeholders and we needed to bridge the communication gap, because what’s the point in having great content if people don’t know about it?
What did we learn?
Our first concern was that maybe material was getting lost, posted to the wrong location, or maybe even deleted. For those conditions, we checked directories and links we provided and confirmed that the content was where it was expected to be and that people could access it. We next checked with our stakeholders to see if we could find the problem.
Initially, we thought that maybe our audience never understood or learned where we kept the content (and couldn’t find it). However, with some polling and research we learned that in most cases they knew where to find content, but simply were not aware that new content was recently posted and available for them to review or retrieve. It came down to an issue of prioritization and communication. People are busy, they skim stuff, they don’t pay attention, they multitask, and messages get lost or glossed over. Additionally, we found out that our readers prefer to be told what’s happening and that they want easy, quick access to material—they’re a group that has a lot going on and they don’t have the time or inclination to self-serve and go looking for documentation.
This discovery was a mixed bag. We were successfully doing our job of producing and providing good content, but there was a gap such that the message of availability of the content was not consistently making it through to our audience. Clearly we needed to reset our assumptions and expectations if we were going to make progress toward closing the gap.
Fortunately, this was an excellent opportunity for our technical communication team to expand beyond our more traditional responsibilities and gain recognition for identifying and addressing a known problem. Since the core issue was primarily a communication problem, we already had the necessary skills and experience to implement a workable solution.
What was the solution?
So how did we bridge this communication gap and spread the word about availability of our content? We created a new team function called Product Delivery, whose primary purpose is to ensure that our stakeholders and audiences know about and have easy access to the content that the technical communication team produces.
In our company, when content is completed and ready for distribution, it is posted to a central location (like SharePoint or an intranet site) for others to retrieve. When this happens, the technical writer sends an email and notifies the project lead and a few other people that the material is available and provides a link to the file or source location. Previously, this was where the role for the technical communication team stopped. It was up to the project lead to notify a broader audience and provide a link or instruction on the availability of material (such as code or documentation). Now, with the product delivery function, this handoff step becomes a point where content is tagged and picked up for delivery (along with other recent content changes).
How does this product delivery function work?
The closest analogy I can think of for product delivery is the model of magazine or newspaper publishing. For these publications, content (such as articles) is gathered on a regular schedule, collated, and packaged into a readable format. The finished product is then shipped to outlets (such as a newsstand) for readers to pick up or it is delivered directly to subscribers. Our product delivery process is similar to this. At the beginning of the week we poll and identify all of the content that has been created or updated in the past week. After that we gather and compile the content changes into a list (with hyperlinks to the source). We then copy the list into a product delivery template and publish our Product Delivery Report using two distribution methods. One we post as a PDF to SharePoint (like a newsstand) for readers to retrieve it. The other, we send (deliver) via email to subscribed readers using internal and external mailing distribution lists.
What is in the report?
The Product Delivery Report is a simple summary sheet with a graphic banner image at the top (to look nice) and then a bulleted listing of the files and documents that have changed in the last week (see following sample). We also include the report date (when it is distributed) and a very short description of the report (for new subscribers who don’t know what the report is). Note that both the PDF and email versions of the report look virtually the same, so the look and feel of the report is consistent regardless of the delivery method.
To organize the report contents, we use a basic outline in a nested bulleted list format. There are a few main sections that keep content from the same source grouped together. We also provide upper-level hyperlinks in the report to Web-accessible folders and list the documents that have changed in that folder. An advantage of this approach is that subscribers are directed to the same location and retrieve the latest version of any posted document when they go there. Pointing to a location (instead of a file) acts like a basic navigation map and reminds subscribers where they should look for updates so that they can remember the spot and look for updates themselves. Also, folder links don’t break if a filename changes, there are fewer individual links to test or validate, and it takes less time to put the report together.
To give more context for each changed document that is listed in the report, we specify the type of change (new or modified) and the date the file was posted or modified. This metadata help subscribers better understand the changes so that they don’t have to spend a lot of time visiting a website to get the extra file information.
Who do we serve with this function?
There are two primary audiences we intend to serve with the product delivery function and report. The first group includes internal stakeholders and staff who need or would like to know what and when information is being published and where it is located. The second group is those within the organization that interface and talk with our clients, including support and our services team members. Both groups are regularly reminded and notified of all of the recent documentation and file changes that they need to know about and that they can share or reference with clients (who ask them about it).
A third, unexpected group that we serve with product delivery are the clients themselves (who often ask about the documentation). Our company uses a shared intranet site to retrieve much of the same published material that our technical communication team produces, so that has become the source for a newer “client” version of the Product Delivery Report, which we began publishing a couple of months after the original Product Delivery Report. As a result of the product delivery function and report, the reach of technical communication has expanded to a direct audience and a derivative delivery report.
Why should you consider product delivery?
Do you work with busy people? Of course you do. Busy people have to juggle and prioritize lots of things, including content. With more and more data and information to juggle, the status and location of content that they may benefit from can be lost in the shuffle.
This is one reason to consider adding product delivery services to your repertoire. It helps you stand out in an organization by meeting an underserved need of an audience that simply wants to know what content has changed and where they can get it so that they are kept current and can quickly pass on information to their stakeholders. You also will likely receive positive recognition across the organization for the work (you were already doing, but people weren’t paying as much attention).
Do you or your team ever get the same question asked multiple times? Before we became product deliverers, we were regularly asked where and when documentation would be available (often after it had been posted and sometimes by the same people). Now that we send weekly reports directly to almost the entire company, our team no longer gets these types of questions. We also don’t rely on other people to answer questions about our work or need them to help spread the word about our documentation.
Given the amount of time and effort it takes to produce and publish our reports, the benefits of adding product delivery services has far outweighed any costs (which are mostly a little extra work). On average, it takes our team about two hours to review, compile, and publish the reports that directly reach hundreds of people each week.
Our writers don’t object to the minor adjustments and they appreciate that their work is more visible because it is promoted and directly pushed to readers. We benefit from the increased visibility and perceived extra value our new service brings to the company. Who doesn’t like to be recognized and appreciated for their work?
Summary
We should all be thinking about how we can enhance our value and increase visibility within an organization—product delivery is one possible and effective way to do both.
I encourage other technical communicators to consider a similar proactive approach and to regularly notify their audiences that content is available and give them easy access to it. Don’t just be a content creator, take it a step further and become a content deliverer as well. Just telling people more about your work can pay big dividends.
What do you think? Can you see benefits to adding or implementing this sort of activity?
Todd Deluca (techcommtodd@gmail.com) has over 15 years of experience as a senior technical writer and currently manages a technical communication department. His professional background includes graphic design, editing, client communication, and software development documentation. Todd is an STC Senior Member and Conference Chair of the 2016 Summit. Other recent STC activities include Philadelphia Metro Chapter president (receiving a Distinguished Chapter Service Award) and Community Affairs Committee outreach team member. Todd has an MA in technical and scientific communication from Miami University (Ohio) and speaks at various regional and national conferences.
