“Can we change this document type?” was the comment I recently heard from a project manager during a weekly status meeting. “I know that’s the type we’ve used for all the other documents, but some of our users for this project call this document something else. Maybe we should try to align the terminology with theirs for this project.”
At first listen, I cringed internally at the suggestion but smiled and quickly planned my reply. “Well, it’s a good suggestion, but I’ll need to take this back to the department to discuss that change. We’re beginning the process of standardizing the types of documents we release, so any change to our current document types need to be approved by our department first.” The PM was a bit frustrated because she figured it was a lost cause and wouldn’t go any further. After the meeting, I pulled her aside to further explain our reasoning for not changing document types on a project by project basis – long-term it causes confusion for the user and makes the documentation set overall much more difficult to manage and standardize.
In many corporate settings, documentation is a challenge to manage as it is. When the documentation department lacks clear cut standards as to the types of documents they produce and the contents of those documents, it adds to the overall confusion – for both the users and the writers.
One of the first steps to standardizing or formalizing a documentation department is to establish clear cut document types. Generally, I recommend the organization look at the types of documents they have produced in the past and begin to categorize them. For one organization, we found we had documents called Admin Guide, Install Guide, Implementation Guide, and User Guide. Through our discussions, we found that the Admin Guide and User Guide were unique document types. Admin Guides always contained system administration information. User Guides always contained end-user guidance.
When it came to Install Guides and Implementation Guides, the discussion was a little more complex. After various discussions, we decided that these two guides contained roughly the same type of information – information used to implement a software package at a site. The group felt that installation of the software was just one small part of an overall implementation, so they decided Implementation Guide was the term they’d use going forward. That process was repeated for the 30+ types the group identified initially.
Now, this may sound like a lot of work to simply determine the standard types of documents these writers produced. However, the long-term benefits of such discussions are numerous:
- Management has better oversight into the types of documents the department produces. Management can pull a variety of metrics to share with executive management about the productivity of the department.
- Writers become empowered. Writers have a solid “menu” (so to speak) of the types of documents they write. Thus, when they interface with the business they can comfortably explain the standards. If a project wants something outside those standards, the decision to escalate the request to documentation management is clear cut. The writers retain their “document expert” status while management gets to handle those strategic decisions.
- Users experience less confusion. Users like consistency. Knowing they can find a certain type of information in a specific type of document reduces the amount of time users spend “looking” for the document they need.
The organization as a whole also benefits through this type of standardization. When standards are implemented and followed, employees spend less time making those strategic decisions on the fly to fit an immediate need. Instead, they are empowered to select the right “tool,” or in this case document type, for the project. Time isn’t spend debating what they should call the document, what should be in it, whether it needs to be two documents or one or four. They simply reference the outlined standard and any issues are escalated up to management where those decisions should be made so they support the whole documentation set, not just the current project.
While it takes time, coordination, effort and compromise, standardization of document types is a win-win for everyone involved. Oh, and that project manager who wanted to change the document type – after she listened to my reasoning and spoke more with the documentation manager, she better understood our purpose for keeping things consistent. And the documentation department developed 22 standard types of documents (down from 40+) they produced for the various business lines and software they supported. I’d definitely call that a success!