Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
Make it easy to find out when it can be removed, in other words.
On one long-term project we even had special comments with an expiry date attached. Every time the build was running a script would scan all comments and print to output those comments that were expired to make sure someone revists them. And you could either remove, keep and extend expiry or modify that code, depending on context.
I guess it never crossed my mind I could do the same when creating company policies and processes.
- summary of issue/opportunity
- things we know are true
- things we think are true
- things we should do
- what if we were wrong in the second part?
- what are the admin/technical negatives of success?
- when do we need to look at that
Nobody reads all the way to the bottom, but the process of writing it out makes sure that I think about it, and it also helps dig up potential Metcalfe's Law impacts on resources, combinational explosions etc.
That's why traditions develop.
Every time you revisit a process you can keep it, kill it or amend it. It sounds pretty evolutionary to me.
What I liked is that adding some fail indicators as part of the policy actually gives ammunition to the people that want to change the policy for the better against people that are abusing the current form of the policy.
If it's updated, it's sent out to all employees. Some require a digital signature (i.e., a process for handling customer data) to make sure it's read and understood.
Each review has a commenting period (4 weeks) for techs to ask questions or voice their opinion on the changes before it's approved.
It's helped keep the important documentation current, helped the processes evolve and allows the people that actually use the process to have input on the matter.
Perhaps by "archive" you mean something like "delete", in which case I would like to strongly encourage you to not use "archive" to mean that, because it's the opposite of the standard meaning of "archive".
I liked the advice because it actually applies to good processes that become embedded in the everyday work.
The point of the article being in how to prepare for the cases when a good policy becomes broken or is abused over time.