HDI - Implementing Incident Management

Overview Implementation Operations Optimization Measurement Annexes

6.1 Overview

6.1.1 Description

An incident is any event that 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 a service. Incident Management processes restore normal service operation as quickly as possible and minimize any adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.

"The Support Center exists to professionally manage, coordinate and resolve incidents as quickly as possible and to ensure that no request is lost, forgotten or ignored."

6.1.2 Relationships to other processes

Processes that are directly affected by Incident Management include:

Incident Management may be affected by any other process. Overall, the affect of, and on, other processes will vary widely across organizations. Some considerations include the maturity level of the IT department, the complexity of the technology being provided and supported, and the level of adoption of formal processes.

Incident Management should interface very closely with Problem Management and Change Management processes, as well as the various functions of the Support Center. If they are not properly controlled within an organization, changes to systems may introduce new incidents, so mechanisms for tracking changes are required. Most ITIL experts recommend that incident records are recorded on the same Configuration Management Database as the problem, known error and change records (or at least linked somehow) to improve interfaces between the various processes. (ITIL IT Service Management Essentials Course Workbook: 91) Figure 6.1 shows some of the possible relationships with other processes.

Figure 6.1 - Incident Management interfaces with other processes

DescriptionSourceImportance
INPUTS
Incident details
  • Support Center
  • Network Group
  • Computer operations
  • Customers
High
Configuration details Configuration Management Database (CMDB)High
Response from incident matching against problems and Known ErrorsProblem and Known Error Databases (in CMDB and/or Knowledgebase)High
Resolution details
  • Incident Management
  • Problem Management
