IT Policy helping to solve the roll out of ITIL in a manageable way

What’s the point of IT Policy?

When I talk about IT policy I am not talking about a step-by-step guide on what to click on and how to perform a particular task.

In my opinion IT Policy it the process that one must go through which in tales the entire change management, release management and testing process. Policy is constantly evolving with time and used as a guide to assure the proper steps have been followed.By following proper policy one can start to improve on IT value and a more focused approach to IT services in terms of error rate.

Some stats that I have seen in the past point to about 85% of all error within the IT infrastructure comes from human error error that I would contribute to poor policy.

If by following an outlined policy and a issue arises during or after the process it only means one of a few things.

  1. The policy was not followed and its a human issue (deal with the human element)
  2. The policy must be change to incorporate the additional change (reevaluate the policy and add missing components)
  3. The policy was incomplete in the initial roll out(appropriate time was not given when outlining the policy rework the policy)
  4. Missing policy (did this process cause an error then create a policy for the future)

Take for example the following: We roll out a change to an IIS configuration to a live environment, the policy helps identify the possible issues with this roll out by outlining what applications this change touched, what areas to test and how to assure the change was successful. If the process fails, it would fall into the 4 outlined issues above and we would have to change policy to assure this process does not happen in the future. This also opens the door for automated policy management insuring that all touch points are tested and if missed added to the automated testing policy.

In our environment, policy is not rolled out to inhibit change rater speed up the process. Nor does our environment justify a full blown change management sign off procedure (yet), however we are starting to look heavily at releasing ITIL in a staged and appropriate manner for our size of an organization. In doing so we need a way to identify critical changes from non critical changes, by outlining the above in a manageable way, we ever so closely become in line with ITIL.

As you can see from above, this is by no means complete nor is it meant to be. It not a new concept, its a simple concept that should be used as a repeatable means to create policy and help identify critical issues. IT is inherently identifying patterns having better control over repeatable processes assures we are able to handle critical issues in a way that will not interrupt routine day-to-day changes and tasks but puts emphasis on identifying patterns to help build policy.

Leave a Reply

You must be logged in to post a comment.