HDI - Implementing Incident Management

6.1.1 Description

6.1.2 Relationships to other processes

• Service Level Management (staffing issues may affect ability to meet service level agreements)
• Knowledge Management (knowledge collected may be added to the CMDB (and/or Knowledgebase)
• Problem Management (a collection of incidents may be identified as a problem, and Customer Service Management (poor or inadequate Incident Management will show up in poor customer service ratings).

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.

6.1.4 Possible problems and issues

Issue/Problem	Potential 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 Management	Listen 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

• Standardization - during all phases of Incident Management process development and implementation, the use of a technical writer to provide a consistent `look and feel' to Incident Management materials is strongly recommended. In ongoing operations as well as working toward optimization, staff from the areas affected by Incident Management process changes should be included in identifying current process gaps and their associated process improvement initiatives.
• Budgetary constraints - implementing Incident Management will cost money. A cost-benefit analysis will help to identify opportunities to improve current processes. It may be necessary to hire consultants to assist with gap analyses and/or training efforts, hire staff dedicated to Incident Management efforts or purchase new tools to help support the process. However, the potential benefits to the customer and business will outweigh the costs.
• Skill shortages - certain skill sets will be needed when implementing a new process, based on the Incident Management goal state. The necessary skill sets may or may not already exist in the organization. Plans will need to be put in place to bring personnel up to speed on Incident Management frameworks and processes; training plans for new staff must be created; and initiatives started to ensure new skill sets are identified at the same time as new process improvement opportunities.

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

Security issues

• Security departments within the organization may not be comfortable with the Support Center handling such incidents as password resets. These may have to be handled by the central Security Department instead.
• Authorization forms may be required for Support Center personnel to gain access to certain security-related products and services.
• New processes may be necessary to ensure that products and services are recovered quickly, yet within secure parameters so as not to compromise IT security policies.
• Physical access to computer and network equipment should be restricted to authorized personnel only.

A decision not to implement Incident Management may result in:

• no one managing and escalating incidents, which may ultimately have an adverse impact on IT service quality
• specialist support staff interruptions, making them less productive (when many issues could have been resolved by first-line Support Center personnel)
• disruption of normal work duties within departments as co-workers ask one another for help instead of contacting the Support Center
• lack of coordinated management information
• lost, incorrectly managed or badly managed incidents.

6.2 - Implementation

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

• Gap Analysis - did the current state assessment and future goal state truly allow for an appropriate gap analysis to occur? Were any gaps identified through the course of the assessment left open?
• work instructions - were quality work instructions specific to the Support Center created and implemented as part of rollout?
• training materials - how satisfied were Support Center users with the training materials related to Incident Management created for implementation? How many gaps were identified? Have these been closed?
• knowledge transfer - use competency checks amongst Support Center staff to determine the success of knowledge transfer about the Incident Management process
• timely completion of implementation - was Incident Management implemented in the timeframe originally committed to?
• stakeholder buy-in - did all the applicable stakeholders `buy in' to the concept and processes associated with Incident Management?

6.2.2 Support Center Function's role

Responsibilities and activities

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

• the Gap Analysis by helping the Manager identify where gaps exist between current state and future/goal state processes
• work instructions, as the Center staff best understand the level of detail that will be needed to ensure that everyone understands what will be required in the future
• training materials, because Center personnel can gauge what kinds of materials will (and will not) be successful
• how knowledge about the Incident Management process will be transferred to the staff.

Deliverables

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

• Current State Assessment
• Gap Analysis
• work instructions
• job aids
• tool and core process training materials.

Competencies

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:

• customer-focused
• articulate and methodical
• trained in interpersonal skills
• able to understand the business's objectives.

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

• Gap Analysis - did the current state assessment and future goal state truly allow for an appropriate gap analysis to occur? Were any gaps identified through the course of the assessment left open?
• work instructions - were quality work instructions specific to the Support Center created and implemented as part of rollout?
• training materials - how satisfied were Support Center users with the training materials related to Incident Management? How many gaps were identified? Have they been closed? Do they understand how to perform their jobs in the new environment?
• knowledge transfer - the level of knowledge about the Incident Management process can be determined by competency checks among the Support Center staff
• timely rollout - was the Incident Management process implemented on time?

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:

• process design consultant: a process design consultant may be used to perform gap analyses and write associated work instructions for groups to help them close any identified gaps between current and goal states
• process trainer: trainers may be employed to train areas on Incident Management processes and detailed work instructions
• class registrar: additional staff may be used to not only register people for upcoming training sessions, but also to track the people who have gone through process training, which will help ensure everyone has participated.
• technical writer: a technical writer on staff can help with all your documentation - the process handbook, assisting with meeting minutes or helping with the content and compilation of training materials.

6.2.3 Planning for implementation

• Meeting agenda template to be used for status meetings, start-up meetings, etc. (See Annex A63 Agenda for Implementation Meeting)
• Representative list of the personnel representing various areas (See Annex A6 4 Project Teams)
• Deliverables Contract defining which deliverables the sponsor will sign off (See Annex A65 Deliverables Contract)
• Incident Charter, a document explaining the implementation and why it is being done (See Annex A6 6 Project Charter sample)
• Incident Scope defining the areas/applications that will implement Incident Management (See Annex A6 6 Project Scope sample)
• Project work plan providing the dates and schedule for delivery (including milestones and key deliverables) (See Annex A6.8 Support Center - Implemtnation Workplan).
• Communication Plan showing how, when and to whom the Support Center will be communicating (as well as the vehicle(s) that will be used) (See Annex A610 Steps to developing a Communications Action Plan)
• Training Plan for who needs to attend, invitation strategy, location information, materials to be used, etc
• Current State Assessment with questions to determine the organization's current maturity
• Gap Analysis to identify any gaps between current state and ITIL/Incident Management goal state (See Annex A611 Gap Analysis Questionnaire)
• Incident Work Instructions showing a detailed, step-by-step process for conducting Incident Management within the area

Steps to take

• Determine scope
• Identify key roles
• Address awareness
• Identify gap-related opportunities (between current and goal states)
• Identify and develop documentation (training materials, policies, work instructions, etc)
• Schedule and conduct training
• Formally implement the process

Groups to contact

• Service Level Management
• Change Management
• Problem Management
• Any other process groups in existence in your organization
• Communications Department

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

Necessary information and data

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

• ensuring that all gaps identified during the Gap Analysis are closed as necessary
• competency checks after process training
• periodic evaluations of effectiveness compared to the baseline.

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

Things that always work

• gain highly visible and vocal executive / senior management sponsorship for implementation efforts
• 'partner with all stakeholder areas
• gain commitment for resources and budget in advance to ensure coverage and growth
• focus on culture change as necessary to ensure the goals of Incident Management are met restoring normal service operation quickly and keeping customers satisfied)
• consider including a relevant objective on every employee's evaluation/scorecard to ensure cooperation

Little things that deliver big returns

• senior leadership support/sponsorship
• A detailed and well-executed communication plan
• Branding the project / ITIL efforts internally
• Use of Themes
• Conduct a session taking trainees through 'A day in the life of an incident'.
• Rewards and recognition - reward people for following new ITIL/Incident Management procedures. Little things like movie tickets or company logo items can go a long way to motivate employees.
• Create a recognition program in which recognition notes are left at associates' desks as acknowledgement for following IT Service Management practices. "Catch people doing things right."
• When designing a new tool for the market, pair technical leads with each functional area manager, so that functional specifications for the tool are developed in partnership.

Little things that always get forgotten

• Ask for, and listen to, suggestions from all personnel involved in following Incident Management procedures and using new or enhanced Incident Management tools.
• If a new tool is being rolled out as part of Incident Management implementation, consider building in a mechanism for real-time feedback during testing. Employees asked for feedback about particular enhancements during testing can say whether certain elements truly add value to the process tool - or not. This helps developers to process feedback more quickly and make adjustments along the way.

6.2.5 Key process activities

Process rollout to the Support Center

• Define scope - Together with your executive sponsor, define a clear scope of who should be included in the implementation. This should be documented in a charter and scope document.

• Identify resources and budget - Depending on your budget and the resources that your sponsor can commit to the Incident Management implementation, begin to identify your core team. Then identify those team members within the departments in scope that will commit resources to the implementation efforts.

• Assemble team - Bring your team together, and share with them the charter and scope to get them started. Build the team and spend time to move from `forming and storming' stages to get to a high performing team. Learn what strengths you have in your team and make best use of those strengths as you define who will do what.

• Meetings
  • Start-up with team.
  • Conduct weekly implementation meetings.
  • Sponsor meetings

• Identify metrics/KPIs/goals - Understand what will constitute success for your Incident Management implementation. Support it with data and statistics that your business partners and customers will understand. Keep it up to date and communicate it often to show progress.

• Workflow design - You should have a team of process designers who have defined the Incident Process for your organization. The document / handbook that represents your organization's Incident Management process is what you will be implementing. It includes a workflow diagram (model), policies and procedures, tool requirements, management information, roles and responsibilities and a glossary.

• Tool selection/configuration - Tool requirements from the process document / handbook are an input to this activity Build or buy decision Coordinate tool needs - if implementing a tool, this is a project in its own right Select vendors if required Choose tool/software Install tool/software.

• Current state assessment
  • Identify current state
  • Use a questionnaire to interview those who have input on the current state

• Perform Gap Analysis
  • Compare current state to goal state (any core processes and/or work instructions)
  • Identify tool and process gaps
  • Document gaps
  • Gap Analysis sign-off from stakeholders
  • MILESTONE: Complete Change / Incident Gap Analysis

• Work instructions
  • Create step-by-step instructions for how to perform Incident Management processes in each department or area of the organization Share generic work instructions that already exist
  • Review work instructions
  • Revise work instructions as needed Deliver work instructions to the team and then to the customer
  • Work instruction sign-off from customer
  • MILESTONE: Work instructions complete

• Perform training
  • Identify core process training needs
  • Prepare training materials including handouts and presentations
  • Communicate core process training
  • Schedule core process training
  • Deliver core process training
  • MILESTONE: Core process training complete

• MILESTONE - Incident process rollout complete

6.2.6 Methods and techniques

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

• competency checks to determine the level of Incident Management maturity within affected groups
• surveys of individuals to determine Incident Management competency level
• training material and presentation assessments
• risk documents created by internal auditors if gaps still exist
• an assessment of whether any additional gaps were identified during implementation
• a list of any stakeholders who did not `buy in' to Incident Management and why.

6.3.1 Support Center Manager's role

• driving the efficiency and effectiveness of the Incident Management process
• producing management information
• managing the work of Incident support staff (both first-and second-line, as applicable)
• controlling the closure process associated with registered incidents
• monitoring the effectiveness of Incident Management and making recommendations for improvement
• participating in the development of Incident Management systems and maintaining those systems
• ensuring that status and resolution progress checks are done on all incidents to ensure they are resolved (and within agreed Service Level targets)
• ensuring that follow-up occurs with owners/solvers of Incidents that are likely to breach agreed Service Level targets
• ensuring that any incidents moving between different specialist support groups are particularly noted (as they may be indicative of uncertainty about an issue or a dispute amongst support staff groups)
• ensuring that affected users are kept informed of progress on Incidents

Competencies required

• be a strong champion for IT Service Management
• understand the business the Center supports and assist it in meetings its goals
• work to keep morale and productivity up with high-performing personnel in place
• ensure that training related to Incident Management and supporting customers is ongoing, so that staff are regarded as experts who can solve issues competently
• promote continuous process improvement programs and activities to ensure incident management goals are aligned with the business goals.

Key Performance Indicators

• total number of incidents
• percentage of incidents handled within agreed resolution and response service levels
• average cost per incident
• percentage of incidents closed `first time final' by the Support Center
• number and/or percentage of incidents processed per Support Center analyst and/or workstation
• number and percentage of incidents resolved remotely, without the need for a site visit
• mean time before failure
• mean time to repair.

Critical Success Factors (CSFs) and Key Performance Indicators (KPIs)

6.3.2 Support Center Function's role

• provides advice and guidance, working toward the rapid restoration of service
• is responsible for monitoring the resolution of all registered incidents, including the closure process
• provides reporting of business-focused management information related to incident service level agreements.

Support Center responsibilities include:

• incident registration
• initial support and classification
• ownership, monitoring, tracking and communication
• resolution and recovery of incidents not assigned to second-line support
• closure of incidents.

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

• monitoring incident details (including any Configuration Items that are affected)
• incident investigation and diagnosis
• detection of possible problems (and assignment of them to the Problem Management team)
• resolution and recovery of assigned incidents
• creation of knowledgebase entries.

Deliverables

• monitoring the status and progress toward resolution of all open incidents
• keeping affected users informed about progress
• escalating processes as necessary.

Competencies required

• customer-focused
• articulate and methodical
• adept in interpersonal skills
• able to understand the business's objectives
• equipped with technical documentation skills.

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

• total number of incidents
• percentage of incidents handled within agreed resolution and response service levels
• average cost per incident
• percentage of incidents closed `first time final' by the Support Center
• number and/or percentage of incidents processed per Support Center analyst and/or workstation
• number and percentage of incidents resolved remotely, without the need for a visit.

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

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

• keeping Incident Management processes in line with business goals
• ensuring that new employees receive adequate process and tool training
• using Key Performance Indicators to determine potential process improvement opportunities
• gaining and using candid feedback from users about what is (and is not) working well.

6.4 - Optimization

6.4.1 - Support Center Manager's Role

Responsibilities and activities

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

• gaining access to additional tools and/or applications to conduct their support successfully
• training (job aids, additional knowledge, etc) in order to facilitate a higher `first time final' rate.

Competencies required

Key Performance Indicators

6.4.2 Support Center Function's role

Responsibilities and activities

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

Competencies required

Key Performance Indicators

• comparing Support Center performance to commitments
• performance data, customer feedback and industry intelligence inputs to improve processes and interfaces
• outsourcing options considered based on requirements
• skill levels of staff
• number of staff
• maximizing physical workspace
• maximizing Support Center technology
• applying monitoring and metrics for continuous improvement.

6.4.3 Other key roles and functions in the optimization process

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

• A good forecasting effort should define and plan for the needs ahead. What skill sets will be required? Technical writers may be needed for expert documentation and reporting, and Six Sigma expertise for metrics and measurement efforts.
• Consider all three sides of the IT triangle: people, process and technology. Be prepared to invest in needed resources and commitments.
• Create metrics to report whether key performance indicators are being met.
• Maintain ongoing communication with customers using Incident Management. Consider their feedback about what is working well, what is not working well and what they would improve.
• Remember that there is always room for improvement.

6.4.5 Future impact of this process on the Support Center

• some metrics may be useful for proving the need to give the Support Center more responsibility for resolving incidents that have previously been passed to specialty groups that are more expensive to the organization. Providing the first-line support staff with the tools to handle additional types of incidents can demonstrate reduced costs, as well as improving customer satisfaction because customers' issues are resolved more quickly.
• additional tools to assess impact and criticality of certain types of issues will also lead to improvements between the Incident Management and Problem Management processes.

6.5 Measurement, costing and management reporting

6.5.1 Implementation: benefits and costs

Why implement this process and what can be gained

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

• the purchase of new tool(s) as necessary to ensure success
• tool-related expenses such as knowledge base transfer, licensing fees, tool customization, professional consulting and cost to implement..)
• training staff on the Incident Management framework and the processes put in place to support it
• training on new tools (if applicable)
• creation and maintenance of a configuration database (if one does not already exist).

Making the business case to implement Incident Management

Consider following these steps to build the business case:

• Examine the current environment. Use a technique such as SWOT analysis (Strengths, Weaknesses, Opportunities and Threats) to determine the current state of the Support Center. (See Annex A6.12 SWOT Analysis)
• Determine objectives. Armed with results from the SWOT analysis, determine what the goal state looks like and what objectives would need to be undertaken to achieve that state.
• Identify risks. What potential risks exist with implementing Incident Management within the Center?
• Perform a cost analysis. Demonstrate how implementing Incident Management will improve efficiency, improve customer satisfaction, and ultimately result in cost reduction due to quicker incident resolution.
• Document the business case. Ensure that information related to the previous four steps is included.
• Present the business case. Provide the written business case to appropriate sponsors and stakeholders and sell the idea of what Incident Management can do for the organization.
• Implement the improvements. After obtaining buy-in from sponsors and stakeholders, take the steps necessary to implement the processes

Metrics and Key Performance Indicators

• decide and set metrics to measure the effectiveness of the Support Center
• establish a baseline before discussing formal Service Level agreements with customers
• provide a framework to collect metrics and use them to measure performance against the SLA criteria
• ensure customers are aware of what is being done with Incident Management processes and why, if there are changes occurring that are not transparent to the customer.

Management reporting

6.5.2 Ongoing operations

Costs

• ongoing costs associated with Incident Management tools, including the incident-tracking tool, knowledge base, reporting tool, etc.
• training costs associated with ensuring that staff are equipped to meet customers' needs (which may include cross-training)
• licensing fees associated with keeping the tools up to date
• the need for promotions/incentives to build and maintain morale within the Center.

Metrics and Key Performance Indicators

• total incident volume
• incidents processed per Support Center workstation or analyst
• percentage of incidents handled within Service Level Agreements
• percentage of incidents closed by the Support Center `first time final' (See Annex A6.14 Incident Metrics Report)
• Metrics visually demonstrate the processes in action. They also enable the Support Center to:
• evaluate the processes for further refinement or enhancement
• evaluate the usage of the processes in each area
• define the basis for continued process improvement.

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

• unclear direction or focus for improvement actions
• limited ability to make qualified and quantified strategic decisions
• dissatisfaction with IT provision by the business
• poor perceived availability of IT services.

6.5.3 Optimization: benefits and costs

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?

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

Metrics and Key Performance Indicators

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

• historical data based on the key performance indicators that have been set, so that management can make informed decisions about what future strategies may be needed customer perception of the Support Center
• information related to potential action items that may help the Support Center better align its services with business and customer needs.

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

6.5.4 Tools Too( selection

• seek to understand requirements for the tool by analyzing current processes, functions needed and capability requirements. Be sure to consult with different kinds of potential users for the tool who act in different capacities related to Incident Management. (Consider both functional and interface requirements.)
• keep in mind the possibility that there may be many more users of the new tool than any current tool(s) in place due to Incident Management process implementation. Consider any potential impacts to the infrastructure as a result of both a new tool and an increased volume of users
• define reporting requirements early in the process to ensure they are not an afterthought
• each documented requirement should be assigned a level of importance. (Decide what is absolutely necessary, what the organization can do without if necessary, etc.)
• analyze proposed system solutions (new tools) based on their ability to achieve he defined requirements
• if a large amount of tool customization is required, consider how customizable a tool is and what kind of effort will be required
• consider the expertise required to build/customize a tool. Is that expertise available within your organization? Is the expertise widely available on the market? Is it highly sought after, but not widely available? (Differences in external vendor/contractor prices may directly affect the bottom line of what tool is ultimately chosen.)

Testing before implementation

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

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

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

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):

• ACD (telephone) systems integration for automatically registering certain sets of information about users/customers (name, phone number, etc.)
• diagnostic tools, such as a natural language search `knowledge base' of information
• tool(s) that allow for automatic logging of incidents when issues are detected on systems (as well as notification to affected parties)
• if a Configuration Management Database is in use, a tool that automatically extracts data from it (which can be useful for quickly identifying failed items and affected items)
• a 'ticker' that shows live data related to Support Center activities. This may include such information as call volume, known outages and service disruptions, average wait time for customers, the number of calls offered, calls abandoned etc.
• lowered cubicle walls to support knowledge transfer between staff. (Note that this knowledge transfer technique is not a replacement for a knowledgebase, but rather a supplement to it.)

Annex Documents

Overview

• Annex A6.1 - Overview of Capability Maturity Model (CMMI)
• Annex A6.2 - Questions to Guide Sustainable Change
• Annex A6.3 - Agenda for Implementation
• Annex A6.4 - Project Teams List
• Annex A6.5 - Deliverables Contract
• Annex A6.6 - Project Charter Worksheet
• Annex A6.7 - Project Scope Worksheet
• Annex A6.8 - ITIL/Support center Incident Management Implementation Workplan
• Annex A6.9 - Steps to develop a Communications Plan
• Annex A6.10 - Communications Plan
• Annex A6.11 - Implementation Scope Questionnaire
• Annex A6.12 - SWOT Analysis
• Annex A6.13 - Proposed metrics and Priority Codes
• Annex A6.14 - Incident Metrics Report
• Annex A6.15 - Support Center Scorecard - Daily
• Annex A6.16 - Support Center Scorecard - Monthly
• Bibliography for Incident Management Section

Annex A6.1 - Requirements Checklist

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
   • Requirements Management,
   • Software Project Planning,
   • Software Project Tracking and Oversight,
   • Software Subcontract Management,
   • Software Quality Assurance,
   • Software Configuration Management

3. Defined
   • Organization Process Focus,
   • Organization Process Definition,
   • Training Program,
   • Integrated Software Management,
   • Software Product Engineering,
   • Intergroup Coordination,
   • Peer Reviews

4. Managed
   • Quantitative Process Management,
   • Software Quality Management

5. Optimizing
   • Defect Prevention,
   • Technology Change Management,
   • Process Change Management

• Commitment to Perform (encompasses the presence of an organizational policy relating to the KPA and specifically assigning key responsibilities)
• Ability to Perform (includes training, resources, and other prerequisites)
• Measurement and Analysis (describes the status and quality measures that are used to control and improve the process)
• Verifying Implementation (describes steps taken to ensure that activities are performed according to established processes and procedures).
• Several common themes run through the key process areas of the CMM. As a starting point, written organizational policies state management expectations around the practice of each KPA. Status and issues are to be reviewed periodically with senior management. A recurrent expectation is that practitioners are trained to perform the activities expected of them. Most activities are to be performed according to documented procedures (in contrast to the oral history of many software cultures). Appreciating such philosophical and practical themes of the CMM is as important as remembering the nuances of each KPA. ^[Ref]

A6.1.1 SEI Capability Maturity Framework

• practices can be repeated. If you do not repeat an activity there is no reason to improve it. There are policies, procedures and practices that commit the organization to implementing and performing consistently
• best practices can be rapidly transferred across groups. Practices are defined sufficiently to allow for transfer across project boundaries, thus providing some standardization for the organization
• variations in performing best practices are reduced. Quantitative objectives are established for tasks; and measures are established, taken, and maintained to form a base-line from which an assessment is possible
• practices are continuously improved to enhance capability (optimizing).

Process Elements	Answers
Purpose	Why is a process performed?
Input	what work products are used?
Output	What work products are produced?
Role	Who (or what) performs the activities?
Activity	What 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:

• reviews and audits performed
• work products that are to be managed and controlled (or placed under configuration management)
• measurements to be made
• training
• tools. ^[Ref]

Annex A6.2 - Questions to Guide Sustainable Change

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 Works	What I Intend	How we talk	Action	How 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?

Annex A6.3 - Agenda for Implementation

Start-off for Organization

Others: Facilitator: Name

Goal:

• To begin working on the socialization and implementation of the XYZ Support Center (process/processes) across Organization XZY
• Agenda/Objectives:
• To review implementation approach
• To discuss implementation teams and members
• To assign implementation tasks to Working Group
• Handout and review questionnaires
• Discuss socializing ITIL within the Organization areas
• Handout & review status report

Notes:

• Expectations:
• Commitment Support
• Gap Analysis
• Work Instructions
• Socialization
• Requirements:
• Points of discussion:

Annex A6.4 - Project Teams List

Functional area 1:

• Core Team contact: name
• Working Team Representatives: name
• Working Team Back ups: name
• Implementation Committee: multiple names

Functional Area 2:

• Core Team contact: name
• Working Team Representatives: name
• Working Team Delegees: name
• Implementation Committee: multiple names

Functional Area 3:

• Core Team contact: name
• Working Team Representatives: name
• Working Team Delegees: name
• Implementation Committee: multiple names

Functional Area 4:

• Core Team contact: name
• Working Team Representatives: name
• Working Team Delegees: name
• Implementation Committee: multiple names

Functional Area 5:

• Core Team contact: name
• Working Team Representatives: name
• Working Team Delegees: name
• Implementation Committee: multiple names

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)

Annex A6.6 - Project Charter Worksheet

Project Charter

• Project name
• Document Author
• Project Sponsor
• date

Tangible Benefits

Description	Dollar Amount:	Liklehood (High, Medium, Low)
1.
2.
3.

• High - Very likely to be realized, probability is greater than 80%
• Medium - May or may not be realized, probability is 20 to 80%
• Low - Unlikely to be realized, probability is less than 20%

Intangible Benefits

Description	Liklehood (High, Medium, Low)
1.
2.
3.

• High - Very likely to be realized, probability is greater than 80%
• Medium - May or may not be realized, probability is 20 to 80%
• Low - Unlikely to be realized, probability is less than 20%

Major Assumptions & Constraints

Description	Assumption or Constraint	Importance (High, Medium, Low)
1.
2.
3.

• High - Critical to project success - If not valid then schedule would be delayed by over 1 month and/or budget would be exceeded by more than 25%
• Medium - Would affect the project - If not valid then schedule would be delayed by up to I month and/or budget would be exceeded by up to 25%
• Low - Minor project impact - If not valid then schedule would be delayed by less than 1 week and/or budget would be exceeded by less than 10%

Risks

Risk	Liklehood (High, Medium, Low)	Impact (High, Medium, Low)
1.
2.
3.

Liklehood
• High - Very likely to affect project, probability is greater than 80%.
• Medium - May or may not affect project, probability is 20 to 80%.
• Low - Unlikely to affect project, probability is less than 20%

Impact

• High - Schedule delay of over 2 weeks and/or over budget by more than 10%
• Medium - Schedule between 1 and 2 weeks and/or 5 to 10% over budget
• Low - Schedule delay of less than 1 week and/or less than 5% over budget

Dependencies

Project	Liklehood (High, Medium, Low)	Description of Impact
1.
2.
3.

• High - Very likely to be realized, probability is greater than 80%
• Medium - May or may not be realized, probability is 20 to 80%
• Low - Unlikely to be realized, probability is less than 20%

Project Structure and Key Roles

Project Charter Acceptance

Date	Role	Signature	Date Signed

Project Charter Revision Log

Date	Description	Change ID	Author	Approved By:

Annex A6.7 - Project Scope Worksheet

Project Scope

• Project name
• Project Manager
• date

• Project Description

• Business Need

• Project Goals

• Project Objectives

• Benefits

• Major Assumptions & Constraints

• Logical Scope

• Within the Scope of the Project

• Outside the Scope of the Project

• Organizational Scope

• External Organizations affected by the Project
  • Name:
  • Impact:
  • Name:
  • Impact:

• Departments affected by the Project
  • Name:
  • Impact:
  • Name:
  • Impact:

• Other Projects affected by the Project
  • Name:
  • Impact:
  • Name:
  • Impact:

• Major Project Deliverables
  • Deliverable:
  • Description:
  • Deliverable:
  • Description:
• Project Scope Acceptance

  Date	Role	Signature	Date Signed	Signed:

• Project Scope Revision Log

  Date	Description	Change ID	Author	Approved By:

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

IM.5	Line of Business Implementation Plan	Start Date	Due Date
IM.5.1	Scope
IM.5.1.1	Identify 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.1	Identify 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

Annex A6.9 - Steps to develop a Communications Plan

• Look at current vehicles
• Rate how they are doing
• What changes to current vehicles need to take place
• What gaps exist?
• Who are the chosen target audiences?
• Short term
• Long term
• What do we want to say?
• How to fill those gaps

Steps to create a specific Communication item:

• Expectations of the communication vehicle:
• What is the overall objective of the communication?
• Who is the intended audience?
• What form(s) of delivery will the communication take?
• How will it be delivered to its audience?
• What will be the basic layout (size, shape, etc.)?

Content

• What is to be said and why? Provide some detail here.
• How frequently will this be published or updated?
• When is the information given (If there are to be updates or future issues, for example, what information is given when? Provide a timeline.)

Project

• Who will lead the project?
• Who is on the team?
• Who will create what parts from the content?
• Who takes ownership for updating or for future issues, if applicable?
• What is the timeline for the project?
• If hardcopy format, how many are to be created, and when (single or multiple batches)?
• Points to stress/remember:
• Simplify (hide complexity where possible)
• Value to them - how do we show this (adds value to business and decision making)
• Educate on how the guidelines work, (changing standards in response to market)
• Tie to business strategy, local, global
• Show success story
• Flexibility will give us strength in changing marketplace, makes IT environment more responsive
• What do we need to communicate?
• High level vision - process
• More immediate level - return on investment
• What do we need from them?
• When do we need it?
• What might their objections be and how do we handle them?
• Is there anyone else that needs to be onboard prior to communicating to them?
• How do we communicate?
• Benefits to organization

Annex A6.10 - Communications Plan

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

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

• Working Group representative names:
• Name of delegates (if applicable):
• Department name being represented:
• Division names being represented within the department:
• Identify what technologies/disciplines your department is directly responsible for:
• For incidents involving your area, what are the Initial Points of Contact (IPOCs) for your customers? In other words, where do your incident tickets come from?
• Support Centers - what support centers do tickets come to your area from?
• Monitoring Tools - if incident tickets for your area are created automatically, please list what tools create those tickets.
• Self-initiated - does your area currently identify incidents yourselves? If so, how and where
• do these tickets get logged (e.g. not logged, call the data center and they open the ticket, logged in a departmental database or spreadsheet, etc.)?
• Other - list any other ways in which incidents may be initiated with your area (e.g. calls directly from customers, monitoring tools that page you directly, etc.)
• For Incident Management, please list all Tool specialty groups that belong to your area. Identify whether these groups are used for Level 1,2 or 3 support.

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:

• Support (handles incidents/problem/calls/pages, etc.) = S
• Administrator (ID admin, server admin, etc.) = A
• Implementer (makes changes to production) = I
• Lead (project lead, project manager, etc.) = L
• Management (manager, director, administrative support, etc.) = M
• Other = 0

Name	Manager	Role 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:

• Emergency changes:
• Typical frequent, recurring changes:
• Non-frequent but low impact types of changes:
• Changes that could have huge impact:

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:

• Severity 0, major impact incidents:

• Low Severity, low urgency incidents:
• Incidents identified through automatic monitoring tools:
• Incidents identified and reported by your team:

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.

Name	Current role/function

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

Name	Current role/function

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

Name	Type of Changes they will coordinate

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

Name	Role

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?

Annex A6.13 - Proposed Metrics and Priority Codes

Metric	Benefit	User	Tool
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

Annex A6.14 - Incident Metrics Report

Annex A6.15 - Support Center Scorecard - Daily

Annex A6.16 - Support Center Scorecard - Monthly

Bibliography for this Section

Interviews:

• Collins, Mary Leigh (2004) US Army Information Technology Agency, The Pentagon. [Interview] May 4.
• Conley, Janna (2004). Nationwide Process Management Specialist. [Interview] April 20.
• Deacon, Leslie (2004). Bank One Infrastructure and Operations Senior Manager. [Interview] April 19.
• Heere, Craig (2004). Nationwide IT Project Management Sr. Consultant. [Interview] April 26.
• Koon, Scott (2004). Mayo Clinic Help Desk Director. [Interview] May 6.
• Mahan, Suzanne (2004). Nationwide Program Support Lead for Continuous Process Improvements, Metrics and Training & Communication. [Interview] May 6.
• McLaughlin, Kevin (2004). Procter & Gamble Service Manager. [Interview] May 6.
• McTigrit, Fran (2004). Katy (Texas) Independent School District Director of Technology Customer [Interview] May 5.
• Meeks, Christina (2004). Nationwide Process Management Specialist. [Interview] April 20.
• Metcalf, Maureen (2004). Metcalf Associates President and Forman, John (2004) Integral Development Associates Managing Partner. [Interview] May 17.
• Milligan, Jim (2004). JW&M Consulting Group Principal Consultant. [Interview] April 19.
• Peterson, Paula (2004). Remedy Customer Support Manager [Interview] April 30.
• Pierce, MaryLynn (2004). Nationwide Service Desk Director. [Interview] April 19.
• Probst, Jack (2004). Nationwide Enterprise IT Process Integration IT Process Officer. [Interview] May 6.
• Rozdeba, Stan (2004). Accenture Operations Consultant. [Interview] April 20.
• Shinault, Merle (2004). Process Management Specialist. [Interview] April 20.
• Snider, William (2004). Nationwide Systems Analysis Lead. [Interview] April 20.
• Stahl, Ron (2004). Nationwide IT Project Management Consultant. [Interview] April 22.
• Storts, Scott (2004). Nationwide IT Process Management Specialist. [Interview] May 18.

Books:

• Office of Government Commerce Staff 2000, Best Practice for Service Support, The Stationery Office United Kingdom.
• Pink Elephant 2003, Establishing a Service Desk According to ITIL Best Practices, Ontario, Canada
• Pink Elephant 2003, ITIL IT Service Management Essentials Course Workbook, Ontario, Canada
• Pultorak, Dave and Quagliariello, Pete, February 2003, Microsoft Operations Framework, Van Haren Publishing, info@vanharen.net.

Document:

• Pink Elephant 2004, Critical Success Factors (CSF) and Key Performance Indicators (KPI). Ontario, Canada

---