project pid.doc - barclay rae web viewmis is a small department without a dedicated problem...

Quality Problem Management Process

of 12

Company Ltd. - UK See Document: Project No: [Click here]Project: MIS Service Improvement Project

Contents1. Purpose................................................................................................................22. Scope...................................................................................................................23. Objective...............................................................................................................24. Structure...............................................................................................................25. Problem Management Responsibilities................................................................36. Problem Management Workflow..........................................................................47. Problem Management Process............................................................................58. Major Incident Workflow.......................................................................................89. Major Incident Process.........................................................................................98. Related Documents............................................................................................12

INFORMATION ONLY - Refer to the online system for the current approved document


of 12


1. PurposeThe Purpose of this document is to describe the Problem Management Process in operation within Company UK MIS department (MIS).

It is a reference document for all MIS staff, other IT support staff and management.It documents the agreed procedure for the management and resolution of MIS Problems logged via the Service Desk and internally within MIS.

N.B. A 'Problem' is the underlying cause of one or more Incidents.

2. ScopeThe scope of Problem Management within IT support includes the logging, management and resolution of IT Problems across all Company locations, including the Service Desk, all 2nd and 3rd level Groups and other Abbott staff involved.

3. ObjectiveProblem Management is a wide ranging function covering a variety of diverse activities, which have both short and long term aims. Problem Management’s overall objective is getting to the root cause of Incidents, and then instigating actions to improve or correct the situation. The System X Problem Management system will be configured to easily distinguish between Incidents and Problems.

4. StructureIn the event of a Major Incident and the subsequent Post Mortem review, the role of Problem Manager will be undertaken by a senior member of MIS, not required to be directly involved in the technical resolution of the Major Incident. The most senior member of MIS present will nominate this individual.

All other aspects of Problem Management will be shared amongst all IT Support Groups, supported by the Service Desk team for day to day Problem tracking.

document.doc Edition No.1


of 12


5. Problem Management Responsibilities

MIS is a small department without a dedicated Problem Management team. Therefore, Problem Management responsibilities will be shared between the nominated Problem Managers, the Service Desk and 2nd & 3rd level groups.

a. Reactive Responsibilities

Intervention when escalation times are exceeded - The Service Desk will be automatically informed via System X, when escalation times are likely to be exceeded so the appropriate action can be taken.

Arbitration where ownership of an Incident or Problem is in dispute – The Service Desk will monitor for Incidents that may be ‘bounced’ between technical domains with no team taking responsibility for investigation, diagnosis or resolution.

Liaison with suppliers and vendor staff – Analysts assigned Problems will liaise directly with suppliers and vendors. The Service Desk will oversee liaison to ensure that Incidents and Problems are satisfactorily resolved within SLA targets.

Management of Problem lifecycle – The Service Desk Manager(s) will monitor the Problem database and compile a list of current outstanding Problems for discussion & review at the weekly CAB meetings.

Control of Major Incidents – The nominated Problem Manager will take control of Major Incidents, relieving the Service Desk of what may be a time consuming and long running activity.

Post mortem reviews - As soon as possible after the resolution of a Major Incident, a post mortem will be held to identify what lessons can be learned. The nominated Problem Manager will own this process and chair all meetings.

b. Proactive Responsibilities

Feedback – The Service Desk will feed back information from the investigation and diagnosis of Incidents and Problems, and the analysis of related information into development and procurement functions, training requirements and the production of manuals and documentation.

Trend analysis – The Service Desk will analyse the volume and nature of Incidents so that, over time, trends can be identified. Separate resolution categories will be utilised to aid this analysis.

Targeting actions to reduce worst peaks – The Service Desk will use the Incident analysis and trend information to identify the aspects of service support that cause the most ‘pain’ so that problem areas can be targeted.



of 12


6. Problem Management Workflow



of 12


7. Problem Management Processa. Receiving New Problems

New Problems will be raised from the Incident Management process by the Service Desk and 2nd & 3rd level groups. Workarounds from the Problem Management system Knowledgebase should be implemented where possible to minimise the impact on the Customer.

In other cases a Problem might affect multiple users and an Incident record may have been opened for each case that the Problem was reported. A Problem record must be opened for the overall issue and Incident records must be linked to it via System X.

The Service Desk will identify new Problems from the analysis of Incident statistics. 2nd & 3rd level teams will also report Problems.

b. Problem Logging

All Problems must be logged in System X. Logging enables the management of the lifecycle of the Problem by technical staff and the feedback of up to date information to the Customer, via the Service Desk. The use of key fields for classification also enables reporting to be carried out on trends.

As with Incidents, a Business Impact and categorisation will be assigned to the Problem. Business Impact codes are defined as follows:

Business Impact Level

Description

A An Incident causing an extremely serious impact to the business as a result of the system(s) / service(s) affected and/or the number of people affected by the Incident e.g. A complete loss of the customers’ service or the impacted business function is halted completely and interim restoration is either not possible or not acceptable.

B An Incident causing significant impact to the business as a result of the system(s) / service(s) affected and/or the number of people affected by the Incident e.g. significant loss of customer’s service but the impacted business function is not halted although interim restoration is not possible or not acceptable.

C An Incident which affects the customer’s service but has a small impact to the business e.g. single user or component affected but the trouble can be circumvented.

D Incidents that have a negligible impact to the business, requests or enquiries for information purposes only.

N.B. Although Business Impact codes will be allocated and used for assigning resources, no Priority code is assigned, and therefore there are no Customer



of 12


SLA targets associated with the resolution of Problems due to their long-term nature.

However, if workarounds are not available, an Incident or Major Incident record will remain open until the Problem is resolved and performance will be tracked against the related Incident Priority target.

