When Help Content Is Forgotten

by Tom Johnson on Nov 10, 2010
categories: technical-writing

In recent posts on content strategy, I've written about how common it is for "user experience" designers to create websites without considering content. I made this point in my last post, Text Matters, and it's what fuels the fervor behind content strategy.

In the same way that user experience designers forget about web content, replacing empty spaces in their prototypes with lorem ipsum filler, project managers do an even better job of forgetting about help content.

Content strategy may seem new (and all the discussions about web content being forgotten in website redesign projects), but help content has been marginalized in tech comm since time immemorial. Today our user education team was sitting around in our weekly team meeting, talking about ways to ensure that help isn't forgotten in project plans.

To illustrate, just last week a project manager emailed me about help solutions for a site launching in a week. Other times project managers come to us at the ninth inning of their projects, when all money is gone and the only remaining budget allows for just a few days of labor. Other project managers suddenly inform us of help needs when the only timeframe to complete the work will require full-time commitment on their project from the first contact until release.

Two Types of Content

In the two situations I've mentioned -- the project manager who forgets web content and the project manager who forgets help content -- "content" doesn't mean the same thing. On a website, content is the main text, audio, video, and images that users will look at, read, interpret, think about, apply, comment on, and so forth. Content drives the heart of a website.

With an application, however, help content isn't the focus. Applications do many different things, but frequently applications are a platform for users to create content, such as documents, presentations, projects, agendas, lists, and so on. Think of PowerPoint, Basecamp, SharePoint, or even Twitter. What's the content in those applications? There is no content, for the most part. The user creates the content. The application offers functionality.

When we talk about help content, clearly help content shouldn't be on center stage like website content. Help content is an emergency kit in the back of your car, available when you need it. Because of this nature of help content, it's understandable that project managers would forget it. I don't even have an emergency kit in my car, for example.

Different Content, Same Question

Despite the different types of content, the problem is similar: project managers forget about content. Website project managers forget about the creation of web copy. Application project managers forget about the creation of help content. (Either they forget or they willfully neglect / postpone it.)

How do you help project managers remember web/help content for their site/application? One of my colleagues is so driven to solve the problem that he emailed the CIO and arranged a meeting with one of the top three decision makers in our organization. It was a positive meeting with many heads nodding in agreement.

But a week later, we sit around asking ourselves if anything will change. Will things be better? What will it take to firmly cement user education into the software development process in a way that has "teeth," as we kept phrasing it? We need teeth to ensure we're not forgotten. It's not enough to acknowledge the problem and agree that user education shouldn't be called at the last minute. We need teeth, dang it. And we want to lock those teeth down on something and hold it like a pit bull clamps down hard on anything between its jaws.

I'm curious to know if any of my readers have found a workable solution for large organizations such as ours, where new projects come out of nowhere with little or no warning, where the right hand and left hand are autonomous agents acting independently. If you work in a small company where you eat lunch together daily, you may not face this issue. Even mid-size companies with a highly standardized documentation process might not have this problem. We're more like a full-size startup organization when it comes to tech comm. Our ratio of tech writers to other IT personnel is 1:200.

Brainstorming Ideas

Since this blog is often a brainstorm of ideas enriched by reader comments, I'll offer a few ideas for helping project managers remember the help content. You can add your own ideas in the comments.

Idea #1. Insert TC into the approval process. Insert a clause in the software development process that requires sign-off from a technical writer before a project gains approval. Almost every IT shop has a project approval process, right? A system of checks and boxes before the finance guys write the check? The problem is in understanding this mysterious process, leveraging the power to change it, educating project managers about the change, and enforcing it. It's kind of like moving the Titanic onto a new course with a spare oar.

Idea #2. Designate a new project scout. Designate someone to be a scout in the project approval process; make it the person's job to continually scan for new projects coming down the way. This person may search a project database daily, making contact with project managers to find out information. Or he or she may have close ties with the lead over project managers. (Someone has to allocate a project to a project manager, right?) Maybe the scout sets up regular meetings with this individual to learn about new projects. The only problem is that this meta project manager no doubt is high profile and busy, with little need or care to meet weekly about documentation that his or her project managers should have to deal with.

Idea #3. Bill support costs into projects. Hold project managers accountable for help costs. In a dream world, project managers would have to factor in costs for all support, which means they'll do everything in their power to minimize these costs up front by providing proper documentation and training. The only problem is that allocating support costs is nebulous. Does the project pay for the health benefits of each support agent, as well as their office space? And how can you budget for something that may be ongoing for years? I wish ITIL recommended a model that considered this idea.

Idea #4. Educate project managers. Start an organization-wide campaign to educate project managers about the need for help, when they should involve technical writers, how many hours to estimate for a project, and such. Hold a regular training for project managers that is ongoing, such as monthly, and invite them all to attend. Begin a campaign of continual education. Even if the project managers keep hitting Decline on meeting invites, they'll get the point sooner or later. This idea, however, assumes project managers forget help not out of willful neglect, but out of dumb ignorance. This may not be the case at all.

Idea #5. Convert UX to champion CS. Almost every application has an interaction designer or user experience person on the team. Although some UX types don't want to focus on content, working with and converting the UX lead about the importance of content can give you the leverage of an insider championing your cause. The only problem is that with application development, many UX designers feel a well-designed application won't need help. Since they plan to create a good design, why would they start thinking about help so early? Doesn't that admit defeat before the design challenge even starts?

Conclusion

I doubt that any process to help project managers remember content will be effort free. Most of these efforts will require time -- maybe 25 percent of someone's time. Usually technical writers are already so busy working on multiple projects, especially last minute projects, they rarely have time to devote to organizational education campaigns or extensive searches of new projects.

Even if you do have extra time, it's not often that tech writers have the tenacity to schedule meetings with people three levels above their pay grade to nag them about "documentation." I know I would feel uncomfortable sending regular emails to the CIO. Maybe this is the real battle: overcoming a feeling of insignificance. Our silence only furthers the degree to which we are forgotten.