Edward Ned Harvey wrote: > The reason why I'm unwilling to simply choose a policy as I see fit, and > cram it down their throats, is because I expect compliance without using > punishment as the motivation factor. This necessitates that people feel > some voluntary commitment and understanding of the rules. People will do > whatever is expedient, unless they know there's a reason not to.
The issue that you are going to have with this process is stagnation. You are going to get one of two results. 1) no real participation. (I wouldn't participate. Too much other crap to deal with.) 2) you get the bike shed problem. http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality Remember, policy is dictating what *must* be done to protect the business. As that, it is a top down drive. Not a bottom up one. A policy might be drafted by someone lower, who has the time and knowledge/experience to know what to include, but it is owned and pushed by the organizational owner (usually the CIO.) Every piece of the policy has an associated risk assessment. o What is the risk to the business? o What are the costs? o What are the alternatives? These are questions for the organization owner. Not the "end users." When it comes to IT policy, anything that is up for grabs by the general population should not be in the policy. Those become guidelines not law. Oh, and there is always an exception to the policy. So, always have a documented and transparent procedure to get the proper approvals signed off, for every exception. When it comes to buy-in/follow through, people will do anything, given a good enough reason. So, make sure you have a good documented case for every point in the policy. The documentation should answer the three questions I had above. Start with a simple "Best Practice" policy. See if it covers all your current issues. Don't go on a witch hunt for issues. The policy is a living document (as noted by a previous post.) This means that when a new issue comes up, a new point in the policy will be generated and vetted, along with the documentation of the three questions. The policy should have a regular review cycle. You should look for policy points that may be antiquated, business risk changed, costs changed or new alternatives are available. -- END OF LINE --MCP _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
