1. ITSM Operational Framework Prepared by: Jacky Frew Section: Integrated Help Services Section Date Created: 11th May 2007Version ControlApril 2007 Version 0.0Jacky Frew June 2007Version 1.0Jacky Frew

2. TABLE OF CONTENTS 1. INTRODUCTION ........................................................................................................................................4 1.1. Background ................................................................................................................................4 1.2. Governance.................................................................................................................................4 1.3. Vendors External to QUT.........................................................................................................4 1.4. Definition of a Service.................................................................................................................4 2. ITSM SECURITY.....................................................................................................................................5 3. ITSM TEAM REQUIREMENTS......................................................................................................................5 4. DASHBOARDS..........................................................................................................................................5 5. ATTACHMENTS, TASK & JOURNAL ENTRIES...................................................................................................6 6. INCIDENT MANAGEMENT ROLES AND RESPONSIBILITIES.....................................................................................6 6.1. Definitions:..................................................................................................................................66.1.1. Service Desk..........................................................................................................66.1.2. Incident Management.............................................................................................6 6.2. Service Desk (IT Helpdesk).........................................................................................................66.2.1. Responsibilities......................................................................................................6 6.3. Incident Manager Responsibilities...............................................................................................7 7. INCIDENT TYPE DEFINITIONS:......................................................................................................................7 7.1. Fault:...........................................................................................................................................7 7.2. Service Request:.........................................................................................................................7 8. INCIDENT STATUS.....................................................................................................................................8 8.1. Draft............................................................................................................................................8 8.2. Logged .......................................................................................................................................8 8.3. Active..........................................................................................................................................8 8.4. Responded..................................................................................................................................8 8.5. Waiting........................................................................................................................................8 8.6. Investigate...................................................................................................................................8 8.7. Resolved.....................................................................................................................................9 8.8. Closed.........................................................................................................................................9 9. INCIDENT PRIORITIES.................................................................................................................................9 9.1. Guide...........................................................................................................................................9 9.2. Priority Definitions.....................................................................................................................109.2.1. CRITICAL.............................................................................................................109.2.2. HIGH....................................................................................................................109.2.3. MEDIUM...............................................................................................................109.2.4. LOW.....................................................................................................................10 9.3. Points also to be considered:....................................................................................................10 10. INCIDENT ESCALATIONS.........................................................................................................................10 11. INCIDENT NOTIFICATIONS........................................................................................................................11 12. INCIDENT OWNERSHIP............................................................................................................................11 12.1. Incident....................................................................................................................................11 12.2. Fault........................................................................................................................................11 12.3. Service Request......................................................................................................................12 12.4. Self Service.............................................................................................................................12 12.5. Transferring Ownership...........................................................................................................12 12.6. Taking Ownership Examples...................................................................................................12 12.6.1. Not a QUT Employee.........................................................................................12 12.6.2. Sick or Extended Leave......................................................................................12 12.6.3. Incident is not logged by the owner....................................................................12 12.6.4. Incident Service Request.................................................................................12 12.6.5. Incident Logged via Self Service........................................................................13Page 2 of 22 3. 13. INCIDENT WORKAROUNDS.......................................................................................................................13 14. INCIDENT RESOLUTION & CLOSURE..........................................................................................................13 15. INCIDENT TASKS..................................................................................................................................1415.1. Task Creation..........................................................................................................................1415.2. Task Assignment.....................................................................................................................1415.3. Task Forwarding......................................................................................................................1415.4. Task Rejection........................................................................................................................1415.5. Multiple Tasks.........................................................................................................................1415.6. Task Sequencing.....................................................................................................................1415.7. Task Completion.....................................................................................................................1415.8. Task Notifications....................................................................................................................1515.9. Task Deletions........................................................................................................................15 16. PROBLEM MANAGEMENT ROLES AND RESPONSIBILITIES................................................................................1516.1. Definition:................................................................................................................................1516.1.1. Problem Management........................................................................................1516.1.2. Responsibilities...................................................................................................1516.1.3. Problem Board....................................................................................................1516.1.4. Problem Workarounds........................................................................................1516.1.5. Problem Closure and Status...............................................................................15 17. PROBLEM TYPE DEFINITION:...................................................................................................................16 18. PROBLEM STATUS................................................................................................................................1618.1. Logged ...................................................................................................................................1618.2. Active......................................................................................................................................1618.3. Waiting....................................................................................................................................1618.4. Investigate...............................................................................................................................1618.5. Resolved.................................................................................................................................1618.6. Closed.....................................................................................................................................16 19. PROBLEM PRIORITIES............................................................................................................................1619.1. Guide.......................................................................................................................................1719.2. Priority Definitions...................................................................................................................1719.2.1. CRITICAL...........................................................................................................1719.2.2. HIGH..................................................................................................................1719.2.3. MEDIUM.............................................................................................................1719.2.4. LOW...................................................................................................................1719.3. Points also to be considered:..................................................................................................17 20. PROBLEM ESCALATIONS........................................................................................................................18 21. PROBLEM OWNERSHIP:.........................................................................................................................1821.1. Problem...................................................................................................................................1821.2. Transferring Ownership...........................................................................................................1821.3. Taking Ownership Examples...................................................................................................1821.3.1. Examples............................................................................................................18 22. PROBLEM WORKAROUNDS.....................................................................................................................1922.1. Problem vs. Incident Workarounds..........................................................................................1922.2. Workaround Documentation & Notification..............................................................................1922.3. Workaround & Known Error....................................................................................................19 23. PROBLEM RESOLUTION & CLOSURE.........................................................................................................19 24. PROBLEM TASKS.................................................................................................................................2024.1. Task Assignment.....................................................................................................................2024.2. Task Forwarding......................................................................................................................2024.3. Task Rejection........................................................................................................................2024.4. Multiple Tasks.........................................................................................................................2024.5. Task Sequencing.....................................................................................................................20 Page 3 of 22 4. 24.6. Task Completion.....................................................................................................................2024.7. Task Notifications....................................................................................................................2124.8. Task Deletions........................................................................................................................21 25. SELF SERVICE.....................................................................................................................................21 26. SELF SERVICE OWNERSHIP....................................................................................................................2126.1. Take Ownership......................................................................................................................2126.2. Incident Ownership..................................................................................................................21 27. CLASSIFICATION...................................................................................................................................211. INTRODUCTION The ITSM business rules have been defined following a number or workshops and visitations to IT support areas. IT support staff have agreed on the ITIL processes for Incident and Problem that can be implemented in the ITSM tool, improving service alignment for support and delivery following best practice methodology. 1.1. BackgroundThe purpose of this document is to define the business rules by aligning ITIL functions and processes together with the ITSM job tracking system. The business rules will be applied across all QUT IT support areas providing standardisation of processes and procedures.The ITSM tool and business rules are aligned with the QUT Service Management Framework, Service Catalogue and ITIL Project. Design of ITSM has incorporated a QUT classification model that allows for statistical reporting of QUT services, based on the service catalogue.The business rules directly reflect ITIL best practice for Incident and Problem Management currently implemented at QUT. The business rules outline the people and technology requirements required in supporting and improving QUT services to clients.Note: the business rules will be updated as additional processes, such as Change Management, are implemented in ITSM, and therefore should be viewed as a living document. 1.2. GovernanceInitially, the first three months following implementation, the governance will be the responsibility of the ITSM steering committee and the ITSM project team. This may at times also involve the IT Service Delivery Advisory Group for recommendations or guidance.After three months of the initial implementation, the governance will then be the responsibility of the Change Advisory Board (CAB). This group will endorse any design, process, etc. changes required to align the business and ITIL in providing improved IT Service Management delivery. 1.3. Vendors External to QUTIt is a requirement that vendors job tracking systems have the ability to integrate with ITSM in the updating and the passing of information between ITSM and their systems using either XML or text file formats. It is important that this point be included in all vendor contracts with QUT. 1.4. Definition of a ServiceFor practical purposes a service can be defined as One or more IT systems, which enable a business process. Page 4 of 22 5. The definition of a service will be restricted to, a service as seen by a client in the first instance. For example, this could be a client application supported by infrastructure made up of any number of IT systems and components. A goal of IT Service Management and the framework is to promote transparency in service delivery to clients. A client does not need to be aware that their incident relates to a business level service (those seen by the client) or an infrastructure level service (those owned by various IT areas that together make up a client facing business level service). If processes and communication are carried out according to QUTs Incident, Problem and Change Management guidelines the make up of the service remains irrelevant to the client.2. ITSM SECURITY Security in ITSM will be attached to a role and the roles will have permissions for required views and actions, involved in the processes available in ITSM. These roles will increase, as more ITIL processes are introduced into the tool.Current roles include the following: Administration Service Desk Analyst Incident Manager Problem Manager Computer Systems Officer CSO Billing Technical Technical Secure 3. ITSM TEAM REQUIREMENTS All teams must supply a team email address. All teams must have a Daily Event Coordinator (DEC). All information recorded in Incidents/Problems should be considered as viewable by the public and therefore subject to the QUT code of conduct. If you are not 100% sure you are the service owner then create a task to the team you think should own the Incident or Problem. 4. DASHBOARDS All support staff are required to monitor the Incident / Problem dashboards. The dashboards will provide a realtime view of current Incidents / Problems and associated tasks.In the majority of cases for Incident Faults most teams will receive work requests via tasks. However, for Incident Service Requests teams will receive Incidents and tasks.It is especially important that Daily Event Coordinators (DECs), Incident and Problem managers monitor the queues and trends on a regular basis encouraging a proactive approach to IT service management.Page 5 of 22 6. 5. ATTACHMENTS, TASK & JOURNAL ENTRIES The following are examples of when attachments, task and journal entries should be used and the type of documentation that you would expect to view under these tabs. It is a requirement that support staff monitor the Activity Log for new entries eg: New Task, Task completed, Journal etc. Attachments: There are no restrictions for attachments. Any file type or size can be attached. Tasks: Documentation in Tasks is required for individual requests to support staff that is specific for that task not the Incident. Journal: Journal entries are required when supporting information concerns the Incident and is required to be viewable by everybody. If client contact has been made this should be documented in the Journal, as it concerns the Incident as a whole. Secure Journal entries This is used when privacy etc. maybe an issue. A secure entry will only be viewable by the support team making it and not global. 6. INCIDENT MANAGEMENT ROLESAND RESPONSIBILITIES6.1. Definitions:6.1.1.Service Desk The Service Desk is a function from the ITIL framework and is known as the IT Helpdesk at QUT acts as the single point of contact between clients and IT service management personnel. The IT Helpdesk plays a key role in Incident Management and this is also inclusive of second level support (CSOs).6.1.2.Incident Management The goal of the Incident Management process is to restore normal service operation as quickly as possible with minimum disruption to the business, thus ensuring that the best achievable levels of availability and service are maintained (Service Support, CCTA, 2000).The Incident Management process at QUT applies to all incidents relating to the IT infrastructure. This includes hardware, software and documentation. 6.2. Service Desk (IT Helpdesk)6.2.1.Responsibilities All faults must be reported and recorded using the IT Helpdesk. If you are not 100% sure of the service owner then create a task to the team you think should action the Incident - Task or Problem if it is a fault. For a service request, create a task to the service provider you think should be the owner. IT Helpdesk staff are required to document all initial testing and checks completed in the Task description field. Any further information supplied either, by the client or support staff member is to be documented in the Journal if it relates to the Incident or added as an attachment. Only the IT Helpdesk can further investigate Incidents that are faults, where they could have been resolved by teams and if required escalate to Incident Manager. Page 6 of 22 7. 6.3. Incident Manager ResponsibilitiesThe Incident Managers role is associated with the IT Helpdesk and is responsible for: The Incident Manager is responsible for ensuring the monitoring of tasks is proactively monitored and bounces from team to team using the reject or forward option are brought to the attention of the Incident Manager. The number of bounces will be viewable in the ITSM Dashboard - Incident Grid. The Incident Manager is responsible for ensuring that workarounds are monitored and provided in Incidents when the check box is selected. A view of workarounds will be available in the Incident Grid. The Incident Manager is responsible for ensuring Problems are created when required and if necessary the Incident Manager can escalate to the Problem Manager as required. Ensure that if there is no resolution for an Incident then the IT Helpdesk can raise a Problem and assign to respective team and if necessary, escalate to the Incident/Problem Manager as required. If an Incident is unable to be classified, then the Incident Manager is responsible to appropriately classify and if required, escalate to ITSM project team. If necessary the ITSM Project team will escalate to the IT Service Management Reference Group. The Incident Manager is responsible for ensuring that all similar Incidents are linked to new or existing Problems. The Incident Manager is responsible for monitoring feedback from clients. The Incident Manager will have a Dashboard Incident grid view that will display dissatisfied responses from customers with the status of Investigate. If a customer is not satisfied the work has been completed, the Incident Manager can change the Incident status to Investigate and if required change to an Active status and reassign the Incident to a Service Provider for actioning. Further Incident Manager responsibilities are as defined in the Service Management Framework (SMF) available at - http://www.its.qut.edu.au/governance/itsm/index.jsp 7. INCIDENT TYPE DEFINITIONS:7.1. Fault:A Fault is any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in the quality of that service. Some examples are: Network is unavailable or slow Email is unavailable or slow Computer will not boot up Software will not open 7.2. Service Request:A Service Request is a service extension. Some examples are: Request for Information or assistance Page 7 of 22 8. Request to install hardware or software Request to change a password Request for a new telephone 8. INCIDENT STATUS The following status used for Incidents and the clarification for each status is listed below.8.1. DraftThis status is used by Self Service only and is the status viewed by the client prior to entering their request details and selecting the Submit button. On Submit the status will then move to Logged and owner as Self Service.8.2. LoggedThis is the status before an Incident has been classified and saved. This is also the status used by Self Service when logged by the client and prior to IT Helpdesk classification of the request.8.3. ActiveThe Incident will automatically move from Logged to Active status when initial classification and save is completed. This status indicates that the Incident is currently being actioned or a task has been created to a service provider. This status also initiates the start of the Service Level Agreement (SLA) and the escalation process.8.4. RespondedThe Incident will automatically move to this status when the first associated task is accepted. However, if the Incident has no associated task(s), then the status can manually be changed to Responded. The status of Responded continues in the progression of the Service Level Agreement (SLA) and the escalation process.8.5. WaitingStatus used when technical support staff are waiting on hardware, software, Request for Change (RFC), etc. generally anything that could be considered beyond the control of the support team. Documentation of the reason is required in the Journal or Task. This will not stop the progression of the Service Level Agreement (SLA) and the escalation process.8.6. InvestigateThis status is only to be used if the Incident Manager is required to investigate and can include any of the following examples: If the resolution of an Incident is unsatisfactory and the client response is NO. The system will automatically move the Incident from Resolved to Investigate status. A client complaint is received and an investigation required. Unable to classify an Incident. Any other reason that impedes the response or resolution of an Incident and requires the Incident Manager to investigate.Page 8 of 22 9. NOTE:If the Incident has not reached Resolved status, the Service Level Agreement (SLA) and the escalation process will continue.8.7. ResolvedThis status initiates an email to the client for sign off for an Incident only. An Incident that is a fault can only be moved to this status by the IT Helpdesk or 2nd level support as they are the owners. An Incident that is a service request can be moved to this status by the owner of the Incident. The Resolved status is the point when the Incident Service Level Agreement (SLA) and the escalation process will stop.8.8. ClosedThis status is used in the following instances: Status used between support staff where there is no client involvement for a service request when an email is not to be initiated. The final status when the customer signs off an Incident providing a YES response. If there is no feedback received from the customer in 5 days, the Incident will automatically move to a closed status. 9. INCIDENT PRIORITIES Priorities implemented in ITSM:4 32 1 LOW MEDIUMHIGH CRITICAL The priority determined will be at the discretion of the IT support staff member logging the request. The default priority is LOW and may require reassessment.When determining a priority, consider the following descriptive guide that is used by fire fighters, as they cannot respond to every fire in the same way eg: 1 building as opposed to multiple buildings. Also QUT specific points are listed below to assist correct selection of the priority. 9.1. GuideIncident priority defines how the organisation will respond in terms of how you will apply management and technical resources. Establishing a priority assignment takes into account multiple aspects of impact (e.g., scope, application, service, reputation, environment, business, etc.) and urgency (e.g., how much time IT has to get the job done.)The fire service use a good model for how IT might respond to incidents. It all begins by defining what resources you have available and how you want to deploy them. This requires a framework for evaluation and escalation. It is not a description of some customer outage, affected users, or litany of services. Instead, it establishes the basis for servicing the customer. Listed below are example definitions: Page 9 of 22 10. 9.2. Priority Definitions9.2.1.CRITICAL This priority means an immediate and sustained effort using all available resources until resolved. On-call procedures activated, vendor support invoked and describes how the IT organisation will respond taking into account any service catalogues and service level agreements.Any reasonable customer would now understand that given such definition of Critical (priority 1) issues, many so-called "urgent" or "critical" requests are not truly urgent or critical after all. How can the IT department apply "all available resources" (internal and external) to every issue? They can't and should not have to either.9.2.2.HIGH This priority means technicians respond immediately, assess the situation, may interrupt other staff working low or medium priority jobs for assistance.9.2.3.MEDIUM This priority means responding using standard procedures and operating within normal supervisory management structures.9.2.4.LOW This priority means responding using standard operating procedures and as time allows.9.3. Points also to be considered: The number of clients affected? Type of client affected eg: VIP, Lecturer, etc? What activity are they trying to do, eg: Exam, Tutorial, Workshops etc? Timing Lab availability during semester as opposed to lab availability for an exam? Is QUTs reputation affected, eg: Newspaper, Conference etc? What is the impact to the business? Is a workaround available? 10.INCIDENT ESCALATIONS Escalations in ITSM are calculated from the time the request is in an ACTIVE status until it reaches a RESOLVED status. The escalations are associated with one standard SLA until Service Level Management module is implemented and as such resolution times are a guide only.Escalations will occur at the following elapsed times or status and initiate an email or SMS to the owner or nominated group. This will also be visually available in the Incident as a colour coded bar.NOTE: The Standard SLA for QUT is for business hours only - 8am to 6pm Monday to Friday outside these hours will not be included.Page 10 of 22 11. Status = Responded Escalation to owner if Incident has not been responded to in set time period 50% of Resolution time Escalation to Incident owner when 50% of resolution time has elapsed. 75% of Resolution time Escalation to Incident team when 75% of resolution time has elapsed. 90% of Resolution time Escalation to Incident teams manager when 90% of resolution time has elapsed. Status = Resolved Escalation to Incident teams manager and Incident manager if not resolved within 100% of the resolution time. PRIORITY RESPONDED 50% 75% 90%RESOLUTION 1 1 hour 4 hours6 hours 7.2 hours8 hours 23 hours 8 hours 12 hours 14.4 hours16 hours 36 hours 16 hours24 hours 28.8 hours32 hours 412 hours36 hours54 hours 64.8 hours72 hoursNOTE: At the time of implementation only the Incident and Problem processes in ITSM will be adopted by QUT. This requires one global Service Level Agreement (SLA) that applies only to Incidents until the Service Level Management process is implemented at a later stage. As a result of this, a very broad resolution time will be adopted to meet the tools requirements for calculating escalations. 11.INCIDENT NOTIFICATIONS Notifications will be sent to the client or incident owner as listed below:Client receives notification that a new incident has been created for them. Client receives a notification when their incident has been resolved. Client receives a notification when their incident has been closed. Incident owner receives a notification when all tasks have been completed. Incident owner receives a notification if an incident has had it owner field changed to them. 12.INCIDENT OWNERSHIP12.1.IncidentOwnership of an Incident can only default to an individual not a team. However, the escalation process is listed below and further references in point 10 with full explanation provided.Owner Team the owner belongs to Manager Manager and Incident ManagerAn Incident can only be edited by the team the individual owner belongs to after it has been recorded and saved.12.2.FaultAll faults must be reported and recorded by the IT Helpdesk. Page 11 of 22 12. The IT Helpdesk will be the owner of all recorded Incident - faults from start to finish and the Incident Manager is responsible for ensuring the resolution and closing of all Incidents. This includes monitoring the contact with the customer to ensure the Incident has been satisfactorily resolved.12.3.Service RequestService Requests can be logged and recorded by all IT Support staff. The team or individual that logged the request is defined as the owner and is responsible for the resolution and closure of Incidents defined as a Service Request.12.4.Self ServiceService Requests logged by clients that are recorded by the IT Helpdesk or via Self Service can have the ownership transferred to appropriate service provider following classification of the request by the IT Helpdesk.12.5.Transferring OwnershipIf the ownership is required to be changed, this can be initiated by creating a Task to the team or individual asking them to take ownership or by changing the owner and team, thereby initiating the notification to the new owner.12.6.Taking Ownership Examples12.6.1.Not a QUT Employee When a person is no longer an employee of QUT then, the team can take ownership of their Incidents / Problems and Tasks.12.6.2.Sick or Extended Leave When a person is on sick or extended leave the team will be required to take ownership of their Incidents / Problems and Tasks.12.6.3.Incident is not logged by the owner When an Incident / Problem is logged on behalf of a support staff member, the person requesting is required to take ownership. An example: the support staff member is unable to access a computer to log the original request. This does not apply to an Incident Fault as the IT Helpdesk are the only group that can own an Incident Fault. Changing the ownership can be initiated by creating a Task to the team or individual asking them to take ownership, or changing the ownership and thereby initiating the notification to the new owner.12.6.4.Incident Service Request When an Incident - Service Request is logged by contacting the IT Helpdesk or via self service, then the ownership can be moved to the appropriate service provider. If ownership is required to be changed this can be initiated by creating a Task to the team or individual asking them to take ownership, or by changing the ownership and thereby initiating the notification. Page 12 of 22 13. 12.6.5.Incident Logged via Self Service When a Service Request or a Fault is logged via Self Service the IT Helpdesk are required to use the Take Ownership button as the Incident must belong to a person and cannot remain as the owner being Self Service. 13.INCIDENT WORKAROUNDS Teams can document Incident workarounds and select the tick box option under the resolution tab. The selection of the workaround tick box will be viewable in the Incident Dashboard to assist support staff. If an Incident workaround is available and a Problem is required to be created then, only a representative sample of Incidents are required to be linked to the Problem. If there is no workaround available then, all Incidents are required to be linked to the Problem. Incident workarounds are not recorded in the knowledge base, only Problem workarounds. However, at this stage the knowledge base will not be implemented in ITSM. 14.INCIDENT RESOLUTION & CLOSURE An Incident - fault can only be moved to a Resolved status by IT Helpdesk and 2nd level support, (CSOs). If you are not a member of above support teams eg: are 3rd level support then you must complete the resolution and save, but do not move the status to Resolved. When all tasks and the resolution have been completed, then the IT Helpdesk or 2 nd level support will determine if the Incident can be resolved and change the status to Resolved. It is at the discretion of all IT support staff if they contact the client to confirm that the fault or service request has been completed to their satisfaction and this is required to be documented in the resolution if client contact has been made. When resolving an Incident, if the Incident has Tasks associated with it, then the First Call Resolution is always NO. When an Incident is placed in a Resolved state, the system will automatically initiate an email to the client for sign off. If no client sign off is received after 5 days, then the system will automatically change the status from resolved to closed. An Incident can only be reopened in a Resolved state but not a Closed state. Resolved and Closed Incidents can be linked to Problems. Page 13 of 22 14. 15.INCIDENT TASKS15.1.Task Creation A Task can be created by any individual. For example, if you receive a task and require work to be done by another team, then you can also create a task to send to that team.15.2.Task Assignment If you are unable to resolve at first point of contact with the client, then a task is required to be created and assigned to the appropriate service provider for assistance. Tasks must be assigned to a team and it is optional to include an individual (Assignee). 15.3.Task Forwarding If a task is to be forwarded to another team then, a reason must be provided and entered in the notification. If you do not know the support team to forward a task to, then forward with a reason to the Incident Manager who will then assign to correct team for actioning. 15.4.Task Rejection If a task is rejected, a reason must be provided and may require the Incident manager assigning ownership where the task appears to be bouncing between service providers. All Incident Faults that have associated tasks and when these tasks are rejected will automatically be sent back to the owner. In this case, the IT Helpdesk as they will own all Incident Faults. All Incident Service Requests that have associated tasks and are rejected will automatically be sent back to the owner. In this case, the support person who logged the initial service request. 15.5.Multiple Tasks When an Incident has associated tasks and when each task has been completed, then the owner of a task can make a decision on whether to contact the client for feedback if required. If the client has been contacted this should also be documented in the Journal. 15.6.Task Sequencing When an Incident has associated tasks required to be completed in a sequence then as each task is created it should have the corresponding number for the order of completion entered in the text box provided. 15.7.Task Completion As tasks are completed a view will be displayed in the Incident Dashboard so all teams will be aware of status. However, this does require that all teams monitor their dashboards to assist in managing workloads and service levels. Page 14 of 22 15. If a task is allocated to a team from an Incident and this Incident is then linked to a Problem with the task still open, then when the Problem is resolved and closed you will receive a message advising if any Incidents with open tasks. The tasks that are open are required to be closed to allow the Problem to be set to a closed status enabling the Incidents linked to change to a resolved status. There will also be a graphical view in the dashboard Incident grid and tab displaying Incidents with open tasks. 15.8.Task Notifications On the creation of a new task a notification will be sent to the Team. However, if there is a selection of an Assignee, then the notification will go to the Assignee only. 15.9.Task Deletions In ITSM you cannot delete a task. If you have mistakenly created a task then complete the task documenting the reason and then create another if required. 16.PROBLEM MANAGEMENT ROLESAND RESPONSIBILITIES16.1.Definition:16.1.1.Problem Management The goal of the Problem Management process is to minimise the adverse effect on the business of incidents and problems caused by errors in the infrastructure, and to proactively prevent the occurrence of incidents, problems and errors (Service Support, CCTA, 2000).16.1.2.Responsibilities The Problem Managers responsibilities are as defined in the Service Management Framework (SMF) available at - http://www.its.qut.edu.au/governance/itsm/index.jsp16.1.3.Problem Board The Problem Manager is responsible for ensuring the Problem Board has up to date information available for support staff.Some examples include: archiving old Problems, removal of Problems mistakenly saved to the Problem Board or those that are considered local and not global.16.1.4.Problem Workarounds Initial implementation of ITSM does not include the knowledge base that records all Problem Workarounds. However, the Problem Manager is responsible for ensuring workarounds are recorded in the Problem resolution and that those workarounds are communicated to the IT Helpdesk and relevant service managers as required. 16.1.5.Problem Closure and Status Only a Problem Manager can set a Problem to a Closed status as this status will automatically change linked Incidents to a Resolved status and initiate an email to the clients requesting sign off.Page 15 of 22 16. 17.PROBLEM TYPE DEFINITION: The type is Problem only. The Problem is not defined as in Incident in relation to a fault or a service request as this is not required.18.PROBLEM STATUS Problem statuses must be changed manually as there is no system automation as in Incident.The following statuses are used for Problems and are similar to Incident; the clarification for each status is listed below.18.1.LoggedThis is the initial status before a Problem has been classified and saved.18.2.ActiveThis status indicates that the Problem is currently being actioned or a task has been accepted by a service provider. This status requires a manual selection by IT support staff.18.3.WaitingStatus used when technical support staff are waiting on hardware, software, Request For Change (RFC), etc. generally anything that could be considered beyond the control of the support team. Documentation of the reason is required in the Journal or Task.18.4.InvestigateThis status is only to be used if the Problem Manager is required to investigate and can include any of the following examples: If the resolution of a Problem is unsatisfactory. A client complaint is received and an investigation required. Unable to classify the Problem. Any other reason that impedes the response or resolution of a Problem and requires the Problem Manager to investigate.18.5.ResolvedThis status indicates the Problem is resolved. IT support staff can only moved to Resolved status to indicate to the Problem Manager it is ready for closure. It should also be noted that linked Incidents with tasks are required to have all tasks completed so the Problem is ready for closure.18.6.ClosedThis status indicates the Problem is resolved and waiting for the Problem Manager to move to a Closed status if satisfied and will initiate emails to clients with any linked Incidents. 19.PROBLEM PRIORITIES Problem has no coloured bar as in Incident as there are no Service Level Agreements (SLAs) or escalation processes. Also if the priority has been created from an Incident then this will populate the Page 16 of 22 17. priority field. However, a Problem priority should be re-evaluated and corrected if required by following the same guide and points to consider provided for an Incident.The priority determined will be at the discretion of the IT support staff member logging the request. The default priority is LOW and may require reassessment.When determining a priority, consider the following descriptive guide that is used by fire fighters, as they cannot respond to every fire in the same way eg: 1 building as opposed to multiple buildings. Also QUT specific points are listed below to assist correct selection of the priority. 19.1.GuideIncident priority defines how the organisation will respond in terms of how you will apply management and technical resources. Establishing a priority assignment takes into account multiple aspects of impact (e.g., scope, application, service, reputation, environment, business, etc.) and urgency (e.g., how much time IT has to get the job done.)The fire service uses a model for how IT might respond to incidents. It all begins by defining what resources you have available and how you want to deploy them. This requires a framework for evaluation and escalation. It is not a description of some customer outage, affected users, or litany of services. Instead, it establishes the basis for servicing the customer. Listed below are example definitions:19.2.Priority Definitions19.2.1.CRITICAL This priority means an immediate and sustained effort using all available resources until resolved. On-call procedures activated, vendor support invoked and describes how the IT organisation will respond taking into account any service catalogues and service level agreements.Any reasonable customer would now understand that given such definition of Critical (priority 1) issues, many so-called "urgent" or "critical" requests are not truly urgent or critical after all. How can the IT department apply "all available resources" (internal and external) to every issue? They can't and should not have to either.19.2.2.HIGH This priority means technicians respond immediately, assess the situation, may interrupt other staff working low or medium priority jobs for assistance.19.2.3.MEDIUM This priority means responding using standard procedures and operating within normal supervisory management structures.19.2.4.LOW This priority means responding using standard operating procedures and as time allows. 19.3.Points also to be considered: The number of clients affected?Page 17 of 22 18. Type of client affected eg: VIP, Lecturer, etc? What activity are they trying to do, eg: Exam, Tutorial, Workshops etc? Timing Lab availability during semester as opposed to lab availability for an exam? Is QUTs reputation affected, eg: Newspaper, Conference etc? What is the impact to the business? Is a workaround available? 20.PROBLEM ESCALATIONS There are no escalations for Problem implemented in ITSM as there is no Service Level Agreement (SLA). 21.PROBLEM OWNERSHIP:21.1.Problem A Problem can be initiated by any support staff member, providing they are associated to a role in ITSM. A Problem can only be logged under support staff user information. A Problem cannot be logged for a client, only an Incident. If required, a Problem can be raised and the specific Incident(s) linked to the Problem. Ownership of a Problem can only default to an individual not a team. However, the team that individual belongs to will own the Problem from start to finish. Ownership of a Problem can be transferred to a service providers team. This can be executed in the same way as Incident where a task is created to that team asking them to take ownership using the Take Ownership button, or by changing the ownership and initiating the email notification to the new owner. If you are not 100% sure who the service owner should be for a Problem then create a task to the team you think should own the Problem. If a Problem or task from a Problem is bounced from team to team, then the Problem Manager(s) will assign ownership to a service provider for actioning. 21.2.Transferring OwnershipIf the ownership is required to be changed, this must be initiated by creating a Task to the team or individual asking them to take ownership, or by changing the ownership and initiating the notification to the new owner.21.3.Taking Ownership Examples21.3.1.Examples The following are some examples where a service provider or individual maybe required to Take Ownership. If you require a more detailed explanation, please refer to Incident Taking Ownership examples. Not a QUT Employee Sick or Extended Leave Problem is not logged by the Owner Page 18 of 22 19. Change of ownership to another service provider 22.PROBLEM WORKAROUNDS22.1.Problem vs. Incident WorkaroundsIncident and Problem workarounds differ in that; Incident workarounds are not recorded in the knowledge base. However, when a Problem is resolved and the resolution completed, this resolution then becomes the workaround and is recorded in the knowledge base when implemented. 22.2.Workaround Documentation & NotificationAll teams are required to document workarounds in the Problem resolution tab and advise the IT Helpdesk or other affected service providers by sending a task advising of the Problem workaround and resolution. 22.3.Workaround & Known ErrorWhen a Problem is moved to a closed state then the workaround/resolution becomes a Known Error and will be stored in the knowledge base when implemented. 23.PROBLEM RESOLUTION & CLOSURE When a Problem is placed in a resolved state, the system will not initiate an email to the client as a Problem only has an owner. A Problem can only be reopened in a Resolved state, not a Closed state. Resolved and Closed Incidents can be linked to a Problem. The Problem owner is responsible for Resolving a Problem and requires the following actions to occur. o All tasks for the Problem are required to be completed o All task for linked Incidents are required to be completed o Classification of the Problem is correct o Any workarounds are fully documented and communicated as required o The Resolution and Root cause are completed o Change the status to Resolved o The Problem owner cannot change to a Closed status The Problem Manager is responsible for ensuring the following actions occur. o All documentation is completed o The Problem Manager is satisfied with the resolution. o Changes the status to Closed o Ensure the status of linked Incident(s) automatically move to a Resolved state as this will initiate an email to the client for sign off Page 19 of 22 20. 24.PROBLEM TASKS24.1.Task Assignment If the Problem owner is unable to resolve, then a task is required to be created and assigned to the appropriate service provider for assistance. Tasks must be assigned to a team and it is optional to include an individual (Assignee). 24.2.Task Forwarding If a task is to be forwarded to another team then, a reason must be provided and entered in the notification. If you do not know the support team to forward a task to, then forward with a reason to the Problem Manager who will then assign to correct team for actioning. 24.3.Task Rejection If a task is rejected, a reason must be provided and may require the Problem manager assigning ownership where the task appears to be bouncing between service providers. All Problems that have associated tasks and when these tasks are rejected will automatically be sent back to the owner. 24.4.Multiple Tasks When a Problem has associated tasks and when each task has been completed, then the owner of a task can make a decision on whether to contact the client for feedback if required. If the client has been contacted this should also be documented in the Journal.24.5.Task Sequencing When a Problem has associated tasks that are required to be completed in a sequence, then as each task is created it should have the corresponding number for the order of completion entered in the text box provided.24.6.Task Completion The Problem owner is responsible for ensuring that all tasks are completed, this includes tasks associated with linked Incidents to a Problem that have open tasks. As tasks are completed a view will be displayed in the Problem Dashboard so all teams will be aware of status. However, this does require that all teams monitor their dashboards to assist in managing workloads and service levels. If a task is allocated to a team from an Incident and this Incident is then linked to a Problem with the task still open, then when the Problem is resolved and closed you will receive a message advising if any Incidents with open tasks. The tasks that are open are required to be closed to allow the Problem to be set to a closed status enabling the Incidents linked to change to a resolved status. There will also be a graphical view in the dashboard Problem grid and tab displaying Incidents with open tasks. Page 20 of 22 21. 24.7.Task Notifications There are no notifications for tasks associated with Problems. 24.8.Task Deletions In ITSM you cannot delete a task. If you have mistakenly created a task then complete the task documenting the reason and then create another if required.25.SELF SERVICE All Self Service requests logged by clients will be reclassified by the IT Helpdesk whether it is an Incident fault or a service request and ownership to appropriate service provider assigned.The Self Help and Self Service queue is to be maintained by the IT Helpdesk. If a Self Service request is determined to be a Problem, then it will follow the same business rules as outlined for a Problem.The client will have the ability to view the current status of their request and the requests they have logged via Self Service or by using the IT Helpdesk.26.SELF SERVICE OWNERSHIP26.1.Take OwnershipThe IT Helpdesk will have a dashboard, Incident grid view that will display the owner as Self Service when initially logged by the client.The IT Helpdesk are required to Take Ownership before completing the classification of the Incident by using the Take Ownership button. 26.2.Incident OwnershipWhen the Self Service request has been classified by the IT Helpdesk, then the same business rules apply as for Incident Fault and Incident Service Request.27.CLASSIFICATION When the IT Helpdesk has taken ownership from Self Service then the following is required: If information provided by the client is incomplete or clarification is required then the IT Helpdesk will contact the client for further details. Ensure client location and contact details are complete. Select required type of Incident Fault or Service Request. Select appropriate service categories. Select appropriate owner. For a Fault no change will be required as when the Take Ownership button was selected this would automatically change the Team and Owner field to that IT Helpdesk staff member. For Service Request, select appropriate Team and Owner. Ensure there adequate and accurate information in the Summary and Details field. Page 21 of 22 22. Create a Task if required and SAVE the Incident.On completion of the reclassification of the Self Service request, the same business rules will apply as for Incident and Problem.Page 22 of 22