Policy Series - 3.: Request Fulfillment Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy Service Request is defined as end user requests that an IT organization is required to fulfill.

SCOPE:

This policy is applicable to the entire Request Fulfillment life cycle as described in Request Fulfillment process document. The scope encompasses entire ICT infrastructure of the organization. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Request Fulfillment process will be defined and adopted by the entire organization
• Staff should be trained to ensure that a common understanding on service request and request fulfillment prevails across the entire organization
• Roles and responsibilities shall be defined and communicated for effective Request Fulfillment
• Service desk should be the Single Point of Contact for the users; Ownership of service requests will rest with the Service Desk
• Single Request Fulfillment tool shall be used across the organization; All service requests should be recorded using this tool including:
• Call to service desk
• e-Mails to service desk
• Service desk should ensure the correct logging of service requests (incident tickets should not be logged as an service request)
• Service desk should correctly categorize all service requests
• Priority should be assigned to every service request based on the impact and urgency (Impact - urgency matrix and critical services list should be referred to)
• All service requests shall be provisioned/fulfilled only after required approvals are obtained
• All service requests that has impact on any CI should be fulfilled/provisioned post change approval; Change Management process should be followed at all times in such cases; Tagging of ticket to CI shall be done in all such cases
• Requests not auto-assigned by the tool has to be routed by the Service Desk to relevant support group
• In case the service request is assigned to a support group and not assigned to the individual support engineer, the accountability for ticket assignment lies with both the team/shift lead of that support group as well as with support engineers
• Progress of all service requests should be monitored by service desk and record updated on the progress till resolution and closure
• User should be updated regarding the progress of the service request as per the communication matrix agreed upon till closure of the ticket
• Escalation matrix should be clearly defined and followed
• All SLAs for Request Fulfillment including the ones related to service desk (average wait time, average hold time, etc.) as agreed with the customer should be adhered to
• Customer should be informed of any breach or potential breach of service levels
• Priority of service requests should be upgraded or downgraded only post approval from the concerned approval authority
• Request Fulfillment process performance shall be reported and reviewed periodically
• Continual Service Improvement initiatives should be taken up by Request Fulfillment

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Request Fulfillment Managers, Service Desk Leads and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

REFERENCES

Following documents should be referred to along with this policy document:

• Request Fulfillment process document
• Change Management policy
• Service Level Management policy

Policy Series - 2.: Problem Management Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy problem is defined as underlying unknown root cause of one or more incidents or potential incidents.

SCOPE:

This policy is applicable to the entire problem management life cycle as described in Problem Management process document. The scope encompasses entire ICT infrastructure of the organization. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Problem Management process will be defined and adopted by the entire organization.
• Staff should be trained to ensure that a common understand on problem management prevails across the organization.
• Roles and responsibilities shall be defined and communicated for effective problem management
• All problems should be recorded in the problem logging tool.
• All problems should be updated on progress till resolution and closure.
• Problem ticket should be created for all incidents that do not have a match in the KEDB.
• Problem ticket should be created for all major incidents.
• Proactive problem management should be driven as documented in the problem management process document and create proactive problem tickets. Proactive analysis of repeat incidents should be done to identify and reduce potential problems.
• In case permanent fix is unavailable, workaround should be provided wherever possible to minimize business impact.
• Problem tickets should be correctly logged, categorize and prioritized.
• Priority should be assigned to every problem based on the impact and urgency.
• All problems should be linked to a CI.
• Any corrective actions should be controlled through the Change Management process.
• Known errors should be updated in KEDB for every problem for which resolution is available.
• Problem Management performance shall be reported and reviewed periodically.
• There should be defined reports and review schedules for the closed and pending problems.
• Continual Service Improvement initiatives should be taken up by Problem Management.

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Problem Managers and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

REFERENCES

Following documents should be referred to along with this policy document:

• Problem Management process document
• Change Management policy

Policy Series - 1: Incident Management Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy incident is defined as:

• Unplanned interruption of any IT Service
• Degradation in quality of any IT Service
• Failure of any CI (configuration item) that has not yet affected a service

SCOPE:

This policy is applicable to the entire incident management life cycle as described in Incident Management process document. It includes all the IT services and underlying infrastructure & applications used to deliver the business services. Thus, the scope encompasses entire ICT infrastructure which includes servers (physical & virtual), applications, software, network components, user end devices, etc. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Incident Management process will be defined and adopted by the entire organization
• Major Incident Management sub-process will be defined and followed to address major incidents
• Staff should be trained to ensure that a common understand on incident and major incident management prevails across the entire organization
• Roles and responsibilities shall be defined and communicated for effective incident and Major Incident Management
• Service desk should be the Single Point of Contact for the users
• All incidents should be recorded in the incident logging tool including:
• Call to service desk
• e-Mails to service desk
• Service desk should ensure the correct logging of incident tickets (service request should not be logged as an incident)
• Service desk should correctly categorize all incidents
• Priority should be assigned to every incident based on the impact and urgency (Impact - urgency matrix and critical services list should be referred to)
• All incidents should be linked to a CI
• Tickets not auto-assigned by the tool has to be routed by the Service Desk to relevant support group
• In case the ticket is assigned to a support group and not assigned to the individual support engineer, the accountability to assign the ticket not only lies with the team/shift lead of that support group but also on the support engineers
• Progress of all incidents should be monitored by service desk and incident record updated on the progress till resolution and closure
• Service desk should immediately inform Major Incident Manager in case of major incidents in order to ensure that Major Incident Management sub-process is triggered
• User should be updated regarding the progress of the incident as per the communication matrix agreed upon till closure of the incident
• Roles and Responsibilities should be clearly defined for escalations
• Service desk should ensure escalation of incidents as per the escalation matrix
• All SLAs for incident management including the ones related to service desk (average wait time, average hold time, etc.) as agreed with the customer should be adhered to
• Customer should be informed of any breach or potential breach of service levels 
• Known errors should be made available for effective Incident Management
• Corrective actions should be controlled through the Change Management process
• Incident priority should be upgraded or downgraded only post approval for the concerned approval authority as documented in the process document
• Incident Management performance shall be reported and reviewed periodically
• Continual Service Improvement initiatives should be taken up by Incident Management 

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Incident Managers, Major Incident Managers, Service Desk Leads and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

EXEMPTION:

N/A.

REFERENCES

Following documents should be referred to along with this policy document:

• Incident Management process document
• Problem Management policy
• Change Management policy
• Service Level Management policy
• Availability Management policy

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.