Tech, Lies, and Red Tape
Why you do what you do AND who’s responsible for doing it.
More important than the actual process to complete a task is the purpose behind why it is done at all. The driving force for any process must be backed up by a doctrine of some sort or the purpose of any process may get questioned and your systems break down. The policy is the ‘law of gravity’ so to speak for your systems. Policies govern the actions required for smooth operations and keep all responsible parties reading from the same sheet of music.
An example of a policy within an organization could be the I.T. offices’ requirement for updating login passwords every X number of days. Most should be painfully familiar with that policy and the common additional requirements of special characters, numbers, and upper/lower case lettering.
When an organization makes a decision to do something there is an impact. Sometimes that impact affects other parts of the organization. Other times the impact is felt by the customer. A policy is an explanation behind the impact regardless of who it affects. When an action is taking in an organization, it should always result from a business decision. That business decision could be anything but some examples are: to reduce cost, increase security posture, save time/resources, or most importantly — streamline day-to-day operations.
No matter what the business decision is, there will almost always be someone affected by the impact that disagrees with the supporting policy. That is why it is important to have buy-in from the majority of stakeholders. Adherence to policy regardless of the repercussions is hard to enforce when the majority oppose the impact.
Policy, like processes, can change or evolve over time. A policy is seldom set in stone. Even some of the most rigid human resources policies have evolved with changes in work culture over the years. The policy governing the work that is done inside your organization should be no different. The importance of policy to make sure everyone, affected by and conducting a process, achieves the same outcome. Consistency is extremely critical. While the process to an end-state may allow some flexibility on the steps to complete, policy dictates that the result be the same every time. That result is what becomes relied upon by all stakeholders.
When creating policy be sure to document 3 key components:
Rationale — the why
Action — the how
Impact — the what
Ancillary information such as policy owner, points of contact, and recommended support/feedback channels may also be included.
When documenting policy, stakeholders need to know where the policy is coming from. A policy should never be derived out of thin air. If there isn’t a reason to do something, why the hell do it in the first place? The rationale is a key component of the decision to do something. This is the story or the background behind the policy. Use the rationale to ‘sell’ the new or modified policy. It is going to cause some level of inconvenience to one or more stakeholders. The rationale will help express understanding of that and hopefully documents a win-win outcome. Be sure to provide the ‘what’s in it for me’ details.
The section itself seems pretty self-explanatory; yet, many parties may be responsible for taking action. This can cause confusion or worse — inaction.
Example: system administrators may be conducting the bulk of some future change, but can only do so after end users do steps X, Y, & Z.
Use this section to briefly explain the steps that are required to prepare for any changes that will be taking place. Considerable detail is not required here. The actions listed may be directions on where to find the full set of instructions. Just make sure that if multiple groups of stakeholders are responsible to complete steps — those steps and their responsible parties are clearly defined in the policy announcement.
The rationale is telling your stakeholders what you’re going to tell them. Action tells them what needs to be done. Now you make sure they are aware of how it will impact them. The impact may only be a single change that happens once but alters how a task is completed indefinitely. Or the impact may be more obtrusive to day-to-day operational activities. Either way, it is important to lay it all in this section. As with the action section, the policy announcement itself doesn’t need all the details. Most important here is documenting what will happen if the action steps are not completed. Provided enough information to close out the rationale. This is an opportunity to reiterate the win-win or “what’s in it for me” for when the actions are complete.
Sharing policy and making it available.
In a perfect world, your policy announcement contains everything that is needed in these three sections. If properly formatted, the announcement can be the policy. However, it is important to make the announcement brief or it is likely the policy will get glossed over. The same is true for the stakeholders that need to follow the policy. Make the requirements for the who, what, why, and how of completing a process easily discoverable in the policy. As stated at the beginning, the policy is what enforces the proper completion and implementation of a process. The policy ensures the outcome of a process so the majority of stakeholders must be in agreement and know where to reference the policy when a process outcome is under debate.
Interested in learning how to better document policy in your organization?