Here are the responses we received when we asked, what are the most common mistakes organisations make with their policies and procedures:
Creating reactive policies (e.g. in response to one employee's transgression) instead of going up one conceptual level and thinking through the bigger picture.
— Rahel Anne Bailie (@rahelab) June 27, 2018
Not having any!
— Rhonda Bracey (@cybertext) June 26, 2018
Not including any context. I've seen people question policies (and ignore them) because they don't understand the reason/benefit of the policy.
— Craig Wright – Tech Writer (@straygoat) June 26, 2018
Thinking that a list of where documentation is stored and the tools used to edit them constitutes a documentations strategy.
Having senior managers who think the know about documentation, when in fact, they know very little. In saying this I allude to not actually having much in the way of documented Policies and Procedures.
I think the most common mistake is in two parts:
1. Organisations often try to document and codify things too early, while things are too chaotic and changing, resulting in wasted effort. (This applies more to procedures than to policies I think)
2. Organisations use inefficient documentation tools and review processes, so policies and procedures are
a) out of date from the moment they are published,
b) too hard to find, understand and use, and
c) too hard to update.
Thus they consume a lot of effort yet are untrusted and underused.
Not having any.
Not valuing what is there.
Disregarding them as ‘red tape’ or toot that applies to others and not them/their team.
Can you sense the frustration?
Basing them on existing documents and not doing any research to produce something new and more effective – my top Grr!
Not enforcing them! You can write these until you’re blue in the fingers, but if they’re never followed it’s a complete waste.
Inconsistent structure, lack of template or failure to apply template, failure to maintain over time, content/document is not findable, wrong level of detail for the end user, no defined end user or too many end users.
Even before I saw the replies I had thought of:-
Not thinking the job though enough
Not consulting those affected (the indians and not only the chiefs!)
And not convincing the indians that they are important or relevant.
Not keeping the documents up to date
Not ensuring that everyone – including new starters- a) know about them and b) have very easy access to them.
Creating all the policies and procedures in their own vacuums so you end up with conflicting information.
Or the corollary, having too many to follow.
And then not having any training to teach new hires.
Writing without process discovery.
Failure to understand the cultural shifts that technical changes invoke.
Failing to write them in the first place; failing to update them; not having a skilled writer or editor look over them; not having a consistent structure; not publishing or promoting them effectively; filling them with jargon terminology, on the assumption that everyone in their organisation understands; using bullets instead of numbers, or vice versa… and that’s just off the top of my head.
Failure to refactor their tools and processes to automate as much as possible and to establish clear visibility and feedback for the things they cannot automate.
You can write policies and procedures until you turn blue but if they depend on people remembering to do things that have no impact on their own work and whose consequences are not visible to them, then you are not going to get effective compliance.
And scolding is not feedback. Feedback is seeing the consequences of your actions in real time or as near to real time as you can make it. If you can’t see the results of your actions, you will not do the action correctly. Refactor your procedures so that the consequences of actions are visible to the people who do them.
Automate what can be automated and make visible what can be made visible and you won’t have to write much down. In fact, you should regard the stuff you can’t automate or make visible, and therefore have to write down, as a sign of failure. Don’t devote your efforts to writing it down better. Devote your efforts to refactoring your process so you don’t have to write it down.
Besides what Mark said. Also, no review and rollback mechanism. I’ve seen companies roll out policy and process changes based on industry “best practices” without running a pilot. When it becomes clear to everybody that it was a stupid decision, and that the change was actually regressive, they plow along anyway, because the plan didn’t include a period of review and analysis, and possible roll back.