Rolling out an IT policy is a tricky business. You need to make sure users will take the policy seriously, but you have to be careful not to be too heavy handed about introducing it. Convincing users to respect the need for the policy -- instead of assuming that it will just hamper their work or restrict their freedom -- takes some finesse. It also takes a well-crafted policy and a thorough, inclusive process for creating and sharing it.
Note: This information is also available as a PDF download.
#1: Gain executive buy-in from the start
Users will generally have an easier time accepting the inevitability -- if not the necessity -- of a policy if they can see that senior executives are totally behind it. In the best case, senior leadership will have played a role in the early stages of policy formulation and will be able to articulate its benefits to employees. At the very least, make sure you have executive support before you invest too much time in drafting a policy. You could find yourself with a brilliant and much-needed document that no one adheres to or enforces because they know it's a lame duck policy that has only tepid support from management.
#2: Involve all affected parties in the policy-building process
No policy should be created in a vacuum. Consider bringing together a committee consisting of the policy owner, subject matter experts, and representatives from the groups that will be affected by the policy. In some cases, it may also be a good idea to bring in someone from your HR, financial, and legal departments to contribute their expertise. Not only will this across-the-board involvement help ensure that all angles of the policy's impact are identified, it will build a broader base of support, since more people will be stakeholders in the policy.
#3: Educate users and manage expectations
The last thing you want to do is spring a policy on employees without establishing any preparation or foundation for understanding it. For starters, you might want to hold a company meeting or a series of lunch-and-learn presentations that introduce some of the underlying reasons you'll be implementing certain policies. For instance, you could have someone explain the risks and business costs of downloading P2P file-sharing programs or the consequences of being careless with passwords.
As the policy is being developed and you get close to rolling it out, you can have managers meet with their staff to talk specifically about the impending policy and how it will affect them. This serves a dual benefit: In addition to helping prepare users for a new set of rules, it gives them a chance to discuss their concerns -- some of which might need to be addressed before the policy is formalized.
#4: Communicate the reason behind the policy
This is a biggie. Nobody likes to be told "Because I said so" when they question the rationale behind a rule or directive... or an IT policy. On the flip side, nearly all users will accept and support the conditions of a policy when they understand that there are legitimate reasons behind it.
For example, if you explain that a policy is needed to ensure compliance with federal regulations -- and that failure to comply could result in drastic consequences -- you're likely to get a cooperative user response. This step goes hand in hand with managing user expectations, but it shouldn't stop there. A brief explanation of the policy's purpose should be part of the policy so that those who missed out on any early work you did to build support (or those who have conveniently forgotten about it) will see that the policy is based on legitimate need.
#5: Write the policy in understandable terms
This seems fairly obvious, but there are plenty of policies out there that are so convoluted and overwritten, users can't make heads or tails of them. In some cases, they may give up on trying to figure out exactly what the policy says and dismiss it altogether.
Policies should consist of a statement of purpose, a description of who it applies to, clearly stated requirements, examples of what constitutes acceptable and unacceptable behavior, and the consequences of violating the policy. And none of those sections needs to be a one-act play. Keep the whole thing as brief as possible so that users won't be confronted with a daunting amount of text.
Your policies should also be written in terms anyone can understand -- no confusing technical jargon or legalese. This is one aspect of policy-building where feedback will come in especially handy. If you give a policy draft to five users and four of them respond, "Huh???" you might want to reconsider the language used in the policy.
#6: Know the policy's impact on the users -- and try to minimize it
A certain amount of inconvenience is almost certain to accompany policy restrictions, but you can reduce user resistance by developing the policy so that it reflects a full understanding of your organization's business processes. If a policy places a serious burden on users' daily work, you can bet some of them will find a way to circumvent the restriction. It will also sour their attitudes about the policy and probably any other policy you attempt to introduce. So it's worth developing knowledge of how users work and how the policy will affect them.
To educate yourself, talk to as many users as possible. Find out what their jobs entail and what types of constraints would constitute a major roadblock to getting their work done. This is also an opportunity for you to convey the fact that the policy could introduce some inconveniences but the organization has no choice because it's the only way to safeguard its assets, protect itself legally, move toward some type of compliance, or whatever the case may be. Users who see that you're taking their situations into account will be far more accepting of the policy when it's introduced.
#7: Obtain feedback and approval before you roll a policy out
You want to have complete confidence in a policy so that you can sell users on its value. That means making sure it's accurate, thorough, and well written. To help with this quality assurance, have a number of people review it before it's distributed. Ideally, you'll want to obtain feedback from users who will be affected by the policy and who represent a variety of job roles.
You may also want to show it to members of the IT department who weren't involved in drafting the policy. They may notice that something is missing -- or point out that some restriction is unnecessary because measures are already enforced on the network. Run the policy by legal counsel to ensure that it complies with state and federal law. And make sure senior leadership signs off on the finished policy. All this may seem excessively cautious, but it's far better to be thorough at this stage rather than to redistribute a series of corrected versions. Users will tend to disregard the policy if it's under constant revision.
#8: Introduce the policy the right way
The approach you take to introducing a policy can make or break the entire effort. To get users to recognize and accept that a new policy is in place, it's best to present it formally and stress its importance. An all-company e-mail from a senior executive endorsing the policy, reiterating its benefits, and thanking users for supporting it may help set the right tone.
Depending on how drastic the policy's guidelines are, managers may want to follow up by holding meetings with their staff to discuss the ways the policy will affect them. Users should be encouraged to express comments, concerns, criticisms, and complaints -- and managers should share those reactions with other managers and senior executives. It could be that the policy really is too restrictive, presenting an obstacle to a certain business process that nobody considered. The discussions will also help ensure that there are no misconceptions about the policy's purpose, its restrictions, or the consequences of violating it. And users will appreciate the opportunity to air any grievances they have.
#9: Ensure timely reviews of all policies
Users will have more confidence in your policies if they know someone's monitoring their ongoing relevance and applicability. You'll also be able to demonstrate your diligence in maintaining control and compliance if you run into a legal need to defend your practices.
One way to ensure timely reviews is for the policy owner to establish a regular schedule for reassessing the policy and recommending any necessary updates or revisions. Another possibility is to form a subset of the original policy committee (or a separate dedicated committee) that convenes periodically to review all the policies that are in place. If changes are implemented, be sure users understand what has changed and why. If a policy is discontinued or completely replaced, managers should address the reasons and implications with their staff.
#10: Keep communication channels open after the policy is distributed
You want to keep your finger on the pulse of user discontent; you want to learn about any serious problems a policy might be causing for employees, partners, or vendors; and you want users to have some recourse for expressing dissatisfaction or obtaining clarification if a policy doesn't make sense to them. You'll be able to achieve all these objectives if you designate a person or group for users to contact with questions and concerns.
You might publish your policies on a company intranet and list a contact person (maybe the policy owner or members of the drafting committee) there. Or you might put the contact information in the policy itself. If you send out regular IT department status reports or newsletters, contact information regarding policies could be part of a standard masthead or footer. How you provide that information is up to you. The important thing is that users have an easy way to contact someone -- and that they know such contact is encouraged.