Keeping documents up-to-date is a major concern in most corporations and organizations. Unfortunately, It is a major concern that receives minor attention. This is mostly because no one is quite sure what to do.
A documentation team can write a comprehensive manual on a system, and take years to do it, as well. Once, it is published and distributed – it is generally put on a shelf. For the first year, it is used voraciously. Managers refer newbees to it for reference, and new requirements are launched using the document as a blueprint or roadmap.
Then, suddenly, the rumor starts to spread that the document is no longer valid – “It’s out of date!” And, the fact is – it is.
Why documents become outdated
The reason a document becomes outdated is because so many changes take place through tickets and change controls and the document does not keep pace.
Some changes, although they seem minor (warranting a ticket and not a change control) can accumulate and make a significant dent in the validity of the documentation. It should also be mentioned that there are often changes made by programmers and developers where a ticket or change control is never submitted. This is most damaging to the document process, and can only be controlled by a strong upper-management influence.
It only takes one document user to come across an inaccuracy to render the entire document useless. And, although, the word, ‘useless,’ may seem rather strong – that is exactly what can happen to 600-page document and two year’s worth of work of an entire document team.
Is there a solution to this – yes. Again, the road leads back to the documentation lead – who, should not be writing, but taking care of administrative tasks such as acquiring and maintaining document projects for the team.
One solution is to ensure an alert is sent to the documentation team every time a ticket is written. Reading through every ticket can be a laborious chore for the team, but the benefit to the organization outweighs the investment of time. Reading every ticket falls into the category of maintenance – and maintenance is one of those jobs that no one, especially an experienced writer, wants to endure. It is, however, to use a relevant cliché, ‘a necessary evil,’ and let us double up on the mundane with the statement, ‘The devil is in the details.’
Documentation must be updated and reissued whenever a ticket is created. Depending upon the size of the ticket, the manager could make a determination as to when a document should be updated: after five tickets; or monthly (regardless of how many tickets accrue).
As for change controls, they are usually larger and can sometimes include new requirements. These must be included in the documentation to ensure on-going value of the information. Again, in most organizations there is no process in place to make this happen. Because the folks who put the change controls in do not always know if there is a related document, having them ‘check’ a box on the change control form is usually valueless.
Once again, it is up to the manager to ensure these changes are assigned to a writer. The manager should attend every change control meeting, and review the change controls thoroughly. If a document within the organization (this assumes the manager knows every document within the organization) is impacted, this document is slated for an update.
Updating the schedule will once again depend upon the size of the change control and how many change controls were submitted against the system.