Set In Stone

The biggest problem with most documentation is that people treat it as if it is "written in stone": that it cannot be changed and that it is intended to be permanent. Requirements documents and detailed design documents are the kinds of documents that are most often treated this way, but it also extends to interface descriptions, organizational policies, and even to checked-in source code.

Such documents are actually not difficult to modify. The problem is that once people see them, approve them, and maybe even sign them, there is great reluctance on anyone's part to make changes. The documents themselves are treated as authoritative and final, and everyone forgets that they were written by admittedly-imperfect people who are willing to improve them if they can.

It is important to remember that these things are not holy documents, received via divine communication. They are just records of decisions and agreements made between people, and can be changed.

Some things are: "Written In Stone". Contracts for one. Some things can be altered, but you would be wise to have a ChangeManagement process in place.

The problem is that many processes designed for ChangeManagement artificially increase the CostOfChange and end up leading to PreventionOfChange?. Even contracts can be altered by mutual agreement. What is important is that all interested parties be notified of changes, and that they have appropriate input to the process.

What is important is that all interested parties be notified of changes, and that they have appropriate input to the process. Sounds like a ChangeManagement process to me. The fact that one can design a bad ChangeManagement process is no excuse for not having a good one.

Nothing above suggests that there be no ChangeManagement process. It only says that everyone needs to remember that change is possible, and that it is not necessary to simply do what the documents say.