Creating A Policy Document

In this blog I would describe how we can create a policy for our various ITIL processes and typically what all should be included. Thereafter, this blog will cumulate into a series of blog providing policies for key ITIL processes that readers can use as a reference or baseline for defining their organization’s service management policies.

Policy can be defined as an overall guiding framework for managing a particular process, function or subject. It can also be said to be a boundary within which certain activities can be performed. It defines the intent.

Wikipedia defines policy as “A policy is a principle or protocol to guide decisions and achieve rational outcomes. A policy is a statement of intent, and is implemented as a procedure or protocol.”

Policies not only act as guidance for performing various activities but also assist in decision making.

A policy document has to clearly articulate what the policy is all about, its need and ownership of its implementation and adherence.

Some of the key sections of a policy document are:

• Introduction: Any information that will create a baseline and remove ambiguities w.r.t ones understanding of the area/topic covered in the policy document have to be documented in this section. Thus, any definition of the subject covered in the policy document will be defined here.
• Scope: This section has to articulate the scope of the policy in the organization, i.e., it should clearly describe whether the policy is applicable to the complete organization or only selective departments besides the functions or components that will be in scope.
• Policy: This section will describe the policy itself.
• Accountability & Responsibility Towards Policy Adherance: This section describes the accountability and responsibility in terms of ownership of policy implementation.
• Breach: This section describes the actions that will be taken in case the policy is not adhered to.
• Exemption: In case there is any exemption situation when the policy adherence is not needed, this section describes the same as well as it provides details on how such exemption has to be obtained
• References: This section provides recommendation on additional documents that a reader should go through which will act as an enabler for policy adherence.

5 Steps To Create A Proactive IT Organization

Host of IT organizations are reactive. Result is that most of the resources, including the critical ones, are always involved in fire fighting. This leads to:

•          Increased support cost
•          Poor CSAT
•          Customer attrition
•          Poor staff morale and satisfaction
•          Staff attrition

Management always talks about pro-activeness, but in a majority of organizations that I have come across, I felt that such 'commitment' was only vocal or only when there has been a severe customer escalation.

Employees have a feeling 'Proactive...Huh!!!'

The definite requirement for even thinking about creating a proactive IT organization is MANAGEMENT COMMITMENT...a real commitment and not simply a vocal one.

Now a question arises - "Got Management Commitment. Now WHAT???"

Following steps would help you turn your reactive IT organization into a proactive one:

Step 1: Implement Pro-active Problem Management

An effective problem management will ensure that similar incidents are eliminated or at worst minimized. Techniques like Pareto Analysis, Fishbone Analysis, 5 Why, Kepner Tregoe, FMEA and Fault Tree Analysis help in driving Problem Management. While analyzing the trends, a problem manager has to ensure analysis of the following data:

(a) Incident data: To identify incidents that could possibly be because of a problem associated with one of the parent CIs, or identifying trends which could possibly be pointing to a potential problem.

(b) Event data: To analyze event trends that could be pointing to a potential problem.

(c) CI status: To analyze CIs those have undergone frequent maintenance. They can point to a potential problem.

Step 2: Fortify Event Management

If event management is not implemented, then the first activity here would be to implement the same. Subsequently we need to fortify event management through intelligent ticketing. This would drive organization towards proactive incident management where a potential incident is identified and resolved even before it occurs.

Step 3: Implement Preventive Problem Management

A highly matured proactive problem management is towards preventing the problem itself and this is what I refer to as Preventive Problem Management. Ascertain that problem manager has a key role in CAB and that he/she ensures that a change is assessed not only for success of the release but also for potential incidents or problems that the release might lead to. Thereafter, approve changes only when such incidents or problems are eliminated from the release or in worst case resolution identified and KEDB updated.

Step 4: Implement Capacity Management

If capacity is not effectively and pro-actively managed it not only has an impact in terms of inadequate (more or less) capacity but even leads to incidents and problems (in cases where capacity is less). An effective capacity management contributes a lot towards a proactive IT organization and eliminating capacity related downtime.

Step 5: Implement Availability Management

Does meeting your incident SLA mean that your availability SLA is met? No. Not at all!!! Even if you have met your entire incident SLAs, there is likelihood with a high probability that your availability SLA is breached and this probability is near to one for a reactive organization. To minimize or make this probability zero, you need to drive your organization towards pro-activeness and availability management is a key process here. Implementing this process would ensure that your services are designed to provide the committed availability levels and your organization starts to work proactively in this direction.