Writing good policies is something every IT admin should learn to do. I’ve seen numerous policies written, but not enforced, and I’ve also seen policies enforced too much.
There needs to be a balance in your policy writing and a balance in your enforcement.
Here are some tips that I’ve learned through the years…
The Law of SSS
First off, policies should be short, sweet, and simple.
Complicating a policy and using words that the average computer user won’t understand and that isn’t thorough can’t be reasonably enforced.
A good example of this would be software policies. Ideally, you only want programs that you’ve approved yourself, and you don’t want someone’s kids installing Deer hunter II or anything else that could later cause problems.
That said, you can’t just say “only approved software titles can be installed”. This opens up an entire slew of questions. First off what is approved and is there a list of approved software? Chances are there isn’t and there probably won’t be a full list of approved programs that can be installed. Rather than saying something so broad and meaningless, say something to extent of “all programs must be approved before installation”. It’s simpler, and appears to allow for more freedom.
If you feel that the program really shouldn’t be installed for whatever reason, explain why and let the user leave your desk feeling like you prevented something bad from happening rather than just saying “no” to what they wanted to install.
Flexibility
Another problem I’ve seen is too much flexibility in policies.
Though some policies can be flexible, others really can’t be, so with that one policy that you really can’t budge on, stick to your guns and explain why you can’t make an exception. An awesome example I’ve come across is inbox sizes. Some churches and non-profit organizations don’t have this issue, and others do.
Hard drives have capacities and the last thing any admin wants is a full email server. This is an example of a policy that shouldn’t be flexible. Set an inbox capacity and stick to it. Users need to understand that, in most cases, an email from 5 years ago is no longer important. If you’re fortunate, you’ll have some sort of archiving service, but chances are you may not. Stick to your guns when you need to.
The same thing applies to usage policies, access policies, and even software policies.
Ownership
Another thing that needs to be clearly laid out is who really owns the hardware: the church, the company, or the individual. In most cases, it’s the church or company. This is extremely important.
Going back to the software issue, if we say no to a request, the argument of “but it’s my laptop” can come up. For this reason, it needs to be clear who owns the hardware and who has the final say in what gets done to it.
Protection
Lastly, and this has been mentioned before, we can’t play God. Our policies need to protect others in a way that doesn’t make them feel subordinate or like any move they make or question they ask is automatically wrong. Well written, well enforced, and fair policies will definitely help you in your ministry and anywhere else you may go.
They aren’t the cure-all to all of your frustrations, but it’s a great place to start.
Will P says
I was recently in a seminar presented by an Apple Engineer. He had two principles that were really challenging to me and will also be challenging to most of you as well.
1. Follow you’re own IT policies that are followed by everyone else in the organization.
2. Treat your users like they are adults.
Both were very lofty ideals when I first heard them. Give them both a try. If you can’t live with a policy, neither can your users.
Kevin says
I agree. Number 1 is probably one of the hardest.
Stuart says
This is good stuff but personally I’m of the opinion that any policy is a start.
That way you know as employers you are considering the staff and as staff you know you are being considered – even if only by default.