Incidents relating to a Problem will be linked to the Problem record within System X.

c. Assigning Problems

By definition a Problem requires the technical expertise or access levels of a 2nd or 3rd level team or 3rd Party supplier. Problems are therefore normally assigned outside the Service Desk immediately.

3rd party suppliers do not have access to System X, hence the Problem Manager or an appropriate 2nd or 3rd level resource will own Problems assigned to them.

Where a Problem spans more than one technical team, or where the root cause is unclear, the Problem will be owned by a nominated appropriate Problem Owner who will co-ordinate the efforts of all groups and facilitate a resolution.

d. Knowledgebase Records

Once the root cause has been established a Knowledgebase record will be created. The Service Desk is responsible for the maintenance & housekeeping of the Knowledgebase. Workaround information to be implemented whilst a long-term Problem resolution is sought should be forwarded to the Service Desk via the Knowledgebase facility in System X or E-Mail.

Knowledgebase records will be stored centrally in System X and will be accessible by all Service Desk and 2nd & 3rd level staff.

e. Resolving the Problem

All details of the Problem resolution must be recorded concisely on the Problem record within System X. Any related RFC numbers should be referenced in the Problem record.

Once the Problem is ‘Resolved’, the Problem record should be reassigned to the Service Desk to feed back into the Incident Management process.

f. Closing the Problem

It is the Service Desk’s responsibility to Close Problems. The Service Desk Call Co-ordinator role will be responsible for final closure of

‘Resolved‘ Problems following Customer agreement and a check of the accuracy and completeness of the System X Problem data.



of 12


All linked Incidents must be revisited before the Problem can be Closed.



of 12


8. Major Incident Workflow



of 12


9. Major Incident Processa. Identification

A Major Incident is defined as a serious outage or problem affecting all or large business areas, for example, server or network outages, or a virus outbreak. Therefore, Business Impact A & B Incidents will always be logged as, or escalated to, a Major Incident.

A Major Incident will generally be detected by the logging of one or more Incidents, but may also be detected by 2nd or 3rd level staff.

A Major Incident may also be logged as a response to a significant number of recurring ‘lower’ Business Impact Incidents, e.g. as the result of a significant failure of a Change or as a result of a serious Complaint about service.

At the point at which a Major Incident is identified the Major Incident process is invoked and a Problem Manager is nominated and becomes the central point of contact for all communication and updates relating to the Major Incident.

b. Problem Manager Responsibilities

The nominated Problem Manager will:

Keep the Service Desk informed of the status of the Major Incident at all times Keep the System X Problem record updated at all times Issue updates to MIS management at agreed ‘appropriate’ intervals Issue updates to key business representatives at agreed ‘appropriate’ intervals Co-ordinate and/or assign the roles and responsibilities of multiple Support

Groups as necessary Call and Chair a Post Mortem Review meeting Issue a written Post Mortem report to MIS management.

c. Post-Mortem Review

At the earliest opportunity following the resolution of a Major Incident, the nominated Problem Manager will organise and chair a Post Mortem Review meeting and produce a Major Incident Report.

The meeting will be attended by the following as a minimum:Problem Manager Head of MIS2nd/3rd Level Representative(s) Business Representative(s)3rd Party Representative(s), if appropriate

If the Major Incident is straightforward, e.g. standard hardware fault, the Problem Manager may decide that a formal meeting is not required, and gather any further information informally via e-mail, telephone or one to one conversations.



of 12


It is important to note that the purpose of a Post Mortem is not to assign blame but to identify the root cause(s) of the Major Incident and implement any actions identified to minimise the chances of any recurrence.

A draft Major Incident Report will be issued at least one working day prior to the meeting. Information within this report will be taken from the Problem Record on System X, along with details that may be available from e-mails.

d. The Major Incident Report

The Major Incident Report (MIR) template is shown at the end of this section. As stated above the details within the MIR are taken from a variety of sources,

but chiefly from the System X Problem Record and the Post-Mortem Review meeting. The draft MIR acts as the basis for the full report, and is the catalyst for discussion at the meeting.

The Report is a factual account of what occurred, why it occurred (if known), and what was done to resolve the Incident. Having completed this account the nominated Problem Manager will also make recommendations on:

How to resolve any outstanding Incidents/Problems linked to the Major Incident

Improvements to processes that may have delayed the resolution of the Major Incident

Any other matters that are raised Some recommendations may be deemed impractical through cost or time

reasons, and rejected. However, they will remain within the Report and alternative suggestions implemented and recorded with the reasons.

The primary audience for the report is the management of MIS and those support analysts involved in resolving the Incident. The CAB process will identify when it is appropriate to forward this information to senior management within the business areas affected by the Major Incident.

e. Major Incident Report



of 12


MIR Ref: System X MI No(s):

Date Occurred: User Name:

Incident Type: Priority Recurring Failed Change Complaint

Customer / Site(s):

Service(s) affected:

Problem Status: Solution in place

Interim Fix Long-term solution

Business Impact:Root Cause(s):Support Groups:Description:

Corrective actions: By who: By when: Date Customer Advised

Outcome of Corrective Actions: Date Customer advised:

By who:

Report Closed: By:



of 12


8. Related DocumentsIncident Management ProcessMajor Incident ProcessOperational Change Management ProcessUK Service Level AgreementOperational Level Agreements for MIS UK

AUTHOR & APPROVALWritten by: Date Approved by: Date Approved by: Date

[Click here and type name] [Click here and type name][Click here and type Job Title]

Development Manager & Ops Manager

MIS Manager

REVISION HISTORYEd. No. Reason for Change

1 New document written 2

=== end of document ===
