First, what is a policy?  Well, in an article we recently ran, we established that a policy and procedure are two distinct entities. According to the dictionary, policy is a “definite course or method of action selected from alternatives and in light of given conditions to guide and determine present and future decisions”.

Organizations typically have high- and low-level policies.  High-level policies govern the entire company in most or all circumstances. They are somewhat generalized and often articulate soft goals.  They speak of company desires, needs, and aspirations.  High-level policy doesn’t readily lend itself to procedures; instead, it takes the form of a standard, or a guideline.

Low-level policy deals with a more specific set of circumstances. Low-level policy is the kind that usually leads to procedures. An example of a low-level policy that everyone’s familiar with has to do with attendance; employees are expected to come to the office to carry out their duties during “normal working hours”.

Because the world around us is continually changing, our policies – especially the high-level policies – have to be reviewed and reshaped occasionally.  We do this by implementing “the policy cycle”.  The policy cycle consists of:

• Setting the policy agenda;
• Writing policy;
• Implementing policy;
• Enforcing it;
• Reviewing the policy; and
• Updating policy.

Setting the Policy Agenda

Your organization has limited resources – time, money, people, etc.  Whatever your company’s intent, whatever its objectives and strategy, you can only do so much.  Your policy agenda is a concession to the scarcity of resources.  What resources you have, you manage well and you prioritize.

The smaller the organization, the easier it is to set a policy agenda, generally.  It’s with large organizations that we see more intense competition to politicize an agenda – to get preferred items on the agenda because they serve localized interests, which are easier to understand and deal with, rather than those of the entire company.

Writing Policy

A policy has to be easy to understand and implement. Policy statements have to be written clearly, concisely, and directly.  Policies should not be open to interpretation, though this isn’t always possible, especially with high-level policies.  In that case, the company must identify policy experts who will be readily available to interpret policy and resolve differences.

Policy writing has to be an iterative process.  Policy drafts should be reviewed by a representative sample of the group or groups who will be responsible for implementing the policy on a daily basis.

Implementing Policy

People have to know that a policy exists if they’re to be held accountable for it.  Not only do they need to be aware of it – they should also know why the policy exists.  People generally view policies as restrictions and unless it’s clear where and why the policy originated – that there’s a valid reason for it and that the organization benefits – compliance will be a problem.

Policies have to be communicated effectively and there needs to be a suitable introductory period to ensure compliance. People should have plenty of advance notice – give them time to learn the policy, discuss it with others, understand it, and submit their comments.  When people feel like they’ve had a say in policy, they’re more likely to comply.

Enforcing Policy

Given that policies are often developed in response to problems, how do you make sure the problem doesn’t recur?  Well, you try not to do what a lot of governmental bodies often do – you don’t make policy that’s unenforceable.  The U.S. Congress has been doing this for years with respect to food safety, writing more laws for the FDA to enforce while hampering its ability to conduct inspections by slashing its budget.

Policy has to be clear on what constitutes compliance and what happens in the event of noncompliance.  There has to be a clear responsibility for ensuring compliance and imposing penalties.

Reviewing and Updating Policy

Policies are often changed only because a noticeable event or trend occurred which forced the organization to respond.  A notable example of that is the proliferation of smartphones; so many individuals have purchased smartphones and incorporated them into their daily routines so quickly that the company can’t keep up.

The majority of company policies, once written and implemented, are rarely looked at again.  Yet, all policies have to be reviewed on a regular basis to ensure that they reflect the business realities of the moment.  A good example of that is some automakers’ infatuation with the SUV, based on a policy of maximizing profit rather than giving customers what they need.  Even if $140 barrels of oil and the decline in SUV sales weren’t a strong enough signal to them, the automakers should have been reevaluating their policy periodically with an eye to updating it.  Their hundred-year-plus histories should have told them – you either change or you have change forced on you.

What about your organization?  When was the last time you reviewed any of your policies? Do you follow a policy cycle?

Last week, we identified “communication” as the most important means to achieving success, the one tool your managerial toolbox cannot do without.  Without effective and timely communication, project development and implementation will suffer and as a result, the organization will have a difficult time reaching its project objectives.

Of course, there are other barriers to project success.  Good communication will take care of a lot of problems but not all — human nature being what it is.  Whether you’ve been a project leader or part of a project team, you’ve undoubtedly run into one or more of the following problems:

1. Lack of Clarity. Some or all employees don’t know or don’t understand the project goals, objectives, roles and responsibilities, etc.  What are their individual goals and how do they relate to the goals of other team members, and to the project?  Stakeholders don’t see what they have to gain if your project plans aren’t clear, and everyone must have something to gain or they don’t cooperate.
2. Inadequately Researched or Defined Requirements. This is a major cause, if not the root cause, of lack of project clarity.  Be sure you and the user/customer agree on what is required.
3. Inadequate Resources. You considered and planned for project development and rollout costs, but what happens after rollout? What does it take to adequately inform, or educate, the customer?  Did you adequately address marketing, customer support, and maintenance needs?
4. Lack of Ongoing Customer Support. For some companies, contact with the customer ends with the sale. Did your plans account for the customer’s satisfaction and loyalty? Too many companies fall short in this regard.
5. Biases (Yours and Theirs). You’ve heard the phrase “overpromised and underdelivered”.  How many times does this happen in your business?  Why?  How likely are potential customers to believe you if they’ve already been burned.  What were their previous experiences?  Be sure to address these.  Also be sure to address your company’s attitudes toward existing customers (see “Ongoing Support”).
6. Technology Gap. Where is the customer on the technology continuum? If your solution is technology-based, consider the amount of training that will be required within your implementation process.  Also, be sure you know what their most pressing needs are and solve them.  Don’t give them more than they need and don’t shoot wide of the mark.
7. Resistance to Change. An individual’s degree of resistance to change is a major factor: While it may seem counterintuitive to you, many people prefer the devil they know to the one they don’t.  Be aware of that and have a plan for dealing with it.  Make sure the customer knows the benefits of your project early on and how they will far outweigh any temporary pain they might feel.
8. Lack of Time. See “inadequate resources”.
9. Not Invented Here. You still see a lot of this from customers: “How can you expect to come in here and solve our problems when you don’t have any experience in our business?”  That may be a purely defensive posture.  One of the messages often underlying that question is, “Once the project is complete, jobs will be lost, etc.”  You have to be able to answer that in your project plan.  Also see “biases” and “resistance to change”.
10. Political Barriers. You lack support from critical areas/functions.  Maybe people are unwilling to step forward for various reasons.  What’s the company culture like?  Are they historically proactive or reactive?  What are their real motives for seeking you out?  Is the project supported all the way from the bottom to the top of the chain of command?

We need to remind ourselves now and again that careful, thorough planning prevents most problems.  The problems you don’t prevent in the project planning phase – and you’re never going to prevent them all, but – they’re a lot easier to identify and correct when you have a sound project plan.