B6 Communication related to exceptions

B5 Communication related to changes

Change Management is covered in detail in the ITIL Service Transition publication and includes information about change communication. However, it is necessary to stress the nature of operational communication about changes.

Purpose	To support the Change Management process by:· Assessing the potential impact of and resources required for the change Ensuring that each team is aware of the nature and schedule of changes that have been assigned to them Building, testing and deploying changes in their environment Ensuring that each team reports that progress on each change Notifying Change Management that a change is ready for deployment Backing out changes that were unsuccessful and communicating the results to Change Management Assisting in the assessment of changes to ensure that they have been implemented correctly
Frequency	The frequency of communication related to changes is determined by the nature of the change and the times set forth in the Change Schedule. Most teams or departments will review changes on a daily or weekly basis. Each day they will discuss and prioritize all new changes assigned to them and report on the progress of changes they are working on. After each change they will report on the success of each change and ensure that any remedial action required is initiated.
Role Players	Change Manager, administrators and coordinators Team-leaders, Department Heads, Shift Managers or Project Managers Service Operation staff involved in building, testing and deploying changes (usually Technical, Application and IT Operations Management teams or department) Managers of Test Environments and teams Change or Release Deployment teams
Content	Requests for and authorization of changes Reports on the feasibility of a change Reports on the resources required to build, test or deploy a change Change Activity Scheduling Detailed descriptions of the change and the activities required of each team or department Progress and status reporting of change activity Test results Exception Reports, including details of the execution of Back-out Plans
Context / sources	RFCs Change Control communication (during daily or weekly operational meetings, or by e-mail, conference call or using the Change Management tools) Change Advisory Board meetings Release Plans Projected Service Availability reports· Change Reviews

Table B.8 Communication about changes

In this context an exception refers to any occurrence that is outside normal or expected activity or performance. The most common form of exception is an Incident (which is covered in detail in section 4.2 of this publication). There are other exceptions that do not necessarily go through Incident Management, such as a process exception (which will be handled in the context of that process or by a Quality Assurance process); a team, department or individual whose performance is not up to standard (which will be handled through HR disciplinary procedures); or an exception to a vendor’s contractual performance. Although these are not all directly related to Service Management, they will add overheads to the level of communication required of staff during the Service Operation phase.

Purpose	Communication during or after exceptions is aimed at: Informing the appropriate people of the exception Assessing the significance, severity and impact of the exception Ensuring that resources with the appropriate skills and seniority are involved in resolving the exception and taking action to prevent future recurrence Providing updates to stakeholders that are affected by the exception
Frequency	This type of communication is reactive and ad hoc, in that it does not occur unless there is an identified exception or the risk of an exception. The frequency is thus directly proportional to the frequency of exceptions. Once an exception is detected, the frequency and content of communication will be determined by the impact, urgency and severity of the exception.
Role Players	The exact role players will depend on the type and extent of the exception, but could include: Incident Management The Service Desk Problem Management Process owners (if the exception relates to process performance) Departmental managers or team leaders SLM Human Resource Management Technology Managers and experts Vendor account management staff Vendor technical experts
Content	Description and assessment of the exception Assessment of the impact. This will typically involve communication with the stakeholders who are affected by the exception Estimation and then confirmation of the cost of resolution A decision on what action will be taken Communication of the decision taken. This is likely to be in a number of formats. For example the communication to customers is likely to contain an apology and a high-level overview of what is being done to resolve the exception. A communication to the people who are expected to resolve the exception will be more detailed and will contain clear actions and timelines Confirmation that the exception has been resolved
Context/sources	Process Reviews Change Reviews Service Level Reviews Events Trend Analysis of processes, devices, team performance, etc. Incident, Problem and Change Records Customer satisfaction surveys.

Table B.9 Communication during exceptions

Дата добавления: 2014-12-23