High
Response on Requests for Change (RFC; to effect resolution for incident(s).
  • Change Management
  • Problem Management
Medium
OUTPUTS
Resolved and closed incidentsIncident ManagementHigh
Communication to customers
  • Incident Management
  • Problem Management
  • Customer Service Management
High
RFC for incident resolution; updated incident record (including resolution and/or workarounds)
  • Change Management
  • Problem Management
  • Incident Management
Medium
Management Information (reports)
  • Change Management
  • Problem Management
  • Incident Management
Medium
Knowledgebase and/or CMDB
  • Configuration Management
  • Knowledge Management
High

6.1.4 Possible problems and issues

Potential problems associated with implementing incident management within an organization include the following.

Issue/ProblemPotential Resolution
Shortage of resources needed for implementation and subsequent maintenance Lack of commitment from senior management might also result in other issues/problems (i.e. difficult to obtain buy-in from stakeholders) Issues other than lack of commitment could result in shortage of resources (e.g. poor planning)?Constant communication with senior management as key stakeholders will keep them informed of progress while regaining their current commitment. Use of robust forecasting techniques from financial, project management and resource staffing perspectives will provide a good roadmap. Obtaining feedback from all the business units and extended team members about what will be needed to complete the work estimated in the next fiscal year will help provide the needed funding and resources to cover the work planned. These might include: additional employees, system capacity, tools, consulting services, process maintenance/maturity activities and auditing functions.
A lack of awareness or understanding among employees about what incident management is or how it applies to them.A successful awareness campaign crafted with all stakeholders in mind can help overcome this issue. To build awareness consider `branding' the effort through the use of targeted communication, themes, rewards and recognition programs.
Customer service levels are not defined or inadequately defined.These should be established through the introduction of Service Level Management within your organization. Evaluating the customer's current perception of service levels is a place to start so that improvement can be measured once the service level agreements are in place.
Lack of knowledge or inadequate training for Support Center staff to resolve incidents.Allocate funding and enlist the support of senior management to strengthen your staff training program. This alone will add credibility to the reputation of your Support Center as being knowledgeable and efficient in solving customer incidents, and increase levels of service. Provide the best training you can afford. For maximum impact and ROI, be sure to provide continuing education after Implementation training to reinforce the original training and to introduce changes.
Low customer confidence in the Support Center - perception that the Support Center is inadequate.Identify the issues that create a poor perception of the Support Center among its customers. For instance, were negative comments provided in a customer satisfaction survey? The key is to define the perception issues and create strategies to build customer confidence in the Support Center. (For examples of potential questions to ask in a Customer Satisfaction Survey, refer to the Customer Satisfaction chapter in this book and/or the Annex Support Center- Customer Satisfaction Survey). Develop a marketing campaign to promote what has been done to address customer complaints, and report to customers on how the Support Center is meeting SLAs, improving in specific areas, etc., to manage customer perceptions.
Poor integration with other processes, especially Service Level, Change and Problem Management Define your incident process first. Then implement an automated tool to support your incident process. Do not buy a tool first and then fit the process to the tool.
Resistance to change. Staff will resist changing the way they conduct their day-to-day work activities. Incorporate principles of organizational change (ensure everyone understands the end goal vision, gaining buy-in from staff, etc.) to help to minimize resistance. (Refer to Annex document titled Organizational Change References.)
The same problems are being resolved repeatedly rather than identifying and eliminating them from the infrastructure.A compliant Incident Management process will record the incident details and match them against known errors and problems, so the same ones will not resurface.
Workarounds are not shared with other support staff when they are identified. Workarounds should be entered into a knowledgebase or CMDB immediately and made available to all support staff instantaneously.
Not being kept up to date with changes and/or Releases being made in the business.. Once the Support Center is established as the single point of contact for customers, ensure that the business reports all planned changes/Releases in a timely manner. This enables the Center to be adequately prepared to respond to enquiries about those changes.
No management information available, so decisions are made on what the support representative thinks instead of what they know.Appropriate metrics must be identified, and then information about them captured. Metrics reporting will enable the Support Center to base its decisions about training needs on reliable data rather than educated guesses. If training gaps are identified through metrics reporting, Support Center management can provide direction for future training sessions for Support Center staff. This will enable them to make use of knowledge rather than guessing at troubleshooting techniques.
Lack of agreed customer service levels.Build relationships with all your customer bases and begin to put service levels in place that both parties agree to.
Poor software tools to support Incident ManagementListen to the feedback from tool users and begin to document new requirements for a tool that will better support the process in place. Build the case to build or buy a better tool when economically feasible.

Quality issues
Potential quality issues associated with Incident Management within organizations may include the following.

(For additional information, see Annex A61 Overview of the Capability Maturity Model and Annex A62 Questions to Guide Sustainable Change.)

Security issues
It is important to determine the security issues that might arise as a result of implementing Incident Management. These might include the following.

A decision not to implement Incident Management may result in:

[To top of Page]

6.2 - Implementation

Figure 6.1 - The Implementation Process

6.2.1 Support Center Manager's Role

Responsibilities and activities
An important part of the Support Center Manager's role is to define what Incident Management means to the Support Center. The Support Center Manager will also need to define how the Center's use of the process interfaces with other processes (Change Management, Problem Management, etc.), functions and/or departments. A good starting point in implementing service management is to ask the question: `What best practice elements are already established and in operation?'

The Support Center Manager should also take part in determining how Incident Management behavior can provide data relating to other processes. As the central point of contact for customers, the Manager must ensure that information detected and classified by the Support Center will be of value to other parts of the organization.

Deliverables The Support Center Manager should first conduct a current state assessment. The Manager should take into consideration what differentiates this Center from others. Implementing Incident Management is not a `one size fits all' proposition; the Manager should create a `differentiation document.' This will provide a clear understanding of the current state of the Support Center, to enable effective definition of the goal state and how to achieve it.

Consider the following questions when creating this document:

  • What is the norm in Support Centers? Use existing Support Center/Service Desk research to determine how your Support Center compares with other Centers.
  • What makes the Center unique? Consider the unique attributes of your Center.
  • Are all customers in the same region?
  • Does your Center support international customers?
  • Are there different regulations that must be followed for different customer bases?
  • How complex or diverse are the applications and systems that are being supported? The resulting `differentiation document' can then be used to drive processes related to Incident Management, including (but not limited to) hours of operation and staff needs.'

The Support Center Manager should compare the Center to maturity models. Examples include:

  • the Capability Maturity Model, which helps to apply process improvement techniques using lessons learned from previous projects
  • ITIL Best Practice framework information available in the public domain. (Refer to description in Quality Issues section)

A Gap Analysis document should be created that identifies the current state of the Support Center and any gaps that exist (between the Center and other Centers and also between current state and desired goal state). This document will drive such activities as the creation of work instructions, training materials, job aids etc.

The Support Center Manager will probably need to develop a budget for implementing Incident Management. Additional information can be found in the Measurement, Costing and Management Reporting section at the end of this chapter.

Competencies
The Support Center Manager who is rolling out Incident Management should be a strong leader. The manager will act as, or coordinate with the Project Manager for all the activities required for a successful implementation. Communication and financial skills will both be assets before, during and after implementation.

The Support Center Manager should have a good understanding of the organization where Incident Management will be implemented. The Manager should have good interpersonal skills (and the ability to influence others), Project Management abilities and a certain level of authority within the organization. The Support Center Manager will need to create a team of people with representatives from each area or department that is being implemented. This team should socialize and communicate the changes ahead, working to build trust and acceptance. Most problems and difficulties in implementation are a result of a resistant audience that will fight the process changes internally.`

A Support Center Manager who is supportive and encouraging in leading the Center and organization through changes, and is able to partner closely with other departments and areas as they are implemented, will achieve more through cooperation and integration than one who does not. Specific competencies include ITIL, metrics and measurement (Six Sigma), workflow and integration points with the other processes such as understanding the Root Cause Analysis (RCA) within Problem Management.

Key Performance Indicators
With the assistance of Support Center staff, the Manager should consider measuring the following types of critical success factors to ensure the planning and strategies of Incident Management were successful:

6.2.2 Support Center Function's role

Responsibilities and activities
With the direction of the Support Center Manager, the Support Center staff will implement the Incident Management process. Its primary role within the process will be to serve as the customer-facing, single point of contact for customers. It will provide guidance to customers and work toward restoration of service, monitor incident resolution and assist the Manager in providing reporting information.

Specific to Incident Management planning and implementation, the Center will provide input into:

Deliverables
Working together, the Support Center and Manager will develop a blueprint for how Incident Management will function within the Center. Because each Center is unique with a different ,et of needs, it is important that a significant amount of time goes into planning what is required for the organization's Incident Management rollout to be a success.

High-level deliverables to be created during implementation may include:

Competencies
As with the Support Center Manager, there is no specific set of experiences or backgrounds that must be in place to ensure a successful Incident Management process rollout to the Center. There are, however, several intangible qualities that should not be overlooked when identifying personnel to assist with Incident Management implementation planning. People who are willing to champion change, have positive 'can-do' attitudes and have a strong work ethic as team players will keep the momentum going.

In general, the Manager should consider the qualities needed in both first-line (and secondline as applicable) support staff, as well as any operations personnel who will help roll out Incident Management. Best practice suggests that all staff involved in supporting customers should be:

Operations experience (specifically call center / help desk experience) generally is associated with greater levels of empathy with customers' issues and results in more customer satisfaction within the Incident Management process. The abilities to adapt easily and quickly to change and to perform under pressure are necessities for both first-line support staff and operations leadership.

A search for staff with process design, development, implementation and application experience should also be considered. Technical skills are, of course, necessary for successful Incident Management. However, those technical skills must be paired with a general understanding of the systems and applications that support the business.

Key Performance Indicators
The Support Center Manager should create the vision for the Center environment when Incident Management processes have been implemented and integrated. The Support Center staff will assist the Manager in measuring the following types of critical success factors to help determine whether implementing planning and strategies used were successful:

Other key roles and functions in the implementation process In addition to the Support Center manager and analysts, some additional functional roles may be helpful in the Incident Management implementation process:

6.2.3 Planning for implementation

Consider using the following project management strategies and documents in putting together a toolkit for Incident Management implementation: Refer to the Annexes for sample documents (where applicable).

Steps to take
At a high level, the following project activities should be part of the Incident Management implementation:

Groups to contact

Before the planning stage, make every attempt to engage top management and gain their support for implementation efforts. During the planning phase, determine the key stakeholders for implementation. Every in-scope area that will be affected by the Incident Management implementation (as well as any external projects with touch points) should be included in all communication strategies.

Necessary resources and relationships
The first and foremost relationship for ensuring a successful implementation is gaining sponsorship within the organization. Without an active senior level sponsor, the initiative would go nowhere. Enroll all personnel responsible for the current Support Center function into the process of improving the strategies already in place. Then, identify a framework such as ITIL to provide guidance for the efforts.

Necessary information and data
Start the implementation planning process within the Support Center by base-lining current levels of activity. The Center can explore basic transaction volumes to determine the effectiveness of the current system. This will help to establish the cost associated with the effectiveness (or ineffectiveness) of processes within the current system. A review of such data can point to obvious improvements.

Improvement areas may include time to resolve, number of tickets that can be handled `first time final' versus escalated tickets, etc. Look at the lifecycle cost of the process, but recognize that costs may be high before process improvements are made. Costs will go up during implementation, but then reduce over time.

Measurements that should be put in place
The planning phase of Implementation should include determining what will be measured with each Incident Management activity. Examples include:

6.2.4 Implementing key process activities: hints and tips What to implement first

The Support Center Manager should determine the vision / mission for Incident Management within the organization. All additional activities should align with this vision / mission.

Things that always work

Little things that deliver big returns

Little things that always get forgotten

6.2.5 Key process activities

Process rollout to the Support Center

6.2.6 Methods and techniques

Overcoming resistance to change may be the single biggest factor in implementing Incident Management. In order to overcome this challenge, consider partnering with all in-scope stakeholders to gain their buy-in to the change as well as their input for creating processes that make sense for the organization.

Ensure that process training is clear and concise, all gaps between current and goal state have been closed appropriately and that people understand what they need to do under the new Incident Management processes and why.

6.2.7 Audits for effectiveness

A vide variety or combination of audit strategies may be used to indicate the effectiveness of implementation. These include: [To top of Page]

6.3 - Ongoing Operation

Figure 6.3 - The ongoing process

6.3.1 Support Center Manager's role

Responsibilities and activities Serving in the role of Incident Manager, the Support Center Manager is accountable for:

Competencies required
To help facilitate the ongoing efforts required with Incident Management, the Manager should:

Key Performance Indicators
Clearly defined objectives with measurable targets must be set to assess how well Incident Management processes are performing within the realm of the Support Center. The Support Center Manager should consider requesting that Center personnel use these Key Performance Indicator targets to monitor the effectiveness and efficiency of the Incident Management process:

Critical Success Factors (CSFs) and Key Performance Indicators (KPIs)
The Support Center Manager is accountable for determining how often reporting associated with these key performance indicators will be run, as well as who will receive the reports.

6.3.2 Support Center Function's role

Responsibilities and activities The Support Center owns the incident process and all associated incidents. Its role is to serve as the customer-facing point of contact for customers. The Center:

Support Center responsibilities include:

In many instances, second-line support is also included as part of the Support Center. This area's tasks and responsibilities include:

Deliverables
The Support Center owns, monitors, tracks and communicates information related to incidents. These tasks include:

Competencies required
For ongoing Incident Management efforts, the same skill sets are important to ensure all support staff delivers first-class service by being:

Support Center personnel should have core IT skills and a desire to interact with customers at all levels. Consideration should be given to hiring staff who already possess extroverted personality traits because the IT skills can generally be taught. '

Key Performance Indicators
The Support Center Manager has authority for defining Key Performance Indicators that are aligned with the business goals. As previously stated, the Support Center may want to consider using metrics on the following items to determine the effectiveness and efficiency of the Incident Management process:

With input from the Support Center Manager, also consider making this data available to users and customers, as applicable. Provide the data in a format that is user-friendly to your audience.

6.3.3 Other key roles and functions in the ongoing operation process

The Incident Group members liaise with application providers to create Operating Level Agreements and Service Level Agreements. They also manage the Support Center's knowledge base and management reporting. The group is instrumental in maintaining focus on the needs of their business customers instead of on their systems issues. '

A knowledge management specialist will help maintain all troubleshooting knowledge the Center uses in its day-to-day Incident Management operations. They can ensure that knowledge is easy to find, and also that its associated category makes sense, that it is adequate and accurate and that opportunities for improvement are identified.

Reporting specialists provide data specific to the Incident Management processes to allow for investigation into process improvement opportunities.

Steps and tips for maintaining this process
Evaluation of Incident Management processes is key to ensuring behavior continues to follow the new performance guidelines. Maintaining focus on the future state and measuring against that will enable the Center to stay on target. Specific examples of maintenance tips include:

[To top of Page]

6.4 - Optimization

Figure 6.4 - The optimizatrion process

6.4.1 - Support Center Manager's Role

Responsibilities and activities
The Support Center Manager's role is to monitor Service Level Agreements that have been set as part of Incident Management. This is accomplished through the enforcement of existing processes and through continuous improvement plans created as part of the Incident Management Implementation Plans.

The Manager participates in an ongoing review of critical performance indicators set by the Support Center for supporting the IT organization. The Manager should monitor the status of such Key Performance Indicators as call volume rates, `first time final' rates, incidents being incorrectly assigned etc. The Manager should have a high-level awareness of what is happening within the Center, but not necessarily the details related to the key performance indicators.

Additionally, the Manager should continually update other functional and process managers on the effectiveness of current Incident Management processes, and determine whether there is anything other process owners (Problem and Change Management, etc) need from the Center. The goal is to both provide and receive any information that could help the entire Incident Management process run more smoothly.

Deliverables
As part of monitoring the status of Key Performance Indicators, the Support Center Manager should work with Center staff to improve staff knowledge and overall effectiveness. Deliverables associated with these efforts may include:

Competencies required
Ability to work with the Incident Management practitioners to gather continuous process improvement suggestions and implement them., The person leading optimization efforts should have a clear understanding of the current state processes in place, together with an idea of what the future goal state is at various stages - six months, one year, three years etc. ' The Manager should have a clear understanding of how people, process and technology work together, to ensure that making a positive change to one of the three does not negatively affect one (or both) of the others.

Key Performance Indicators
The ultimate goal of optimization related to Incident Management is to make the Support Center more connected with the entire business/organization. The Center should strive to achieve more integration between Incident Management and other processes.

6.4.2 Support Center Function's role

Responsibilities and activities
The Support Center should continually review Incident Management processes and procedures to determine which are still valid and which are in need of updates. Additionally, incident analysis occurring through the review of Key Performance Indicator metrics reporting should drive the creation and delivery of new reference materials, training materials, job aids, process updates, etc.

The incident reporting and review process should produce reports that enable Support Center management to make informed decisions and monitor performance (based on Service Level Agreements).

Deliverables
The ability to provide good quality management reporting information demonstrates a level of maturity within the Support Center. Metrics around such items as trends and workloads can provide management with the information they need in order to justify budgets for additional resource needs such as additional staff, tools, etc.

Competencies required
Support Center staff must have a good understanding of the role they play at the Center in Incident Management processes. They must also understand what types of optimization the Center is interested in attaining. This information, along with a thorough understanding of the business's objectives, will allow personnel to provide feedback to management about the strategies that could help to attain the optimization goals.

Key Performance Indicators
The goal of optimization related to Incident Management is to help the Support Center become more connected with the entire business/organization. The Center should strive to achieve more integration between Incident Management and other processes. Critical success factors to be monitored might include:

6.4.3 Other key roles and functions in the optimization process

In addition to Support Center personnel, it is important to include as many Incident Management practitioners as possible in optimization efforts. Working as a group, this cross-functional team can bring their various viewpoints together to determine the best optimization opportunities within the organization.

Functions performed by this group may include determining the items to be addressed, producing requirements documents, prioritizing opportunities and testing solutions.

6.4.4 Tips for optimizing this process

6.4.5 Future impact of this process on the Support Center

Successful optimization strategies ultimately have the ability to improve more than Support Center productivity. Availability of applications, increased customer satisfaction etc can also be improved. Some specific impacts of optimization strategy may include:

[To top of Page]

6.5 Measurement, costing and management reporting

6.5.1 Implementation: benefits and costs

Ensuring that the Support Center activities are in line with the business needs of the organization makes good business sense in any organization. The Incident Management process should contribute positively to keeping customers up and running so they can perform their duties efficiently and effectively.

Why implement this process and what can be gained
Examination of the current environment and objectives to be achieved in the goal state, once Incident Management is in place, will help determine what types of benefits could be realized as a result of implementing Incident Management. With the Support Center becoming the single point of contact, benefits might include increased customer satisfaction and revenue enhancement.

Incident Management provides consistent metrics for use in problem analysis, providing greater capability for reducing or eliminating future incidents. It can also reduce the volume of incidents escalated to groups outside the Support Center. Ultimately, customers know they can expect to receive consistent levels of service, and they tend to have a higher satisfaction rate as more of their issues are being resolved quickly, or in many cases first time final.'

Cost elements for implementation
Costs associated with implementing Incident Management may include:

Making the business case to implement Incident Management
As a detailed investment proposal, the business case should provide analysis of all costs, benefits and risks associated with the proposed investment of implementing Incident Management. The investment decision is put into a strategic context. It positions the business objectives and options that will affect both the decision and the investment.

Consider following these steps to build the business case:

Metrics and Key Performance Indicators
Before rolling out Incident Management, consider placing the following types of measurable targets in place for the Support Center's involvement in Incident Management implementation:

Management reporting
After determining the metrics to be used for measuring the Center's success and the framework that will be put in place to help meet those targets, ensure that the reporting to be produced clearly demonstrates whether targets are being met.

6.5.2 Ongoing operations

Costs
In order to keep Incident Management efforts alive in the organization, the following cost factors will probably exist:

Metrics and Key Performance Indicators
To determine the effectiveness and efficiency of the Support Center's Incident Management processes, consider using some of the following measurable targets as key performance indicators:

The following excerpt lists several common problems symptomatic of an organization that does not produce regular, relevant and accurate management reports:

6.5.3 Optimization: benefits and costs

The ultimate goal of optimizing Incident Management processes is to better help the business reach its goals by streamlining processes. Byproducts of optimization often include higher levels of customer satisfaction and better motivated Support Center staff.

As Incident Management processes become more mature, it also allows organizations to focus on activities to interact with other processes such as Change Management and Problem Management.

Why optimize this process and what can be gained?
Optimization is synonymous with increasing efficiency and with reaching higher levels of performance maturity. More efficient and streamlined processes generally decrease costs.

Implementing processes to help the Support Center support its customers more effectively generally results in greater customer satisfaction.

Cost-effective process changes such as cross training tend to minimize boredom within the Center. When personnel believe they have the ability to make a difference, retention levels tend to be greater.

Making the business case to optimize
Using management reporting to help optimize Incident Management processes can help identify items that were missed in various stages of application development (before the time when the Support Center begins supporting a new application, release of an application etc). A rapid and sharp increase in calls is generally indicative of a larger issue. Is additional application testing necessary in the future? Are there opportunities to close gaps in the development organization? Should the customers have received additional communication about or training on application changes? The Support Center is in the unique position of helping the IT organization understand how to optimize its processes in the future to ensure that its customers are satisfied.

Metrics and Key Performance Indicators
Key Performance Indicators should be linked to business goals. Look periodically at the metrics being used in ongoing operations and determine whether they still make sense. Is there a need to revise the way some information is being looked at or reported on?

A team of specialists might be assembled to conduct an analysis of high volume call categories to contribute to a better understanding of root cause and recommend process improvements. 'Top 10' list of those categories has been created, and opportunities for reducing call volumes have begun to be identified.

Management reporting
Information used for management reporting must be accurate, reliable and communicated in a timely manner each reporting period. The types of information the Support Center should consider supplying in such reporting includes:

In very general terms, management information can be used to validate decisions, to direct the goals and targets of Support Center activities, to justify specific courses of action related to incident Management and to assist when intervention activities related to the Support Center are necessary (Refer to Annex for supporting documents titled Support Center Scorecard - Daily, Support Center Scorecard - Monthly, and Support Center - Customer Satisfaction Survey.)

The best way to present management information is to show charts with trending information and provide explanations where changes are above or before a threshold defined as acceptable for your organization. For instance, a goal of 95% may have an acceptable threshold of +/1%, meaning anything between 94% and 96% is attributable to normal fluctuations but anything lower or higher than needs to be investigated and a cause determined. Such information enables management to identify where changes may be necessary, e.g. processes, staffing, hours of operation, etc. Again, all key performance indicators should be included in this reporting. Look for direct and indirect correlations between indicators. For instance, is there any correlation between `Speed to Answer' and 'Abandon Rate?' Do customer satisfaction/perception scores rise when more calls are being resolved `first time final'?

Use management information to validate the IT decisions that did (or did not) make sense, to direct future goals and activities and to justify specific courses of action.

Incident Management Metrics
MetricDefinition
Ratio of Minor, Significant and Major Incidents Comparison of volumes by severity level.
Ratio of Incidents by Owning Group Comparison of volumes by group creating the incident ticket.
Ratio of Incidents by Responsible Group Comparison of volumes by group in possession of the ticket when the SLA becomes measurable.
Ratio of Incidents by Customer Type Comparison of volumes by 2-digit code derived by BCR type.
Ratio of Incidents by Disbursement Code Comparison of volumes by cost center.
Volume of Incident by Period Volumes for a specified period that tally Carried Over Open Items, Current Period Submitted Items, Current Period Closed Items, and End of Period Open Items.
Number of Incidents Reassigned Volume of incidents that were changed due to an incorrect identification of cause/severity.
Number of Incomplete Incident Tickets Number of items submitted that were incomplete.
Number of Incidents Related to Implementation of a Change Related to root cause identification and used to identify issues with Change Process.
Elapsed Time Between Phases in Incident Management Process Elapsed time (hours or days) between phases in the Incident Management Process at the Business Sponsor, CAB, and Priority levels as well as compared to the SLAs (if any).
Variances Between Elapsed Times Between Measuring Points Differences in time (hours or days) between phases in the Incident Management Process at the Business Sponsor, CAB, and Priority levels as well as compared to the SLAs (if any).

6.5.4 Tools Too( selection

ITIL methodology suggests that any tools chosen should follow ITIL processes. Consider using these suggestions when selecting an Incident Management tool:

Testing before implementation
Clearly define testing scenarios, but allow for the flexibility to test variations of each scenario (i.e. - normal paths vs. alternate paths to achieve the same outcome).

Give identical scenarios to multiple testers. The idea behind this technique is that a distinct possibility exists for the testing of scenarios using different strategies (and some of these different strategies may uncover flaws in the system or processes).

Test the new tool from multiple perspectives (first-line, second-line, third-line/specialty group, etc). Build testing scenarios based on the perspective of all possible types of users.

Brainstorm about ways users may misuse the tool (intentionally or unintentionally) and document the results. Consider whether misuse cases require system modifications to prevent their possibility or whether a clear and concise communication plan may avoid the scenario.

Implementation
The need for a clear and detailed Training/Communication plan cannot be overstated. Ample time should be provided between development and implementation phases to allow trainer(s) to prepare training materials with screenshots of how the system will look when implemented.

All users should be provided advance notice of the upcoming tool change, and enough time should be allowed to properly educate users. (Plan a communication approach that will reach users multiple times using varying communications techniques/strategies.)

Consider a phased rollout or pilot release approach instead of an 'all-at-once' or `big bang' implementation approach. (This is especially important if both the process and tool are being rolled out simultaneously.)

Use the pilot phase of the implementation to identify any bugs in the tool and/or process. Take steps to alleviate these issues before the main rollout.

Ongoing operations
After implementation (especially the first few weeks following implementation), many issues will be identified that require resolution. Additionally, users will begin requesting enhancements. It may be challenging to balance the needs of resolving tool issues and work on enhancement requests simultaneously. Establish a plan well in advance of this time to ensure that adequate resources (time, people, etc.) will be available to work on both efforts.

From the first phase of implementation throughout rollout to 100% capacity, ensure appropriate monitoring of hardware and software for efficiency, capacity and traffic management are in place.

Reporting
Reporting requirements should be considered with any other functional requirements at the beginning of the tool selection/analysis process. Reporting needs may direct processes and tool build vs. buy selection.

In the System Design phase, consider having a section devoted to Reporting. Make sure the design accommodates the reports that the Support Center (and other users / customers) will need and expect. [Note]

Finally, consider balancing the need for data against the effort to collect it. Assign each reporting need a level of importance, and think about how much development effort the organization is willing to spend to achieve the creation of the report.

Additional tools/resources that may be useful in supporting the Incident Management process within the Support Center include (but are not limited to):

[To top of Page]

Annex Documents

Overview

[To top of Page]

Annex A6.1 - Requirements Checklist

The Capability Maturity Model (CMM) was developed by the Software Engineering Institute (SEI), a federally-funded research and development center operated by Carnegie Mellon University. The definitive resource is The Capability Maturity Model: Guidelines for Improving the Software Process, (Carnegie Mellon University/Software Engineering Institute), published in 1995 by Addison-Wesley. The CMM serves two major purposes: to guide process improvement efforts in a software organization, and to assist with identifying contracting organizations that are qualified to perform software work.

The five maturity levels (Initial, Repeatable, Defined, Managed, and Optimizing) represent evolutionary plateaus on the road to a high level of software process capability. Each maturity level, except the first, defines several key process areas or KPAs - groups of related software practices - all of which must be satisfied in order for an organization to attain that level (Table 1).

Each KPA has two to four goals, all of which must be achieved in order to satisfy the objectives of that KPA. In addition, each KPA describes a number of key practices that typically lead to achieving that KPA's goals. These practices are grouped into five `common features'. The key practices of the common feature called Activities Performed define technical and managerial activities that typically lead to satisfying the KPA goals, thereby establishing a specific process capability in that key process area.

Maturity Level Definitions
  1. Initial None

  2. Repeatable

  3. Defined

  4. Managed

  5. Optimizing

The other four common features relate to institutionalization of the practices performed in a software organization. Institutionalization means that a practice is routinely applied across the organization, even in times of crisis. Application of that practice has been ingrained in the group's culture, and it is supported with an infrastructure of policies. Common features of institutionalizing are:
A6.1.1 SEI Capability Maturity Framework
The maturity framework provided by CMM establishes a context in which: Process Definition Criteria are the set of information that must be included in a software process description for it to be usable by the people performing the process. To establish the criteria you are asking the question: `What software process information do I need to document?'

Process ElementsAnswers
PurposeWhy is a process performed?
Inputwhat work products are used?
Output What work products are produced?
Role Who (or what) performs the activities?
ActivityWhat is done?
Entry criteria When (under what circumstances) can processes begin?
Exit criteria When (under what circumstances) can processes be considered complete?
Procedure How are activities implemented?

Other process elements are:

[To Annexes]

Annex A6.2 - Questions to Guide Sustainable Change

John Kotter, the Konosuke Matsushita Professor of Leadership at Harvard Business School, is a noted authority on leadership. He has written [Ref] After conducting fourteen formal studies and more than a thousand interviews, directly observing dozens of executives in action, and compiling innumerable surveys, I am completely convinced that most organizations today lack the leadership they need ... and the shortfall is often large. I'm not talking about a deficit of 10%, but of 200%, 400%, or more in positions up and down the hierarchy. Kotter's model of change management is excellent and we contend that it, like so many other useful approaches to change, leadership and organizational development, can be usefully enhanced with the introduction of more integral perspectives.

The following table conveys our understanding of Kotter's [Ref] change model in columns 1 and 2. We have aligned Kotter's eight stages of change with potential leadership questions to guide action based on integral theory as defined by Ken Wilber. We present four categories of questions for each stage of change designed to capture the thoughts and actions necessary to implement sustainable change.

Individual thoughts and actions are captured in Column 3 (What do I intend?) and Column 5 (What do I do?)

The implementation is tailored to the specific culture when answering the questions in Column 4 (How do we talk about this?) The organization systems, processes, and infrastructure are incorporated into the implementation why answering the questions in Column 6 (How do we do this?)

When implementing a sustainable change, it is critical to consider the individuals leading the change, the culture in which the change takes place and the systems, processes, and infrastructure that either reinforce the status quo or support the change. For change efforts to deliver the expected value in a sustainable manner, the entire organizational system must be taken into account and the change management effort must address not only the system (as is common) but also the individual and the culture.

Change agents and coaches working with the individuals and teams charged with creating and implementing these changes will make the best use of time, money, energy and thought by using these questions as a way to guide their efforts. We do not prescribe specific actions. The questions will guide the user to create their own approach tailored to the specific change effort, the people involved and the organization.

What WorksWhat I IntendHow we talkActionHow it is done
Create a Sense of Urgency
Showing others the need for change with a compelling object they can actually see, touch and feel Showing people valid and dramatic evidence from outside the organization that demonstrates that change is required Looking constantly for cheap and easy ways to reduce complacency Never underestimating how much complacency, fear and anger exists, even in good organizations. Reflect on the urgency of the change. What does it mean for you personally? What will you need to change about yourself (your approach) to lead the change effort successfully? Will you lead the same way this time or will you change from what you have done in the past? what is perceived he the employees as urgent? Do different groups of employees perceive different things as urgent: How will this change affect the individuals in the organization? How will you create a sense of urgency for different segments of the organization (by department) based on their priorities, goals, and pains? How will I model appropriate response to the sense of urgency by my actions? What segments of the population that will change most rapidly? How will I encourage the segment that is most likely to change without ignoring others? How will I explain the impact of change in a manner consistent with culture? What stories can I use that are linked to corporate folklore to illustrate prior examples of urgency and positive outcome? How can I convey messages that use emotion (personal stories) and external sources to demonstrate urgency' What are the influences and constraints that will affect success (legal, financial, building, staffing mix? What resources are required to succeed and how will we secure them? What measures should we track to understand employee sense of urgency? Based on the measures, once we have achieved the correct level or urgency, move to step 2, Build a guiding team
Build a Guiding Team - first "who" then "what"
Showing enthusiasm and commitment for helping someone do so) to help draw the right people into the group Modeling the trust and teamwork needed in the group (or helping someone to do that)] Structuring meeting formats for the guiding team so as to minimize frustration and increase trust Putting energy into raising urgency if you cannot take on the step 2 challenge and if the right people will not. Do I believe this change is possible? Do I realize that people are affected by my belief in the success of this change? What are the social and cultural norms that dictate who should be leading the project: Do they still fit for where we are going? How do I communication the criteria for 'right' people on the team? ('Right' includes character traits, innate capabilities, and skills and knowledge) Who are the best people and how do I place them in charge of the biggest opportunity (not the biggest problem)? What comments and actions will I take that demonstrated my belief that change is possible? Am I looking for opportunities to support the project as events unfold? What trust building activities can we conduct to improve the team dynamics? How do I lead the team based on the task at hand? I may run the risk of appearing aloof and detached from the rest of the organization because I am so focused on the change project. What measures should we track to reinforce desired team behaviors?
Get the Vision right
Visualize, literally, possible futures with such clarity that they can be articulated in one minute or written on one page. Legacy statements with potential emotional engagement, such as a commitment to serving people Sufficiently bold strategies focused on making bold visions real Watching for objective and subjective cues as to the tolerance for and speed of chang How do I see our organization within the larger environment: (Ranging from the company to the global environment)? What are the connections between possible business futures and my personal mission, passion, and economic goals (hedgehog principle' How do I see our organization within the larger environment: (Ranging from the company to the global environment)? What are the connections between possible business futures and my personal mission, passion, and economic goals (hedgehog principle' What organizational vision and strategies will move my part of the business into a position of long-term success? What are the visions and strategies within my part of the organization (departments)? How do I translate the vision into long and short term timelines? How do I incorporate specific tangible goals into the timelines? What do I fund based on the timelines and when? How do we cascade the shared vision of possible futures (realistic and wild card options) to all levels of the organization% How do we aggregate organizational goals that align with the overall vision? What measures help the organization measure progress toward goals?
Communicate for Buy-in
Keep communication simple and genuine, sufficiently but not unnecessarily complex for the task and audience at hand. Doing your homework before communicating, especially to understand what people are feeling, sensing and saying. Being aware of and, if necessary, speaking to anxieties, confusion, anger, and distrust Ridding communication channels of junk so that important messages can go through Using new technologies to help people see the vision (intranets, satellites, etc.) Bringing forward approaches that work. \X' hat personal stories (actions and emotions) will convey my struggles in heartfelt manner and empower others to act? What do I communicate when the situation and priorities change What is the appropriate language and message content based on the values, goals, language and culture of each audience segment (department)? What objective and subjective feedback are we receiving from these segments? How do I show my conviction through m; actions ('walk the talk' How do I deliver messages tailored to different segments of the organization that motivate everyone to accomplish the vision? How do I convey messages that will make a strong statement using both the languages of feelings and of logic to appeal to multiple groups? How do I demonstrate humility and give credit to others? How do I communicate the vision in a manner that is hard hitting ant realistic and still conveys our confidence that it is achievable? How do I communicate progress, challenges an my support? How do I communicate the facts and hope for the future? What arc the different audience segments based on function, profile, and other factors (union membership etc)? What stories will convey messages effectively? Do we have any applicable stories connected with company folklore? Of our current communication methods and vehicles, what will most effectively convey the messages? Can we combine and/or eliminate any current communications? Would communication be more effective if multiple projects were communicated in a joint vehicle to help the audience understand the linkages and impacts? How do we communicate measures and rewards for successfully accomplishing the vision (ensure clear linkage between vision and rewards)?
Empower for Action
Finding individuals with change experience who can bolster people's self-confidence with we-won-you-can-too anecdotes. Recognition and reward systems that inspire, promote optimism, and build self-confidence. Providing feedback that can help people make better vision-related decisions. Clarity on the nature of change required. What is my individual role and value within s the organization? How can I effectively grow and empower others and support their success and the success of the organization? How can I benefit from the success of the project? Do I need to change my perspective or skills to succeed? What is the appropriate reward system based on the organizations values, goals, and culture? What are the stories of prior organizational success? How can we connect prior successes to the current change effort? Why did we have failures in the past? How do we minimize previous barriers to success? Are we building a culture that supports the behavioral traits necessary to support ongoing change such as freedom and empowerment, where employees are free to act within limits to meet their goals? Is this first order change or adaptive change? How kill I deliver clear, concise feedback that will empower others to correct, redirect or recalibrate their behavior and feel motivated to make the necessary changes? How am I funding projects and acting to increase organizational awareness and commitment? What creative solutions can I find to increase organizational awareness? How am I following through on the preestablished consequences for behaviors that undermine our success? How can I respond to undermining conflicts as learning opportunities? How do I encourage bad news as well as good? How am I assigning work to ensure the change is accomplished? How will the organization build a reward system aligned with the new environment and that meets multiple motivations (among people or department Have we set goals and expectations (measures and behaviors) for each individual that supports the overall organization and the change effort? Have we created evaluation and feedback processes that support new behaviors? Have we created, communicated and used processes to identify those not exhibiting or supporting the new strategies and behaviors? Why is this happening? What are we doing to measure, communicate and fund `learning organization' processes and activities without sacrificing financial security?
Create Short term wins
Wins that are visible to as many people as possible Wins that penetrate defenses by being unambiguous Wins that are meaningful to others - the more deeply meaningful the better Early wins that speak to powerful players whose support you need and do not yet have Wins that can be achieved cheaply and easily, even if they seem small compared with the grand vision. What do I consider personal wins? What do I consider wins for my team? What do I consider wins for the organization? Why do we need short term wins? How do we incorporate short term wins into the project without affecting long term project success, schedule or cost? What wins will be provide meaningful business results? What wins will provide emotionally meaningful results? What stories can we tell about the wins that will be shared with the organization in public settings such as town hall meetings? Who are the leaders within the sub-cultures who can best communicate wins? What wins can I identity and support that solve "problems" for others or that are seeds for future shifts? How do I publicly recognize people who accomplish the wins? How does this communication reinforce my own values among the group? Who do we need to support the change effort for it to be successful? How can our project help these key people meet their personal objectives? How will we identify short term wins in the context of the larger project objectives? How will we connect wins to vision and measures to demonstrate the impact of small steps forward? How will we measure (objectively and subjectively) and communicate the merit of wins in relation to overall goals? How will we support systematically achieving shifts from key people and the overall organization?
Build Momentum
Aggressively rid yourself of work that is no longer yours to do - tasks that may have been relevant in the past but not now, tasks that can be delegated to those who should be doing the work. Looking constantly for ways to keep sense of urgency heightened without over stimulating. Using new situations opportunistically to launch the next wave of change Show them - show them - show them How do I deal with both profound progress and a need for continued change? How do I deal with unresolved issues and uncertainty as we move forward? How is morale maintained by different departments (subcultures)? How do specific departments want to be recognized beyond public recognition? What do I communicate that conveys both progress and continued urgency Am I `walking the talk'? Am I living up to the standards I have set for others? Am I perceived as acting with integrity with regard to meeting my commitments? What processes will we establish to identify work that is no longer appropriate or necessary in the changing environment? What processes will we create and staff to scan the environment of opportunities that can be leveraged to create additional momentum? Are we reviewing measures regularly and recognizing results toward the change goals?
Make Change Stick
Continued attention until the changes have taken root Using new employee orientation to compellingly show recruiters what the organization really cares about. Using the promotions process to place people who act according to the new norms into influential and visible positions Telling vivid stories over and over about the organization, what it does and why it succeeds Making sure you have the continuity of behavior and results that help a new culture grow. What progress have I made as a leader/ person? Are my assumptions still valid? Am I still in the right role for my personal values and mission? When I think of my mental, emotional, moral and physical state, am I still the right person for the job ahead? How will organization goals and values change based on the change effort? How do we shift our focus in support of long change effort without losing value of recent gains? How do we incorporate new language, best practice and human interest into emerging organizational stories? How do we reward the small accomplishments toward the overall organizational success? What do I do that reinforces the value of the change? How do I continue to send my emotional engagement, the logical case and the senior management support for the new way of doing business? How do I emphasize the focus on systematic change that encourages but does not insist on personal growth? How does the organization fund, staff and supply sufficient and appropriate infrastructure to support and reinforce new behaviors and culture? (These including promotions, orientation, rewards and recognition that meet people's natural way of doing business) Have we sufficiently updated employee orientations and other human resources and IT systems to support changes in goals and values? Have we reviewed objective and subjective measures regularly and recognized results toward the change goals? Are we reinforcing actions that positively influence the larger vision and inquiring into those that do not?

[To Annexes]

Annex A6.3 - Agenda for Implementation

Start-off for Organization
Date: Thursday, June 13, 200X Time: 2:00 PM - 3:30 PM Location: Address Invitees: Others: Facilitator: Name

Goal:

Notes:

[To Annexes]

Annex A6.4 - Project Teams List

Functional area 1:

Functional Area 2:

Functional Area 3:

Functional Area 4:

Functional Area 5:

[To Annexes]

Annex A6.5 - Deliverables Contract

Project name:
IT Project Manager/Lead:Business Project Manager/Lead:
IT Sponsor
Acceptance Signature:
Business Spnsor
Acceptance Signature
Milestone/
Deliverable
Owner
(IT or Business)
Date
Planned
Date
Completed
Acceptance Form
Required?
(Y or N)
     
     
     
     
     
     
     
     
     
     
     
     
     
     

[To Annexes]

Annex A6.6 - Project Charter Worksheet

Project Charter

Tangible Benefits
DescriptionDollar Amount:Liklehood
(High, Medium, Low)
1.   
2.   
3.   

Intangible Benefits
DescriptionLiklehood
(High, Medium, Low)
1.  
2.  
3.  

Major Assumptions & Constraints
DescriptionAssumption or ConstraintImportance
(High, Medium, Low)
1.   
2.   
3.   

Risks
RiskLiklehood
(High, Medium, Low)
Impact
(High, Medium, Low)
1.   
2.   
3.   

Dependencies
ProjectLiklehood
(High, Medium, Low)
Description of Impact
1.   
2.   
3.   

Project Structure and Key Roles
Project Structure and Key Roles

Project Charter Acceptance
DateRoleSignatureDate Signed
    
    
    
    
    
    
    
    
    
    

Project Charter Revision Log
DateDescriptionChange IDAuthorApproved By:
     
     
     
     
     
     
     
     
     
     

[To Annexes]

Annex A6.7 - Project Scope Worksheet

Project Scope

[To Annexes]

Annex A6.8 - ITIL/Support center Incident Management Implementation Workplan

IM.5Line of Business Implementation PlanStart
Date
Due
Date
IM.5.1Scope   
IM.5.1.1Identify IPOCs   
IM.5.1.2 Identify specialty groups   
IM.5.1.2.1 Identify Change Mgmt Specialty Groups   
IM.5.1.2.2 Identify Incident Mgmt Specialty Groups   
IM.5.1.3 Identify other affected areas   
IM.5.1.3.1 Identify other areas affected by Chg process   
IM.5.1.4 Identify training needs   
IM.5.2 Roles   
IM.5.2.1 Identify existing roles   
IM.5.2.1.1 Identify existing Chg Mgmt roles   
IM.5.2.1.2 Identify existing Incident Mgmt roles   
IM.5.2.2 Update roles and responsibilities   
IM.5.2.2.1 Update Chg Mgmt roles & responsibilities   
IM.5.2.2.2 Update Incident roles & responsibilities   
IM.5.2.3 Identify Who will fill Chg Mgmt roles   
IM.5.2.3.1 Identify Local Change Coordinators   
IM.5.2.3.2 Identify CAB Members   
IM.5.2.4 Identify project team roles   
IM.5.2.4.1 Identify Implementation sub-team   
IM.5.2.4.2 Identify Working Team reps   
IM.5.2.4.3 Identify process go-to people   
IM.5.3 Awareness   
IM.5.3.1 Develop awareness materials   
IM.5.3.2 Conduct awareness sessions   
IM.5.4 Gap   
IM.5.4.1 Capture existing process information   
IM.5.4.1.1 Capture existing Change Process info   
IM.5.4.1.2 Capture existing Support Center Incident Process info   
IM.5.4.1.3 Capture existing eComm Incident process info   
IM.5.4.2 Capture existing policy information   
IM.5.4.2.1 Capture existing Change Policy info   
IM.5.4.2.2 Capture existing Support Center Incident Policy info   
IM.5.4.2.3 Capture existing eComm Incident Policy info   
IM.5.4.3 Capture existing work instructions   
IM.5.4.3.1 Capture existing Chg Mgmt work instructions   
IM.5.4.3.2 Capture existing Support Center Incident Mgmt work instructions   
IM.5.4.3.3 Capture existing eComm Incident Mgmt work instructions   
IM.5.4.4 Validate against core process   
IM.5.4.4.1 Validate against core Change Process   
IM.5.4.4.2 Validate against core Incident Process   
IM.5.4.5 Document additional requirements   
IM.5.4.5.1 Document additional requirements   
IM.5.4.5.2 Document upcoming Major Changes   
IM.5.4.5.3 Document types of Standard Changes   
IM.5.5 Documentation   
IM.5.5.1Identify documentation requirements   
IM.5.5.2 Develop LOB/application handbook   
IM.5.5.2.1 Develop LOB Incident Handbook   
IM.5.5.2.2 Develop LOB Change Handbook   
IM.5.6 Policies   
IM.5.6.1 Identify missing policies   
IM.5.6.1.1 Identify missing Change Policies   
IM.5.6.1.2 Identify missing Incident Policies   
IM.5.6.2 Submit additional policies for approval   
IM.5.7 Work Instructions   
IM.5.7.1 Capture Work Instructions   
IM.5.7.1.1 Complete Chg Mgmt work instructions   
IM.5.7.1.2 Complete Support Center Incident Mgmt work   
IM.5.7.1.3 Complete eComm Incident Mgmt work instructions   
IM.5.8 Use Case Walkthroughs   
IM.5.8.1 Validate design via Use Case walkthroughs   
IM.5.8.1.1 Validate Change Mgmt design   
IM.5.8.1.2 Validate Incident Mgmt design   
IM.5.8.2 Identify Use Cases   
IM.5.8.2.1 Identify Change Mgmt Use Cases   
IM.5.8.2.2 Identify Incident Mgmt use cases   
IM.5.9 Training   
IM.5.9.1 Identify Training Audience (Process, Tool, or Both)   
IM.5.9.1.1 Identify Who needs Chg Mgmt process training   
IM.5-9-1.2 Identify who needs Incident Mgmt process trng   
IM.5.9.1.3 Identify who needs TCM training   
IM.5.9.1.4 Identify who needs TPM training   
IM.5.9.1.5 Identify who needs Chg Manager detailed trng   
IM.5.9.1.6 Identify who needs ITIL Essentials trng   
IM.5.9.1.7 Identify who needs ITIL overview trng   
IM.5.9.2 Schedule Training   
IM.5.9.2.1 Schedule Chg Mgmt process training   
IM.5.9.2.2 Schedule Incident Mgmt process trng   
IM.5.9.2.3 Schedule Change Tool training   
IM.5.9.2.4 Schedule Incident Tool training   
IM.5.9.2.5 Schedule Chng Manager detailed training   
IM.5.9.2.6 Schedule ITIL Essentials training   
IM.5.9.2.7 Schedule ITIL overview training   
IM.5.9.3 Reserve & Prepare Training facilities   
IM.5.9.3.1 Reserve facilities for Chg Mgmt process trng   
IM.5.9.3.2 Prep room & materials for Chg Mgmt process trng   
IM.5.9.3.3 Reserve facilities for Incident Mgmt process trng   
IM.5.9.3.4 Prep room & materials for Incident Mgmt process trnl   
IM.5.9.3.5 Reserve facilities for Change Tool training   
IM.5.9.3.6 Prep room & materials for Change Tool training   
IM.5.9.3.7 Reserve facilities for Incident Tool training   
IM.5.9.3.8 Prep room & materials for Incident Tool trng   
IM.5.3.9.9 Reserve facilities for Chg Manager detailed trng   
IM.5.9.3.10 Prep room & materials for Chg Manager detailed trng   
IM.5.9.3.11 Reserve facilities for ITIL Essentials training   
IM.5.9.3.12 Prep room & materials for ITIL Essentials trng   
IM.5.9.3.13 Reserve facilities for ITIL overview training. Prep room & materials for ITIL overview training   
IM.5.9.4 Conduct Process Training   
IM.5.9.4.1 Conduct Change Mgmt process training   
IM.5.9.4.2 Conduct Incident Mgmt process training   
IM.5.9.4.3 Conduct Change Manager detailed training   
IM.5.9.4.4 Conduct ITIL Essentials training   
IM.5.9.4.5 Conduct ITIL overview training   
IM.5.9.5 Conduct Tool Training   
IM.5.9.5.1 Conduct Change Tool training   
IM.5.9.6 Training Completed   
IM.5.9.7 Train Implementation sub-team   
IM.5.10 Implementation   
IM.5.10.1 Roll out process to targeted areas   
IM.5.10.2 Provide Coaching and Mentoring   
IM.5.10.3 Rollout Completed   
IM.5.11 Evaluation   
IM.5.11.1 Review of Implementation   
IM.5.11.1.1 Review Change Mgmt implementation   
IM.5.11.1.2 Review Incident Mgmt implementation   
IM.5.11 2 Revise Core Process   
IM.5.11.2.1 Revise Change Mgmt Process   
IM.5.11.2.2 Revise Incident Mgmt Process   
IM.5.11.3 Revise Training   
IM.5.11.3.1 Revise Change Mgmt process training   
IM.5.11.3.2 Revise Incident Mgmt process training   
IM.5.11.3.3 Revise Change Tool training   
IM.5.11 3.4 Revise Incident Tool training   
IM.5.11.3.5 Revise Change Manager detailed trng   
IM.5.11.3.6 Revise ITIL overview training   
IM.5.11.4 Recommend Policy Changes   
IM.5.11.4.1 Recommend Change Mgmt policy changes   
IM.5.11.4.2 Recommend Incident Mgmt policy changes   
IM.5.11.5 Build Audit Process   
IM 5.11.6 Evaluate Rollout   
IM.5.11.7 Modify Process Based on Evaluation   

[To Annexes]

Annex A6.9 - Steps to develop a Communications Plan

Steps to create a specific Communication item:

Content

Project

[To Annexes]

Annex A6.10 - Communications Plan

Communication Plan template

Stakeholder
Project Involvement/Interes
Influence over Others
Direct Control of Resources

[To Annexes]

Annex A6.11 - Implementation Scope Questionnaire

When filling out this questionnaire, please be sure to include information for all areas that you are representing for your department. Questions that ask about your "area' refer to all teams you are representing in this assignment, not just to your immediate team.
A6.11.1 General Information

Toll Speciality Group name Support level
  
  

For Change Management, please list all Tool specialty groups (if different than above) that belong to your area.

Toll Speciality Group name
 
 

List below all other areas that are (or can be) directly affected by incidents/problems from your area.

List below all other areas that are (or can be) directly affected by changes initiated and/or implemented by your area.

List below all people in your affected areas and what type of training they For the Role column, use the following categories:

NameManagerRole S.A.I.L,M.O
   
   
   
   
   
   
   
   
   
   
   
   
   

A6.11.2 Process Documentation Questionnaire
When answering these questions, please consider documentation to include paper hardcopy documents, electronic softcopy documents and files, web pages containing this information, diagrams, handbooks/user guides etc. Also, if a document does not exist but the information is `known' by the individuals or teams doing that work, please list the names of those individuals who know that information.

 
General Documentation questions:
  • What methods of awareness building are you using to communicate these changes to your teams and increase the acceptance of the new processes?

Change Management documentation
  • Do you currently have a Change Management or Change Control Process?
  • If so, please list below the locations of the documentation for this process or attach copies of the documents.
  • If the process is not formally documented, please identify a list of individuals who know the process and can explain it to the implementation team.
  • Are there any types of changes that currently do not follow this process because they are too frequent, low risk, or other reason? If so, please list those types of changes here.
  • Do YOU currently have any policies regarding Change Management or Change Control that Your areas use?
  • Please attach the policy documents or locations, or list individuals that can describe these policies if they are not documented.
  • Do you have any type of Change Management work-instructions that are used in your area or by users of your areas' services? These could be located in such places as Team guidelines, checklists, handbooks, websites, etc.
  • In the new process, changes that occur frequently in high volume and have a high success rate can be considered Standard Changes. Please list below all types of changes that your areas might perform that you believe could be candidates for being declared Standard.
  • Do you have any upcoming changes planned or types of changes that could be coming soon -that would be considered `Major' changes? If so, list them below. These would be:
    • changes that would have new technologies
    • changes that are part of an executive strategic project
    • changes that would cost over $XXX
    • or changes that could have major impacts to the business

To help validate that the Change Management process will work efficiently for your areas, please list below 5-10 types of changes that we can walk through the process. These should include several types of changes in each of the following categories:

A6.11.3 Incident Management Documentation
Do you currently have an incident Management, Problem Management, or other support Process?

If so, please list below the locations of the documentation for this process or attach copies of the documents.

If the process is not formally documented, please identify a list of individuals who know the process and can explain it to the implementation team.

Are there any types of incidents or problems that currently do not follow this process because they are too frequent, there is no help desk support, or other reason? If so, please list those types of incidents/problems here.

Do you currently have any policies on Incident Management or Problem Management that your areas use?

Please attach the policy documents or locations, or list individuals that can describe these policies if they are not documented.

Do you have any type of Incident or Problem Management work-instructions that are used in 'our area or by users of your areas' services? These could be located in such places as team guidelines, checklists, handbooks, websites, etc.

To help validate that the Incident Management process will work efficiently for your areas, please list below 5-10 types of incident or problems that we can walk through the process. These should include several types of incidents in each of the following categories:

A6.11.4 Roles and responsibilities
When filling out this questionnaire, please be sure to include information for all areas that you are representing on the Working Team. Questions that ask about your "area" refer to all areas you are representing in this assignment, not just to your immediate team. Who will be your go-to person(s) for Change Management questions and coaching?

Who will be your go-to person(s) for Incident Management questions and coaching?

List anyone in your area currently performing any Change Management roles or functions.

NameCurrent role/function
  
  

List anyone in your area currently performing any Incident Management role or functions.

NameCurrent role/function
  
  

Who in your area will act as the Local Change Coordinators for changes in your area?

NameType of Changes they will coordinate
  
  

Identify who in your area will participate on Change Advisory Boards (CABs).

NameRole
  
  

[To Annexes]

Annex A6.12 - SWOT Analysis

Strengths
What are we good at?
How do we help the business achieve its goals?
Weaknesses
What do we do poorly?
Where are the gaps? (People, Process,Technology)
Opportunities
Identify new service opportunities.
What is happening within the industry
Threats
What is happening within the business?
How will technology changes affect us?

[To Annexes]

Annex A6.13 - Proposed Metrics and Priority Codes

MetricBenefitUserTool
Service Centre
Workload Analysis
Amount of time required to resolve each incident
Staff Optimization Incident Manager Capable
Escalation by Group
Volume of incidents having to be referred to specialty groups for resolution
Identifies potential problem areas where additional training or knowledge transference may be needed. Incident Manager
Specialty Group
Capable
Service Breaches
Volume of incidents not resolved within SLA causing service escalations
Identifies service failures for review regarding cause of breach and future prevention Incident Manager
Users
Capable
Outstanding incidents
Incidents unresolved
Reports on incidents that are still open so that they can be reviewed and evaluated and to ensure that none fall through the cracks Incident Manager Capable
Service Availability
Reports time that system was available for use
Performance indicator and touchpoint to Availability Management Incident Manager
Users
Availability Management
Requires Research
Incident Areas Volumes
Reports volumes by incident type to highlight problem areas
Performance indicator focused on volume by incident type Incident Manager
Users
Capable
Incident Areas by Work Time Requirement
s Ranks incident types by work time to resolve
Performance indicator with attention to time spend on incidents by type. Incident Manager
Users
Requires Research
Incident Areas by Turn-Around Time to Customer
Ranks incident types by time from outage of service to when service restored
Performance indicator with attention on time of service outage for the customer by incident type Incident Manager
Users
Requires Research
Trending Analysis
Utilization of current and past occurences to determine future probabilities
Forecasting tool to help identify potential problem areas and for training or staffing requirements. Incident Manager
Process Owner
Incapable
Multiple Incidents Escalated to Problem Management
Reports those incidents that are escalated to Problem Management for resolution
Performance indicator end touchpoint to Problem Manager Incident Manager
Problem Manager
Capable
Ratio of Incidents by Customer type
Comparison of volumes by 2-digit code derived by BCR type
Identifies large and small volume by customer. Incident Manager
Users
Requires Research
Ratio of Incidents by Type

(eg. call, email, walk-up, system generated) Compares volumes by entry method for evaluation
Comparison of reporting mediums for over/under utilization. Incident Manager Capable
Ratio of Incidents Handled First-Time Final by Category
. Compares First-Time Final volumes by total incidents to assess efficiency. Goal is to see FTF percentages to increase over time. On the Peregine tool. this includes items categorized as Calls and Incidents. Calls are classified as First-Time Final items.
Measures effectiveness of first time final and can be used for trending. Incident Manager
Speciality Groups
Process Owner
Capable
Ratio of Incidents by Disbursement Code
Comparison of volumes by user who reported the incident. This reeds to be further assessed as there are questions concerning low used and reported,
Identifies large and small volume by disbursement code. Incident Manager
Users
Capable
Ratio of Incidents Handled within SLA
. This would involve the capability of measuring overall, by group and by priority
Looks at no. effective we are in meeting SLAs. Incident Manager
Users
Capable
Cost of Service Provision/Failure
Business costs associated with incident types
Assigns a cost to incident types in order to assess priorities and value of service provided. Incident Manager
Users
Incapable
Incident - Note: most metrics for Incident are captured under Service Desk
Elapsed Time of Resolution by Impact Code
re Measures the length of time to resolve incidents by severity to assess performance
Performance Indicator Incident Manager
Users
Process Owner
Capable
First Time Finals
Indicates the number of incidents that are resolved at time of initial contact
First Time Final measurements should be used as a timeline indicator similar to a 2 year stock history. FTF should demonstrate highs and lows with a reference point indicating why the lows. A healthy process should trend upwards. Incident Manager
Process Owner
Speciality Groups
Capable
Ratio of Incidents by Priority
Comparison of volumes by according to the assigned level of importance.
Notes trends regarding priority. Incident Manager
Process Owner
Speciality Groups
Capable
Ratio of Incidents by Owning Group
Comparison of volumes by group creating the incident ticket,
Identifies large and small volume initiators. Incident Manager
Process Owner
Speciality Groups
Capable
Ratio of Incidents by Responsible Group
Comparison of volumes by group in possession of the ticket when the SLA becomes measurable,
Used for capacity analysis of resources. Incident Manager
Process Owner
Speciality Groups
Capable
Number of Incidents Related to Implementation of a Change
Related to mot cause identification and used to identify Issues with Change Process.
Used in root cause analysis and for correlation analysis to measure effectiveness of Change Management. Incident Manager
Process Owner
Speciality Groups
Change Manager
Incapable
Number of indents not documented in Incident Database
. Need to determine a way to m incidents that were not document in Incident Management database but still worked.
Tracks items not documented in IM database. therefore, outside the Incident Management Process. Incident Manager
Users
Process Owner
Incapable
Elapsed Time of Phase Duration in Incident Management Process
. Elapsed time (minutes) of phases in the Incident Management Process at the Initiators, Owning/Responsible Groups, and Priority levels as well as compared to the SLAs (it any).
Establishes values for component evaluations for effectiveness measurement. Incident Manager
Process Owner
Requires Research
Variances Between Elapsed Times Between Measuring Points
Differences in time (hours or days) between phases in the Incident Management Process at the Initiators, Owning/Responsible Groups, and Priority levels as well as compared to the SLAs (if any).
Used to determine whether the variances in the duration at the components are within tolerances or if action might be needed to identify why out of tolerance. Incident Manager
Process Owner
Incapable
Ratio of Service Requests vs. other Tools
Used to determine impact on current probties and understand volume of service requests.
Comparison allows for the acknowledgement of other tools and tine degree that Peregrine meets the needs of the process or when it ho longer accommodates those needs. Incident Manager
Process Owner
Incapable
Ratio of Service Requests vs. Incidents
Compares volumes between SRS and Incidents to evaluate knowledge transfers vs. actual issues.
Evaluates effectiveness of knowledge transfer and classification of incoming calls. Incident Manager
Process Owner
Requires Research - request tracking
Volume/Percentages of Incidents Resolved Remotely
Incidents resolved without having to visit the physical location
Performance Indicator Incident Manager Capable
Volume/Percentages of Incidents Resolved Remotely
Incidents resolved without visit to the physical location
Performance Indicator Incident Manager Capable
Problem
Trends on Post-Change Occurrence of Particular Problem Type
s Validates that the Change implemented to resolve a Problem actually works
Evaluates success of Change. Touchpoint to Change Management. Problem Manager
Change Manager
Process Owner
Incapable
Number and Impact of RFCs on availability and reliability of service
Volume and impact description by Problem type
Grouping problems by type, this is an indicator to demonstrate areas of focus. Touchpoint to Availability Management Problem Management Team
Process Owner
Availability Manager
Capable
Amount of time worked on investigations and diagnoses per organizational unit split by Problem type
Length of time required to formulate solution to problem by Problem type
Useful for workforce analysis and for determing lob costs. Problem Management Team
Process Owner
Availability Manager
Capable
Number and impact of Incidents occurring before the root Problem is closed or a Known Error is confirmed
Evaluation of the extent of incidents arising from a Problem before the root cause is determined,
Measures the reaction time from both the Incident and Problem Management areas in determining root cause. Problem Management Team
Incident Manager
Process Owner
Capable
Ratio of Immediate (reactive) support effort to planned support effort in Problem Management
Evaluation of time spent conducting 'damage control' versus time spent on planned Changes
Determines how proactive the company is regarding the mitigation of Problems versus putting out fires'. Problem Manager
Change Manager
Process Owner
Capable
Elapsed Time to Close a Problem Time measurement from the point a Problem is opened to the point where it is dosed
. Since this includes the execution of the solution this would also include Change and Release Management elapsed time regarding the build and implementation of the solution.
Performance Indicator. This is a Touchpoint with Change and Release Management_ Problem Management Team
Process Owner
Capable
Elapsed Time to Date on Outstanding Problems
A daily report designed to track outstanding problems and how they are progressing
  Problem Management Team Capable
Expected Resolution Time on Outstanding Problems
Expresses the anticipated resolution time for an outstanding Problem.
This is a speculative measurement which may help regarding downtime estimation or resource planning. It may point to a particular Problem that needs increased attention but is should net be considered as a trending indicator. Problem Management Team Requires Research
Mean/Maximum Elapsed Time to close Problems
Compares averages and maximum times for trending purposes. Can also be used for variance analysis.
Performance Indicator -Establishes averages for comparisons in order to gauge the process efficient Problem Manager
Change Manager
Process Owner
Requires Research
Change
Impact of Change (degree of Service increase}
Positive impact of Change on Service (Availability)
Performance Indicator - Touchpoint to Availability, and Problem Management. Change Manager
CAB
Process Owner
Incapable
Decrease in service disruption over time resulting from Change
Validation that the Change being implemented is positively affecting Service by reducing or eliminating disruptions
Performance Indicator Change Manager
CAB
Process Owner
Requires Research
Number of Changes Implemented in the Period by CI, Configuration Type, Service
Volume count for a particular period viewed from several categories to evaluate process efficiency..
Performance Indicator Change Manager
CAB
Process Owner
Capable
Breakdown by Reason for Change
Assesses the volume counts by Reason for Change to note any trends or problem areas that may require further research.
Performance Indicator Change Manager
CAB
Process Owner
Capable
Number of Successful Charges
Measures the success of the process components such as RFC submission. Build and Testing phases by looking at the success of the Implementation
Performance Indicator Change Manager
CAB
ITEC
Process Owner
Capable
Number of Changes Backed Out and Reasons
Examines the volume of items implemented then backed out for one reason or another. Goal is to have few of these. Reasons help to identity causes for future elimination_
Performance Indicator Change Manager
CAB
Process Manager
Capable
Number of Incidents Traced to Changes
Measure of Change efficiency in regards to communication training and impact analysis. To be used for risk elimination in future,
Touchpoint to Incident Management. Change Manager
CAB
Process Manager
Incident Manager
Incapable
High Incident of RFCs to a Particular CIs and Reasons
Identifies areas of risk by association of volume counts to particular CIs
Proactive analysis that identifies risk and allows for appropriate action to be taken to mitigate risk. Change Manager
CAB
Process Manager
Incapable
Trending of RFCs by Type
Analysis of trends based upon past and current data by type to forecast future events to be used to address perceived issues.
Proactive analysis that identifies potential issues or arcs of focus or investigation Change Manager
CAB
Capable
Previous Period Comparisons
Compare/contrast current to previous periods to gauge process performance
Performance indicator Change Manager
CAB
ITEC
Process Manager
Capable
Number of RFCs Rejected and Why
Provides volumes and reasons for RFCs being rejected for action. Allows analysis of to prevent abuse on to highlight training requirements.
Performance indicator Change Manager
CAB
Requires Research
Proportion of implemented Changes Unsuccessful (in total am by CI)
Analysis of authorized changes that were implemented but proved unsuccessful. By categorizing these numbers, focus may be pieced on individual areas requiring adjustment in activities.
This metric identifies where training of execution may be tacking in the correct identification of requirements to provide successful Change implementations or Problem resolutions. Change Manager
CAB
ITEC
Process Manager
Capable
Change Backlogs by CI and Stage
Measures Changes that are taking longer than average or estimated
This identifies possible workload issues or procedural issues that may be the cause of the backlogs. Change Manager
CAB
Capable
Ratio of Change Types
Comparison of Change Types to understand the workloads, the reasons for change and the exposure of the CABS/Charge Managers
Performance Indicator Change Manager
CAB
Capable
Ratio of Stardard:Minor:Signlficant:Major Changes
Comparison of volumes by category.
Performance indicator - Notes trends regarding category. Change Manager
CAB
Process Manager
Requires Research
Ratio of Submitted Changes by CAB
Comparison of volumes by CAB.
Performance indicator Compares efficiency by CAB. Change Manager
CAB
Process Manager
Capable
Ratio of Authorized/Rejected/Pending Changes by CAB
Comparison based upon the CAB review of the RFCS-
Performance Indicator- Comparison of responsiveness by CAB. Change Manager
CAB
Process Manager
Incapable
Ratio of Successful vs. Unsuccessful Changes by CAB
. Application & Technology Comparison of the outcomes of the implementation of RFCs_
Performance Indicator - Quick comparison of the effectiveness of submitted changes. Change Manager
CAB
Process Manager
Capable
Number of incomplete Change Requests
Number of RFCs submitted that were incomplete for consideration by CAB. Requires a further breakdown of the rejection code to identify why rejected (new requirement),
Used to indicate possible training need. Evaluates the efficiency of training for tool users Change Manager Incapable
Variances Between Elapsed TImes Between Measuring Points
Differences in time (hours or days) between phases in the Change Management Process at the Business Sponsor. CAB, and Priority levels as well as compared tot" SlAs (if any))
Performance indicator - Used to analyze differences in elapsed times to identity issues. Would require the development of averages and/or SLAs. Change Manager
Process Manager
Requires Research
Aging By Status
(Submitted/Authorized/Pending/Build/Test)- Measurement of elapsed time in each status of the Change Process
Prevents RFC's from falling between the cracks' and being forgotten. Change Manager
CAB
Process Manager
Requires Research
Average Time to Create an RFC
Average time it takes to enter an RFC from the moment the screen is opened to the point that the submission is complete.
Evaluates the user interface to determine tow fast and easy it is to use. Measures the effectiveness of the user interface, Change Manager
Process Owner
Incapable
Correlation of Incidents to Change
Measures the number of incidents that Change use related to a change This could be done by comparing volume reports for each to see if spikes occur In incidents immediately after a change takes place.
An increase in Incidents as a result of a Change may point to a lapse or defect in the Change process Measures the effectiveness of the Change Process via comparison to fallout on the Incident Process Change Manager
Process Owner
Incident Manager
Incapable

[To Annexes]

Annex A6.14 - Incident Metrics Report

Incident Metric Report

[To Annexes]

Annex A6.15 - Support Center Scorecard - Daily

Support Center Scorecard - Daily

[To Annexes]

Annex A6.16 - Support Center Scorecard - Monthly

Support Center Scorecard - Monthly

[To Annexes]

Bibliography for this Section

Interviews:

Books:

Document:
[To Annexes]



Visit my web site