The reason I told the story in parts one and two, was to illustrate how humble the beginnings of a technical communications program can be. In this case, from the humble beginnings of a simple document development project, a very robust and highly regarded program blossomed. It is flourishing to this day. This was not because of me, I just happened to be the one from the outside who noticed a few things. It really was due to some astute people in leadership recognizing their reliance on a single-sourced publications group wasn’t working at their department level.
Keep in mind, all programs don’t start off to be programs. Had I come into this first project suggesting that this department needed a technical communications program, I would have been laughed off the property. At this point, you might be wondering what I mean by a technical communication program and how that is distinct from a technical communications project. A project can be as simple as one document or a series of documents of different types that cover a specific topic. The best source I have found for information about documentation projects is, Managing Your Technical Communications Projects by Joann Hackos. While many books have come along since, this one still scores the sweet spot in my documentation library.
Conversely, to keep this simple, I’m going to refer to a Technical Communications Program as a collection of technical communication projects that have a consistent look and feel, follow a set of documented standards and are governed by policies that ensure the materials are developed, reviewed and stored in a protected, accessible, centralized repository. These projects include things like the development of training, documenting standard operating procedures and providing reference material all designed to promote the understanding of specific functions within an organization.
With that being said, there was a firm belief in this particular organization that the corporate-level unified publications department was sufficient to meet all technical communication needs with their set of manuals. In the broad sense, that worked but at the micro level where I was, it didn’t. While the bureaucracy and structure built around the publications department was necessary, it made it very difficult to keep things at the department level fluidly up to date, and that was hurting the department. It wasn’t just the bureaucracy complicating matters, it was this false sense of security that all their bases were covered with a department manual managed by this organization.
There was an additional sense of false security in this department that all their training needs were met and managed by the corporate training department and that wasn’t at all true. Their e-learning training hub while truly sophisticated, and I took full advantage of it when I first arrived on the scene, didn’t meet the needs at the department level when it came to the nitty-gritty functions of a person’s job and it wasn’t the purpose to which it was intended. That was left to the departments to figure out on their own.
As a contractor and a technical communications generalist, I saw all these gaps. I immediately wanted to fix everything all at once. But the one thing in particular I saw was the need to transform this organization’s attitude of “knowledge is power and job security” to an organizational culture where knowledge was freely shared, organized and accessible to everyone in the department. No small undertaking, I assure you. It became my secret mission and I only had about three months left in my contract to accomplish it.