This is a topic that’s been pretty near and dear to me, as I’m currently involved in an effort to migrate an enterprise taxonomy to an updated taxonomy management system. As part of the migration effort, I went back through old documentation to get a better understanding of why certain decisions had been made previously and to figure out what dependencies existed between the enterprise taxonomy system and those systems which use the taxonomies. We needed this information to help guide us in what system requirements we would need to be aware of and how to model the taxonomy in the new system.
Going back to the documentation ended up becoming a scavenger hunt. When I started looking through it to find the answer to a particular question, I was never sure if I was going to find it. When I did find something that looked relevant to our needs, a lot of times it was out of date and the information was no longer correct. A lot of the research work I did was legwork, as I was trying to fill in those knowledge gaps and also verify that the information I had was still correct.
So speaking from experience, documentation is a very important part of the taxonomy governance process. I’m also speaking from experience when I say that no documentation plan is complete without a documentation maintenance process. A documentation maintenance process helps ensure that your documentation is updated to keep pace with changes in the taxonomies, changes or updates in your taxonomy management system, and changes or updates in those systems which utilize the taxonomy.
You may not have thought of having a documentation maintenance plan as part of your governance policy. Here’s a quick five Ws (and one H!) going over the questions that your maintenance plan should answer:
Who
Who is responsible for updating documentation?
*This might be split up according to role and/or domain. For instance, if you have someone on your team who handles technical issues, they might be responsible for updating documentation based on changes to IT or tech processes.
When
When should documentation be updated?
*Is there a particular trigger to signal when to make updates?
*How often should documentation be reviewed?
*How much time should be taken on documentation updates?
What
What documentation needs to be updated?
*Is there a review process in place for your documentation?
*Are there links that need to be updated?
Where
Where are updates being tracked?
*Is there a change log that can be published or shared?
Where can users find your documentation maintenance plan?
Why
Why was this documentation changed?
*Does your change log have space to list what changes were made in your documentation?
**The change log can be a very useful historical document.
How
How are changes tracked?
*What is your change log process for documentation updates?
How are changes made?
*Is there a request or publishing process for documentation updates?
How can taxonomy users or other stakeholders notify the documentation team of changes that are being made?
It’s understandable why documentation can end up getting the short end of the stick. Writing and organizing documentation is a time-consuming endeavor, and during a project people are focused on getting the work done more than they’re concerned with documenting it. But just because documentation is difficult, doesn’t make it any less important. It’s understandable why documentation might get neglected, but neglecting it is only kicking the can down the road and causing yourself more stress and giving problems to yourself in the future.