Announcement or reminder of training that may be available over the next week or month to give staff and their supervisors time to schedule the training into the Operations Schedule
| Context/sources |
- Operations Logs
- Incident Reports
- Problem Reports
- Maintenance Schedules
- Change Schedule
|
B2. COMMUNICATION BETWEEN SHIFTS
|
Table B.2 Communications Requriements Between Shifts
|
| Purpose | This communication ensures that the hand-over between outgoing and incoming shifts is smooth and also makes
the new shift aware of any potential difficulties. They also ensure that the new shift is aware of any tasks that
need to be completed.
|
| Frequency | At the handover of every shift
|
| Role Players |
- Shift leaders of each shift
- Staff from each shift who perform similar tasks
|
| Content |
- A summary report on operations undertaken during the previous shift
- A summary of all exceptions and alerts that were resolved during the shift
- Details of any outstanding exceptions and alerts, with information about all actions taken to the current point
and any information about anticipated future actions (e.g. a vendor is expected to be on site to provide support during the next four hours)
|
| Context/sources | Communication between shifts will usually be based on the following sources:
- Shift logs
- Shift Leader's report
- Interpersonal verbal or electronic 'chat' communication where shift personnel are in different facilities
|
B3. PERFORMANCE REPORTING
Performance Reporting in the context of communication refers to three main areas, as set out below:
-
IT Service Performance
This category of Performance Reporting is generally done as part of SLM and is covered in the Continual Service Improvement publication. However, there is a very important aspect of Service Reporting that concerns Service Operation, namely that it is the Service Operation teams or departments that are required to record and communicate the information that goes into these reports.
However, Service Operation staff are not in the best position to decide on the content, format and frequency of Service Performance Reporting. The requirements for this type of communication have to be to be clearly defined during Service Design and refined during Continual Service Improvement.
- Service Operation team or department performance
This is an 'internal' communication in that it takes place between the members of a team or department and their manager, or a process manager and the team that executes the process. People outside of these teams or departments should not be involved in this type of communication as it is aimed at managing people rather than measuring the quality of a service.
However, it is a common mistake for IT departments to communicate this type of information to customers as if it were the same as reporting on Service Quality. For example, a manager might report that their department solves 80% of all problems. As far as the average user is concerned, however, this information is irrelevant. They are more concerned with whether their IT Service performed as agreed. In addition, disclosing internal information to customers and users could be embarrassing for the Service Operation teams and departments and could result in high levels of interference from the business to 'correct' perceived problems.
- Infrastructure or process performance
As with team or department performance, this is an 'internal' communication that takes place between the members of a team or department who are responsible for managing an infrastructure component or system, or the members of a process team. People outside of these teams should not be involved in this type of communication as it is aimed at managing people rather than measuring the quality of a service.
|
| Table B.3 Performance Reporting Requirements: IT Services
|
| Purpose | To provide information to the groups responsible for IT Service reporting to customers and users, which they can
use to demonstrate the achievement of service targets and as input to Service Level Review meetings The
information can also be used as a basis for charging for IT services
|
| Frequency | As defined in the SLAs and OLAs. This information is usually communicated regularly on a daily, monthly and
quarterly basis.
|
| Role Players | - Service Operation teams and departments, usually IT Operations staff
- SLM staff
- Service Design teams (who help to define performance standards and refine these through Continual Service Improvement)
- Continual Service Improvement teams, especially those tasked with Service Reporting
|
| Content | Examples of the type of Service Performance information that needs to be communicated to enable reporting on
Service Performance are:
- Achievement of specific activities as defined in OLAs
- Achievement of targets for delivery of specified outputs
- Service or system availability achievements
- Ability to meet Service Maintenance Objectives within targeted times and impact levels
|
| Context/sources | - Monitoring and reporting tools
- Event Logs
- Shift Logs
|
| Table B.4 Performance Reporting Requirements: Service Operations Team or Department
|
| Purpose | There are three main purposes of Service Operation team or department Performance communication:
- Proactively, to ensure that Service Operation staff are executing the activities required to deliver IT services and to support the IT Infrastructure
- To detect potential issues with resource levels, capability and circumvention of procedures
- To ensure that corrective action has been correctly implemented and adhered to
|
| Frequency | There is no set frequency for this type of communication. Although some Performance Reports may be produced
daily, weekly or monthly, most managers are involved in ongoing communication with their teams or
departments as the situation requires.
Under normal operating situations, this communication will tend to be less frequent than in situations where
there is a high degree of change or where the organization is experiencing high numbers and severity of
incidents
|
| Role Players | - Service Operation Managers
- Service Operation staff
- Performance issues may be escalated to the Service Manager or CIO
|
| Content | - Comparison between required and actual performance
- Trends of performance over time
- Specific reports of misconduct or failure to perform a required action
|
| Context/sources | - Regular performance reports, e.g. Incident Logs, maintenance records, process metrics
- Interpersonal and verbal communication during working situations
- Team or department meetings
- Coaching by a team leader or manager
- Investigation following a poor Service Report may initiate a series of communications in Service Operation
- Individual Performance Appraisals, usually using (KPIs) documented in the individual's job description
|
| Table B.5 Performance Reporting requirements: infrastructure or process
|
| Purpose | There are at least three purposes of this type of communication:
- To ensure normal operation of the infrastructure or a process
- To detect potential issues with the infrastructure or process concerned
- To ensure that corrective action has been taken and that it was effective
|
| Frequency | The frequency of this type of communication will vary depending on the nature of the system(s) being managed
or the process being executed.
Some components of the infrastructure are more volatile and will require frequent communications and even
meetings to ensure that it performs predictably. More stable components will simply require a confirmation that
everything is still working as expected.
Some processes have a requirement of frequent reporting and communication. For example, Incident
Management may require updates every five minutes for a high-impact incident. Other processes do not need to
communicate that frequently. For example Capacity Planning needs to communicate changes on a monthly or
even quarterly basis.
|
| Role Players | - Staff who manage key CIs
- Staff who execute processes
- Process owners and technology managers
- Potential escalation to more senior managers, the Service Manager
|
| Content | - Comparison between required and actual performance
- Trends of performance over time
- Specific reports of missed targets or unexpected levels of performance
|
| Context/sources | - Event Logs
- System Performance Records
- Process Performance Reports
- Incident and Problem Records
- Exception Reports and Audit Reports
- Review with vendor
- Service reporting may indicate a problem with one or more technology areas or processes
|
B4 COMMUNICATION IN PROJECTS
Service Operation staff are often involved in projects. This may be to provide input to a new design, or to assist in verifying utilization or throughput rates, or to assist in conducting tests of new or changed services. In other cases the projects may affect existing OLAs and their feedback will be required. It must be recognized that this involvement will add to the level of communication that these individuals will be receiving and transmitting. This will require additional time and focus, which should be allowed for by managers assigning resources to projects on a part-time basis.
Formal project communication tends to follow the cycle of project meetings. For example:
- Weekly or monthly project meetings will be held with
the Project Manager and the individual team leaders A monthly status update will be sent to the project's
- Executive Sponsor and possibly other key stakeholders
- Exceptions and the result of quality assurance checks are reported into Project Assurance teams, who in turn will communicate the need for corrective action as necessary.
Inside each team, communication will be more focused on completing their tasks and will generally be more frequent than the project-wide communication.
There is likely to be a high level of less formal communication inside each team and also between teams to ensure that tasks are completed on time and promised resources are available when and where they are supposed to be. Extensive communication is also required as part of the hand-over from one team to another as the project moves from one stage or phase to another. An important rule of thumb is to document any communication that could potentially affect the outcome or the cost of the project.
|
Table B.6 Communications with Projects
|
| Purpose | Project communication as multiple purposes, including:
- To gain support from project stakeholders - this communication will focus on the scope, cost and benefits
of the project and will seek to demonstrate an overall return on the project's investment
- To ensure that all members of the project team understand and are aligned to the objectives of the project
- To assign work to individuals or teams
- To schedule activities and ensure that resources are ready to begin their stage of the project
- To check on and report the progress of the project
- To detect and escalate potential exceptions or delays in the project
- To prepare project customers and audiences for the rollout of the solution being built
|
| Frequency | The frequency, role players and content of communication will depend on the nature of the project and the type
of Project Management methodology being used
|
Table B.7 Communication on hand-over of projects
|
| Role Players | - Project Manager and project administrative and coordination staff
- Project Sponsor
- Key Project Stakeholders (e.q. customers, IT Managers, Board members, users, etc.)
- Project teams and individual contributors
- Vendor sales and technical staff where the purchase of services or solutions are part of the project
|
| Content | - Gathering requirements for the solution being built by the project
- Project scheduling
- Project 'Marketing' information including Return on Investment or Business Case information
- Status updates
- Gathering information to complete a task
- Events that could affect the scope, cost or timely completion of the project
- Progress reporting within teams or between teams
- Information about the results of testing
- Notifications to teams or individuals that the project is approaching 'their' stage or activity and that they
should make the appropriate preparations
- Reporting on the successful completion of activities
- Review of the overall success of the project
|
| Context/sources | - Project Charter
- Project Budget
- Statement of requirements
- Project Schedule
- Project meetings
- Team meetings
- Status and progress reports
- Test reports
- Customer sign-off documentation
- Post-Implementation Review
|
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.
|
Table B.8 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 Outage reports
- Change Reviews
|
B6. COMMUNICATION RELATED TO EXCEPTIONS
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.
|
Table B.9 Communication during exceptions
|
| 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
|
B7. COMMUNICATION RELATED TO EMERGENCIES
Although ITIL specifies how to deal with urgent, highimpact situations such as disasters (IT Service Continuity Management) and Major Incidents (Incident Management), managers in the Service Operation phase will find themselves dealing with various types and scales of emergency not covered in these processes. It is important to note that this is not a separate process, rather it is a view of several processes and situations from a communication perspective.
Communication during emergencies is similar in purpose and content to communication during exceptions. The
main differences are in the level of urgency and impact of the exception.
Emergency communications are usually initiated by the Incident Manager (see paragraph 4.2.5 for a discussion on Major Incidents) or by a senior IT Manager who has been designated as the escalation point for all such emergencies.
In the case where an IT Service Continuity Plan is invoked, this will include a detailed Communication Plan to be executed by the appropriate authority.
The Incident Manager or designated manager will often form a response team, and the communication is initiated and coordinated by this team.
|
Table B.10 Communication during emergencies
|
| Purpose | The purpose of communication in an emergency is to immediately investigate and confirm the impact and
severity of the Incident to confirm that it is indeed an emergency situation. It should also confirm that this
Incident does not represent a disaster or any contingency covered in the IT Service Continuity Plans.
As soon as the scope of the emergency has been identified, the team responsible for managing the situation will
allocate resources to create an action plan and to begin resolving the emergency and restoring service.
|
| Frequency | This type of communication does not occur unless there is a Major Incident or emergency situation.
Once an exception is detected, the frequency and content of communication will be determined by the impact
and severity of the exception, and potentially by a Service Recovery Plan.
|
| Role Players | - Incident Manager
- Senior Managers of groups responsible for the IT staff that will be required to resolve the situation
- Business managers and Executives (possibly including legal staff if the organization is exposed to potential
legal action as a result of the incident)
- Customers and users
- IT Service Continuity Manager and Central Coordination team
- Senior vendor staff and managers (depending on the extent and nature of the situation)•
- Technical Management staff and managers
- Application Management staff and managers
- IT Operations Management staff and managers
|
| Content | - The nature and extent of the emergency
- 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 | - Incident Record for Major Incidents
- Events
- Crisis or emergency meetings called by the Incident Manager, the designated manager, or the IT Service
Continuity Manager
| B8. COMMUNICATION WITH USERS AND CUSTOMERS
This section appears last, not because it is the least important, but because it incorporates several of the areas discussed above. An important principle in communicating with customers is that communication should not focus
on internal aspects of Service Operation. The focus is on the customer or users' requirements and what IT is doing to meet them. This should not involve technical descriptions and detailed information about internal processes.
| Table B.1 1 Communication with users and customers
| | Purpose | There are a number of reasons for user and customer communication in Service Operation. These include:
- Ensuring that services have been delivered as agreed
- Communication around fulfilling Service Requests
- Reporting Incidents and keeping users and customers updated on their status until resolved
- Notifying users and customers of changes that may impact them
- Providing access to services
- Dealing with potential security issues
- Scheduling activities that involve users or customers, e.g. maintenance
- Notification of special business events that require additional support or changed priorities
- Review of customer and user satisfaction
- Coordination during contingency situations
| | Frequency | Communication with users and customers is ongoing. The format and content of communication will be defined
by the processes that are being executed. For example, communication about an Incident will be determined by
the Incident Management process.
Some communication will be formal and scheduled, e.g. providing reports on the performance of a service
during a review meeting. Other communication will be formal, but ad hoc, e.g. communication about the status
of an Incident
| | Role Players | The identity of the role players and their number will depend on which process is being executed, the type of
situation that has occurred and the scope of what is being communicated, e.g. providing an update about the
status of a Service Request will have a very different audience than when participating in a Service Level Review
meeting
| | Content | The content of this communication will vary depending on the context. However, it is important to gear the
communication to the audience. This means using service names rather than server or application names, being
professional, avoiding technical jargon, not being condescending and treating customers and users with respect
| | Context/sources | The context of this communication is the day-to-day executing of operational activities and the delivery and
support of services. Service Operation teams should not be communicating with customers or users on planning
issues, strategy, design or testing - unless they have been assigned to a project team which is dealing with one
of these areas
| |
![[To top of Page]](../../../images/up.gif){kind=small}
